supporting fipa interoperability for legacy multi-agent systems christos georgousopoulos 1 omer f....
Post on 14-Dec-2015
214 Views
Preview:
TRANSCRIPT
Supporting FIPA Interoperability for Legacy Multi-Agent Systems
Christos Georgousopoulos 1
Omer F. Rana 1
( http://www.cs.cf.ac.uk/Digital-Library/ )
2 Department of Computation, UMIST, Manchester
Anthony Karageorgos 2
1 Department of Computer Science, Cardiff University
What is needed to support interoperability between heterogeneous systems ?
Their design should be based on a common STANDARD
- it enables existing agent systems to be integrated in a seamless manner
- without amending their original architecture (i.e. design)
- limited code-writing is required (i.e. implementation) by using the API that we developed
- with limited or no knowledge of FIPA specifications
…which is relevant to software engineering since:
Introduce automatically FIPA interoperability in a number of systems…
Standard APIs for agent programming
System deployment using standards such as FIPA
E X M A SE X M A S
E X M A SE X M A S
non-F IPA c om p lian t
M A S
F IPA com plian t
M A S
A different approach of conforming a MAS to a FIPA compliant oneA different approach of conforming a MAS to a FIPA compliant one
The gateway:
- Contains the AMS, DF and Gateway agents
The gateway agent:
- Can communicate with its internal agents
- Is informed of any services provided by each of those agents
- Registers all the available services under its entity
(an EX MAS can only see those 3 agents)
A different approach of conforming a MAS to a FIPA compliant oneA different approach of conforming a MAS to a FIPA compliant one
When an EX MAS needs to communicate with the legacy MAS:
- The EX Agent sends its request to the Gateway agent
b) passes it to the appropriate internal agent
- The Gateway agent: a) translates the message
- The internal agent: a) receives the message
b) accomplishes the request
c) sends the response back to the Gateway agent
b) gives feedback to the EX Agent
- The Gateway agent: a) translates the message to ACL
A different approach of conforming a MAS to a FIPA compliant oneA different approach of conforming a MAS to a FIPA compliant one
Multiple gateway agentsMultiple gateway agents
MAS 2
non-FIPA compliant
service 1
s ervic e 2
s ervic e 3s ervic e 4s ervic e 5
EX MAS
DFAMS
FIP
A g
atew
ay
G A 1
G A 2
G A 3
Some developers might need to expose more than one agents to an external MAS…
- Balancing the incoming requests among the existing gateways agents
- Increasing fault tolerance of the interoperability part of a legacy MAS
The introduction of multiple gateway agents with replicated services may also be useful for:
Case scenariosCase scenarios
Three case scenarios for the FIPA-compliant gateways…
- A single gateway agent with all the available services registered under its entity
- A gateway agent per service
- Multiple gateway agents with replicated services
Steps of deploymentSteps of deployment
- register with AMS, DF
- be aware of the available services provided by its internal agents
- translate an ACL message to a form understood by its internal agent and vice-versa
- be able to communicate with its internal agents and vice-versa
The deployment of the FIPA-compliant gateways involves two steps
The creation/configuration:of each of the gateway agents
of the FIPA-compliant gateways 1
2
The gateway must be FIPA-compliantmust adhere to:
- FIPA Agent communication specifications
* creation/initialization of AMS, DF agents
* setup of MTS (configure the ACC)
* concerns only the gateway agent (not any internal agents)
- FIPA Agent management specifications
1 The gateway agent must:2
GatewayAgent APIgateway_setup script
GatewayAgent APIGatewayAgent API
Method summary
void disable() Disables the gateway agent and frees-up resources
String getID(GatewayAgent GatewayAgent_name) Returns the unique ID of a gateway agent - specified by the GatewayAgent_name
boolean isEnabled(GatewayAgent GatewayAgent_name) Returns true if a gateway agent is alive - specified by the GatewayAgent_name
void addProperty(LinkedList property_details) Adds a property to the gateway agent - specified by the property_details
void delProperty(String service_name) Removes a property from the gateway agent - indicated by the service_name
LinkedList getProperty(String service_name) Returns a property of the gateway agent - specified by the service_name
LinkedList getProperties() Returns all the properties of the gateway agent
int getPropertiesSize() Returns the number of the gateway agent’s properties
void updProperty(String service_name, LinkedList property_details) Updates a property of the gateway agent - indicated by the service_name, the property_details specify the property details to be updated
void delPerformative(String performative_name) Removes a performative from the gateway agent’s list of supported performatives - indicated by the performative_name
int getNumberOfPerformatives() Returns the number of performatives supported by the gateway agent
LinkedList getPerformatives() Returns a list of the performatives supported by the gateway agent
void setPerformative(String performative_name) Adds a performative to the gateway agent’s list of supported performatives - specified by the performative_name
void delEXservice(String ex_service_name, String ex_DF_name) Removes the external service specified by ex_service_name from the configuration details of the gateway agent. The ex_DF_name indicates the DF of the MAS hosting the service to be removed
LinkedList getEXservices() Returns a list of the external services stored in the gateway agent’s configuration details
void setEXservices(String ex_DF_name, LinkedList service_name, String com_protocol) Sets a list of external services specified by the service_name parameter, the DF’s name of the MAS which hosts the specified services indicated by the ex_DF_name parameter and a list of the communication protocols supported by the corresponding MAS
String sendRequest(String ex_service_name, String message) (gateway agent) sends a REQUEST to the external agent that provides the service indicated by ex_service_name with content as the content of the message parameter
Constructor summary
GatewayAgent(String platform_profile, String name, String ownership) Construct a new gateway agent
Creation of the Gateway agentCreation of the Gateway agent
1 import GatewayAgent.*;2 ...3 4 public class EXSA5 {6 7 public void initialise()8 {9 GatewayAgent EXSA;10 IEXSA_serv exsa_serv=null;11 12 try // get a proxy for that class13 {14 exsa_serv=(IEXSA_serv) Namespace.lookup("//localhost:8000/EXSA_serv");15 }16 catch(Exception e) {}17 18 LinkedList properties=new LinkedList();19 properties.add("EXSA");20 properties.add("serve_EXMAS");21 properties.add("EX_SARA_ontology.dtd");22 properties.add(exsa_serv);23 properties.add("EXSA_URA");2425 // Setup the Gateway agent26 EXSA=new GatewayAgent("c:/fipaos/profiles/platform.profile",”EXSA”,”SARA”);27 EXSA.addProperty(properties);28 ...29 }30 }
The GatewayAgent Librarymust be imported
EXSA is declared asa GatewayAgent
EXSA is constructed by calling theconstructor of the GatewayAgent
configure the gateway agent
iii) a name for its owner
ii) a unique name for the gateway agent
i) the location of FIPA-OS configuration file
i) service-name
ii) service-type
iii) service’s ontology
iv) Internal agent that provides the corresponding service
v) Internal agent’s method
Request handling by the Gateway agentRequest handling by the Gateway agent
public String EXSA_URA ( String do_undo, String message, String convID )
do: perform an action i.e. a REQUEST is receivedundo: cancel a previous action i.e. a CANCEL is received
external request translated into the form understood by the Internal agent
supports agent communication sessions
REQUEST
AGREE NOT-UNDERSTOOD
INFORM FAILURE
REFUSE
INPUT
OUTPUT
(from external MASto Gateway Agent)
(From external MAS)
Gateway Agentto
(message validation)
(message is valid)
(Request has been servedsend the results)
(Request has not been served dueto internal agent’s error)
(message is valid butinternal agent in either
down or unable of contacting)
(message is invalid)
System’s architecture remains the same as before
Security is increased
- the FIPA-compliant gateways does not influence the original architecture of the MAS…
- the policy of the architecture remains hidden to the foreign Agency
- securing the FIPA-compliant gateways implies minimum security for the rest of the system
Advantages and limitations of adopting the FIPA-compliant gatewayAdvantages and limitations of adopting the FIPA-compliant gateway
Automatic FIPA interoperability with no or limited knowledge of FIPA specifications- saving time in terms of reading, understanding, applying the FIPA specifications to the MAS that needs to address FIPA compliance and testing its interoperability
- …due to the isolation of the interoperability part of the architecture (i.e. gateways) from the rest of the system, new/revised FIPA specs concern only the gateways
- limited knowledge of FIPA specs is only needed for supporting performatives that are not currently provided by the GatewayAgent API
( i.e. knowledge on the ACL message structure & the performative’s specifications)
- implementation is only needed for the gateway agent and its interaction with its internal agents that provides a service
Limitation on the kind of systems that need to address FIPA interoperability
- can stand as a firewall restricting agent (communication/migration) instead of ports
( i.e. advantage in performance of encrypting only the messages exchanged between the gateway agent and an external agent)
- the default GatewayAgent API supports 7 out of the 22 FIPA performatives
- systems that their interoperability with foreign systems is mainly based on the request of information
The FIPA interoperable SARA architectureThe FIPA interoperable SARA architecture
EXSA
URAS
URA
URA
AGENT ENVIRONMENT
AGENT ENVIRONMENT
LAA LRA
LMAUAA
UMA
LSA
LIGA
DB
FILEARCHIVE
COMPUTESERVER
META-DATA
URA
LAA LRA
LMA
LSA
LIGA
Web Server
Voyager platform
Voyager platform
FIPA-OS platform
FIPA-OS platform
EXSA
URA
AGENT ENVIRONMENT
UAA
UMA
Web Server
Voyager platform
FIPA-OS platform
CLIENT
EX MAS
EX MAS
CLIENT
EX MAS
Web SERVER 1
Information SERVER 1 Information SERVER 2
URAS
AGENT ENVIRONMENT
Voyager platform
FIPA-OS platform
EX MAS
Web SERVER 2
message exchange
creation of agent
Management agent’s interaction
movement
send/receive request
hidden architectural details
FIPA-compliant gateway
UIA: User Interface Agent
URA: User Request AgentUAA: User Assstant Agent
LIA: Local Interface AgentLAA:LMA:UMA:
LSA: LIGA: URAS: EXSA:
Local Assistant Agent Local Management AgentUniversal Management Agent
Local Security AgentLocal InterGration Agent
URA’s ServantExtermal Service Agent
LRA: Local Retrieval Agent
DB
FILEARCHIVE
COMPUTESERVER
META-DATA
URAS
URALMA
LSA
LRA LAA
LIGA
MTS
RMI Naming ServiceCORBA Naming Ser vice
Voyager platform
FIPA-OS platform
AMS DFACC
SARA information-server 1
AC
L
AC
L
AC
L
AC
L
Loo
kup
External MAS
ACC
MTS
AC
L
ACL over IIOPor RMI MTP
ACL overRMI MTP
Loo
kup
RMI Naming ServiceLo
oku
p
EXSA
Web ServerUPA
UMA
SARA web-server 1
URA
MTS
RMI Naming ServiceCORBA Naming Service
Voyager platform
FIPA-OS platform
AMS DFACC
AC
L
AC
L
AC
L
AC
L
Loo
kup
Loo
kup
External MAS
ACC
MTS
AC
L
ACL over IIOPor RMI MTP
ACL overRMI MTP
RMI Naming Service
Loo
kup
CLIENT
The SARA FIPA-compliant gatewaysThe SARA FIPA-compliant gateways
(of the Information-server)(of the Web-server)
<?xml version="1.0" encoding="UTF-8"?><!ELEMENT coordinates EMPTY ><!ATTLIST coordinates c1 NMTOKEN #REQUIRED ><!ATTLIST coordinates c2 NMTOKEN #REQUIRED > …<!ATTLIST coordinates c7 NMTOKEN #REQUIRED ><!ATTLIST coordinates c8 NMTOKEN #REQUIRED ><!ELEMENT ex_SARA_mes ( coordinates ) >
(request:sender agent_from_EX MAS_id:receiver EXSA_id:content (<?xml version="1.0" ?> <ex_SARA_mes> <coordinates c1="33.132" c2="-115.196" c3="33.501" c4="-114.607" c5="32.775" c6="-113.969" c7="32.409" c8="-114.555"/> </ex_SARA_mes>):language XML:ontology EX_SARA_ontology.dtd …)
Requesting a collection of SARA imagesRequesting a collection of SARA images
An external FIPA agent’s ACL message send to the SARA gateway agent
The service’s ontology
:content (<?xml version="1.0" ?> <ex_SARA_mes> <coordinates c1="33.132" c2="-115.196" c3="33.501" c4="-114.607" c5="32.775" c6="-113.969" c7="32.409" c8="-114.555"/> </ex_SARA_mes>
node inManchester University
node inCardiff University
1
2
3
Conclusion / summary
Future work: Support for mobility between heterogeneous MAS
Conclusion / summary
It is presented how a MAS can automatically inherit FIPA interoperability
Demonstration of the steps of deployment in accordance to the GatewayAgent API
Tests results of our experiments
1 package GatewayAgent;2 3 import fipaos.agent.conversation.*;4 import fipaos.agent.task.*;5 import java.util.*;6 7 public class PROPOSEperf extends Task8 {9 private Conversation conv;10 LinkedList properties;11 12 public PROPOSEperf(Conversation conv, LinkedList properties)13 {14 this.properties=properties;15 this.conv=conv;16 }1718 protected void startTask()19 {20 // developer’s code here21 }2223 }
Java Class Template of a performativeJava Class Template of a performative
gateway_agent.setPerformative(PROPOSE)
Multiple gateway agentsMultiple gateway agents
MAS 2
non-FIPA compliant
service 1
s ervic e 2
s ervic e 3s ervic e 4s ervic e 5
EX MAS
DFAMS
FIP
A g
atew
ay
G A 1
G A 2
G A 3
MAS 2
non-FIPA compliantFIPA compliant
s ervic e 1
EX MAS
DFAMS
FIP
A g
atew
ay
GA 1
GA 2
GA 3
Some developers might need to expose more than one agents to an external MAS…
- Balancing the incoming requests among the existing gateways agents
- Increasing fault tolerance of the interoperability part of a legacy MAS
The introduction of multiple gateway agents with replicated services may also be useful for:
Different approaches of standardization
KQML
MASIF
FIPA
Different approaches of standardization
- One of the 1st initiatives to specify how to support social interaction characteristics of agents using a protocol, based on speech acts
- No set of specifications ratified by a common forum/organization (different dialects exist)
- Does not support standarization of communication between agents on different platforms
- It regards the defining characteristic of an agent as to its mobility (only on a CORBA platform)
- Provides an ACL based on performatives- The key agent necessary for the management of the agent system
- The ontology necessary for the interaction between systems
- Defines Transport Level Protocols
top related