Claudia Raibulet and Claudio Demartini
Dipartimento di Automatica e Informatica, Politecnico di Torino,
Corso Duca degli Abruzzi 24, 10129 Torino, Italy
Phone: +39-011-564 70 85
Fax: +39-011-564 70 99
E-mail: firstname.lastname@example.org, email@example.com
|Abstract: Mobile agent technology has become an alternative approach for the design of distributed systems to the traditional client-server and message-based architectures. The main difference between the two technologies is the key solution they provide for the distribution problems: local interaction and mobile logic versus location transparency. An important example of their application, where the advantages of mobile agent technology are exploited best, is the management of distributed systems. This paper presents an implementation example of the mobile agents used to access and to manage information stored in the Distributed Database Repository (DDR), as specified within the ESPRIT Project “Network Oriented Application Harmonization” (NOAH).|
|Key words: mobile agents, distributed systems, information repository, system technical management.|
1. IntroductionThe increasing development of distributed systems requires more and more efficient technologies to ensure the access and the management of the network resources. Features such as efficiency, flexibility, velocity, security should be related to all the operations performed within distributed systems.
In this context, mobile agent technology is considered an enhancement of distributed technologies as it provides powerful and efficient mechanisms to develop applications for distributed and heterogeneous systems. To deal with the increasing amount of data/resources available nowadays, and the large number of tasks which have to be performed to manipulate the data/resources, mobile agent technology offers the possibility of executing these tasks in an automated way, with minimal human intervention. This allows the user to concentrate attention on other activities. The solution proposed by mobile agent technology for the distribution problem includes basic functions such as creation, migration, execution of the mobile agents, as well as specialized functions that involve agent security and management.
Mobile agent technology has become popular primarily because of the efficient way it provides for the access and the manipulation of remote information. It is based on a different approach for the design of distributed systems [10, 12]. The traditional client-server and the message-based architectures treat local and remote resources in the same way, in that they use location transparency. From the user’s point of view all information is stored locally. In contrast to the traditional technologies, the mobile agent architecture considers that local interaction is more efficient than the remote one. The solution proposed by mobile agents is for software to migrate to remote hosts, where information is stored, so that the user’s request can be executed . It means that agents can take decisions or fulfill previously designed operations in an autonomous way on the remote site, even if the home host becomes temporary unavailable. This feature, called mobile logic, gives flexibility to the design of distributed systems.
Local interaction and mobile logic also lead to the achievement of load balancing in the whole distributed system. The agents move from host to host to execute the user’s requests and return the result to the host where they were created. They act autonomously according to the mobile logic they incorporate.
The applications which are best suited to mobile agent technology are electronic commerce , telecommunication , information retrieval, and management of distributed resources [2, 4], etc. Usually, they are characterized by asynchronous transactions, low bandwidth, high latency, remote information retrieval, multi-processing, or distributed task processing features.
This paper describes an example of the application of mobile agents used to access and to manage information related to an industrial system. The DDR model  represents a distributed information repository designed to ensure a common view of the system for any application. The immediate advantage of the DDR model is a unified perspective for several activities that concern the distributed resources of the industrial system (e.g., installation, maintenance and technical management). The specification of the DDR model has been one of the goals of the ESPRIT Project named “Network Oriented Application Harmonization” (NOAH).
The DDR has been implemented as an object-oriented database in the Java environment. As support for the mobile agents’ implementation, the Voyager platform [8, 9], developed by the ObjectSpace, Inc has been chosen.
The remainder of this paper is organized as follows. Section 2 contains general considerations about mobile agent technology. Section 3 contains a description of the DDR architecture. Section 4 discusses the reasons that led to the usage of mobile agent technology to access and to manage DDR distributed information. Section 5 presents aspects related to the implementation approach. The conclusions and the further work are dealt with in section 6.
2. Mobile Agent Technology - General ConsiderationsAn agent is defined as a self-contained software element that acts autonomously on behalf of a user (e.g., person or organization) [6, 12]. Each agent has its own thread of execution which means that it can perform tasks on its own initiative. A mobile agent has, in addition, the unique ability to migrate from one host in a network to another [6, 12].
The definition of a mobile agent contains at least two key words that raise important issues which have to be considered when developing mobile agent systems.
The first key word refers to the autonomy of a mobile agent. This is a feature that allows the agent to act on its own by using the data and the mobile logic which it incorporates, and does not need human intervention or guidance. The user can perform other activities in the meantime. Further, the time needed to fulfill the tasks is reduced because interaction with the user is avoided. The agent is designed to deal with any situation that may occur during execution. There are however cases when the lack of human supervision may lead to unexpected and undesired actions, such as the violation of the private information associated to the agent’s owner . The relation agent-owner should be based on trust because the agent has access to information stored in the user’s profile, information that may be private. Due to the fact that an agent can collect, manipulate, and distribute data, including user’s personal data, it is possible that there is a violation of privacy when the agent communicates and/or exchanges data with its environment and/or agents belonging to different systems. In order to defend the user's privacy, Privacy-Enhancing Technologies (PETs) (e.g., Identity Protector)  should be added or integrated in mobile agent systems.
The second key word in the definition refers to the mobility of an agent. The mobility feature enables the agent to travel to the host where the data is physically stored. In this way the transfer of a large amount of data in the network is prevented. The agent accesses the data locally and so provides only the results to the user. There are at least two advantages to this approach: low traffic in the network and a better use of network resources. The migration of an agent within the network should respect rules concerning the agent transport, agent interaction and security, otherwise it is not possible to ensure interoperability among mobile agents which belong to different vendors’ systems.
The security issue has always been considered to be the weak point of mobile agent technology. The security problem regards the security of the host that may receive a potentially malicious agent, as well as the security of the agent that should be protected from potentially malicious hosts. Closely related to this aspect, is legal responsibility which concerns authentication of mobile agents, secrecy, privacy, data quality, and many other similar aspects. Questions such as: “Is the agent really what it pretends to be?” or “Has it the right to access this kind of data?” should have a clear response because otherwise the host will not know how to react to the agents’ requests.
3. The DDR Model
3.1 ScopeThe main goal of the DDR is to provide a general information model that can describe any distributed system during the different stages of its life cycle. The DDR specification unifies the actual representation of the devices within complex systems, enabling heterogeneous devices and their links to be described according to a common approach, regardless of their specific implementation. The advantage of this approach is that the model provides a common view for the installation, the maintenance, and the management of distributed resources in the system.
STEP/ISO 10303 AP 212 [14, 15] has been chosen for the specification of the DDR model because it includes all the concepts necessary to describe a plant (e.g., devices, interfaces, networks, functions, variables, etc). The objective of the AP 212 is to specify the tasks of the operation activities of each plant and the relationships among them. It analyses the data used by individual activities and/or shared by several activities. Based on the previous affirmations, attention is directed to the abstraction of generic activities and data structures that provide the basis on which efficient activity models and data models can be built up. The AP 212 is used not only to create data models to represent and to exchange data, but also to build distributed data repositories.
3.2 The DDR ArchitectureWithin the DDR model architecture, four distinct components are identified:
Figure 1. The Architecture of the DDR Model
The DDR System Manager contains general information related to the whole
distributed system, such as a complete directory of the system resources
or the network wide topology information. The detailed information associated
to each plant is stored locally in the DDR Databases and the MIBs. This
repartition of the information has at least two advantages. The first is
that the System Manager does not have to store a huge amount of information
that can over time get proportionally bigger together with the development
of the distributed system. The second refers to the velocity of the updates
or changes of the information that may be carried out over time for the
4. Mobile Agents for the Management of the DDR InformationTwo main categories of management operations have been identified among the user requirements: the read management operations and the set management operations. The first category includes device identification, check of the parameter values, and the monitoring of the device status, while the second refers to the set or modification of device parameters, and the set of functional configuration for the devices.
4.1 Three Types of Queries for the Management of the DDRThis subsection discusses three examples of queries used for the management of DDR information:
1. List all the type T devices of the industrial plant that have parameter X set on the Y value.
This type of query implies every plant of the system that has at least
one device of type T connected in the local network to be interrogated.
A query has to be sent to each plant in order to read parameter X for the
type T devices, and to check its value.
2. Monitor the value of parameter X belonging to the Y device every N seconds. Do operation Z and notify the DDR System Manager if the value is out of a certain range.
Such a query implies reading the parameter value in a local MIB, which
is associated to the above mentioned device, and the validation of this
3. A new resource X has been added to the industrial plant. Update the related information in the DDR Database and the DDR System Manager.
As mentioned before, the DDR System Manager stores information related
to the entire industrial plant, such as the network topology related data.
When adding a new resource in the network, the DDR System Manager and the
DDR Database data should be updated.
4.2 Four Reasons to Use Mobile Agents for the Management of Distributed InformationFrom the discussion presented above it results that, there is nothing in the management queries that cannot be solved by the client-server and the message-based architectures. Although, it results that in the case of the management of distributed resources, mobile agent technology provides a more efficient solution then the client-server based approach. This is due to the way in which distribution problems are treated. Traditional technologies achieve communication among distributed resources by using location transparency, while mobile agents provide local interaction for communication and mobile logic facilities. The mobile agents migrate on remote hosts and perform different operations according to the mobile logic they incorporate. They use local interaction to access the distributed information because they move to where the data is stored.
Four important reasons that sustain the use of mobile agents for the management of distributed resources can be identified from the previous subsection:
5. Implementation of the Mobile Agents Using the Voyager PlatformThe implementation of the mobile agents must be supported by a platform that provides the mechanisms and the functionality necessary for their proper creation and execution in distributed environments. In November 1997, the Object Management Group (OMG)  specified within its first mobile agent standard named Mobile Agent System Interoperability Facilities (MASIF) , the requirements that have to be supplied by any mobile agent platform. These requirements are related to the support for execution, management, mobility, security, communication, transaction, and unique identification of agents. Among the available platforms for the implementation of mobile agents, Voyager (ObjectSpace, Inc) , Aglets Workbench (IBM) , Grasshopper (IKV++) , and Telescript (General Magic)  can be mentioned.
The Voyager platform has been chosen for the implementation of the DDR. Based on the most common available industry standards, its scope is to unify and to simplify the development of distributed applications. Voyager is a pure Java distributed platform that provides a complex and competitive state-of-the-art Object Request Broker (ORB)  in order to support the implementation of distributed applications. The list of the ORB features includes dynamic class loading, remote construction, distributed garbage collection, dynamic aggregation, mobility, autonomous mobile agents, and many others.
5.1 Mobile Agents in the DDR ModelIn the DDR model, all the computers connected in the system must have the Java Development Kit and the Voyager platform installed in order to support the creation, migration, execution, and destruction of the mobile agents. Usually, the agents are created by the DDR System Manager on receiving user’s requests. The agents are sent to perform the queries and to provide the results to the System Manager that will forward them to the user. Mobile agents are also created within the local plants when a new resource is added. This kind of agents is designed to add the information related to the new resource in the local DDR Database and in the DDR System Manager. The mobile logic of an agent contains the information necessary for its migration, execution, and destruction.
5.2 Creating a Mobile AgentWithin the Voyager platform, a mobile agent is defined as a common, simple class that implements the Serializable interface. An object of this class becomes a mobile agent at runtime when a secondary object, named agent facet, is attached to it. The agent facet enables the primary object to use the methods defined within the IAgent interface and to exploit the mobility facility provided by the Voyager platform. The aggregate object is then treated as a single unit. The facility of adding new code and data to an object at runtime is called dynamic aggregation and it is considered to be an important enhancement for the object modeling that complements the inheritance and polymorphism mechanisms.
5.3 Moving a Mobile AgentThe IAgent interface provides a moveTo method that implements the support for the migration of the mobile agents. This method has three parameters: the location to which the agent will move, the name of a method implemented by the agent that will be executed when the agent reaches the new location, and the parameters for the agent method, if any. If the agent has to migrate to another location after finishing its mission on a host, the last instruction executed on the present location will contain the moveTo method.
5.4 Executing a Mobile AgentOn reaching a new host, the mobile agent starts its execution with the method specified as parameter in the moveTo instruction. The agent continues its execution in order to perform the query for which it has been designed, and in order to obtain the requested results.
5.5 Destroying a Mobile AgentBy default, the mobile agents created within the Voyager platform are autonomous. This means that a mobile agent cannot be garbage collected even if there are no more local or remote references to it. The IAgent interface provides a method called setAutonomous that sets the autonomy of an agent to true or false. Usually, after achieving its goal, the mobile agent sets its autonomy to false in order to specify that it has finished its job and it can be garbage collected.
6. Conclusions and Further WorkThis paper has presented a case study of mobile agents’ usage for the management of the DDR distributed resources. The DDR model validation has been demonstrated with an example of an actual system: a Temperature Loop in the IAM-Pilot laboratory at ENEL in Milan .
Mobile agent technology should be seen as an alternative approach to the client-server traditional architectures, not as a universal solution for distributed systems. In the case of the management of distributed resources, a comparison between a client-server solution and a mobile agent based approach shows that mobile agent technology offers important advantages, such as flexibility and scalability of the system, load balancing, on-demand services, low traffic in the network, and many others. These advantages are due to the way in which mobile agents treat distribution problems by using local interaction and mobile logic.
The mobile agents require a proper and secure environment for their implementation and execution. For the implementation of the mobile agents, the Java environment and the Voyager platform have been chosen. Java is considered the de facto standard for the mobile agents, while Voyager provides a complex platform that supports the development of distributed applications and the implementation of the mobile agents is implicit.
Further work will be related to the security of the mobile agents and of the hosts that receive them in public networks. The mobile agents should be protected against potentially malicious hosts. The hosts should also be protected against malicious actions that may be performed by the mobile code they receive and execute.
VitaeClaudia Raibulet received the M.S. degree in Computer Science from “Politehnica” University of Bucharest, Romania, in July, 1997. Currently, she is a PhD student in Computer and Systems Engineering at Politecnico di Torino, in Turin, Italy. Her research activities concern software engineering, distributed systems, mobile computing, distributed databases, and object-oriented methodologies. She is currently involved in the ESPRIT Project “Network Oriented Application Harmonization”.
Claudio Demartini received the M.S. degree in Electronic Engineering
from Politecnico di Torino, Italy, in 1980. From 1984 to 1986 he attended
the PhD course in Computer and System Engineering at “Politecnico di Torino”
getting his degree in 1987. He is currently Professor at the “Politecnico
di Torino”. His research activities concern distributed systems, local
area networks, communication protocols, fieldbus networks, and product
data technology. Claudio Demartini authored several technical papers and
co-authored a book on computer networks.