Supporting FIPA Interoperability for Legacy Multi-Agent Systems

1. Supporting FIPA Interoperability for Legacy Multi-Agent Systems Christos Georgousopoulos 1 Omer F. Rana 1 Anthony Karageorgos 2 ( http://www.cs.cf.ac.uk/Digital-Library/ ) 1 Department of Computer Science, Cardiff University 2 Department of Computation, UMIST, Manchester

2. What is needed to support interoperability between heterogeneous systems ? Their design should be based on a common STANDARD

3. Introduce automatically FIPA interoperability in a number of systems… …which is relevant to software engineering since:  System deployment using standards such as FIPA - it enables existing agent systems to be integrated in a seamless manner - with limited or no knowledge of FIPA specifications - without amending their original architecture (i.e. design)  Standard APIs for agent programming • limited code-writing is required (i.e. implementation) • by using the API that we developed

4. A different approach of conforming a MAS to a FIPA compliant one A different approach of conforming a MAS to a FIPA compliant one

5. A different approach of conforming a MAS to a FIPA compliant one A different approach of conforming a MAS to a FIPA compliant one  The gateway: - Contains the AMS, DF and Gateway agents (an EX MAS can only see those 3 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

6. A different approach of conforming a MAS to a FIPA compliant one 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 - The Gateway agent: a) translates the message b) passes it to the appropriate internal agent - The internal agent: a) receives the message b) accomplishes the request c) sends the response back to the Gateway agent - The Gateway agent: a) translates the message to ACL b) gives feedback to the EX Agent

7. Multiple gateway agents Multiple gateway agents • Some developers might need to expose more than one agents to an external MAS… • The introduction of multiple gateway agents with replicated services may also be useful for: • Balancing the incoming requests among • the existing gateways agents • Increasing fault tolerance of the • interoperability part of a legacy MAS

8. Case scenarios 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

9. 1 1 2 2 The gateway must be FIPA-compliant The gateway agent must: must adhere to: - FIPA Agent management specifications * creation/initialization of AMS, DF agents * setup of MTS (configure the ACC) • FIPA Agent communication specifications * concerns only the gateway agent (not any internal agents) Steps of deployment Steps of deployment The deployment of the FIPA-compliant gateways involves two steps of the FIPA-compliant gateways The creation/configuration: of each of the gateway agents • be aware of the available services • provided by its internal agents - register with AMS, DF • be able to communicate with • its internal agents and vice-versa • translate an ACL message to a form • understood by its internal agent and • vice-versa GatewayAgent API gateway_setup script

10. GatewayAgent API GatewayAgent API

11. The GatewayAgent Library must be imported EXSA is declared as a GatewayAgent i) service-name ii) service-type iii) service’s ontology iv) Internal agent that provides the corresponding service v) Internal agent’s method EXSA is constructed by calling the constructor of the GatewayAgent configure the gateway agent i) the location of FIPA-OS configuration file ii) a unique name for the gateway agent iii) a name for its owner Creation of the Gateway agent Creation of the Gateway agent 1import GatewayAgent.*; 2 ... 3 4 public class EXSA 5 { 6 7 public void initialise() 8 { 9GatewayAgent EXSA; 10 IEXSA_serv exsa_serv=null; 11 12 try // get a proxy for that class 13 { 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"); 24 25 // Setup the Gateway agent 26EXSA=new GatewayAgent("c:/fipaos/profiles/platform.profile",”EXSA”,”SARA”); 27EXSA.addProperty(properties); 28 ... 29 } 30 }

12. do: perform an action i.e. a REQUEST is received undo: cancel a previous action i.e. a CANCEL is received supports agent communication sessions external request translated into the form understood by the Internal agent Request handling by the Gateway agent Request handling by the Gateway agent public String EXSA_URA ( String do_undo, String message, String convID )

13. Advantages and limitations of adopting the FIPA-compliant gateway 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 • 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)  System’s architecture remains the same as before - implementation is only needed for the gateway agent and its interaction with its internal agents that provides a service - the FIPA-compliant gateways does not influence the original architecture of the MAS… • …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  Security is increased - 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 ( i.e. advantage in performance of encrypting only the messages exchanged between the gateway agent and an external agent) - can stand as a firewall restricting agent (communication/migration) instead of ports  Limitation on the kind of systems that need to address FIPA interoperability - 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

14. The FIPA interoperable SARA architecture The FIPA interoperable SARA architecture

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

16. 2 1 node in Manchester University node in Cardiff University 3 Requesting a collection of SARA images Requesting a collection of SARA images An external FIPA agent’s ACL message send to the SARA gateway agent The service’s ontology

17. Screen-shots of tests performed Screen-shots of tests performed

18. Conclusion / summary 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 Future work: Support for mobility between heterogeneous MAS

19. The End The End

20. Java Class Template of a performative Java Class Template of a performative gateway_agent.setPerformative(PROPOSE)

21. Multiple gateway agents Multiple gateway agents • Some developers might need to expose more than one agents to an external MAS… • The introduction of multiple gateway agents with replicated services may also be useful for: • Balancing the incoming requests among • the existing gateways agents • Increasing fault tolerance of the • interoperability part of a legacy MAS

22. Different approaches of standardization Different approaches of standardization KQML • 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) MASIF • 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) FIPA • 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