Decentralized Orchestration of Composite Web Services
Web services encapsulate information, software or other resources, and make them available over the network via standard interfaces and protocols. Complex web services may be created by aggregating the functionality provided by simpler ones. This is referred to as service composition and the aggregated web service becomes a composite web service.
Centralized Orchestration
Composite web services may be developed using a specification language such as BPEL4WS and executed by a workflow engine such as Websphere Business Integration Server Foundation Process Choreographer and BPWS4J. Typically, a composite web service specification is executed by a single coordinator node. It receives the client requests, makes the required data transformations and invokes the component web services as per the specification. We refer to this mode of execution as centralized orchestration.
Decentralized Orchestration
Specifying a composite service using a language like BPEL4WS has interesting ramifications. The specification can be analyzed using techniques such as program analysis, petri-nets,etc. In the Symphony project, we analyze a composite service specification for data and control dependences and partition the code can into smaller components that execute at distributed locations. We refer to this mode of execution as decentralized orchestration. In decentralized orchestration of composite web services, there are multiple engines, each executing a composite web service specification (a portion of the original composite web service specification but complete in itself) at distributed locations. The engines communicate directly with each other (rather than through a central coordinator) to transfer data and control when necessary in an asynchronous manner.
The goal of the Symphony project is to achieve performance improvements in terms of throughput, scalability and lower response times by utilizing decentralized orchestration. Decentralized execution brings performance benefits for the following reasons :
- There is no centralized coordinator which can be a potential bottleneck.
- Distributing the data reduces network traffic and improves transfer time.
- Distributing the control improves concurrency.
- Asynchronous messaging between engines brings benefits of better throughput and graceful degradation.
We also instrument the infrastructure to collect runtime performance and availability metrics, and dynamically switch between different decentralized topologies to further optimize the performance.
Last updated 30 May 2007