Distributed Orchestration Versus Choreography: The FOCAS Approach

Abstract

International audienceWeb service orchestration is popular because the application logic is defined from a central and unique point of view, but it suffers from scalability issues. In choreography, the application is expressed as a direct communication between services without any central actor, making it scalable but also difficult to specify and implement. In this paper we present FOCAS, in which the application is described as a classic service orchestration extended by annotations expressing where activities, either atomic or composite, are to be executed. FOCAS analyzes the orchestration model and its distribution annotations and transforms the orchestration into a number of sub-orchestrations to be deployed on a set of distributed choreography servers, and then, deploys and executes the application. This approach seemingly fills the gap between "pure" orchestration (a single control server), and "pure" choreography (a server per service). The paper shows how FOCAS transforms a simple orchestration into a distributed one, fitting the distribution needs of the company, and also shows how choreography servers can be implemented using traditional orchestration engines

A systematic literature review of service choreography adaptation

“…Since service choreographies do not rely on a single party to coordinate the business processes, some authors claim that they are more scalable than orchestrations [35,53,57,58]. Nanda et al [53], for example, presents an algorithm to automatically generate a set of distributed processes given a single BPEL process as input, and provides experimental results showing improvements on the throughput when services interact without the central coordinator.…”

Partially distributed coordination with Reo and constraint automata

“…Pedraza and Estublier [56] present FOCAS. This framework consumes as input an annotated APEL [19] specification of an orchestration scenario and produces as output a number of suborchestrations and a deployment plan (for distributing suborchestrations over machines).…”

Choreography Modelling in Embedded Systems Domain - Requirements and Implementation Technologies

“…Knowledge: Examples of literature sources that were consulted during this work include four studies. Two similar service invocation mechanisms which include the supplementation of the orchestration language with attributes that hold the address of the next participant in the choreography scenario were proposed in (Pedraza and Estublier, 2009;Zhang et al, 2008). This way, instead of routing the invocation through an orchestration engine, each participant knows the location of the next service and invokes it in choreographed or peer-to-peer manner.…”

“…Abstract Process Execution Language, or APEL, represents a hybrid modelling language that merges both choreography and orchestration viewpoints (Pedraza and Estublier, 2009). APEL specifies interactions in an orchestrated manner and uses annotations to label model parts which will be deployed to various participants.…”