AgentScape Concepts

As stated at the home page, AgentScape is a distributed system. It can connect a (large) number of hosts together, to deploy large-scale agent-based applications.

To this end, AgentScape defines the following concepts:

Hosts & Locations

An AgentScape platform contains hosts and locations. A location can consist of a number of hosts. These hosts may be physically distributed, but they belong to a single administrative domain (the location).

Each physical host runs an instance of the AgentScape platform with a Host Manager Service. Optionally, some of the hosts can run a Location Manager Service, which performs the coordination of all the available hosts in the location. This is illustrated in the following picture.

Here we see three different instances of the AgentScape platform. Each are running a host manager, but one is also running a location manager. All hosts that are connected to this location manager belong to the same location. Starting the AgentScape hosts like this results in a single location being active, which consists of three different hosts.

Each AgentScape host can offer some services, as well as a platform where agents can be started.

Worlds

In order for (distributed) hosts to find other hosts (and the location manager), AgentScape defines the concept of a World. A world is defined by a World Lookup Service, where all location and host managers are registered. Hosts can use this lookup service to find other hosts and location managers.

There is a default world lookup service available at http://lookup2.agentscape.org, which can be used by anyone. Each location that uses this lookup service, runs in the public world. As a result, these hosts can see (and be seen by) all other hosts that use the same lookup service.

It is also possible to define your own world, by running your own lookup service. This allows for running isolated experiments or a separate (non-) public world. Creating a new world is as easy as starting your own lookup service.

Hosts and Locations can only contact others in their own world. There is no bridge from one world to another, so a single world is isolated from all other worlds. By default, you do not need to configure any world lookup services (the global service is used by default) but the disadvantage is that all kinds of (experimental) applications running on unknown hosts may interfere with your local running application.

Agents

Most applications on AgentScape will be centered around the concept of agents. These agents are pieces of code that can interact with the AgentScape platform and other agents in order to achieve their (collective) goals.

Agents generally do not run independent, but as part of the platform. The AgentScape middleware contains a (number of) agent servers, which provide the runtime environment for the agents. So in order to start an agent, at least one instance of the middleware platform has to be running.

Agents can be written in Java (though other language support is experimental). There is a default agent class (org.iids.aos.agent.Agent) which can be extended to create Java agents, but different types of agents can be added to the middleware at a later point.

Agent Location

Location managers keep track of all the hosts that are active in the location. Starting an agent means that a location manager has to be contacted, which has to make sure that the agent is activated on the platform. The user that wants to start an agent can contact the location manager (either programmatically or using the injector.jar utility) who takes care of starting the agent.

Because a location may consist of multiple hosts, the location manager itself decides on which physical host the agent is actually started. The user requesting the startup has no direct control over this. When a location consists of a large number of distributed hosts, the agent may end up on a (very) remote host.

Agents themselves also have no knowledge about which host they are running on. The location manager is trusted to make the best decision about where to place the agent. Functionally, there should be no difference between running on one host or another (as long as it is within the same location). In the following picture there is an example of this.

In this example you see a number of agents, all running on Location A, but not all are running on the same physical host. Multiple hosts can be used to transparently distribute the load of agents in a single location. However, some hosts may contain different services that are not accessible from agents running on another host (within the same location). The location manager is responsible for the initial placement of the agent on the host that best matches the startup criteria of the agent.

The criteria of the agent cannot be supplied yet in version 2.0-m1

Agent Migration

Agents in AgentScape have the opportunity to migrate to another location. A remote location may offer different services or resources, so an agent may decide to migrate to a remote location at some point in time. Whenever an agent wants to migrate, the agent requests to be migrated to a remote location. The local location manager contacts the manager of the remote location to receive the agent. When an appropriate host is found for the agent in the new location, the platform transports the agent to the remote host.

The remote location manager decides on which physical host the agent is placed. Once the agent (all state + code) have been transported to the new host, the agent is resumed at this new location. AgentScape offers weak migration for agents, which means that the thread of execution is not transported to the remote site, but the data inside the agent instance is automatically saved (serialized) and restored at the remote location. After the agent has been completely restored, it is restarted and the old agent instance is removed.

It is currently not possible to migrate between specific hosts in the same location

Agent Lifecycle

TODO

Agent Communication

Agents communicate with other agents using Agent Handles. An handle as an unique endpoint which is specific for one agent. Agents can also generate extra handles for different conversations. Each handle is unique and external sources cannot associate two handles to the same agent. So a handle is also useful for anonymous communication: a handle can be deleted once the conversation is done.

When an agent is started, it already knows two handles: its own primary (initial) handle, and the handle of its owner process.

Agent Owner

When an agent is created programmatically (using the AgentScape API), the process that creates the (child) agent receives a special handle, which is called the owner handle. This handle can be used to communicate with the primary handle of the agent that just was created. This is a convenient mechanism to exchange information between the owner and the agent, even long after the agent was started.

However, if the owner only wants to send some initial information to the agent, it can also specify a number of command-line arguments when starting the agent.

The owner handle is private information to the child agent. Once it receives a message from the owner handle, it can know for sure that this message was actually sent by the owner process. Messages from the owner are usually sent to the primary handle of the agent. The owner can both send and receive messages to/from the agent process.

Note: when starting an agent through the injector.jar program, the injector application actually receives the owner handle of the agent. By default, it does not do anything with the owner handle, so any communication with the child agent cannot be done anymore (because the injector finishes). Currently, the injector does print the owner and primary handle information, so it can still be used some other way. This may change in later revisions of AgentScape, so it is best not to rely too much on this behavior.

Host Structure

Each AgentScape (JVM) consists of a number of components. The basic outline of an AgentScape host is shown in the following picture.

The base for all interaction with other hosts (communication & migration) is supplied by the AOS kernel. This kernel provides some secure communication primitives as well as encrypted transfer of Agent Containers.

In addition to this, a host contains a number of System Services that together provide the core functionality of the AgentScape middleware. Some services provide adminstrative tasks (host & location managers), and some provide more specific tasks (agent & service runtime environment).

The most important system services seen from the figure will be explained next.

Host Manager

Each host runs at least this system service. The host manager service manages all the resources and services on this specific host. It is responsible for interaction between local services (and resources) and the location manager. Just as each other service, the host manager relies on the AOS kernel to perform basic interaction with services on the local host (local communication) as well as communication with remote services.

Location Manager

Each host is part of a single location. The location itself is the administrative domain for a set of hosts. A location is administrated by a location manager service. A host can be part of a location because it contains a (local) location manager service (as shown in this figure) but it can also connect to a remote location manager. In the latter case, where the host uses a remote location manager, the location is distributed over a set of hosts.

Because only a single location manager is responsible for administrating the location, creating a new location manager automatically defines a new location.

AgentScape API

The AgentScape API offers access to some high-level access to a running platform. This is convenient for creating agents, and interacting with these agents from the external process. External processes can:

  • Create a new agent
  • Communicate with the agent
  • Kill the agent

In addition, some information about the platform and the agent can be obtained from the API.

The API is published using Java RMI, so only other Java processes can access the API. This makes it convenient to create an application that consists of agents on one hand, and standalone processes on the other hand.

One example of a standalone process that uses the AgentScape API is the injector.jar program. The injector only works when an instance of the platform (with API accessible over RMI) is locally started. The injector then contacts the API and creates the agent programmatically.

Agent Server(s)

Agent servers provide the basic runtime facilities for agents. By default, an agent server is available that offers support for Java agents. Dedicated agent servers for other languages or models can be added to AgentScape as well. For example, there is an (experimental) agent server for binary agents, but there can also be separate servers that allow running of agents written in Python, or a high-level kind of agent language (Jason).

Service Server

The service server provides a plugin mechanism for running application services. Normally, agents do not have direct access to system services (because these offer functionality critical for the platform). User level services, however, can be supplied by users of AgentScape, and have the ability to provide services for agent applications.

Agents usually run with limited permissions (no direct file access, etc). Services, however, can be configured to run with these special permissions. This is the task of the platform administrator. Whereas agents may not be allowed to open connections to a database, this functionality can be delegated to a specific service. Because the services are managed by AgentScape (as well as the interaction between agent an service) this is a mechanism to prevents agents from accessing ciritical system resouces. The access is delegated to services, which can have more access rights.

For a more detailed explanation, have a look at the blackboard_service page.

concepts.txt · Last modified: 2010/10/07 16:12 by reinier