The problem we are facing
consists in lowering the cost of developing a multi-agent application. It is
not easy to achieve this goal without simplifying the context. We decided of using
FIPA-compliant platforms and this reduce effectively the dimension of the
problem (almost all of them are JAVA-based). In order to understand how this choice effect the proposed solution we will now
describe the main differences in two different implementations (FIPA-OS and
JADE) of the same agent. It is important to note that FIPA-OS and JADE cover
the greatest part of the deployed platforms in the AgentCities
network and therefore the availability of patterns for them results in a
broadly applicable repository.
Fig. 1
In fig. 1 we can see the
structure of a very simple FIPA-OS agent. It is composed of the main agent
class and two task classes.
Fig. 2
The expressed behavior (as
described in fig. 2) consists of:
1. The execution of the agent’s
constructor and setup methods.
2. The instantiation of the
ComponentTask1 task (a piece of behavior in the FIPA-OS terminology) from the
agent’s setup. In the FIPA-OS platform at the moment of the instantiation of a
new task, the execution of the constructor it is followed by the execution of
its startTask method. While the constructor is often
used to initialize variables, the startTask method is
used to actuate the specific initial behavior of the task.
3. From the startTask
method of ComponentTask1 we instantiate ComponentTask2 (another task, for
example devoted to elaborate some kind of data). Again, after the constructor,
the startTask method is executed.
4. The conclusion of the execution of
ComponentTask2 is stated by a done command in the last line of the code of its startTask method. The result is that the done event is sent
to the task that invoked this one. This event is received by the done method in
ComponentTask1. One different done method is necessary in the calling task for
each other invoked task (the name of the method is in fact composed by the done
prefix and the invoked task name).
Fig. 3
In fig. 3 we can see the
JADE implementation of the same agent. The same behavior of the FIPA-OS agent
is described for this agent in fig. 4.
Fig. 4
We can see that the
structure is very similar. One of the differences consists in the done method.
In JADE we have one done method for each behavior class (a behavior is the JADE
implementation of the FIPA-OS task). The agent’s scheduler verifies the result
of the done method for each behavior and if it is true the class will not be
rescheduled. There is no necessity of introducing a method in a behavior who
calls another one.
Many works have been
proposed about the patterns of agents; as already discussed, our concept of
pattern addresses an entity composed of portions of design and the
corresponding implementation code. We look at an agent as a composition of a
base agent class and a set of task/behavior classes – this is the structure.
The behavior expressed by the agents using their structural elements can be
detailed in a dynamic diagram such as an activity/state chart diagram – this is
the behavior.
From the structural point
of view, we consider four classes of patterns. They are described as follows:
Action
pattern. A
functionality of the system; it may be a method of either an agent class or a
task class.
Behavior
pattern. A specific
behavior of an agent; we can look at it as a collection of actions (it
represents a task in FIPA-OS and a behavior in JADE).
Component
pattern. An
agent pattern; it encompasses the entire structure of an agent together with
its tasks.
Service
pattern. A
collaboration between two or more agents; it is an aggregation of components.
From our experience we
deduct that some elementary pieces of behavior are largely used. For example,
if two agents communicate using one of the FIPA standard interaction protocols,
the parts of code devoted to dealing with communication can be reused. On the
one hand, we can consider tasks as encapsulating behaviors that can be put in
patterns (patterns of behavior). On the other hand, if we consider an agent as
an entity capable of pursuing specific goals, carrying out some operations
(e.g. communication, moving across platforms, using some hardware resources),
we see that we can also identify patterns of agents. Furthermore, we may put
together two or more patterns of agents to obtain a pattern of service. Thus,
we can access and use single patterns or a composition of them.
It is now important to
highlight that we can identify some specific patterns for some specific fields
of application. For example, as for robotics, patterns of tasks may be useful
to reuse common behaviors like planning and obstacle avoidance. Hence, it turns
out that some application domain classification needs to be done. Looking at
the functionality of the patterns, we can consider four categories:
Mobility. These patterns describe the
possibility for an agent to move from a platform to another, maintaining its
knowledge.
Communication. They represent the solution to the
problem of making two agents communicate by a communication protocol.
Elaboration. They are used to deal with the
agent’s functionality devoted to perform some kind of elaboration on relevant
amounts of data.
Access to
local resources.
They deal with information retrieval and manipulation of source data streams
coming from hardware devices, such as cameras, sensors, etc.
In fig. 6 we can see an
example involving two agents of our patterns for the FIPA-OS platform. It is
structurally described by two class diagrams (one for each agent) and
dynamically by one activity diagram. According to the description, the two
agents communicate in order to exchange some kind of information. The
communication is started by the QueryInitiator
agent with its QueryTask task and received by QueryParticipant agent in its QueryReplyTask.
The handleQuery, handleInform
methods are devoted to deal with each specific message (identified by its
specific performative, the speech act), in the chosen
agent interaction protocol (the Query protocol in this example).
Fig. 5
According to our
classifications, this is structurally a service pattern, since it
involves two different agents, while from the functional point of view, this is obviously a communication pattern.