Skip to end of metadata
Go to start of metadata

Summary of the Iteration Tasks

This page gives a brief summary of the set of tasks for the iteration, their status and the approaches adopted to address them in the iteration.

Prototype a Jython based agent

This subtask focused on developing a Jython based prototype implementation of the multiagent system to show that the components chosen for the implementation can be integrated and to realize a simple use case to prove the soundness of concept. The following architecture was realized in the prototype.
The Community and Member agents are illustrated as communicating through the Magnet Framework. Any typical rule based agent needs two components, essentially:


  • Communication infrastructure:
    In our prototype the agent relies on the Magnet framework to provide a name based addressing scheme that cleanly abstracts away lower level constructs like sockets and queues from the agent by employing the Twisted framework. Magnet in turn abstracts the AMQP constructs that underlie the infrastructure, but a detailed discussion of Magnet is outside the scope of this document.
  • Rule and fact processing capability:
    The rule engine used for this prototype is the Rete algorithm realized in Java called JESS (Java Expert System Shell). We use the forward chaining rules to enable reactive and proactive action in the agent. A more detailed description of how the framework is being used may be found here

Following are the points of note:

  •  The reasoning engine - JESS is implemented in Java and thus cannot be consumed directly by the current Python based implementation.
  •  This calls for a way to access JESS which led us to adopt Jython as the language of choice for the agent implementation.
  •  Jython, however, does not support the communication framework being used in the project -Twisted
  •  Therefore the architecture was modified to contain two components -
    • A Python component to interface with Magnet via twisted.
    • A Jython component that consumes the JESS engine and runs the agent thread.
  • To enable communication between the two components an XML RPC setup was realized.
  • The illustration shows two agents using the Magnet framework to communicate among themselves and the XMLRPC setup to communicate between the components.
  • The messages being exchanged are FIPA messages formatted to text.

Represent an Org as an agent

The agents in the above prototype adopt various roles and interact with other agents to further their interest. In the OOI space, the agents represent autonomous entities such as individuals and Organizations (Orgs) or communities. An Org scopes the interaction of its members and enforces its policy in administration of the group. Agents join the Org by negotiating their membership with the Org agent and realizing a contract. An Org agent also wields the power to subject its members to penalty or sanction in the case of a breach of a clause in the contract. This calls for a agent representation of the Org.

We enable this by crafting an Org role that may be adopted by the agent. The local policy that motivates action or drives decision making in an agent is crafted as being separate to the role so an Org can reuse the template. The roles are extensible, in that the Org can negotiate for a different set of terms to play the role in. A sample of the rules that are scripted for an Org are listed here:

Prototype federated resource directories

An Org is viewed as being the central entity that represents a community and therefore requests to discover the pool of resources available with the agents in a community must be addressed to the Org agent. The Org agent by consequence of its status as a representative of the community is obliged to service such requests if they are from agents in the OOI space. To this end, it must maintain a listing of the resources available with the agents that comprise it. It projects these resources and thereby enables the discovery of the resource owner by the seeker.

We realize this by stating as facts the ownership and states of the resources in the community. Agents register their resources with the Org agent. A request for the discovery of a certain resource is now handled by the Org agent by evaluating its knowledge base for the presence of a fact that suits the description in the request. The template for the resource listing fact is :

Prototype local identity of resources and members

An Org lends scope to its constituent members. In keeping with this notion we visualize a hierarchical system of identity provided by the Orgs. This identity is local and may be parallel to the universal identification scheme. A simple version of this was realized as a set of facts that represented the membership of an agent with the Org, and thus identified it locally. This may further be evolved to be more wholistic but its current state is merely to enable the members and the Org to reason about the role being played by an agent. The template for such a representation is as follows:

Prototype implementable policy mechanism

Our approach to modeling agent interaction divorces the local motivation from the interaction constraints and patterns. This calls for a mechanism to specify the policies in a systematic and standard fashion so that one may reason about the validity of the policies (loftier goal). The current iteration aims at making a first cut at such an approach. We try to formalize the specification of policies for an agent such they may be readily plugged in by the protocol rules (interaction constraints and patterns).

Initial specification for Orgs

The specification of an Org identifies the kinds of interactions and thus the roles at play in its scope. Typically the specification would employ normative constructs to identify the roles. These specification capture the essence of the setting being modeled. An example of such a specification is listed here.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.