Service composition

The technologies or standards related to service composition will be reviewed in this section such BPEL4WS,CSSL,BPWS4J,etc… In addition,two differentruntimestrategies (centralized and decentralized) will be introduced as well.

2.3.1 Service composition

Service composition is the construction process of composite services [8]. A composite service is a complex Web service which is composed of several simple (primitive) Web services. There are many research programmes endeavour in this field such as BPEL4WS [36],[37],[38], CSSL [9], WSIPL [41], WSCI [40], WSFL [39] and [8],[42],[43], etc. Some of these focus on the mechanisms of how to compose Web services while others are concerned with the semantic issues in composing a complex Web service.

The most frequently referenced language for Web service composition is the Business Process Execution Language for Web Services (BPEL4WS) [36],[37],[38] which has been developed jointly by IBM, BEA Systems, Microsoft, et al. BPEL4WS is a high-level distributed XML-based language which is used for assembling Web services to form a composite Web service. BPEL4WS enhances the Web services interaction model by supporting business transactions. The script language is used to describe the interactions among Web services by clarifying the control flow constructs (sequential, concurrent, conditional, etc.), the data structures and the activities (invoke, receive, compute, etc.) of a composite Web service as summarized in Table 2-4. The BPEL4WS runtime engine interprets BPEL4WS scripts to determine the execution process of a composite Web service.

Table 2-4 Summary of BPEL constructs and notation [44]

BPEL

construct Description Notation

Control Flow Constructs sequence

switch while pick flow link

sequential flow conditional flow iterative flow

non-deterministic flow concurrent flow

wait-notify type of synchronization

sequence… end-sequence switch … end-switch while… end-while pick … end-pick flow … end-flow.

source(linkId), target(linkId) Data Structures

variable variables include a set of parts analogous to fields variableName{part1,part2…}

Activities

invoke¹ synchronous (blocking) invocation on a partner P, sending data from an input variable in and receiving the response in the output variable out

invoke(P, in, out)

invoke² asynchronous (oneway, nonblocking) invocation on a partner P, sending data using an input variable in (no response variable)

send(P, in)

receive blocking receive of data from a partner P into a variable var

receive(P, var) reply send response to a partner P from a variable var reply(P, var) assign assignment. Multiple assignments can be specified

in a single assign statement, which executes atomically

var1.p1.g1 = var2.p1.g3

compute arithmetic or logical operation

The BPEL4WS flow constructs provide the ability for a developer to model the concurrent tasks within a composite Web service and to invoke them simultaneously. It also allows a service to wait for the response from other Web services. It can be treated as a workflow control language.

In other works [7],[8], the authors try to model semantic service requests for composite Web services by enhancing OWL-S with language construct extensions. These works help to achieve a uniform semantic representation of service requests before service composition.

It also enables discovery agents to unambiguously understand the service.

The authors of [9] define a Composite Service Specification Language (CSSL) which is based on XML and is a WSDL-like language for composite services. This language extends WSDL to provide the semantic feature of Web services and defines the specification of the

control flow between composite service operations. This work [9] proposed an ontology-based framework to accomplish service composition as shown in Figure 2-11.

They model the ontology using directed graphs in which thenodesrepresenttheontology’s concepts, the unfilled nodes refer to WSDL concepts, the gray nodes refer to extended features, and the edgesrepresentrelationshipsbetween the ontology’sconceptslabelled with the cardinality of the corresponding relationship.

In the research on service composition, most researchers focus on how to describe a composite Web service or model the process of service composition by assuming that all primitive services are ready-to-use or can be identified via simple UDDI queries. Therefore, service discovery and selection are not the main concerns in this field. The proposed approach of this dissertation, a consensus-based service discovery, tries to touch upon this question to assist the consumer in service discovery and selection during the process of service composition.

Figure 2-11 Ontology-based description of Web services [9]

The most interesting idea of the CSSL work [9] is that the authors define a composability model for Web services to determine whether two Web services are composable or not. This

composability model uses two set of rules, syntactic rules and semantic rules, to estimate the composition possibility for two Web services. The syntactic rules concern (1) mode composability and (2) binding composability. The semantic rules consider (1) message composability, (2) operation semantics composability, (3) qualitative composability, and (4) composition soundness.

2.3.2 Centralized and decentralized orchestration

The script languages introduced in Section 2.3.1 are used to describe the processes of Web services. During runtime, the execution of a composite Web service is governed by a runtime engine such as Business Process Execution Language for Web Services JavaTM Run Time (BPWS4J) [45]. Once a complex Web service is composed, it can be executed by a BPWS4J engine as shown in Figure 2-12 [44].

Figure 2-12 Centralized orchestration of a composite Web service [44]

In this example, a client has composed three primitive services AddressBook(1), AddressBook(2) and TrainRoute into a composite service called FindRoute. FindRoute needs two names, name1 and name2, from the client, then sends name1 to AddressBook(1) and name2 to AddressBook(2) for acquiring the addr1 for name1 and addr2 for name2 simultaneously. FindRoute extracts only the city and zipcode from the returned two

addresses as input parameters for TrainRoute. TrainRoute will return the train route from address1 to address2. This is so-called centralized orchestration or centralized execution.

Figure 2-13 Decentralized orchestration of a composite Web service [44]

During the runtime, however, BPEL4WS, WSIPL, WSCI, executed by BPWS4J can be modified for decentralized orchestration as shown in Figure 2-13. A BPWS4J engine [45] is required to be installed in each of the distributed primitive Web services. The code for FindRoute will be divided and distributed to each of the corresponding BPWS4J engine (D0, D1, D2, and D3). FindRoute also receives name1 and name2 from client, and then send name1 to D1 and name2 to D2 in parallel for acquiring the address. However, addr1 and addr2 will not be forward back to the D0. They will be directly sent to the D3 for carrying out the TrainRoute and only the result of TrainRoute will be forward to D0. This is known as decentralized orchestration. These research projects, [4],[44], try to simulate and analyze the performances of different orchestration from various points of view such as throughput and response time. They find the performance of decentralized orchestration is somewhat better then centralized orchestration but it raises some questions in relation to fault handling.

Again, researchers in this field focus on how to handle the data flow and pay their attention to fault propagation. They assume that all primitive services are easy to find and locate. Service discovery and selection are not the main concerns in this field.