Mobile Agent Interoperability Revisited
Volker Roth , Ulrich Pinsdorf , and Walter Binder
Fraunhofer Institut f¨ur Graphische Datenverarbeitung Rundeturmstraße 6, 64283 Darmstadt, Germany {vroth|ulrich.pinsdorf}@igd.fhg.de
CoCo Software Engineering GmbH Margaretenstraße 22/9, A-1040 Wien, Austria
[email protected]
A major setback for mobile agent technology is – apart from a frequently cited absence of appropriate security mechanisms – a lack of interoperability between systems for mobile agents, which prevents mobile agents from reaching “critical mass” for widespread application. Interoperability is required where systems of different vendors come into contact with each other. More precisely, two mobile agent systems are interoperable if a mobile agent of one system can migrate to the second system, the agent can interact and communicate with other agents on this system (or even remote agents), the agent can leave this system, and it can resume its execution on the next interoperable system. At the time of writing, we are aware of only one attempt to provide means of interoperability among systems of mobile agents, which is the dated MASIF proposal [1]. FIPA is also active in the standardization of agent mobility1 issues, but this particular thread of FIPA’s work focuses on a high level of abstraction, and, to the best of our knowledge, the document did not have much public scrutiny yet. It is therefore fair to say that these existing standardization efforts have not yet shown to be effective to provide actual interoperability among systems for mobile agents with regard to our definition. Rather than following the top down approach to interoperability by means of standards, we chose to take a bottom up approach based on voluntary and practical interoperability with other systems for mobile agents. In this vein, a working group was established in the Special Interest Group on Intelligent and Mobile Agents, which is part of AgentLink,2 Europe’s Network of Excellence for Agent-Based Computing. Current members of this working group are CoCo Software Engineering GmbH, Austria, Fraunhofer Institute for Computer Graphics, IKV++, and University of Jena, Germany. The short-term goals of this working group are threefold: 1 2
FIPA document PC00087A, available at URL http://www.fipa.org http://www.agentlink.org
1. The exploration and demonstration of practical interoperability within a distributed mobile agent testbed of multiple heterogeneous agencies. 2. The design of harmonized interfaces for the purpose of mobile agent invocation, migration target specification, and actuation of migration. 3. The design of patterns that facilitate adaption of mobile agents of heterogeneous agent systems in a given system. The expected outcome is a working interoperability layer for the mobile agent systems enago Mobile, J-SEAL2, SeMoA, and Tracy that can serve as a role model for the integration of heterogeneous systems. The long-term goals include the design of a unified and open architecture that allows to plug in modules that represent the individual strengths of the working group members, as well as non-affiliated contributions. From a layering perspective, we target a micro-kernel architecture that allows to insert e.g., layers between the JVM and the agent system that improve the security of the JVM against malicious code. Current achievements include the design of an abstraction layer for SeMoA3 that we call a Lifecycle pattern, and that is closely related to the Factory pattern [2]. This pattern has been applied successfully to the Jade [3] and Tracy [4] systems, whose agents run seamlessly in SeMoA and may benefit transparently from the mobility and security features provided by SeMoA [5]. We chose these platforms because each stands for a major topic in mobile agent interoperability. Jade is known for its focus on FIPA compliant agent communication, Tracy concentrates on efficient migration. Instances of the Lifecycle pattern provide agents a view on SeMoA that mimicks the view they have on their native system. More precisely, lifecycle instances fullfill two tasks. First, they translate between the native SeMoA lifecycle and the lifecycle of the emulated system. Second, they act as hooks into the acme4 Agent setup routines, called e.g. after migration, typically involve an initialization of the agent with an interface class which provides access to the agent system. Agents wrapped by a specific lifecycle can use their native API for communication, migration, and interaction with the system without recompilation of their code. Furthermore, the lifecycle pattern provides the possibility to observe and control the agent’s access to system information according to the security policy of the hosting system – in our case the SeMoA system. Adaption of agent communication has two specific problems: enabling the lifecycle to access the acme communication infrastructure and the correct adressing of peer agents. The adaption of acme communication interfaces turned 3 4
http://www.semoa.org For simplicity, we speak of the acme system whenever we refer to a system other than our own system, e.g. Jade or Tracy agent system.
out to be easier as expected. For the Jade system, which communicates by means of the IIOP protocol [6], we built a message service which acts as IIOP stub and is globally accessible for Jade lifecycles. Outgoing messages will be hand over from the lifecycle to the message service which simply drops them into the IIOP channel. The other way around, incoming messages will be dispatched to the particular lifecycle of the receiver agent. The adaption for Tracy’s communication infrastructure was quite similiar. Tracy uses the meeting metapher for communication and posts messages on a system global blackboard. We wrapped a blackboard instance in a globally accessible service which will be used by all Tracy lifecycles on the host. The adaption of various communication channels has the drawback that we run multiple communication channels concurrently. We hope to address this problem in the future with a concept for interoperable integration of multiple communication infrastructures. The correct addressing of peer agents is less troublesome for acme agents that are created on a SeMoA server. Many agent systems use naming schemes based on the Uniform Resource Locator [7] syntax, for instance something like
[email protected]:40000/strangeplace, where “wombat” is a name that can be chosen freely by the agent’s creator. However, SeMoA allows no free choice of an agent’s name, instead an agent’s name is computed implictly5 from a digital signature of its static part (see [9] for reference). If the agent is created on the SeMoA server, and its implicit name is computed as f42a1cc0 then the agent can be given the name
[email protected]: 40000/strangeplace in order to match acme’s syntax. A suitable mapping mechanism must be used by the lifecycle implementation in order to translate back and forth between these names as required. Our experience up to the time of writing shows that agent communication is less of a problem when compared to agent migration, though. Migration is often more tightly interwoven in a system’s design and implementation. For instance, SeMoA’s security policy requires that migration is initiated only after all threads of the migrating agent have terminated, Tracy agents for instance have to throw a particular exception at any time during their execution in order to initiate migration. Nevertheless migration was realised for Tracy agents;6 they are able to migrate back and forth between SeMoA servers. The next step is to implement a gateway which allows interoperability with the transport protocol of Tracy and therefore migration to and from a native Tracy system, too. 5
6
Implicit names consist of SHA-1 [8] digests, hence are 20 bytes long. For ease of reading, we give only 8 hexadecimal nibbles rather than the whole 40. Jade is not of interest in respect of migration, because it only allows migration between containers located on the same host.
The lessons we learned so far fall into two broad categories. First, we gained insight into design patterns that help to build agent systems in a way that facilitates provision of interoperability. Second, we gained insight in designs that inhibit provision of interoperability. We concentrate on agent setup, lifecycle, and system interfaces.
Acknowledgements We thank Peter Braun and Jan Eismann from the University of Jena, Germany, for kindly providing access to the source code of Tracy.
References 1. D. Milojicic, M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman, K. Kosaka, D. Lange, K. Omo, M. Oshima, C. Tham, S. Virdhagriswaran, and J. White, “MASIF – The OMG Mobile Agent System Interoperability Facility,” in Proceedings of the Second International Workshop on Mobile Agents (MA ’98) (K. Rothermel and F. Hohl, eds.), vol. 1477 of Lecture Notes in Computer Science, pp. 50–67, Berlin Heidelberg: Springer Verlag, September 1998. The MASIF specification is available from URL: http://www.fokus.gmd.de/ research/cc/ecco/masif/doc/97- 10-05.pdf. 2. E. Gamma, R. Helm, R. Johnson, and J. Vissides, Design Patterns. Addison Wesley Longman Publishing Co., December 1994. ISBN 0201633612. 3. F. Bellifemine, A. Poggi, and G. Rimassa, “Jade programmers guide,” June 2000. available from http://sharon.cselt.it/projects/jade. 4. P. Braun, C. Erfurth, and W. R. Rossak, “An introduction to the Tracy mobile agent system,” Technical Report No. 2000/24, Friedrich Schiller University of Jena, Computer Science Department, September 2000. available from ftp://ftp.minet.uni-jena.de/ips/ braun/bericht-00-24.pdf. 5. V. Roth and M. Jalali, “Concepts and architecture of a security-centric mobile agent server,” in Proc. Fifth International Symposium on Autonomous Decentralized Systems (ISADS 2001), (Dallas, Texas, U.S.A.), pp. 435–442, IEEE Computer Society, March 2001. ISBN 0-76951065-5. 6. “CORBA 2.2 specification,” Tech. Rep. formal/98-07-01, Object Management Group, 1998. available from http://www.omg.org. 7. T. Berners-Lee, L. Masinter, and M. McCahill, “Uniform Resource Locators (URL),” Request for Comments 1738, Internet Engineering Task Force, December 1994. 8. FIPS180–1, “Secure Hash Standard,” Federal Information Processing Standards Publication 180–1, U.S. Department of Commerce/National Bureau of Standards, National Technical Information Service, Springfield, Virginia, April 1995. supersedes FIPS 180:1993. 9. V. Roth, “Scalable and secure global name services for mobile agents.” 6th ECOOP Workshop on Mobile Object Systems: Operating System Support, Security and Programming Languages (Cannes, France, June 2000).
