Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Agents talking to agents

Find out how to get agents to talk to each other -- simply, efficiently, and reliably

By Todd Sundsted, JavaWorld.com, 09/01/98

Communication is the backbone of organization. This is true of ants, of people, and, of course, of agents. The reason communication is so important is that it allows individuals to organize into groups with a shared purpose and to operate much more efficiently. An organization is much more (and more effective) than the sum of the individual parts. (Just look at any political or corporate entity and you'll see what I mean.) There's even a word -- synergism -- that describes this property of organizations. And it all begins with communication.

With this thought in mind, let's take a look at three mechanisms agents might use to communicate.

Communication mechanisms

Communication is just as important in the realm of software as it is in the realm of animal life. Whether the entities in question are threads, subroutines, processes, or agents, they usually find themselves in the position of needing to share data (or communicate) with others of their kind.

Consequently, the field of computer science has produced a number of mechanisms to enable communication. I've selected three of the most common. I'll describe them, present their strengths and weaknesses, and then explain why I eventually selected the mechanism I did.

The procedure call mechanism
The first mechanism is known as the procedure call mechanism. It came into being at almost the same time as the first modern programming languages. It's simple and effective. It works like this:

The procedure call mechanism

Assume entity A needs the services of entity B in order to carry out its purpose, and B in turn needs the services of entity C in order to fulfill its obligation to A.

Entity A begins by asking entity B to do something. It then waits for entity B to do it. Entity B works for a while and then realizes it needs something from entity C. It asks entity C for what it needs and waits for entity C to fulfill the request. As programmers we see this occur in all its glory whenever we call a procedure (or subroutine or function or method).

The procedure call mechanism is fast and (because of its sequential nature) makes it easy to follow a program's flow of execution. However, it's also inherently synchronous and difficult to parallelize.

Java's remote method invocation (RMI) system is based on the procedure call mechanism.

The callback mechanism
Now we'll shift to the other end of the spectrum and look at the callback mechanism. It works like this:

The callback mechanism

This scenario is similar to what we saw with the procedure call mechanism; however, instead of asking for something and then waiting for it, entities A and B ask for something and then continue on with their tasks. When entities B and C have done whatever they were asked to do, they call back the original caller and give it what it asked for. The original caller must stop what it's doing and deal with the callback. If you've ever written windowing code, you've used callbacks before.

The callback mechanism is useful because it permits truly asynchronous processing. However, it's also complicated, and makes the program's flow of execution more difficult to follow.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.