Information Technology Reference
In-Depth Information
Experience in developing agent-based systems has shown that actions and sensors
alone are insufficient - there are many cases where actions and sensors must interact
through some shared data structure or API, for example: a graphical interface, a con-
nection to a remote system (e.g. controlling a robot via bluetooth), or something sim-
pler, such as a queue. While it is possible to model all of this through the FIPA notion
of a platform service, the approach is not appealing because platform services are typ-
ically shared resources, whereas these resources are more often private (to the agent).
As a result, we introduce a third component, known as a
module
. This component is an
aggregation of related sensors and actions that share a common data structure (the mod-
ule). Typically, the sensors and actions associated with the module are implemented as
inline classes, making the component self-contained, but this is not required, and the
implementation can just as easily be spread over multiple classes. Modules are named
so as to maintain a clear distinction between them and services, which are a runtime
environment concept.
By introducing the notions of actions, sensors and modules, we offer a simple model
for integrating with the environment that engenders reuse of components both across
applications and across languages. In particular, modules can be viewed as a form of
API that can be used by any CLF-based agent. Currently, module's exist for: creating
and manipulating Stack and Queue data structures; and interacting with various pre-
existing platform services, including the FIPA Agent Management Service, and our EIS
and CARTAGO services. As hinted above, they can also be used to implement clients
to connect to remote systems or graphical interfaces for agent-user interaction.
Planning.
Support for planning comes in the form of an extensible set of plan opera-
tors and a plan executor that is based on the intention stack approach adopted in Jason
[2]. The default implementation includes: brackets, if-else statements, while loops, state
querying, plan expansion (foreach), assignment (assigning a value to a variable), failure
handling (try-recover), and durative actions. Each of these operators has an associated
class that implements the
IPlanStep
interface. The key method of this class is the
han-
dle(...)
method, which implements the operational semantics of that plan operator. This
method is called by the plan executor. Additional operators can be added, for example,
in Af-AgentSpeak, goal invocation is implemented as a custom plan step.
2.2
Skeleton Interpreter
The recommended hierarchy of the agent classes is shown in Fig. 3. Whilst it is not re-
quired that agents extend the AbstractLanguageAgent class, it is the easiest and quick-
est way to incorporate Agent Factory's Environment Interface, FIPA standard platform
services, and runtime environment features such as scheduling algorithms. The Ab-
stractLanguageAgent class provides basic agent action and sensor functionality, such
as printing, ACL communication, migration, state monitoring, and platform service
availability.
When prototyping languages we recommend the following naming scheme. The pri-
mary functionality of the agent is encapsulated within the
AbstractXXXXAgent
class,
where XXXX is replaced with the name of the language. This scheme is also applied
