The sample project helps new ADK users by guiding them through developing their first agent application with step-by-step instructions. A simple example is used to demonstrate the project design and process steps. In many real world situations, important data can reside in different sources on several computers. A query for a specific set of data on a certain person is created on one central computer; however, the data sources can be found on several other computers and are needed to complete the query. This example explores this situation and provides further insight into application development.

The Javadoc API documentation, thoroughly documented source code, and instructions are provided. Additional suggestions to extend the project are given. For further explanation of the concepts behind agent development, refer to the scenarios and examples found earlier in this guide, along with the Developer's Guide which is distributed with the ADK software. Be sure that the ADK is properly configured, as described in the Quickstart Guide, prior to attempting to work with these examples.

This example involves two types of agents: one that collects information (CollectAgent) and one that provides information (InfoAgent). There can be several instances of the InfoAgent, potentially on separate computers. Each InfoAgent provides a piece of the information needed by the CollectAgent. The CollectAgent tries to find this information by visiting each InfoAgent, and then communicating with it. After receiving results, the CollectAgent checks whether it has obtained all the information it requires. If this is not the case, it travels to the next location to communicate with another InfoAgent. After, it finds all the information it needs, it returns home and reports the results. A setup of this example with four computers is depicted in the following figure.

Figure 13.1. Global overview.

Two types of agents are present in the application, the CollectAgent and the InfoAgent. The task models of these agents are depicted in the following figures.

Figure 13.2. Task model of the CollectAgent.

The CollectAgent finds locations to visit by reading host IP addresses from a file (in the multi-machine version). The Sofi-number (social security number) is used to match and retrieve information specified in a file. The CollectAgent goes through a cycle of sense-reason-act to achieve its goal. It senses that information still needs to be found, reasons that moving to the next location with an InfoAgent might be useful, and acts by moving to the next location and asking for information. Once all information is collected, the CollectAgent returns home and reports the information it has found.

Figure 13.3. Task model of the InfoAgent..

The InfoAgent waits for messages that query for information about a certain Sofi-number. If such a message arrives, a data file is read (the location is specified in a configuration file). Any information pertaining to the given Sofi-number is returned to the sender. The InfoAgent effectively acts as a monitoring agent of the data source by reading the data file each time a message arrives. In a real application, this data source could be a database accessed through JDBC.

Agents use messaging to communicate. A sequence of related messages (for example, a question and answer session) is called a Conversation. In this example, there is only one type of conversation between the CollectAgent and the InfoAgent. The CollectAgent asks each InfoAgent for information about a certain Sofi-number. Such a message type is called a Query-Ref according to FIPA specifications, a standard for agent communication, (for more information, visit www.fipa.org). A Query-Ref should only be answered with an Inform, Failure or Refuse. In this example, the InfoAgents always respond with an Inform, containing any results that may be found. (A useful extension would be to let the InfoAgents send a Failure message in case no information on the given Sofi-number could be found but this is not included in this example). The messaging used in this example is given in the following table of the properties of the messages used in this application:

The actual message content consists of key-value pairs. The Query-Ref in this example contains one tuple with the key SOC_SEC_NUMBER defined in the interface sampleproject.Constants.Keys. Both the InfoAgent and the CollectAgent use this interface to understand each other's messages. The Inform sent back by the InfoAgent contains specific tuples with data about the given Sofi-number. The keys are the properties (name, address, location, salary, employer, stock, hobby, birthdate, number_of_kids) defined in the data files used by the InfoAgents.

A solution like this is fine for relatively small applications. For bigger applications with more complex messaging, it is advisable to use business objects to encapsulate and communicate data.