140 likes | 232 Views
An approach to conforming a MAS to a FIPA-compliant system. Georgousopoulos Christos. Omer F. Rana. http://www.cs.cf.ac.uk/Digital-Library/. What is needed to support interoperability between heterogeneous systems ?. Their design should be based on a common STANDARD.
E N D
An approach to conforming a MAS to a FIPA-compliant system Georgousopoulos Christos Omer F. Rana http://www.cs.cf.ac.uk/Digital-Library/
What is needed to support interoperability between heterogeneous systems ? Their design should be based on a common STANDARD
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
Overview of the FIPA specifications Overview of the FIPA specifications
A different approach of conforming a MAS to a FIPA compliant one A different approach of conforming a MAS to a FIPA compliant one
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
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
Steps in deploying the gateway Steps in deploying the gateway The gateway agent must: The gateway must be FIPA-compliant must adhere to: • be aware of the available services • provided by its internal agents - FIPA Agent management specifications * creation/initialization of AMS, DF agents - register with AMS, DF * setup of MTS (configure the ACC) • be able to communicate with • its internal agents and vice-versa • FIPA Agent communication specifications • translate an ACL message to a form • understood by its internal agent and • vice-versa * concerns only the gateway agent (not any internal agents)
Advantages of adopting the FIPA-compliant gateway Advantages of adopting the FIPA-compliant gateway System’s architecture remains the same as before - Reduction of Code implementation & Testing procedures 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 • Performance is increased - Homogeneous agents can interoperate with themselves
The FIPA interoperable SARA architecture The FIPA interoperable SARA architecture
(of the Web-server) (of the Information-server) The SARA FIPA-compliant gateways The SARA FIPA-compliant gateways
Conclusion – Future work Conclusion – Future work Test & evaluate the interoperability of our system using the AgentCities Support for mobility between heterogeneous MAS
The End The End
An example of an ACL message translation An example of an ACL message translation (request :sender agent_from_EX MAS :receiver EXSA :content (coordinates 50,50,85,75,105,60,150,150) :language PlainText … ) <?xml version=’1.0’> <!DOCTYPE message SYSTEM “message.dtd”> <Message type=”request” id=”CLIENTID”> <Context sender=”//web_server1/EXSA” receiver=”//web_server1/URA”> <Content> <querydef> &trackquery;</querydef> </Content> </Message> where the trackquery contains: <?xml version=’1.0’> <!DOCTYPE trackquery SYSTEM “trackquery.dtd”> <trackquery> <Condition> <and> < MoreThanOrEqual > <left> latitude.upperleft</left> <right>50</right> </ MoreThanOrEqual > < MoreThanOrEqual > <left> longtitude.upperleft</left> <right>50</right> </ MoreThanOrEqual > < MoreThanOrEqual > <left> latitude.upperright</left> <right>85</right> </ MoreThanOrEqual > < LessThanOrEqual > <left> longtitude.upperright</left> <right>75</right> </ LessThanOrEqual > < LessThanOrEqual > <left> latitude.lowerleft</left> <right>105</right> </ LessThanOrEqual > < MoreThanOrEqual > <left> longitude.lowerleft</left> <right>60</right> </ MoreThanOrEqual > < LessThanOrEqual > <left> latitude.lowerright</left> <right>150</right> </ LessThanOrEqual > < LessThanOrEqual > <left> longitude.lowerright</left> <right>150</right> </ LessThanOrEqual > </and> </Condition> </trackquery>