515978-1-4244-4478-6/09/$25.00 ©2009 IEEE

5th International Symposium on Applied Computational Intelligence and Informatics • May 28–29, 2009 – Timişoara, Romania

A Process Algebraic Framework for Service Coordination

Amelia Bădică, Costin Bădică, Elvira Popescu, Mihnea Scafeş

A Process Algebraic Framework for Service Coordination

Amelia BadicaUniversity of Craiova

Business Information Systems DepartmentA.I.Cuza 13, Craiova, RO-200585, Romania

ameliabd@yahoo.com

Costin Badica, Elvira Popescu, Mihnea ScafesUniversity of Craiova

Software Engineering DepartmentBvd.Decebal 107, Craiova, 200440, Romania

{badica costin,popescu elvira,scafes mihnea}@software.ucv.ro

Abstract

We propose a formal framework based on finite stateprocess algebra for modeling service coordination in agentsystems. The model is inspired by WS-coordination spec-ification. Several participant agents can coordinate theiractions towards reaching a semantically consistent outcomein a distributed activity. The model defines coordinator andparticipant agents and their generic interaction protocolsand allows integration of application specific protocols bymeans of protocol handlers. The approach is demonstratedby a sample model showing how coordination is achievedbetween a set of agents involved in contracting activities.

1. Introduction

Real service-oriented applications require complex serviceinteractions, usually involving more than a single clientinvoking a given service. Such interactions typically involveseveral independent service invocations that are performedin a pre-established order, obeying certain pre-defined rules.

Following [4], we define a conversation as a sequenceof message exchanges representing service interactions thatoccur between a set of participant services, as part of acomplex distributed business activity. Typical examples areinteractions during a purchasing activity that involves acustomer, a supplier and a warehouse agent, or during anauction that involves a seller and multiple buyer agents.

According to [4], we shall define a coordination protocolas the specification of the set of correct conversationsthat occur between a set of participant services during therealization of a complex and distributed business activity. Acoordination protocol defines a coordination type.

In this paper we develop a formal framework based onfinite state process algebra – FSP ([10]) for modeling servicecoordination in agent systems. In our model several partic-ipant agents can coordinate their actions towards reaching

Project “SCIPA: Servicii software semantice de Colaborare si Interop-erabilitate pentru realizarea Proceselor Adaptive de business” supportedAmelia Badica, Elvira Popescu and partly Costin Badica. Project “DIA-DEM: Distributed information acquisition and decision-making for environ-mental management” supported Mihnea Scafes and partly Costin Badica.

a semantically consistent outcome in a distributed activity.The model defines: (i) coordinator and participant agents,(ii) generic interaction protocols between coordinator andparticipant agents, and (iii) protocol handlers that allowintegration of application specific coordination protocols.The approach is demonstrated through a detailed modelingexample showing how coordination is achieved between aset of agents involved in contracting activities.

Note that our model is generic because we abstract awayfrom: (i) domain dependent details, i.e. we do not assumea specific application area, like e-commerce or crisis man-agement and (ii) details of message representation (requests,responses, proposals, etc.), i.e. we do not assume a certainrepresentation language of message content (eg. XML orOWL) or certain interaction primitives (like FIPA-ACL). Thework builds on our formal framework introduced in [6].

The paper is structured as follows. We start in section 2 byintroducing the problem of service coordination. We followin section 3 with a brief review of the modeling framework.In section 4 we present in detail our proposal by developinga service coordination model for one-to-one contract-net. Wefollow in section 5 with a brief review of related works. Thelast section contains conclusions and future works.

2. Service Coordination

Our formal service coordination model is inspired by theWS-Coordination specification [4], [12], [2]. This specifi-cation aims at defining a framework for implementationof specific coordination types between participant Web ser-vices. However, in our model the focus is on the definitionof a generic and formally verifiable model, rather than onintroduction of precise implementation details specific onlyto Web services (as in [2]). Therefore our model is moregeneral and can be applied to other technological standardsrather than only to Web services, as FIPA [3] for example.

Note that, as Ian Robinson pointed out on his Blog, WS-Coordination is “perhaps the hardest to understand” specifi-cation from its family of standards [12]. Taking into accountthat WS-Coordination is also the core of the other two stan-dards – WS-AtomicTransaction and WS-BusinessActivity

Amelia Bădică, Costin Bădică, Elvira Popescu, Mihnea Scafeş • A Process Algebraic Framework for Service Coordination

516

that are part of OASIS WS-TX [1], we hope that our formalmodeling can help to improve their understanding.

Figure 1. Coordination model

The general idea of our model is presented in figure 1(please note that this model has a centralized architecture;however, it is possible to apply the model to a distributedcoordination architecture by chaining coordinators, as it isshown in [4], [2], but this is outside the scope of this paper).

In our model there are two types of agents: coordinatorsand participants. For each conversation between the setof participants that must be coordinated, the coordinatoris managing a data structure called coordination context.Achieving coordination of the set of participants assumesthe following steps [4]:(i) A special initiator participant requests the coordinator

to create a coordination context of a given coordinationtype. This process is called activation [4], [2].

(ii) Before the coordination is started, the coordinationcontext is passed to the other participants by whatevermeans (for example, either the initiator can directly passthe coordination context to the other participants, or theinitiator can register the coordination context and itsassociated type with a yellow pages agent and interestedparticipants can proactively search the yellow pagesagent for the coordination type they are interested into get the associated coordination context;

(iii) The participants register with the coordinator, using thecoordination context, as wishing to participate in theexecution of the coordination protocol;

(iv) Coordinator and participants exchange messages (thatincorporate the coordination context) according to thecoordination protocol. Messages are forwarded by coor-dinator to required participants following the protocolrules. Note that coordinator achieves its coordinationfunction by holding a specialized protocol handler foreach coordination type that she is able to handle.

3. FSP Modeling Framework

Overview of FSP. FSP is an algebraic specification tech-nique of concurrent and cooperating computational pro-

cesses as finite state labeled transition systems (LTS here-after). FSP allows a more compact and easy to managedescription of a LTS, rather than by directly describing it asa list of states and transitions between states. In the contextof our work, this has the advantage of being able to de-velop more compact coordination models (as compared forexample with representations as activity, sequence or statediagrams suggested in [4]). Moreover, these FSP models areeasier to understand and they can be formally analyzed withthe help of appropriate verification tools.

A FSP model consists of a finite set of sequential and/orcomposite process definitions. Additionally, a sequentialprocess definition consists of a sequence of one or moredefinitions of local processes. A process definition consistsof a process name associated to a process term. FSP usesa rich set of constructs for process terms (see [10] fordetails). For the purpose of this paper we are using thefollowing constructs: action prefix (a → P ), guarded actionprefix (when cond a → P ), and nondeterministic choice(P |Q) for sequential process terms and parallel composition(P ||Q) and re-labeling (P/{new1/old1, . . . , newk/oldk})for composite process terms.

FSP has an operational semantics given via a LTS. Themapping of a FSP term to a LTS is described in detail in[10] and it follows the intuitive meaning of FSP constructs.

Modeling Framework. The modeling that we propose herefollows the general guidelines outlined in [6]. In particu-lar, note that the coordinator agent functions as a specialmiddle-agent located “between” participant agents. Briefly:(i) agents are modeled as FSP processes and a multi-agentsystem is modeled as a parallel composition of processes;(ii) the various sets of agents that must be coordinated areassumed to be initially given and each agent of a given typehas associated an agent identifier; (iii) agent messages areindexed with agent identifiers; in particular, messages sent tothe coordinator are indexed with sender identifier, messagesreceived by an agent from the coordinator are indexed withreceiver identifier, and messages between agents (differentfrom the coordinator) are indexed with both identifiers (inaddition to the coordination context).

4. Case Study

In this subsection we illustrate a particular coordinationexample of manager and contractor agents involved incontract-net negotiations [13]. Our example is in fact a sim-plified one-one contract-net. Further extensions of contract-net involve one-to-many and iterative versions.

In this scenario a Manager agent must contract the exe-cution of a given task to a Contractor agent. The Managerfirstly sends a call-for-proposal message to the Contractoragent. The Contractor agent either refuses the proposal, byreplying with a refuse message or submits a proposal by

5th International Symposium on Applied Computational Intelligence and Informatics • May 28–29, 2009 – Timişoara, Romania

517

replying with a propose message. In turn, if the Contractorhas decided to submit a proposal, the Manager agent maychoose either to reject the proposal by replying with a reject-proposal message or accept the proposal by replying withan accept-proposal message. Finally, if the Manager hasaccepted the proposal, the Contractor replies with an informmessage when the task is completed.

Let us assume that agents in our system are partitionedinto a set M of Managers and a set of C of Contrac-tors. Managers are engaged into one-to-one contract-netnegotiations with Contractors. The system contains also aCoordinator agent holding a contract-net protocol handlerthat is able to handle a predefined set of contexts X . Sys-tem block diagram showing interactions between Managers,Contractors and Coordinator is shown in figure 2.

Figure 2. System block diagram

Coordination Service. Let us assume that managers andcontractors are represented by their identifiers m ∈ M andc ∈ C. The Coordinator is responsible with:

(i) Management of active contexts. For each active contextx ∈ X the Coordinator records the assigned managerm and contractor c that must be coordinated by man-aging their registration processes.

(ii) Activation and termination of contexts using an activa-tion service.

(iii) Coordinating participants registered with a given activecontext using a protocol handler.

For the internal details of Coordinator agent see figure 3.Let X ⊆ X be the set of active contexts. Assignment

of managers and coordinators to active contexts is modeledusing functions RM : X →M∪{⊥}, RC : X → C ∪ {⊥}.For x ∈ X if RM (x) =⊥ (or RC(x) =⊥) then context xwas activated, but no manager (or contractor) was assignedyet to x. If x ∈ X \X then RM and RC are undefined. RM

and RC can be represented as functional relations RM ⊆X×(M∪{⊥}) and RC ⊆ X×(C∪{⊥}). This representationis useful for contexts’ management, see below.

When a new context x is created it must be added to theset of active contexts X . Additionally the Coordinator mustrecord that there is no manager and contractor assigned to xyet by setting the values RM (x) and Rx(x) to ⊥, i.e. RM :=RM ∪ {(x,⊥)} and RC := RC ∪ {(x,⊥)}. In what follows

we shall denote these operations as RM := RM + (x,⊥)and RC := RC + (x,⊥).

Registration of manager m (or contractor c) to an activecontext x is modeled by changing the value of RM (x) (orRC(x)) from ⊥ to m (or c), i.e. RM := (RM \ {(x,⊥)}) ∪ {(x, m)} (or RC := (RC \ {(x,⊥)}) ∪ {(x, c)}. Inwhat follows we shall denote these operations as RM :=RM + (x, m) and respectively RC := RC + (x, c).

When the coordination between manager m and contrac-tor c is finalized, the associated context x must be deletedfrom the set of active contexts X and also the pairs (x, m)and (x, c) must be deleted from the functional relationsRM and RC . That is, if RM and RC are representedas functional relations then RM := RM \ {(x, RM (x))}and RC := RC \ {(x, RC(x))}. In what follows we shalldenote these operations as RM := RM \ x and respectivelyRC := RC \ x.

Figure 3. Details of the Coordinator process

Using functional relations RM and RC and associatednotations, the management of coordination contexts can bemodeled using the process ContextManager (see figure 4).

Note that in our model there is a separate Activation-Service process for each context x ∈ X . Contexts areactivated and terminated using a process that represents theparallel composition of all the individual activation services– process ActivationServices shown in figure 5.

ActivationService = (new cc(m ∈ M) →return cc(m) →ContextActivated),

ContextActivated = (end cc → ActivationService).

ActivationService(x ∈ X ) = ActivationService/{new cc(x)/new cc,return cc(x)/return cc,end cc(x)/end cc}.

ActivationServices = ||x∈XActivationService(x)

Figure 5. ActivationServices process.

The actual coordination is controlled by a separate processcalled protocol handler. This process is initialized with, and

Amelia Bădică, Costin Bădică, Elvira Popescu, Mihnea Scafeş • A Process Algebraic Framework for Service Coordination

518

ContextManager = ContextManager(∅, ∅, ∅),ContextManager(X,RM , RC) = (when X ⊂ X create cc(m ∈ M)→ CreateContext(X,RM , RC ,m)|

end cc(x ∈ X)→ ContextManager(X \ {x}, RM \ x,RC \ x)|when RM (x) =⊥ reg mng(x ∈ X,m ∈ M)→ Coordinator(X,RM + (x,m), RC)|when (RC(x) =⊥) ∧ (RM (x) =⊥) reg ctr(x ∈ X, c ∈ C)→ Coordinator(X,RM , RC + (x, c))),

CreateContext(X,RM , RC ,m) = (end cc(x ∈ X)→ ContextManager(X \ {x}, RM \ x,RC \ x)|new cc(x ∈ X \X,m)→ ContextManager(X ∪ {x}, RM + (x,⊥), RC + (x,⊥))).

Figure 4. ContextManager process.

subsequently notified for, any registered participants with agiven coordination. So we shall have a separate protocolhandler for each active coordination context and a specialcomponent of the Coordinator representing their parallelcomposition – process ProtocolHandlers. We discuss asample protocol handler for coordination of managers andcontractors involved in one-to-one contract-net negotiation.Typically there is a separate type of protocol handler foreach coordination type supported by a given coordinator.

Finally, Coordinator agent is a composite process repre-senting the parallel composition of processes ContextMan-ager, ActivationServices and ProtocolHandlers, i.e.:

Coordinator = (ContextManager||ActivationServices||ProtocolHandlers).

Coordination Example. In this subsection we illustrate aparticular coordination example of manager and contractoragents involved in contract-net negotiations.

Firstly, we must define a protocol handler for coordinatingone-to-one contract-net negotiations. The model is shownon figure 6. The ProtocolHandler process is activated whenboth a manager m and a contractor c are registered, viamessage phandler(c, m). There is one separate protocolhandler for each context x.

We follow with definition of participants – Manager(figure 7) and Contractor (figure 8). The coordination isinitiated by Manager who creates a coordination context andthen passes it to Contractor. Then Manager and Coordinatorproceed according to the rules of one-to-one contract-net.Note that all Managers and all Contractors are initiallycreated using parallel composition of individual Managerand Contractor processes.

Finally the System agent can be described as a compositeprocess representing the parallel composition of processesCoordinator, Managers and Contractors, i.e.:

System = (Coordinator||Managers||Contractors).

Experiment. We conducted a series of experiments tocheck correctness of our models introduced so far, usingthe Labeled Transition System Analyzer – LTSA tool [10]1.

Initially we had to express the general models using theFSP language supported by LTSA. For that purpose wemapped set-indexed processes to LTSA notation. Assuming

1. FSP models used in experiments are available at http://software.ucv.ro/∼badica costin/fsp/saci09 models.zip

that S is a set with n elements, mapping of processesindexed with sets and/or set elements to the FSP notationsupported by LTSA follows the guidelines: (i) an indexs ∈ S is encoded as [s]; (ii) an index S ⊆ S is encodedas [s1] . . . [sn] s.t. si = 1 if i ∈ S and si = 0 if i ∈ S.

Indexing with (X,RM , RC) as needed byContextManager process was handled separately.Assuming there are k contexts (i.e. set X has k elements)indexing with X is encoded as usual as [x1] . . . [xk] s.t.xi = 1 if i ∈ X and si = 0 if i ∈ X . Assuming there arem managers (i.e. set M has m elements), the indexingwith RM is encoded as [r1] . . . [rk] s.t. ri = 0 if context iis not active or context i is active but there is no managerregistered with i yet, and ri = j such that 1 ≤ j ≤ mif context i is active and manager j is registered with i.Similarly, assuming there are c contractors (i.e. set C has celements), the indexing with RC is encoded as [r1] . . . [rk]s.t. ri = 0 if context i is not active or context i is activebut there is no contractor registered with i yet, and ri = jsuch that 1 ≤ j ≤ c if context i is active and contractor jis registered with i.

For a simple system consisting of 3 contexts, 2 managers,and 2 contractors the resulting LTS has 27697 states and83480 transitions. The system is deadlock-free, thus con-firming our expectations.

5. Related Work

Formal modeling of service-oriented applications, eitheragent-based or Web-based, received quite a lot of attentionduring the last few years. This tendency is partly drivenby the advent of a number of Web services standards andframeworks that were proposed for service choreography,orchestration, coordination, and composition. In this sectionwe consider four of these works that satisfy at least one ofthe following conditions: (i) they use process algebras and(ii) they address issues related to service coordination.

Paper [5] proposes FSP modeling and verification ofan auction service. The authors consider an agent systemthat allows parallel execution of multiple English auctionsinitiated by different seller agents. In that system, buyeragents can dynamically register for participation in auc-tions matching their goals. Note that the auction serviceconsidered in [5] is in fact a coordinator that coordinates aseller and multiple buyer agents in an English auction, while

5th International Symposium on Applied Computational Intelligence and Informatics • May 28–29, 2009 – Timişoara, Romania

519

ProtocolHandler = (phandler(c ∈ C,m ∈ M) → WaitCfp(c,m)),WaitCfp(c ∈ C,m ∈ M) = (cfp(m) → fwd cfp(c) → WaitPropose(c,m)),WaitPropose(c ∈ C,m ∈ M) = (refuse(c) → fwd refuse(m) → EndProtocolHandler|

propose(c) → fwd propose(m) → WaitAccept(c,m)),WaitAccept(c ∈ C,m ∈ M) = (reject(m) → fwd reject(c) → EndProtocolHandler|

accept(c) → fwd accept(m) → WaitInform(c,m)),WaitInform(c ∈ C,m ∈ M) = (inform(c) → fwd inform(m) → EndProtocolHandler),EndProtocolHandler = (end cc → ProtocolHandler).

ProtocolHandler(x ∈ X ) = ProtocolHandler/{phandler(x)/phandler,cfp(x)/cfp, fwd cfp(x)/fwd cfp,propose(x)/propose, fwd propose(x)/fwd propose,refuse(x)/refuse, fwd refuse(x)/fwd refuse,accept(x)/accept, fwd accept(x)/fwd accept,reject(x)/reject, fwd reject(x)/fwd reject,inform(x)/inform, fwd inform(x)/fwd inform,end cc(x)/end cc}.

ProtocolHandlers = ||x∈XProtocolHandler(x)

Figure 6. ProtocolHandler process for simple one-to-one contract-net negotiation.

Manager = (create cc → return cc(x ∈ X ) → RegisterManager(x)),RegisterManager(x ∈ X ) = (reg mng(x) → ContactContractor(x)),ContactContractor(x ∈ X ) = (send cc to contractor(x) → ManagerDoProtocol(x)),ManagerDoProtocol(x ∈ §) = (send cfp(x) → WaitPropose(x)),WaitPropose(x ∈ X ) = (receive refuse(x) → Manager|

receive propose(x) → DoAcceptOrReject(x)),DoAcceptOrReject(x ∈ §) = (send reject proposal(x) → Manager|

send accept proposal(x) → WaitInform(x)),WaitInform(x ∈ X ) = (receive inform(x) → Manager).

Manager(m ∈ M) = Manager/{create cc(m)/create cc,return cc(x ∈ X ,m)/return cc(x),invites(x ∈ X , c ∈ C,m)/send cc to contractor(x),reg mng(x ∈ X ,m)/reg mng(x),cfp(x ∈ X ,m)/cfp(x),fwd refuse(x ∈ X ,m)/receive refuse(x),fwd propose(x ∈ X ,m)/receive propose(x),accept(x ∈ X ,m)/send accept proposal(x),reject(x ∈ X ,m)/send reject proposal(x),fwd inform(x ∈ X ,m)/receive inform(x)}.

Managers = ||m∈MManager(m)

Figure 7. Manager process for simple one-to-one contract-net negotiation.

an auction instance closely corresponds to a coordinationcontext. However, the coordination approach presented hereis more general, at least for two reasons: (i) it can beapplied to arbitrary coordination protocols, rather than onlyto auctions; (ii) coordination contexts are modeled separatelyof participating agents, while in [5] an auction instance isassociated to a seller agent. This is quite restrictive, as itdoes not allow a seller to simultaneously start more auctions,while this feature is possible with the current proposal.

Paper [8] presents event calculus, an extension of π-calculus ([11]) with multicast event notification and eventscopes names binding in order to simplify modeling of long-running business activities, possibly including error-handlingand compensations. The main difference between [8] and ourcurrent work is the level of abstraction. The main motivationbehind event calculus is to propose a suitable abstractionthat allows convenient modeling of complex coordination

scenarios usually encountered in e-business applications. Inour work we were mainly focused of providing an accurateformal model of service coordination, following the idea ofWS-Coordination specification. It clearly follows that themodeling proposed by [8] is at a higher level of abstractionthan what we have proposed in this paper.

Paper [7] proposes the use of FSP for modeling andverification of Web service compositions. Authors of [7]show how: (i) BPEL implementations of composite servicescan be translated into FSP models; (ii) interaction protocolsspecified using Message Sequence Charts – MSC can betransformed into FSP properties (a special class of FSPprocesses useful for property checking, see [10] for moredetails), and (iii) FSP models of composite services can beverified against the FSP properties using LTSA tool. Notethat, while we are using the same modeling language – FSP,our work is different, as focus is set on modeling service

Amelia Bădică, Costin Bădică, Elvira Popescu, Mihnea Scafeş • A Process Algebraic Framework for Service Coordination

520

Contractor = (receive cc from manager(x ∈ X ) → RegisterContractor(x)),RegisterContractor(x ∈ X ) = (reg ctr(x) → ContractorDoProtocol(x)),ContractorDoProtocol(x ∈ X ) = (receive cfp(x) → DoProposeOrRefuse(x)),DoProposeOrRefuse(x ∈ X ) = (send refuse(x) → Contractor|

send propose(x) → WaitAccept(x)),WaitAccept(x ∈ X ) = (receive reject proposal(x) → Contractor|

receive accept proposal(x) → DoInform(x)),DoInform(x ∈ X ) = (send inform(x) → Contractor).

Contractor(c ∈ C) = Contractor/{invites(x ∈ X , c,m ∈ M)/receive cc from manager(x),reg ctr(x ∈ X , c)/reg ctr(x),fwd cfp(x ∈ X , c)/receive cfp(x),refuse(x ∈ X , c)/send refuse(x),propose(x ∈ X , c)/send propose(x),fwd accept(x ∈ X , c)/send accept proposal(x),fwd reject(x ∈ X , c)/send reject proposal(x),inform(x ∈ X , c)/send inform(x)}.

Contractors = ||c∈CContractor(c)

Figure 8. Contractor process for simple one-to-one contract-net negotiation.

coordination rather than service composition.Paper [9] proposes the application of Temporal Logic

of Actions – TLA+ for the specification of WS-AtomicTransaction. Basically, WS-AtomicTransaction spec-ifies a two-phase commit protocol for implementation ofACID transactions on top of WS-Coordination (see also[4]). Similarly to our approach, the specification involvescoordinator and participant agents. However, as the authorsmention, ”the model involves an initiator, a transactioncoordinator (TC), and a set of participants [...] and theinitiator and TC are actually executed on the same processor,so they can be considered to be a single process.”. In ouropinion this a restrictive and non-realistic assumption. Inour model several coordinations can be run in parallel, somore initiators are allowed, and participants (including theinitiator participant) and coordinator are treated as separatedprocesses. Furthermore, our approach is more general be-cause it is focused on generic coordination, rather than onatomic transactions.

6. Conclusions and Future Work

In this paper we applied a formal framework based onFSP process algebra for modeling service coordination inagent systems. We have applied this framework to model aone-to-one contract-net scenario and we have checked theresulting model with the help of LTSA analysis tool.

We also identified some paths for continuing this research:i) modeling of more complex coordination scenarios totest the capabilities of this framework; ii) introduction andanalysis of qualitative properties of service coordination; iii)extending the modeling to distributed service coordinationby means of coordinators chaining.

References

[1] OASIS Web Services Transaction (WS-TX) TC. http://www.oasis-open.org/committees/tc home.php?wg abbrev=ws-tx , (accessed in

January 2009).

[2] Web Services Coordination (WS-Coordination) Version 1.2,Committee Specification 01, 2 October 2008, http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec.html, 2008.

[3] The Foundation for Intelligent Physical Agents, http://www.fipa.org, 2008.

[4] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. WebServices. Concepts, Architectures and Applications. Springer,2004.

[5] A. Badica and C. Badica. Specification and verification ofan agent-based auction service. In G. Papadopoulos, W. Wo-jtkowski, G. Wojtkowski, and S. Wrycza, editors, InformationSystem Development. Towards a Service Provision Society,Proc. of ISD’2008, volume 1. Springer, 2009.

[6] A. Badica, C. Badica, and L. Litoiu. Middle-agents in-teractions as finite state processes: Overview and example.In Proc.16th IEEE International Workshops on EnablingTechnologies: Infrastructure for Collaborative Enterprises(WETICE 2007), pages 12–17. IEEE Computer Society, 2007.

[7] H. Foster, S. Uchitel, J. Magee, and J. Kramer. Model-basedverification of web service compositions. In Proc.18th IEEEInternational Conference on Automated Software Engineer-ing, pages 152–163. IEEE Computer Society, 2003.

[8] C. Guidi, R. Lucchi, and M. Mazzara. A formal frameworkfor web services coordination. Electronic Notes in TheoreticalComputer Science, 180(2):55–70, 2007.

[9] J. Johnson, D. Langworthy, L. Lamport, and F. Vogt. Formalspecification of a web services protocol. Journal of Logicand Algebraic Programming, 70(1):34–52, 2007.

[10] J. Magee and J. Kramer. Concurrency. State Models and JavaPrograms (2nd ed.). John Wiley & Sons, 2006.

[11] R. Milner. Communicating and Mobile Systems: The π-calculus. Cambridge University Press, Cambridge, 1999.

[12] I. Robinson. The Roots of WS-Coordination. http://ianrobinson.blogspot.com/2007/01/roots-of-ws-coordination.html, 2007.

[13] R. Smith. The contract net protocol: High-level communi-cation and control in a distributed problem solver. IEEETransactions on Computers, C-29(12):1104–1113, 1981.