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 Methods
||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 graphical interfaces.
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 machine)?
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 come.
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
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 assumed.
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 web site:
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
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
The Actor interface has been released to the public domain so that
it may be universally downloaded and compiled immediately by other
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
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 context.
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.
David Wallace Croft,