by David Reilly

Needs and Solutions

Agent technology is becoming more prevalent as the availability of network access, and the demand for the end-uses of agents, become greater. Electronic commerce and the Web are playing no small part, posing a challenge for developers to design agents that can enrich the user experience, or make behind-the-scenes work cheaper, faster, or more effective. Agents are being called on to assist users, to assist employees, or even to assist other agents. It is the latter, agents assisting other agents, that this article focuses on.
February 15, 1999

 Growing Need for Agent Cooperation

As the demand for more powerful, efficient and versatile agents grows, so too does the pressure on developers. After all, there's only so much that any one agent can do! If you make your agent perform too many tasks, then the complexity of development and maintenance increases. Just like any other class of application, the more demands we put on our software, the more work must be put in to achieve that functionality.

Agents are generally designed with a specific purpose in mind. They do one or perhaps several tasks very well, but aren't often designed as a jack-of-all-trades. If agents must perform more tasks, we can either increase their complexity (which increases the development effort), or we can make them work co-operatively.

 Cooperation Requires Communication

For cooperation between agents to succeed, effective communication is required. We can view a collection of agents that work together co-operatively as a small society, and for any society to function coherently we need a common language and communication medium.

This language and communication medium is critical for cooperation between agents. Imagine how ineffective software agents would be if they worked in isolation - unable to interact with their peers. Certainly we write proprietary protocols and languages, or piggyback requests over other protocols like HTTP - but this adds time and complexity to an agent's development. Unless your communication mechanism is reusable in future projects, this can be a wasteful option, and can lead to systems that aren't interoperable with future systems.

A better alternative is to use an existing agent communication mechanism, or if you're really game, to roll out your own reusable system. Remember, however, to use a common form of communication, so that one agent is capable of communicating with another.

 Seeking a Solution

There are many agent frameworks, languages and protocols available today, specifically designed for inter-agent communication. Some solutions are language-specific, while others are more general in nature. Some solutions are designed for simplicity and ease of use, and others offer more expressive communication. Each have their pros and cons, and are suited to different types of agents. Before choosing any agent communication mechanism, be sure to evaluate your needs carefully.

For developers who are getting up to speed with software agents, you may find that the sheer range of solutions is daunting. There are so many choices available, and each solution offers different properties. I've prepared a checklist of agent communication properties that agent developers should look for.

• Ease of Use
• Support for Text and Binary Data Exchange
• Support for Message Passing/Queries as well as Data Exchange
• Implementations Available for Target Platform

 Ease of Use

Ease of use is important, because many agent communication mechanisms are extremely complex. For developers who are familiar with knowledge bases and speech act theory, KQML is a good choice with its feature-rich communication primitives. However, if you're looking at writing your first agent, you're going to need a much simpler communication mechanism that meets your needs and experiences.

My work in agent communication has focused on developing a simplified agent communication protocol that isn't tied to any one platform or language. To this end, I've written the Simple Agent Communication Protocol (SACP), a mechanism for agent communication. SACP works by grouping agent communication into two roles, listening and talking.

A "listener" accepts requests for information from other agents, that do the "talking". Agents can both listen and talk concurrently, allowing for a great deal of versatility. Information is exchanged by reading and writing to a "nodespace" - a hierarchical collection of information nodes, which can contain key-value pairs with an associated MIME type. Figure 1 shows the structure of a fictitious agent's nodespace, with a specific node (IT) expanded.

Figure 1.0 - Nodespace of an Agent, Containing Both Keys and Subnodes

Under SACP, agent designers are free to choose whatever type of structure they want for their nodespaces, just as Web designers or FTP administrators are free to organise their directory structure in whatever manner they desire. Using a hierarchical approach and grouping nodes under logically related parent nodes is recommended, however, to allow easy access to information.

Whether you use an approach like SACP or another agent communication mechanism, remember that ease of use for the developer is important. Organizations will have different levels of experience, so you need to strike a balance between ease of use and functionality.

 Text and Binary Data Exchange

SACP supports reading and writing of both textual information and binary data. This is extremely important, because agents that are limited to exchanges of text data can't transmit rich multimedia, persistent objects, or application files such as documents. Versatile agent communication mechanisms should support binary data, because this type of data is extremely useful for other agents. Not all agent communication mechanisms will support binary data, however, and you should be aware of this limitation if your agents will communicate non-textual information.

 Message Passing/Queries

While exchange of data is a vital function of any agent communication mechanism, there are more advanced forms of communication. Message passing, for example, allows an agent to send a request to another agent, rather than a request for information. The distinction is important, because many languages and protocols use a fixed set of commands for exchanging information, as opposed to communicating intentions or requests to perform services. Queries are another way of executing commands, and can make transactions more efficient by performing searches on the server side (rather than an agent requesting all information and performing a manual search).

Not all agents will require these features, but it is important for many classes of agents. If you intend to have one agent commanding another to execute commands, or perform searches, you should consider using an agent communication mechanism that supports message passing or queries.

Other alternatives include distributed systems technologies, like remote procedure calls (RPC), remote method invocation (RMI) and the Common Object Request Broker Architecture (CORBA). By making procedure calls, or invoking object methods, message passing and query mechanisms can be written. If you choose an agent communication mechanism without these features, it is possible to implement your own.

 Implementations Available

Many agent communication languages and protocols are platform-neutral, but do not yet have implementations available for a wide range of platforms. You need to carefully evaluate your project needs (both now and for the future), to determine which platforms your agents will run on. Now, for many projects, a single platform will suffice, but if your agents are going to be long-lived, you may want to consider whether you're locked into a specific platform.

Many agent implementations are written in Java, because of its "write once - run anywhere" ability. Java code can be executed on any platform that supports a Java Virtual Machine (JVM), without the need for recompilation. Java is an excellent choice for developing agent applications, because of its rich networking support and the solution to application portability it offers.

That said, Java may not always be appropriate if you have legacy systems you need to "agentify". If your legacy system is written in an older language (e.g - C, Pascal, Ada, Cobol) then connecting a Java agent may pose some difficulty. Furthermore, if your strengths lie in another language, you may wish to choose a non-Java approach. In this case, a language or protocol rather than a language-specific agent framework may be your best bet, as you can write a new implementation in your language of choice.

 Summary

Developers of software agents should be mindful of the need to support some form of agent communication. Agents that work co-operatively can share access to resources (such as information or knowledge), as well as contributing towards a common goal. By designing agents to perform specialized tasks, and to work co-operatively with other agents, system complexity can be reduced. Sharing a common form of communication is vital to the success of agent cooperation, and there are many solutions available to bridge the communication gap. However, developers should be aware of their needs, and evaluate a range of solutions before any choice is made.

 Resources

Java Remote Method Invocation (RMI), http://java.sun.com/products/jdk/rmi/index.html

Simple Agent Communication Protocol (SACP) http://www.davidreilly.com/sacp/

David Reilly is a Sun Certified Java Programmer, and postgraduate student at Bond University, Australia, and is currently completing an Honors degree in Software Engineering. He is currently researching software agent communication, and developing a simplified agent communication protocol (SACP). Details of the protocol and a Java implementation of SACP can be found at http://www.davidreilly.com/sacp/.