Agents, Actors, Roles, and Semantic Interfaces
David Wallace Croft
|All the world's a stage,
And all the men and women merely players:
They have their exits and their entrances;
And one man in his time plays many parts, ...
"As You Like It"
Act 2, Scene 7
This publication describes a method by which mobile software agents and
hosts can automatically communicate their roles and responsibilities.
The introduction of "semantic interfaces", or "roles", allows such
actors from multiple and diverse agent framework families to interact
without necessitating the requirement for a universal agent
communication language. Instead, diverse agents support a simple, common
method for enumerating what interfaces they are capable and willing to
implement in the current context.
One of the problems of those who do research in mobile software agents
is universality. It is desirable that any agent should be able to
communicate, understand, and interact with any other agent despite
initial unfamiliarity with the purposes or protocols of the other.
The Java programming language lays the groundwork by facilitating
communications at the levels of the transport protocol and at the
syntactical interface. In particular, Java Remote Method Invocation
(RMI) provides a simple programming interface for code mobility,
including remote polymorphism, and encapsulated remote interfaces. The
Java programming language even includes a mechanism by which any object
can query any other object for a list of its interfaces via the
metaclass "Class" object and its "getInterfaces()" method.
Despite the fact of having for any Java object inherent access to
all interfaces which establish the comprehensive set of syntactic
"contracts" for communication and interaction, the problem of selecting
appropriate interpretations and interactions still remains.
The Tower of Babel
One approach at attacking this problem is to create a common Agent
Communications Language (ACL) in which roles can be communicated and
understood in depth. Unfortunately, this attempt seems to be centered on
the use of symbolic ontologies developed by academic consortiums aimed
at creating a universal language which would solve the hard problem of
intelligent comprehension of natural language by machines. I have very
little faith in this approach as it relies upon (1) the symbolic
approach to AI and (2) top-down design by committee. I prefer instead
what I see as a proven, natural approach to real-world intelligence: the
incremental evolution and opportunistic cooperation of bottom-up
subsymbolic self-organizing subsystems.
Another approach to this problem is to discard universality and
rely upon an "inside-out" approach in which the established framework
for communication and behaviors for multiple-agent systems is designed
and promoted by a single entity such as an academic or industry research
lab. By adhering to this standard, third party developers of agents
expand the base of the available agents, achieving a "mini-universality"
within a closed system. JavaSoft has effectively and beneficially
promoted such a standard by introducing the interfaces for single-hop
mobile agents on clients and servers, "java.applet.Applet" and
"java.servlet.Servlet" respectively. The IBM Aglet and ObjectSpace
Voyager frameworks are similar examples.
What is desired is the ability for one agent to potentially
interact with any agent from any other standardized or proprietary
framework family. The problem with this is that there are multiple
standards for the life-cycle processes ("their exits and their
entrances"). It seems that every mobile code framework has its own
unique set of life-cycle methods. To create a framework for a host that
can receive and implement the union of all such agents is an impossible
task as new agent frameworks are being created continuously.
||init(), start(), stop(), and destroy()
||init(), service(), destroy()
A Sampling of Agent Life-Cycle
||onCreation(), run(), onDisposing(), many others
It's Just Semantics
With the introduction of reflection and introspection on objects in Java
1.1, JavaSoft introduced new flexibility as to the ways in which an
object can be queried for all of its possible manipulation mechanisms.
Note, however, that while this allows for a listing of all of the
syntactic interfaces, this does not provide for an automated
understanding of how the state can be modified or operations invoked
intelligently. Instead, the potential for such intelligent acts are
deferred to humans through the presentation of human-readable JavaBeans
For example, if an object implements the "java.lang.Runnable"
interface, it is guaranteed to have a publicly accessible "run()" method
which can be called by any other object that has access to it. If a
machine host receives an object from a remote source and, upon having
queried it for a list of its interfaces, found that is "Runnable",
should it assume that the object is an agent to be launched in an
autonomous thread by calling its "run()" method? Or, if it is also an
applet, should it call its "init()" and then "start()" methods instead?
If the object implements multiple interfaces with overlapping methods,
which interpretation should be used in invoking these operations for the
given context? What if the host simply wishes to suspend and remove the
object gracefully but despite calling the visiting object's "stop()" and
"destroy()" methods, it just will not give up the ghost (in the
The problem here is that while an interface advertises a syntax
for communication between objects, it does not guarantee the semantics.
The semantics, or meanings as they apply to a language within a given
context, is quite a different story from the syntax, the way in which
the language is expressed. The ability to effectively deal with the
context-dependent semantics issue is currently only possessed by human
intelligence and probably will continue to be that way for many years to
Given that only humans currently possess the ability to reliably deal
with the semantic issues of communication in the face of uncertainty,
how is it that current multi-agent systems are able to automatically
communicate today at all? The answer is that they rely upon
pre-established, human-defined semantic interfaces. Examples of these
include the well-defined, well-known, and universal protocols of the
Internet such as FTP, SMTP, and HTTP. With the adoption of
object-oriented programming, other standards have been established such
as CORBA and RMI. For agents, it is the aforementioned ACLs such as KQML
and the framework-specific life-cycle methods.
The adoption of specific semantic interfaces is an effective
means of communication which has proven itself in practice. As an
analogy, peoples of different dialects readily carry out their daily
business within their family as they all speak the same language within
that unit. Some multilingual persons have overcome this inflexibility to
gain a limited advantage when traveling abroad. Likewise, those that
have hypothetically learned Esperanto, the proposed single international
language for human communications, can interact with others that know
Esperanto. Human translators serve a purpose in these dynamics by acting
as gateways for communication among those who know well-established but
differing languages within the repertoire of the translator. Almost
everyone is at a loss when dealing with a newly evolved or esoteric
slang or jargon.
What is it, however, that any unilingual or multilingual world
traveler or translator will first do when attempting to establish
communication with a stranger? They will settle upon a pre-defined
semantic interface for further communications (examples: "Hola?",
"Speaka da English?").
If a common language is not established, communication can only
proceed by the interpretations of behaviors, common behaviors being
walking away and hanging up the phone to communicate that no further
interaction will occur. (Note that I do not include "the Language of
Love" as an example of interpreted behavior-based communication as the
interfaces are universally defined and known.) If one is lucky in these
situations, an object, such as money, can be presented to the recipient
and the right reciprocation will occur by default, such as the serving
of a beverage instead of the simple acceptance of the money as a gift.
In this latter case, the role of a vendor-consumer transaction was
What I am proposing, then, is a simple mechanism by which agents of
differing or multiple dialects can initially establish the semantic
interfaces for further communication and interaction. All agents that
possess this one single interface method for responding to a request to
enumerate their available semantic interfaces acquire the flexibility to
potentially communicate with any other agent without making any
preliminary assumptions. A simple listing ordered by preference of the
names of available interfaces in some universal namespace would be
sufficient. A querying object could then treat the queried object, if
pre-programmed to do so and at its discretion, as an implementation of
that interface. As examples, responses might be
Note that this list can change continuously over time. As an
example of the flexibility of this, an agent host server that supports
just a "Landlord" interface may accept an object that implements the
"LeasedOffice" interface. This latter object may then pass a special
interface such as a "ChatServer" interface to the server. The server may
then advertise the additional interface with requests to use the new
service being delegated to the object that has temporarily set up shop
within its chassis.
Furthermore, the list provided by the queried agent can be
context dependent given its current role. That is to say an object may
decide to only provide a subset or even none of its available interfaces
to a querying object at any given time. As examples, "I don't speak
English" could mean
- "You have mistaken me for a different type of agent."
- "You're not of the expected class."
- "The time of desired interaction has been preallocated."
- "I'm currently occupied with another object."
- "I know you can't afford my services."
- "The request for service is inappropriate! (Ask later.)"
- "That was last night. Today I'm an all-business agent."
To implement this highly flexible and simple multiple-agent
communications bootstrap mechanism, a single interface method is
required of an object.
public abstract String [ ] getRoles ( );
Note that supporting this method implies a universal semantic
interface, albeit a simple one, in and of itself. I am providing such a
universal interface, Actor, which may be viewed and downloaded from this
A number of things must be mentioned about the choices that I
have taken in the actual documentation and coding of this Java
interface. Some of these should be considered when implementing one's
own semantic interfaces.
The interface is in a universal namespace. The JavaSoft
standard for universal namespaces for classes utilizes the fact that
all Internet domain names are unique. It suggested, then, that the
package name for any class start with the domain name, in reverse, of
the responsible authors to prevent namespace clashes for object classes
and interfaces. Similarly, semantic interfaces, especially universal
semantic interfaces, should be thus named. The Actor interface is in a
package namespace owned by me but I will not preclude the possibility
that some other party with more momentum will place the class in their
own package and thus set a more reusable standard. I am hoping that
this hypothetical package name will start with "java." or "javax.".
The javadoc provides a human-readable full description
of the semantic definition of the interface or a reference to where the
definition can be otherwise found. It is important that the description
provide the full semantics for the interface including the intent,
caveats, and interaction sequence. Agent developers that write code to
this interface must be provided with an in-depth presentation of how
the interface is to be used.
The intellectual property rights for the interface have
been fully disclosed. While it is dubious as to whether an interface
can be protected, the law provides an inherent copyright to the source
code for an interface by default whether or not the copyright is
explicitly stated. On the other hand, code can only be assumed to be in
the public domain if it is explicitly stated. The Actor interface has
been released to the public domain so that it may be universally
downloaded and compiled immediately by other parties.
Contact information has been provided. A point of
contact is provided for any questions regarding the implementation and
use of the interface. This is crucial for semantic interfaces in that
there are always detail questions that are not covered, try as one
might, within the description.
The version is clearly identified. Along this line,
while not necessarily crucial for in-house semantic interfaces,
interfaces that are intended to be wide-spread and universal should be
stable. The Actor interface, with the possible exception of its javadoc
comments, will never be changed from its current form and is thus a
suitable, stable base for incorporation into applications developed by
other parties. A better reassurance would be to see the introduction of
the getRoles() method, or something akin to it, added to the
java.lang.Object or even to see the addition of a java.rmi.Actor
It is a Java interface. While it is feasible to provide
a semantic "interface" as an abstract class or even a concrete class,
Java interfaces provide the most flexibility and the best method of
doing object-oriented design. The Java programming language allows for
the multiple inheritance of interfaces by classes, abstract classes,
and even other interfaces. Because of this, they can be kept small and
reused frequently. As a general rule of thumb, when doing Java
programming, use interfaces everywhere.
The name of the interface is "Actor". When doing
research on the concept of a "semantic interface" as a separate and
distinct conceptual interface contract from a "syntactic interface", I
came across a design patterns paper on the web on the subject of
"roles". After discovering this, with the pun on "actor" as a human
thespian and the connotations surrounding an "actor" within the
object-oriented design and the intelligent software agents research
communities, the name came naturally.
The getRoles() method returns an array of String. While
I considered using an java.util.Enumeration object as the return value,
I decided that an array of String as an immutable robust iterator would
be more appropriate. While iterator classes that are guaranteed to be
robust are forthcoming in Java 1.2, the array of String was chosen for
its simplicity and universality.
The returned array may represent only a subset of the
interfaces that the object implements. Which interfaces are returned
are chosen as deemed appropriate by this object for the current
The ordering of the roles returned in the array has
meaning. The ordering of the roles in the array may be determined
dynamically by the object and should be assumed to be listed in the
order of preference, from the viewpoint of this object, for polymorphic
casting of this object by another.
The generation of the returned array is dynamic. The
selection, count, and ordering of the interfaces returned within the
array may change with each call to this method.
The method may return null. In this case where no
semantic interfaces could be communicated, what the calling object
chooses to do with the queried object from that point is, as it always
was, at the discretion of the calling object.
There are no more methods in the Actor interface. One
might be tempted to add to the Actor interface a method for the passing
of an Actor object, such as an mobile agent, to another Actor object,
such as an Actor remote host object. Another temptation might be to add
a method to facilitate the dynamic downloading of concrete classes from
a remote site as needed. In the first case, a mobile agent, whether it
be an Actor or not itself, can query an Actor remote host to see what
semantic interfaces it provides for receiving a mobile agent. In the
second case, a remote host for mobile agents, whether it be an Actor or
not itself, can query the the Actor mobile agents to see what semantic
interfaces it provides for the dynamic downloading of classes. Any
other function that can possibly be provided by an Actor object can be
bootstrapped by this one method.
The Actor source code has been sucessfully compiled.
Even as small and simple as it is, this is reassuring to know.
The wide-spread use of the semantic interfaces agent design pattern
would lead to more flexibility and diversity in communications between
multiple-agent framework families. The simple ability to dynamically
determine the subset that an agent currently supports of all of the
known semantic interfaces will allow for a richer variety of
interactions between agents without prematurely locking them down to any
pre-ordained design or structure. This will allow for the evolution of
an organic agent infrastructure in which the maximum potential for
multi-agent interoperability is presented.