Implementing Mobile Agent Design Patterns in the JADE framework

Authors Emerson Ferreira de Araújo Lima

Graduated in the Federal University of Alagoas, Brazil Mastering in the Federal University of Campina Grande, Brazil

Patrícia Duarte de Lima Machado

PhD in Computer Science. University of Edinburgh, Edinburgh, Scotland Jorge César Abrantes de Figueiredo

Pos-Doctor. Aarhus Universitet, Aarhus C, Denmark

Flávio Ronison Sampaio Graduating in the Federal University of Campina Grande, Brazil

Abstract Mobile Agents are programs that can migrate between different hosts in an

autonomous way, continuing their execution from the point where they stopped before the migration. An approach that can simplify and improve the development of applications based on Mobile Agents are the use of Design Patterns – ideas of solutions for a given problem inside some context. However, despite their potentiality, they have seldom been used in the development of applications based on Mobile Agents. This is perhaps due to the lack of information on mobile agent patterns or how complicated it would be to implement them in a given platform. In this work, we present the implementation of Design Patterns in the JADE framework, showing the experience and results obtained. We expect to stimulate the use of these patterns, showing how they can be implemented and raising interest on the advantages that they can bring.

1. Introduction Mobile agents are autonomous computer programs that can act in the interest of

an entity, migrating between different network locations, executing tasks locally and continuing their execution at the point where they stopped before migration [4]. Mobile agents can also have features like intelligence and ability to cooperate.

The use of mobile agents can bring several advantages to applications and their users: (1) reducing network traffic, as interactions can be carried out locally, independently of network latency; (2) asynchronous and decentralised execution,

allowing the user to disconnect from the network when agents are performing a task; (3) ability to detect changes in the execution environment and react autonomously, simplifying the development of distributing systems that are more robust and fault tolerant. One may argue that these advantages can be obtained when using other paradigms. However, despite this, the great advantage of mobile agents is to combine these advantages in single and more abstract paradigm [7].

A disadvantage of mobile agents is the need to install a support agent platform at each host the agents need to visit. Also, in these platforms, agents code is usually interpreted. This can impact considerably on the performance of systems. In this sense, it is recommended to avoid moving agents unnecessarily, since this can increase network traffic. Besides, agents code and data must be as short as possible if we want to achieve the benefits of the technology . An agent functionality can be factored in a way it carries exactly what is needed. Information that is not going to be used or can be easily recovered can be discarded. Furthermore, it is important to mention security. This is a hard problem that is faced by all technologies of developing distributed systems [3],[19]. The more secure, the lower the performance of the system is.

[16]

The use of design patterns is an approach to improve the development process of applications and the quality of the final products. Some mobile agent design patterns have already been proposed [1],[11]. However, most of these patterns have not been concretely implemented yet. In addition, there is not enough concrete information on how they can be implemented and on whether they are technically feasible when considering a specific agent platform.

In this paper, we present an experience on implementing mobile agent design patterns in the JADE platform1, showing that they are feasible. We aim at stimulating their use when developing applications based on this technology. In order to choose the agent platform to conduct our experiment, we have used the following criteria: (1) the platform has to be distributed free of charge and expiration date and in its complete form; (2) the platform must have compatible versions that run in different operational systems, like Unix and Windows and their variations for portable devices; (3) the programming language supported must be JAVA, an object oriented language that is portable, running in different operating systems and having versions dedicated to minimum hardware configurations; and (4) support for users such as documentation, forums and discussion lists as well as a list of reported problems. JADE meets all of these criteria. In addition, the platform is integrated with the LEAP project2, which offers support for portable devices, and it is open source. Also, the platform has detailed documentation for programmers and administrators and an active discussion list.

In the sequel, Section 2 introduces design pattern concepts and motivation for their use. The mobile agent design patterns considered in this paper are briefly described. Section 3 presents our experience on implementing the patterns in the JADE framework. Finally, concluding remarks are presented in Section 4.

1 http://jade.cselt.it 2 http://leap.crm-paris.com/

2. Mobile Agents Design Patterns Although mobile agents technology has been successfully applied in different

case studies ([2],[12],[5] and [8]), its application in practical scenarios is still restricted. The well-known methodologies and notations employed in the development of object oriented applications do not properly address mobility issues. In some notations, as for example in the AUML3 notation, mobility is considered only at the deployment diagrams level.

To cope with this limitation, in the last decade, many projects were conducted in

order to incorporate mobility aspects into traditional methodologies. In [18], it is proposed a method to be applied in the design phase. In [12], UML diagrams extensions are proposed to incorporate mobility. In [6], a modified software development process based on the process defined by Larman [15] is presented. This modified process allows the representation of mobility in the analysis and design phases.

A different approach to increase the usage of mobile agents in real applications is

the definition of design patterns. The basic idea of design patterns is to define general solution models for common problems found in a given context. In fact, some problems can be faced many times during different phases of the development process. It would be worthwhile if good solutions for these problems could be reused instead of the necessity to develop a new one from scratch. Design patterns make easier the development of applications, increasing flexibility and promoting reuse.

Design patterns for different problems on mobile agents have been proposed in

and . Despite the importance of these patterns, they have been not largely used in practice. The lack of a systematic approach in the definition of those patterns, as well as the inexistence of adequate studies about their implementation in real platforms have contributed to this scenario. The purpose of this work is to implement a group of design patterns for mobile agents in the JADE framework. As a result of these implementations, we expect to improve our understanding on the solutions defined by the patterns, as well as to verify the feasibility in implementing them.

[18] [1]

In the following paragraphs, we describe the design patterns we considered for

implementation. Itinerary This pattern, proposed in [18], provides a way to execute the migration of an

agent, which will be responsible for executing a given task in remote hosts. The agent receives an itinerary on the source agency, indicating the sequence of agencies it should visit. Once in an agency, the agent executes its task locally and then continues on its itinerary. After visiting the last agency, the agent go back to its source agency. Figure 1 illustrates this pattern.

3 http://www.auml.org

Figure 1 - Itinerary Pattern

Star-Shaped On the Star-Shaped pattern[18], the agent receives a list of agencies that it has to

migrate to. So, it migrates to the first destination agency, where it executes a task, going back to the source agency. The agent repeats this cycle until visit the last agency on its list. Figure 2 shows this pattern.

Figure 2 - Star-Shaped Pattern

Branching On the Branching pattern [18], the agent receives a list of agencies to visit and

clones itself according to the numbers of agencies in the itinerary. Then, all clones will visit an agency of the received list. Each clone has to execute its corresponding task and

notify the source agency when the task is completed. The importance of this pattern is that it splits the tasks that can be executed in parallel. The treatment of the final results is an issue not covered by this pattern. For instance, the clones can put the result of the task in a user interface or send it to another agent. This pattern is shown at Figure 3.

Figure 3 - Branching Pattern

Master-Slave On the Master-Slave pattern [13], a master agent delegates a task to be done on a

given agency to a slave agent, in order continue executing other tasks that cannot be interrupted. The slave agent visits the indicated agency, where it accomplishes the task and then returns to the source agency with the results. The master agent receives the results from the slave agent. Then, the slave one destroys itself.

MoProxy On this pattern, proposed in [17], when an agent needs a resource, it requests to

the Resource Granter, indicating the desired permissions. Then, the resource granter returns a mobile proxy for the agent in order to access the resource with the desired permissions depending on the restrictions of the resource.

Meeting The Meeting pattern [13] suggests a way to promote local interactions between

agents distributed on the net. Such interactions make possible the execution of given tasks, as well as the optimization of results. Then, the MeetingAgent, who will meet others, has a Meeting object that keeps the place and the identification of the meeting. In this way, the MeetingAgent requests the Meeting object the place of the meeting and then migrates to it. A MeetingManager, which is an entity that manages the meeting, is responsible for notifying the agents located in the meeting place about the arrivals and exits of new ones. The Meeting object is responsible for intermediating the register of the agent on the manager.

Facilitator The Facilitator pattern defines a service that provides a name service and

localization of agents with specific abilities, thus facilitating the localization of a given agent.

[13]

Mutual Itinerary Recording This pattern ( ) is a general schema that guarantees the itinerary of a given

agent will be registered and tracked by other cooperative agent and vice-versa, in a disposal of mutual support. When an agent is moving between platforms, it carries the information from the last platform, the current and the next ones to the cooperative agent through an authenticated channel. The agent keeps the register of the itinerary and it always compares the itinerary that it possesses with the received one. When an inconsistence is detected it should be treated. For instance, it would either disallow the agent to visit the platform that caused the inconsistency, or suspend the functioning of an agent, or send the agent back to the source agency.

[10]

3. Design Patterns Implementation In this section, we present the implementation of the design patterns described

previously. For each of them, we explain the functioning in JADE, emphasizing the classes we implemented and the JADE framework classes and concepts used.

Itinerary In our implementation, we defined an ItineraryAgent, whose type is Agent. This

agent initially adds the behaviour Itinerarybehaviour, whose type is OneShotBehaviour, that sets the itinerary the agent must follow, and then, it starts the migration. The agent execution is controlled by the methods beforeMove and afterMove, that controls the migration and allows the execution of the job, respectively. The agent job is implemented in JobBehaviour (of type OneShotBehahvour) class, added to the agent whenever he arrives to the new destination. An important detail: before migrating, the agent verifies, through AMS4, if the destination container exists. If it does not, it tries to migrate to the next destination in its itinerary. This verification is made by the behaviour GetAvailableLocationBehaviour, that is available in the example codes provided by the framework.

Star-Shaped In this implementation, we defined a StarShapedAgent, of type Agent, that adds

the SetItineraryBehaviour behaviour, identical to the explained in previous pattern. The functioning of this agent is similar to the ItineraryAgent, being controlled by the methods beforeMove and afterMove, having the JobBehaviour implementing the task and the class GetAvailableLocationsBehaviour responsible for verifying the availability of the destination container.

4 AMS – Agent Management System

Branching In this pattern, we implemented a BranchingAgent, of type Agent, that adds the

SetItineraryBehaviour, identical to the explained in the Itinerary pattern. Before initiating the migration, the agent adds the CloneBehaviour behavior, that is responsible for cloning the agent according to the number of destinations in the itinerary. Each agent verifies, adding the GetAvailableLocationsBehaviour , if the destination container exists. If it does not exist, the agent destroys itself. If it exists, clone migrates for one of the destinations in the itinerary, where it adds the JobBehaviour, and executes the defined task. When it finishes the task, it returns to the source container, shows the results in the UI5 and destroys itself.

Master-Slave Here, a MasterAgent, of type Agent, was implemented. It adds the

ReceiveResultBehaviour, of type CyclicBehaviour, responsible for receiving the messages destined to the master. Then, master requests to its container the creation of a SlaveAgent, also of type Agent, passing as parameter the destination of the slave. After being created and started, the slave initializes the job and migrates. When it arrives in the destination, the agent adds the JobBehaviour, that executes the defined task, and then returns the source container, where it sends the results to the master and destroys itself. The results are sent through ACL messages, and received by the master’s cyclic behavior.

In Figure 4 we have the sequence diagram for this pattern. In the used notation, we have an object representing the container, and when the agent wants to migrate, it requests to this object, using an arrow labeled with a move(). Then, the container sends the agent to the destination container (arrow labeled with a MIGRATING AGENT), that receives and instantiate the agent, so that it continues the execution in the new container (arrow labeled with a initialize()). Message interchange is represented by arrows labeled with a send(“content”).

MoProxy In this pattern, we defined a MoProxy agent, of type Agent, that is the resources

granter. Then, any agent can send an ACL message to the MoProxy, passing as parameters the type of resource that it desires to access and the permissions desired. When it receives the message, MoProxy creates an agent (ResourceAgent) which gives access to the desired resource, respecting the access restrictions of the resource. Then, it sends the identification of the ResourceAgent to the agent who requested the resource. From there, the requester agent starts to interact with the ResourceAgent through ACL messages and, for this, both agents must add a CyclicBehaviour to receive and to treat the messages directed to them. The agent must know the types of requests that are available for that resource and in case that the resource is not available, MoProxy agent returns the message to the requester agent informing the inexistence of the resource.

5 User Interface

Figure 4 - Master-Slave pattern Sequence Diagram

Meeting The implementation of this pattern is illustrated in the sequence diagram shown in

Figure 5, where we use the notation explained previously. As we can see, we defined a MeetingAgent, of type Agent, that is in a container called SourceContainer. This agent possesses a Meeting object and requests to it the meeting place (method getMeetingPlace). Then, the agent migrates to the meeting place (DestinationContainer),

and, after its arrival, it adds the ReceiveMessageBehaviour(CyclicBehaviour), that is responsible for receiving the messages destined to the MeetingAgent.

In the meeting place there is a MeetingManager, implemented as an agent. It has the CyclicBehaviour named UpdateMeetingBehaviour, responsible for receiving messages for the meeting update.

The MeetingAgent requests the Meeting object, to register it in the meeting (method ready). Then, a message is sent to the MeetingManager, using the capacity of sending ACL messages of the MeetingAgent. The manager sends the list of identifications of agents in the meeting for the just-arrived agent, and sends the identification of the just-arrived agent to all agents in the meeting. From now on, the MeetingAgent can interchange messages with others agents in the meeting.

When it wants to leave the meeting, the MeetingAgent sends a request to the Meeting object (method leave). A message is sent to the manager, informing that the agent is leaving the meeting. The MeetingAgent, then, migrates to another container.

Figure 5 - Meeting Pattern Sequence Diagram

Facilitator The implementation of this pattern was simplified, since the platform already

provides a Directory Facilitator (DF) service. To register in the DF the agent must include in its initialization (method setup) the following piece of code:

try { ServiceDescription serviceDescription = new ServiceDescription(); serviceDescription.setType("AgentType"); serviceDescription.setName("AgentName");

DFAgentDescription dfd = new DFAgentDescription(); dfd.setName(getAID()); dfd.addServices(serviceDescription); // register the description with the DF DFService.register(this, dfd); System.out.println(getLocalName()+" registered with the DF"); } catch (FIPAException e) {e.printStackTrace();}

Then, we implemented a FacilitatorAgent, of type Agent, that waits for messages from other agents. When the agent receives a message, it adds the SearchBehaviour (OneShotBehaviour), that will do the search according to the type defined in the message and then it returns the results to the requester agent.

Mutual Itinerary Recording In this pattern implementation, we have two cooperating ItineraryAgent agents.

The functionality is similar to the Itinerary pattern. The difference is that, here, an agent always sends to the other a message carrying its previous, current and next container. This message is sent in a safe way using SSL/TLS6. It is necessary, however, to define a security configuration file, as explained in . In this file the following line must be added:

[21]

To receive the itin

the agent adds the CheckIti

4. Conclusions The use of design p

bring to applications develThese advantages can also

6 SSL/TLS – Secure So

imtp=jade.security.impl.RMISSLIMTPManager

erary from the other agent and verify if some problem exists, neraryBehaviour (CyclicBehaviour).

atterns has generally increased due to the advantages they can opment, like reuse and a better understanding of their project. be obtained when developing mobile agent-based applications

cket Layer/TransportLayer Security

by using mobile agent design patterns. In this sense, several mobile agent patterns have already been proposed. These patterns present solutions that can be reused, avoiding loss of time and effort to investigate problems that have already been solved.

In this work, we implemented mobile agent design patterns using the JADE framework. As mentioned in Section 3, all patterns chosen could be implemented without major obstacles as long as the developer is familiar with JADE. Indeed some concepts and tools offered by JADE made the task easier. For instance, the Sniffer Agent helped testing and debugging. Also, the Directory Facilitator provides the search service required by the Facilitator pattern.

In general, the behaviour concept is very useful, since it can be dynamically added to an agent to change its actions and add new functionality. Also, behaviours encapsulate the actions of agents. For instance, by defining the JobBehaviour class, we were able to implement the task of the agent separately from the implementation of the agent itself. Another example is the SetItineraryBehaviour class, where the way of setting the itinerary can be changed without affecting the corresponding agent. Agent communication can also be easily implemented by using the behaviour concept.

Another advantage of JADE is the possibility to check whether a destination agency is available before moving an agent to it. The ACL feature of messages exchange is also very useful, since it does not require an agent to have concrete references to other agents in order to be able interact with them. Interaction between agents can be made by asynchronous messages exchange.

A drawback of JADE is not to provide support to migration between different execution environments, i.e., it is only possible to migrate agents in the scope of a single one. Therefore, migration between different hosts is only supported if containers are in the same platform.

Finally, it is important to remark that most of the patterns considered in this paper have been proposed in the scope of other agent platforms. This is evidence that the JADE platform offers support that is comparable to other platforms.

5. References

[1] Y. Aridor and D.B. Lange. Agent design patterns: Elements of agent application design. In Proceedings of the Second International Conference on Autonomous Agents. ACM Press, 1998.

[2] M.C. Bernardes and E.S. Moreira. Implementation of an intrusion detection

system based on mobile agents. In International Symposium on Software Engineering for Parallel and Distributed Systems (PDSE 2000). IEEE, 2000.

[3] D.M. Chess. Security issues in mobile code systems. In Mobile Agents and Security, 1998.

[4] A. Fuggeta, G.P. Picco, and G. Vigna. Understanding code mobility.

In IEEE Transactions onSoftware Engineering, volume 24, May 1998.

[5] R.H. Glitho, E. Olougouna, and S. Pierre. Mobile agents and their use for

information retrieval: A brief overview and an elaborate case study. IEEE Network, 2002.

[6] F.P. Guedes. Um modelo para o desenvolvimento de aplicações baseadas em agentes móveis. Master’s thesis, Universidade Federal de Campina Grande, 2002.

[7] C.G. Harrison, D.M. Chess, and A. Kershenbaum. Mobile agents: are they a good

idea? Technical Report RC 19887, IBM Thomas J. Watson Research Center, 1995.

[8] Hayzelden and Bigham, editors. Agents for Future Communication Systems.

Springer, 1999. [9] IKv++ GmbH. Grasshopper - A Platform for Mobile Software Agents.

http://www.grasshopper.de, 1998. [10] W. Jansen and T. Karygiannis. Mobile agent security. In NIST Special Publication

800-19, 1999. [11] E.A. Kendall, P.V.M. Krishna, C.V. Pathak, and C.B. Suresh. Patterns of

intelligent and mobile agents. Proceedings of the 2nd International Conference on Autonomous Agents (Agents’98), New York, 1998. ACM Press.

[12] C. Klein, A. Rausch, M. Sihling, and Z. Wen. Extension of the Unified Modeling

Language for mobile agents. In Keng Siau and Terry Halpin, editors, Unified Modeling Language: Systems Analysis, Design and Development Issues. Idea Publishing Group, 2001.

[13] D.B. Lange and M. Oshima. Programming and Deploying Java Mobile Agents

with Aglets. Addison-Wesley, Reading, MA, 1998. [14] D.B. Lange and M. Oshima. Seven good reasons for mobile agents.

Communications of theACM, March 1999. [15] C. Larman. Applying UML and Patterns - An Introduction to Object-Oriented

Analysis and Design. Prentice Hall, Inc., 1999. [16] H. Peine. Application and programming experience with the ara mobile agent

system. Software-Practice and Experience, 2002. [17] A.Kr. Singh, R. Sankar, and V. Jamwal. Design patterns for mobile agent

applications.

[18] Y. Tahara, A. Ohsuga, and S. Honiden. Agent system development method based on agent patterns. In Proceedings of the 21st international conference on Software engineering. IEEE Computer Society Press, 1999.

[19] Y. Tahara, A. Ohsuga, and S. Honiden. Safety and security in mobile agents. In

Draft Proceedings of AOSE2000, 2000. [20] Y. Tahara, N. Toshiba, A. Ohsuga, and S. Honiden. Secure and efficient mobile

agent application reuse using patterns. In Proceedings of the 2001 symposium on Software reusability. ACM Press, 2001.

[21] G. Vitaglione. JADE Security Administrator guide. http://jade.cselt.it/doc/tutorials/SecurityAdminGuide.pdf, September 2002.