Table of Contents
The ADK environment and its constituent components are introduced in this chapter. Agents are the most important part of the ADK for end users. Agents send messages to each other; move around from habitat to habitat; carry, deliver and retrieve information; and communicate with their owners via a user interface. This chapter provides background on agents, discussing what they are and what they can do.
Tryllian was founded on the idea that mobile agents have the potential to be a core element in the future of distributed computing. Agents are pieces of code that are able to perform complex, autonomous operations, and become truly powerful when they are mobile, meaning that they can travel from one machine or computer network to another. The ADK offers such mobility.
Yet, with mobility comes the risk of security being compromised. Agents must be both safe from being harmed and incapable of doing any harm to themselves before they are even sent out into the world. The ADK offers extensive security features to ensure a secure and safe agent world.
There is another benefit to agent technology. At Tryllian, we believe that software has to be easy to understand. Humans are not wired to understand bits, machine code instructions or overly generic abstractions. Humans tend to feel comfortable when reasoning about real-life situations using concepts they use every day. That's why the use of metaphors is so important when writing software. Stretching an exotic metaphor may do more harm than good, but a well-chosen one helps to think about practical solutions in a clear way.
When we started designing the Agent Development Kit, we realized it was essential to build it up from a small set of easy-to-understand concepts. The cornerstones of the Tryllian agent world are the concepts of agents, habitats, and messages.
Agents are to a degree autonomous and may make their own decisions based on their current situation. The habitat denotes the agent's location. An agent can only be in one habitat at the same time and can interact with other agents. Agents are able to move from one habitat to another. Agents communicate with other agents and with the system by sending messages.
In the end, agents are pieces of code where a computer environment is needed for them to operate. This environment is provided by the habitat. Simply put, the habitat is a software system running on a computer, and can also be thought of as the runtime environment. It provides the agents with the functionality needed to for code execution, mobility, communication and much more. Another analogy for the habitat is that it acts as an Agent Operating System. Without it, agents would not be able to exist. You can run one or more habitats per machine and configure them individually.
The concepts behind software agents are linked to artificial intelligence (AI). It is true that agents have their origins in AI; however, the ADK is primarily a software development tool and provides no built-in AI functionality. (Although integration with a rule engine like JRules is possible.)
One of the most important decisions to make prior to beginning development of an agent software project is whether you need to solve your software problem using agents in the first place. In principle, agents can be used to solve any software problem; but in some cases, they are more appropriate than in others. Here is a checklist to see if your project could use agents.
Is this a business integration problem? Are you trying to connect currently incompatible systems to each other?
Do you need to continuously monitor external systems?
Does the problem involved a network of machines?
If so, are these located at different geographical locations and is that part of the problem?
Would autonomous, upgradable mobile code help solve your problem?
If you answered more than one question answered with "yes", then your project would likely benefit from using the ADK.
The Tryllian Agent Development Kit (ADK) allows developers to design and implement distributed applications based on sophisticated mobile agent technology. Contrary to conventional applications, where executing programs reside either on a user's computer or on a server, mobile agents are traveling programs that perform their tasks on a variety of different machines, dependent upon the problem that needs to be solved. The Tryllian technology implements multi-agent systems in which many agents, with different goals and purposes, can interact in open environments.
Agents are task driven, and the composition of different tasks leads to the desired behavior. The ADK provides a large number of functions that allow the developer to create agents and to program their behavior. The ADK also provides libraries of standard behaviors that help developers shorten their development time.
To use a Tryllian agent, the habitat, or Agent Runtime Environment (ARE), must be running. This environment creates all resources and structures that are required for an agent to exist on your computer. In most cases the actual agents will be pre-defined as part of an existing application.
With the ADK, agents can also communicate with software components that are not necessarily part of the controlled agent world, such as databases, search robots, mail systems, J2EE applications, webservers.
The following concepts are commonly used with the ADK:
Habitat. This is an application on which agents run. A habitat is an application that runs on a Java Virtual Machine (VM) and provides the agent environment with an Agent Runtime Environment (ARE), i.e. a Java VM process providing different types of services. Examples of services include the agent execution model, inter platform communication, inter habitat agent travel, agent persistence, security model. Environments for agent applications are typically composed of several habitats, each hosting a number agents and providing resources exist.
Agents. An agent is an autonomous piece of code that can carry data and travel the network to perform a task for its owner. An agent has the ability to move itself to another location, but the location needs to have a habitat installed. Agents do not have the ability to travel to sites that do not have a habitat installed. An agent could employ a search engine or other Internet facilities to investigate sites without a local meeting place.
Conceptually, a Tryllian agent consists of its body and its behavior. The body includes the components that executes the agent code, sending messages and moving the agent code over the network. It is the most technical part and least configurable. The behavior specifies the actions and the knowledge of an agent. Knowledge can be given at the moment of the agent's creation but can also be obtained during the lifespan of the agent.
Figure 2.1. Agent Behavior
Sense: Observe the environment and model it internally.
Reason: Update the internal state and determine a sensible action based on the state of the environment and the internal state.
Act: Carry out the proposed action.
Let's take a closer look at these three phases in more detail.
The agent can receive sensory input, or events, from the outside and from within itself. External events are always messages. An agent can receive messages from System Agents or from other agents in the habitat. Behavior triggered by such messages is known as reactive behavior . Later chapters in the Developer's Guide explain how messages are sent and received.
The agent also receives an internal event, known as a heartbeat. This event is fired at regular intervals to give the agent a chance to act spontaneously and not just to react to outside events. Behavior triggered by heartbeats is known as proactive behavior .
A heartbeat normally occurs once every so many milliseconds, to give an agent the opportunity to execute its tasks. The heartbeat rate may be explicitly raised or lowered, either for debugging purposes or to fine-tune the performance of the system. The heartbeat rate can be varied by editing a file called habitat.properties in the config directory.
The next phase in the agent's behavior cycle is processing the incoming information, or generally deciding what to do. The reasoning part is to be provided by you, the ADK developer, since you are defining the agent's behavior. Suppose, for instance, that you were to make a Calculator Agent that would process an incoming message containing a calculation (as a string) to perform, and send back the result as a message. Parsing the incoming string and actually performing the calculation would be considered the reasoning part of the agent.
Reasoning is always performed by use of tasks, which are plugged into the agent. A task is an atomic unit of reasoning that is used as a building block to define complex behavior. As an agent is supposed to display complex and intelligent behavior, it may have several tasks that are active at the same time. When an event occurs, it is routed to all tasks interested in doing something with it. Tasks are processed according to a specific Task Model, as explained in (Chapter 7, The Agent Task Model) The task model allows the agent to perform its task simultaneously or in a scheduled sequence. The task model roughly corresponds to the modern office employee's concept of time management.
The actual action that the agent takes is defined in a task. A variety of tasks are already available in the ADK which are found in the Task Model chapter (Chapter 7, The Agent Task Model). Some of the most obvious tasks are sending a message and moving to another location. However, scheduling another task is itself also a task.
The Act phase occurs when the agent interacts with other agents and with its runtime environment. The technicalities of sending and receiving messages, moving the agent around and keeping it alive in the process, are self-contained in the runtime system, and does not need to be handled by the developer.
Agents receive stimuli from their environment and store these observations in their memory. How and if the agent reacts to these stimuli is decided during reasoning. As a result of reasoning, the agent commits to one or more actions and plans them in its personal agenda. These actions are then executed during the act phase. Agent actions can implicitly or explicitly influence the agent environment, e.g., by sending a message into the current habitat. The implementation is done in the following parts of the ADK:
| Stimuli | Meaning |
|---|---|
| Body: | Handled by the ARE |
| Behavior: | The AFC API |
| Sense: | Receive an event |
| Reason: | Perform tasks |
| Act: | Calls to ARE / Jumps out of the method |
An agent contains a collection of currently active tasks. Tasks can be added to or removed from an agent. The Agent class provides a common context for all tasks it contains. In that context, agents have the ability to find information about the location and the identity of the agent. A task can receive heartbeats and messages. Heartbeats are a type of non-event that occur to provide the agent time to perform proactive behavior. An example of proactive behavior would be an agent suddenly deciding to move somewhere else. In our behavior model, this "sudden decision" is triggered by a heartbeat received by a task. Behavior of an agent can be also reactive, for example, a task can react to messages the agent receives. A task may at will receive all or some of the messages sent to the agent. A task can finish, either succesfully or with a failure.
The Task Scheduler enables you to encapsulate subtasks in a higher-level container task. By default, tasks are executed in parallel. However, in addition to encapsulation, the container task incorporates a scheduling mechanism that enables the developer to have control over the order in which the subtasks are executed. There are two ways to schedule subtasks in a task. In the first approach instances of subtasks are created and added to a task. Then all subtasks are running at the same time. Another way to schedule subtasks is by adding them into a sequence. This sequence is comprised of a number of subtasks that may or may not form a loop. Using the Task Scheduler, you program the agent similarly to creating a flowchart by stating the order of the subtasks to be executed.
Clients of Tryllian are building applications and solving day-to-day problems that provide new facilities that would be hard to deliver without agent technology. Several applications have already been developed, examples are an SMS dating application, and a system for remote software distribution. More applications are under development.
The following are a number of functions used by developers to create agent-based applications:
Create habitats. With the ADK, you can define a habitat where agents exist. A habitat also has a number of standard system agents that assist other agents in accessing external resources.
Create agents. Different agents with new behaviors can be built.
Create agent behavior. Simple agents may receive innate knowledge that allows them to act in a default manner. More sophisticated agents will have defined decision rules. They even have facilities that allow them to learn new behaviors depending on their experiences.
Define conversations. The ADK is primarily composed of conversations in the context of a specified language or set of protocols. The format of these messages is defined by the Agent Communication Language (ACL) and is currently inspired on the FIPA (Federation of Intelligent Physical Agents) protocol. The ADK also allows developers to specify their own protocol.
Prior to building an agent applications, several important factors need to be taken into consideration. These will become important as you build more complex software applications, and careful thought to these early in the process will result in efficient programming.
Depending on the type of application you are designing, you must determine how many habitats (Agent Runtime Environments) are going to be used. If your project goal involves connecting two incompatible, remote databases to each other, you generally would set up two habitats, one near each system. It also depends on where you need connectivity and flexibility; if a plain JDBC connection is good enough, use that, but if you want more (such as system monitoring, intelligent and/or pro-active behavior), sending an agent to a habitat is preferred. If your project is about a web interface to easily upgradable agents that handle user requests of some sort and store them in a database, a single habitat solution would be sufficient.
Habitats are the nodes in the network which can have many forms; hierarchical, all-to-all or many-to-many. It is up to the architect which network type suits best, given the technical design.
In most cases, all functionality of the application can be implemented into one agent. This agent might have to communicate with several (types of) databases, some servlets and be able to send email. It is our experience that encorporating all functionality into one agent is not a wise thing to do; it prevents dividing the application into small enough pieces such as database connectivity, webserver communication and email communication and causes engineers to run into each others code and components.
Dividing up these three tasks into three separate agents will prevent this. One agent knows how to access the databases, one agent can communicate with the webserver and yet another can send email. Managing this approach allows you to measure progress per agent. In addition, it provides an agent-oriented approach, enabling the reuse of agents for other projects. Moreover, modifying a subcomponent during runtime is easy; just replace the corresponding agent with a new version instead of installing a new application.
However, do not overdo the division of the application's functionality; the more agents you design, the more agent-to-agent communication will be needed to get information where it is needed. This is a complicating factor and should not be disregarded. Good design takes the trade-off between too few and too many agents into account and contains an intermediate setup; it distinguishes between roles and responsibilities. Roles translate into agents, whereas their responsibilities are their tasks. If you doubt that you should create a new agent or extend an existing one with additional responsibilities, as a rule of thumb, do not create new agents but reduce complexity by giving responsibility to existing agents.
Once it is clear which agents are going to play a role in the application, you must define what they do, when they do it, and what they should do if they cannot. More on this is discussed in the Task Model chapter (Chapter 7, The Agent Task Model).
Messaging ties all agents together. If the database agent wants to send email, it will have to ask the email agent to do this for him. This is done by sending a request message from the database agent to the email agent, containing the necessary data (such as an email address). The messaging mechanism provides a nice, weak-coupling interface for the engineers to use; they can tell each other "send me a message with the right content and my agent will send it to the specified email address", or "my agent will store the data in the database for you".