On the Impact of Formal Methods in the SOA

(1)

On the Impact of Formal Methods in the SOA

Laura Bocchi

1

Dipartimento di Science dell’Informazione, University of Bologna Mura Anteo Zamboni 7, 40127 Bologna, Italy

Paolo Ciancarini

2

Dipartimento di Science dell’Informazione, University of Bologna Mura Anteo Zamboni 7, 40127 Bologna, Italy

Abstract

We present an overview of recent research that provide a formal analysis of coordination and composition in Service Oriented Architectures. In particular we focus on transactional support in the Web Service Architecture. The classic notion of transaction in database systems evolved into weaker forms, in order to adapt to multi-domain, loosely coupled environments including the execution of long running activities. Despite the shared interest in these weaker transactions, supported by most languages for Web service coordination and composition, in many cases there is not an agreement on their semantics. Transactions are considered under two complementary perspectives. The former is the local perspective of the business process: transactions are a control construct providing a user-deﬁned error handling mechanism. The latter, is the perspective addressing the synchronization among distributed services: distributed transaction protocols. Distributed transaction protocols are evolving according to the requirements of the real e-business scenario over the Web. One particular direction of this evolution, that we discuss, is the negotiation of service capabilities to enable automated selection.

Keywords: Service oriented architectures, transactions, formal methods.

1 Introduction

In the last decade the Web as the dominating Internet service has evolved into the most popular and widespread platform for world wide global information systems. At its core, the Web is a hypertext in which documents are oﬀered by servers, retrieved by clients with the HTTP protocol, and displayed by graphical interfaces that are very easy to use. Because of its diﬀusion, the usage of the Web as a platform for dynamic, distributed applications rapidly attracted the interests of both industry and academia.

1 _{Email:[email protected]} 2 _{Email:[email protected]}

(2)

At the same time, one of the main trends that we can observe since within diﬀerent areas of application of Computer Science, is the creation of complex systems as a composition of simpler, heterogeneous, and possibly distributed parts.

On the e-business scenario, we observe a common trend toward outsourcing [34]. Outsourcing means contracting workers from outside a company to perform specific tasks instead of using company employees. Applying this term to the In-formation Technology (IT) infrastructure of a company means exploiting external hardware and software resources and integrate them with the internal system. The IT infrastructure of a company might thus comprise external resources, networks and services as well as internal or legacy parts. As to e-science, the need concerns huge computational power to perform scientific tasks and wide storage to manage big amount of data. Since the middle of 90’s the firsts Grid experiments meant to address this issue.

The consequent need of a middleware that integrates dynamic services running on distributed, heterogeneous platforms led to diﬀerent but in some parts interleav-ing solutions. The problem, in its most general signiﬁcance, has been addressed trough the concept of Service Oriented Architecture (SOA).

At present, diﬀerent areas are adopting the Web protocols as a basis for service oriented middleware infrastructures. For example, e-business and e-science are cur-rently focusing their attention on middleware platforms that merge the notion of SOA with the usage of Web infrastructures and protocols (i.e., Web Service Archi-tecture (WSA) [11] for e-business and Open Grid Service Architecture (OGSA) [25] for e-science).

In this paper we discuss the key ideas of the Service Oriented Architecture, and the impact that formal methods in the coordination and composition of services in the Web Service Architecture. Our discussion will focus on the particular coordi-nation issue of transactional support in loosely coupled environments. Transactions are considered under two complementary perspectives. The former is the local per-spective of the business process: transactions are a control construct providing a user-defined error handling mechanism. The latter, is the perspective addressing the synchronization among distributed services: distributed transaction protocols. Distributed transaction protocols are evolving according to the requirements of the real e-business scenario over the Web. One particular direction of this evolution is the negotiation of the capabilities that are provided by a service, that addresses the automation of services selection. Negotiation involves a number of different issues (i.e., the negotiation protocol, the internal strategy of the participants, the descrip-tion of the negotiated features) that benefit from the usage of formal methods.

Synopsis. Section 2 presents an overview of service oriented computing. Sec-tion 3 discusses the impact of formal methods in coordination of services in the WSA. Section 4focus on service composition and on formal approaches to the en-actment of a negotiation. Section 5 presents the conclusion and ﬁnal remarks.

(3)

2 Coordination and Composition in the Service

Ori-ented Architecture

A SOA is ‘a set of components which can be invoked, and whose interface descrip-tions can be published and discovered’ [10]. Services are network addressable entities with a well deﬁned, easy-to-use and standardized interface.

Services have stateless connections; they are available to possible clients by waiting in a idle state until a request comes. They communicate by means of standard protocols, and they can be easily accessed and readily used with no need for integration. A services may be used in diﬀerent scenarios as, typically, it is not bound to a precise costumer context.

The notion of service presents analogies with the notion of software component. Services like components are loosely coupled and they are often designed indepen-dently from the context in which they are used and composed. What distinguish the two concepts is the level of abstraction. SOAs typically involve multiple orga-nizations that interact with a networked systems where there is no single designer having full knowledge, control and ownership. Services are the non-material equiva-lent of a good, they are owned by a particular organization and they have a semantic that is meaningful for some other customer organization. In this sense, services are more coarse grained than components. As an example, the WSA can be described as a self-interested system where a server provides some beneﬁts to the client for its own interest (e.g., the service is ‘bought’ by the client).

Coordination and composition have a key role in architectures based on the notion of service. The activity of services is typically cooperative: they can be invoked by other services or simply interact in order to carry on a task.

Services Coordination. Services, in their essence, are stateless entities. Besides, Many business-to-business scenarios need a stateful, collaborative behavior thus implying complex coordination. It is thus crucial to specify a precise order and causality of the service operations (for example: a purchase should happen after a payment). In the Web service scenario, nothing prevents from coordinating ser-vices at the level of application code. Anyway, most coordination languages have their focus on a clear separation between coordination and computation, seen as orthogonal language design issues. A very famous metaphor in form of a simple equation [16] establishes this orthogonality as follows:

application = computation + coordination. (1)

Thus, according to such a metaphor a programming language should be composed of two orthogonal components: a coordination component and a computational component. This separation is effective from a software engineering viewpoint: keeping the specification of coordination issues separate from computational issues brings interaction to a higher level of abstraction thus simplifying the programming task. This separation is crucial in a SOA: in a loosely coupled systems, characterized by a high impact of change, modularity is an important feature. Since the 90’s the business logic can be expressed and managed separately from the application by means of a centralized Workflow Management System (WFMS). In the context of

(4)

WfMSs Equation1 has been rewritten as [39]:

workﬂow = activities + processes (2)

where the basic entities involved in a workﬂow are activities performing working units while processes are employed for coordinating such activities. This approach is followed by current XML-based languages (e.g., orchestration/choreography lan-guages) that attempt to standardize the possibility of service coordination in the WSA.

Services Composition. Composition is a crucial feature in SOAs: new services can be oﬀered by composing existing ones. A service that acts as the composi-tion of other services is simultaneously a client and a server. For this reason, the relationship among services is peer-to-peer, more than client-server-like. The in-teroperability and composition of services belonging to heterogeneous domains is enabled by the usage of standard protocols and interfaces.

In the context of Service Oriented Architectures (SOAs), services can be pub-lished, modiﬁed and revoked at any time; this implies a high impact of change. Services can be statically bound or they can dynamically search for other services to cooperate with. Making composition dynamic and automated requires

(i) a software entity capable of selecting in a dynamic environment the services to invoke,

(ii) a machine-readable speciﬁcation of what a service requires and provides (i.e., the service semantic).

As to (1), the automation of service composition can achieve considerable bene-ﬁts from technologies deriving from the agents scenario. According to the deﬁnition of Burstein-McDermott Agents are ‘programs that operate at a high enough seman-tic level that they can form new connections to other programs in order to get a job done’.

In a highly dynamic system where services can be published, modified and re-voked at any time, it is desirable for composition not to rely only on a priori infor-mation. In some cases the aspects that characterize a service can be known just at run time (e.g., the load of a system) or they are critical for the client service. Inter-estingly, the scenario of dynamic automated service composition is similar to that of Distributed Problem Solving (DPS) in multi-agent systems, where some knowledge-sources (KS) have to find a cooperative solution to a problem, in a decentralized way. In the context of DPS each knowledge source is not able to autonomously achieve the solution; thus the problem is decomposed in sub-tasks that are delegated to some other KSs. A KS can decompose the assigned task in further sub-tasks. Davis and Smith [20] proposed the Contract Net Protocol [45], enacting a negotiation based on a bidding activity, to solve DPS. Negotiation is ‘...a discussion in which the interested parties exchange information and come to an agreement’ [20]. In the most general significance the discussion is a process involving parties that can be either human or software agents.

The interaction between agent involved in a CNP has been described by the Foundation for Intelligent Physical Agents (FIPA) [24] by means of the following

(5)

steps: (a) the Initiator sends a call for proposal, (b) each Participant reviews the received call for proposal (possibly from diﬀerent initiators) and bids accordingly, (c) the Initiator chooses the best bid, awards the Contract to the respective Participants and rejects the other bids. In [8] we discussed the analogy of CNP, and the problem it addresses, with problems and solutions in the WSA. Section4of this paper recalls such aspects of this discussion.

As to (2), it is important to have some model that describes, in a machine readable way, the capabilities provided by a service. A key issue is to suitably deﬁne which aspects of a service are captured by the description (e.g., its functional, non functional, and behavioral properties) and which kind of language is used to express them. In [5] three approaches to service description are discussed: text based (searching is typically done by pattern matching), frame based (properties of a service are expressed as couples attribute-value), and ontology based. The advantages of using ontologies are remarked, considering recall (i.e., absence of false negative) and precision (i.e., absence of false positive) in the search process. An ontology is a description of an abstraction (conceptual schema) consisting in a vocabulary plus a semantics. An ontology expresses a range of concepts and the relationship among them; it can be represented by a XML ﬁle and it is typically used to describe semantic aspects of a resource in a machine readable way.

3 Formal Methods for Web Service Coordination

Web services are based on a very minimal set of concepts: service, XML document, address and envelope [51]. Furthermore, all the Web services must expose an inter-face that is expressed using the Web Service Deﬁnition Language (WSDL) [17]. The messages contained in the envelope and the WSDL interfaces are XML based; this has a crucial role in the automation of Web services interactions. Behind a WSDL interface there might be a variety of entities: a stateless service, a subservient ob-ject, a human or an autonomous agent with its own life cycle. Anyway, the WSA does not provide statefulness of interactions as a built in feature: all the data for a request must be in the request. Statefulness is an important requirement in many e-business scenarios. It typically implies a complex coordination of the activities performed by each single service. Current XML-based languages are emerging in the Web service scenario that support statefulness and coordination in an orthogonal way to computation, according to Equation1.

Some of these languages, under the general headings of orchestration and chore-ography, attempt to standardize the possibility of service coordination and composi-tion by supporting the deﬁnicomposi-tion, execucomposi-tion and management of a business process. Some other standards, that in [23] are called Composable Service Assurances, intend to extend base Web service properties (i.e., Quality of Service) by means of speciﬁc information inside the SOAP message headers. Some properties are security (e.g., WS-Security [2]), reliability of messaging upon unreliable connections (e.g., WS-ReliableMessaging [6]) and support for business transactions (e.g., Business Transaction Protocol (BTP) [42] and WS-Transaction [15]).

(6)

In the rest of this section we discuss the impact of formal methods in Web service coordination. Section 3.1 focus on orchestration and choreography, and in particular on emerging notions of transaction as a control constructs of business processes in loosely coupled environments. As to Composable Service Assurances, Section 3.2considers the distributed protocols that underpin the standards for the support of business transactions.

3.1 Orchestration and Choreography

In the WSA, the activities of Equation 2 (workflow = activities + processes) are Web services that can be processes themselves and that are invoked by means of standard messages along the Internet. As to the processes, the definition and man-agement of this composition component is, at present, addressed by the emerging orchestration and choreography standards. It does not exist a universally accepted definition, the two terms are somehow overlapping, and somehow referring to com-plementary perspectives of the composition problem [43]. Orchestration character-izes executable business processes that embody the local perspective of a particular party. Choreography describes the interaction pattern between different distributed business processes according a the global perspective.

Several XML-based languages have been proposed for orchestration and chore-ography. Orchestration languages are for instance BPML [22], XLANG [47] and WSFL [38]. BPEL4WS [18] has been proposed as a merge of XLANG and WSFL, therefore it presents analogous features. In this sense it could be deﬁned as an orchestration language. It is usually referred to as a choreography language since it also allows to specify some roles, partners, and relations for a complex distributed interaction. The Oracle WS-CDL [33] is a choreography language.

Existing research addressed the formal deﬁnition of orchestration and choreog-raphy aspects. Much of the work in this context use message-based process algebras that can suitably describe coordination aspects in the WSA, as the main proposals for Web service orchestration and choreography are also message based.

To this aim, the choice of the pi calculus [41] in often motivated by its capability of modeling the dynamic binding of services. In fact, the possibility of commu-nicating channel names as messages, enables the dynamic instantiation of output channels. This aspect makes pi calculus more suitable than CCS [40]. For example, the process defined in 3 models a business process that receives the reference to a flight booking service from a service broker known a priori, and then invokes the actual flight booking service that has been discovered at run time.

service broker(flight booking).flight booking (flight request) (3)

Busi, Guidi et al. investigate, in the papers [28,13], the rules of composition and coordination of Web services with the pi calculus. Choreography deﬁnes the coor-dination/composition rules of a number of services participating to the interaction according to a role. A notion of conformance between choreography (global perspec-tive) and orchestration (local perspecperspec-tive) is deﬁned by means of a bisimulation-like relation.

(7)

Some other work, analyzed emerging concepts related to the support of transac-tions in the WSA and addressed the lack of a rigorous speciﬁcation of the semantic of Web transactions within a business process. The classic notion of transactions, typical of database systems, evolved, granting weaker properties than the ACID ones, in order to adapt to multi-domain and loosely coupled environments. These weaker transactions, referred to as long running transactions, are object of a shared interest and are supported, in a mainly local perspective, by the languages for ser-vice orchestration such as XLANG [47] and BPEL4WS [18]. Despite the interest in long running transactions in the WSA, their semantics, as well as the slight diﬀer-ences among languages, may be hardly pointed out due to the informal nature of the documents, and to the complexity of parsing implementations.

It follows an overview of some work that extend some process algebra with long running transactions.

Bocchi et al. [9] proposed πt-calculus to address the formal analysis of long run-ning transactions, as specified in XLANG and implemented by Microsoft BizTalk. πt-calculus is an extension of the asynchronous pi calculus with long running trans-actions and the sequential composition. A transaction is defined with a compact syntax as a set of main process, exception handler and compensation. The focus is put on the compensation mechanism, that does not grant isolation by definition: when a transaction fails some effects of its execution could already have been made visible to external parties. Compensation in this case can cancel just a part of the effects of a transaction. This is modeled in πt-calculus by the fact that a process can emit messages out of the transaction boundary during the transaction execution. πt-calculus has been encoded into the asynchronous pi calculus.

Bruni et al. [12] implemented long running transactions with the Join calcu-lus [26]. In these papers more grants are given, with respect to πt-calculus, con-cerning isolation: messages can not cross the transaction boundaries until the com-mitment occurs.

Laneve et al. [36] deﬁned a process calculus, Web-π , with timed transactions. The approach of Web-π is more general than that of πt-calculus: the focus is on the orchestration language (i.e., BPEL) and not on a precise implementation of it (i.e., BizTalk).

BPEL has also been modeled by Hinz et al. [30] with Petri Nets. Petri Nets are a suitable to represent workﬂow schedules [48,50] and have been used to model and analyze a fairly complete set of workﬂow patterns [49].

Butler et al. [14] proposed StAC (Structured Activity Compensation) to model error handling and compensation. StAC is an algebraic language that manages ar-bitrary levels of nesting. πt-calculus provides a simpler semantic for the mechanism of compensation triggering by putting the focus only on two levels of nesting. The management of multiple nesting levels can be achieved, in πt-calculus, by explicitly programming a compensation to call the compensations of the nested transactions. The more complex semantic of StAC is managed by keeping the aspects of process management separated from those of error/compensation management.

(8)

Fig. 1. A cohesion representing a nested business activity

3.2 Distributed Transaction Protocols

In Section 3.1transactions have been considered as a mechanism for building higher level (composite) actions, up to a local perspective. For example long running transactions can be included in a workflow schedule specified with an orchestration language (e.g., XLANG); the business process associated to the schedule, that pos-sibly involves calls to remote services, is executed by a local engine (e.g., Microsoft BizTalk). The definition of an orchestration, by means of language as XLANG or BPEL, provide a flexible way to coordinate actions among Web Services.

There is also a number of these standard proposals that oﬀers support for tributed business transactions. These languages, provide a mean to enact a tributed transaction using standard messages. The aim is to synchronizes the dis-tributed status of services and let the participants to achieve a commitment. As choreography describes business interaction patterns among diﬀerent Web Services, distributed transaction protocols describe the multi-step interaction among multiple distributed participants that enact a distributed transaction.

We already mentioned WS-Transaction that has been modeled and analyzed with the Temporal Logic of Actions [35] in [32]. We discuss here BTP with particular emphasis, as it presents interesting intersections with the issue of negotiation.

BTP supports two types of transaction: atoms and cohesions. Atoms are a loosely coupled version of the classic ACID transaction: it commits only if all its sub-entities are able to commit, and in case of commitment all its sub-entities commit. Atoms are representable as instances of atomic commit. The atomic com-mit [29] is a well known problem addressing the agreement of a number of distributed participants (distributed consensus) to achieve a global outcome, typically commit or abort. With cohesions the consensus is no longer required. A cohesion can de-cide to commit even if some of its sub-entities are unable to commit. Furthermore in case of commit, a cohesion can decide to reject the commitment of some of its sub-entities, causing their failure. Figure 1 illustrates an example of cohesion en-closing multiple distributed and multi-organizational transactions, that models a travel booking service. The service travel booking tries to book different alternative flights (the same path with two different airlines) and to rent a car. Travel booking succeeds if at least one of the airlines has available flights. In that case both airlines have available flights, travel booking commits but rejects the reservation of the most expensive flight

In [7] the generic BTP transaction manager has been modeled with the asyn-chronous pi calculus. The implementation extends the implementation of Two Phase Commitment Protocol with the asynchronous pi calculus provided by Berger

(9)

and Honda [4]. The extension involves the management of an arbitrary number of nesting levels and the ﬂexible behavior of cohesions, with respect to that of atoms. In particular, the set of children of a node is partitioned in necessary/unnecessary in order to decide whether to commit or not. Furthermore, the same set is partitioned in accepted/rejected in order to decide, in case of commitment, which of the children is conﬁrmed. Interestingly, atoms are modeled as a special case of cohesion where all the children are necessary and accepted. [7] anyway does not model run-time choice of the partitions and unreliability (that is instead managed by Berger and Honda in [4]).

4 Negotiation and Service Composition

Composition is a key feature in SOAs. Applying the widespread and accepted Web protocols to the notion of SOA provided a set of standards for the integration of heterogeneous systems. This possibility already supports outsourcing, up to a cer-tain degree, by enabling static composition. In the simplest case, composition relies on a static activity where service cooperation is decided a prior by a human. Also in this basic case Web services increase the amount of automatization of the inter-actions between enterprizes. For example, let us consider two companies, A and B, that already cooperate using the Web; in particular A provides a Web interface for some services as the possibility of ordering merchandize. The Web interface of the service provided by A (i.e. the ordering form) could be periodically used by human employees of B. Web services enable A to define a Web service interface to the ordering service, so that B can run an a software agent that periodically and auto-matically requests merchandize. In the Web scenario there are already a number of meta-services (i.e., providing their own service by exploiting other sub-services). For example www.edreams.com offers an interface to different flight companies in order to propose the best offers. Another example is Accuradio (www.accuradio.com), a radio via Web that provides the possibility of purchasing the music that is played using Amazon. Amazon, on the other hand, sells books and music by exploiting the mail service.

Recalling Section2, a desirable step forward consists in supporting the automa-tion of, possibly dynamic, service composiautoma-tion. In the rest of this secautoma-tion we focus our discussion on the negotiation of services, as it includes a set of problems that are meaningful to this aim. In [31] negotiation is described by means of a number of orthogonal issues:

objects description the description of the objects that have to be sold/bought, protocol the pattern of information exchange between the parties,

strategy the evaluation rules to decide whether to sign an agreement.

The object description. In this case it consists in the description of services capabil-ities. Automation of composition is partially addressed by the usage of XML-based standards for a machine readable message and interface description (i.e., WSDL). Also, orchestration languages provide the possibility of deﬁning business processes

(10)

where the binding of an activity with an actual service is done at run time. Besides, there is a number of additional elements that characterize a service and that are not captured by the above mentioned standards (e.g., the service semantic, the Quality of Service (QoS), etc.) Ongoing research is investigating diﬀerent approaches to the addition of these concepts to service description.

Some of these approaches are based on the notion of ontology. For example OWL-S [27] is an OWL based ontology for the description of services that has been created as a part of the DARPA Agent Markup Language Program (DAML) [19]. The Web Ontology Language (OWL) is the World Wide Web Consortium (W3C) recommendation [3] for deﬁnition of ontologies on the Web. OWL-S includes functional, non functional and behavioral description of services.

Another work that focus on QoS, and that is mostly oriented to the Grid scenario is [1]. In [1], many quality perspectives are simultaneously considered, relying on the Logic Scoring of Preferences (LSP) method [46], a quantitative decision method for evaluation, comparison and selection of hardware and software systems consisting of:

(i) a quantitative evaluation of the satisfaction associated to each value returned by measurements of the attributes under investigation,

(ii) the aggregation of such satisfactions in a global score.

Finally, we cite an approach based on process algebra [21], that deﬁnes a process calculus with QoS attributes, and provides primitives to coordinate services on the basis of these properties.

The protocol. The protocol has to be known and applied by all the parties in order to perform a correct conversation. In the WSA, the OASIS BTP support an exchange of messages that can enact a negotiation (i.e., cohesions).

The problem of automated dynamic service composition in SOAs presents analo-gies with the notion Distributed Problem Solving (DPS) and, interestingly, CNP presents some similarities with the notion of cohesion. There is a procedural anal-ogy since in both cases (1) the initiator sends a call for proposal (CFP) to many potential contractors, (2) the initiator awaits for proposals for a certain amount of time, (3) the initiator chooses a number of bids to award. Participants can sub-contract. Furthermore, both CNP and cohesion refer to a context of self interested agents where the strategy reﬂects the local perspective of a party.

Pi-CNP [8] is a model of a variant of CNP (i.e., Acceptance-Guaranteed Pro-tocol [37]) with the asynchronous pi calculus. Pi-CNP has been modeled as a generalization of the model of cohesion [7] with the asynchronous pi calculus.

The strategy. The strategy is embodied within each single party; the evaluation is done according to a single party’s perspective. In this case, some formal language is required to perform an automated decision.

In Pi-CNP the focus is put on the protocol. Strategy is not addressed in detail but, since it induces choices that inﬂuence the execution of the protocol, it is rep-resented as a non deterministic among all the possible internal choices operated by the node. Strategy can have the following inﬂuences on the protocol execution:

(11)

the proposal The participant node has to deﬁne a proposal given a call for

pro-posal.

the outcome On the basis of the received proposals an initiator node decides

whether to sign the agreement or not,

the contractors In case of an agreement, an initiator node must decide which of

the participants to include,

Some preliminary considerations have been done in [8] to study the relationship between different protocols by defining different strategies within the same protocol skeleton (i.e., Pi-CNP). In particular, a strategy has been provided to implement an atomic commit protocol. Different approaches can be adopted to refine the treatment of the strategy, including for example the usage of logic-based languages. The development of such mechanisms and their integration with the model of the protocol are a desirable future work.

5 Conclusion

This paper discussed the main aspects characterizing a SOA and focused on diﬀerent approaches to the formal analysis of coordination and composition of services in the WSA.

In particular, emerging concepts related to the support of transactions have been considered. The focus has been put both on the local perspective of the business process and on the distributed perspective of transaction protocols. Composition of services, and its automation have also been considered. We discussed issues related to service description and negotiation. Diﬀerent approaches to the formal analysis of coordination and composition have been discussed.

The issues presented in this paper are included in the goals of the ongoing Euro-pean project SENSORIA (Software Engineering for Service-Oriented Overlay Com-puters) [44]. Sensoria aims to develop a novel pragmatic approach to the engineering of service-oriented software systems, that comprehends and integrates foundational theories, techniques and methods. Further developments of the presented research is expected in the context of the project, such as just in time composition of services.

References

[1] Andreozzi S., Montesi D., Ciancarini P. and Moretti R., Towards a Model for Quality of Web and Grid Services, in: Proceedings of the 13th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’04) (2004), pp. 271–276.

[2] Atkinson B., Della-Libera G., Hada S., Hondo M.A., Hallam-Baker P., Klein J., La Macchia B., Leach P., Manferdelli J., Maruyama H., Nadalin A., Nagaratnam N., Prafullchandra H., Shewchuk J. and Simon D., Web Services Security (WS-Security) (2002).

URLwww-106.ibm.com/developerworks/webservices/library/ws-secure/

[3] Bechhofer S., Harmelen F., Hendler J., Horrocks D., McGuinnes I., Patel-Schneider P. and Stein L.A., OWL Web Ontology Language Reference, Technical report, World Wide Web Consortium (W3C) (2004).

URLwww.w3.org/TR/owl-ref/

[4] Berger M. and Honda K., The Two-Phase Commitment Protocol in an Extended Pi-calculus, Electronic Notes in Theoretical Computer Science39 (2003), pp. 105–130.

(12)

[5] Bernstein P. A.and Hadzilacos V. and Goodman N., “Concurrency Control and Recovery in Database Systems,” Addison-Wesley, 1987.

[6] Bilorusets R., Bosworth A., Box D., Cabrera F., Collison D., Ferguson D., Ferris C., Freund T., Hondo M.A., Ibbotson J., Kaler C., Langworthy D., Lewis A., Limprecht R., Lucco S., Mihic M., Mullen D., Nadalin A., Nottingham M., Orchard D., Samdarshi S., Shewchuk J. and Storey T., Web Services Reliable Messaging protocol (WS-ReliableMessaging) (2004).

[7] Bocchi L., Compositional Nested Long Running Transactions, in: Wermelinger M. and Margaria T., editors, Proceedings of the 7th International Conference on Fundamental Approaches to Software Engineering (FASE 2004), Lecture Notes in Computer Science2984 (2004), pp. 195–208.

[8] Bocchi L., Ciancarini P. and Lucchi R., Atomic Commit and Negotiation in Service Oriented Computing, Technical Report UBLCS-2005-16, University of Bologna, Italy (2005).

URLftp://ftp.cs.unibo.it/pub/techreports/2005/2005-16.pdf

[9] Bocchi L., Laneve C. and Zavattaro G., A calculus for long running transactions, in: Najm E., Nestmann U. and Stevens P., editors, Proceedings of the 6th IFIP WG 6.1 International Conference on Formal Methods for Open Object-Based Distributed Systems (FMOODS 2003), Lecture Notes in Computer Science2884 (2003), pp. 124–138.

URLwww.cs.unibo.it/∼laneve/papers/biztalk.pdf

[10] Booth D., Haas H. and Brown A., Web Services Glossary, Technical report, World Wide Web Consortium (W3C) (2004).

URLwww.w3.org/TR/ws-gloss/

[11] Booth D., Haas H., McCabe F., Newcomer E., Champion M., Ferris C. and Orchard D., Web Service Architecture, Technical report, World Wide Web Consortium (W3C) (2004).

URLwww.w3.org/TR/ws-arch/

[12] Bruni R., Melgratti H. and Montanari U., Nested Commits for Mobile Calculi: Extending Join, in: Levy J-J., Mayr E. W. and Mitchell J. C., editors, Proceedings of 3rd IFIP International Conference on Theoretical Computer Science: Exploring New Frontiers of Theoretical Informatics (IFIP TCS 2004) (2004), pp. 563–576.

[13] Busi N., Gorrieri R., Guidi C., Lucchi R. and Zavattaro G., Choreography and Orchestration: a Synergic Approach for System Design, in: Proceedings of 3rd International Conference of Service Oriented Computing (ICSOC’05), 2005, to appear.

[14] Butler M. J. and Ferreira C., An Operational Semantics for StAC, a Language for Modelling Long-Running Business Transactions, in: De Nicola R., Ferrari G. L. and Meredith G., editors, Proceedings of 6th International Conference on Coordination Models and Languages (COORDINATION’04), Lecture Notes in Computer Science2949 (2004), pp. 87–104.

[15] Cabrerea F., Copeland G., Cox B., Freund T., Klein J., Storey T. and Thatte S., Web Services Transaction (WS-Transaction) (2002).

URLwww-106.ibm.com/developerworks/webservices/library/ws-transpec/

[16] Carriero N. and Gelernter D., Coordination Languages and Their Signiﬁcance, Communications of the ACM35 (1992), pp. 97–107.

[17] Christensen E., Curbera F., Meredith G. and Weerawarana S., Web Services Description Language (WSDL) 1.1 (2001).

URLwww.w3.org/TR/wsdl

[18] Curbera F., Goland Y., Klein J., Leymann F., Roller D., Thatte S. and Weerawarana S., Business Process Execution Language for Web Services (BPEL4WS 1.1), Technical report (2004).

URLwww-106.ibm.com/developerworks/webservices/library/ws-bpel/ [19] DARPA, The DARPA Agent Markup Language.

URLwww.daml.org

[20] Davis R. and Smith R. G., Negotiation as a Metaphor for Distributed Problem Solving, in: Readings in Distributed Artiﬁcial Intelligence, Morgan Kaufmann Publishers Inc., 1988 pp. 333–356.

[21] De Nicola R., Ferrari G., Montanari U., Pugliese R. and Tuosto E., A Basic Calculus for Modelling Service Level Agreements, in: Jacquet J. and Picco G. P., editors, International Conference on Coordination Models and Languages, Lecture Notes in Computer Science3454 (2005), pp. 33 – 48. [22] Dubray J. J., A novel approach for modeling business process deﬁnitions (2002).

URLwww.ebpml.org/ebpml2.2.doc

[23] Ferguson D.F., Storey T., Lovering B. and Shewchuk J., Secure, Reliable, Transacted Web Services (2003).

(13)

[24] FIPA, “FIPA Contract Net Interaction Protocol Speciﬁcation,” FIPA (2001). URLwww.fipa.org/specs/fipa00029/

[25] Foster I., Kesselman C. and Tuecke S., The Anatomy of the Grid: Enabling Scalable Virtual Organizations, International Journal of Supercomputer Applications15 (2001), pp. 200–222. [26] Fournet C. and Gonthier G., The Reﬂexive Chemical Abstract Machine and the Join-Calculus, in:

Proceedings of the 23rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages (POPL ’96) (1996), pp. 372–385.

[27] France Telecom, Maryland Information and Network Dynamics Lab at the University of Maryland, National Institute of Standards and Technology (NIST), Network Inference, Nokia, SRI International, Stanford University, Toshiba Corporation and University of Southampton, OWL-S (2005).

URLwww.w3.org/Submission/2004/07/

[28] Gorrieri R., Guidi C. and Lucchi R., Reasoning about Interaction Patterns in Choreography, in: 2nd International Workshop on Web Services and Formal Methods (WS-FM’05), Lecture Notes in Computer Science3670 (2005), pp. 333–348.

[29] Hadzilacos V., On the Relationship Between the Atomic Commitment and Consensus Problems, in: Simons B. and Spector A. Z., editors, Fault Tolerant Distributed Computing, Lecture Notes in Computer Science448 (1990), pp. 201–208.

[30] Hinz S., Schmidt K. and Stahl C., Transforming BPEL to Petri Nets, in: Business Process Management, 2005, pp. 220–235.

[31] Jennings N. R., Parsons, S., Sierra C. and Faratin P., Automated Negotiation, in: Proceedings of 5th Int Conf. on Practical Application of Intelligent Agents and Multi-Agent Systems (PAAM-2000), 2000, pp. 23–30.

[32] Johnson J. E., Langworthy D. E., Lamport L. and Vogt F. H., Formal Speciﬁcation of a Web Services Protocol, in: Proceedings of the 1st International Workshop on Web Services and Formal Methods (WS-FM 2004), Electronic Notes in Theoretical Computer Science105 (2004), pp. 147–158.

[33] Kavantzas N., Olsson G., Mischkinsky J. and Chapman M., Web Services Choreography Description Language (WS-CDL) 1.0 (2004).

URLwww.w3.org/TR/ws-cdl-10/

[34] Klepper R. and Jones W. O., “Outsourcing Information Technology, Systems and Services,” Prentice Hall, Inc., 1998.

[35] Lamport L., The Temporal Logic of Actions, ACM Transactions on Programming Languages and Systems (TOPLAS)16 (1994), pp. 872–923.

[36] Laneve C. and Zavattaro G., Foundations of Web Transactions, in: Proceedings of Foundations of Software Science and Computation Structures (FOSSACS 2005), 2005, pp. 282–298.

[37] Lee K. J. and Chang Y. S., Time-Bounded Negation Framework for Multi-Agent Coordination, in: Selected papers from the First Paciﬁc Rim International Workshop on Multi-Agents, Multiagent Platforms (PRIMA’98), Lecture Notes in Computer Science1599 (1999), pp. 61–75.

[38] Leymann F., Web Services Flow Language (WSFL 1.0) (2001). URLwww-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

[39] Leymann F. and Roller D., “Production Workﬂow: Concepts and Techniques,” Prentice Hall PTR, 2000.

[40] Milner, R., “A Calculus of Communicating Systems,” Lecture Notes in Computer Science92, Springer Verlag, 1980.

[41] Milner R., “Communicating and Mobile Systems: the Pi-Calculus,” Cambridge University Press, 1999. [42] OASIS, Business Transaction Protocol (2002).

URLwww.oasis-open.org/

[43] Peltz C., Web Services Orchestration and Choreography, IEEE Computer36 (2003), pp. 46–52. [44] Sensoria, Software Engineering for Service-Oriented Overlay Computers (SENSORIA).

URLsensoria.fast.de/

[45] Smith R. G., The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver, in: Readings in Distributed Artiﬁcial Intelligence, Morgan Kaufmann Publishers Inc., 1988 pp. 357–366.

(14)

[46] Su S.W., Dujmovic J. J., Batory D. S., Navathe S. B. and Elnicki R., A Cost-Beneﬁt Decision Model: Analysis, Comparison, and Selection of Data Management Systems, ACM Transaction on Database Systems12 (1987), pp. 472–520.

[47] Thatte S., XLANG: Web Services for Business Process Design (2001). URLwww.gotdotnet.com/team/xml wsspecs/xlang-c/default.htm

[48] Van der Aalst W. M. P., Three Good Reasons for Using a Petri-net-based Workﬂow Management System, in: Progeedings of International Working Conference on Information and Process Integration in Enterprises (ICEIS’96), 1996, pp. 179–201.

[49] Van Der Aalst W. M. P., Ter Hofstede A. H. M., Kiepuszewski B. and Barros A. P., Workﬂow Patterns, Distributed Parallel Databases14 (2003), pp. 5–51.

[50] Van der Aalst W.M.P., The Application of Petri Nets to Workﬂow Management, The Journal of Circuits, Systems and Computers8 (1998), pp. 21–66.