Each task has its own internal task state, which can be used to see if the task has started, is active or has finished. When the task finishes, its state will become either success or failure. You can check these end states to determine which task to execute next or to stop executing tasks altogether.

Communication between agents occurs asynchronously. For example, this means that when some request is made to move an agent to another location, the task that requests the service regains control before the action is actually performed. Of course, we need to be careful not to engage in any activity that assumes that the action has taken place. It follows that the task must check if the move has already been completed.

Because the signal of completion is also sent as a message, any further action needs to be delayed until the expected message comes in. In the meantime, however, other messages could come in that are not expected, and these need to be dealt with. Consequently, some kind of control mechanism is required to process incoming messages.

Two types of events trigger task execution. The first type of event is an incoming message sent by another agent. This is comparable to the event model of Java. The other type of event is the task simply executing itself of its own free will, whenever it finds time. A task gets control occasionally (once every few milliseconds) in the form of an event during which the agent may perform some action.

This agent clock tick is referred to as the agent's heartbeat. Upon every heartbeat, the agent needs to check what to do next. When the agent releases control, for instance, to send a message, it does not know where to continue when the expected answer comes in, and the expected response might never come.

The agent therefore needs to keep track of its internal state and must remember what it was waiting for. To prevent an agent from entering a never-ending loop it should also check if a timeout has happened on events it was waiting for.

The Task interface is the external interface of all tasks. As seen later, the interface is implemented in a class called AbstractTask, which in turn has two direct extended classes, DefaultTask and TaskScheduler. The last two classes are used by developers, in addition to the ReactiveTask, which extends the DefaultTask. For now let's focus on the Task interface, which consists of the methods below. For your convenience, the methods are organized by logical functionality groupings.

The Task interface allows you to implement the following types of methods:

A task can be in various states, stored in the property task state (accessible through the getState() method of the Task interface). The organization of a task's states is as follows:

Figure 7.1. Task State diagram

As you can see, the task can be in the following states:

For your convenience, there are also two derived states:

These states are the cornerstones of task programming. You can view a task as an asynchronous method. Just like a method, a task promises to do something. But unlike ordinary methods, tasks are executed asynchronously. The task state can be read to find out if a task is still busy or if it has finished. Discerning between successful and failed completion of a task allows robust programming schemes. A task that completes with success can be seen as a method that has returned with all its postconditions fulfilled. A task that fails is like a method that throws an exception.

An active task can be stopped by calling the forceFinish() method of the Task interface. The expected behavior is that the task fails. But it may also be the case that the task decides all conditions for success are fulfilled so it will succeed.

The task state may be manipulated more directly from within the task by calling the succeed() or fail() methods of the AbstractTask class, which will, of course, set the task state to Succeeded or Failed, respectively.

The program needs to be alerted of changes in the task's state. This can be done using task scheduling, as explained later, but it can also be done by listening to events. This is the subject of the next section.

Each task belongs to a certain agent. Information that is the same for all tasks in an agent can be found in the agent context. This context is stored in an object of class AgentContext that can be referenced by calling getAgentContext(). However, it is important to realize that this property does not exist when the task is in the state Just Created, because in that state, the task is not part of an agent yet. In practice, this means that you cannot call getAgentContext() in the constructor of a task (it will return null). The first opportunity to call this method is in taskStarted().

The agent context contains default properties, custom properties and hooks to request and listen to movements of the agent. Here is a simple overview of the type of information that may be retrieved from the agent context (a full list of methods may be found in the javadoc):

The tryllian.afc.task.find.Directory is obtained by calling getDirectory() on the AgentContext. It offers a lookup service for agents, services and habitats. The Directory contains methods for obtaining sets of agents in a certain habitat. You can find agents that advertise a certain service and get a set of available habitats.

The table shows its most important methods, see the javadoc for a full list.

The Directory implementation uses the JNDI implementation of the ARE and facilitates most common JNDI lookups. It is not intended to completely hide or replace JNDI functionality offered by the ARE. If you want to make full use of the features offered by JNDI, you can query the Tryllian ADK Naming Context directly by calling getNamingContext() of the Directory. The structure of the returned JNDI context is described in the JNDI section of the ARE Specifications document.

The task interface has a basic implementation in the form of an AbstractTask. This derived class has two extended classes, DefaultTask and TaskScheduler. The DefaultTask has an extended ReactiveTask class itself. Schematically:

Figure 7.2. Diagram of Derived Task Classes.

We will now explain these derived classes in detail.

7.4.6.5. DefaultSchedulingRule

If a task is added and no scheduling rule is provided, either explicitly, or implicitly through extra tasks as parameters, the DefaultSchedulingRule is invoked. The DefaultSchedulingRule implements one task for success, and one for failure. You would not usually use the DefaultSchedulingRule class, since addTask(Task, Task, Task) allows you to do the same thing.

Example 7.1. Task scheduling

You can define complex task behavior by drawing up state diagrams and implementing it using TaskSchedulers. Refer to the diagram below:

Figure 7.3. ExampleScheduler.

This diagram depicts a TaskScheduler called ExampleScheduler. DoSomething and MoveSomewhere are subtasks. DoSomething is the first task that becomes active. If it succeeds, ExampleScheduler also succeeds. If it fails, MoveSomewhere is scheduled. If the agent moved successfully, it tries to do something again and we are back in the task DoSomething. If the agent could not move, the ExampleScheduler fails.

It is very easy to imagine how this implementation could be used to create an agent that could search a habitat for a certain piece of information. The above example can be translated easily to Java code using the TaskScheduler:

import tryllian.afc.task.*;

public class SchedulerExample extends TaskScheduler {

    // Subtasks
    private final Task doSomething   = new DoSomething();
    private final Task moveSomewhere = new MoveSomewhere();

    public SchedulerExample () {

        addTask(doSomething, null, moveSomewhere);
        addTask(moveSomewhere, doSomething, null);

        setFirstTask(doSomething);
    }
}

For your convenience, the AFC contains standard implementations for the most common tasks. They can be found in the packages tryllian.afc.task.* (see the javadoc for further information).

These tasks can be found in tryllian.afc.task.standard.

The following Tasks, in the tryllian.afc.task.find package, provide a way to look up agents and services and retrieve information about them. Apart from these Find tasks, the AFC contains the tryllian.afc.task.find.Directory interface to easily access local JNDI data using method calls. Thus, the Directory provides an easier way to perform local lookups than the task mentioned below, but is less general because it cannot be used to perform lookups on a remote habitat.

These methods, from tryllian.afc.task.interaction, can be used for messaging. See chapter on agent communication (Chapter 9, Behind Agent Communication) for more information.

Agents can create and delete contexts in JNDI user space. Contexts can be hierarchically ordered and are garbage collected when they become empty. If all agents bound to a certain context are persisted, the context is not assumed to be empty. Agents can bind and unbind themselves in a context, and retrieve a directory of any context.

Most of the JNDI functionality is accessible through the Directory interface. However, as a replacement for the old Rooms concept, the more general Groups concept has been introduced in the package tryllian.afc.task.group. Using this package, agents can create (hierarchical) Groups, find the available Gropus, join and leave them, find the agents in a Group, and delete them.

The tryllian.afc.task.statistics package contains tasks for getting statistics information about agents or the habitat.

The subpackage, tryllian.afc.swing, contains tasks that are not often used. SwingAgentTask (in tryllian.afc.swing) implements agents within the class of a Swing application. It propagates all messages to a SwingAgentInterface. See the Javadoc for more information.