OmarJ
is an agent development environment that provides tools for creating
and managing systems of agents. The core simulator is a Java
implementation of OmarL (formerly D-OMAR), which is written in LISP.
OmarJ provides a procedural language for defining behavior (ScoreJ), a
time management component, an inter-process communication mechanism, an
event recording mechanism, and an external communication layer.
The list below gives a
quick listing of the main features of OmarJ. Longer descriptions follow
the list and much more detailed descriptions can be found in the
appropriate Java Docs.
The class scorej.S contains many constructs
useful for defining agent behaviors that are present in the Lisp SCORE
language. The race, join, and satisfy
methods of scorej.S provide a mechanism for controlling parallel
procedure execution. These methods spawn separate Java Threads in which
each parallel method is executed. The methods to be executed by race,
join, and satisfy are
specified with scorej.Invocation,
which is a wrapper around the Java reflection mechanisms that are used
to invoke methods. race, join, and satisfy
return an implementation of scorej.Future,
which controls thread completion and collection of return values.
One major change is that
in Lisp D-OMAR, each procedure had an Agent object directly associated
with it. In OmarJ, no such association is necessary. Methods are
usually executed by some agent, but this is not a constraint and a
method can execute with no associated agent. This allows for scenarios
in which not every activity is 'agentized'. The actual definition of an
agent object is mainly left up to the user, with the scorej.ScoreJAgent class
provided as a possible starting point.
The SCORE concept of
scenarios is directly translated to the class scorej.Scenario. Scenario
contains methods that may be overridden to start whatever agents or
methods are neeeded.
The time management
system of D-OMAR is implemented in the class scorej.SimulationClock.
The basic idea is that each of the executing threads are stored in a
table and time is advanced by the clock when all threads are in a wait
state. The clock then calculates the next time when a thread has work
to do. Depending on whether the clock is running in real-time mode or
not, the SimulationClock will either immediately jump to the next time
or will sleep until that time occurs.
An addition to OmarJ is
the presence of the NonSimulationClock,
which allows the work threads to execute in an unmanaged environment.
With the NonSimulationClock, time advancement is not controlled by any
central process. This forces the programmer to pay more attention to
the ordering of events, since there is no direct user control of what
thread will execute when and for how long. NonSimulationClock is useful
for when you want to break out of the simulation mindset, or have time
managed by an external process.
Inter-agent commuication
(which in the OmarJ world, could also be thought of as inter-Thread
communication) is provided through Signals. scorej.Signal is a direct
translation of the Lisp D-OMAR signal class, and is even interoperable
with the Lisp signals. A Lisp D-OMAR node can send and receive signals
from an OmarJ node. Signals are managed by the SignalProcessor, which
is in turn managed by the OmarJ Clock.
In Simulation mode, the
Signal processor is controlled by the Clock. The Clock will directly
invoke the Signal Processor to process signals only when all threads
are in a wait state. In Non Simulation mode
the Signal processor operates independently of the clock in its own
thread, processing signals as soon as they are received.
Threads can wait for
specific signals with the various S.waitForSignal
methods; these set up a pattern against which to match incoming
Signals. In addition, threads can set up a SignalWaitQueue to
catch all signals matching a pattern, and then manage the queue in the
user code. The SignalWaitQueues and SignalEvaluator
concepts are new to OmarJ and not present in the Lisp D-OMAR.
Automatic event
recording will be added to a later release of OmarJ. Our initial
implementation uses AspectJ to weave
event recording code into existing code. We will also provide a
graphical event viewer program. Subsequent implementations of event
recording may use some form of Java macro package.
OmarJ was designed to
make external communication as simple as possible by providing numerous
connection options. The Lisp D-OMAR socket-based protocol was
implemented in the class scorej.external.socket.SignalServer.
The D-OMAR protocol is a type-value based protocol, where objects are
sent across the socket by first sending a data type code, followed by
the data itself. The data encoding used is Java's
InputStream/OutputStream protocol, with some Omar specific object types
added. In addition to the type-value protocol, OmarJ socket connections
can also speak the Java Serialization protocol, a string only protocol,
and some agent communication languages such as FIPA and KQML.
OmarJ nodes can also be
part of a Jini network by using the class scorej.external.jini.J
iniHelper. An OmarJ node registers as a Jini service that provides
a scorej.external.jini.MessageQueueInterface,
which allows remote clients to add messages. OmarJ nodes can use the
Jini network to send Signals back and forth, and can interface with
non-OmarJ Jini nodes.
The third external
communication network in which an OmarJ node can take part is the CoABS Grid. The Grid is a
layer built on top of Jini that provides many services useful to agent
systems. The Grid is accessed through the class scorej.external.grid.GridHelper.
|
D-OMAR Home