Implementando Padrões de Projeto para Agentes móveis no

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 [16]. 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.
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
2
http://jade.cselt.it
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
[18] and [1]. 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.
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 [13] defines a service that provides a name service and
localization of agents with specific abilities, thus facilitating the localization of a given
agent.
Mutual Itinerary Recording
This pattern ([10]) 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.
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 [21]. In this file the following line must be
added:
imtp=jade.security.impl.RMISSLIMTPManager
To receive the itinerary from the other agent and verify if some problem exists,
the agent adds the CheckItineraryBehaviour (CyclicBehaviour).
4. Conclusions
The use of design patterns has generally increased due to the advantages they can
bring to applications development, like reuse and a better understanding of their project.
These advantages can also be obtained when developing mobile agent-based applications
6
SSL/TLS – Secure Socket 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.