Distributed Orchestration v.s. Choreography: The FOCAS Approach

Size: px

Start display at page:

Download "Distributed Orchestration v.s. Choreography: The FOCAS Approach"

Carol Dorothy Walker
5 years ago
Views:

1 Distributed Orchestration v.s. Choreography: The FOCAS Approach Gabriel Pedraza, Jacky Estublier Grenoble University. France ICSP May

2 Abstract Process Engine Language (APEL) X x, y, z t t B x y, z t y Abstract Process model 2

3 Abstract models Why using abstract models : Describe the «business» process, Easy to read and understand, Hide «irrelevant» details, Independent on any implementation, Can be instantiated differently in different contexts, Can be reused. But cannot execute! (useless?) 3

4 Orchestration: a process for calling WS Workflow model Workflow engine A B B1 B2 B3 C N1 N3 N2 Requires to know at least: Activity <-> WS. Data <-> parameter And to know at least: Activity + data <-> method call, Formats, Protocols. 4

5 Model composition: Abstract process execution X B Process model x, y, z x y, z t y t t XD = { } YD = {.. } TD = Data model SC (t1, ) = SB1 ( ) = SA ( ) Service Model WSDL Executes but still an academic exercise 5

6 Orchestration: a workflow for calling WS Workflow model Workflow engine A B B1 B2 B3 C N1 N3 N2 Requires to know at least: Activity <-> WS. Data <-> parameter And to know at least: Activity + data <-> method call, Formats, Protocols. But also: distribution constraints. security properties. error recovery, performance issues,.. 6

7 Non Functional properties : Annotations Non functional properties can be expressed as annotations on the abstract model. Exemple of annotation available today : Security, Transaction, Choreography (process distribution). 7

8 Orchestration Workflow model Workflow engine A B B1 B2 B3 C N1 N3 N2 Pros : Centralized Easy to understand Simple to design, administrate, dynamic selection, error recovery Cons : Centralized Bottleneck : scalability issues. 8

9 Choreography Pros : Scalable. Availability, efficiency, Improved security, flexibility A B B1 B2 B3 C N1 N3 N2 Cons : Difficult to design and understand Difficult to implement, control, administrate,. Requires to execute a «routing» algorithm on each server. 9

10 Distributed orchestration A distribution annotation on an orchestration model. X N1 x, y, z N1 t N2 t B x y, z t N3 y N3 10

11 Distribution annotation : FOCAS/Eclipse 11

12 From Orchestration to Choreography Transform the central process : one sub-process per node N1 N3 N2 12

13 Abstract Choreography 14

14 Choreography Server (N1) Incoming messages ICS Data Management Interface Orchestration Engine Routing Table Node N1 X/B.end ->N3:X_C/C.begin X/B.begin->N2: X_B/B2.begin Event Notification Interface OCS Outgoing messages Process specific model (abstract services) and routing metadata Choreography Server (Generic code) interprets Logical Layer SAM Machine (ID = N1) Infrastructure Abstract - Concrete Binding Web Services OSGi Services Concrete Services Physical Layer 15

15 Deployment server : SAM Service Abstract Machine. Subsumes current SOA platforms (currently: OSGi, ipojo, AXIS, upnp, DPWS, SNMP). Natively distributed. SAMs are discovered dynamically. N3:X_C/C.begin (t). Routing and deployment tables can be changed dynamically Choreography topology can be changed dynamically Process model can be changed dynamically 16

16 Choreography server The workflow engine is unmodified: identical on each node. Reuse existing workflow engines The Choreography server is made of two generic components Output Choreography Server (OCS). Interprets routing tables. Input Choreography Server (ICS). Starts activities. Each Choreography node is identical (process independent). Can be installed once for all Can run any process Can run any number of process instance 17

Application Specific Level Generic Code Level Choreography N1: sub-process, Routing N2: sub-process, Routing N3: sub-process, Routing X/B.end- >X_C/C.b X/B.begin- >X_B/B2.b X_B/B3.end - >X/B.

17 Application Specific Level Generic Code Level Choreography N1: sub-process, Routing N2: sub-process, Routing N3: sub-process, Routing X/B.end- >X_C/C.b X/B.begin- >X_B/B2.b X_B/B3.end - >X/B.end X_C/C.end - >X.end ICS Orchestration Engine OCS ICS Orchestration Engine OCS ICS Orchestration Engine OCS SAM Machine (ID=N1) SAM Machine (ID=N2) SAM Machine (ID=N3) Underlying services level 18

18 Conclusion: Orchestration v.s. Choreography Orchestration. good for design: Easy to understand and communicate Business model, error recovery, dynamic selection etc. Choreography. good for execution: Efficient, Scalable, Adaptable to various contexts Fully dynamic Annotations can bring the best of both camps: Designing an orchestration (a centralized process), Executing a choreography, Without any change in the model, Without any change in process engine, editor, tools A few new meta data (model) 19

19 Conclusion2: Enhancing process technology From Orchestration to choreography A transformation that enforces the same process semantics Does not change the process model Does not change the PML environment (interpretors, editors, ) Annotation Are also abstract Distribution annotation Provides large dynamic capabilities Can be applied to any process model and engine Any process can be executed in a distributed way whatever the formalism (if abstract). A practical way to apply separation of concerns to process technology. 20

Lab 1 Introduction ipojo Component Model

Lab 1 Introduction ipojo Component Model Thomas Leveque A Page 1, January 27, 2011 Service Oriented Computation New computing paradigm Service as fundamental element Reduce dependencies among «software