main menu:
  » home
  » introduction
  » indigolog overview
  » oaa overview
  » interface model
  » developing agents
  » simple example
  » advanced example
  » other interface models
  » implementation details
  » tips
  » links

 

   

Open Agent Architecture

 

Open Agent Architecture is a framework for constructing multiagent systems developed at the Artificial Intelligence Center of SRI International.

The primary goal of OAA is to provide a means for integrating heterogeneous applications in a distributed infrastructure. In addition OAA also incorporates some of the dynamism and extensibility of blackboard approaches, the efficiency associated with mobile objects, and the rich and complex interactions of communicating agents.

OAA provides the communication infrastructure for the agents as well as Interagent Communication Language (ICL). ICL is used to exchange information among agents. The system has at least one special agent called facilitator. This agent acts as a broker and all inter-agent communications go through it. The facilitator keeps track of all the agents in its system, their addresses and capabilities (see below). It is possible to create a hierarchy of facilitators, each with its own subsystem of agents. Agents other than the facilitator are called client agents. The current version of OAA supports such agents written in C/C++, Java, Compaq's Web Language and Quintus and SICStus Prolog.

When a client agent enters the system, it connects to the facilitator agent and registers with it. It provides the facilitator with a list of solvables - the agent's capabilities. These provide the high level interface to the agent. Callback methods for each solvables are also provided. They are invoked when some agent wants to use this agent's declared capabilities. The agents can dynamically add and remove solvables. The solvables can be of two types: procedure and data. Procedure solvables describe some service that can be performed by the agent, while data solvables are most commonly used to create a data storage shared among the agents in the system. Such data store can not only be queried, but also updated by a number of agents having the necessary permissions.

Here are some primitives form the OAA library for Prolog. For more information and for other languages, see OAA documentation.

  • com_Connect(parent, [], ConnectionInfo) — Connect the agent to the facilitator. The first parameter specifies the name of the facilitator connection (usually "parent"). The second argument is a list of optional parameters. The last argument returns the address of the facilitator.

  • oaa_Register(parent, <agent name>,<list of solvables>, <parameter list>) — Register solvables with the facilitator. The parameter list is usually just an empty list. Each solvable on the list can be declared using the following format (there are other formats as well):

    solvable(<goal>,<parameter list>,<permissions list>) — Many of the parameters and permission can usually be omitted , so it is often the case that the list are empty. The goal of a solvable is agent capability specification which will be used according to the semantics of unification, just as it is used in logic programming. When the facilitator receives request to solve some goal, it uses unification to test that request against the goals contained in the solvables specifications of its connected agents.

  • oaa_RegisterCallback(app_do_event, user:oaa_AppDoEvent) — Register the general OAA callback which will be called whenever a new ICL request arrives for the agent.

    The request with different goals can be separated in the following way:

    oaa_AppDoEvent(<goal 1>, _GoalParams) :- <handle goal 1>.
    oaa_AppDoEvent(<goal 2>, _GoalParams) :- <handle goal 2>.


  • oaa_Ready(true) — Tell the facilitator that the agent has completed the initialization and is ready to receive messages. Use this construct if the agent is supposed to be proactive.

  • oaa_MainLoop(true) — This primitive first calls oaa_Ready and then runs the main OAA event loop. Use this construct if the agent is supposed to be reactive.

When an agent wants some services performed by other agents, it issues an oaa_Solve request that is forwarded to the appropriate agent by the facilitator. The goal part of such request is an ICL description of the service to be performed.

oaa_Solve(<goal>,<list of parameters>) — Request services of other agents. The list of parameters is quite extensive. It is possible to specify that the shouldn't be blocked until the answer is received (reply(none) or block(false)) and that it is fine if multiple agents will attempt to solve the problem simultaneously (parallel_ok(true)). For the full list of oaa_Solve parameters see the OAA documentation.

The result of the query is returned through unbound variables. For example, suppose an agent would like to get a distance from one location to another from another agent. The oaa_Solve might look like this:

oaa_Solve(distance(location1,location2,Distance).

Notice that 'location1' and 'location2' are constants while 'Distance' is a variable (OAA ICL is very Prolog-like). If this call returns successfully, Distance will be bound to the actual distance between the two locations.



 

 


 
© 2001 All Rights Reserved. See Legal Notice.