Design Pattern for Agent

 

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.

Pattern

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.

Pattern

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).

Pattern

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.

Pattern

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).

 

Pattern

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.