|
|
||||||||||||||||||||||||
Fig. 5. Correspondence between AUML
and WSBPEL concepts AUML is an easily comprehensible visual language
that allows to express the high level structure of interaction protocols,
while WSBPEL is a quite complex XML language suitable for expressing not
only the high level structure of business 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 conditions.
WSBPEL 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 WSBPEL documents
partly shown below. WSBPEL specification 1: <process
xmlns="http://schemas.xmlsoap.org/..." ....> 2: <partnerLinks> 3: <partnerLink name="publisherPL"
partnerLinkType="lns:SellerBuyer" 4: <partnerLink
name="readerPL" partnerLinkType="lns:BuyerSeller" 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" 18: <copy><from
opaque="yes"/><to>$choose2.value</to></copy>
19: <switch> 20:
<case
condition="$choose2.value=1"> operation="SND Mess 15"/> operation="RCV Mess
15"/> n5: </case> n: </process> WSDL specification j: <xs:element name="content of Mess 15"
type="xs:string" fixed="i may sell(fruit(F1))"/> k: <message name="Mess 15"> For each condition to check in
the AIP, a variable is defined in the WSBPEL document
(lines 613), to which opaque values (used by internal/private functions,
as opposed 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 n10, 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 WSBPEL 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 satisfied in order to allow the execution of
that protocol branch (condition = "$continue 1.value = true", for example). Apart from the first message of the protocol, that, according to
the WSBPEL specification,
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 actions. For example, lines n9 and n8 describe
the delivery of the message identified by the number 15 from the publisher
to the reader, both from the publisher’s viewpoint, 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 functionalities
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 Prologbased 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
flavor of the Prolog notation, a fragment of the FruitMarket AIP is included
below. We think that any reader with a basic knowledge of firstorder 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 identifiers for the publisher’s and reader’s short names (’seller@giocas:1099/JADE’
and ’buyer@giocas: 1099/JADE’ respectively). These identifiers 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 modification) 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, case(no guard, seq([
receive(msg(’INFORM’,’available(fruit(F))’)), case(no guard, 5 Automatic generation of the protocol-compliant code
Automatic generation of code
from specifications allows the MAS engineer to
save programming time and thus to concentrate on the engineering stages
that require more brainpower. West2East offers a “Prologoriented”
code generation functionality; the generation of a Prolog program starts
from the Prolog representation of the AIP, and a finite 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 Prolog
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 final 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 efficiency 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))
: 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)) : clause 7: exec(s(s(s(s(’sd
FruitMarket’,0),0),1),0)) : clause 8: exec(s(s(s(s(s(’sd
FruitMarket’,0),0),1),0),0)) : 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 n3: exec(s(s(s(s(s(’sd
FruitMarket’,0),0),1),1),1)) : clause n2: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1))
: clause n1: exec(s(s(s(s(s(s(’sd
FruitMarket’,0),0),1),1),1),0)) : clause n: exec(s(’sd FruitMarket’,final))
:true. The
predicate check guard(State,Guard) (clauses 1, 6 and n3) characterises a
check transition, and succeeds if call(Guard) succeeds. Since no guards were specified 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 developer 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 n1) characterises
a send transition (resp., a receive transition). These communication
predicates are implemented by the DCaseLP library, Gungui et al. (2005),
that provides an interface 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 final states of the transition, the identifier of the agent, and the term representing the structured activity
to translate, and returns a list of clauses that implement the transition.
The state that represents the end of the protocol is identified 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 FruitMarket’,0) for reaching the state s(’sd FruitMarket’,final). Clause 0 of our code fragment
corresponds to the first clause of the translation of the
while activity (clause a); clause 2 corresponds to clause b; and clause 3
to clause c. All the remaining 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 communication
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 n1. –
Translating sequences. A seq([Activity0,
..., ActivityN]) action performed 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 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 first activity within the sequence, send(’REQUEST’,’availability and
price(fruit(F))’,’seller@giocas:1099/JADE’), from s(s(S,I),0) to s(s(S,I),1). Clause n1 corresponds to the
very last activity in the sequence. Also clauses 8 and 9 translate two
items of a sequence, – Translating alternatives. A switch([case(Guard0,Activity0),
..., case(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 .... 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 m3 and m2 correspond to
clauses a and b respectively, where s(S,I) corresponds 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
m1), as anticipated when we introduced the translation of cycles. Both the
publisher and the reader may take advantage of the automatic code generation
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 (either
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 instantiated 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,Receiver), or a receive(Performative,Content,Sender), or a check guard(State,Guard), is executed. If the condition
is satisfied, the reader agent engages in a dialog 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(receive(’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 execution. 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 action 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 file: 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) I executed the statement check
guard(s(’sd FruitMarket’,0),no guard) Nondeterministic action: I
received the message I was waiting for, namely Nondeterministic action: I
received the message I was waiting for, namely I executed the statement Nondeterministic action: I
received the message I was waiting for, namely 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 + WSBPEL,
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 “nonJADE” 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 specific infrastructure. To implement our
publisher/reader MAS, we have developed a JADE Protocol Manager Agent
(PMA) that, together with JADE’s Directory Facilitator (DF), allows agents
to publish and retrieve WSDL + WSBPEL specifications 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 account (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 + WSBPEL notation discussed in Section 4.3; p.2 advertisement of the WSDL + WSBPEL
document by exploiting the services offered 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 Section 4.4; p.4 generation of the Prolog code from
the Prolog term representing the AIP, as described 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 + WSBPEL
documents; r.2 translation from the WSDL + WSBPEL
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 designed 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 specific services such as the fruitselling service offered by the fruit
seller and advertised by publishing the WSDL + WSBPEL 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 find 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 + WSBPEL documents on a MySql DBMS13. When the JADE platform is started, the PMA
registers the protocolpublishing and the protocolreading agent services
to the DF (arrows 1 and 1.
generates the WSBPEL +
WSDL documents from the AUML AIP; 2.
looks in the DF to find the protocolpublishing agent service (arrows 3, 4); 3.
sends a message to the
PMA with the WSDL + WSBPEL document, and waits to receive the protocol
identifier (PID)
assigned by the PMA to it (arrows 5, 6); 4.
registers the agent service specified by the WSBPEL 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 find 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 assigned to the agent service (if they exist in
the DF); 2.
sends a message to the
PMA to obtain the WSDL + WSBPEL document representing the AIP (arrows 11,
12) and identified by the PID obtained in 1; 3.
from the WSDL + WSBPEL
specification,
generates the corresponding Prolog term, and, from this, the Prolog code,
and reasons about it; 4.
according to the reasoning outcome, eventually starts
the protocolcompliant communication in order to obtain the agent service
(direct communication between the publisher 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 figure, corresponding to the example of
Figure 3, the publisher plays the role of fruitSeller while the reader plays the role
of fruitBuyer. The first twelve messages correspond to the communication represented by
the twelve solid arrows in Figure 8, while the other messages are exchanged
during the execution of the fruitMarket AIP, aimed at allowing the fruitBuyer to obtain the fruitselling 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
specification, and the capability of reasoning about AIPs. As far as the first feature is concerned, the literature describes many proposals of
using 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 composition. 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 agentoriented 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 specification from the UML one are described
in these three papers, Gardner (2003) describes a UML profile for automated business processes which allows BPEL4WS14 processes to be modelled using an existing UML
tool and automatically mapped to BPEL4WS, and Mantell (2005) describes a
tool which takes processes defined by UML activity diagrams and
generates the corresponding BPEL4WS and WSDL files. The key difference between
our work and both Gardner’s and Mantell’s ones is that we translate
interaction protocols represented as AUML protocol diagrams (that are an
extension of UML sequence diagram) into WSBPEL abstract processes, 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 plugin 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); GomezSanz and Pavon (2003); Rooney et al. (2004);
Cabac and Moldt (2004), while the generation of code from WSBPEL and UML
2.0 specifications is already supported by many commercial tools.
However, West2East purpose goes further beyond an (A)UML → code or a WSBPEL →
code translation, since it aims at making the MAS analysis and design,
carried out following AOSE methodologies, 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 corresponding
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 interaction diagrams, using
Winikoff’s notation as a bridge. Sections 4.2 to 4.4 highlight other
possible usages and advantages. Finally, the Prologrelated
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
general, 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 requires 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 WSBPEL, 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
specification 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 orchestration
are formalised by using two process algebras and conformance takes the form
of a bisimulationlike 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 wellaccepted platform
for agentbased software development, JADE; – facilitate the interaction
between existing and new agents thanks to the representation of AIPs in a
widely used and standardised language, WSBPEL. 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 timesaving
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 “Specification and verification of agent interaction protocols”. Footnotes
1. http://www.cs.rmit.edu.au/agents/protocols/
3.
http://centria.di.fct.unl.pt/˜clima/ 4.
http://staff.science.uva.nl/˜ulle/DALT2006/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.agentsoftware.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 WSBPEL, respectively. 10.
http://www.cs.sunysb.edu/˜lmc/ 11. The reader may consider one of the online
Prolog tutorials, such as http: //www.coli.unisaarland.de/˜kris/learnprolognow/lpnpage.
php?pageid=online, besides the classic book “The
art of Prolog”, 13. http://www.mysql.com/ 14. BPEL4WS is the
previous version of WSBPEL. 15.
http://www.alphaworks.ibm.com/tech/ettkws Bibliography
Agentcities
Task Force (2003). ‘Integrating web services into agentcities recommendation’.
Alberti, M., Daolio, D., Torroni, P., Gavanelli, M.,
Lamma, E., and Mello, P. (2004). ‘Specification and verification of agent interaction protocols in a logicbased 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 runtime
verification of web services choreographies: exploiting the SOCSSI tool.
In Third International Workshop on Web Services and Formal Methods, WSFM
2006, Proceedings, Lecture Notes in Computer Science. Springer. To appear. Baldoni,
M., Baroglio, C., Martelli, A., and Patti, V. (2003). ‘Reasoning about conversation
protocols in a logicbased agent language’. In A. Cappelli and F. Turini,
editors, Advances in Artificial Intelligence, 8th Congress
of the Italian Association for Artificial 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). ‘Verifying the conformance of web services to global interaction protocols:
A first step’. In M. Bravetti, L. Kloul, and G. Zavattaro, editors,
Formal Techniques for Computer Systems and Business Processes, European
Performance Engineering Workshop, EPEW 2005, and International Workshop on
Web Services and Formal Methods, WSFM 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 interaction 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 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, AgentOriented 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 multiagent systems
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 verification 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 verification of secrecy properties for
linear logic specifications 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 serviceoriented programming’. In P. Isaias and M.
B. Nunes, editors, IADIS International Conference WWW/Internet 2005, ICWI
2005, Proceedings, volume 2, pages 205–209. IADIS Press. Bresciani, P., Perini, A., Giorgini, P., Giunchiglia,
F., and Mylopoulos, J. (2004). ‘Tropos: An agentoriented software development
methodology’. Autonomous Agents and MultiAgent 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 workflow enactment using multiagent systems’. Information Technology and
Management, 6, 61–87. Busi, N.,
Gorrieri, R., Guidi, C., Lucchi, R., and Zavattaro, G. (2005). ‘Choreography
and orchestration: A synergic approach for system design’. In B.
Benatallah, F. Casati, and P. Traverso,
editors, ServiceOriented 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 protocol diagrams’. In J. Odell, P. Giorgini, and J. P.
Mueller, editors, AgentOriented 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 methodology’. In Sixth International Conference on Enterprise
Information Systems, ICEIS 2004, Proceedings, volume 3, pages 283–288. Cervenka,
R., Trencansky, Ciancarini,
P. and Wooldridge, M. (2000). ‘Agentoriented software engineering: The
state of the art’. In P. Ciancarini and M. Wooldridge, editors, AgentOriented
Software Engineering, First International Workshop, AOSE 2000, Revised
Papers, volume 1957 of Lecture Notes in Computer Science, pages 1–28. Springer. Denti, E., Omicini, A., and Ricci, A. (2005). ‘Multiparadigm JavaProlog 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.
FallahSeghrouchni, editors, Programming MultiAgent Systems, First
International Workshop, 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 MultiAgent Systems. Annals of Mathematics and Artificial Intelligence, 37(12). FIPA
Modeling Technical Committee (2003). ‘FIPA modeling: Interaction diagrams, first proposal, july 02 FIPA
Technical Committee (2002). ‘FIPA ACL message structure specification, december 06 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. GomezSanz, J. and Pavon, J. (2003). ‘Agent oriented software
engineering with INGENIAS’. In V. Marìk, J. P. Mueller, and M. Pechoucek,
editors, MultiAgent Systems and Applications III, Third International
Central and Eastern European Conference on MultiAgent Systems, CEEMAS
2003, Proceedings, volume 2691 of Lecture Notes in Computer Science, pages
394–403. Springer. GòmezSanz, J. J. and Pavòn, J. (2005). ‘Implementing multiagent
systems organizations with INGENIAS’. In R. H. Bordini, M. Dastani, J.
Dix, and A. E. FallahSeghrouchni, editors, Programming MultiAgent
Systems, Third International Workshop, ProMAS 2005, Revised and Invited
Papers, volume 3862 of Lecture Notes in Computer Science, pages 236–251.
Springer. Grønmo, R.
and Solheim, Gungui, Huget, M.P.
(2002). ‘Generating code for Agent UML sequence diagrams’. Technical
report, Department of Computer Science, Juan, T.,
Pearce, A. R., and Koning, J.
and RomeroHernandez, G. Weiß, editors, AgentOriented
Software Engineering, Third International Workshop, 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 AgentBased
Computing. AgentLink III. Mantell, K.
(2005). ‘From UML to BPEL – model driven architecture in a web services
world’. Available online from http://www128.ibm.com/
developerworks/webservices/library/wsuml2bpel/. Mascardi, V., Martelli, M., and Sterling, L. (2004). ‘Logicbased specification languages 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. Giacobazzi,
editor, Static Analysis, 11th International Symposium, SAS 2004, Proceedings,
volume 3148 of Lecture Notes in Computer Science, page 21. Springer. OASIS
WSBPEL Technical Committees (2006). ‘Web Services Business Process Execution
Language (WSBPEL) Version 2.0, May 17 Object
Management Group (2005a). ‘MOF 2.0/XMI Mapping Specification, Version 2.1, September 1 Object
Management Group (2005b). ‘Unified Modeling Language (UML):
Superstructure, Version 2.0, July 4 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). ‘Logicbased 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 Protocol
EditoR’. In R. D.
Nicola, G. L. Ferrari, and G. Meredith, editors, Coordination 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 multiagent systems: a
roadmap. Technical report, Department of Computing, Sturm, A.,
Dori, D., and Shehory, O. (2003). ‘Single model method for specifying multiagent
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 agentbased management of web services
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 W3C Working
Group (1999). ‘XSL Transformations (XSLT) Version 1.0, November 16 Wagner, G.
(2004). ‘AOR modelling and simulation towards a general architecture for
agentbased discrete event simulation’. In AgentOriented Information
Systems, Fifth International BiConference 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 Winikoff,
M. (2005). ‘Towards making Agent UML practical: A textual notation and a
tool’. In 2005 NASA / DoD Conference on Evolvable Hardware, EH 2005,
Proceedings, pages 401–412. IEEE Computer Society. Zambonelli,
F., Download and installation instructions
Credits
DisclaimerThe 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
Last Updated: September, 6th, 2006 |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
The Department | Research | Education | People | Contacts |
|||||||||||||||||||||||||
|
|