The Agent Grid

The Agent Grid: A Software Framework for Building Massively Distributed Autonomous Systems

Larry Suarez Grid Research Group Agent Net, Inc.

Abstract

Software solutions that deal with highly distributed artifacts1 have traditionally been very difficult to construct. Naturally distributed domains include air traffic control, transportation, military battlespaces, supply chains, and massively multiplayer online games (MMOG). But with the ubiquitousness of computing today, even traditionally localized domains are becoming distributed. For example, tracking and reacting in real-time to national product usage or national consumer product preferences. Solutions need to manage and control thousands of artifacts and require a myriad of technology. And these domains are constantly changing while rapidly outdating static solutions. There are no available frameworks for building massively distributed autonomous systems. And there are no frameworks that support solutions that socialize and evolve with the domain. The Agent Grid represents an attempt at creating a software framework for quickly building massively distributed autonomous systems.

This paper will present a cursory description of the Agent Grid software framework. The framework has been implemented and deployed in a number of test environments. Although the basis for the Agent Grid is not new to researchers, the technology will be new to most software developers. The Agent Grid is meant to be used as a valid framework for commercial solutions but also as a tool to foster further discussions on frameworks for massively distributed computing.

There were three driving goals for the Agent Grid beyond providing a framework for constructing distributed solutions:

1. Constructing Agents must be easy, quick, and rapidly deployed. No deployment XMLs, location requirements (special file directories), or any required ancillary processes.

2. Software behaviors (contents of an Agent) must be easily constructed and deployed by developers with only basic skills. Skills in robotics, artificial intelligence, agent-based systems, or massively distributed processing are not required.

1 Vehicles, hand-held devices, military hardware, aircraft, workers, sensors.

The Agent Grid 2

Agent Net, Inc. 3/7/2010

3. The construction and augmentation of Agents through the process of cobbling is the primary goal of the framework. Cobbling is defined as the building of Agents through the use of existing behaviors. Cobbling may be a human effort (end-user or software developer) or it may be automated as defined in this paper.

The Agent Grid is a software framework designed to allow software developers to easily construct massively distribute autonomous systems. The Agent Grid is viewed simply as a collection of software constructs called “Agents” which are autonomous, evolve, and work together to form solutions. Solutions built on the Agent Grid typically model one Agent per artifact where the Agent manages, controls, and augments the artifact. For example, an Agent may represent an aircraft. The Agent would maintain information about the aircraft (fuel, passengers, armament) and be able to change the behavior of the aircraft (turn left 30 degrees). Agents essentially create a virtual world where they live and communicate on behalf of their real-world counterparts. Realize the Agent Grid does not mandate that an Agent have a corresponding artifact in the real world. Agents may represent logical entities such as an algorithm or processing step.

There are many aspects of massively distributed domains that make solutions difficult to construct:

Decentralized information, data, and artifacts. This includes data which cannot be

relocated or collected into one central location because of data size, data ownership, or data security. Domains also typically include hundreds if not thousands of artifacts that must be managed and controlled.

Involving numerous, disparate 3rd party systems. These systems contribute to

the domain and must be integrated into the overall solution.

Dynamic, changing environments. Includes environments where new artifacts are

being added or removed from the environment. For example, a testing laboratory where test machines go down or machine operators become sick. Or transportation which is effected by weather systems, traffic congestion, and traffic accidents.

Agent technology, the core of the Agent Grid, has been researched for well over 30 years and currently drives a number of advanced real-world solutions such as air traffic control, autonomous vehicles (space, marine, and air), and transportation. As shown in Figure 1: Agent Grids and Existing Technology, the Agent Grid brings together a number of technologies into one consistent model to solve these types of problems. In most software frameworks today, each of the technologies is a distinct feature set added to the solution resulting in a hodgepodge of terminology, tools, and staffing requirements.

The Agent Grid 3


Figure 1: Agent Grids and Existing Technology

Agent Grids are not meant to be a replacement for technologies such as web servers, application servers, or other frameworks such as Apache Hadoop, Sun JXTA or the Globus Toolkit. Agent Grids are merely part of the evolution of software solutions. Many types of solutions will co-exist. Certainly customers will make decisions as to whether to use an Agent Grid as oppose to a traditional n-tier solution. Agent Grids were designed to be incorporated into existing environments. And customers can view Agents merely as software services if they find that more convenient. Customers require that new technologies such as the Agent Grid be able to leverage off their existing expenditures including software developer skills, computer hardware, and computer software.

Advantages

Research into agent-based systems encompasses advanced areas such as robotics, artificial life, and complex systems. The aspects of Agents that have attracted researchers for years are just as attractive to business solutions and include:

Natural way to model solutions. Solutions are modeled based on the

environment or organization as oppose to programming-based modeling (objects).

Agents are very flexible. They can change capabilities in real-time, can adapt,

and have learning capabilities. This is a tremendous benefit towards supporting automation or what we term Agent Oriented Social Computing.

Provides a new paradigm for developing solutions. Developers today

predominately write software code to be placed into application servers. They may have choices as to how to deliver the code (Java Beans, Java Servlets, .Net) but the paradigm remains the same. Agents introduce new ways to design code solutions which allow more creativity and novel solutions. We have just scratched the surface on how to construct agent-based solutions.

Autonomous management of services. Agents can be placed in front of

services (such as a software service or even physical device) to provide service-related features and autonomous management.

Agent-based Workflows. Agents can participate in business processes as

“workers”. Agent-based autonomous workflow is a major area of research.

The Agent Grid 4


Social. Agents can be organized into different control structures where needed.

The architectures are based on the environment not the type of computing solution available. A traditional client-server solution has only one control structure: client-server. The different architectures allow us to distribute the specific control behaviors out to the individual Agents where they belong as oppose to composing all the behaviors into one local server.

Multiple solution views. Agents can model the environment in a number of

ways. Processes within the environment can be decomposed into functional units where an Agent is assigned to each functional unit. For example, an Agent could be responsible for populating a SAP database for billing purposes. Processes within the environment could also be broken down into physical units where an Agent is assigned to each physical unit. For example, an Agent could be responsible for all software access to a person or test workstation.

The Agent + Grid

The Agent Grid consists of two major concepts: Agents and Grids. The Grid represents the software infrastructure used to allow Agents to communicate with one another and maintain their world models. The Grid is known in the industry as middleware. Agents are the “services” that execute on the Grid. Separating the two concepts allows software developers to concentrate on the design of their Agents while letting the framework handle the distributed aspects. This “separation of concerns” is required to ensure the acceptability of the framework by developers. The separation also allows replacing the Grid infrastructure with other 3rd party solutions such as the Globus Toolkit without reducing the effectiveness of the framework.

The Grid

A grid is a distributed software solution focusing on the integration, virtualization, and management of services. Grids tend to differ from conventional distributed computing by concentrating on issues that involve:

Crossing institutional boundaries. In other words, solutions requiring multiple institutions, organizations, or business units.

Sharing and management of resources such as software applications, physical devices, or employees.

Virtualization of resources so participants are unaware of the physical aspects of a resource which includes its location, size, and protocols.

The peer-to-peer architecture has gained a deal of notoriety in the past ten years. A peer-to-peer architecture is one in which there are no specific servers servicing the participants on the network. Grids are naturally peer-to-peer solutions. Participants are not required to visit a particular server on the grid to access services. This is in contrast to architectures such as client-server where there exists a server that must be visited to acquire a service. Web Servers are an example of a client-server solution. Peer-to-peer architectures are typically used when the services or data tend to be naturally distributed and coalescing the services or data onto one host system would be impractical and often impossible. This will be the case when the participants are distinct organizations often representing different vendors. Requiring vendors to move their data, processes, and

The Agent Grid 5


software to a central location would be very difficult. A point to remember when reading the material in this paper is that the Agent Grid is a distributed software system employing the peer-to-peer architecture. Each Agent on the Agent Grid can communicate with any other Agent on the Grid without having to go through a central server.

Agents

So what is an Agent? Agent technology had its start in the studies of Artificial intelligence. Research into how the human mind functions led to computing research in modeling some of the basic tenets of the mind. An initial definition is that an Agent is simply a software container of behaviors much like our minds are a container of behaviors. The goal of Agent technology research is geared towards mimicking the way the human mind manages its behaviors. This includes defining how behaviors move from the subconscious (non-executing) to consciousness (executing). Figure 2: Agent Reacting to its Environment (Server Down) shows the basic principle of Agent execution. In the figure, an Agent maintains a pool of behaviors which are not executing. This is much like our subconscious. If a change occurs within the world of the Agent, such as a server going down, the Agent determines if the change causes a reaction. In this case it does and the behavior “Alert IT” moves out of the behavior pool into the execution pool. It’s interesting that humans are not necessarily aware of what changes trigger a reaction (behavior execution) which leads to surprising behaviors within ourselves (i.e. “...I did not know I would react like that.”).

Figure 2: Agent Reacting to its Environment (Server Down)

Notice that this mechanism is different from the current programming world where software is “invoked” and there is a tight coupling between the request and the software being invoked. If either changes, the coupling fails and a service cannot be provided. In Agent technology, behaviors are not invoked. There is a loose coupling between the change in the environment and the reaction. And the coupling can be manipulated at any time and the Agent will still function. For example, with a little training a human could be taught to change the stimulus of a “flee-danger” behavior so that they can function in dire situations such as would be the case for firemen or policemen. A fireman never loses

The Agent Grid 6


that “flee-danger” behavior but rather another competing behavior such as “save life” is brought into consciousness in its place.

Behaviors are the basic building blocks of Agent actions. Behaviors are small, succinct pieces of software code which contribute to a task or goal. They are inherently modular to allow behaviors to be added, subtracted, or shared from an Agent at any time. For example, an Agent may represent a forklift and has behaviors such as “turn left”, “turn right”, and “move forward”. There are a number of differences between a traditional software server executing chucks of code and an Agent. Agents are designed to mimic the human mind and how it functions. This includes how the human mind “executes” human behaviors such as opening a door, taking a step, and fleeing danger. The human mind does not execute behaviors in the same fashion as an Application Server would execute services.

The Service Oriented Architecture Computing Model

A major area of interest in the computing arena is distributed applications based on the computing model called Service Oriented Architecture (SOA). An SOA views all resources on the network (CPU, storage, applications, etc.) as services which are available for use. A service provider makes the services available for access over the network. The idea is to provide a loose coupling between the services so that callers are only concerned with the functionality of the service and not the details of how the service is constructed. SOA systems are still based on the communication style of request-response where a request to a service should involve a response from that service given that the caller uses the correct protocol. There is a consensus among the computing establishment that the SOA computing model is the future for building distributed applications.

The SOA computing model is a one dimensional system. It merely defines the protocols that are used to communicate with individual services. The model does not support any relationships or dependencies between services which the model defines as its strength. Services are viewed as distinct and disjoint. However, this simplicity is forcing vendors and solution providers to build additional capabilities on top of SOA systems to truly solve industry problems. For example, event-based systems and workflow systems are added to allow designers to create business processes that are reactive to the events that occur within an organization. There is no doubt that the SOA computing model will be expanded to encompass these features since all solutions will need some form of those capabilities. But currently the additional capabilities are being added outside the scope of the computing model and hence users and developers have to digest a number of computing models within a single business solution.

The basic premise of the SOA computing model is to provide services that are available for re-use and for the ability to replace like-services on the basis of constraints such as cost. Hence, a vendor will provide services that are available for use on the network in exchange for some nominal fee.

The Agent Oriented Architecture Computing Model

The Agent Oriented Architecture (AOA) computing model shares many of the capabilities of SOA. In AOA, Agents provide goals derived from their many behaviors. In

The Agent Grid 7


SOA, a user requests a service from a service provider. In AOA, a user requests a goal to be achieved from the Agent. There is no guarantee that the Agent will accomplish the goal or even respond. This is the case even when the Agent advertises the goals it is able to accomplish. The reason for this style of computing is that an Agent is designed to be autonomous and to maintain some form of decision processing. An Agent may acquire additional goals over time. A human may be asked to run up a hill (service) but would not do so if a hungry lion happens to be sitting on top of that hill. SOA systems do not use decision processing in providing their services. They merely provide a set of services. So Agents provide the ability to define some form of coupling between “services” ranging from no coupling to very tight coupling.

Whereas SOA services do not share data, Agents can share a world model. A world model is a description of the world as it is known to the Agents on the grid. A world model may describe a room, an organization, a city. This is a natural reflection on how humans are able to function together. An individual may provide distinct “services” but all humans share a world framework otherwise it would be impossible for humans to construct societies and civilizations. Finally, AOA is designed to be peer-to-peer systems as oppose to client-server systems which is the case with SOA.

Agents

There are many industry definitions of an Agent. The definitions are usually dependant on the system supporting the Agent. Standard bodies have provided some clarity to the definition of Agents but primarily in Agent communication only. Our discussion of Agents is based on the Agent Grid as defined in this paper.

It is well known among researchers that real-world complex systems exist which are constructed from simple entities using a very limited number of skills or capabilities (for example, ant colonies). Agent-based solutions are based on that premise. Those core capabilities which are found in an Agent include:

Adaptable. Ability of the Agent to change over time to match its environment.

Without adaptability, the Agent would soon become useless in a dynamic environment. Agents can change their behaviors and world models to fit their environment.

Reactive. Ability of the Agent to react to changes in its environment. Reaction is

the core capability that enables an Agent to change over time. And its ability to service other Agents.

Social. Ability of the Agent to engage with other Agents to form structures such

as processes, societies, and organizations with the purpose of solving problems.

Deliberative. Ability of the Agent to construct sequences of behaviors (plans) to

execute complex tasks. In addition, the ability to manipulate the sequences (add and remove behaviors) during execution.

Autonomous. Ability of the Agent to execute without control or direction simply by

using its environment (stigmergy).

Another powerful aspect of Agents is that they are small, succinct entities that can be constructed by anyone participating in the environment. Hence, a third party vendor,

The Agent Grid 8


system integrator or channel partner can construct, deploy, and manage their own Agents while participating in an overall business solution.

Just as the case with human behavior, Agent behaviors are not directly visible to the outside world. In humans we only see the results of our behaviors. When we throw a ball, we are only seeing the results of the behaviors which control our arms, legs and hands. To get another individual to answer a question on fishing, we pose the question and wait for a response. A response indicates that either the individual does have “fishing” knowledge or that the individual needs further instructions (“what kind of fishing?”). There is a loose coupling between goals required by a client (e.g. questions on fishing) and the actual behaviors of an individual. Human’s react to events: a question being asked, a car honks its horn, a closed door blocking our way. These events change our view of the world. Change an individual’s view of the world and a behavior is elicited as a result. How do you elicit a “salute” behavior from a soldier? Merely change their world by standing in front of them wearing a type of military uniform. It was the task of the soldier’s Drill Sergeant to “develop” the salute behavior in the soldier’s mind and adding the trigger that stipulates when it should be executed. From this discussion, we can see that a behavior needs a model of the world, a trigger to bring the behavior into consciousness, and a definition of what the behavior is to accomplish (its intention).

An Agent has the following major components:

Behaviors.

Sequences

A world model.

Triggers which elicit a behavior.

Figure 3: Agent Components shows the relationship between the Agent components for an Agent representing a forklift operating on a shop floor.

Figure 3: Agent Components

The Agent Grid 9


World Model

Each of us maintains a model in our mind of the world we live in. The model describes the world as it is known to us, filtered by biases, experiences, and culture. Sometimes the model becomes distorted or skewed. This model drives every behavior that we maintain and exhibit. Two individuals may have the same world model but each reacts differently by exhibiting different behaviors. Or they may have the same behaviors but different world models which also affect which behaviors are exhibited. This is what makes us unique. Without this world model, humans would not be able to function since the model drives our behaviors. An Agent also maintains a model of its world. It is the responsibility of the Agent designer to define the world model of an Agent. Agents have the ability to augment or restrict their own world model at any point in time. And Agents have the power to augment or restrict the world model of each other. This is part of the learning capabilities of an Agent. Figure 4: Robotic Vacuum's World Model shows an example world model (room) for an Agent controlling a robotic vacuum cleaner. Interestingly, some commercial robotic vacuum cleaners do not maintain a world model.

Figure 4: Robotic Vacuum's World Model

World Model Conflicts

It cannot be expected that every human or Agent has the exact same world model. Humans are able to function very well even when their world model is incomplete. For example, suppose that I understand that a soccer ball has shape, size, and texture. But I don’t know that a soccer ball has a color. Now someone comes to me and asks if I have a green soccer ball. I could either not respond or utter a phrase such as “Do soccer balls come in colors?” A conversation would ensue in which my world model of a soccer ball would probably change to include color. This is part of learning. Now suppose that I understand about color and I am asked if I have a soccer ball (no specified color). I could either respond with “yes” or I could utter the response “will a green soccer ball suffice?” These interactions are part of the Agent fabric which separates Agents from other modeling facilities. World models may differ on two levels:

The Agent Grid 10


Syntax. This implies that two models differ syntactically. This may be merely a

versioning issue or similar Agent models defined by different individuals. In our example of soccer balls, our worlds match except one model defines “color” and the other define “ballColor”.

Semantic. This implies that two models differ on how they are semantically

modeling their world. In our example of soccer balls, one model may be describing color on a number of levels in which they are including shading and luminosity.

The resolution of differences between models of the two participating Agents is done at interaction time. In other words, the Agent Grid will try very hard to ensure that two Agents can affect work but it must ensure that both Agents should in fact be interacting. The Agent Grid does not want to force two Agents to interact that should not be interacting. From the resolution, the world model of both Agents may be affected.

Agent World Model

Within an Agent, the world model is represented as facts. For example, facts for an airport include:

Aircraft 591 taxiing on runway 51.

Aircraft 100 requesting permission to land.

Fire truck 111 at terminal 41.

Changes in the real world cause events that update an Agent’s world model. The facts may also represent the state of the Agent itself. For example, an Agent may represent an aircraft hence information about the aircraft (number of passengers, airspeed, and fuel level) is maintained in the Agent’s world model.

The actual representation of the world model is in the form of XML. For example, a fact about an aircraft would look as follows:

<aircraft><id>591</id><status>inFlight</status><fuel>20</fuel></aircraft>

An Agent designer would define the format of an aircraft fact as part of designing the Agent. The format is in the form of an XML schema. Clients who wish to update the world model of an Agent should use the XML schema of the Agent to submit facts. However, Agents are intelligent enough to discern minor differences and resolve issues concerning the format of facts when submitted by outside participants. The assumption is that some outside organizations will define the XML schemas so that all Agents will support well-known standard definitions of facts.

Behavior World Model

Behaviors can maintain their own world models. This allows a behavior to migrate from one Agent to another and still be able to function. In essence, each behavior is able to migrate and bring its own baggage. If this was not the case, a behavior would only be able to execute within the confines of one Agent and the Agent Grid would not be able to

The Agent Grid 11


support reusability. When an Agent starts execution, the world model of each of its behaviors is added to the Agent’s world model to create a single composite world model.

Stigmergic System

The Agent Grid is a stigmergic system. Stigmergic systems are self-organizing systems where the participants use their environment for management and control with limited interaction between the participants. Agents do not communicate directly with one another; they merely affect each other’s world model. Stigmergic systems are very adept at self-organization, self-tasking, and learning. When groups of fish school together it is a result of stigmergic communication as oppose to having one “managing” fish that instructs the other fish. Stigmergic systems do not have managing entities to control the organization. Ants are another great example of a stigmergic system where large colonies can organize without “managers” and with a very small set of behaviors. Figure 5: Stigmergic Forklift System shows two forklifts that are executing behaviors based on their environment and not by instructing each other. In other words, forklift B has run out of fuel but it does not broadcast a message to all other forklifts to stop their motors. In addition, neither Forklift A or B needs to understand the entire world around them (i.e. the entire shop floor). At minimum, they only understand the immediate area around them. This is a subtle difference from standard software systems and has a great impact in massively distributed systems where central control is impossible as well as complete knowledge about the entire world.

Figure 5: Stigmergic Forklift System

Agents request goals from other Agents by affecting the world model of the destination Agent. Figure 6: A Speech act results in an intention (start motor) shows the situation for our stigmergic forklift system. Forklift A does not instruct Forklift B to start its motor. It merely tells Forklift B that it needs its space on the shop floor. The intent is to have Forklift B start its motor and move but Forklift A does not express that explicitly. Forklift B is free to respond to the goal request in any way it finds feasible including not moving at all. As another example, a person may tell their roommate that “The Trash is piling up in the Kitchen” with the intention that the roommate should throw out the trash without actually requesting the roommate to throw out the trash. There are in fact numerous ways in which intent can be conveyed to an Agent.

The Agent Grid 12


Figure 6: A Speech act results in an intention (start motor)

Behaviors

Behaviors are software “chunks” of fairly succinct work. A behavior can be written in a number of programming languages including Java, Pearl, and C++. The Agent Grid supports two kinds of behaviors:

Reactor – models behaviors within the human body which do not require

conscious thought such as reflexes (involuntary reactions to stimulus). Reactor behaviors react to events within the environment. For example, “stop the car when an object is 5 feet away” or “start ceiling sprinklers when heat exceeds x degrees”.

Procedure – Behaviors which react to goal requests. For example, “stop forklift

engine” or “open door”.

Future releases may see additional types of behaviors. Supporting behavior types provides designers with greater latitude in designing software solutions. A designer can create a reactor behavior to service a critical event and let the system control the execution without having to define any further criteria. Behaviors are discussed in detail later in this document.

Sequences

A sequence is a description of behaviors and Agents which are executed in a pre-defined order. Sequences are also known as Agent-based workflows. Sequences allow an Agent to construct complex actions from simple behaviors. In the human mind, complex actions include “throwing a ball”, “exiting a room”. In the Agent world, complex actions include “find recharging station”, “load delivery vehicle”. In the Artificial Intelligence world, sequences are analogous to “plans” and “planning”. Sequences are the predominant construct for solving goals within an Agent.

The Agent Grid 13


Triggers

A trigger is essentially a description of what the real world must look like if a particular behavior is to be executed. For example, a trigger could be “rainfall of 4 inches” or “room temperature of 100 degrees”. The trigger describes the future state of the world as it is known by the Agent. Let’s take the airport example and assume that we have a world model fact as follows:

<aircraft><id>591</id><status>inFlight</status><fuel>20</fuel></aircraft>

As fuel is consumed, the aircraft sends an electronic message containing the current status of the aircraft. The values are extracted from the message received at a ground station, and the fact within the world model of the aircraft’s Agent is updated. There is a trigger defined in the Agent as follows:

(aircraft (id 591) (fuel <= 2))

The trigger says that when the fuel of the aircraft is less than 2, then trigger the

corresponding behavior. The behavior would undoubtedly generate the necessary events to ensure that the aircraft is properly warned and all the necessary arrangements are done to service the aircraft as soon as possible.

Designing an Agent

Designing an Agent involves four main steps:

Creating the Agent.

Defining the Agent’s world model format. This is accomplished using XML which describes the world model in the form of a schema.

Creating an initial real world model. These are the facts about the real world. For example, there is a chair, table, and picture in a room. An initial world model is not required in the design of an Agent. Other Agents on the grid as well as behaviors added to the Agent will contribute to the world model of your Agent.

Designing the behaviors and specifying the triggers for each individual behavior.

Behaviors, schemas, and world model facts can be added at any time during the existence of an Agent.

Agent Life Cycle

Once designed, an Agent must be revealed to be used. Revealing an Agent makes the Agent alive and makes the Agent’s behaviors available for execution. A revealed Agent can be later hidden which causes the Agent to cease living. Enhancements to the Agent’s pool of behaviors will persist once the Agent is hidden. However, changes to the Agent’s world model will not persist unless requested. An Agent is revealed when it is asked to achieve a goal or when the Agent is recruited for work. An Agent may be identified by either it’s grid-wide numeric identifier, its name-version-status string identifier, or via its classification (e.g. give me an Agent that adds two integer numbers).

The Agent Grid 14


Conversing with an Agent

So how does one communicate with an Agent and affect their world model? Messages are sent to the Agent via a number of protocols. Messages can be sent from software applications, from within Agent behaviors, from web browsers using URLs, or even emailed to an Agent. The messages contain speech acts. Agent communication is patterned off the theory of speech acts. Speech act theory provides a new dimension to how objects communicate on the Grid. Speech act theory tells us that communication is much more than mere request-responses. A request to a “service” in SOA is a pure pattern match between the request and the service provider’s interfaces. In Speech act, a request has more of an intention on the receiver (Agent). Communicating with an Agent involves a performative. This is a keyword recognized by an Agent to indicate an illocutionary act (the intentions of the speaker on behalf of the addressee). The following are some of the performatives recognized by an Agent:

Tell - indicates that the requester wants to add a fact to the world model of the

receiving Agent.

UnTell - indicates that the requester wants to remove a fact from the world model

of the receiving Agent.

Achieve - indicates that the requester wants the receiving Agent to achieve a

goal.

Ask-Health - indicates that the requester wants to know the health of another Agent.

Reveal - indicates that the requester wants an Agent to start living.

Messages to an Agent consist of a performative followed by data relating to the performative. For example, to indicate to an Agent that you wish to add a fact to their world model, the message would look roughly as follows:

TELL “<aircraft><id>591</id><status>inFlight</status><fuel>20</fuel></aircraft>”

If the message does not fit the Agent’s world model, the Agent merely ignores it.

As mentioned, the Agent Grid supports conversing with Agents using a web browser. The URL supports the expression of performatives, identification of the receiving Agent, and parameters that are part of the performative. Figure 7: URL Access to an Agent shows an example request to an Agent via a URL.

The Agent Grid 15


Figure 7: URL Access to an Agent

The “HomePage” goal is a well-known goal that is supported by all Agents. This paper will not detail the well-known goals of every Agent but suffice it to say that the “HomePage” goal generates a web page which describes all the goals of an Agent and the necessary web page forms to converse with that Agent. It is a very handy means of communicating with an Agent via a web browser.

The Agent Grid provides a Software Development Kit (SDK) to support developers who wish to converse with Agents via programming languages. The Agent Grid currently supports Java, C++, and Pearl. Figure 8: C++ Access to an Agent shows sample C++ code to request an Agent to achieve a goal.

Figure 8: C++ Access to an Agent

Behaviors

Behaviors serve as the basic building blocks of Agent. An Agent consists of a collection or pool of behaviors which execute in reaction to changes in their world model. For example, if a sensor for a robot detects heat, a behavior would execute to reduce any immediate damage to the robot. Or if a temperature sensor within a room indicates a potential fire, a behavior would execute to cause the overhead sprinklers to activate. Unlike static software systems where code is designed, implemented, and deployed, behaviors of an Agent may be added or removed or altered at any time. In addition, the triggers which determine when behavior executes can be manipulated at any time as well.

The Agent Grid 16


For those knowledgeable about object-oriented systems, behaviors may be thought of as methods while an Agent may be thought of as an object. However, their relationship stops there. Behaviors are much more powerful than methods and may migrate from Agent to Agent. Methods of objects are tied to the object to which they were designed because of their reliance on the state of the object. This does not hold for behaviors. This section will introduce the concept of behaviors and their construction.

Behavior Types

The Agent Grid supports two types of behaviors. Other types are expected in future revisions:

Reactor – models behaviors within the human body which do not require

conscious thought such as reflexes (involuntary reactions to stimulus). Reactor behaviors react to events within the environment. For example, “stop the car when an object is 5 feet away” or “start ceiling sprinklers when heat exceeds x degrees”.

Procedure – Behaviors which react to goal requests. For example, “stop forklift

engine” or “open door”.

Reactor Behaviors

Reactor behaviors are always active during the life of an Agent. They react to changes in the world model of the Agent. Reactor behaviors are designed to maintain constant vigilance over the Agent. Reactor behaviors correspond to reflexes within a human. A human reflex action bypasses all processing in the mind and responds directly to stimulus. Agent reactor behaviors are intended to bypass all “execution flow” processing in the Agent and execute immediately if triggered.

Designers constructing reactor behaviors should adhere to the following guidelines:

May not assume the existence of another specific behavior.

May not assume the order in which the behavior will be executed.

During execution of the behavior, the behavior may not wait for a response from another Agent. In other words, the behavior may not block waiting for a response. If the behavior must request work from another Agent, the behavior will submit the request and another behavior will be responsible for processing the response.

Procedure Behaviors

Procedure behaviors correspond to complex behaviors in humans. Complex behaviors in humans include sequenced actions such as saluting an officer, exiting a room, and throwing a ball. These behaviors in humans are not reflexes. They are behaviors specifically called upon when the world model in a human reaches a certain state. For example, the “exit the room” behavior would occur when a business meeting ends. Procedure behaviors in Agents are the same way. The behaviors may be a single behavior or a sequence of behaviors (workflow). A procedure behavior is said to provide

The Agent Grid 17


a goal. For example, a goal called “exit-the-room”. To initiate the behavior, a client would request that an Agent achieve a particular goal such as “I need to exit the room”. The relationship between the client request and the corresponding procedure behavior in an Agent is said to be loosely coupled. In other words, it should not be viewed as a service invocation where the service names are well-known and the service parameters of the behavior are well-known. However, the assumption is that the individual vertical industries (e.g. manufacturing, medical, etc.) will define strict naming for goals as they relate to their industry. It is up to the Agent designer to map well known goal invocations to the triggering of procedure behaviors. At times, it may be one-to-one. At other times, it may be quite complex. For example, a goal request of “Request an Ambulance” may result in the triggering of a procedure behavior call “dispatch Ambulance” for an Agent called “Jon’s Friendly Ambulance, Inc.”.

Default Execution Flow

When an Agent is first revealed (started), the behaviors of the Agent are placed in a pool. The behaviors are then ordered by priority, criteria, and any other characteristics defined by the Agent Grid system. Once complete, the behaviors are tested one at a time. If the current state of the Agent’s world model triggers a behavior, that behavior is executed to completion. The Agent then moves to the next behavior until all behaviors have had an opportunity to execute. The process is repeated continuously to include newly added behaviors and any changes to behavior priorities, criteria, or characteristics. The general execution flow is defined by the designer of the Agent Virtual Machine (AVM). The AVM is a software service that is responsible for defining the execution flow of the Agent. Other forms of execution flow are possible merely by providing a new AVM. AVMs will be introduced later in this paper.

Components of a Behavior

A behavior consists of the following components:

Body – behavior code executed by the Agent (default in Java but other

programming languages such as Pearl and C++ are supported). Future versions will allow web services to act as behavior bodies.

Triggering or activation – world model event that will cause the behavior to come

into consciousness. The event could be either real-world driven or created by another behavior (e.g. when dreams trigger behaviors such as running). Activation only applies to reactive behaviors.

Taxonomy / Classification – every trigger is defined within the context of a

taxonomy. Unless two Agents agree on a taxonomy, they cannot communicate effectively. For example, two individuals who come from different cultures will find it difficult to elicit specific behaviors from one another. In addition, a classification can be added to the behavior to ensure competition only among behaviors with the same classification. Sample classifications include “protective”, “exploration”, “foraging”, “walking”).

Coupler – descriptions that allow two behaviors to be coupled for the creation of

explicit behavior (deliberations). Couplers could be explicit specifications for a behavior or it could be part of the triggering or activation.

The Agent Grid 18


Goal – these are the changes made by the behavior to the external world or

internal world. The modifiers are used to trigger or activate other behaviors and are used by the couplers. The behavior is not complete until its goals are accomplished. These are essentially the “services” they provide. If a goal is to “authorize an inpatient treatment” then any other Agent requesting that goal from the Agent will recruit the Agent.

Long Term Memory – represent the beliefs of an Agent containing the behavior.

The content of long-term memory changes depending on the Agent to which the behavior belongs.

Short Term Memory – Short-term memory contains local or global variables for a

behavior. The assumption is that the behavior is well aware of the well-known names associated with short-term memory. Short-term memory is used to support the execution of a particular behavior and is not intended to persist longer that the life of a particular behavior.

Context or World Model – Agents have a defined world model but so do behaviors. The context or world model of a behavior defines a model specific to the behavior regardless of the bounding Agent. This allows the behavior to be shared among Agents. The behavior’s context is added to the Agent’s world model when the behavior is attached to the Agent.

Figure 9: Behavior Components shows the components of a behavior.

Figure 9: Behavior Components

The Agent Grid 19


Behavior Body

The body of a behavior is implemented using the Java programming language. Any industry Java IDE can be used to design a behavior. All behaviors consist of a class definition with a public static void method called Behavior. The class name is the name

of the behavior merely by convention. The method name “Behavior” must remain constant but all other parts of the Java class may be changed. For example, new methods and attributes may be added. In addition, new import declarations may be added. The following shows the basic behavior class definition for the behavior “SampleBehavior”:

import com.Agentnet.system.*;

import com.Agentnet.daplet.*;

import java.io.IOException;

import com.Agentnet.clips.*;

import java.io.*;

import java.util.*;

public class SampleBehavior {

public static void Behavior (int AgentId,

int callerHdl,

int behaviorId,

byte[] converseOid,

int context) {

}

}

The static method Behavior contains 5 parameters. The parameter list cannot be

changed by the designer however the parameter names may be changed to suit the designer.

AgentId - handle (identifier) of the Agent containing this behavior. Behaviors may

execute under a number of different Agents during its life. The parameter indicates the Agent under which this behavior is executing.

callerHdl - handle (identifier) of the Agent which caused the invocation of this

behavior. This handle can be used to respond to the initiating Agent.

behaviorId - handle (identifier) of this behavior. At times, the designer may wish

to retrieve further details of this behavior from the grid or may wish to change aspects of the behavior such as the behavior context.

converseOid - XML document containing any additional information required by

the behavior.

context - identifier used to get access to the world model of the Agent containing

this behavior. Allows the designer to interrogate and manipulate the contents of the Agent’s world model.

After designing the behavior, the behavior must be compiled. The generated byte stream is then stored within one of the Grid’s Directory Services. Unlike traditional Java systems, the compiled class is not stored on disk. When needed by an Agent, the

The Agent Grid 20


behavior byte contents are retrieved from the database and executed like any other Java class.

Agent-Oriented Social Computing

The Agent Oriented Architecture (AOA) promotes a basic tenet that there will be software entities out in the world that will provide capabilities but, most important, will socialize to accomplish work. The social aspect will remain as the most fundamental and important component of AOA systems. Within the context of the Agent Grid, this is known as Agent-oriented social computing. Cobbling or assembling are other terms

used to describe the requirement that these entities must communicate to accomplish work. However, we use the term social computing because the future entails more than the mere assembling of entities as would be found in workflows or business processes. The autonomous construction of software solution will be the holy grail of AOA systems. These solutions will be cobbled from existing Agents and behaviors without human intervention. The solutions may form and then disband after completion. Complete autonomous software construction will only come about by using complex modeling structures beyond workflows. Workflows and process flows are very limited forms of social computing. True solution creation will come about using social structures such as organizations and societies which allow Agents to form complete relationships with other Agents. Whereas design patterns are used in the manual construction of object-based software systems today, the Agent Grid uses social patterns and Organization Theory in

the automated construction and management of Agent Grid solutions. Social computing will be used in four important aspects in Agent Grid solution automation:

Self-generation. The ability for solutions to form based on a change in the

environment such as a new business need.

Self-organization. The ability for solutions to change structure because of a

change in its environment.

Self-optimization. The ability for solutions to change because of a reduction in performance or diversion from best practices.

Self-healing. The ability to resolve issues dealing with the health of the solution

such as an unavailable or misbehaving Agent.

In general, a social pattern is a defined set of relationships, behaviors, and structures between participants. The pattern defines how the participants are organized and what they can expect from each other under specific circumstances. Organization Theory studies how participants are structured and how they interact based on their environment. For example, a small company with few employees will support much different organizations than a large company with many employees. Given the state of the environment, Organization Theory can indicate the types of structures that will appear under specific circumstances such as during the development of a software product. Both social patterns and Organization theory can be applied to Agents to dictate how they autonomously form relationships.

Let’s take an example. If two companies are to merge resources (employees, computer systems, software), the process of automating the merge would be as follows:

The Agent Grid 21


Describe the environment of both companies (employees, organizational charts, computer networks) and allow an Agent Grid solution to form autonomously for each company. The grids will form based on Organization Theory and social patterns. Figure 10: Automatic Grid Generation shows an example Agent Grid solution generation driven by an organizational chart and the computer network.

Define the type of environment envisioned when two companies merge. For example, the organization charts, the divisions, the tasks, etc. Then let the two grids self-organize to the new environment. Figure 11: Agent Grid Self-Organization shows a simple example of two company grids self-organizing. The process would be monitored, tracked, evaluated, and optimized based on best practices.

Figure 10: Automatic Grid Generation

Figure 11: Agent Grid Self-Organization

The Agent Grid 22


Societies

A society is the most basic social structure in the Agent Grid. Social patterns are evident within the confines of a society. Every “cobbling” capability in the Agent Grid must occur within the confines of a society. In fact, the society paradigm is the glue that ties all existing and future cobbling capabilities. The concept of a society is defined by two major aspects:

Shared behaviors and Rules. These are the behaviors that bind the participants

of the society. They are shared by the participants and the participants are expected to hold such behaviors. This would include basic tenets such as obeying the law, speaking the same language (protocol) and paying local taxes.

Defined Roles and Relationships. Participants are expected to fulfill certain roles

and relationships within the society. These may be well-known roles such as a machine operator, a mechanic, a teacher, or a pupil.

Societies work or function because each individual member of that society plays particular roles and each role carries a status and norms which are formed by the values and beliefs of the culture of that society. The process of learning these roles and values is called socialization.

In contrast, a society within the Agent Grid is defined by three major components:

The Society behaviors.

The Society relationships.

Supported social patterns.

These components define how the society should form and the types of agents expected in the society.

There are two aspects to social computing for Agent Grids:

Social skills of each Agent. In humans and Agents, these skills overlap and

include listening, respecting distance, recognizing the feelings of others, taking turns.

Social Patterns. In human terms, these are technology tools that allow us to

socialize such as email, blogs, and chat rooms. In Agent Grids, these are workflows, process flows, and organizational structures.

Social Skills are commonly defined as those specific behavioral strategies that allow one to initiate and maintain positive social interactions with others. The intent is to embed these skills within Agents in the form of behaviors. The behaviors will be used during socialization processes. These social skills are the same skills adults and children use in constructing new friendships, forming groups, or solving tasks. Some of the envisioned skills include:

Sharing. Agents will offer their behaviors to other Agents dependent on policies

and security.

Compromising.

The Agent Grid 23


Survival. There will be behaviors in an Agent that ensure their internal goals

override all others. This may includes requirements to prevent sensitive company data from being released from the Agent. Or requests for services that are considered detrimental to the Agent such as removing a fact from the Agent’s world model.

Friendship. An Agent will form a special bond with other Agents to support the

direct sharing of behaviors. For example, suppose that an Agent needs help in supporting a goal and it determines that one specific Agent is always able to respond. That Agent may be given preferential treatment.

Knowing rules. This is the support of policies that define the overall behavior of

the Agent and any societies that it participants in.

Flexibility. Allowing behaviors to be added or removed from the Agent.

Winning and losing. This is about competition. We will add certain criteria that an

Agent must strive to achieve. For example, responding to requests within a certain time frame. Or ensuring that all requests are answered (no missing behaviors). If an Agent loses (does not fulfill a criteria), then it will try to find ways of achieving that criteria such as collaborating with other Agents to achieve its goals.

Design and Implementation

This section will discuss the design and implementation of the Agent Grid. Specifically, the software services (components) that are required to run the Agent Grid. These services can be categorized as follows:

Grid Services. These are services that support the grid technology itself as

oppose to the Agent features.

Agent Services. These are services designed to support Agent technology.

Vertical Market Services. These are services designed to support a specific

vertical market. These services will not be discussed in this paper.

The Grid Router Service

The Grid Router service is a grid service that provides a key role in the Agent Grid. The Grid Router can be viewed in the same context as physical network routers found on LANs. Unlike network routers, Grid Routers do not have a defined area of responsibility so a Grid Router is not guaranteed to see every message that passes through the grid. However, if there is only one Grid Router servicing a small local grid then that router will in fact see all messages traveling through the grid. The basic rule of the Agent Grid and of Grid Routers is that a message between participants on the grid must travel through at least one router. The Grid Router provides a number of important features for the Agent Grid including:

Agent Discovery and Message Routing. All messages that travel through the grid

must pass through at least one grid router. Since Agents are identified with a logical identifier, the Grid Router is responsible for translating the logical identifier into a physical identifier (i.e. IP Address). The Grid Router may use other grid

The Agent Grid 24


services to do the actual translation (e.g. Discovery Service) however the Grid Router is responsible for initiating and terminating the discovery process. Once the Agent is discovered, the Grid Router is then responsible for determining where the Agent is to execute (see discussion in section “Agent Discovery”).

Protocol Translation. The Grid Router accepts network messages in a number of

protocols including the default Agent Grid message protocol (called “Daplets”). The Grid Router may receive Agent messages in the form of HTTP requests, Web SOAP calls, and any other protocol that the Agent Grid defines acceptable. In addition, the Grid Router will return messages to a caller in the protocol in which the message was first received. Hence, a Web Browser would submit an Agent message in the form of HTTP and would get a response from an Agent in HTTP format for display as shown in Figure 12: Grid Router Protocol Translation (From HTTP to Agent Grid).

Service Launching. The Grid Router has the ability to launch software services

upon request or when required by the Grid. The Agent Grid Directory Service maintains information about software services such as the host location, the location on disk, and any required parameters. The Grid Router has the ability to communicate with any launched software service.

Figure 12: Grid Router Protocol Translation (From HTTP to Agent Grid)

The Grid Router supports any application that uses TCP/IP as its communication protocol. However, the application must be using an application protocol that the Grid Router understands. The Grid Router listens on a number of ports. These ports are either defined by the Agent Grid or by industry standards (ICANN) such as the SNMP ports.

The Global Directory Service

The Agent Grid Directory Service is a database that provides metadata for the grid. The Agent Grid supports any number of Directory Services. These databases provide information on how to locate an Agent/service (White Pages), how to locate a class of

The Agent Grid 25


Agents/services (Yellow Pages), or how to locate descriptive information about an Agent/service such as on which host to execute an Agent. Directory Services are typically distributed throughout the infrastructure. Agent metadata may be partitioned among several Directory Services in order to reduce contention. There is no requirement that each Grid Router be given its own Directory Service. Directory Services will be deployed depending on issues such as the organization it is servicing or the amount of visibility required. Figure 13: Grid Routers and Directory Services shows an Agent Grid with Grid Routers and the Directory Services. Retrieving the metadata of an Agent may require the request to meander through the network until it finally finds a Grid Router that has access to the Directory Service containing the metadata. In massively distributed solutions, the Agents are typically partitioned/regionalized along with their metadata. Hence, only Agents within a region compete for a particular Directory Service.

Figure 13: Grid Routers and Directory Services

The Grid Infrastructure

The Agent Grid can be configured in a number of ways to accommodate the size of the solution. The Agent Grid is a peer-to-peer solution. When we refer to a grid infrastructure we are implying a network where Agents will be executing on multiple hosts. This is typically the case when multiple vendors are part of a business solution and the vendors will be executing their Agents on their side of the firewall. The connection points within the Agent Grid are represented by Grid Routers as discussed in section “The Grid Router Service”. To extend the Grid, Grid Routers are added to key host computers. The Agent Grid Directory Service maintains information about the available Grid Routers that

The Agent Grid 26


it knows about. This information is loaded into a Grid Router’s memory on startup. Grid Routers also update their in-memory tables during quiet points in their execution. A Grid Router should be installed on any machine that needs to execute an Agent. This is needed if the Router is to launch an Agent Virtual Machine application whose task is to execute Agents.

There are two key concepts that are involved when executing distributed infrastructures such as the Agent Grid:

Object Discovery - process of locating an object via a Global Directory Service.

Object Metadata - maintaining descriptive information about an object. This

would include all the data related to the design of the Agent (for example, its behaviors).

Object Discovery is provided by the Agent Grid Directory Services. At this time, object metadata is also provided by the Directory Services. Future releases will certainly see this change with the separation of data to two distinct databases.

If a request arrives to a Grid Router to access a particular Agent, the Grid Router executes the following steps:

Requests Agent Discovery via the Directory Services service. The Router needs to locate the description of the Agent (see Chapter “Agent Discovery” for a description of the process).

If the Agent description is found, the contents are examined to determine if the Agent needs to execute on a particular host.

If an Agent does not specify a host or if the Grid Router has access to the host, then launch a special software service called the Agent Virtual Machine (AVM) on that host and submit the request to the AVM. The AVM is responsible for executing the Agent.

If an Agent does specify a host and the Router does not have access to that host, locate the Grid Router that has access to that host and pass on the request to that Router.

Agent Discovery

A major capability of the Agent Grid is Agent discovery. Agent discovery is defined as that task which translates a logical Agent identifier to a physical definition of the Agent. Participants on the Agent Grid will locate Agents via their logical identifier, name, classification, criteria, etc. The component responsible for Agent discovery is the Grid Router. That may change in future releases as the Agent discovery capability matures. Object discovery is a large, complex research subject. Agent discovery in the Agent Grid will undoubtedly change and evolve over time to include new technologies and the support of industry standards such as LDAP.

The Agent Grid 27


Agent Services

Agent services are those services that directly support the execution of Agents. The full set of Agent Services includes:

Agent Virtual Machine (AVM) - responsible for providing the execution

environment for an Agent. Agents must execute within the confines of an AVM. This is much like the case that a Java program must execute within the confines of a Java Virtual Machine.

Semantic (MatchMaker) Service - responsible for applying discovery services

involving more complex capabilities such as constraints and semantic data. The Semantic Service will not be discussed in this paper.

Conversation Service - responsible for controlling complex conversation styles

between Agents beyond those styles handled by the Grid Router and AVM. The Conversation Service will not be discussed in this paper.

The Agent Virtual Machine (AVM) is the critical service required to support Agents. An Agent is a collection of behaviors but has no capability to execute by itself. Given a set of behaviors for an Agent, it’s the AVM that sets up the environment to allow behaviors to execute. Figure 14: The Agent Virtual Machine shows the relationship between the AVM and the other services on the grid. The AVM can support any number of Agents. The Grid Router launches the AVM when it receives a message destined to the Agent.

Figure 14: The Agent Virtual Machine

The Agent Virtual Machine

Whereas the Agent represents a collection of behaviors, it’s the Agent Virtual Machine (AVM) that represents the processing part of the human mind. The AVM is a software server that can execute Agent definitions. The Agent definitions are stored in the Grid Directory Services and extracted to the AVM and executed. Figure 15: Network Execution Flow shows the execution flow of the AVM on the Grid. The Agent definition includes the behaviors, knowledge (mental model & pre-defined knowledge base), and run-time behavior description.

The Agent Grid 28


The Artificial Intelligence aspect of an Agent is embodied in the AVM. It’s envisioned that the AVM will be the most redesigned component of the Agent Grid. There will be many 3rd party versions of the AVM and integrators will position for the best and most human-like AVM. This was the intent of the design in which the behaviors and the engine that executes the behaviors are separate. The AVM also incorporates all the social behaviors attributed to the Agents. And we envision that any changes which relate to artificial life are embedded with the AVM.

Figure 15: Network Execution Flow

The AVM is a software server. The AVM waits for requests from the participants on the Grid. Typical requests include revealing an Agent, telling something to an Agent, hiding an Agent, and asking an Agent about itself. The AVM routes a request in the form of a performative to the correct controller. A controller is software code that manages either one Agent or a society of Agents. The controller processes performatives destined to its society/ Agent. Controllers do not directly communicate with its Agents. The controller is primarily responsible for manipulating the world model for its society/Agent.

The most important responsibility of the AVM is the processing of Agent behaviors. Agents consist of behavior pools. These behaviors are triggered into consciousness by the state of the world model. However, this is a very simplistic view of how the human mind works. Humans have many behaviors which conflict with each other. Most humans would run when a building they are occupying catches fire. But this would not be an admirable behavior for a fireman. Fireman still maintains behaviors which will cause them to flee a building (for example, when the fire is out of control). However, their behaviors to stay and fight a fire have a higher “priority” than their behaviors to flee. Training ensures that their behaviors are prioritized appropriately. The AVM needs to be able to model this type of prioritization. There are other aspects of human behavior management that must be modeled within the AVM. The modeling capabilities of an AVM must include:

The ability to prioritize behaviors and the ability to manipulate the priorities in real-time.

The Agent Grid 29


The ability to disable behaviors. This implies that a disabled behavior will no longer participate in behavior selection. The behavior may still exist but it won’t be selected unless enabled.

The ability to add behaviors to the behavior pool in real-time. This supports learning capabilities.

AVM Architecture

An AVM is a software server designed to interpret and execute Agent definitions. The Agent Grid does not enforce a specific architecture of an AVM. Vendors and developers are free to define the architecture of their associated AVMs. The sample AVM allocates a collection of software threads to handle an Agent or society definition. The threads are defined as follows:

Society/Agent Controller - this thread represents a society if executing a society

or an Agent if the execution consists of a solo Agent.

Agent Coordinator - this thread represents a single Agent.

Reactor - this thread handles the execution of an Agent’s reactive and procedural behaviors.

Coordinator - this thread handles situations where multiple Agents are

collaborating to solve a goal.

Deliberator - this thread handles Agent sequences.

AVM Data Resources

The AVM data resources include the in-memory knowledge bases supporting each Agent and the behavior pools. Each Agent has its own knowledge base structured according to its mental model and populated by facts pre-defined for the Agent and added to by other Agents on the grid. For the most part, the data resources are kept distinct.

The Daplet

Agents and services communicate by exchanging messages called Daplets (short for Data Applets). A daplet is a collection of datums in which each datum represents a piece of data such as an integer, string, code. Datums can be constructed in many configurations which allow a daplet to be as expressive as XML data, database records, and any other structured data. Daplets also contain a number of innovations that separate them from simple messages including:

X400-like header which includes features such as security signatures, priority, sensitivity level, and routing information (in-reply-to, reply-to).

Ability to encrypt or compress at the datum level.

Information on how to process the daplet for vendor specific formatting.

Special hidden sections for system-only information.

The Agent Grid 30


Ability to push portions of the message out to the network for performance reasons before the entire message has been constructed.

Ability to hold an unlimited amount of data for sending large data streams.

Datums are known as TNLVs (Type-Name-Length-Value). They consist of a type indicator, a name value, a length value, and the actual data value itself. For example, a datum containing an employee title would look as follows:

TYPE: string NAME: employeeTitle LENGTH: 6 VALUE: “execVP”

The corresponding record in XML would look as follows:

<TNLV> <TYPE>string</TYPE> <NAME>employeeTitle</NAME> <LENGTH>6</LENGTH> <VALUE>execVP</VALUE>

</TNLV>

Datums take up less space than their corresponding XML representation. Datums also contain advance features such as:

Ability to encrypt or compress the data contents (value).

Ability to assign a conversation identifier to indicate datums relating to a conversation stream between Agents.

Ability to control the structure of the datum. For example, to remove any indication of a name within the datum. This reduces the size of the datum and increases the amount of information that can be sent on the network within a single network packet.