The STL++ Coordination Language: Application to ... - Semantic Scholar

The STL++ Coordination Language: Application to Simulating the Automation of a Trading System Michael Schumacher, Fabrice Chantemargue, Oliver Krone, Simon Schubiger, Beat Hirsbrunner University of Fribourg, Computer Science Department, PAI group Perolles 3, CH-1700 Fribourg, Switzerland http://www-iiuf.unifr.ch/pai

Keywords: Multi-Agent Systems, Agent-Oriented Programming, Distributed Arti cial Intelligence Applications.

1 Introduction Coordination theory introduced by Malone [6] is concerned with the management of dependencies between dierent activities. Tenets developed in this theory encompass conceptual and methodological aspects that enable a distributed application to have a better expressiveness and to be much more easily implemented, through a clear separation between coordination and computation [3]. In computer science, research in coordination theory focused on the de nition of multiple coordination models and related languages [7]. A coordination language is the linguistic embodiment of a coordination model [3] and has to be orthogonal to a computation language. The most representative of this class of languages is Linda [2]. The coordination language STL++, presented in this paper, applies theories and techniques known from coordination theory and languages in distributed computing to better formalize communication and coordination in distributed multi-agent applications. Because of the inherent distributivity of multi-agent systems (MAS), agent languages should have means to clearly describe the coordination part of a MAS application. STL++, as such, may be seen as a preliminary agent language which allows the organizational structure or architecture of a MAS to be described, with some means to dynamically recon gure it. We present a simulation of the automation of a trading system and show how it can be implemented in STL++.

2 The Coordination Language STL++ STL++ is based on the ECM1 coordination model [5]. It uses an encapsulation mechanism as its primary abstraction (referred to as blops), oering structured separate name spaces which can be hierarchically organized. 1

ncapsulation Coordination Model.

E

Agents, which are implemented as threads over a network of UNIX workstations, communicate anonymously within and/or accross blops through connections. The latters are established by the matching of the communication interfaces of these agents. STL++ consists of ve building blocks (see gure 2): 1. Agents; 2. Blops, as an abstraction and modularization mechanism for group of agents and ports; 3. Ports, as the interface of agents/blops to the external world; 4. Events, a mechanism to support dynamic state changes inside a blop; 5. Connections, as a representation of matched ports.

Blop Agent Port Connection Event

Fig. 1.

The Key Components of the Coordination Language STL++.

2.1 Blops Blops are an abstraction for an agglomeration of agents and blops to be coordinated and serve as a separate name space for ports, agents, and subordinated blops as well as an encapsulation mechanism for events. Blops enable structured hierarchical sets of agent environments to be set up, each of which being a private coordination space with communication interfaces (ports) to other environments. A blop inherits from the base class Blop and has to reimplement the start() method. The user must call Blop::start() for initialization. The creation of a blop results in the initialization of all enclosing blops, ports and agents. Blops can be parameterized. 2

Feature

Values

Explanation

Communication blackboard, stream, group Basic communication paradigms. Msg. Synchronization synchron, asynchron Message passing semantics. Orientation in, out, inout Direction of the data ow. Saturation {1,2,...,INF} Number of connections a port can have. Data Type typeName Type of data owing through a port. Lifetime {1,2,...,INF} Number of data units that can pass through a port before it decays. Table 1.

Port Features

2.2 Agents An agent has a name and a set of ports (which can be empty). It exclusively communicates anonymously through its ports. So, an agent does not have to care about to which agent information will be transmitted or received from. Agent classes inherit from the base class Agent and have to reimplement the start() method. Agents can be created directly by blops, through events or by other agents. An agent is initialized with Agent::start(). To communicate, agents dynamically create ports of prede ned types through instantiation of a port class.

2.3 Ports Ports are the interfaces of agents and blops to establish connections to other agents/blops. Ports have one or several names and a set of well de ned features describing the port's characteristics (see Table 1). The combination of port features results in a port type. Names and type of a port are referred to as the port's signature. The primitives for accessing data via ports are: get (blocking): put (nonblocking, except for synchronous ports); and read (blocking), only for blackboard ports. Four basic port types are de ned, resulting in four connection types. To ease the implementation, two base port classes for every port type have been de ned, one for agents and one for blops. { Blackboard ports (BB Port and BB Blop Port classes). The resulting connection has a blackboard semantics. Messages are persistent objects which can be retrieved using a symbolic name. An agent reading/writing a message does not have to be aware of the agent that has written or that will read this message. Moreover, messages are not ordered. { Group ports (Group Port and Group Blop Port classes). The resulting connection has a closed group semantics. Each member of the group can broadcast asynchronously messages to every participant in the group. Messages are stored at the receiver side. Thus, if a port in a group disappears, then the sequence of information that has not been read is lost. 3

{ S-Stream

ports (S inPort,

S outPort, S Blop inPort and classes). The resulting connection has the same semantics as the S-Channel de ned in [1] (S for synchronous). This connection always results from the matching of uni-directional contradictory oriented ports. In contrast to other connections, this connection never contains data, due to its synchronous nature. { KK-Stream ports (KK inPort, KK outPort, KK Blop inPort and KK Blop outPort classes). The resulting connection has an analogous semantics to the asynchronous KK-Channel de ned in [1] (K for keep), with its speci c semantics (see below) when a port disappears from one end of the connection. As for S-Streams, this connection always results from the matching of contradictory oriented ports. If the connection is broken at its consuming port, the next new matching port will consume all pending data. If the connection is broken at its producing port, the consuming port will be able to continue to consume all data in the connection. If both ports are deleted, the connection disappears with its data. S Blop outPort

2.4 Establishing Connections between Agents

Features of pairs of ports must comply with each other for ports to match (for detail on port compatibility, see [8]). Furthermore, four general conditions must be ful lled for two ports to get matched: (1) both use the same communication paradigm (stream, group or blackboard); (2) both have at least one common name; (3) both belong to the same level of abstraction ; and (4) both belong to dierent objects (agent or blop). Conceptually the matching of agent ports can be described as follows. When an agent is created in a blop, it creates with its port signature a \potential" in the blop where it is currently embedded. If two compatible potentials exist in the blop, and if conditions (1)-(4) are ful lled, the connection between the corresponding ports is established and the potentials disappear.

2.5 Events

Events can be attached to conditions on ports (see table 2 for an overview on conditions). A condition determines when the event is triggered. Event classes inherit from Event; the launch() method, which de nes the acting of the event, must be reimplemented. Conditions on ports are checked when data ow through the port. Events are instantiated with a speci c lifetime which determines how many times they can be triggered.

3 Simulation of a Trading System

Figure 2 shows how STL++ can be applied to implement the simulation of the automation of a trading system. 4

Condition

Explanation

UnboundCond() SaturatedCond() MsgHandledCond(int n) AccessedCond(p) PutAccessedCond(p) GetAccessedCond(p) TerminatedCond()

Port not connected. Port saturated. Port has handled n messages. Port accessed. Port accessed with put primitive. Port accessed with get primitive. Port lifetime is over.

Table 2.

Port Conditions

The numerous activities that take place within a trading system are typically distributed and can be modelized by a multi-agent system. Our aim here is not to focus on the control algorithms of the dierent agents, nor on the negociation techniques (see e.g. [4]) that are undertaken by the agents in order to process a transaction, but rather to concentrate on the basic coordination mechanisms that come into play in the interactions between agents. These aspects (negotiation and control algorithms) will be tackled in a next stage. In this implementation, agents are autonomous [10] in the sense that they can make decisions on their own, without user intervention. We brie y describe the organization of the agents in our trading system and their interactions. Company or private customers (end-user agents) create trade queries to buy or sell goods. These queries are written on a speci c port and transmitted to a trading system blop (TSB). In the TSB, brokers handle their customer's demands and delegate new broker assistants to do the negotiation of a unique trade: for every query posted by the broker to its trade P port, so as to be published in the trade unit blackboard, the NewBrokerAss Evt event is triggered; the role of this event is to dynamically create a broker assistant that will be in charge of nalizing the trade. Each trade is supervised by the trade manager. After a successfull trade, both implicated assistant brokers exchange useful information through dynamically created connections, and inform their respective customers of the result.

4 Conclusion STL++ is a coordination language which provides a coordination framework for

distributed multi-agent applications. It oers tools to describe the organizational structure or architecture of a MAS, with means to dynamically recon gure it. STL++ is still to be extended in order to encompass as many generic coordination patterns as possible, yielding in templates at disposal for general purpose implementations. We plan also to realize a new STL++ mapping in Java, using the JavaSpaces API [9]; on this platform should be implemented a distributed trading system accessible via the Web. 5

References 1. F. Arbab. The IWIM Model for Coordination of Concurrent Activities. In Paolo Ciancarini and Chris Hankin, editors, Proceedings of the First International Conference on Coordination Models, Languages and Applications, number 1061 in LNCS. Springer Verlag, April 1996. 2. N. Carriero and D. Gelernter. Linda in Context. Communications of the ACM, 32(4):444{458, 1989. 3. N. Carriero and D. Gelernter. Coordination Languages and Their Signi cance. Communications of the ACM, 35(2):97{107, February 1992. 4. A. Chavez and P. Maes. Kasbah: An Agent Marketplace for Buying and Selling Goods. In Proceedings of the First International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, London, UK, April 1996. Lawrence Erlbaum. 5. O. Krone, F. Chantemargue, T. Dagae, and M. Schumacher. Coordinating Autonomous Entities with STL. The Applied Computing Review, Special issue on Coordination Models Languages and Applications, 1998. To appear. 6. T.W. Malone and K. Crowston. The Interdisciplinary Study of Coordination. ACM Computing Surveys, 26(1):87{119, March 1994. 7. G.A. Papadopoulos and F. Arbab. Coordination Models and Languages. In M. Zelkowitz, editor, Advances in Computers, The Engineering of Large Systems, volume 46. Academic Press, August 1998. 8. M. Schumacher, F. Chantemargue, O. Krone, and B. Hirsbrunner. STL++: A Coordination Language for Autonomy-based Multi-Agent Systems. Technical report, Computer Science Department, University of Fribourg, Fribourg, Switzerland, March 1998. 9. Sun Microsystems, Inc. Java Space TM Speci cation, Revision 1.0, March 1998. 10. T. Ziemke. Adaptive Behavior in Autonomous Agents. Autonomous Agents, Adaptive Behaviors and Distributed Simulations' journal, 1997.

This article was processed using the LATEX macro package with LLNCS style

6

TradeWorld Trading System Blop (TSB)

Trade Manager trade_P

Trade Unit Blackboard

NewBrokerAss_Evt

trade_P

trade_P

Broker

Broker Assistant

query_P

result_P

off1_query_gate_P

trade_partner_i_P

trade_partner_o_P

trade_P

Broker query_P

trade_partner_i_P result_P

off1_res_gate_P

query_gate_P

trade_P

Broker Assistant

trade_partner_o_P

off2_query_gate_p

off2_res_gate_P

result_P

result_gate_P

query_P

Private Customer query_P

Secretary result_P

query_P

BB Transaction Results

Company Customer result_P

Trade Member Company Blop

Fig. 2.

Trading System with STL++.

7