Objects and Agents: How Do They Differ?

Just how different are objects and agents? Some developers consider agents to be objects, but with more bells and whistles. This approach tends to define agents beginning with the phrase, "An agent is an object that..." where the definers add their favorite discriminating features. Then there are those who see agents and objects as different even though they share many things in common. Both approaches envision using objects and agents together in the development of software systems. This article discusses the differences and similarities between agents and objects, and lets you decide which viewpoint to choose. Whichever you do choose, I hope you will find that the agent-based way of thinking provides a useful and important perspective for system development.

EVOLUTION OF PROGRAMMING APPROACHES
Figure 1 illustrates one way of thinking about the evolution of programming languages. Originally, the basic unit of software was the complete program where the programmer had full control. The program's state was the responsibility of the programmer, and its invocation was determined by the system operator. The term modular did not apply because the behavior could not be invoked as a reusable unit in a variety of circumstances.

As programs became more complex and memory space became larger, programmers needed to introduce some degree of organization to their code. The modular programming approach employed smaller units of code that could be reused under a variety of situations. Here, structured loops and subroutines were designed to have a high degree of local integrity. While each subroutine's code was encapsulated, its state was determined by externally supplied arguments, and the subroutine gained control only when invoked externally by a Call statement. This was the era of procedures as the primary unit of decomposition.

In the next evolution, object orientation added to the modular approach by maintaining its segments of code (or methods) as well as by gaining local control over the variables manipulated by its methods. However, in traditional OO, objects are considered passive because their methods are invoked only when some external entity sends them a message.

Software agents have their own thread of control, localizing not only code and state but their invocation as well. Such agents can also have individual rules and goals, making them appear like active objects with initiative. In other words, when and how an agent acts is determined by the agent itself.

Agents are commonly regarded as autonomous entities because they can watch out for their own set of internal responsibilities. Furthermore, agents are interactive entities capable of using rich forms of messages. These messages can support method invocation—as well as informing the agent of particular events, asking something of the agent, or receiving a response to an earlier query. Finally, because agents are autonomous, they can initiate interaction and respond to a message in any way they choose. In other words, agents can be thought of as objects that can say "No"—as well as "Go." Due to the interactive and autonomous nature of agents, little or no integration is required to physically launch an application. Van Parunak summarizes it well: "In the ultimate agent vision, the application developer simply identifies the agents desired in the final application, and they organize themselves to perform the required functionality."1 No centralized thread or top-down organization is necessary because agent systems can organize themselves.

OBJECT/AGENT BOUNDARIES
Before proceeding, note that OO technology can be extended in various ways to support many of the properties ascribed to agents. In fact, much of the current work on UML includes these notions. For example, the UML > and > stereotypes can be considered active objects. The point here is that the agent-based approach is an extension of how we think in an OO world—just as OO was an extension to the modular programming world. Yes, objects could be used to support the agent-based approach, just as any modular language (e.g., C or COBOL) could be used to write OO code. So, why not just write in C and forget about C++ or Java? The answer lies in building on what we know to provide another way of thinking about systems and their implementation. Agents, then, are an evolution rather than a revolution.

I will explain those aspects of agents that are different from the conventional OO approach (i.e., the way OO is commonly practiced and supported by most OO languages, e.g., C++ and Smalltalk). Different here does not mean bad or good—only different. In the end, you might conclude that agents are really just objects++, or that agents and objects are different but can peacefully coexist and even support one another in the same system. Either way, the agent-based way of thinking brings with it a useful and important perspective for system development. If we can imagine agents as a pattern for systems, we can avoid any of the OO vs. agents controversy and just get on with developing systems in a richer way. Both approaches are useful for IT development.

AGENTS ARE AUTONOMOUS
A key feature of agents is their autonomy; they are capable of initiating action independent of any other entity. However, such autonomy is best characterized in degrees rather than simply being present or not. To some degree, agents can operate without direct external invocation or intervention.

Dynamic autonomy
Autonomy has two independent aspects: dynamic autonomy and nondeterministic autonomy. Agents are dynamic because they can exercise some degree of activity. As illustrated in Figure 2, an agent can have some degree of activity, from being simply passive to entirely proactive. For example, while ants are basically reactive, they still exhibit a small degree of proactivity when they choose to walk, rest, or eat. A supply-chain agent can react to an order being placed and keep its list of suppliers up to date proactively.

GM paint booths are treated as agents. Here, information about an unpainted car or truck coming down the line is posted in an automated form that is accessible to all paint booths. When a paint booth nears completion of its current job, it basically says, "Hmmm, I'm running out of work; I'll look over at the jobs posted." If the booth is currently applying the color of paint required by an upcoming job, it will bid more for the job than a booth applying a different color. Other bidding criteria could include how easy or how important the job is. In a top-down, planned, push-through world, if one booth malfunctions, the plan would require immediate recomputing. With bottom-up, pull-through paint booth agents, there are other booths to pick up the bidding slack at a moment's notice.2

Agents can react not only to specific method invocations but to observable events within the environment as well. Proactive agents will actually poll the environment for events and other messages to determine what action they should take. To compound this, in multiagent systems, agents can be engaged in multiple parallel interactions with other agents—magnifying the dynamic nature of agents. In short, an agent can decide when to say "Go."

Objects, on the other hand, are conventionally passive, with their methods being invoked under a caller's thread of control. Here, the term autonomy barely applies because method invocation depends solely on other components in the system. However, UML and Java have recently introduced event-listener frameworks and other mechanisms to allow objects to be more active. In other words, objects are now capable of some of the dynamic capability of agents.

Unpredictable autonomy
Agents may also employ some degree of unpredictable (or nondeterministic) behavior. When observed from the environment, an agent can range from being totally predictable to completely unpredictable (see Fig. 2). For example, an ant that is wandering around looking for food can appear to be taking a random walk. However, once pheromones or food is detected, its behavior becomes reasonably predictable. In contrast, it is difficult to predict which GM paint station will paint which vehicle. The behavior of a shopping agent might be highly unpredictable. Giving it criteria for a gift will not predict exactly which gift it will choose. In fact, the agent might return empty-handed because it did not find any gifts that matched the criteria. In other words, the agent can also say "No."*

Conventional objects do not have to be completely predictable, but the typical usage and direct support with OO languages tends toward a more predictable approach. For instance, when a message is sent to an object, the method is predictably invoked. Yet, an object may determine whether or not to process the message and how to respond if it does. However, in common practice, if an object says "No," it is considered an error situation; with agents, this is not the case.

Usually, object classes are designed to be predictable in order to facilitate buying and selling reusable components. Agents are commonly designed to determine their behavior based on individual goals and states as well as on the states of ongoing conversations with other agents. While OO implementations can be developed to include nondeterministic behavior, this behavior is a fundamental characteristic in agent-based thinking.

Agent behavior can also be unpredictable because the agent-based approach has a more opaque notion of encapsulation. First, an agent's knowledge can be represented in a manner that is not easily translated into a set of attributes. Even if an agent's state were publicly available, it might be difficult to decipher or understand. This is particularly true when the agent involves neural networks or genetic structures. You can look at it, but you can't always understand what you see.

Second, the requested behaviors that an agent performs may not be publicly known within an active system. This is a clear distinction from object systems, because current OO languages only let you ask an object what interfaces it supports. Because the programmer needs to have some idea of what interface to ask for, this makes coding difficult. In OO, there is no provision in current languages for an object to advertise its interfaces. In contrast, an agent can employ other mechanisms, such as publish/subscribe, protocol registration, and yellow page and white page directories. Another common mechanism provides specialized broker agents to which other agents can make themselves known for various purposes, but otherwise remain unlisted to the rest of the agent population.

Finally, the underlying agent communication model is usually asynchronous. This means that there is no predefined flow of control from one agent to another. An agent may autonomously initiate internal or external behavior at anytime, not just when it is sent a message.3 Asynchronous messaging and event notification are part of agent-based messaging systems, and agent languages need to support parallel processing. These are not part of the run-of-the-mill OO language. Those that require such functionality in an OO system typically layer these features on top of the object model and OO environment. The agent model, then, explicitly ties together the objects (data and functionality) with the parallelism (execution autonomy, thread per agent, etc.). According to Geoff Arnold of Sun Microsystems, "Just as the object paradigm forced us to rethink our ideas about the proper forms of interaction (access methods versus direct manipulation, introspection, etc.), so agents force us to confront the temporal implications of interaction (messages rather than RMI, for instance)."

Agents are Interactive
Interaction implies the ability to communicate with the environment and with other entities. As illustrated in Figure 3, interaction can also be expressed in degrees. On one end of the scale, object messages (method invocation) can be seen as the most basic form of interaction. A more complex degree of interaction would include those agents that can react to observable events within the environment. For example, food-gathering ants don't invoke methods on each other. Their interaction is indirect through direct physical effects on the environment. And, most complex, in multiagent systems agents can be engaged in multiple, parallel interactions with other agents. Here, agents can act as a society.

One method per message
An object's message may request only one operation, and that operation may only be requested via a message formatted in a very precise way. The OO message broker has the job of matching each message to exactly one method invocation for exactly one object.

Agent-based communication can also use OO method invocation. However, the demands that many agent applications place on message content are richer than those commonly used by object technology. While agent communication languages (ACLs) are formal and unambiguous, their format and content vary greatly. In short, an agent message could consist of a character string whose form can vary yet obeys a formal syntax, while a conventional OO method must contain parameters whose number and sequence are fixed. Theoretically, this difference in message requirements could be handled with an OO environment by splitting the world into two portions: one including messages for which we have conventional methods, and another including messages that we send as strings.

To support string-based messages in an OO language, you could either anticipate every possible variation by supplying a specialized method for each or use a general utility AcceptCommunicativeString method. The AcceptCommunicativeString method, then, could cover the multitude of services that an object might handle. However, with just a single method, the underlying services would not be part of the published interface. In the traditional OO environment, such an method would be both boring and not very forthcoming. In agent-based environments, agent public services and policies can be made explicit through a variety of techniques.

ACLs
Because we may wish to send a message to any (and every) agent, we need the expressive power to cover all desired situations-including method invocation. Therefore, an ACL is necessary for expressing communications among agents—and even objects. The ACL syntax could be specially crafted for each application but the lack of standardization would quickly result in a Tower of Babel. Two applications could have difficulty interacting with one another; for an entire organization, it would be totally impractical. Standard ACL formats, then, would be desirable. Two of the most popular general purpose ACLs are KQML (www.cs.umbc.edu/kqml/) and the FIPA ACL (www.fipa.org). These ACLs communicate agent speech acts, specify ontologies, and participate in discussion patterns called protocols.

Conversations and long-term associations
Another way in which agent interaction can be more than just method invocation is that agents can be involved in long-term conversations and associations. Agents may engage in multiple transactions concurrently, through the use of multiple threads or similar mechanisms. In an agent messaging environment, each conversation can be assigned a separate identity. Additionally, either a unique message destination or a unique identifier can be used to sort out the threads of discourse. Conventional OO languages and environments have difficulty supporting such a requirement, directly or indirectly. Note that objects could be used for the elements of agent conversation, including the conversation itself. In other words, agents can employ objects for those situations requiring entities with little autonomous or interactive ability.

Third-party interactions
Geoff Arnold has considered the question of third party interactions, which are very hard for strongly typed object systems to handle. Here, two patterns come to mind. The first pattern involves a broker that accepts a request and delegates it to a particular service provider based on some algorithm that is independent of the type of service interface (e.g., cost, reachability). The second involves an anonymizer that hides the identity of a requester from a service provider. Models based on strong typing, such as CORBA, RMI, and Jini, cannot easily support these patterns.

Conclusion
Agents employ some of the mechanisms and philosophies used by objects. (A more complete treatment is found in Agents (Part 2): Complex Systems.4) In fact, many software developers strongly advocate composing agents from objects, building the infrastructure for agent-based systems on top of the kind of support systems used for OO software systems. Many structures and parts of agents can be reasonably expressed as objects. These might include agent names, agent communication handles, agent communication language components (including encodings, ontologies, and vocabulary elements), and conversation policies.

In multiagent systems, an additional layer of software components may be naturally expressed as objects and collections of objects. This is the underlying infrastructure that embodies the support for agents composed of object parts. For example, this layer might include communication factories, transport references, transport policies, directory elements, and agent factories.

Agents are autonomous entities that can interact with their environments. Many believe that objects and agents are distinct enough to be treated differently. When we design systems, we can choose a well thought-out mixture from both the OO and agent approached. We can even build aggregates where agents consist of both objects and other agents and vice-versa. For Grady Booch, the reasons to use agents are clear.

Agents are important/useful because

  1. they provide a way to reason about the flow of control in a highly distributed system,
  2. they offer a mechanism that yields emergent behavior across an otherwise static architecture, and
  3. they codify best practices in how to organize concurrent collaborating objects.

References

  1. Parunak, H. V. "Go to the Ant: Engineering Principles from Natural Agent Systems," Annals of Operations Research, www.erim.org/~vparunak/papers.htm, pp. 69–101, 1997.
  2. Morley, D. "Cases in Chaos: Complexity-Based Approaches to Manufacturing," Embracing Complexity, Ernst & Young Center for Business Innovation, Boston, MA, pp. 97–102, Aug. 1998.
  3. Wooldridge, M., N. R. Jennings, and D. Kinny. "The Gaia Methodology for Agent-Oriented Analysis and Design," Autonomous Agents and Multi-Agent Systems, forthcoming, 2000.
  4. Odell, J. Agents (Part 2): Complex Systems, Cutter Consortium, Executive Report 3(6), 2000.

FOOTNOTE
* The FIPA (http://www.fipa.org) agent standards organization states that all agents must be able to handle all messages that they receive. An agent may choose various actions, such as to respond in a manner of its choosing, to decide that the request is outside of its competency, to ignore the message because it is not well-formed, or to just refuse to do it on various grounds.

Most   Popular