Web Services Choreography and Orchestration ... - ACM Digital Library

Web Services Choreography and Orchestration in Reo and Constraint Automata Sun Meng [email protected]

Farhad Arbab [email protected]

CWI, Amsterdam, The Netherlands

ABSTRACT

tion development processes. Services are platform- and networkindependent operations that can be invoked by customers and other services. Web services [11] constitute a typical example of SOC, which aims to achieve universal inter-operability among applications by using web standards. Web services are considered as selfcontained, self-describing, modular applications that can be published, located, and invoked across the Web. Nowadays, an increasing number of companies and organizations implement only their core businesses and use other application services over the Internet to support their needs. Thus, how to efficiently and effectively select and integrate heterogeneous services on the Web is an important problem in the development of web services applications. Especially, if no single web service can satisfy some requirements, there should be a possibility to combine existing services together in order to fulfill those requirements. Recently, the web services community has been discussing the problem of service composition whereby larger services are assembled using other services as basic units. A survey of existing proposals for composition of web services can be found in [18]. Current techniques, such as the Web Services Description Language (WSDL) [28], Universal Description, Discovery, and Integration (UDDI) [24], Simple Object Access Protocol (SOAP) [25], intend to provide languages that allow easy integration of services. Some other initiatives such as the Business Process Execution Language for Web Services (BPEL4WS or BPEL) [1], are focused on representing service compositions where flow of a process and bindings between services are known a priori. BPEL allows to describe the behaviour of a business process composed of web services based on interactions between the process and its partners (client and web services). Despite all these efforts, composition of web services still remains a highly complex task, and automatic composition of web services is a critical problem. Conspicuously, the principles of component-based software development (CBSD) [23] are not yet integrated in the various methods that currently exist for custom composition of web services. We, therefore, focus on the issues related to composition of web services. We aim to support service-based software development on and for the web. Composition of web services addresses the situation where a client request cannot be satisfied by available web services, but a composition of web services, obtained by combining “parts of” available component web services, can provide the service. Orchestration and choreography are two forms of service composition, which describe two aspects of creating business processes from composite web services. Orchestration refers to an executable business process that can interact with both internal and external web services to fulfill its task. The interactions occur at the message level, i.e., in terms of message exchanges and execution order. Orchestration always represents control from one party’s

Currently web services constitute one of the most important topics in the realm of the World Wide Web. Composition of web services lets developers create applications on top of service-oriented computing platforms. Current web services choreography and orchestration proposals, such as BPEL4WS, WSCDL, and WSCI, provide notations for describing the message flows in web service interactions. However, such proposals remain at the description level, without providing any kind of formal reasoning mechanisms or tool support for checking the compatibility of web services based on the proposed notations. In this paper, we present our work on compositional construction of web services using the Reo coordination language and constraint automata. Reo is an exogenous coordinational language based on channels. We investigate the possibility of representing the behaviour of web services using constraint automata as black-box components within Reo circuits. We describe the orchestration of web services by the product of corresponding constraint automata, and use Reo circuits for choreography of web services. We investigate the issues of description, orchestration, and choreography of web services at a unifying abstract level, based on constraint automata, which have been used as the semantics of the coordination language Reo, allowing us to derive a natural correspondence relationship between orchestration and choreography.

Categories and Subject Descriptors D.2 [Software Engineering]: Requirements/Specifications

Keywords Web services, Choreography, Orchestration, Reo, Constraint Automata

1.

INTRODUCTION

Service-oriented Computing (SOC) [16] has now become the prominent paradigm for distributed computing and e-commerce, creating opportunities for service providers and application developers to use services as fundamental elements in their applica-

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’07 March 11-15, 2007, Seoul, Korea Copyright 2007 ACM 1-59593-480-4 /07/0003 ...$5.00.

346

perspective and differs from choreography, which is more collaborative and addresses the interactions that implement the collaboration among services. Choreography tracks the message sequences among multiple agents rather than a specific business process that a single party executes. In this paper we present a formal framework for compositional construction of web services using Reo and constraint automata. As services are computational entities that may be running independently, we can naturally consider them as components in a coordination language. Reo [2] is an exogenous coordination model wherein complex coordinators, called connectors, are compositionally built out of simpler ones. Modelling the coordination and communication mechanism that bind concurrent services can be done by Reo circuits. Furthermore, the behaviour of each service as a blackbox component connected to the Reo circuit and their interaction can be specified by constraint automata [4]. The final goal is to have a unifying formalism for both orchestration and choreography of web services, and link the two by a refinement relationship, so that the behaviour of the peers and that of the overall system can be designed in a precise way. This paper is organized as follows: In Section 2, we provide a brief overview of Reo and constraint automata, which are used for description of web services and their composition in this paper. Web services are described as constraint automata in Section 3. In Section 4 we describe our approach for orchestrating web services using constraint automata wherein a composed web service is the product of the orchestrator and the invoked services. Section 5 shows how Reo circuits are used to specify the choreography of web services. Finally, in Section 6 we consider related research work, and in Section 7 we draw conclusions and discuss future work.

2.

components which are called port nodes. A

B

D

C

Y

X

E

F

G

H

K

Figure 1: Discriminator in Reo Figure 1 shows a Reo connector that implements the behavior of a blackbox that in the workflow literature is called a discriminator. The first item that arrives through one of the writers A, B or C is selected for output through the taker D. All three input values must arrive before the next cycle can start. Here, we use this figure to show the visual syntax for presenting Reo connector graphs and some frequently useful channel types. The enclosing thick box in this figure represents hiding: the topologies of the nodes (and their edges) inside the box are hidden and cannot be modified. Hiding yields a connector with a number of input/output ports, represented as nodes on the border of the bounding box, which can be used by other entities outside the box to interact with and through the connector. The simplest channels used in these connectors are synchronous (Sync) channels, represented as simple solid arrows (like the edge YD in Figure 1). A Sync channel has a source and a sink end, and no buffer. It accepts a data item through its source end iff it can simultaneously dispense it through its sink. A lossy synchronous (LossySync) channel is similar to a Sync channel, except that it always accepts all data items through its source end. If it is possible for it to simultaneously dispense the data item through its sink (e.g., there is a take operation pending on its sink) the channel transfers the data item; otherwise the data item is lost. LossySync channels are depicted as dashed arrows, e.g., AX, BX and CX in Figure 1. Another channel is the synchronous drain channel (SyncDrain), whose visual symbol appears as the edge EF, FG, GH or HK in Figure 1. A SyncDrain channel has two source ends. Because it has no sink end, no data value can ever be obtained from this channel. It accepts a data item through one of its ends iff a data item is also available for it to simultaneously accept through its other end as well. All data accepted by this channel are lost. The edge AE in Figure 1 represents an asynchronous channel with bounded capacity 1 (FIFO1), with the small box in the middle of the arrow representing its buffer. Data can flow in from its source when its buffer is empty, and flow out of its sink, if its buffer is not empty; input and output cannot take place simultaneously when the buffer is full or empty. Constraint automata were introduced in [4] as a formalism to capture the operational semantics of Reo, based on timed data streams which also constitute the foundation of the coalgebraic semantics of Reo. We recall the definition of timed data streams from [3]. The set of all (infinite) timed data streams over Data, which is a fixed, non-empty set of data that can be sent and received via channels, is given by

REO AND CONSTRAINT AUTOMATA

Reo is a channel-based coordination model wherein complex coordinators, called connectors, are compositionally built out of simpler ones. Primitive connectors are channels each of which has two channel ends. There are two types of channel ends: source and sink. A source channel end accepts data into its channel, and a sink channel end dispenses data out of its channel. It is possible for the ends of a channel to be both sinks or both sources. Reo places no restriction on the behaviour of a channel and thus allows an open-ended set of different channel types to be used simultaneously together. Each channel end can be connected to at most one component instance at any given time. Complex connectors are constructed by composing simpler ones via the join operation. Channels are joined together in a node which consists of a set of channel ends. A component can write data items to a source node that it is connected to. The write operation succeeds only if all (source) channel ends coincident on the node accept the data item, in which case the data item is transparently written to every source end coincident on the node. A source node, thus, acts as a replicator. A component can obtain data items, by an input operation, from a sink node that it is connected to. A take operation succeeds only if at least one of the (sink) channel ends coincident on the node offers a suitable data item; if more than one coincident channel end offers suitable data items, one is selected nondeterministically. A sink node, thus, acts as a nondeterministic merger. A mixed node nondeterministically selects and takes a suitable data item offered by one of its coincident sink channel ends and replicates it into all of its coincident source channel ends. Note that a component cannot connect to, take from, or write to mixed nodes. At most one component can be connected to a (source or sink) node at a time. The I/O operations are performed through interface nodes between different

T DS = {hα, ai ∈ Dataω × Rω + | ∀k ≥ 0 : a(k) < a(k + 1) and lim a(k) = ∞} k→∞

A timed data stream A = hα, ai represents occurrence of events at a port A and consists of a data stream α and a time stream a. The time stream a indicates for each data item α(k) the moment a(k) at which it is being input or output.

347

A constraint automaton over the data domain Data is a tuple A = (S, s0 , N , −→) where S is a set of states, also called configurations, S s0 ∈ S is its initial state, N is a finite set of nodes, −→⊆ N ⊆N S × {N } × DC(N ) × S, called the transition relation 1 . A transition fires if it observes data items in its respective ports/nodes of the component and according to the observed data, the automaton may change its state.

{D}, d_D=d_1 \/ d_D=d_2 \/ d_D=d_3 {A,B,C}, d_A=d_1, d_B=d_2, d_C=d_3 {A}, d_A=d {B,C,D}, d_D=d {C,D}, d_D=d_1 \/ d_D=d_2

N,g

We write s −→ s0 instead of (s, N, g, s0 ) ∈−→ and refer to N as the node-set and g the guard for the transition. Transitions where the node-set N is non-empty are called visible, while transitions with the empty node-set are called hidden. Constructing complex connectors out of simpler ones is done by the join operation in Reo. Joining two nodes destroys both nodes and produces a new node on which all of their coincident channel ends coincide. Each channel in Reo, and the merger nodes are mapped to a constraint automaton. The single most important composition operator in Reo, join, amounts to a product of automata. For two given constraint automata A1 = (S1 , s0,1 , N1 , −→1 ) and A2 = (S2 , s0,2 , N2 , −→2 ), their product is defined as a constraint automaton A1 ./ A2 with the components

{C}, d_C=d

{A,B}, d_A=d_1, d_B=d_2

{A,B,D}, d_D=d

{A,D}, d_D=d_1 \/ d_D=d_2 {B}, d_B=d {A,C,D}, d_D=d

{A,C}, d_A=d_1, d_C=d_2

{B,C}, d_B=d_1, d_C=d_2

{B,D}, d_D=d_1 \/ d_D=d_2

Figure 2: Constraint Automata for Discriminator in Reo

(S1 × S2 , (s0,1 , s0,2 ), N1 ∪ N2 , −→)

The first rule is applied when there are two transitions in the automata which can be fired together. This happens only if there is no shared name in the two automata that is present on one of the transitions but not present on the other one. In this case the transition in the resulting automaton has the union of the name sets on both transitions, and the data constraint is the conjunction of the data constraints of the two transitions. The second rule is applied when a transition in one automaton can be fired independently of the other automaton, which happens when the names on the transition are not included in the other automaton. The third rule is symmetric to the second one. After a join operation, hiding can be done on the resulting automaton. Hiding abstracts the details of internal communication among channels in a Reo circuit, and shows the observable behaviour of a Reo circuit. As an example, the constraint automaton for the discriminator in Figure 1 is given in Figure 2, which is constructed by applying the product and hiding operations to the constraint automata corresponding to the basic channels in Figure 1. Model checking and analysis methods available for finite state automata and labeled transition systems can be adapted to the constraint automata [4, 14].

operational basis for both activities based on constraint automata. Later we use this basis to formalize choreography and orchestration and develop a semantic framework that defines and supports composition of web services. Constraint automata allow us to capture an interesting set of web services, with rather complex interactions with their clients. To describe a web service, the essential attributes include its signature, states, and its non-functional properties. The signature is represented by the service’s ports and data constraints. It provides information about the data transformation during the execution of a web service. The states of a service are specified by the corresponding states in its constraint automata. Non-functional properties are those attributes that are used for evaluating a service, such as service cost, response time, throughput, security, availability, etc. In this paper we do not consider the non-functional properties in the constraint automata model, but note that constraint automata can be easily extended with non-functional properties as additional labels on the state transitions in a conceptual generalization, where data constraints together with these properties influence applicable state transitions. From the external point of view, i.e., that of a client, a web service can be taken as a black box that exhibits a certain exported behaviour represented as sequences of actions with constraints on their invocation order. From the internal point of view, i.e., that of an application deploying the service and running it, it is also relevant to consider how the actions that are part of the behaviour of the service are effectively executed. Especially, it is useful to specify whether each action is executed by the web service itself or its execution is delegated to another web service with which the former interacts. For example, in the searching-and-downloading example we give later, the search action in the service is delegated to services wa and wt , which respectively represent search by author and search by title. In the following, we capture these two points of view separately with constraint automata.

3.

3.1

where −→ is given by the following rules: N ,g

N ,g

1 1 2 2 0 0 • If s1 −→ 1 s1 , s2 −→ 2 s2 , N1 ∩ N2 = N2 ∩ N1 and

N1 ∪N2 ,g1 ∧g2

g1 ∧ g2 is satisfiable, then hs1 , s2 i −−−−−−−−→ hs01 , s02 i. N,g

N,g

N,g

N,g

• If s1 −→1 s01 , where N ∩ N2 = ∅ then hs1 , s2 i −→ hs01 , s2 i. • If s2 −→2 s02 , where N ∩ N1 = ∅ then hs1 , s2 i −→ hs1 , s02 i.

WEB SERVICES AS CONSTRAINT AUTOMATA

External View of Web Services

The external view of a web service specifies the exported behaviour of that web service. We consider here web services whose external behaviour can be captured by a finite number of states. Intuitively, this means that we can factorize the sequences of actions executed at a certain point into a finite number of states, which are sufficient to decide the future behaviour of the service. Formally,

Description and composition of web services are central design activities. In this section we develop a formal model to serve as an 1

Here DC(N ) denotes the set of data constraints that at most refer to the observed data iterms dA at node A ∈ N .

348

{AUTHOR,SEARCH} d_AUTHOR=name, d_SEARCH=yes

respectively. Generally, the internal view and the external view of a web service may have different structures in their constraint automata, as this example shows.

{DOWNLOAD} d_DOWNLOAD=yes

{(w_a,AUTHOR),(w_a,SEARCH)} d_AUTHOR=name, d_SEARCH=yes

{TITLE,SEARCH} d_TITLE=title, d_SEARCH=yes

{(w_a,DOWNLOAD)}

Figure 3: External View of an Article Search and Download Service

d_DOWNLOAD=yes {(w_t,TITLE),(w_t,SEARCH)} d_TITLE=title, d_SEARCH=yes

the external view of a web service w is the constraint automaton AEw = (SE , s0,E , N , −→E ) where

{(w_t,DOWNLOAD)} d_DOWNLOAD=yes

• SE is the set of states of the constraint automaton representing the configurations of the service w.

Figure 4: Internal View of an Article Search and Download Service

• s0,E is the initial state of the constraint automaton representing the initial configuration of the service w.

Most service composition systems distinguish between the external and internal service specification languages and the translation between the external languages. For instance, the standard web service languages like WSDL serve for external specification, more formal and precise languages for internal service specification are yet to be developed. In our approach we use constraint automata for both external and internal views of web services, which makes it easier to check the conformance between the internal view and external view of a web service w, i.e., if w is well-formed. In this paper we do not go into the details of this problem, and instead concentrate on the composition mechanisms as discussed in the following sections.

• N is a finite set of nodes. S • −→E ⊆ N ⊆N SE ×{N }×DC(N )×SE is the transition relation of the constraint automaton. Figure 3 shows a constraint automaton for the external view of a web service that allows searching and downloading of articles from the Internet. In particular, the client may choose to search for an article by specifying either its author(s) or its title, as specified by the port names in the constraint automaton. Then the client selects and downloads the article, which is specified by the data constraint on the port name DOWNLOAD. Finally, the client can choose whether to execute the service again.

3.2

4.

Internal View of Web Services

ORCHESTRATION OF WEB SERVICES

The term orchestration refers to an executable business process that can interact with both internal and external web services. The interactions occur at the message level, and represent control from one party’s perspective. An orchestration engine, which is called an orchestrator in the following, is used to handle the overall process flow, calling the appropriate web services and determining what steps to complete.

Many atomic services may be available for the same action. Besides its external behavior, the internal view of a composite web service specifies which other web service executes each of its actions. An internal view of a web service is analogous to its external view, given by a constraint automaton, except that every element in the set of names N is a pair (W, n) where W is an identifier which designates the set of web services executing the corresponding action within the constraint automaton, and n stands for the name of input/output ports of all the services in W that are used in the action. We can label the transitions in a constraint automaton for the internal view of a web service by the pair (N, g) where each element in N is a pair (W, n) as given previously, and g is a data constraint. Every possible W in the set N identifies a set of web services that contribute to the execution of the action. If W is the empty set ∅, it means that the action is executed by the running web service itself. The internal view of a web service w can be represented as a constraint automaton AIw = (SI , s0,I , NI , −→I ) where

{Balance.ACC,Balance.BAL} d_Balance.ACC=accountnumber /\ d_Balance.BAL=balance(accountnumber) {Transfer.ACC,Transfer.DEST,Transfer.AMOUNT} d_Transfer.ACC=accountnumber /\ d_Transfer.DEST=dest /\ d_Transfer.AMOUNT=sum

{CheckAcc.ACN} d_CheckAcc.ACN=accountnumber {Stock.NAME,Stock.ORDERDETAIL} d_Stock.NAME=stockname /\ d_Stock.ORDERDETAIL=detail BankAccount {USER,PWD} d_USER=USERID /\ d_PWD=password(USERID)

{LOGOUT} d_LOGOUT=yes

• SI , s0,I , −→I have the same meaning as SE , s0,E , −→E in the external view.

{USER,PWD} d_USER=USERID /\ d_PWD

password(USERID)

Login

• every element of NI is a pair (W, n) where n is a node in N in the external view, W is a set of services that have ports with same name n.

{ACN} d_ACN=accountnumber CheckAcc

As an example, we consider the constraint automaton given in Figure 4, which shows the internal view of the web service for searching and downloading articles from the Internet that conforms to the external view as given in Figure 3. We assume that we have two primitive web services for searching-by-author-and-downloading and searching-by-title-and-downloading, denoted by wa and wt

Figure 5: Atomic Services for an Online Banking Service We capture the foundations of the orchestration in the form of a constraint automata model focusing on service composition. An orchestrator can be seen as a constraint automaton that can exchange

349

information with other constraint automata via data constraints on their shared ports. In the orchestration, the orchestrator itself and the web services that are used to implement the process are separated. The process is executed as the orchestrator which invokes the respective services. An orchestrated system S consists of a parallel composition of orchestrators. An orchestrator is a constraint automaton and different orchestrators can be composed by using the product operation. For each orchestrator, there may be a family of basic services that are composed together with the orchestrator to obtain the required web service. We assume that the internal view of an orchestrator o is modelled by a constraint automaton AIo = (SIo , so0,I , NIo , →o,I ), and in its execution, the orchestrator may invoke a service w whose external w w view is the constraint automaton AEw = (SE , sw 0,E , NE , →w,E ). Then the orchestrated process is given as the orchestrated product of the two constraint automata AIo ./o AEw with the components

Balance, Transfer, CheckAcc and Stock services, where the external view of the orchestrated service is given in Figure 6. Finally, an orchestrator for an online banking account is given in Figure 7, which exhibits the internal behaviour of the online banking service. {BankAccount.ACC,BankAccount.BAL} d_BankAccount.ACC=accountnumber /\ d_BankAccount.BAL=balance(accountnumber) {Login.USER,Login.PWD} d_Login.USER=USERID /\ d_Login.PWD=password(USERID)

{Login.USER,Login.PWD} d_Login.USER=USERID /\ d_Login.PWD password(USERID)

Figure 7: The Online Banking Service Orchestrator

5.

N ,g

w.N2 ∩ NIo

and the data sw −→ = constraint g1 ∧ (g2 [w.n/n | n ∈ N2 ]) is satisfiable, then hso , sw i

N1 ∪w.N2 ,g1 ∧(g2 [w.n/n|n∈N2 ])

−−−−−−−−−−−−−−−−→

hs0o , s0w i.

N,g

• If so −→o,I s0o , where N ∩ w.NEw = ∅ then N,g

hso , sw i −→ hs0o , sw i. N,g

• If sw −→w,E s0w , where w.N ∩ NIo = ∅ then hso , sw i

w.N,g[w.n/n|n∈N ]

−−−−−−−−→

CHOREOGRAPHY IN REO AND CONSTRAINT AUTOMATA

A choreography contains a “global” contract of the common ordering conditions and constraints under which messages are exchanged and describes, from a global viewpoint, the common and complementary observable behaviour of all the participants involved. Each participant can then use the global definition to build and test solutions that conform to it. The global choreography contract is in turn realized by a combination of the resulting local systems, on the basis of appropriate infrastructure support. The advantage of a contract based on a global viewpoint as opposed to any one endpoint is that it separates the overall “global” process being followed by an individual business or system within a “domain of control” (an endpoint) from the definition of the sequences in which each business or system exchanges information with others. This means that, as long as the “observable” sequences do not change, the rules and logic followed within a domain of control (endpoint) can change at will and interoperability is still guaranteed. In real-world scenarios, corporate entities are often unwilling to delegate control of their business processes to their integration partners. Choreography offers a means by which the rules of participation within a collaboration can be clearly defined and agreed to, jointly. Each entity may then implement its portion of the choreography as determined by the common or global view. The intent of choreography is to make it easy to determine the conformance of each implementation to the common view that it expresses. As specified in the Web Service Choreography Description Language (WS-CDL) [26], a choreography model consists of the following entities:

1 1 0 w , if we have so −→ • For given so ∈ SIo and sw ∈ SE o,I so ,

N1 ∩ w.NEw

{BankAccount.NAME,BankAccount.ORDERDETAIL} d_BankAccount.NAME=stockname /\ d_BankAccount.ORDERDETAIL=detail OnlineBanking

while the transition rules for product of constraint automata are changed to the following:

0 w,E sw ,

{BankAccount.ACN} d_BankAccount.ACN=accountnumber

{Login.LOGOUT} d_Login.LOGOUT=yes

w o w (SIo × SE , (so0,I , sw 0,E ), NI ∪ NE , −→)

N2 ,g2

{BankAccount.ACC,BankAccount.DEST,BankAccount.AMOUNT} d_BankAccount.ACC=accountnumber /\ d_BankAccount.DEST=dest /\ d_BankAccount.AMOUNT=sum

hso , s0w i.

{ACC,BAL} d_ACC=accountnumber /\ d_BAL=balance(accountnumber) {ACC,DEST,AMOUNT} d_ACC=accountnumber /\ d_DEST=dest /\ d_AMOUNT=sum

{ACN} d_ACN=accountnumber {NAME,ORDERDETAIL} d_NAME=stockname /\ d_ORDERDETAIL=detail

Figure 6: External View of an Orchestrated BankAccount Service

• roleType, relationshipType and participantType: Within a choreography, information is always exchanged between participants within or across trust boundaries. All interactions occur between roles manifested by participants, and are constrained by a relationship. A participantType groups together those parts of the observable behaviour that must be implemented by the same logical entity or abstract organization. A roleType enumerates potential observable behaviour a participantType can exhibit in order to interact. A relationshipType identifies the mutual commitments that must be made for collaborations to be successful.

We use an online banking example to illustrate our service orchestration framework. In this example, the bank offers an “Online Banking Service” that allows customers to repeatedly check their balances, make orders for stocks or transfer money online. In Figure 5 three services BankAccount, Login and CheckAcc are described via constraint automata. The constraint automata for Login and CheckAcc describe the corresponding atomic services that are used in the online banking service internally. Note that the BankAccount service also invokes other atomic services Balance, Transfer and Stock, which are not given here due to the space limits. The interactions between provider and user of a service are addressed in service orchestration. In fact, the BankAccount service given in Figure 5 should be taken as an orchestrator of the

• informationType, variable and token: A variable contains information about commonly observable objects in a collaboration, such as the information exchanged or the observable information of the roleTypes involved. A token is an alias

350

WS-CDL Role Relation Type Participant Type Variable ChannelType Workunit Activity Choreography

Reo and Constraint Automata Port Reo circuit Components connected to Reo circuits (Constraint Automata) Variable Channel Data constraint Channel operation Behavior in Reo circuits (Constraint Automata)

• parallel • choice and can be easily represented in Reo and constraint automata: • The sequential composition of activities can be represented by connecting the corresponding sink and source channel ends in Reo and sequence of transitions in constraint automata. • The parallel composition of activities can be represented by a source node where the communications in the connected channels are executed in parallel, and by the product of the corresponding constraint automata.

Figure 8: Correspondence Between WS-CDL and Reo with Constraint Automata

• The choice of activities can be represented by a sink node in Reo and a state connected to the two alternatives in constraint automata.

that can be used to reference parts of a variable. Both variables and tokens have informationTypes that define the type of information the variable contains or the token references.

c: Client

• choreography: A choreography defines collaborations among interacting participantTypes. The choreography life-line expresses the progression of a collaboration. Initially, the collaboration is established between participants, then work is performed within it and finally it completes either normally or abnormally. An exception block specifies what additional actions should occur when a choreography behaves in an abnormal way and a finalizer block specifies additional actions that should occur to modify the effect of an earlier successfully completed choreography.

w_a: Search by Author Service

s: Search and Download Service

w_t: Search by Title Service

f: File Server

search key alt

search

key in Author

search_results search_results

key in Title

search search_results search_results

• channelType: A channel realizes a point of collaboration between participantTypes by specifying where and how information is exchanged. Within WS-CDL, channels are abstractly modeled as channelTypes.

download file from f

download file file

Figure 9: Sequence Diagram for the Search and Download Service

• workunit: A workunit prescribes the constraints that must be fulfilled for making progress, and thus performing work, within a choreography.

As an example we consider the article search and download service further and derive its choreography in Reo and constraint automata. The example consists of a scenario where a client invokes a search and download service in order to search an article from the Internet. Depending on the search request type (search by title or by author), the search and download service invokes the respective atomic service. After the search is performed, the search and download service can list all the available links for download for the client. At the end, the client chooses one link and downloads the file. The choreography consists of a declaration of roles and variables, and a description of the conversation between the roles, where a conversation is a message or a composition of conversations via an ordering structures. Therefore, the choreography in this example is defined by introducing five roles: the client c, the search-anddownload service s, the search-by-author service wa , the searchby-title service wt and the file server f . Instead of giving the detailed WS-CDL description, here communication among the roles is illustrated by the sequence diagram in Figure 9. The complete choreography for this service is specified by a sequential composition of the basic interactions with a choice controlled by the client represented by the oracle key in Author or key in Title. In our approach, the choreography can be represented by constraint automata for each role involved together with the Reo circuits connecting them. For example, the Reo circuit in Figure 10

• activities and ordering structures: Activities describe the actions performed within a choreography. Ordering structures combine activities with other ordering structures in a nested structure to express the ordering rules of actions performed within a choreography. • interaction activity: An interaction is the basic building block of a choreography. It results in an exchange of information between participants and possible synchronization of their observable information exchanges. To model the choreography of web services in Reo, we can consider each web service as a black-box component, and model the coordination and communication among the services via Reo circuits. The ports of a Reo circuit represent corresponding services. Services and their ports can be receivers and senders of data, i.e., services can read from or write to the ports. A service can be connected to several ports. The choreography model is about interaction of web services, i.e., synchronisation and message exchanges among services via the Reo circuits. We summarize the WS-CDL components and their correspondence with Reo and Constraint Automata in Figure 8. An ordering structure is one of the following: • sequence

351

A

D

tween a single orchestrator with respect to a given choreography. [19] presents a logical view of choreography, and [9] presents an automatic translation from choreography description to timed automata, but they contain no discussion on orchestration. [6] uses IO-automata and defines a conformance notion which allows to test whether interoperability of a protocol is guaranteed by limiting the notion to systems containing only two peers. [7] proposes two formal calculi for representing choreography and orchestration respectively, which are redefined in [8] by introducing state variables to increase their expressiveness, and defines a notion of conformance based on a bisimulation between the LTSs as the semantics of these calculi. In comparison to all these existing works, the strength of our approach is that it allows to investigate the issues of description, orchestration and choreography at a unifying abstract description level, based on constraint automata. Constraint automata have been used as the semantics of the coordination language Reo in [4], and thus offer a natural correspondence relationship between orchestration and choreography.

X

G

B

Y

E

H

C

Z

F

Figure 10: Reo Circuit Connecting the Client and the Search and Download Service represents the protocol connecting the client and the search-anddownload service. The client writes the message search key to port A which is taken by the service s at port D, then the service s is executed, which may invoke the atomic service wa or wt and then returns the search result through port E to the client, which will be received at port B. Afterwards, the client sends the message download file from f through port C to service s, which will be received at port F by the service. During this execution, other roles may be invoked, whose executions are represented by their corresponding constraint automata, connected together by their respective Reo circuits.

6.

7.

CONCLUSION

Web services are becoming a powerful tool for the implementation of distributed applications over the Internet. Combining web services to create higher level, cross-organizational business processes requires standards to model the interactions among different web services. Orchestration and choreography are widely used for composing service-based applications. In this paper we advocate the use of constraint automata as an abstract representation means to describe and compose web services. Two different views of web services are presented via constraint automata. Note that although constraint automata are also based on transition systems, they are unlike the approach in [13] which uses the Mealy machine model for services and transitions are labeled with action names. The transitions in constraint automata are data-dependent and thus lead to a symbolic representation by means of data constraints. Furthermore, we illustrate our approach with examples of abstract description for orchestration issues, and a framework for linking from choreography to Reo and constraint automata. Since we use constraint automata as the underlying framework for both orchestration and choreography, we can naturally derive the formal correspondence relationship between them. Our future work will focus on the problem of service composition with QoS constraints [17]. The web service components can be composed dynamically at run time as system conditions change or applications’ needs evolve. Dynamic composition requires the web services consumers to discover service providers that satisfy not only their functional requirements, but also nonfunctional requirements like cost and various QoS requirements such as performance and availability of services. In particular, this relates the work in [5] which proposes a stochastic variant of constraint automata called continuous-time constraint automata (CCA), allowing the possibility to make a performance analysis of channel-based coordination mechanisms. Another perspective is to work on the formalization of conformance between the choreography and orchestration of web services by providing a refinement relation between their corresponding constraint automata models. The equivalence of typical composition patterns is also a interesting problem. Some ideas on simulation and bisimulation between constraint automata have been sketched in [4] and should be investigated more carefully due to the difference between internal and external views of web services.

RELATED WORK

Composition of web services has received much attention for supporting enterprise application integration over the network. Many industry standards have been proposed for composing services, such as the so-called orchestration and choreography languages [1, 15, 26, 27]. A thorough discussion of the differences between choreography and orchestration can be found in [21]. Currently, these proposals still remain at a descriptive level without providing any kind of reasoning mechanism or tool support for checking properties of web services based on the proposed notations. At an abstract level, works originally tended to describe web services and their composition using semi-formal notations, especially workflow [12], which models business processes as sequences of automated activities, in terms of data and control flows among them. Due to the lack of formal meaning of the notations, this approach is error-prone and mostly not supported by tools other than editors. More recently, some formal proposals have been made for representing web services, using LTS, process algebra, Petri nets, etc. [13, 22, 29]. Choreography and orchestration are widely used for composing service-based applications. These approaches have been separately developed by industrial consortia and international organizations like IBM, W3C [1, 26, 27, 15], and there are several works that consider choreography and orchestration languages in serviceoriented systems. [20] proposes an ontology framework for web service composition which is based on an operational model, and uses a process model for orchestration and an interaction model for choreography. However, this ontology is neither formal enough nor complete, and presents no formal relation between the two model. [10] exploits Petri nets for describing orchestration, choreography and service interface behaviour focusing on the relationship be-

352

Acknowledgements.. The work reported in this paper is sup-

2001. [13] R. Hull, M. Benedikt, V. Christophides, and J. Su. E-services: a look behind the curtain. In Proceedings of the 22nd ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems (PODS’03), pages 1–14. ACM Press, 2003. [14] S. Kl¨uppelholz and C. Baier. Symbolic Model Checking for Channel-based Component Connectors. In C. Canal and M. Viroli, editors, Proceedings of 5th Int. Workshop on the Foundations of Coordination Languages and Software Architectures (FOCLASA’06), pages 19–36. [15] F. Leymann. Web Services Flow Language (WSFL 1.0). http://www4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf. [16] M. P. Papazoglou and D. Georgakopoulos. Service Oriented Computing. Comm. ACM, 46(10):25–28, 2003. [17] D. A. Menasc´e. Composing Web Services: A QoS View. IEEE Internet Computing, 8(6):88–90, 2004. [18] N. Milanovic and M. Malek. Current Solutions for Web Service Composition. IEEE Internet Computing, 8:51–59, 2004. [19] C. Montangero and L. Semini. A Logical View of Choreography. In P. Ciancarini and H. Wiklicky, editor, COORDINATION 2006, volume 4038 of LNCS, pages 179–193. Springer-Verlag, 2006. [20] C. Pahl and Y. Zhu. A Semantical Framework for the Orchestration and Choreography of Web Services. In A. Arenas, J. Dong, A. Martin, and B. Matthews, editors, Proceedings of the International Workshop on Web Languages and Formal Methods (WLFM 2005), volume 151 of Electronic Notes in Theoretical Computer Science. Elsevier Science Publishers, 2006. [21] C. Peltz. Web Services Orchestration and Choreography. IEEE Computer, 36(10):46–52, 2003. [22] G. Sala¨un, L. Bordeaux, and M. Schaerf. Describing and Reasoning on Web Services using Process Algebra. In H. Jain and L. Liu, editors, Proceedings of the IEEE International Conference on Web Services (ICWS’04), pages 43–50. IEEE Computer Society, 2004. [23] C. Szyperski. Component Software – Beyond Object-Oriented Programming. Addison-Wesley, 1998. [24] Universal Description, Discovery, and Integration (UDDI) v3.0. http://www.uddi.org/. [25] W3C. Simple object access protocol (soap) v1.2. http://www.w3.org/2000/xp/Group/. [26] W3C. Web Service Choreography Description Language (WS-CDL) 1.0. http://www.w3.org/TR/ws-cdl-10/. [27] W3C. Web Service Choreography Interface (WSCI) 1.0. http://www.w3.org/TR/wsci/. [28] W3C. Web Service Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl. [29] J. Zhang, J.-Y. Chung, C. K. Chang, and S. W. Kim. WS-Net: A Petri-net Based Specification Model for Web Services. In H. Jain and L. Liu, editors, Proceedings of the IEEE International Conference on Web Services (ICWS’04), pages 420–427. IEEE Computer Society, 2004.

ported by a grant from the GLANCE funding program of the Dutch National Organization for Scientific Research (NWO), through project CooPer (600.643.000.05N12). Part of the first author’s work was done when he visited Prof. Naixiao Zhang in Peking University and is further supported by NNSFC project No. 60473056. We would like to thank the reviewers for their valuable comments.

8.

REFERENCES

[1] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana. Business process execution language for web services version 1.1, 2003. http://www106.ibm.com/developerworks/webservices/library/ws-bpel/. [2] F. Arbab. Reo: A Channel-based Coordination Model for Component Composition. Mathematical Structures in Computer Science, 14(3):329–366, 2004. [3] F. Arbab and J. Rutten. A coinductive calculus of component connectors. In M. Wirsing, D. Pattinson, and R. Hennicker, editors, Recent Trends in Algebraic Development Techniques: 16th International Workshop, WADT 2002, Frauenchiemsee, Germany, September 24-27, 2002, Revised Selected Papers, volume 2755 of LNCS, pages 34–55. Springer-Verlag, 2003. [4] C. Baier, M. Sirjani, F. Arbab, and J. Rutten. Modeling component connectors in Reo by constraint automata. Science of Computer Programming, 61:75–113, 2006. [5] C. Baier and V. Wolf. Stochastic Reasoning About Channel-Based Component Connectors. In P. Ciancarini and H. Wiklicky, editor, COORDINATION 2006, volume 4038 of LNCS, pages 1–15. Springer-Verlag, 2006. [6] M. Baldoni, C. Baroglio, A. Martelli, V. Patti, and C. Schifanella. Verifying the Conformance of Web Services to Global Interaction Protocols: A First Step. In Mario Bravetti and Le¨ıla Kloul and Gianluigi Zavattaro, editor, EPEW 2005 and WS-FM 2005, volume 3670 of LNCS, pages 257–271. Springer, 2005. [7] N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and Orchestration: A Synergic Approach for System Design. In B. Benatallah and F. Casati and P. Traverso, editor, ICSOC 2005, volume 3826 of LNCS, pages 228–240. Springer-Verlag, 2005. [8] N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Choreography and Orchestration Conformance for System Design. In P. Ciancarini and H. Wiklicky, editor, COORDINATION 2006, volume 4038 of LNCS, pages 63–81. Springer-Verlag, 2006. [9] G. Diaz, J.-J. Pardo, M.-E. Cambronero, V. Valero, and F. Cuartero. Automatic Translation of WS-CDL Choreographies to Timed Automata. In Mario Bravetti and Le¨ıla Kloul and Gianluigi Zavattaro, editor, EPEW 2005 and WS-FM 2005, volume 3670 of LNCS, pages 230–242. Springer, 2005. [10] R. Dijkman and M. Dumas. Service-oriented design: A multi-viewpoint approach. J. Cooperative Inf. Syst., 13:337–368, 2004. [11] G. Alonso and F. Casati and H. Kuno and V. Machiraju. Web Services - Concepts, Architectures and Applications. Springer-Verlag, 2004. [12] G. Shegalov and M. Gillmann and G. Weikum. XML-enabled Workflow Management for e-Services across Heterogeneous Platforms. VLDB Journal, 10(1):91–103,

353