Table of Contents
The sample application described in this tutorial is intended to be a starting point for further development with the ADK. A series of basic steps have been identified and described in this section and are relevant for most agent applications. In specific cases, some steps may not be as relevant than others. Also, the order of these steps is not always sequential during the actual development processes. The following listed steps specifically refer to the Sample Project distributed with the ADK (also known as Kickstart), described later in this guide, but can be expanded to include agent development in general.
The components of the problem that are active and which require important central decisions are natural candidates for implementation as agents. It is good practice to immediately identify these agents within an application, being one of the advantages of agent-oriented software. However, to complete this first step, some additional questions should be thoroughly considered for each proposed agent called X:
With what agents and or other system components will X communicate?
What is the knowledge X needs to have or retrieve?
How many agents of type X will be present at any time?
Does X need to be mobile; if so, where are its destinations?
What is the standard behavior (task model) of X?
Are there security implications for the behavior of X that need to be taken into account?
This example contains only two types of agents, where one of the two must be mobile. Real world applications may have many more types, especially in complex business flow applications.
Once the agents are sketched out, there will be a basic understanding of what agent-agent communication is needed. These can be further specified using the FIPA performatives classification.
The agents in this application communicate by asking one type of question and replying to it. The FIPA performatives used in the sample project are shown in the previous table.
After specifying the message types, actual data to be sent with the message can be specified. At this point, there are two basic situations:
The data is limited in size and can be designed to represent a small set of key value pairs.
This solution is sufficient for small-scale applications with one or two developers. Because key value pairs are not self-explanatory and type safe, the semantics and coding of data need to be well documented and cautiously followed by the team members. The advantage is that no extra code is needed to create wrapper objects.
The Kickstart project described here is an example of messaging with data added as key-value pairs directly to the agent messages. This approach was selected because the number of data types is small, and input from data files is straightforward. Strong typing with wrappers would break with the current configuration method of editable data files.
The data requires business objects with a specific object type.
This is the optimal solution for larger agent projects where a (distributed) group of developers requires a clearly defined set of business objects, defined by an architect. The main advantage is that duplicate code is not created and programmers can quickly be up to speed on the latest code. In addition, the API and additional error checking in business objects decreases the chances of bugs in data transfer code.
Although the sample project does not use business objects, you can look at the class tryllian.afc.message.object.ObjectMessage if you want to send an business object to another agent.
In the event that one or more agent is mobile outside its habitat, additional habitats must be installed. These can host identical types of agents or different ones. Initially, some habitats may even be empty. This implies that habitat configuration follows out of decisions made during agent behavior and communication specification.
One challenge during this phase is the creation of runtime scripts to start several habitat configurations from a single distribution. The sample project demonstrates how to deal with this scenario by using its platform independent ANT project builder tool. For each habitat configuration (localhabitat, infohabitat), separate runtime targets are defined in a single XML build file. It is possible to start up agents with variations in their initial state depending on the role of the habitat that is started using this method. This is demonstrated in the sample project with agents that are supplied various filenames depending on their roles. For convenience, batch files are provided as shortcuts to start a habitat in the desired state.
In case of a multi-habitat design with frequently traveling agents, monitoring the distributed application is not straightforward. Standard ADK tools may not provide sufficient feedback at the application level, for example, information is given at individual agent level. An option is to add one or more monitoring agents that interact with the other agents and report their findings to a monitoring component. For instance, in the sample project, the InfoAgent can be extended to log a timestamp and agent ID of the CollectAgent each time an information request is received.