foundational study and practical experimentation of service orchestration with sock/jolie ivan...

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

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.

SessionA 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

S1 S2

We say that Session A and B are not distinguishable if S1=S2

x=0, y=1, z=2 x=0, y=1, z=3S1 S2

S11 S21

= 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 routingSession 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=2SM

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








• Conclusion

Programming a service with Jolieexecution { 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.


main{ sendNumber@B( 5 )}



main{ sendNumber( x )}

A sends 5 to B through the sendNumber operation.

A: B:


main{

twice@B( 5 )( x )}



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…

send@S( x ) ; receive( msg )

send@S( 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{

twice@B( 5 )( x )}

A should know how to contact BB should expose the operation twice Two types of ports:

Input ports: expose operationsOutput ports: bind output operations to input operations

main{


result = x * 2}

}

A: B:

Communication ports

main{

twice@B( 5 )( x )}



inputPort MyInput {Location: “socket://localhost:8000/”Protocol: soapRequestResponse: twice(int)(int)}

main{


result = x * 2}

}

Location

Protocol

Interface

A:

Communication ports

outputPort B {Location: “socket://192.168.1.2:8000/”Protocol: soapRequestResponse: twice(int)(int)}

main{

twice@B( 5 )( x )}




main{


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 dynamicallyBehaviour specification is independent of the actual protocol (for data manipulation a generic tree-like structure is considered)

outputPort B {Location: “socket://192.168.1.2:8000/”Protocol: soapRequestResponse: twice(int)(int)}

main{

twice@B( 5 )( x )}


main{


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 dynamicallyBehaviour specification is independent of the actual protocol (for data manipulation a generic tree-like structure is considered)

person.name = “John”;person.surname = “Smith”;

<person><name>John</John><surname>Smith</surname>

</person>

SOAP

<form name=”person”><input name=”name”

value=”John”/><input name=”surname”

value=”Smith”/></form>

01person02name114Johnsurname11Smith

SODEP

HTTP








• 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 activitiesMechanisms for interrupting activities




main{

scope(carRepair){{ scope(carRental)

{...

} | scope(garage){

... }

} ; scope(towingTrack)

{ ...}

}

carRepair

carRental garage

towingTrack




main{

scope(carRepair){{ scope(carRental)

{...

} | scope(garage){

... }

} ; scope(towingTrack)

{ ...

throw(noTowTrack);

} }

carRepair

carRental garage

towingTrack

The scope hierarchyScopes have a name q, an activity P, and a set of fault handlers HAt runtime they are organized in a hierarchyWhen a fault is raised, it goes up in the hierarchy until it reaches a handlerWhile 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

qScopes have a name q, an activity P, and a set of fault handlers HAt runtime they are organized in a hierarchyWhen a fault is raised, it goes up in the hierarchy until it reaches a handlerWhile going up, parallel scopes are interrupted

The scope hierarchy

throw(f) (q2,T2)

q2

(q1,T1)

q1

(f,Q)Scopes have a name q, an activity P, and a set of fault handlers HAt runtime they are organized in a hierarchyWhen a fault is raised, it goes up in the hierarchy until it reaches a handlerWhile going up, parallel scopes are interrupted

The scope hierarchy

throw(f)

q2

(q1,T1)

q1

(f,Q)

T2

Scopes have a name q, an activity P, and a set of fault handlers HAt runtime they are organized in a hierarchyWhen a fault is raised, it goes up in the hierarchy until it reaches a handlerWhile going up, parallel scopes are interrupted

T1

(q2,T2)

The scope hierarchy

throw(f)

(f,Q)Q

Scopes have a name q, an activity P, and a set of fault handlers HAt runtime they are organized in a hierarchyWhen a fault is raised, it goes up in the hierarchy until it reaches a handlerWhile going up, parallel scopes are interrupted

T1

T2

Dynamic installation of handlersDuring 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

customer orchestrator

clerkSrvc

supervisorSrvc

ratingSrvc

1

2bis

3

Three possible outcomes:• approved• declineByClerk• declineBySupervisor

2



clerkSrvc

supervisorSrvc

ratingSrvc

1

2bis

3

Three possible outcomes:• approved• declineByClerk• declineBySupervisor

denyFault

denyFault

Assume that the Clerk and the Supervisor deny the credit throwing a fault

2


main{ login( request ); calculateRating@ratingSrvc( request )( rating ); scope( decision ) { if (rating == “AAA”) { } else { if (rating == “BBB”) { requestApproval@clerkSrvc( request )( ) } else { requestApproval@supervisorSrvc( request )( ) } } ; approved@customer( request ) } }


clerkSrvc

supervisorSrvc

ratingSrvc

1

2

2bis

3

denyFault

denyFault


main{ login( request ); calculateRating@ratingSrvc( request )( rating ); scope( decision ) { if (rating == “AAA”) { } else { if (rating == “BBB”) { inst(denyFault => declineByClerk@customer( request )); requestApproval@clerkSrvc( request )( ) } else { inst(denyFault => declineBySupervisor@customer( request )); requestApproval@supervisorSrvc( request )( ) } ; } ; approved@customer( request ) } }


clerkSrvc

supervisorSrvc

ratingSrvc

1

2bis

3

2

denyFault

denyFault

Compensation handlingWhen a scope q finishes its activity, it passes to the parent scope the compensation handlerHandlers in the parent scope can perform comp(q) to execute the compensation handler

q

(q,Q)

q successfully terminates

q’ q’

(q,Q)

Handlers in q’activates Q

performing comp(q)

Formal reasoning about fault/compensationsThe 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)








• 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 Jolieexecution { concurrent }interface embeddedInterface { OneWay: start}interface myInterface { ...}

outputPort embedPort { Interfaces: embeddedInterface}

embedded { Jolie: “embed.ol” in embedPort}

inputPort myPort { … Interfaces: myInterface}

main{ start@embedPort( ... ) …}

Interface of the embedded service

outputPort definition of the embedded service

embedding

Invocation of the embedded service

RedirectingRedirecting 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

MM/?

Redirecting with JolieoutputPort 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

AggregationAggregation is a redirecting composition of services whose interfaces are

joined together and published as unique.

A

B

C

op1@A

M

op1op2op3

op1

op2

op3

op1@M

Aggregation with JolieoutputPort 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

Interface conformance








• 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

foundational study and practical experimentation of service orchestration with sock/jolie ivan...

Documents