Agents, Actors, Roles, and Semantic Interfaces

David Wallace Croft
croft@alumni.caltech.edu

1998-04-26

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, ...

William Shakespeare
"As You Like It"
Act 2, Scene 7

Abstract

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.

The Foundation

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.

Interface Life-Cycle Methods
java.applet.Applet init(), start(), stop(), and destroy()
javax.servlet.Servlet init(), service(), destroy()
aglet.Aglet onCreation(), run(), onDisposing(), many others
A Sampling of Agent Life-Cycle Methods

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.

Semantic Interfaces

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 assumed.

Roles

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

Actor

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:

http://www.alumni.caltech.edu/~croft/research/agent/role/Actor.java

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.

  1. 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.".

  2. 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.

  3. 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.

  4. 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.

  5. 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 interface.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. The Actor source code has been sucessfully compiled. Even as small and simple as it is, this is reassuring to know.

Conclusion

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.

References

Back

http://www.alumni.caltech.edu/~croft/research/agent/role/
David Wallace Croft, croft@alumni.caltech.edu
Posted 1998-04-26.