1 Ivan Lanese Computer Science Department University of Bologna Italy Error Handling in Service Oriented Computing Joint work with Claudio Guidi, Fabrizio

1

Ivan LaneseComputer Science Department

University of BolognaItaly

Error Handling in Service Oriented Computing

Joint work with Claudio Guidi, Fabrizio Montesi and Gianluigi Zavattaro

Roadmap

Service Oriented Computing

SOCK

Error handling in SOCK

– Dynamic installation of handlers

– Interplay with request-response

The automotive case study

Conclusive remarks

Roadmap


SOCK





Conclusive remarks

Service Oriented Computing (SOC)

SOC is a paradigm to program distributed applications based on the composition of services

Services are software entities able to perform a specific task

A SOC application looks over the net for a set of suitable services and orchestrate them to reach its goal

Services are independent, eterogeneous and loosely-coupled

Services are looked for at runtime

Why SOC?

The same service can be used in different applications– Great code reusability

New services may be used in already existing applications– Always the best available service is used

The service composition can be changed to meet new requirements– Great adaptability

Services from different companies can be composed and interact– Useful for business processing

SOC challenges

We have to make eterogeneous services to interact– Interoperability problems - need for standardization

– Security problems

How to describe services to allow for dynamic retrieval?– Service interface - not enough

– Service goal - described using ontologies

– Service behavior - allows to guarentee correctness of the composition (e.g., deadlock freedom)

Web services

A set of standards to realize the SOC idea XML for data representation SOAP for communication WSDL for describing service interfaces

– Based on one-way and request-response interaction patterns

UDDI for building service repositories BPEL for orchestrating services

– Graphical language to invoke and combine services

Roadmap


SOCK





Conclusive remarks

SOCK (Service Oriented Computing Kernel)

A process calculus for modelling service oriented systems

Strongly inspired by current technologies…– WSDL, BPEL

– Implemented by Jolie

…but featuring a formal LTS semantics SOCK explores service interactions

– Based on WSDL interaction patterns

Why process calculi?

Formal methods are necessary to master the complexity of SOC– Different implementations of BPEL have different behaviours

– Standards are only informally defined

– Difficult to understand the interplay between different features

Process calculi allow to unequivocally specify the behaviour of the different mechanisms…– Clarify their semantics and their interactions

– Drive the implementations

… and prove properties of the resulting system– Good behaviour guarenteed

SOCK layers

SOCK has a 3 layers architecture– Service behaviour layer: defines the basic behaviours of

service instances

– Service engine layer: deals with instantiation of services, sessions management, and state

– Service system layer: describe whole networks of interacting services

Behaviour primitives

or@z(~y;~x)

o(~x)

or (~x;~y;P )

Output Input

One-way

Request-response

o@z(~y)

and assignment x := e

Behaviour composition operators

P ;Q Â?P : Q whileÂ do P

P jQ

From sequential languages

From concurrent calculiPi2W ²i ;Pi

Booking the cheapest hotel

(price@hotel1(data;pr1) j price@hotel2(data;pr2));pr1> pr2 ?

reserve@hotel2(data;ok) :reserve@hotel1(data;ok)

Service engine layer

Each running behaviour is completed by a state

Process definitions are specified, and instantiated on demand

A definition and all its instances are tagged by a correlation set

(P1;S1)

Pd[(P1;S1)j :: : j(Pn ;Sn)]

Y = c. Pd[(P1;S1)j : : : j(Pn ;Sn)]

More on correlation sets

A correlation set is a set of variables Allow to manage concurrent sessions When there are many possible receivers for a message…

– A definition and an instance

– Many instances of the same definition

…the most correlated one receives the message– Roughly a message (2,3) is received by (2,x) over (y,x) if both x

and y are in the correlation set

If the definition receives the message a new instance is created

Service system layers

A service system is a parallel composition of located service engines

Y1@l1jj : : : jjYn@ln

A three layered LTS semantics The behaviour produces all the possible transitions

The service engine discards the transitions non compatible with state and correlation– The transition above is allowed in a state with y=5, not in a state

with y=6

The matching of synchronizing inputs and outputs is checked at the system level

An idea about the semantics

x := y;P¿([5=y]:[5=x])¡¡ ¡ ¡ ¡ ¡ ¡ ¡! P

Roadmap


SOCK





Conclusive remarks

Error handling

Safe composition of services requires todeal with faults– Scarce guarentees on components’ behaviour

because of loose coupling

– Unexpected events can happen

A fault is an abnormal situation that forbids the continuation of an activity– An activity that generates a fault is terminated

Faults should be managed so that the whole system can reach a consistent state

BPEL offers various mechanisms for error handling

Fault handling mechanisms

Based on the idea of long running transactions– ACID transactions impossible to obtain

– Compensations are used to reach a consistent state

Faults terminate the current activity and trigger recovery activities specified by suitable handlers

Fault handler: executed as answer to a fault Termination handler: executed to smoothly terminate a

parallel activity Compensation handler: executed to undo the effect of an

already completed activity

What we propose?

A formal model for faults and compensations in SOC– Built on top of SOCK– Rigorous LTS semantics

1. Expressive high-level primitives– Mimicking but improving BPEL ones– Allowing for easy management of different kinds of faults

2. Dynamic installation of handlers– The fault handling code is always up-to-date

3. Faults do not spoil request-response communications– Automatic notification in case of server fault– The client always waits the reply from the server– Possible to recover from remote errors

Extending SOCK with faults and compensations

Code boxed into scopes {P}q

– Provide a hierarchical structure

– Define the boundaries of error handling activities

Primitives for:– Throwing faults: throw(f)

– Installing handlers: inst(u,P)

– Invoking compensations: comp(q)

A few other things

The scope hierarchy

P H

q

P H

q

P H

q

P H

q

P H

q

At runtime the scopes

contain handlers H

Throwing a fault

q1

q2

(f,Q)

Throw

(f)

(q2,T2)

(q1,T1)

Throwing a fault

q1

q2

(f,Q)

(q2,T2)

(q1,T1)

f

Faults kill activities

while propagating

Throwing a fault

T1

q1

T2

q2

(f,Q)

f

Termination handlers

of parallel activities

are executed

Throwing a fault

T1

q1

T2

q2

Q

f

When found, the fault

handler is executed

More on fault propagation

Recovery activities cannot be killed by other faults– Error recovery activities are always completed

But termination overrides fault handling– Global errors more important than internal ones

After having been killed a scope smoothly terminates– Ongoing communications are terminated

– No more faults can be thrown

Compensation handlers

Allow to undo the effect of an already completed activity– The fault handler of a purchase activity could ask to annul a

previously done payment

Has to be explicitly programmed and invoked– Primitive comp(q)

– Available only inside handlers

– Only child activities can be compensated

Roadmap


SOCK





Conclusive remarks

Dynamic fault handling

In all the previously existing languages handlers are statically installed while programming– Java throw … catch …

– BPEL handlers

Not always easy to write the desired compensation

Example

{ throw(f) | while (i <100) if i%2=0 then P else Q , H}q

We want to compensate each completed execution of P and Q in the reverse order of execution

We need auxiliary variables to track the executions of P and Q– Complex and error-prone

Atomicity problem– Suppose P has been executed but the auxiliary variables have

not been updated yet– If a fault occurs then the last execution of P is not

compensated

Our solution

{ throw(f) | while (i <100) if i%2=0 then P ; inst(f,P’;cH)

else Q ; inst(f,Q’;cH) , H0}q

P’ compensates P, Q’ compensates Q The handlers are dynamically installed cH (for current handler) allows to recover the previous

handler for updating inst is a special primitive that has higher priority than

fault execution– No atomicity problem

Installing an handler

Inst

(f,Q)

As soon as inst is

enabled it is executed

Installing an handler

(f,Q)

Compensation handlers

When an activity terminates the last defined termination handler becomes its compensation handler

Same handling for faults immediatly before activity termination and immediatly after activity termination

Installing compensation handlers

q

q’

Inst

(q,Q)


q

(q,Q)

Q terminates

q’


(q,Q)

Handlers in q’

can compensate

q using comp(q)

q’

Roadmap


SOCK





Conclusive remarks

Fault handling and request-response

Request-response is a long lasting interaction Faults on one side influence the other side Two possibilities:

– Faults on server side during the interaction

– Faults on client side while waiting for the answer

Faults on server side

A client asks a payment to the bank, the bank fails In ActiveBPEL the client receives a generic “missing-

reply” exception Our approach

– The exact fault is notified to the client

– The notification acts as a fault for the client

– Suitable actions can be taken to manage the remote fault

Faults on client side

A client asks a payment to the bank, then fails before the answer

In BPEL the return message is discarded Our approach

– The return message is waited for

– The handlers can be updated according to whether or not a non-faulty message is received

– The remote activity can be compensated if necessary

Roadmap


SOCK





Conclusive remarks

Automotive case study

Case study of European project Sensoria

A car failure forces the car to stop The car service system looks for

– A garage to repair the car

– A tow truck to take the car to the garage

– A car rental to take the driver home

The suitability of the services is checked The services are booked and paid via a bank

(Part of) the automotive case study in SOCK

CARP ::= RP j (GP ;TP )

RP ::= book@R(Gcoords;hRacc;R idi );pay@B(hRpr ices;R id;Racci ;Rpayid)

GP ::= book@G(f ailure;hGacc;Gidi );pay@B(hGpr ice;Gid;Gacci ;Gpayid)

TP ::= book@T(hCARcoords;Gi ;hTacc;Tidi );pay@B(hTpr ice;Tid;Tacci ;Tpayid)

Adding tow truck faults

CARP ::= finst(f T;comp(g) j comp(r));( RP j (GP ;TP ) )

gmainRP ::= f : : :grGP ::= f : : :ggTP ::= finst(f B ;comp(tb);throw(f T)); fbook@T(hCARcoords;Gi ;hTacc;Tidi );inst(tb;revbook@T(Tid))

gtb;pay@B(hTpr ice;Tid;Tacci ;Tpayid)gt

Screenshot from JOLIE

Feedback from the case study

Easy to write the desired error handling policies All the mechanisms are used All unexpected behaviours catched

Roadmap


SOCK





Conclusive remarks

Conclusions

SOCK is a powerful framework for modelling SOC systems– Near to current technologies, but fully formalized

– Good to experiment with error recovery strategies

Our proposal for error handling– Recovers BPEL approach based on fault, termination and compensation

handlers

– Adding new features

Dynamic installation of handlers– Allows to update the termination handler as the activity progresses

Errors do not spoil the request-response protocol– Either the fault or the normal answer is sent back

– The answer can be used during error recovery

About Jolie

Jolie is a programming language for SOC based on SOCK

Extends the basic calculus with– Management of XML data

– Support for different communication standards (SOAP, …)

– …

Allows to program and orchestrate web service systems Developed by Italian company ItalianaSoftware

Future work

Apply the dynamic approach to error-handling to other calculi– Other calculi for SOC (COWS, SSCC, CASPIS)

– Basic calculi such as π-calculus [TGC08]

Study the relative expressive power of different approaches to error handling– Static vs dynamic handling installation– Hierarchical vs flat code structure

End of talk

Documents

1 Ivan Lanese Computer Science Department University of Bologna Italy Error Handling in Service Oriented Computing Joint work with Claudio Guidi, Fabrizio