Decentralized orchestration of composite web services

Abstract

Web services make information and software available programmatically via the Internet and may be used as building blocks for applications. A composite web service is one that is built using multiple component web services and is typically specified using a language such as BPEL4WS or WSIPL. Once its specification has been developed, the composite service may be orchestrated either in a centralized or in a decentralized fashion. Decentralized orchestration offers performance improvements in terms of increased throughput and scalability and lower response time. However, decentralized orchestration also brings additional complexity to the system in terms of error recovery and fault handling. Further, incorrect design of a decentralized system can lead to potential deadlock or non-optimal usage of system resources. This paper investigates build time and runtime issues related to decentralized orchestration of composite web services. We support our design decisions with performance results obtained on a decentralized setup using BPEL4WS to describe the composite web services and BPWS4J as the underlying runtime environment to orchestrate them.

Scientific Workflows as Services in caGrid: A Taverna and gRAVI Approach

“…For example, researchers from IBM India Research Lab have conducted a series of studies on decentralized execution of BPEL processes. This work includes model partition method, fault-handling in a decentralized manner, and performance improvement [14], dataflow constrained partition [15], and optimum decentralized orchestration with limited network bandwidth [16].…”

Reference Architectural Styles for Service-Oriented Computing

“…P2P composition can be classified into three substyles, namely (1) Static, (2) Mobile, (3) Hybrid. .In the Static Composition Style (P2PC-S) style [37] [38] [39], [40], the overall process specification (e.g. BPEL4WS 2 ) is, at design-time, partitioned into smaller pieces and deployed to involved service providers and during run-time each local engine only obtains the partial copy of the whole process, and finally executes it at the local site where the invoked service resides.…”

Fault Tolerant Web Service Orchestration by Means of Diagnosis

“…3 The result is generated after the interaction between Local and Global Diagnosers and it is a String value corresponding to the global exception to be raised, depending on H. The result received by the local fault handler f after having invoked the Local Diagnoser is characterized as follows: a) If f is the appropriate handler for the current case (i.e., the global exception coincides with the local one), the result is the value held by localFaultCode, which means that f can continue its own regular execution. 4 b) If the case has to be treated by means of another fault handler of the same Web Service, the result returned by the Local Diagnoser is set to the code of a different fault event. In that case, f has to throw the new fault and terminate the execution of the current scope.…”

“…In decentralized orchestration there is the additional problem that the entire state of the original composite Web Service is distributed across different nodes. To address this issue, Chafle and colleagues propose a framework where Local Monitoring Agents check the state of the orchestrated Web Services and interact with a Status Monitor that maintains a view on the progress of the composite service [4]. Although there is a direct correspondence with our Local and Global Diagnoser services, the authors apply traditional error detection and are therefore subject to the limitations we discussed.…”