Agentcities Interaction Using the Opal Platform

Agentcities Interaction Using the Opal Platform Martin Purvis, Stephen Cranefield, Mariusz Nowostawski, Roy Ward, Dan Carter, and Marcos Antonio de Oliveira Information Science Department University of Otago Dunedin, New Zealand +64-3-479-8318 {mpurvis, scranefield, mnowostawski, rward, dcarter, moliveira}@infoscience.otago.ac.nz specific modes of operation and representations of the world in which they operate. In general, the only common factor among these system platforms that one can anticipate is adherence to the protocols established by the Foundation for Intelligent Physical Agents (FIPA) [5]. This environment will provide us here, at the University of Otago in New Zealand, with an opportunity to test our agent platform, Opal [11], which features some new techniques that are designed to facilitate agent interoperation.

ABSTRACT The Agentcities network provides an opportunity to test the interoperation of multi-agent systems that are distributed and implemented across a variety of platforms whose only common factor is adherence to the FIPA protocols. In this context we aim to test our agent platform, Opal, which employs some new techniques for agent information exchange that we believe can make agent interaction in heterogeneous environments such as Agentcities more effective. The new agent interaction techniques supported by Opal involve (a) ontology and ontology-specific content language representation in the Unified Modeling Language (UML) and (b) dynamic exchange of interaction protocols. We will be testing the Opal system in the areas of tourism and distributed healthcare, both of which are significant application areas in New Zealand.

2.

Travel is more and more a multi-purpose activity: people are combining business, education, and entertainment as they move about the globe. For the increasing population of nomadic business people/tourists, time is the scarce commodity, and they want to use it as efficiently as possible. They often do not have the time nor the inclination to prepare detailed travel schedules, yet they need to be able to access location-based information about business requirements, medical facilities, weather conditions, culture, history, leisure activities, and entertainment options. The modern tourist also would prefer to have individualised information and services that take into account their own interests and the history of their previous activities. Here in New Zealand, these developments are particularly important due to three principal factors:

Keywords Agent communications, coordination.

1.

ontologies,

APPLICATIONS

applications,

INTRODUCTION

The Agentcities [1] initiative offers an open network of agent-based platforms in order to test real-world distributed applications that employ agent-based technology. In particular, it offers a testbed for examining the interoperation of agent-based systems that have been developed on different platforms and have their own

• Tourism is one of the foundation blocks of the economy. • Due to its geographic location, New Zealand’s citizens are, themselves, often seasoned world travellers. • New Zealand’s small population dispersed over large areas (particularly in the South Island, where the University of Otago is located) requires the availability of mobile services to monitor, manage, and sustain its natural and human resources. An open agent architecture can offer advantages isn these circumstances, because individual service agents can be added or replaced by improved models, thereby enabling an overall system to improve gradually, grow in scope, and

1

agents. The same agent-based modelling approaches apply in the same way to both coarse-grained agents and to micro-agents. Agent-oriented decomposition and rolebased modelling are independent of the deployment scale, and roles can potentially be played by micro-agents or coarser-grained agents with a similar result. However the key advantage of micro-agents is that for small-scale systems they will radically out-perform coarse-grained agents at runtime. Further details of Opal micro-agents have been described previously [11].

adapt to changing conditions. For such agent-based systems to operate effectively, they must share information by exchanging information in the form of messages that have a common ontology underlying them. Understanding messages that refer to an ontology can require a considerable amount of reasoning on the part of the agents, and this can affect system performance. To reduce the search space of possible responses to agent messages, interaction protocols, which specify a limited range of responses that are appropriate to specific message types for a given protocol, can be employed. Thus there may be a specific interaction protocol associated with securing, engaging, and paying for health services when a person arrives in a new location. This should be satisfactory if all the agents already know the interaction protocol prior to engaging in an interaction, but for open agent environments, there may be situations where the protocol is either unknown to some of the agents or it must be adapted to changing conditions.

For “coarse-grained” agents, Opal provides a concrete instantiation of the FIPA Abstract Architecture [5]. The key services that the platform provides are inter-platform message transport via the Message Transport System (MTS), agent management and a white pages directory via the Agent Management System (AMS), and yellow pages directory services via the Directory Facilitator (DF). These three logical capability sets are implemented in the Opal platform as separate micro-agents. Aside from the micro-agent role representing the agent platform, an Opal system will also contain higher-level FIPA agents that exist on the Agent Platform. Figure 1 shows a single FIPA agent that uses a conversation controller micro-agent role to keep track of conversations that the agent is involved in. The conversation controller requires the existence of some micro-agent to play the message dispatcher role. Another FIPA agent may require the Belief-Desire-Intention micro-agent role to enable it to be developed using the BDI model.

Consider, for example, a situation in which a group in a wilderness area encounters an environmental emergency, such as a storm or a forest fire. In such circumstances the responsible authorities may need to call on the services of agents who can provide crucial assistance in connection with specialised rescue operations and medical assistance. These specialist service providers may be private operators who can be contacted to respond to emergencies in critical situations, rather than people under the permanent employ of the government. If wireless communications are used, system components may come in and out of range as environmental professionals move around in the field. For such situations, there is a need for agent technology to provide • a robust, high-performance architecture • support for open standards • improved mechanisms for ontology usage • dynamic exchange of interaction protocols The Otago agent platform, Opal, has been developed to address some of the issues that arise in these situations.

3. The Opal Platform 3.1 Micro-agents Opal uses special modules, called Micro-agents, as basic building blocks. Micro-agents exist at the lowest level of agent-based abstraction in this architecture, employ a simpler form of agent communication than those based on the FIPA specifications, and have more limited flexibility when compared to higher-level agents. Agents in Opal may be composed of any number of other agents or micro-

Figure 1. An Opal agent structure.

2

net representation of the initiator of the FIPA request interaction.

A complete Opal Agent System with associated FIPA-specified services is depicted in Figure 2. Individual Opal Agents of the type shown in Figure 2 can all access an Opal Platform Agent.

In

Receive request answer Agreed Start

Request sent Refused

Send request

Out

Process precondition Notunderstood

Process refuse

Agreed (processed)

Receive request result

Process not-understood

Result Fail

Done

Process Process fail done

Process result

Figure 3. Request interaction protocol for the Initiator role.

The In place has tokens placed in it when the agent receives messages from other agents. It is a fusion node (a place common to more than one net): every time the agent receives a message from another agent, a token with information associated with the message is placed in the In place that is shared by several Petri nets. The transitions connected to the In place have guards on them such that the transitions are only enabled by a token on the In place with the appropriate qualification. In this encoding of the Petri net we include transitions that correspond to internal actions of the agent, such as those labelled “Process refusal” and “Process not understood”. These are not part of the protocol when it is viewed in the pure sense of simply being a definition of the possible sequences of messages that can be exchanged. However, they communicate the underlying intent of the protocol: there are a number of points at which the agent must invoke particular types of computation to internalise and/or react to the different states that can occur, and they are part of the conversation. Although in the example shown most of these ‘extra’ transitions occur after the final states of the protocol, this is not always the case: the “Process precondition” transition gives the agent a chance to reason about the precondition that may be specified by the other agent when it agrees to the request. This precondition must become true before the other agent will fulfil the request.

Figure 2. Example of an Opal system.

3.2

Agent interaction protocols

FIPA has developed some standard and general interaction protocols that can be adopted by agents, and these have been typically represented by state machines. We use coloured Petri nets (CPNs) [7,3] in Opal, because their formal properties facilitate the modelling of concurrent conversations in an integrated fashion. Coloured Petri nets are similar to ordinary Petri nets in that they comprise a structure of places, transitions, and arcs connecting those two types of elements. Additionally, coloured Petri nets have structured tokens and a set of net inscriptions (arc expressions, guards, and place initialisations) which can be evaluated to yield new net markings when transitions are fired. Moreover, coloured Petri nets facilitate the modelling of individual agent conversations within a larger behavioural modelling context associated with a particular problem domain.

For our Agentcities applications, it is our intention to provide agents with the ability to download an interaction protocol previously unknown to it, work out where and how to plug in to the protocol its own code for message processing and for domain-specific decision making, and begin using that protocol to interact with other agents. Thus when new agents appear and are to be incorporated into the network of available agents, they are sent a FIPA Propose message by the group manager with a message content containing an XML-encoding of the interaction

We now model all interaction protocols in terms of the roles that are engaged in the interaction. For each role, there is a separate Petri net. In Figure 3, we show the Petri

3

proposition, term, action or definite description). In this framework, a message is viewed in the abstract as a network of objects that are instances of the classes in the ACL and content languages models. By leveraging object oriented techniques, it is possible to implement the entire content language processing module and linkages to user-defined ontologies with standard tools.

protocol that is used. The target agent parses the XMLencoded interaction protocol, and if it accepts the proposed mechanism for interaction, sends the Accept message back to the group manager. This kind of interoperation can be accomplished by describing at an abstract level the required agent actions that must be ‘plugged into’ the protocol for it to be executed. To achieve this it is necessary to design and publish ontologies describing the input and output data that are processed during the protocol’s execution, together with the actions and decisions that the agents must perform. An agent that has previously defined mappings between the internal agent code and the actions and decisions in an ontology would then be able to interpret any interaction protocol that is defined with reference to that ontology.

We are developing a proof-of-concept framework for automating most of the programming work needed for using ontologies based on UML within our agent system and have submitted this as a proposal to FIPA [9]. This framework will take as input a designed ontology expressed as an UML class and object diagram, and will then automatically generate the necessary code for objects and classes, together with the marshalling and unmarshalling codeneeded for object serialization. It will be possible to use that framework for different object-oriented implementation languages, however at the current time only Java is being supported. This framework will considerably ease the programming overhead needed for ontology binding from within the content language.

We connect the interaction protocol with the ontologies by taking advantage of the inscription mechanisms that are part of the coloured Petri net formalism. Concepts in an associated ontology are used as the types of CPN places (colours) and of arc expressions. We use the objectoriented Unified Modeling Language (UML) [2] to represent the ontology and UML’s associated Object Constraint Language (OCL) [12] as our expression language Thus in the case of the Request protocol, the concepts that need to be defined in the associated ontology are message types. We also include an optional operation associated with a CPN transition. In addition, the inputs to the operation are specified as OCL expressions, and a list of variables to assign the outputs to is also given (UML allows multiple ‘output’ parameters in an operation).

3.3

4.

CONCLUSIONS

We are developing tools and techniques, as part of the Opal platform, that we intend to use to support agent-based applications operating in dynamic and distributed environments, such as those associated with tourism services and distributed healthcare services. This work is part of the New Zealand Distributed Information Systems project [8] and is carried out at the Software Agents Research Centre at the University of Otago in New Zealand [10].

Content Languages and Ontologies

In Opal we use the notion of an abstract content language, in which textual representation handling is delegated to appropriate pluggable codecs. The content of the messages, expressed in this abstract content language, make direct references to the terms, objects and methods defined in a particular ontology.

5. REFERENCES

Following our previous line of research [4], we have proposed and used the Unified Modelling Language as an abstract modelling tool for ontologies. It is beyond the scope of this paper to describe how ontologies can be specified using object oriented meta-modelling and UML. so we concentrate here on the binding and mapping between an ontology and a content language. With the ontology formally defined, it is straightforward to map the concepts and relations depicted in an ontology to the abstract syntax of an ontology-specific content language. The interface between content languages and the agent communication language (ACL) is explained using the notion of type substitution: classes in a content language can be declared to ‘implement’ a predefined interface representing a specific type of content expression (e.g.

4

[1]

Agentcities, http://www.agentcities.org, also “Agentcities: a Worldwide Open Agent Network”, Agentlink Newsletter, Issue 8, pp. 13-15.

[2]

G. Booch, I. Jacobson, and J. Rumbaugh. The Unified Modeling Language User Guide. Addison-Wesley, 1998.

[3]

Cost, S., Chen, Y., Finin, T., Labrou, Y., and Peng, Y., “Using colored etri nets for conversation modeling, Issues in Agent Communication, Lecture Notes in AI, SpringerVerlag, Berlin (2000).

[4]

Cranefield, S., Nowostawski, M., and Purvis, M., “A proposal for a strongly-typed ACR framework”, FIPA Input Document f-in-00048, http://www.fipa.org/docs/input/f-in-00048/.

[5]

The Foundation for Intelligent Physical Agents, http://www.fipa.org/specifications/index.html.

[6]

Greaves, M, and Bradshaw, J. (eds.), Specifying and Implementing Conversation Policies, Autonomous Agents '99 Workshop, Seattle, WA, (May 1999).

[7]

Jensen, K., Coloured Petri Nets – Basic Concepts, Analysis Methods and Practical Use, Springer-Verlag, Berlin, 1992.

[8]

The New Zealand Distributed Information Systems project, http://nzdis.otago.ac.nz.

[9]

Nowostawski, M., Cranefield, S. and Purvis, M., "Simple Semantic Language - The Abstract Content Language", Proceedings of the 2nd International Workshop of Central and Eastern Europe on Multi-Agent Systems (CEEMAS 2001), Department of Computer Science, University of Mining and Metallurgy, Krakow, Poland (2001) 347-354.

University of Otago, Dunedin, New Zealand, http://secml.otago.ac.nz/agents/. [11] Purvis, M., Cranefield, S., Nowostawski, M., and Carter, D., "Opal: A Multi-Level Infrastructure for Agent-Oriented Software Development", Information Science Discussion Paper Series, Number 2002/01, ISSN 1172-6024, University of Otago, Dunedin, New Zealand (2002). [12] J. B. Warmer and A. G. Kleppe. The Object Constraint Language: Precise Modeling With UML. Addison-Wesley, 1998.

[10] The Otago Software Agents Research Centre, m The

5