|
Coordination Artifacts are designed to separate out an
abstract communication pattern, on the one hand, and the
domain-specific clients of the communication on the other. The
internal parts of the Artifact are concerned with organizing
Communities, Relays and other COUGAAR infrastructure in a
structured way in order to represent a pattern of inter-Agent
chatter. Each kind of Artifact completes this by supplying
Community names, data types etc.
Coordination Artifacts are specifically designed to
operate across Plugins. At first glance this might appear
to violate one of the design principles of COUGAAR. But on
further reflection it can be seen that the Coordination approach
is analagous to a cross-cut in Aspect Oriented Programming.
Just as an Aspect cross-cuts the dominant Object Oriented
decomposition, so a Coordination Artifact cross-cuts the Plugin
"decomposition" of a COUGAAR Agent.
Coordination Artifacts are created by a
CoordinationArtifactProvider, via requests made to the
CoordinationArtifactBroker. A CoordinationArtifactProvider is
like a COUGAAR ServiceProvider: its primary job is to find or make
CoordinationArtifacts of some particular kind. But it also
defines a set of Roles that describe the functions
performed by clients of this kind of Artifact. For example in
Artifacts that implement a multicast request (one request,
multiple replies), the two Roles are queryer and responder. A
Provider also implicitly defines a set of parameters that
distinguish the individual instances of that kind of Artifact from
one another.
Every Role in an Artifact can be seen from two perspectives: that
of the Artifact and that of a Role player. Borrowing some
terminology from the CORBA Component Model, we refer to these
as Facets and Receptacles, respectively. The
analogy is only approximate, however. Unlike CCM, both Facets and
Receptacles are interfaces, and typically these interfaces overlap
without being identical. On the other hand, a Receptacle is
always bound to exactly one Facet, as in CCM, and is the client's
only handle into the Artifact (which in this analogy is like a
Component in CCM), also as in CCM.
This leads to the following Java interfaces:
- RolePlayer: From the Artifact's
perspective, each client plays one of the Artifact's defined
roles. This interface specifies that abstracion.
- Facet: The generic viewport that any given
RolePlayer has into the Artifact is specified by a Facet,
which is effectively a definition of the role.
- Receptacle: The RolePlayer's handle on a Facet.
- CoordinationArtifact: The creation of
Facets and the linkage between Facets RolePlayers is handled
at this layer.
- CoordinationArtifactProvider: The main job
of the Provider is to define the logical Roles and parameters, and
to create and manage CoordinationArtifacts as needed.
- CoordinationArtifactBroker: This interface
defines a COUGAAR service that provides the top-level entry point
into CAs.
Given these definitions, we can see that a Coordination Artifact
is essentially coordinating communication between Role Players.
But the Role Players as well implement a kind of coordination of
their own, a dual of the Coordination Artifact: the Players
coordinate the operation of the various Artifacts in which they
play. Although the purposes and structure of these two sorts of
coordination differ, they share one important feature: the logical
structure of both can be described declaratively as set of
dependencies between and actions among the parts. Furthermore,
the interactions between a Role Player and an Artifact can be
expressed as assertions, retractions or modifications of facts.
Rule languages are particularly good at expressing facts and
dependencies, and the Coordination Artifact code is explicitly
designed to work with rule systems, though it's written in a
language neutral way. The assumption is that a collection of
implementation classes of the abstract Artifacts and Role Players
can be written to use a specific rule language and rule engine,
while the common infrastructure can deal in general with facts,
assertions, etc.
In this scenario, the rule engine is owned by the Role Player, and
its collection of facts at runtime is partitioned by the Artifacts
with which it interacts. Once a Player is bound to an Artifact,
the primary means of interaction between them by means of facts: a
given Player sends fact assertions, modifications and retractions
into its Receptacle for a given Artifact in order to propogate
those assertions etc to other Player's in the same Artifact; the
Artifact in turn propogates assertions, retractions etc by sending
them to the appropriate Player. Thus the RolePlayer and
Receptacle interfaces are very similar, precisely because of this
duality.
|