Home | Search | Help  

 

West2East:
Exploiting WEb Service Technologies
to Engineer Agent-based SofTware







 

Description

 

Printable version (.pdf file)

 

1 Introduction

The realisation of distributed, open, dynamic, and heterogeneous software systems is a challenge that involves most industries producing applications for sensors and mo­bile networks, pervasive and grid computing, e­commerce, e­health, and for many other domains. The Internet is often used as the communication infrastructure for exchang­ing both data and services among the individual applications that constitute complex systems.

Agent­Oriented Software Engineering (AOSE) studies how existing techniques can be adapted or extended in order to engineer this kind of complex distributed systems, and offers methodologies, notations, and techniques suitable for analysing, modelling, prototyping and nally implementing them following the “Multiagent System” (MAS) metaphor. On the other hand, Web Services (WSs) provide an already available and widely accepted infrastructure for supporting interoperable machine­to­machine inter­action over a network, allowing heterogeneous software applications written in various programming languages and running on various platforms both to expose themselves as WSs, and to use other WSs.

Currently, many AOSE methodologies (for example, Gaia, Zambonelli et al. (2003)), notations (such as AUML, Bauer et al. (2000)) and projects (the “Flexible and Robust Protocol­Based Interaction between Agents in Open Systems1” and “Societies Of Com­puteeS (SOCS)2, just to cite two recent ones) take interaction among agents as their starting point for engineering complex systems. To quote Ciancarini and Wooldridge (2000), in fact, “it is now widely recognised that interaction is probably the most im­portant single characteristic of complex software.”

Unfortunately, mainly due to the lack of industrial strength Computer­Aided AOSE tools, many results achieved within the AOSE community remain conned to the aca­demic world, while industrial practitioners continue to use classical SE approaches that often do not suit well for the requirements of nowadays’ complex applications. Web Services technologies suffer from the opposite problem: despite they are already well known and accepted by the industry, their implementation often lacks a solid engineer­ing background that academic research might offer.

This paper describes “West2East”, a prototypical Computer­Aided AOSE tool that exploits “WEb Service Technologies to Engineer Agent­based SofTware”, and that aims at making a step towards bridging the gap between academic research on AOSE, and industrial practice with WSs. In particular, West2East helps the systems developer in moving from the analysis and design of open MASs, carried out following AOSE methodologies, to their implementation and deployment. West2East offers facilities for enabling the implemented agents to learn how to interact with other agents and to reason about these interactions. The applicability of West2East is not limited to MASs based on the WSs technological infrastructure, although this was its initial purpose. Indeed, we have used it for implementing a MAS in the JADE agent platform, Bellifemine et al. (2000), and we envisage that its adoption in conjunction with other infrastructures and platforms may be also feasible.

West2East builds upon three technologies: Intelligent Agents, Web Services, and Computational Logic (CL).

The literature in the agents’ eld devotes much space to exploring the relationships between agents and WSs. The most well settled opinions are that WSs provide the infrastructure and agents provide the coordination framework, Walton (2005); Buhler and Vidal (2005); Bozzo et al. (2005), and that WS and agent technologies are related by the common goal of providing tools, languages, and methods necessary for engineering systems that behave in a correct way, for example w.r.t. a given interaction protocol, Baldoni et al. (2005). Our position integrates both points of view. We think that, besides the coordination framework, agents also provide the metaphor that can be exploited for engineering and correctly implementing MASs based on the WSs infrastructure. Based on this claim, we propose to use AUML to model interaction protocols, and WS­BPEL – OASIS WSBPEL Technical Committees (2006) – plus WSDL – Web Services Description Working Group (2006) –, besides other notations, to share the specication of these protocols.

If we view agents as a design metaphor, the relationship between them and CL sug­gests itself. As pointed out in Ciancarini and Wooldridge (2000), in the AOSE field formal methods are used in the specification of systems, for directly programming sys­tems, and in the verification of systems. CL can be very effective for fitting all three roles above. In fact, if an agent is specified by means of a logic­based program, a work­ing prototype of the given specification is immediately available and can be used for early testing and debugging the specification. The distinction between specifying and directly programming an agent is thus blurred. Moreover, the model checking approach to verification can be adopted to show that the agent implementation is correct with re­spect to its original specification. The fervid activity in this area is demonstrated by the success of many workshops, such as CLIMA3 and DALT4. Various surveys and mono­graphic collections on this topic are also available, such as Sadri and Toni (1999); Dix et al. (2003); Mascardi et al. (2004).

Finally, CL has been used for representing, composing, and reasoning about inter­action protocols for a long time, Bozzano and Delzanno (2002, 2004); Baldoni et al. (2003); Alberti et al. (2004). In order to make complex interaction among WSs possi­ble, it is necessary to define the sequence and conditions under which WSs exchange messages in order to perform a task to achieve a goal state. The message sequenc­ing and associated logic, named “choreography” in technical words, may be fruitfully represented and verified adopting CL, Alberti et al. (2006). CL is also suitable for deal­ing with WSs composition, Rao et al. (2004); McIlraith (2004), and selection, Baldoni et al. (2006). Our usage of CL in West2East is related both to rapid prototyping, since West2East offers facilities for automatically generating Prolog code starting from the protocol specification, and to verification of interaction protocols, since it exploits Pro­log meta­programming facilities for reasoning on the protocol itself in order to check whether some given condition on the protocol holds.

The paper is organised as follows: Section 2 provides an overview of West2East, while Section 3 explains why and how we use AUML for representing AIPs. Sections 4 to 6 describe the translation, code generation, and reasoning functionalities offered by West2East, respectively. An example of MAS engineered using West2East is discussed in Section 7, whereas Section 8 deals with related work and concludes. The reader is assumed to have some basic knowledge of WSDL, WS­BPEL, and Prolog.

 

2 The West2East toolkit

West2East is a prototypical Computer­Aided AOSE tool. It is available to the research community5, and provides a set of functionalities to the MAS developer aimed at mak­ing the engineering and implementation of interaction within a MAS faster, easier, and less error prone than if performed entirely by hand. In particular, West2East offers li­braries for the automatic translation of AIPs represented in AUML into a) a textual notation proposed by Winikoff; b) an XML notation proposed by ourselves; c) a couple of WS­BPEL and WSDL documents; and d) a Prolog term (Figure 1). It also offers e) a mechanism for allowing agents that read a published AIP to reason about it before engaging in a dialog with its publisher, and f) libraries for the automatic generation of an executable program compliant to the original interaction protocol (Figure 2).

Fig. 1. Translation functionalities of West2East

Fig. 2. Reasoning and execution functionalities of West2East

The MAS scenario that we address is inspired by the provider/consumer model described by Luck et al. (2005): “an agent­oriented view of web services is gaining increased traction and exposure, since provider and consumer web services environ­ments are naturally seen as a form of agent­based system.” We extend this point of view since we have provider and consumer agents instead of WSs, the good that is pro­vided/consumed is a service that may be accessed by following a given AIP, and the AIP may be represented either using WS­BPEL and WSDL, like in any standard application based on WSs, or using other languages that might be preferred by the agents’ devel­opers in specic domains or situations. Thus, our MASs are composed by agents that publish AIPs, named publishers or providers, and agents that read AIPs, named read­ers or consumers. Our reference scenario is an open system: the languages in which agents are implemented may be different, as well as their internal architecture and be­haviour. The only features that two agents need to share for being able to interact are the ability to understand the languages in which the AIP is represented (if these lan­guages are WSDL and WS­BPEL, this requirement may be easily met since they are based on XML), and the parameters that must be shared in any communication between agents, namely the agent communication language, the message content language, and the ontologies to which messages refer.

Engineering the publisher agent requires that the MAS developer follows a set of steps leading to the description of the AUML AIP the publisher wants to be respected for offering its services. There are many AOSE methodologies that show how to de­sign an AIP in AUML starting from the analysis of the system: Gaia, Zambonelli et al. (2003); Cernuzzi and Zambonelli (2004), INGENIAS, G´omez­Sanz and Pav´on (2005), Prometheus, Padgham and Winikoff (2002), ROADMAP, Juan et al. (2002), and Tro­pos, Bresciani et al. (2004), are just some of them. We assume that the publisher’s developer takes advantage of one of the existing methodologies and tools for engineer­ing the AIP in the correct way; West2East comes into play at this point. In fact, it can be used to generate, from the AUML AIP, the corresponding representation in one of the four notations introduced above, and discussed in detail in Section 4. In order to be accessed by the reader agent, the resulting document must be published in some ad­hoc repository. Besides for generating the document representing the AIP, West2East may be also used for automatically generating the code that corresponds to the AIP itself (Section 5).

As far as the reader is concerned, it reads the AIP document published by the provider, in order to “learn” the communication protocol to follow for obtaining the service. In this case, West2East can be used both for generating the executable code corresponding to the AIP, starting from the document retrieved from the repository, and for reasoning about it and deciding if and when it is appropriate to engage in a dialog with the publisher, as discussed in Section 6.

In order to use West2East, the MAS developer must be aware of the following fea­tures:

 

– First, any AIP must involve only two agents, the publisher and the reader. A pub­lisher may provide and publish as many services as it wants, and a reader may interact with as many publishers as it wants. Besides this, the agent that plays the reader role in AIP P1 may play the publisher role in AIP P2, and vice versa. In fact, the pieces of code that are automatically generated for each AIP and for each role do not interfere with the ones generated for other AIPs and other roles. This makes the MASs that we are able to engineer similar to provider/consumer applications, where both the publisher­provider and the reader­consumer may interact with more than one consumer (resp. provider) fol­lowing different interaction protocols. However, an agent can neither be both a provider and a consumer within the same AIP, nor a consumer (resp. provider) for more than one provider (resp. consumer) within the same AIP. Also, interleaved execution of two or more AIPs is not allowed. We are currently working for overcoming these limitations.

 

– Second, West2East can generate code in an automatic way starting from the AUML specication, from the XML one, from the Prolog one, and from the WSDL and WS­BPEL one, but not from documents in Winikoff’s textual notation. The im­plementation of a bidirectional translation facility from any supported notation to any other, that would eliminate this limitation, is under way.

 

– Third, the generated code is written in Prolog, and is ready to be run inside the JADE agent platform. Although it can be executed as it is (in which case, all the boolean guards present in the AIP are assumed to be satised, as better explained in Section 5), it would be much more useful for the MAS developer to edit it, manually insert a belief base (namely, a set of Prolog atoms) representing the initial mental state of the agent, and manually add the AIP boolean guards referring to the agent’s mental state, inside the generated code. This requires basic skills in Prolog programming that are seldom found in practitioners from the industry. A similar consideration holds for the reasoning stage, that is performed exploiting meta­programming facilities offered by Prolog and that requires to express the conditions upon which performing the reasoning, as Prolog terms. We are working both for making the underlying Prolog code as transparent to the MAS developer as possible, by means of an intuitive graphical interface, and for generating code in languages other than Prolog, rst of all Java.

 

By means of all the envisaged improvements, we hope to make West2East a tool useful not only for academic research, but also for industrial implementation of real MASs.

3 Visual representation of AIPs in AUML

We consider the AUML interaction diagrams proposed by the FIPA Modeling Technical Committee (2003) as our reference visual notation for AIPs.

As it is well known, AUML is a semi­formal graphical notation inspired by the UML standard, but aimed at not being restricted by UML. AUML, even if neither fully specied nor standardised, is widely adopted in the AOSE community: many AOSE methodologies use it as the basic notation technique, and some of the diagrams it pro­vides are embedded in open source academic AOSE applications.

Besides the advantages that motivate its success, AUML also presents some short­comings both from the semantic and the syntactic perspectives that have been partly overcome by recent notations (Sturm et al. (2003); Cervenka et al. (2005); Wagner (2004)). Most new notations take inspiration from AUML, but build on more solid technical foundations and are better specied and documented. Nevertheless, we take AUML as our reference notation because AUML AIPs are expressive enough to let us represent the most common interaction activities, and, although AUML semantics is given in natural language, it can be easily formalised as discussed in Cabac and Moldt (2004). Also, AUML AIPs can be drawn using most of the existing UML­based CASE tools and can thus be exported in XMI, Object Management Group (2005a); we exploit XMI for moving from AUML to the textual notations supported by West2East. Using tools for UML editing is possible because AIPs in AUML are based upon the same set of visual symbols used in UML 2.0 sequence diagrams, Object Management Group (2005b), even if some symbols take a different meaning in AUML.

To make an example of an AIP in AUML, Figure 3 describes a FruitMarket scenario where a fruit seller (the agent on the left, named fs, playing the role of fruitSeller and belonging to the fruitSellerClass) interacts with a fruit buyer (the agent on the right, named fb, playing the role of fruitBuyer and be­longing to the fruitBuyerClass). The content language is rst order logic, and we assume that an ontology named FruitMarketOntology contains all the informa­tion required by the agents to understand the content of the exchanged messages. Since it is becoming the de facto standard, we adhere to the FIPA­ACL message syntax, FIPA Technical Committee (2002); as a consequence, the ACL parameter always assumes the “FIPA­ACL” value in our diagrams, and we drop it from the diagram for readability.

 

 

 

Fig. 3. Fruit marketplace protocol in AUML

 

 

The message that res the protocol is a request from the buyer to the seller about the availability and price of a certain kind of fruit, represented by the logical variable F. According to the availability of the requested fruit, the seller can

 

either perform a sequence of activities (weak sequencing box) that consist in rst informing the buyer that fruit F is available, and then proposing to buy the fruit at price EuroForKg. At this point, the seller may expect two reactions from the buyer (alternative box):

the buyer prefers to decide the delivery and payment mode, rather then getting a discount. Thus, it sends two requests about the accepted delivery modes and payment methods, to which the seller answers with two lists of possibilities, and then the buyer either accepts the proposal, choosing one delivery method and one payment method among the possible ones, or refuses.

the buyer prefers to get a discount, also if this means that it will not be able to choose
the delivery and payment methods. Thus, it sends a call for proposal (cfp) to the seller,
asking to make another proposal with discounted price, and
xed delivery and payment
methods. The seller makes the proposal, and again, the buyer can either accept or refuse
it.


or it can inform the buyer that fruit F is not available, and, optionally (option box),
inform the buyer that another fruit F1 is available instead.

 

4 Translation functionalities

Since visual diagrams like AUML AIPs have been conceived and designed for facilitat­ing human beings, but are not suitable for being worked on by machines, we translate them into four different notations amenable for automatic processing. The “transla­tion library” has been developed in Java. It takes in input the XMI description and, by exploiting the Extensible Stylesheet Language Transformations (XSLT) technology, W3C Working Group (1999), extracts the relevant features of the represented AIP from it. These features are used to generate a document in our XML notation, and, from it, documents in Winikoff’s textual notation, in WS­BPEL and WSDL, and in Prolog. The library also allows to translate the couple of WS­BPEL and WSDL documents into a Prolog term. This WS­BPEL + WSDL Prolog translation takes advantage of JDOM6.

Fig. 4. Bidirectional translation between the different notations supported by West2East

We are currently extending the library in order to allow a bidirectional translation from any notation to any other among the supported ones, in order to reach the situation rep­resented in Figure 4 (dotted arrows are translation links not yet implemented). This will allow agents to easily switch from any notation to any other thus making interaction among them easier, and to exploit the code generation and reasoning functionalities offered by West2East also when the AIP is represented in Winikoff’s notation.

4.1 Winikoff’s textual notation

The textual notation proposed by Winikoff (2005) has a signicant scientic value per se as one of the rst textual notations for AUML together with the one proposed by Koning and Romero­Hernandez (2003). Besides this, it is integrated in the Prometheus Design Tool (PDT7) which offers the means for generating visual AUML diagrams from textual AIPs, thus complementing the functionalities offered by West2East.

PDT also supports code generation in JACK8, although at the moment this func­tionality does not look at the AIPs. PDT generates code for each agent, each capability, each plan, each event, and each data. It also generates events corresponding to percepts, and inserts some information corresponding to actions. Although this extension is not envisaged for the near future, AIPs might be used to help derive plans, so they would feed into code generation indirectly. In this case, West2East and PDT might be used in cascade ­with Winikoff’s textual notation as the bridge between them ­for generating JACK code compliant to an AUML diagram edited using any editor for UML 2.0.

Winikoff denes a textual AUML protocol as a sequence of commands (one per line). The rst line denes the name of the protocol (start name) and the last concludes the protocol (finish). Commands in between are used to dene agents (agent shortname longname), messages (message), start and end of boxes (box and end), types of the box (weak sequencing, alternative, option, etc), boundaries between regions within a box (next), guards (guard), continuations (goto and label), and the end of an agent’s participation in the protocol (stop).

We extend this textual notation with

– mandatory parameters (content­language and ontology ) – optional parameters (to be eventually dened by the developer)

– information on the agent class and role (the short name is always p for the pub­lisher and r for the reader, while the name is extracted by the AUML diagram) – optional content of the messages

 

A portion of Winikoff’s representation of the protocol depicted in Figure 3 is shown below.

start sd FruitMarket
FruitMarketOntology first order logic
agent­publisher p fs fruitSeller fruitSellerClass
agent­reader r fb fruitBuyer fruitBuyerClass

message r p request availability and price(fruit(F))

box alternative

box seq

message p r inform available(fruit(F))

message p r propose buy(fruit(F),price(EuroForKg))

box alternative

message r p request delivery modes

message p r inform delivery mode(ListOfModes)

message r p request accepted payment methods

message p r inform accepted payment methods(ListOfMethods)

...

 

 

4.2 Our XML notation

The advantages of using XML to exchange information are widely recognised. XML is highly interoperable, easy to read both for human beings and for machines, and many tools embed parsers for it. West2East offers the functionality to output an XML repre­sentation of the AIP that corresponds to Winikoff’s one, but has the advantage of not requiring any ad­hoc parser. A portion of the protocol depicted in Figure 3 is shown below. We think this notation, as Winikoff’s one, is self­explanatory, thus we do not further comment on it.

<?xml version="1.0" encoding="UTF­8"?>
<protocol­diagram­intermediate­notation xmlns:UML2="org.omg.xmi.namespace.UML2"
xmlns:UML="org.omg.xmi.namespace.UML">
<parameters> &lt;parameters&gt;

ontology = "FruitMarketOntology"

CL = "first order logic"
</parameters>
<protocol­name>

sd FruitMarket

</protocol­name>
<agent­publisher short­name="p">fs/fruitSeller:fruitSellerClass</agent­publisher>
<agent­reader short­name="r">fb/fruitBuyer:fruitBuyerClass</agent­reader>
<main­interaction­fragment>

<combined­fragment>
<type>seq</type>
<guard/>

<fragment>

<message>
<sender>reader</sender>
<communicative­act>request</communicative­act>
<content>availability and price(fruit(F))</content>

</message>
</fragment>
...

 

 

4.3 WSDL and WS­BPEL

We have already anticipated in Section 1 the need and the usefulness of a bridge be­tween AOSE methodologies and notations, and the WS infrastructure. It is common opinion that both parties involved would benet from this bridge, and that the advan­tage of an integrated “AOSE + WSs” approach would be greater than the sum of the advantages of the two approaches taken in isolation. These considerations motivate the third translation functionality offered by West2East, namely the one whose target is a couple of WSDL and WS­BPEL documents. We assume that the reader has some famil­iarity with these two languages. Many introductory resources about them can be found on the Web9.

The suitability of WS­BPEL for representing AUML AIPs is supported by the close relationships between the constructs offered by WS­BPEL and those offered by AUML, summarised in Figure 5.

 

 

AUML

WS­BPEL

Roles

ag­name/ ag­role: ag­class box

myRole and partnerRole tags

Message

Labelled arrows between lifelines

invoke and receive

Content

Speech­act based

Unspecied

Sequence

Weak Sequencing

Sequence

Condition

Alternative

Switch

Option

Option

If

Cycle

Loop

While

 

Fig. 5. Correspondence between AUML and WS­BPEL concepts

AUML is an easily comprehensible visual language that allows to express the high level structure of interaction protocols, while WS­BPEL is a quite complex XML language suitable for expressing not only the high level structure of busi­ness processes involving a set of WSs, and consequently the interactions between them, but also details of message exchange, operations requested to the WSs, and guard con­ditions. WS­BPEL is thus powerful enough to represent all the information contained in AUML diagrams.

To make an example, the AUML protocol depicted in Figure 3 corresponds to the WSDL and WS­BPEL documents partly shown below.

WS­BPEL specication

1: <process xmlns="http://schemas.xmlsoap.org/..." ....>

2: <partnerLinks>

3: <partnerLink name="publisherPL" partnerLinkType="lns:SellerBuyer"
myRole="seller" partnerRole="buyer"/>

4: <partnerLink name="readerPL" partnerLinkType="lns:BuyerSeller"
myRole="buyer" partnerRole="seller"/>

5: </partnerLinks>

6: <variables>

7: <variable name="continue 1" element="lns:continue 1 type"/>

8: <variable name="choose 2" element="lns:choose 2 type"/>
....

13: </variables>

14: <copy><from opaque="yes"/><to>$continue 1.value</to></copy>

15: <while condition="$continue 1.value=true">

16: <sequence>

17: <receive partnerLink="publisherPL" portType="lns:publisherPT"
operation="RCV Mess 1" createIstance="yes"/>

18: <copy><from opaque="yes"/><to>$choose2.value</to></copy>

19: <switch>

20: <case condition="$choose2.value=1">
....
n­10: <if condition="$condition 6.value=true"/><then>
n­9: <invoke partnerLink="publisherPL" portType="lns:publisherPT"

operation="SND Mess 15"/>
n­8: <receive partnerLink="readerPL" portType="lns:readerPT"

operation="RCV Mess 15"/>
n­7: </then> </if>
n­6: </sequence>

n­5: </case>
n­4: </switch>
n­3: </sequence>
n­2: <copy><from opaque="yes"/><to>$continue 1.value</to></copy>
n­1: </while>

n: </process>

WSDL specication

j: <xs:element name="content of Mess 15" type="xs:string"

fixed="i may sell(fruit(F1))"/>
....

k: <message name="Mess 15">
k+1: <part name="performative" element="inform ca"/>
k+2: <part name="Participant" type="tns:Participant MsgFromPublisher"/>
k+3: <part name="Content" element="tns:content of Mess 15"/>
k+4: <part name="Content Language" element="tns:content language name"/>
k+5: <part name="Ontology" element="tns:ontology name"/>
k+6: <part name="Protocol" element="tns:protocol name"/>
k+7: </message>

For each condition to check in the AIP, a variable is dened in the WS­BPEL doc­ument (lines 6­13), to which opaque values (used by internal/private functions, as op­posed to transparent data relevant to public aspects) are associated (line 15, where the condition of the while activity, corresponding to the AUML Loop, is given a value; line 20, condition of the switch activity corresponding to the AUML Alternative; line n­10, condition of the if activity corresponding to the AUML Option). Since in an heterogeneous environment as a multiagent system is, it is not usually possible to know in advance which kind of conditions can be expressed and understood by the participants in a communication, the WS­BPEL document provides no details about conditions. The document just declares that at some point, someone will need to check a condition, and that this condition will need to be satised in order to allow the exe­cution of that protocol branch (condition = "$continue 1.value = true", for example).

Apart from the rst message of the protocol, that, according to the WS­BPEL spec­ication, must be received by the publisher of the document, the points of view of both the publisher and the reader are taken into account when describing communicative ac­tions. For example, lines n­9 and n­8 describe the delivery of the message identied by the number 15 from the publisher to the reader, both from the publisher’s view­point, and from the reader’s one. The WSDL document describes the details of each exchanged message: for example message 15 has an inform performative (line k+1) and i may sell(fruit(F1)) content (line j).

 

 

4.4 Prolog

 

The last translation functionality offered by West2East goes from AUML to Prolog. The choice of this language was driven by the code generation and reasoning functionali­ties that, for the moment, are implemented in Prolog and thus were easier to program starting from a Prolog term rather than from any other notation. Another reason was the possibility to use a Prolog­based model checker like LMC10 to verify properties of the AIP, using techniques alternative to those described in Section 6. We have not yet started to experiment LMC, but we trust that adapting our Prolog notation to it will require a small effort.

To give the avor of the Prolog notation, a fragment of the FruitMarket AIP is in­cluded below. We think that any reader with a basic knowledge of rst­order logic can understand this representation, since it is just a syntactic variation of Winikoff’s and XML ones. The only difference that should be noted is the usage of JADE agent iden­tiers for the publisher’s and reader’s short names (’seller@giocas:1099/JADE’ and ’buyer@giocas: 1099/JADE’ respectively). These identiers must be added by hand by the MAS developer, if she wants to automatically generate the Prolog code of the two agents in such a way that they can be run (eventually without any modication) inside JADE.

process( parameters(ontology(’FruitMarketOntology’),content language(’first order logic’)), protocol name(’sd FruitMarket’), agent publisher(short name(’seller@giocas:1099/JADE’),long name(’fs/fruitSeller:

fruitSellerClass’)), agent reader(short name(’buyer@giocas:1099/JADE’),long name(’fb/fruitBuyer: fruitBuyerClass’)), main fragment(

while(no guard,
seq([
send(msg(’REQUEST’,’availability and price(fruit(F))’)),
switch([

case(no guard,

seq([ receive(msg(’INFORM’,’available(fruit(F))’)),
receive(msg(’PROPOSE’,’buy(fruit(F),price(EuroForKg))’)),
switch([

case(no guard,
seq([
send(msg(’REQUEST’,’delivery modes’)),
receive(msg(’INFORM’,’delivery mode(ListOfModes)’)),
send(msg(’REQUEST’,’accepted payment methods’)),
receive(msg(’INFORM’,’accepted payment methods(ListOfMethods)’)),
...

5 Automatic generation of the protocol­-compliant code

Automatic generation of code from specications allows the MAS engineer to save programming time and thus to concentrate on the engineering stages that require more brainpower. West2East offers a “Prolog­oriented” code generation functionality; the generation of a Prolog program starts from the Prolog representation of the AIP, and a nite state machine corresponding to the AIP is simulated by the generated clauses. States are meaningless terms only used to enforce the correct transitions, and transitions correspond either to communicative actions, or to check of conditions. Although the generated clauses have a very simple structure (exec(FromState) :­Transition, exec(ToState), where Transition may also be the null one, thus leading to even simpler clauses, exec(FromState) :­exec(ToState)), some background on Pro­log programming might help to face this and the next sections.11

According to the nature of AIPs we consider, transitions can be of four kinds: send transition, receive transition, check transition and null transition. The initial and nal fragments of the Prolog code corresponding to the protocol depicted in Figure 3 are shown below (the clause numbers written in italic are not part of the code). Note that we did not take care of efciency in the development of this prototype: states can become very long terms, and no optimisations are made in implementing the transitions.

clause 1: exec(s(’sd FruitMarket’,0)) :­check guard(s(’sd FruitMarket’,0), no guard), exec(s(s(’sd FruitMarket’,0),0)).

clause 2: exec(s(’sd FruitMarket’,0)) :­exec(s(’sd FruitMarket’,final)).

clause 3: exec(s(’sd FruitMarket’,1)) :­exec(s(’sd FruitMarket’,0)).

clause 4: exec(s(s(’sd FruitMarket’,0),0)) :­
exec(s(s(s(’sd FruitMarket’,0),0),0)).

clause 5: exec(s(s(s(’sd FruitMarket’,0),0),0)) :­send(’REQUEST’,’availability and price(fruit(F))’,’seller@giocas:1099/JADE’), exec(s(s(s(’sd FruitMarket’,0),0),1)).

clause 6: exec(s(s(s(’sd FruitMarket’,0),0),1)) :­
check guard(s(s(s(s(’sd FruitMarket’,0),0),1),0), no guard),
exec(s(s(s(s(’sd FruitMarket’,0),0),1),0)).

clause 7: exec(s(s(s(s(’sd FruitMarket’,0),0),1),0)) :­
exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),0)).

clause 8: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),0)) :­
receive(’INFORM’,’available(fruit(F))’,’seller@giocas:1099/JADE’),
exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),1)).

clause 9: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),1)) :­receive(’PROPOSE’,’buy(fruit(F),price(Euro))’,’seller@giocas:1099/JADE’), exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),2)).

...................

clause n­3: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1)) :­
check guard(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1),no guard),
exec(s(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1),0)).

clause n­2: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1)) :­
exec(s(’sd FruitMarket’,1)).

clause n­1: exec(s(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1),0)) :­
receive(’INFORM’,’i may sell(fruit(F1))’,’seller@giocas:1099/JADE’),
exec(s(’sd FruitMarket’,1)).

clause n: exec(s(’sd FruitMarket’,final)) :­true.

The predicate check guard(State,Guard) (clauses 1, 6 and n­3) characterises a check transition, and succeeds if call(Guard) succeeds. Since no guards were spec­ied by the original AIP, their translation is always no guard, and call(no guard) succeeds. The check guard(State,Guard) atom may be manually edited by the de­veloper for inserting the conditions that depend on the agent’s belief base (also to be manually added to the generated code).

The predicate send in clause 5 (resp., receive, in clauses 8, 9 and n­1) charac­terises a send transition (resp., a receive transition). These communication predicates are implemented by the DCaseLP library, Gungui et al. (2005), that provides an inter­face between the tuProlog implementation of a Prolog interpreter, Denti et al. (2005), and the communication facilities offered by JADE.

The predicate that performs the generation of the code, takes the initial and nal states of the transition, the identier of the agent, and the term representing the struc­tured activity to translate, and returns a list of clauses that implement the transition. The state that represents the end of the protocol is identied by the constant final.

The demonstration of exec(s(ProtocolId,final)) always succeeds (clause n).

– Translating cycles. A while(Guard,WhileActivities) action performed in the state s(S,I) for reaching the state SFinal, is translated into

 

clause a: exec(s(S,I)) :- check_guard(s(S,I), Guard), exec(s(s(S, I), 0)).

clause b: exec(s(S,I)) :- exec(SFinal).

clause c: exec(s(S, I1)) :- exec(s(S,I)).

 

clauses that translate the WhileActivities from s(s(S, I), 0) to s(S, I1)

 

Our fruit market AIP starts with a while activity performed in the state s(’sd Fru­itMarket’,0) for reaching the state s(’sd FruitMarket’,final). Clause 0 of our code fragment corresponds to the rst clause of the translation of the while activity (clause a); clause 2 corresponds to clause b; and clause 3 to clause c. All the remain­ing activities of the protocol correspond to the WhileActivities, and they will need to end with reaching state s(’sd FruitMarket’,1) (corresponding to s(S,I1) in clause c). When discussing the translation of options, we will see that this truly happens.

 

– Translating communication actions. A communication action (where communi­cation may be either send or receive) performed in the state s(S,I) for reaching the state SFinal, is translated into the clause

 

clause a: exec(s(S, I)) :­communication(Perform,Cont,Addr), exec(SFinal).

 

Examples of this translation are clauses 5, 8, 9, and n­1.

 

– Translating sequences. A seq([Activity0, ..., ActivityN]) action per­formed in the state s(S,I) for reaching the state SFinal, is translated into

 

clause a: exec(s(S,I)) :­exec(s(s(S,I),0)).

Clause that translates Activity0 from s(s(S, I),0) to s(s(S,I),1)
Clause that translates Activity1 from s(s(S, I),1) to s(s(S,I),2)

....

Clause that translates ActivityN from s(s(S,I),N) to SFinal

 

An example of this translation are clauses 4 and 5. The state s(S, I) from which the translation starts is s(s(’sd FruitMarket’,0),0) (S = s(’sd FruitMarket’,0); I = 0) and the state to reach is s(’sd FruitMarket’,1). Clause 4 corresponds to clause a, while clause 5 corresponds to the translation of the rst activity within the sequence, send(’REQUEST’,’availability and price(fruit(F))’,’seller@gio­cas:10­99/JADE’), from s(s(S,I),0) to s(s(S,I),1). Clause n­1 corresponds to the very last activity in the sequence. Also clauses 8 and 9 translate two items of a sequence,
started in clause 7.

– Translating alternatives. A switch([case(Guard0,Activity0), ..., ca­se(GuardN,ActivityN)]) action performed in the state s(S,I) for reaching the state SFinal, is translated into

 

clause a: exec(s(S,I)) :­check guard(s(s(S,I),0),Guard0), exec(s(s(S,I),0)).

Clauses that translates Activity0 from s(s(S,I),0) to SFinal

....
clause z: exec(s(S,I)) :­check guard(s(s(S,I),N),GuardN), exec(s(s(S,I),N)).

Clauses that translates ActivityN from s(s(S,I),N) to SFinal

 

Clause 6 is an example of translation of a switch activity, and corresponds to clause a. Clauses 7, 8, 9 and successive ones correspond to the alternative branch where the fruit is available; another clause with the same head exec(s(s(s(’sd FruitMarket’,0), 0),1)) as clause 6, not shown in the program fragment, corresponds to clause z, namely to the alternative branch where the fruit is not available.

 

– Translating options. An if then(Guard,Then activities) action performed in the state s(S,I) for reaching the state SFinal, is translated into

 

clause a: exec(s(S,I)) :­check guard(s(S,I),Guard), exec(s(s(S,I),0)). clause b: exec(s(S,I)) :­exec(SFinal).

Clauses that translate ThenActivities from s(s(S,I),0) to SFinal

 

Clauses m­3 and m­2 correspond to clauses a and b respectively, where s(S,I) corre­sponds to s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1) and SFinal to s(’sd FruitMarket’,1). ThenActivities correspond to the reception of the message ’i may sell(fruit(F1))’, after which the agent moves to s(’sd FruitMarket’,1) (clause m­1), as anticipated when we introduced the translation of cycles.

Both the publisher and the reader may take advantage of the automatic code gen­eration functionality. In fact, given the same Prolog AIP (that can be obtained directly from the AUML AIP by the publisher, and from any textual representation of the AIP but Winikoff’s one by the reader), the only difference between the code generated by the publisher and that generated by the reader is a swap of senders and receivers inside exchanged messages. The West2East library for generating code has the agent role (ei­ther publisher or reader) among its parameters, and thus it can produce the right code using the same algorithm.

6 Reasoning about the protocol

The reasoning functionality offered by West2East can be exploited by both the publisher and the reader, but it makes sense only for the latter one, since the publisher is expected to publish an AIP designed to meet its requirements.

In order to perform the reasoning stage, the Prolog program generated by West2East must contain the fact condition to check(Condition). Condition must be in­stantiated with exists(Action), forall(Action), or no cond (the default for this fact, meaning that no checks on the protocol are made). Action may correspond to one of the transition types, send, receive, check. The reader agent may thus check that there is one possible path where (resp. in any possible path) a send(Performative,Content,Re­ceiver), or a receive(Performative,Content,Sender), or a check guard(Sta­te,Guard), is executed. If the condition is satisfied, the reader agent engages in a dia­log with the publisher trying to enforce the execution of the “right” path, as long as the choice is up to it12.

To go on with our fruit market example, let us consider a “restrictive” fruit buyer agent that accepts to interact with the fruit seller agent only if it provides ­whatever the protocol branch followed ­a bunch of payment methods among which the buyer can choose. The fruit buyer agent’s code should contain the fact: condition to check(forall(re­ceive(’INFORM’,’accepted payment methods(ListOfMethods)’,Sender))).This condition is not verified by the protocol depicted in Figure 3, as it can be easily seen. Thus, the “restrictive” fruit buyer agent would not even start the protocol execu­tion.

However, a “flexible” fruit buyer might just want to check if, in the best case, the fruit seller would allow it to choose among more than one payment method. The buyer might force the execution of the protocol branch where this possibility takes place, as long as the choice is up to it, but it might also be ready to accept that the seller, at some point in the protocol execution, acts in such a way that the execution of the desired ac­tion can no longer take place. The condition to check for the “flexible” agent would be

exists(receive(’INFORM’, ’accepted payment methods(ListOfMethods)’, Sender)). The protocol does verify this condition, and the buyer agent would start the protocol execution.

While executing, the buyer explains its actions by printing them on a log le:

I will try to enforce the following path, as long as the choice is up to me

check guard(s(’sd FruitMarket’,0),no guard)
send(’REQUEST’,’availability and price(fruit(F))’,’seller@giocas:1099/JADE’)
check guard(s(s(s(s(’sd FruitMarket’,0),0),1),0),no guard)
receive(’INFORM’,’available(fruit(F))’,’seller@giocas:1099/JADE’)
receive(’PROPOSE’,’buy(fruit(F),price(EuroForKg))’,’seller@giocas:1099/JADE’)
check guard(s(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),2),0),no guard)
send(’REQUEST’,delivery modes,’seller@giocas:1099/JADE’)
receive(’INFORM’,’delivery mode(ListOfModes)’,’seller@giocas:1099/JADE’)
send(’REQUEST’,accepted payment methods,’seller@giocas:1099/JADE’)
receive(’INFORM’,’accepted payment methods(ListOfMethods)’,’seller@giocas:1099/JADE’)

I executed the statement check guard(s(’sd FruitMarket’,0),no guard)
.........

Nondeterministic action: I received the message I was waiting for, namely
(’INFORM’,’available(fruit(F))’,’seller@giocas:1099/JADE’)
.........

Nondeterministic action: I received the message I was waiting for, namely
(’INFORM’,’delivery mode(ListOfModes)’,’seller@giocas:1099/JADE’)

I executed the statement
send(’REQUEST’,accepted payment methods,’seller@giocas:1099/JADE’)

Nondeterministic action: I received the message I was waiting for, namely
(’INFORM’,’accepted payment methods(ListOfMethods)’,’seller@giocas:1099/JADE’)

I have reached my goal!

7 Engineering and Implementing a MAS exploiting West2East

In this section we discuss a possible usage of West2East for implementing a MAS. The textual representation of AIPs that we have chosen for this example is WSDL + WS­BPEL, and the infrastructure for running the MAS is JADE. An approach similar to that discussed in this section might be followed for implementing JADE agents that represent AIPs in any other notation among the supported ones, as well as for “non­JADE” agents, still implemented in Prolog, that use the infrastructure already available for WSs for advertising and exchanging services.

With this respect, it is interesting to note that many proposals for frameworks that integrate WSs and JADE can be found in the literature, for example Greenwood and Calisti (2004); Agentcities Task Force (2003); Thang and Kowalczyk (2005). Although West2East may prove useful for engineering agent systems based both on WSs and on JADE (and also JADE agent systems that exploit languages for WSs, as in this example), it is independent from any specic infrastructure.

To implement our publisher/reader MAS, we have developed a JADE Protocol Man­ager Agent (PMA) that, together with JADE’s Directory Facilitator (DF), allows agents to publish and retrieve WSDL + WS­BPEL specications representing AIPs.

 

Fig. 6. Activities for the development of a publisher agent in JADE using West2East

Fig. 7. Activities for the development of a reader agent in JADE using West2East

 

 

The development of the publisher agent must take the following activities into ac­count (see Figure 6):

 

p.0 design of an AIP in AUML following an AOSE methodology (outside the scope of West2East);

p.1 translation from the AUML visual diagram to the WSDL + WS­BPEL notation dis­cussed in Section 4.3;

p.2 advertisement of the WSDL + WS­BPEL document by exploiting the services of­fered by the DF and the PMA, as described later in this section;

p.3 translation from the AUML visual diagram to the Prolog notation discussed in Sec­tion 4.4;

p.4 generation of the Prolog code from the Prolog term representing the AIP, as de­scribed in Section 5;

p.5 execution of the Prolog code in JADE extended with the DCaseLP libraries.

The reader agent must be engineered in order to follow the steps shown in Figure 7:

 

r.1 interrogation of JADE’s DF and access to the repository managed by the PMA in order to retrieve the WSDL + WS­BPEL documents;

r.2 translation from the WSDL + WS­BPEL notation to the Prolog one;

r.3 generation of the Prolog code from the Prolog term;

r.4 reasoning stage discussed in Section 6;

r.5 execution of the Prolog code in JADE extended with the DCaseLP libraries.

 

Fig. 8. Our MAS implemented in JADE

For supporting the interaction between the publisher and the reader, we have de­signed and implemented the MAS depicted in Figure 8. We will name “Agent Services” both the general management services offered by JADE’s DF and by the PMA that we implemented, and the application specic services such as the fruit­selling ser­vice offered by the fruit seller and advertised by publishing the WSDL + WS­BPEL document discussed in Section 4.3.

The DF is provided by JADE, and offers a “yellow pages” service allowing agents to publish agent services, so that other agents can nd and exploit them. An agent wishing to publish a service must send information about itself and about the service it provides, to the DF. The DF is used in conjunction with the PMA that offers a service for the advertisement and retrieval of AIPs’ specifications, and stores the WSDL + WS­BPEL documents on a MySql DBMS13.

When the JADE platform is started, the PMA registers the protocol­publishing and the protocol­reading agent services to the DF (arrows 1 and 2 in Figure 8). When a publisher agent wants to advertise an agent service offered by means of an AIP initially specied in AUML, it

1.                generates the WS­BPEL + WSDL documents from the AUML AIP;

2.                looks in the DF to nd the protocol­publishing agent service (arrows 3, 4);

3.                sends a message to the PMA with the WSDL + WS­BPEL document, and waits to receive the protocol identier (PID) assigned by the PMA to it (arrows 5, 6);

4.                registers the agent service specied by the WS­BPEL document to the JADE DF (arrows 7, 8), adding the PID obtained by the PMA and the PMA address to the agent service properties.

 

When a reader agent looks for an agent service, it

1.                queries the DF to nd the required agent service (arrows 9, 10) obtaining the name and address of the publisher, the address of the PMA, and the PID that the PMA as­signed to the agent service (if they exist in the DF);

2.                sends a message to the PMA to obtain the WSDL + WS­BPEL document represent­ing the AIP (arrows 11, 12) and identied by the PID obtained in 1;

3.                from the WSDL + WS­BPEL specication, generates the corresponding Prolog term, and, from this, the Prolog code, and reasons about it;

4.                according to the reasoning outcome, eventually starts the protocol­compliant commu­nication in order to obtain the agent service (direct communication between the pub­lisher and the reader, represented by dashed arrows in Figure 8).

 

Fig. 9. Execution run in JADE

 

 

 

Figure 9 refers to an execution run of the MAS composed by one PMA, one reader, one publisher, and the DF. In this gure, corresponding to the example of Figure 3, the publisher plays the role of fruitSeller while the reader plays the role of fruitBuyer. The rst twelve messages correspond to the communication represented by the twelve solid arrows in Figure 8, while the other messages are exchanged during the exe­cution of the fruitMarket AIP, aimed at allowing the fruitBuyer to obtain the fruit­selling agent service from the fruitSeller. The execution run shown here corresponds to the situation where the conditions on the protocol execution put by the buyer are all met, and the seller’s proposal is accepted.

8 Related work and conclusions

The related work that we consider in this section deals with the three features that better characterise West2East: the exploitation of (A)UML for engineering WSs, the automatic generation of code starting from the AIP specication, and the capability of reasoning about AIPs.

As far as the rst feature is concerned, the literature describes many proposals of us­ing UML for modelling WSs. For example, Grønmo and Solheim (2004) and Bauer and Huget (2004) share the same purpose of exploiting UML for modelling WS composi­tion. Both of them propose extensions to UML when it does not provide enough support for the given purpose: those suggested by Grønmo and Solheim are within a composite WS model that represents a gas dispersion emergency case, but can be generalised to other domains, while those proposed by Bauer and Huget are agent­oriented ones. The paper by Provost (2003) discusses how to design WSs in UML, express their semantics in WSDL, and implement them in a supporting programming language. While no tools for generating the WSs specication from the UML one are described in these three pa­pers, Gardner (2003) describes a UML prole for automated business processes which allows BPEL4WS14 processes to be modelled using an existing UML tool and auto­matically mapped to BPEL4WS, and Mantell (2005) describes a tool which takes pro­cesses dened by UML activity diagrams and generates the corresponding BPEL4WS and WSDL les. The key difference between our work and both Gardner’s and Man­tell’s ones is that we translate interaction protocols represented as AUML protocol dia­grams (that are an extension of UML sequence diagram) into WS­BPEL abstract pro­cesses, while they start from UML activity diagrams and generate executable BPEL4WS processes. The tool for automatic generation referenced by both authors is the same, namely a plug­in integrated inside the Emerging Technologies Toolkit by IBM15, and no longer available.

The generation of executable code from an AUML specification has been dealt with by some papers and implemented toolkits, described for example in Dinkloh and Nimis (2003); Huget (2002); Gomez­Sanz and Pavon (2003); Rooney et al. (2004); Cabac and Moldt (2004), while the generation of code from WS­BPEL and UML 2.0 specifi­cations is already supported by many commercial tools. However, West2East purpose goes further beyond an (A)UML code or a WS­BPEL code translation, since it aims at making the MAS analysis and design, carried out following AOSE methodolo­gies, closer to its implementation and deployment. West2East offers functionalities for generating code also from textual representations of the AIP (different from UML or AUML), and can be used for generating a document in one of these textual notations starting from the visual AUML diagram, without necessarily generating the correspond­ing code. One possible usage of the AUML textual notations functionality has been discussed in Section 4.1, where we envisaged that, for example, West2East might be used in conjunction with PDT for generating JACK code from AUML visual interac­tion diagrams, using Winikoff’s notation as a bridge. Sections 4.2 to 4.4 highlight other possible usages and advantages.

Finally, the Prolog­related functionalities offer a suitable way to realise MASs in which new agents are able to learn how to interact with existing agents by reasoning about AIPs. These functionalities may be exploited for reasoning about AIPs in gen­eral, but can also be used to reason about WSs, in particular. The need of reasoning about WSs is extremely pressing, since the full exploitation of the WS technology re­quires to address issues of security and privacy protection, that West2East reasoning mechanism, although simple, may help to cope. We represent AIPs using languages for WS orchestration, namely WSDL and WS­BPEL, thus complementing many proposals that can be found in the literature where AIPs are described by means of choreography languages. For example, Baldoni et al. (2005) propose an approach to the verification of a priori conformance of a business process to a protocol, which is based on the theory of formal languages and guarantees the interoperability of agents that are individually proved to conform to the protocol. Brogi et al. (2004) formalise the WSCI language, W3C Web Services Choreography Working Group (2002), and discuss the benefits that can be obtained by such formalisation, in particular the ability to check whether two or more WSs are compatible to inter operate or not, and, if not, whether the specifica­tion of adaptors that mediate between them can be automatically generated. A unifying view of orchestration and choreography is suggested by Busi et al. (2005) that define a notion of conformance between choreography and orchestration which allows to state when an orchestrated system conforms to a given choreography. Choreography and or­chestration are formalised by using two process algebras and conformance takes the form of a bisimulation­like relation.

The originality of West2East goes beyond the originality of each single functionality it provides, and lies in the capability of offering to the MAS developer a bunch of choices integrated within the same environment. The contribution of West2East to the acceptance of AOSE approaches outside the boundaries of academic research may be found in its effort to

 

– promote the use of AOSE methodologies in the realisation of commercial MASs by offering a set of functionalities that support the MAS implementation starting from previous analysis and design stages that led to the definition of AIPs in AUML;

– ease the development of agents thanks both to the automatic translation of AIPs into Prolog code, and to the direct support of agent implementation inside a well­accepted platform for agent­based software development, JADE;

– facilitate the interaction between existing and new agents thanks to the representation of AIPs in a widely used and standardised language, WS­BPEL.

 

The two main directions of our work involve the extension of the set of notations and languages that West2East supports, both for representing AIPs and for implementing agents, and its evaluation on some application larger than those developed, by us, since now. For facing the last activity, we plan to involve the bachelor and master students of the Artificial Intelligence course that we teach. Given the same MAS to build, some of them will be asked to follow an existing AOSE methodology for designing the AUML AIP, and to use West2East for implementing a MAS in JADE, while some others will be asked to build the MAS directly in JADE. By comparing the average performance of the two groups of students, we will be able to measure time­saving and reduction in error gained by using West2East in conjunction with a principled AOSE approach.

 

Acknowledgments

This work was partially supported by the Italian project MIUR PRIN 2005 “Specica­tion and verication of agent interaction protocols”.

 

 

Footnotes

 

1. http://www.cs.rmit.edu.au/agents/protocols/


2. http://lia.deis.unibo.it/research/socs/

 

3. http://centria.di.fct.unl.pt/˜clima/

4. http://staff.science.uva.nl/˜ulle/DALT­2006/home.html

 

5. http://www.disi.unige.it/person/MascardiV/Software/WEST2EAST. html

 

6. http://www.jdom.org/

 

7. http://www.cs.rmit.edu.au/agents/pdt/

8. http://www.agent­software.com

9. Consider for example the two tutorials http://www.w3schools.com/wsdl/ default.asp and http://www.eclipse.org/stp/b2j/docs/tutorials/ wsbpel/wsbpel_tut.php, dealing with WSDL and WS­BPEL, respectively.

10. http://www.cs.sunysb.edu/˜lmc/

 

11. The reader may consider one of the on­line Prolog tutorials, such as http: //www.coli.uni­saarland.de/˜kris/learn­prolog­now/lpnpage. php?pageid=online, besides the classic book “The art of Prolog”, Sterling and Shapiro (1994).

 

12. In Prolog technical words, the reasoning stage is implemented by allowing the agent to make a depth­first exploration of the SLD­tree for P {G} via R, where P is the program generated as described in Section 5, G is the goal that starts the execution of the protocol (exec(s(’sd FruitMarket’,0)) in our example), and R is the leftmost selection rule. This exploration is aimed at either finding one path where the desired condition is verified (for demonstrating that an existential property holds), or finding a path where the final state is reached, and the desired condition is not verified (for demonstrating that a universal property does not hold).

 

13. http://www.mysql.com/

 

14. BPEL4WS is the previous version of WS­BPEL.

 

15. http://www.alphaworks.ibm.com/tech/ettkws

 

 

Bibliography

Agentcities Task Force (2003). ‘Integrating web services into agentcities recommenda­tion’.

 

Alberti, M., Daolio, D., Torroni, P., Gavanelli, M., Lamma, E., and Mello, P. (2004). ‘Specication and verication of agent interaction protocols in a logic­based system’. In H. Haddad, A. Omicini, R. L. Wainwright, and L. M. Liebrock, editors, ACM Symposium on Applied Computing (SAC 2004), Proceedings, pages 72–78. ACM.

 

Alberti, M., Chesani, F., Gavanelli, M., Lamma, E., Mello, P., Montali, M., Storari, S., and Torroni, P. (2006). Computational logic for run­time verication of web services choreographies: exploiting the SOCS­SI tool. In Third International Workshop on Web Services and Formal Methods, WS­FM 2006, Proceedings, Lecture Notes in Computer Science. Springer. To appear.

 

Baldoni, M., Baroglio, C., Martelli, A., and Patti, V. (2003). ‘Reasoning about con­versation protocols in a logic­based agent language’. In A. Cappelli and F. Turini, editors, Advances in Articial Intelligence, 8th Congress of the Italian Association for Articial Intelligence, AI*IA 2003, Proceedings, volume 2829 of Lecture Notes in Computer Science, pages 300–311. Springer.

 

Baldoni, M., Baroglio, C., Martelli, A., Patti, V., and Schifanella, C. (2005). ‘Verify­ing the conformance of web services to global interaction protocols: A rst step’. In M. Bravetti, L. Kloul, and G. Zavattaro, editors, Formal Techniques for Com­puter Systems and Business Processes, European Performance Engineering Work­shop, EPEW 2005, and International Workshop on Web Services and Formal Meth­ods, WS­FM 2005, Proceedings, volume 3670 of Lecture Notes in Computer Science, pages 257–271. Springer.

 

Baldoni, M., Baroglio, C., Martelli, A., and Patti, V. (2006). ‘Reasoning about inter­action protocols for customizing web service selection and composition’. Journal of Logic and Algebraic Programming, special issue on Web Services and Formal Methods. To appear.

 

Bauer, B. and Huget, M.­P. (2004). ‘Modelling web service composition with UML 2.0’. Int. J. Web Eng. Technol., 1(4), 484–501.

 

Bauer, B., M¨uller, J. P., and Odell, J. (2000). ‘Agent UML: A formalism for specifying multiagent software systems’. In P. Ciancarini and M. Wooldridge, editors, Agent­Oriented Software Engineering, First International Workshop, AOSE 2000, Revised Papers, volume 1957 of Lecture Notes in Computer Science, pages 91–104. Springer.

 

Bellifemine, F., Poggi, A., and Rimassa, G. (2000). ‘Developing multi­agent sys­tems with JADE’. In C. Castelfranchi and Y. Lesp´erance, editors, Intelligent Agents

VII. Agent Theories Architectures and Languages, Seventh International Workshop, Proceedings, volume 1986 of Lecture Notes in Computer Science, pages 89–103. Springer.

 

Bozzano, M. and Delzanno, G. (2002). ‘Automated protocol verication in linear logic’. In Fourth international ACM SIGPLAN conference on Principles and Practice of Declarative Programming, PPDP 2002, Proceedings, pages 38–49. ACM.

 

Bozzano, M. and Delzanno, G. (2004). ‘Automatic verication of secrecy properties for linear logic specications of cryptographic protocols’. J. Symb. Comput., 38(5), 1375–1415.

 

Bozzo, L., Mascardi, V., Ancona, D., and Busetta, P. (2005). ‘CooWS: Adaptive BDI agents meet service­oriented programming’. In P. Isaias and M. B. Nunes, editors, IADIS International Conference WWW/Internet 2005, ICWI 2005, Proceedings, vol­ume 2, pages 205–209. IADIS Press.

 

Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., and Mylopoulos, J. (2004). ‘Tro­pos: An agent­oriented software development methodology’. Autonomous Agents and Multi­Agent Systems, 8(3), 203–236.

 

Brogi, A., Canal, C., Pimentel, E., and Vallecillo, A. (2004). ‘Formalizing web service choreographies’. Electr. Notes Theor. Comput. Sci., 105, 73–94.

 

Buhler, P. A. and Vidal, J. M. (2005). ‘Towards adaptive workow enactment using multiagent systems’. Information Technology and Management, 6, 61–87.

 

Busi, N., Gorrieri, R., Guidi, C., Lucchi, R., and Zavattaro, G. (2005). ‘Choreogra­phy and orchestration: A synergic approach for system design’. In B. Benatallah,

F. Casati, and P. Traverso, editors, Service­Oriented Computing, Third International Conference, ICSOC 2005, Proceedings, volume 3826 of Lecture Notes in Computer Science, pages 228–240. Springer.

 

Cabac, L. and Moldt, D. (2004). ‘Formal semantics for AUML agent interaction pro­tocol diagrams’. In J. Odell, P. Giorgini, and J. P. Mueller, editors, Agent­Oriented Software Engineering Workshop, Fifth International Workshop, AOSE 2004, Revised Selected Papers, volume 3382 of Lecture Notes in Computer Science, page 4761. Springer.

Cernuzzi, L. and Zambonelli, F. (2004). ‘Experiencing AUML in the Gaia methodol­ogy’. In Sixth International Conference on Enterprise Information Systems, ICEIS 2004, Proceedings, volume 3, pages 283–288.

Cervenka, R., Trencansky, I., and Calisti, M. (2005). ‘Modeling social aspects of multi­agent systems: The AML approach’. In Agent­Oriented Software Engineering Work­shop, Sixth International Workshop, AOSE 2005, Proceedings.

 

Ciancarini, P. and Wooldridge, M. (2000). ‘Agent­oriented software engineering: The state of the art’. In P. Ciancarini and M. Wooldridge, editors, Agent­Oriented Soft­ware Engineering, First International Workshop, AOSE 2000, Revised Papers, vol­ume 1957 of Lecture Notes in Computer Science, pages 1–28. Springer.

 

Denti, E., Omicini, A., and Ricci, A. (2005). ‘Multi­paradigm Java­Prolog integration in tuProlog’. Sci. Comput. Program., 57(2), 217–250.

 

Dinkloh, M. and Nimis, J. (2003). ‘A tool for integrated design and implementation of conversations in multiagent systems’. In M. Dastani, J. Dix, and A. E. Fallah­Seghrouchni, editors, Programming Multi­Agent Systems, First International Work­shop, PROMAS 2003, Selected Revised and Invited Papers, volume 3067 of Lecture Notes in Computer Science, pages 187–200. Springer.

 

Dix, J., Sadri, F., and Satoh, K., editors (2003). Special Issue On Computational Logic in Multi­Agent Systems. Annals of Mathematics and Articial Intelligence, 37(1­2).

 

FIPA Modeling Technical Committee (2003). ‘FIPA modeling: Interaction diagrams, rst proposal, july 02 2003’.

 

FIPA Technical Committee (2002). ‘FIPA ACL message structure specication, de­cember 06 2002’.

 

Gardner, T. (2003). ‘UML modelling of automated business processes with a mapping to BPEL4WS’. In First European Workshop on Object Orientation and Web Services, EOOWS 2003, Proceedings.

 

Gomez­Sanz, J. and Pavon, J. (2003). ‘Agent oriented software engineering with IN­GENIAS’. In V. Marìk, J. P. Mueller, and M. Pechoucek, editors, Multi­Agent Systems and Applications III, Third International Central and Eastern European Conference on Multi­Agent Systems, CEEMAS 2003, Proceedings, volume 2691 of Lecture Notes in Computer Science, pages 394–403. Springer.

Gòmez­Sanz, J. J. and Pavòn, J. (2005). ‘Implementing multi­agent systems organi­zations with INGENIAS’. In R. H. Bordini, M. Dastani, J. Dix, and A. E. Fallah­Seghrouchni, editors, Programming Multi­Agent Systems, Third International Work­shop, ProMAS 2005, Revised and Invited Papers, volume 3862 of Lecture Notes in Computer Science, pages 236–251. Springer.

Greenwood, D. and Calisti, M. (2004). ‘Engineering web service ­agent integration’. In IEEE Systems, Cybernetics and Man Conference, Proceedings, volume 2, pages 1918–1925. IEEE.

 

Grønmo, R. and Solheim, I. (2004). ‘Towards modeling web service composition in UML’. In S. Bevinakoppa and J. Hu, editors, Web Services: Modeling, Architec­ture and Infrastructure, Second International Workshop, WSMAI 2004, Proceedings, pages 72–86. INSTICC Press.

 

Gungui, I., Martelli, M., and Mascardi, V. (2005). ‘DCaseLP: a prototyping environ­ment for multilingual agent systems’. Technical report, DISI, University of Genova, Italy. DISI­TR­05­20.

 

Huget, M.­P. (2002). ‘Generating code for Agent UML sequence diagrams’. Technical report, Department of Computer Science, University of Liverpool, UK. ULCS­02­020.

 

Juan, T., Pearce, A. R., and Sterling, L. (2002). ‘ROADMAP: extending the Gaia methodology for complex open systems’. In First International Joint Conference on Autonomous Agents & Multiagent Systems, AAMAS 2002, Proceedings, pages 3–10. ACM.

 

Koning, J. and Romero­Hernandez, I. (2003). ‘Generating machine processable rep­resentations of textual representations of AUML’. In F. Giunchiglia, J. Odell, and

G. Weiß, editors, Agent­Oriented Software Engineering, Third International Work­shop, AOSE 2002, Revised Papers and Invited Contributions, volume 2585 of Lecture Notes in Computer Science, pages 126–137. Springer.

 

Luck, M., McBurney, P., Shehory, O., Willmott, S., and the AL Community, editors (2005). Agent Technology: Computing as Interaction – A Roadmap for Agent­Based Computing. AgentLink III.

 

Mantell, K. (2005). ‘From UML to BPEL – model driven architecture in a web services world’. Available online from http://www­128.ibm.com/ developerworks/webservices/library/ws­uml2bpel/.

 

Mascardi, V., Martelli, M., and Sterling, L. (2004). ‘Logic­based specication lan­guages for intelligent software agents’. Theory and Practice of Logic Programming, 4(4), 429–494.

 

McIlraith, S. A. (2004). ‘Towards declarative programming for web services’. In R. Gi­acobazzi, editor, Static Analysis, 11th International Symposium, SAS 2004, Proceed­ings, volume 3148 of Lecture Notes in Computer Science, page 21. Springer.

 

OASIS WSBPEL Technical Committees (2006). ‘Web Services Business Process Exe­cution Language (WS­BPEL) Version 2.0, May 17 2006’.

 

Object Management Group (2005a). ‘MOF 2.0/XMI Mapping Specication, Version 2.1, September 1 2005’.

 

Object Management Group (2005b). ‘Unied Modeling Language (UML): Superstruc­ture, Version 2.0, July 4 2005’.

 

Padgham, L. and Winikoff, M. (2002). ‘Prometheus: a methodology for developing intelligent agents’. In First International Joint Conference on Autonomous Agents & Multiagent Systems, AAMAS 2002, Proceedings, pages 37–38. ACM.

 

Provost, W. (2003). ‘UML for web services’. Available online from http://www. xml.com/pub/a/ws/2003/08/05/uml.html.

 

Rao, J., K¨ungas, P., and Matskin, M. (2004). ‘Logic­based web services composition: From service description to process model’. In IEEE International Conference on Web Services, ICWS’04, Proceedings, pages 446–453. IEEE Computer Society.

 

Rooney, C., Collier, R. W., and O’Hare, G. M. P. (2004). ‘VIPER: A VIsual Pro­tocol EditoR’. In R. D. Nicola, G. L. Ferrari, and G. Meredith, editors, Coordi­nation Models and Languages, Sixth International Conference, COORDINATION 2004, Proceedings, volume 2949 of Lecture Notes in Computer Science, pages 279– 293. Springer.

 

Sadri, F. and Toni, F. (1999). Computational logic and multi­agent systems: a roadmap. Technical report, Department of Computing, Imperial College, London.

 

Sturm, A., Dori, D., and Shehory, O. (2003). ‘Single model method for specifying mul­tiagent systems’. In Second International Joint Conference on Autonomous Agents & Multiagent Systems, AAMAS 2003, Proceedings, pages 121–128. ACM.

 

Thang, X. and Kowalczyk, R. (2005). ‘Enabling agent­based management of web ser­vices with WS2JADE’. In 2005 NASA / DoD Conference on Evolvable Hardware, EH 2005, Proceedings, pages 407–412. IEEE Computer Society.

 

W3C Web Services Choreography Working Group (2002). ‘Web Service Choreography Interface (WSCI) Version 1.0, August 8 2002’.

 

W3C Working Group (1999). ‘XSL Transformations (XSLT) Version 1.0, November 16 1999’.

 

Wagner, G. (2004). ‘AOR modelling and simulation towards a general architecture for agent­based discrete event simulation’. In Agent­Oriented Information Systems, Fifth International Bi­Conference Workshop, AOIS 2003, Revised Selected Papers, volume 3030 of Lecture Notes in Computer Science, page 174188. Springer.

 

Walton, C. (2005). ‘Uniting agents and web services’. AgentLink News, 18, 26–28.

 

Web Services Description Working Group (2006). ‘Web Services Description Language (WSDL) Version 2.0, March 27 2006’.

 

Winikoff, M. (2005). ‘Towards making Agent UML practical: A textual notation and a tool’. In 2005 NASA / DoD Conference on Evolvable Hardware, EH 2005, Proceed­ings, pages 401–412. IEEE Computer Society.

 

Zambonelli, F., Jennings, N. R., and Wooldridge, M. (2003). ‘Developing multiagent systems: The Gaia methodology’. ACM Transactions on Software Engineering and Methodology, 12(3), 317–370.

 

 

 

 




Download and installation instructions





Credits





Disclaimer


The AUML2WS-BPEL translator is still under testing. You may download and use it (in this case, we would be very happy to be informed), but please take into account that its debugging has not been completed yet.
For the moment, only option, seq, loop, and alt UML 2.0 operators are translated into the corresponding if-then, sequence, while and switch WS-BPEL activities.
Comments in the code are sometimes still in Italian.

Suggestions are welcome: please send them to
Giovanni Casella


Back to Viviana's home page



Please send suggestions and comments to:

Viviana Mascardi mascardi@disi.unige.it

Last Updated: September, 6th, 2006

 

  The Department | Research | Education | People | Contacts