Supporting FIPA Interoperability for Legacy Multi-Agent Systems Christos Georgousopoulos 1 Omer F. Rana 1 ( ) 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

A 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 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 one

Multiple gateway agents  Some developers might need to expose more than one agents to an external MAS… - Balancing the incoming requests among the existing gateways agents - I- 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 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 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-compliant must 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 API gateway_setup script

GatewayAgent API Method summary voiddisable() Disables the gateway agent and frees-up resources StringgetID(GatewayAgent GatewayAgent_name) Returns the unique ID of a gateway agent - specified by the GatewayAgent_name booleanisEnabled(GatewayAgent GatewayAgent_name) Returns true if a gateway agent is alive - specified by the GatewayAgent_name voidaddProperty(LinkedList property_details) Adds a property to the gateway agent - specified by the property_details voiddelProperty(String service_name) Removes a property from the gateway agent - indicated by the service_name LinkedListgetProperty(String service_name) Returns a property of the gateway agent - specified by the service_name LinkedListgetProperties() Returns all the properties of the gateway agent intgetPropertiesSize() Returns the number of the gateway agent ’ s properties voidupdProperty(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 voiddelPerformative(String performative_name) Removes a performative from the gateway agent ’ s list of supported performatives - indicated by the performative_name intgetNumberOfPerformatives() Returns the number of performatives supported by the gateway agent LinkedListgetPerformatives() Returns a list of the performatives supported by the gateway agent voidsetPerformative(String performative_name) Adds a performative to the gateway agent ’ s list of supported performatives - specified by the performative_name voiddelEXservice(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 LinkedListgetEXservices() Returns a list of the external services stored in the gateway agent ’ s configuration details voidsetEXservices(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 StringsendRequest(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 agent 1 import GatewayAgent.*; public class EXSA 5 { 6 7 public void initialise() 8 { 9 GatewayAgent EXSA; 10 IEXSA_serv exsa_serv=null; try // get a proxy for that class 13 { 14 exsa_serv=(IEXSA_serv) Namespace.lookup("//localhost:8000/EXSA_serv"); 15 } 16 catch(Exception e) {} 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"); // Setup the Gateway agent 26 EXSA=new GatewayAgent("c:/fipaos/profiles/platform.profile",”EXSA”,”SARA”); 27 EXSA.addProperty(properties); } 30 } The GatewayAgent Library must be imported EXSA is declared as a GatewayAgent EXSA is constructed by calling the constructor 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 agent public String EXSA_URA ( String do_undo, String message, String convID ) do: perform an action i.e. a REQUEST is received undo: 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

 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 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 architecture

The SARA FIPA-compliant gateways (of the Information-server) (of the Web-server)

… (request :sender agent_from_EX MAS_id :receiver EXSA_id :content ( <coordinates c1="33.132" c2=" " c3="33.501" c4=" " c5="32.775" c6=" " c7="32.409" c8=" "/> ) :language XML :ontology EX_SARA_ontology.dtd … ) Requesting a collection of SARA images An external FIPA agent’s ACL message send to the SARA gateway agent The service’s ontology :content ( <coordinates c1="33.132" c2=" " c3="33.501" c4=" " c5="32.775" c6=" " c7="32.409" c8=" "/> node in Manchester University node in Cardiff University 1 2 3

Screen-shots of tests performed

Conclusion / summary Future work: Support for mobility between heterogeneous MAS Conclusion / summary  I t is presented how a MAS can automatically inherit FIPA interoperability  D emonstration of the steps of deployment in accordance to the GatewayAgent API  Tests results of our experiments

The End The End

1 package GatewayAgent; 2 3 import fipaos.agent.conversation.*; 4 import fipaos.agent.task.*; 5 import java.util.*; 6 7 public class PROPOSEperf extends Task 8 { 9 private Conversation conv; 10 LinkedList properties; public PROPOSEperf(Conversation conv, LinkedList properties) 13 { 14 this.properties=properties; 15 this.conv=conv; 16 } protected void startTask() 19 { 20 // developer’s code here 21 } } Java Class Template of a performative gateway_agent.setPerformative(PROPOSE)

Multiple gateway agents  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 1 st 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 he ontology necessary for the interaction between systems - Defines Transport Level Protocols