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

Screen-shots of tests performedScreen-shots of tests performed

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

The EndThe 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 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