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
22
Embed
Supporting FIPA Interoperability for Legacy Multi-Agent Systems Christos Georgousopoulos 1 Omer F. Rana 1 ( ) 2.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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