Extending the MASIF Location Service in the MAP Agent System Eleonora Di Pietro, Aurelio La Corte, Orazio Tomarchio
Antonio Puliafito
Istituto di Informatica e Telecomunicazioni - Universit`a di Catania
Dipartimento di Matematica - Universit`a di Messina
Viale A. Doria 6, 95125 Catania - Italy
Salita Sperone, 98166 Messina - Italy
E-mail: fdipietro,lacorte,
[email protected]
E-mail:
[email protected]
Abstract
tems [7, 1, 15, 8, 10, 14], whose architectures and implementations are different because they run on different operating systems, are based on different programming languages and techniques, and implement different and noncompatible functions for the management of agents. However, some basic requirements have been recognized, which any agent platform should have. First of all, any agent platform needs to implement management functions that allow the monitoring of the execution of their agents. Such functions allow the creation of agents, their location within a distributed environment, the suspension and the resuming of their execution, and (if necessary) their early termination. Each platform therefore needs to provide a support to agent mobility; in particular, the remote creation of agents and their migration through the network are needed. Besides, functions supporting the identification in one way of agents and agent systems and their communication must be available in each agent platform. Even if the above mentioned functionalities are present in all mobile agent platforms [11], their implementation can be very different. The differences among these platforms make their interaction difficult (or even impossible), and prevent agent technology to be widely and practically used. In order to solve this problem and favour the interaction among different platforms, the OMG (Object Management Group) has proposed a standard called MASIF (Mobile Agent System Interoperability Facility) [4, 9], whose purpose is to overcome the differences of platforms, by specifying a set of functions and interfaces which all agent platforms need to comply with, so to communicate and interact. In this paper our purpose is the definition of a mechanism that could allow the interaction among the agents running in different regions. In fact, this point has not been dealt with in the present MASIF specifications. Thus, after describing the MASIF standard in Section 2, in Section 3 we present the MAP [14] platform used for our experiments. In Section 4 we present the limitations to MASIF specifications and the proposed solution. The implementation of the system is described in Section 5. Finally, in Section 6 we describe the future development in the work on the MAP agent system.
The recent development in the field of telecommunication networks has enabled the evolution of distributed systems, and has favoured the development of a new generation of applications based on the use of mobile agents. In fact, during the last few years, several agent platforms have been created; however, the architectures and implementation of such platforms are very different, and this makes their interaction difficult. In order to favour the interaction among differently implemented platforms, the OMG has recently proposed the MASIF standard, which includes some definitions and interfaces which all platforms have to comply with. In this paper we present the MAP platform for developing and managing mobile agents; it complies with MASIF, in order to communicate and interact with similar platforms provided that they comply with the mentioned standard. Besides, we present a mechanism, which has been implemented in the MAP, which extends MASIF’s functionalities so to enable the interaction among agents and agent systems operating in different regions. Keywords: mobile agents, MASIF, interoperability, CORBA, location service.
1 Introduction The close interaction between the field of computers and the one of telecommunications has led to a widespread use and a growing evolution of distributed systems. Such growth has led to the need for appropriate methods and tools for programming such systems. RPCs were the first mechanism to program these systems: today we have much more complex object distributed systems represented by the CORBA architecture [16]. The concept of code mobility [5, 6] has recently appeared as a valid tool for developing distributed applications. In particular, the mobile agent paradigm [11, 6] has proven successful in several distributed applications [2, 3, 12]. The research in this field has therefore led to the development of several agent sys1
MAFAgentSystem: supports the management, the transfer and the execution of agents. Each agent platform has to extend this interface, in order to interact with differently implemented platforms and to be able to accept agents coming from them.
2 Interoperability of agent systems: MASIF specifications In order to favour the interaction among differently implemented platforms, the OMG (Object Management Group) has recently proposed the MASIF specification [4, 9]. A set of standard requirements, which all agent platforms need to comply with, is defined within the MASIF. While specifying such requirements, MASIF uses the concepts of agent, agent system, place and region; such terms are currently being used by the majority of the existing agent platforms. According to such specifications, an agent is a program acting independently, on behalf of either a person or an organisation (agent authority). The agent can be either stationary or mobile. During its execution, a stationary agent operates only in the system where it has been created, and communicates (if necessary) with other agents and systems. Conversely, a mobile agent is not linked to the system where it starts running, and can move through the network while it performs the task that it has been assigned. An agent system is a platform that can create, interpret, run, transfer and terminate agents. Like agents, each agent system is associated with a specific authority, which identifies the person or the organisation on behalf of which the agent system operates. Besides, each agent system is associated with a type, which specifies the profile of the agents that the agent system can accept and run. When an agent migrates through the network, it moves within execution environments called places, each representing the context where an agent may run. Each place is associated with a location, consisting of the name of the place and the address of the agent system where the place is resident. An agent system may contain one or more places, within which one or more agents may run. Finally, a region is a logical entity grouping a set of agent systems (not necessarily of the same type) belonging to the same authority. Each region provides a set of functionalities that allow the identification of agents, agent systems and places within the same region, transparently with regard to their current location. In order to allow the interaction among different platforms, MASIF standardizes the following operations:
MAFFinder: enables the registration/deregistration of agents and agent systems, and provides for the methods needed for identifying and locating them. MASIF, in its present form, provides for the functionalities required for the first level of interoperability. This consists of moving agents from an agent system to another. Once the information concerning the agent has been transferred, the way the destination agent system manages such information depends on the implementation of the agent system, and has not been dealt with in the MASIF specification. In fact, it does not standardise some operations for the local management of agents, such as those concerning their interpretation, serialisation/deserialization, and execution. Besides, interfaces are defined at the level of the agent system, rather than being defined at that level of the agent.
3 The MAP agent system MAP1 is a mobile agent platform, which has been created so to provide all the basic tools for the creation and the management of agents, and for their migration and communication [14]. In fact, the platform enables to create, run, suspend, wake up, deactivate and reactivate agents, to stop their execution, and to make them communicate and migrate through the network. Besides, the MAP allows the remote creation of agents, which can be dynamically loaded and run even on hosts where their classes are not present. The MAP is also equipped with a simple graphical interface that facilitates the access to the above mentioned management functions. Further details on the MAP internal architecture and security functionalities it provides are described in previous works [14, 13]. The MAP platform has been made compliant with the MASIF specification; the functions it implements are therefore uniform with the set of interfaces and functionalities defined in the standard. This way, each MAP platform can accept agents coming from different platforms (also complying with MASIF), and can make them run, allowing them to access the methods needed for their management. Besides, the same way, a MAP agent is allowed to migrate to other platforms that can support it, and can run there.
operations for the management of agents; operations for transferring agents; operations for identifying agents, agent systems and places; operations for locating agents, agent system and places.
3.1 Implementation of MASIF in MAP In each host a MAP server object provides the execution environment for agents, and provides all the functionalities
Such functionalities are concretely specified by the MASIF standard, by defining the following interfaces in IDL:
1 MAP is available at http://sun195.iit.unict.it/MAP
2
form of co-operation has been defined among the regions in MASIF, such information can be accessed only within the local region, and not outside. This prevents agents and agent systems to be identified and located outside their region since the information concerning agents and agent systems belonging to other regions cannot be accessed. This is a considerable limitation to their execution, because they are allowed to access only the services available in the region where they are running, while the access to the functionalities provided by remote entities is denied. As a consequence, agents cannot migrate to agent systems belonging to other regions than the one where they have been created. Besides, should we succeed in making an agent migrate to an agent system belonging to a different region, another issue would arise: the original region of the agent, due to its migration, loses all the information concerning the agent; it will therefore have no chance of being located in the region where it was created. This can be a problem, since the agent, while running in a certain region, can contact other local entities in the same region, which might try to locate it even after its migration. For example, the agent might require a local entity (agent or agent system) for the execution of a service, and then migrate before the result of this service is delivered. In this case, the entity that was required for this service will no longer have chance to locate it for sending the information required, because the local region, due to the migration of the agent, lost all the information concerning such agent, and can no longer determine its current location.
needed for their creation, management and communication. It therefore represents the implementation of the agent system concept defined in MASIF. However, in MAP we have only one place for each agent system; this means that each server includes all the functionalities it provides, without subdividing them into smaller logical entities (places). In order to favour the interaction with the different agent platforms, each MAP server implements all the control and management functions of agents provided in the MASIF standard. This way, each server can accept agents coming from different platforms and make them run, thus enabling them to access the functions for their management. According to MASIF, MAP servers are grouped into regions, that is into logical entities including all the servers operating on behalf of the same person or organization. A Registrator object is associated with each region, and deals with the registration/deregistration of MAP servers and agents, as well as with their identification and location in the region. In order to allow the access to MAP entities in accordance with the MASIF standard, all of the MAP servers and the agents running in them (once they have been created), must be registered in the Registrator, before they can run. At the time of registration, each component is assigned a name (that is, a single ID that allows it to be identified anywhere within its region, independently from its current location). The functionalities provided by the Registrator, enable us to locate the agents and the agent systems present in a region and to obtain a reference to them, even if we only know the name they have been assigned and we do not know the address of the host where they are resident. Map Server
Map Server
A different MASIF compliant agent system
MAFAgentSystem
MAFAgentSystem
MAFAgentSystem
In order to solve such problems, a mechanism that allows the interaction between agents and agent systems belonging to different regions has been designed. The mechanism, which has been designed within the MAP platform, has been developed considering the interoperability with the MASIF systems. In fact, the system obtained still respects the MASIF specifications, because the additional functionalities have been developed as an extension of the standard MASIF interfaces. The main issue that we have dealt with concerns the location of agents and agent systems belonging to different regions. First of all, we have introduced (in each agent system) additional functionalities that allow the interaction among agents and/or agent systems belonging to different regions, in case the different entities involved know the physical location of the relevant partners (as well as their name). In fact, in such cases, the MAP servers where the entities involved are running have the information needed for allowing them to communicate and interact, with no need to contact the Registrator. Besides, a generalised location service has been implemented in the MAP; this service allows locating mobile agents even outside their current region.
Communication Channel (ORB)
MAFFinder Region Registration Component MASIF Region
Figure 1. Overview of MASIF architecture
4 Interactions among different regions At the time of the creation of agents and agent systems, MASIF requires that the information concerning them (and needed for locating them) is stored in the region they belong to, in order to identify them easily. However, since no
The designed location service allows locating a mobile agent in any region it has visited while running. This design 3
choice is a compromise between the need for reducing (as much as possible) the additional information to be stored in each MAP Server, and the possibility of locating an agent outside its region. In fact, in an agent application we are likely to need to make agents communicate with each other independently from their location. Conversely, an agent is really unlikely to want to communicate with an agent it does not know, and that has always run in a different region. The designed architecture provides that each region keeps track of all the mobile agents that (after running inside any region) have migrated to a MAP Server belonging to a different region. A communication protocol among regions has been defined; thanks to this protocol, each region can interact with the other ones, in order to determine the current location of migrated agents. Thanks to the mechanism implemented in the MAP, all the regions visited by a mobile agent can communicate, by exchanging information about the current location of the agent, so that it can be located in any region where it has run during its moves. The same way, further functionalities have been added in each agent system (as well as the ones provided by MASIF), so to allow the migration of agents to MAP servers whose location is not known a priori, even if they belong to different regions than the one where the agent comes from. In fact, in such cases, the original MAP server has all the information needed for interacting with the destination server directly, in order to allow the transfer of the agent, with no need to contact the Registrator. The mechanism we described before will allow updating the information maintained by each Registrator in the regions involved by the migration.
The Registrator maintains the information about all the components associated with the region. For this purpose, it stores a data structure containing an entry for each component (agent system or agent) belonging to the region: each entry contains the name assigned to the component and its current location. It must be noticed that the registration and deregistration procedures within the Registrator with regard to MAP servers and static agents (the agents that, once they have been created in a MAP server, run there until their termination) are carried out only once. In fact, static agents are registered only at the time of their creation, and their entry is removed only when their execution ends. Conversely, mobile agents, require a registration/deregistration procedure each time they move. In fact, each time an agent migrates to a new server, it must be deregistered from the original MAP server, and registered on the destination one. Besides, it must be noticed that all registration and deregistration procedures have been carried out automatically, transparently to both the final user of the system and the programmer.
5.1 Interaction among regions The MASIF standard provides that an agent, at the time of its migration, is deregistered from the original agent system and then registered in the destination one. As long as the agent moves within the same region, the Registrator can maintain updated information about the location of the agent, and can therefore locate it within the region. However, if the agent migrates to an agent system belonging to a different region, the Registrator of the original region loses all the information about the agent and its location, and is no longer able to identify and locate it. As described in the previous section, a mechanism for the interaction among regions has been implemented in MAP. Such mechanism allows locating a mobile agent in all the regions it has visited when it has moved. For this reason, each agent maintains a list of all the regions it has visited, and each region keeps track of all the agents that (after running in the region) have migrated to another region. Some additional operations to be carried out at the time of the registration/deregistration of agents are therefore defined, in order to assure the interoperability among regions. Figure 2 shows the sequence of steps to be followed when an agent requests to migrate to a MAP server belonging to a different region than the original one. The figure also allows us describing the mechanism that we have introduced for the interaction among regions. First of all, by observing the figure, we can understand that each Registrator object maintains two separate structures where it stores the local agents and the ones that, after running in a region, have migrated to different regions. As the standard provides, before the agent migrates to the new agent system, the original server deregisters it (1), and the Registrator in the list of
5 Implementation details In this section we provide some details concerning the implementation of MASIF in MAP, so that we can describe the mechanisms implemented for the interactions among different regions. The Registrator object in MAP implements the MAFFinder interface specified by MASIF: all the MAP servers and the agents created within the region must be registered in the MAFFinder interface. At the time of the registration, each component is assigned a name, which is a unique ID that allows its identification anywhere within the region, independently from its current location (transparency to the location). Agents and agent systems are assigned the names at the time of creation, and remain associated with such names until the end of their execution. In compliance with the MASIF standard, each name consists of three fields: authority, identity, and agent system type. In the case of agents, the identity is selected so to contain a reference to the original server MAP and a single ID within the server: this way, we can assure that the name associated with each component is unique. 4
Figure 2. Mechanisms implemented for the interaction among different MASIF regions local agents consequently removes the corresponding entry (2). After the migration (3), the agent is registered again in the destination server (4). However, in this case, the Registrator not only enters a new entry (concerning the agent) in the list of local agents. In fact, it has also to communicate the present region of the agent to the region where the agent comes from, as well as to all the ones (if any) that the agent has visited before. As the figure shows, such information is stored by the Registrator in an entry created in the list of migrated agents. This way, each region always has updated information, which allows us locating the agent even after its migration. Thus, each local entity in any region visited by the agent can contact it, as if it was still running in the same region. The Registrator determines the current location of the agent, by searching for it among the agents registered within the region. If the Registrator cannot find the agent, then it searches among the migrated ones, for which (according to the mechanism implemented in the MAP) has kept track. If the agent is found among the migrated agents, the Registrator directly interacts with the region where the agent is currently running, in order to retrieve the information needed for locating it. Of course, if the agent has never run in the region, the Registrator will find no information concerning it, neither among the agents registered locally, nor among the migrated ones. This aspect is not managed in the MAP; the main purpose to be reached by means of the mechanism for the interaction among regions (which has been implemented in our platform) is enabling the location of a mobile agent within the only regions (and not within all the existing regions) that it has already visited while running.
When an agent ends its execution, its present region deregisters it (as provided by MASIF). However, the mechanism defined in MAP for the communication among the regions provides that all the regions visited by the agent are informed, by means of a similar mechanism as the one we have seen for the migration of the agent from a region to another. Consequently, the entry concerning the agent is removed from the list of the agents that have migrated to all the regions involved, so that the agent can no longer be located in any of them. The functionalities described before have been specified in MAP, in an IDL interface called ExtendedMAFFinder. It is shown below: interface ExtendedMAFFinder:MAFFinder { void add_location_agent( in Name agent_name, in Location region_name) raises(NameInvalid); void update_location_agent( in Name agent_name in Location region_name) raises(EntryNotFound); void remove_location_agent( in Name agent_name) raises(EntryNotFound); Locations register_region_agent( in Name agent_name, in Locations region_names, in Location agent_location, in AgentProfile agent_profile) raises(NameInvalid); void in in in
unregister_region_agent( Name agent_name, Locations region_names, boolean isend) raises(EntryNotFound);
ExtendedMAFFinder get_ExtendedMAFFinder( in Location region_name) raises(FinderNotFound); };
5
In order to assure the interoperability with other MASIF compliant agent platforms, the interface shown above has been derived from the standard MAFFinder interface, in order to contain all the methods already defined in it for the registration/deregistration of agents and agent systems, as well as for their identification and location. Besides, in the ExtendedMAFFinder interface we have introduced additional functions (in comparison with the MAFFinder interface), which implement the described mechanism of interaction among the regions. In particular, methods add location agent, update location agent, and remove location agent allow entering, updating and removing the entry (concerning a migrated agent) in all the regions that the agent has previously visited, while methods register region agent and unregister region agent implement the extended functions of registration/deregistration of agents, according to the modes specified before.
[4] Crystaliz, General Magic, GMD Fokus, and IBM. Mobile Agent System Interoperability Facility. Available through ftp://ftp.omg.org/pub/docs/orbos/97-1005.pdf, November 1997. [5] A. Fuggetta, G.P. Picco, and G. Vigna. Understanding Code Mobility. IEEE Transaction on Software Engineering, 24(5), May 1998. [6] K. Rothermel and R.Popescu-Zeletin Eds.,. Mobile Agents. Lecture Notes in Comp. Science, LNCS1219, 1997. [7] J. Kiniry and D. Simmermann. A hands-on look at Java Mobile Agents. IEEE Internet Computing, 1(4):49–52, July 1997. [8] D.B. Lange and M. Oshima. Programming Mobile Agents in Java with the Java Aglet API. Technical report, IBM Tokyo Research Division, 1997.
6 Conclusions
[9] D. Milojicic, M. Breugst, S. Covaci, and al. MASIF: the OMG Mobile Agent System Interoperability Facility. In Second International Workshop on Mobile Agents, (MA’98), Stuttgart (Germany), September 1998.
In this paper, the MAP agent system has been presented. Our attention has been focused about the issues of interoperability caused by the many agent systems that are nowadays present in literature. The purpose of the MASIF standard is quite overcoming the implementation differences of the various systems, by defining some common interfaces that such systems will need to implement for interacting with each other. An extension of such interfaces has been proposed, in order to allow the interaction among agents and agent systems belonging to different regions. In fact, this is a point that has not adequately been dealt with by the current MASIF specifications. After describing the designed mechanism, we have focused our attention about the implementation aspects of the system, which has been created by using the MAP agent platform. Acknowledgements: This work has been partially supported by the European Community through the VESPER project (#IST-1999-10825) under the IST programme.
[10] ObjectSpace. Voyager Core Technology. http://www.objectspace.com/voyager, 1997. [11] V. A. Phan and A. Karmouch. Mobile Software Agents: An Overview. IEEE Communication Magazine, 31(7):26–37, July 1998. [12] A. Puliafito and O. Tomarchio. Advanced Network Management Functionalities through the use of Mobile Software Agents. In 3rd International Workshop on Intelligent Agents for Telecommunication Applications (IATA’99), Stockholm (Sweden), August 1999. [13] A. Puliafito and O. Tomarchio. Security mechanisms for the MAP agent system. In 8th Euromicro Workshop on Parallel and Distributed Processing (PDP2000), Rhodos (Greece), January 2000.
References [1] M. Breugst, I. Busse, S. Covaci, and T. Magedanz. Grasshopper - A Mobile Agent Platform for IN Based Service Environments. In IEEE IN Workshop 1998, Bordeaux (France), May 1998.
[14] A. Puliafito, O. Tomarchio, and L. Vita. MAP: Design and Implementation of a Mobile Agent Platform. Journal of System Architecture, 46(2):145–162, 2000.
[2] M. Breugst and T. Magedanz. Mobile Agents - Enabling Technology for Active Intelligent Network Implementation. IEEE Network, 12(3):53–60, May/June 1998.
[15] M. Strasser, J. Baumann, and F. Hohl. MOLE - A Java Based Mobile Agent System. In Proceedings of the 2nd ECOOP Workshop on Mobile Object Systems, July 1996.
[3] D.M. Chess, C.G. Harrison, and A. Kershenbaum. Mobile Agents: Are they a Good Idea? Technical Report RC19887, IBM T.J. Watson Research Center, March 1995.
[16] R. Zahavi T.J. Mowbray. The essential CORBA: Systems Integration Using Distributed Objects. John Wiley & Sons, Inc., 1995.
6
