Foundational Study and Practical Experimentation of Service Orchestration with SOCK/JOLIE Ivan Lanese, Fabrizio Montesi, Claudio Guidi, and Gianluigi Zavattaro Department of Computer Science, University of Bologna

SOCK/JOLIE Web Services specifications Concurrency theory models: Petri nets, pi-calculus SOCK Behaviour, session, correlation set, operations, ports, engine, service system xml-like data management, protocol interoperability, … Primitives, Mechanisms, and Patterns for Service Composition and Orchestration No service orchestration language (XLANG, WSFL, BPEL) had a formally defined semantics This was perceived as a problem for the application of formal techniques

In this presentation… The concept of “service” according to SOCK/JOLIE Programming services with JOLIE First lesson learned: need for fault/compensation primitives and mechanisms providing strong cohesion guarantees Second lesson learned: need for native primitives supporting more sophisticated mechanisms for service combination and rebinding Conclusion

In this presentation… The concept of “service” according to SOCK/JOLIE Programming services with JOLIE First lesson learned: need for fault/compensation primitives and mechanisms providing strong cohesion guarantees Second lesson learned: need for native primitives supporting more sophisticated mechanisms for service combination and rebinding Conclusion

A “Service” in SOCK/JOLIE Behaviour: it describes how a service session behaves Engine: it manages sessions Interface: it describes the service Ports: they represent the access points where the service is deployed Network

Behaviour Communication activities OneWay Request-Response Functional activities Data manipulation The behaviour of a service is the description of the service activities composed in a workflow.

Session A service session is an executing instance of a service behaviour equipped with its own local state. Local state In general a session is identified by its own local state or a part of it. The part of the local state which identifies a session can be programmed and it is called correlation set.

Session identification x=0, y=1, z=2 Session A x=0, y=1, z=2 Session B S1S2 We say that Session A and B are not distinguishable if S1=S2 x=0, y=1, z=2x=0, y=1, z=3 S1S2 S11S21 = correlation set We say that Session A and B are not distinguishable by correlation if S11=S21

Engine Session creation when a message is received on an initial input when a user manually starts it State support local state global state (shared among sessions) storage state (persistent shared state) Message routing Session execution concurrent sequential An engine is a machinery able to manage service sessions by providing session creation, state support, message routing and session execution capabilities.

Message routing Session A Session B x=0, y=1, z=2 x=0, y=1, z=3 S1 S2 = correlation set We say that the message M is delivered to the session which is not distinguishable by correlation with message M x=0, y=1, z=2 SM Message M

Interface It reports all the input operations used by the behaviour for receiving messages from other services or applications. It could contain also additional information: Work-flow: description of the expected “conversation” (input/output message ordering). Semantics: information about the specific provided functionalities A service interface contains the description of the service

Deployment A port is an endpoint equipped with a network address and a communication protocol joined to an interface whose operations will become able to receive or send requests. Ports which enables operations to receive requests are called input ports, output ports otherwise. The deployment phase is in charge of binding the service interface with network locations and protocols. input ports: they allow for the declaration of all the input endpoints able to receive messages exhibited by the service engine output ports: they bind target location and transport protocol to the receiving services of the behaviour

In this presentation… The concept of “service” according to SOCK/JOLIE Programming services with JOLIE First lesson learned: need for fault/compensation primitives and mechanisms providing strong cohesion guarantees Second lesson learned: need for native primitives supporting more sophisticated mechanisms for service combination and rebinding Conclusion

Programming a service with Jolie execution { concurrent } cset { request.id } interface myInterface { OneWay: login RequestResponse: get_data } inputPort myPort { Protocol: http Location: “socket://localhost:2000” Interfaces: myInterface } main { login( request ) ; get_data( request )( response ) { response.data = “your data” + request.id } } Service engine execution modality Correlation set definition Interface definition inputPort definition Main code

Basic communication primitives Data are exchanged by means of operations Two types of operations: One-Way: receives a message; Request-Response: receives a message and sends a response to the caller.

Basic communication primitives main { 5 ) } Data are exchanged by means of operations Two types of operations: One-Way: receives a message; Request-Response: receives a message and sends a response to the caller. main { sendNumber( x ) } A sends 5 to B through the sendNumber operation. A:B:

Basic communication primitives main { 5 )( x ) } Data are exchanged by means of operations Two types of operations: One-Way: receives a message; Request-Response: receives a message and sends a response to the caller. main { twice( x )( result ) { result = x * 2 } A sends 5 to B; B doubles the received value; B sends the result back to A. A:B:

Workflow and control flow Basic activities can be combined with sequence, parallel and choice constructs… x ) ; receive( msg ) x ) | receive( msg ) [ recv1( x ) ] { … } [ recv2( x ) ] { … } sequence: parallel: choice: … as well as the usual control flow constructs if ( x > 1 ) { … } else { … } for( i = 0, i < n, i++ ) { … } if then else: for: while: while( i < 0 ) { … }

Communication ports main { 5 )( x ) } A should know how to contact B B should expose the operation twice Two types of ports: Input ports: expose operations Output ports: bind output operations to input operations main { twice( x )( result ) { result = x * 2 } A:B:

Communication ports main { 5 )( x ) } A should know how to contact B B should expose the operation twice Two types of ports: Input ports: expose operations Output ports: bind output operations to input operations inputPort MyInput { Location: “socket://localhost:8000/” Protocol: soap RequestResponse: twice(int)(int) } main { twice( x )( result ) { result = x * 2 } Location Protocol Interface A:

Communication ports outputPort B { Location: “socket:// :8000/” Protocol: soap RequestResponse: twice(int)(int) } main { 5 )( x ) } A should know how to contact B B should expose the operation twice Two types of ports: Input ports: expose operations Output ports: bind output operations to input operations inputPort MyInput { Location: “socket://localhost:8000/” Protocol: soap RequestResponse: twice(int)(int) } main { twice( x )( result ) { result = x * 2 } Location Protocol Interface

Decoupling between behaviour and ports Different communication protocols are supported (SOAP, HTTP, SODEP,… and new one can be easily plugged-in) The protocol (and location) can be even changed dynamically Behaviour specification is independent of the actual protocol (for data manipulation a generic tree-like structure is considered) outputPort B { Location: “socket:// :8000/” Protocol: soap RequestResponse: twice(int)(int) } main { 5 )( x ) } inputPort MyInput { Location: “socket://localhost:8000/” Protocol: soap RequestResponse: twice(int)(int) } main { twice( x )( result ) { result = x * 2 } Location Protocol Interface

Decoupling between behaviour and ports Different communication protocols are supported (SOAP, HTTP, SODEP,… and new one can be easily plugged-in) The protocol (and location) can be even changed dynamically Behaviour specification is independent of the actual protocol (for data manipulation a generic tree-like structure is considered) person.name = “John”; person.surname = “Smith”; John Smith SOAP <input name=”name” value=”John”/> <input name=”surname” value=”Smith”/> 01person02name114Johnsurname11Smith SODEP HTTP

In this presentation… The concept of “service” according to SOCK/JOLIE Programming services with JOLIE First lesson learned: need for fault/compensation primitives and mechanisms providing strong cohesion guarantees Second lesson learned: need for native primitives supporting more sophisticated mechanisms for service combination and rebinding Conclusion

Fault/Termination/Compensation handling Experimenting the development of non-trivial orchestrators in JOLIE (eg. in the car-repair scenario) we felt the need for: Hierarchical structuring the activities Mechanisms for interrupting activities

Fault/Termination/Compensation handling Experimenting the development of non-trivial orchestrators in JOLIE (eg. in the car-repair scenario) we felt the need for: Hierarchical structuring the activities Mechanisms for interrupting activities main { scope(carRepair){ { scope(carRental){... } | scope(garage){... } } ; scope(towingTrack){... } carRepair carRentalgarage towingTrack

Fault/Termination/Compensation handling Experimenting the development of non-trivial orchestrators in JOLIE (eg. in the car-repair scenario) we felt the need for: Hierarchical structuring the activities Mechanisms for interrupting activities main { scope(carRepair){ { scope(carRental){... } | scope(garage){... } } ; scope(towingTrack){... throw(noTowTrack); } carRepair carRentalgarage towingTrack

The scope hierarchy Scopes have a name q, an activity P, and a set of fault handlers H At runtime they are organized in a hierarchy When a fault is raised, it goes up in the hierarchy until it reaches a handler While going up, parallel scopes are interrupted P H q

The scope hierarchy P H q P H q P H q P H q P H q Scopes have a name q, an activity P, and a set of fault handlers H At runtime they are organized in a hierarchy When a fault is raised, it goes up in the hierarchy until it reaches a handler While going up, parallel scopes are interrupted

The scope hierarchy throw(f) (q 2,T 2 ) q2q2 (q 1,T 1 ) q1q1 (f,Q) Scopes have a name q, an activity P, and a set of fault handlers H At runtime they are organized in a hierarchy When a fault is raised, it goes up in the hierarchy until it reaches a handler While going up, parallel scopes are interrupted

The scope hierarchy throw(f) (q 2,T 2 ) q2q2 (q 1,T 1 ) q1q1 (f,Q) Scopes have a name q, an activity P, and a set of fault handlers H At runtime they are organized in a hierarchy When a fault is raised, it goes up in the hierarchy until it reaches a handler While going up, parallel scopes are interrupted

The scope hierarchy throw(f) q2q2 (q 1,T 1 ) q1q1 (f,Q) T2T2 Scopes have a name q, an activity P, and a set of fault handlers H At runtime they are organized in a hierarchy When a fault is raised, it goes up in the hierarchy until it reaches a handler While going up, parallel scopes are interrupted T1T1 (q 2,T 2 )

The scope hierarchy throw(f) (f,Q) Q Scopes have a name q, an activity P, and a set of fault handlers H At runtime they are organized in a hierarchy When a fault is raised, it goes up in the hierarchy until it reaches a handler While going up, parallel scopes are interrupted (q 1,T 1 ) q1q1 T1T1 q2q2 T2T2

Dynamic installation of handlers During practical experimentation of fault handling, we noticed that in many cases a lot of activities during forward execution influenced the backward recovery activity Handlers had to carefully check which activities already took place before the fault was raised (boring, error-prone, not modular,…) For this reason we included primitives for dynamic handler installation and update q inst(f,Q) q (f,Q)

Credit request scenario customerorchestrator clerkSrvc supervisorSrvc ratingSrvc 1 2bis 3 Three possible outcomes: approved declineByClerk declineBySupervisor 2

Credit request scenario customerorchestrator clerkSrvc supervisorSrvc ratingSrvc 1 2bis 3 Three possible outcomes: approved declineByClerk declineBySupervisor denyFault Assume that the Clerk and the Supervisor deny the credit throwing a fault 2

Credit request scenario main { login( request ); request )( rating ); scope( decision ) { if (rating == “AAA”) { } else { if (rating == “BBB”) { request )( ) } else { request )( ) } } ; request ) } customerorchestrator clerkSrvc supervisorSrvc ratingSrvc 1 2 2bis 3 denyFault

Credit request scenario main { login( request ); request )( rating ); scope( decision ) { if (rating == “AAA”) { } else { if (rating == “BBB”) { inst(denyFault => request )); request )( ) } else { inst(denyFault => request )); request )( ) } ; } ; request ) } customerorchestrator clerkSrvc supervisorSrvc ratingSrvc 1 2bis 3 2 denyFault

Compensation handling When a scope q finishes its activity, it passes to the parent scope the compensation handler Handlers in the parent scope can perform comp(q) to execute the compensation handler q (q,Q) q successfully terminates q’ (q,Q) Handlers in q’ activates Q performing comp(q)

Formal reasoning about fault/compensations The SOCK formal semantics allowed us to prove several high- level properties for fault/compensation handling in JOLIE For instance (differently from BPEL) when a fault handler is activated it: has precise knowledge of either the success or failure of all the initiated internal or remote activities, in such a way that exactly the successful ones can be compensated We have also proved the correctness of an implementation in JOLIE of the SAGAS model for long-running transactions (under the policy with interruption of parallel activities and centralized compensation) Our experience suggested us also a new “dynamic semantics” for SAGAS (in which also parallel activities are undone in reverse order of completion)

In this presentation… The concept of “service” according to SOCK/JOLIE Programming services with JOLIE First lesson learned: need for fault/compensation primitives and mechanisms providing strong cohesion guarantees Second lesson learned: need for native primitives supporting more sophisticated mechanisms for service combination and rebinding Conclusion

Embedding In some cases it is useful to deploy different services in the same engine (eg. local interaction/communication facilities can be used, or a service can perform stop/restart actions on another local service) Local connection

Embedding with Jolie execution { concurrent } interface embeddedInterface { OneWay: start } interface myInterface {... } outputPort embedPort { Interfaces: embeddedInterface } embedded { Jolie: “embed.ol” in embedPort } inputPort myPort { … Interfaces: myInterface } main { ) … } Interface of the embedded service outputPort definition of the embedded service embedding Invocation of the embedded service

Redirecting Redirecting allows for the creation of a master service acting as a single communication endpoint to multiple services which are called resources. A B C /A /B /C M M/?

Redirecting with Jolie outputPort SubService { Location: "socket://localhost:8001/“ Protocol: soap } outputPort SumService { Location: "socket://localhost:8002/" Protocol: soap } inputPort MyService { Location: "socket://localhost:8000/" Protocol: sodep Redirects: Sub => SubService, Sum => SumService } main { … } Service to which redirect the incoming messages redirecting

Aggregation Aggregation is a redirecting composition of services whose interfaces are joined together and published as unique. A B C M op1 op2 op3 op1 op2 op3

Aggregation with Jolie outputPort SubService { Location: "socket://localhost:8001/“ Protocol: soap } outputPort SumService { Location: "socket://localhost:8002/" Protocol: soap } inputPort MyService { Location: "socket://localhost:8000/" Protocol: sodep Aggregates: SubService, SumService } main { … } Services to aggregate aggregation

Also mobility patterns are suppported Interface conformance

In this presentation… The concept of “service” according to SOCK/JOLIE Programming services with JOLIE First lesson learned: need for fault/compensation primitives and mechanisms providing strong cohesion guarantees Second lesson learned: need for native primitives supporting more sophisticated mechanisms for service combination and rebinding Future work

Conclusion We have presented the results of our experience in programming service orchestrations both from a theoretical and a practical point of view We have investigated the problem of consistent service composition in the presence of faults: Dynamic fault/compensation handling Correct implementation of SAGAS compensation policy We have defined new primitives and mechanisms for supporting good practices in (dynamic) service composition Future/current work: Definition of a choreographic language for the global description of SOCK/JOLIE architectures