Th0. 1. a: SENSORIA languages and calculi for modelling services

Sensoria016004

Software Engineering for Service-OrientedOverlay Computers

Th0.1.a: SENSORIA languages and calculi for modellingservices

Lead contractor for deliverable: DSIUFAuthor(s): R. De Nicola (DSIUF) - Editor, L. Bocchi (ULEICES), R. Bruni (PISA), L. Caires(FFCUL), R. Heckel (ULEICES), I. Lanese (UNIBO), A. Lapadula (DSIUF), M. Loreti (DSIUF), L.Semini (PISA), C. Montangero (PISA), V. Vasconcelos (FFCUL) and G. Zavattaro (UNIBO)

Due date of deliverable: August 31,2007Actual submission date: October 10, 2007Revision: FinalDissemination level: PU

Contract start date: September 1, 2005 Duration: 48 monthsProject coordinator: LMUPartners: LMU, UNITN, ULEICES, UWARSAW, DTU,PISA, DSIUF, UNIBO, ISTI, FFCUL, UEDIN, ATX, TILab,FAST, BUTE, S&N, LSS-Imperial, LSS-UCL, MIP, ATXT

Integrated Project funded by theEuropean Community under the“Information Society Technologies”Programme (2002—2006)

Th0.1.a: SENSORIA languages and calculi for modelling services (Final) October 10, 2007

Executive Summary

During the first year of the project, several ideas emerged for designing service core calculi, either ex-tending well-known process calculi and technological standards or defining novel approaches. At thesame time, the extensions required for addressing Service Level Agreement, negotiation mechanismsand transactional disciplines were necessarily based on already existing process calculi, because core-calculi were not yet assessed.

This thematic deliverable and its companion Th0.2a (Sensoria Languages and Calculi for ModellingServices) report on the outcomes of the activities conducted during the second year of the project, i.e.(1) to clarify similarities and differences among the proposed calculi from a conceptual viewpoint, (2)to export primitives emerged at one conceptual layer to other layers, possibly through different levels ofabstraction, and (3) to integrate or unify different approaches whenever possible.

The deliverable is concerned with three main aspects of service specification, the first one has beenmainly investigated in WP1 and is concerned with abstract specification, the second one, consideredin WP2, is concerned with behavioural specification, the third one, considered in WP5, is concernedwith extended behavioural specification to deal with unexpected events, like unreachability of a serviceend-point, time-outs, session termination. We summarize the different approaches to the definition ofsuitable languages to deal with the three above mentioned aspects. To enable the reader to appreciatethe differences between the used formalisms, we consider a simple case study (a car repair service) as arunning example.

016004 (Sensoria) 2


Contents

1 Introduction 4

2 Modelling Service-oriented Systems 72.1 UML Extension for Service Oriented Architectures . . . . . . . . . . . . . . . . . . . . 72.2 The Sensoria Reference Modelling Language . . . . . . . . . . . . . . . . . . . . . . . 92.3 StPowla: integrating business policies and SOA . . . . . . . . . . . . . . . . . . . . . . 13

3 Session-based Core Calculi 153.1 CaSPiS: a dataflow service centered calculus . . . . . . . . . . . . . . . . . . . . . . . 173.2 SSCC: Stream-based Service Centered Calculus . . . . . . . . . . . . . . . . . . . . . 213.3 CSCC: The Conversation Service Centered Calculus . . . . . . . . . . . . . . . . . . . 24

4 Correlation-based Core Calculi 284.1 COWS: Calculus for Orchestration of Web Services . . . . . . . . . . . . . . . . . . . . 304.2 SOCK: Service Oriented Computing Kernel . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Handling the unexpected 375.1 Handler mechanisms in session-based calculi . . . . . . . . . . . . . . . . . . . . . . . 375.2 Handler mechanisms in correlation-based calculi . . . . . . . . . . . . . . . . . . . . . 40

6 Conclusion 41

7 Relevant Papers 42

016004 (Sensoria) 3


1 Introduction

The S project [Sen] aims at developing a novel, comprehensive approach to the engineering ofsoftware systems for service-oriented overlay computers. The project aims at supporting the develop-ment of Global Computing applications along the whole design process. It builds upon existing stan-dards, such as Web Services Description Language (WSDL) and Business Process Execution Language(BPEL), to define specification languages for services. Specifically, S focuses on methods andtools for the development of global services that are context adaptive, personalisable, possibly with dif-ferent constraints on resources and performance, and deployable on significatively different platformsover a global computer.

A central role in this process is played by the used linguistic primitives. They will represent thebasis for finalizing the aim to develop a novel comprehensive approach to the engineering of softwaresystems for service-oriented overlay computers where foundational theories, techniques and methods arefully integrated in a pragmatic software engineering approach. Linguistic primitives and the associatedsemantic models are essential in this respect. They are needed both to describe systems at the rightlevel of abstraction to model their discovery and their composition and to prove that their behavior isconsistent with the expectation of the designer. Indeed, five work-packages (WP1-5) are concerned withlinguistic issues. More specifically, WP1, WP2 and WP5 are interested in finding the right primitivesfor expressing services behaviours and for formulating and proving services properties. While WP3 andWP4 are concerned with the development of the right tools and methodologies

In WP1 five different views have been proposed for an ontology for service specification and devel-opment.

1. Service Description for Coordination and Composition

2. Service Discovery and Dynamic Reconfiguration

3. Non-Functional Properties of Services

4. Business Goals and Policies

5. Business Processes

One of the concerns of WP1 is the development of high-level modelling languages for services. Thisincludes their formal syntax, their semantics in relation to the concepts of the ontology, as well as theirvisual representation based on extensions to the UML.

SRML is aimed at providing a formal modelling notation for the ontology. Views 1 and 5 of theontology are supported by the core subset SRML-P. Central to SRML-P is the notion of module, agraph of components jointly providing services that are offered on the module’s export interface. In linewith the ontology, interaction with services is stateful, i.e., the invocation of a service is associated tothe execution of a session. Due to the joint provision of services by several components, a distributeddescription of the executable pattern of invocations that an orchestrator must follow to achieve its goal isprovided by SRML-P internal wires. Such a distributed perspective is more realistic than the global oneusually adopted by business process languages such as BPEL, where a single orchestrator per service isassumed.

UML extensions are being developed for the different views to provide a visual notation closer to themainstream of software development. As far as formal semantics is provided we will make sure that it iscompatible with that of SRML.

WP 2 aims at providing a foundational understanding of the Service-Oriented Computing (SOC)paradigm and at developing calculi for service specifications and analysis that comply with a service-oriented approach to business modeling, allow for modular description of services, support dynamic,ad-hoc, ”just-in-time” composition. Such calculi have to provide a small set of primitives to be used asthe basis for formalizing and programming service oriented applications.

016004 (Sensoria) 4


We planned to use process algebras as our starting point and to add them primitives for manipulatingsemi-structured data (e.g. pattern matching), mechanisms for describing safe client-service interaction(e.g. sessions), operators for composing (possibly unreliable) services, techniques for query and discov-ery of services. We already foresaw that the outcome could not necessarily be a single core languagebut a few calculi that could be differentiated by the chosen level of abstraction, the chosen client-serviceinteraction/coordination mechanisms, the primitives for orchestration.

During the first year of the project we have experimented with existing process calculi without spe-cific service oriented features. These calculi have been used in different work-packages (such as WP2,WP3 an WP4) as reference models for prototype encoding, for comparisons of emerging proposals andfor experimenting with tool supporting specification and verification of case studies. Building on theexisting calculi, within WP2 a few proposals have emerged distinguished by different abstraction levelsand different aims [BBC+06, BGG+06, FGS06, LPT07, BDF06].

• SC [FGS06] aims at providing a basic framework, a sort of middleware, for implementing lan-guages for SOC;

• SOCK [BGG+06] is an abstraction of BPEL approach but sufficiently close to it to mimic itsdevelopment process;

• COWS [LPT07] starts from BPEL but abstract more from it to get very close to a classical processdescription language;

• SCC [BBC+06] starts from the abstract notion of session to develop a calculus along the lines ofπ-calculus;

• λreq [BDF06] is specifically designed for call-by-contract service selection and the advocatedparadigm could be used to extend any of the previous formalisms.

The comparison, assessment, refinement and integration of the proposed calculi has constituted aprominent research activity for the prosecution of the project. We plan to assess the quality of ourproposals, by means of a number of case studies by considering issues connected to service contracts;service discovery; service composition. Thus, within WP2, for the work on calculi in the second year,we have concentrated on formalism that are at a comparable abstraction level, namely SOCK, COWSand SCC. We plan to further study SC within WP6 as a basis for developing (in alternative to IMC ortogether with it) middleware for the implementation of service description languages, and to study λreq

within the task of WP2 dealing with resources handling and services discovery.The final aim of WP2 is to define a set of basic concepts (primitives and operators) that correspond

to key notions of SOC and could be then grouped/subsetted in different calculi aiming for capturingdifferent approaches to services development and analysis. During, the second year of the project,we started working on the key issue of convergence for the various proposals and set up a wiki page(http : //www.pst.ifi.lmu.de : 8080/Sensoria/WP2) by attempting what could be called a LEGO ap-proach aiming at putting all proposals on the same ground and aiming at defining the so called PLanguage. We were aiming at providing a separate description for each primitive by using labelled tran-sition systems and Structured Operational semantics as the unifying framework, under the assumptionthat if descriptions could be defined unambiguously in some standard and uniform notation, then thesoftware engineer can be provided with some sort of menu from which service programming languagescan be assembled, by need, in a modular fashion. In our case, descriptions involved the syntax, the oper-ational semantics (in terms of labeled transitions) and some informal text defining the purpose and usageof each construct.

In fact process calculi should not be seen as ordinary specification or programming languages, butrather as experimental prototypes, whose primitives can inspire new computing paradigms. For specifi-cation formalisms and for programming languages standardization is essential for widespread usage andfor building tools and the right balance between size and expressiveness is very important. Exactly to

016004 (Sensoria) 5


capture different notions of interacting processes, plenty of combinators have been devised but then theyhave been carefully grouped into a the different (all successfully used) process calculi after identifyingthe minimal and most elegant set of essential constructs for each particular issue. We feel, however, thatsome amount of standardization is essential to facilitate success and tool development, more than everin service oriented paradigm. Indeed, each issue (e.g. the programming of service sessions) is typicallyaddressed by a small group of primitives and it obviously makes no sense to take some of them separately(e.g. consider having primitives for catching exceptions without the possibility of throwing them, or viceversa).

After discarding the LEGO approach we aimed at classifying the different proposals to understandthe key points of SOC and grouped the different proposals into two main groups:

Correlation Based Calculi The link between partners (caller and callee) are determined by correlationsets. An instance contains some correlation values and only messages with the right correlationvalues are received. Two different alternatives are being considered corresponding to COWS andSOCK , their main difference is that the former is stateless (correlation based on values) and thelatter is stateful (correlation based on variables).

Session Based Calculi For calculi of this group a session corresponds to a private channel that is in-stantiated when calling a service: It binds caller and callee and is used for their communication.To manage inter-session communication different mechanisms have been proposed that are at themoment under evaluation. We worked first on a single core calculus (SCC) then studied variantsbased on different inter-session communication mechanisms.

Within WP5 more sophisticated composition patterns and primitives, pertaining to SLA, servicecompliance and transactional aspects have been considered. They are typically more specialized anddefined at a higher level of abstraction than WP2 primitives. During the first year of the project, we haveexperimented with extensions of reference calculi, like π-calculus and join calculus. During the secondyear of the project, we started to carry out the extensions on the existing proposals emerged within WP2.We have thus extended some of the calculi introduced in WP2 with handlers for unexpected events, likethe sudden unreachability of a service end-point, or the expiration of a time-out, or the decision of someparties to abandon an ongoing negotiation or conversation. At the same time, the experience maturatedwith the modeling of WP5 issues helped us in refining general purpose WP2 primitives so that they canoffer better support for encoding different flavours of QoS negotiations and compensation policies forlong running transactions.

In the remaining sections we shall briefly describe the different formalisms that have been proposedin WP1, WP2 and WP5 and shall use the following running example to present and discuss their mainfeatures. To enable the reader to appreciate the differences between the used formalisms, we consider asimple case study, that we describe below, as a running example.

A Car Repair Service

A car manufacturer offers a service that once a users car breaks down the on-board computer system triesto locate garages, car rentals and towing truck services in the car’s vicinity, so that

• the car is towed to the garage and repaired

• the car driver may continue her travel

Furthermore, the interdependencies between service bookings makes it necessary to have an orches-tration with compenstations. The dependencies are:

• Before orders, the credit card is charged with a security amount.

• Before looking for a tow truck, a garage must be found as it poses additional constraints to thecandidate tow trucks.

016004 (Sensoria) 6


• If finding a tow truck fails, the garage appointment must be revoked.

• If renting a car succeeds and finding either a tow truck or a garage fails, the rented car must beredirected to actual location of the broken down car.

• If the car rental fails, it should not affect the tow truck and garage orders.

2 Modelling Service-oriented Systems

This section provides an overview of the modelling languages considered in Sensoria WP1. The fol-lowing subsections present the UML extension for modelling service-oriented systems, the SensoriaReference Modelling Language (SRML) and StPowla, respectively.

2.1 UML Extension for Service Oriented Architectures

Within the SENSORIA approach, services can be modelled by using a specialisation of the UML. For thestatic aspects of service-oriented software systems, this representation effort ranges from rather simple,stereotyped language extensions for introducing services to more complicated structures like dependencyrelations between services and their contextual relationships to resources and legacy systems. The dy-namic parts of service-oriented software, in particular orchestration and choreography of services aresupported by developing primitives for interaction and activity modelling that take into account possiblefailures and quality-of-service aspects. The extensions will incorporate behavioural descriptions but alsostructural and non-functional notions.

Modelling Structural Aspects

The structure of a service oriented architecture can be visualised by UML deployment and compositestructure diagrams. A deployment diagram is used to represent the—usually nested—nodes of the ar-chitecture, i.e. hardware devices or software execution environments. Fig. 1 shows a UML deploymentdiagram of the car and its environment as first approximation to an architecture model. The nodes areconnected through communication paths that show the three types of communication that characterisethe automotive domain: intra-vehicle communication (non-named connections), inter-vehicle communi-cation, and communication among vehicle and environment such as communication with the car man-ufacturer or a remote discovery server. Note that the architecture comprises a local as well as a remotediscovery service in order to find services in the local repository. The components that are involved inthe execution of service orderings are a service discovery which may be local or external to the car, areasoner for service selection and a service orchestrator.

In addition to UML deployment diagrams, which give a static view of the architecture, we use UMLstructure diagrams to represent the evolving connections within the service oriented architecture of thevehicle and its environment. Three different types of connections are identified: discovery connection,permanent connection (as in modelling of non service oriented architectures) and temporary connections.In order to be invoked services need to be discovered before the binding to the car’s on-board systemtakes place. Thus the discovery connection is based on the information provided by a discovery service.We distinguish a temporary connection which is for example one from the car on-board system to aknown service such as the car manufacturer discovery service, from a permanent connection. Permanentconnections wire components as in traditional software. For a graphical representation and more detailsabout these connections the reader is referred to [WCG+06].

Modelling Behavioural Aspects

An important aspect when modelling the behaviour of a service oriented system is the workflow describ-ing the orchestration of services. Modelling orchestration of services includes specifying different types

016004 (Sensoria) 7


HardwareLow level

Vehicle Platform

«execution environment»High Level Vehicle Platform

«device»Vehicle

«device»Mobile Phone

Remote Discovery

Vehicle Communication Gateway

In-Vehicle Service Platform

Driver-VehicleUI

Orchestrator LocalDiscovery

Repository

«device»Vehicle

«inter-vehicle» «vehicle-environment»

Reasoner

Figure 1: Simplified architecture of car and car environment

of interaction among services, modelling transactional business processes that may require a very longperiod of time in order to complete, and also specifying non-functional properties of services.

In the modelled business process of the on road car repair scenario the orchestration is triggeredby an engine failure or a sensor signal like low oil level. The process starts with a request from theOrchestrator to the Bank to charge the driver’s credit card with the security deposit payment, which ismodelled by an UML action ChargeCreditCard. In paralell the orchestrator initiates an interaction toFindServices expecting a reply from the Local Discovery service. For the selection of services the or-chestrator synchronises with the Reasoner to obtain a list of the most appropriated services. Serviceordering is modelled by the UML actions OrderGarage, OrderTowTruck and RentACar following a se-quential and parallel process, respectively. Fig. 2 shows an UML activity diagram of the orchestrationof services in the on road car repair scenario. We use stereotyped UML actions indicating the type ofinteractions performed based on the interaction classification proposed by SRML ([FLB06b]). The useof these stereotyped UML action has direct advantages when model transformations are applied.

The key technique to handle long running transactions is to install compensations, e.g. based onthe saga concepts. Modelling of compensations is not directly supported in UML. We provide an UMLextension within SENSORIA for the modelling of these compensations. The extension consists of twomodelling primitives – Saga and ActivityGroup – and corresponding stereotypes for UML activity dia-grams. Saga is an executable activity node that may have subordinate nodes with the ability to compen-sate long running transactions. CompensableAction owns exactly one pair of actions (forward action andcompensation action). For further details see [WCG+06], article which also describes the use of anno-tations in UML activity diagrams for the specification of non-functional properties such as performanceand resource consumption.

016004 (Sensoria) 8


«rcv»GarageOK

Orchestrator OnRoadRepairService

«rcv»CurrentLocation

LocalDiscovery

«ask»RequestLocation

«tll»ChargeCreditCard

Bank

EngineFailure

«s&r»FindServices

«ask»ChooseServices

Reasoner

«snd»OrderTowTruck

«snd»RentACar

«snd»OrderGarage

Figure 2: Orchestration in the on road car repair scenario

2.2 The Sensoria Reference Modelling Language

In SRML, composite services are modelled through modules. A module declares one or more servicecomponents, or components for short, a number of requires-interfaces that specify services that need tobe provided by external parties, and (at most) one provides-interface that describes the service that isoffered by the module. A number of wires establish interaction protocols among the components andbetween the components and the external parties that instantiate the interfaces.

A component is a computational unit represented in a module by what we call a business role. Abusiness role declares the interactions in which the component can become involved, and the executionpattern that orchestrates those interactions. Each such execution pattern, or orchestration for short, isdefined independently of the language in which the component is programmed and the platform in whichit is deployed; it may be a BPEL process, a Java program, a wrapped-up legacy system, inter alia. Inaddition, the orchestration is independent of the specific parties that are actually interconnected with thecomponent in any given run-time configuration. Such interconnections are established by interactionprotocols as discussed below. In SRML, the orchestration of the service provided by a module is thecomposition of the orchestrations defined within the components and the interaction protocols throughwhich they are wired together.

The external interface that exposes the business logic offered by a module describes the properties ofthe interactions that the module supports as a service provider, which any client may expect once boundto the service. The external interfaces to services required from other parties specify the interactionsbetween a service component and the corresponding party and the conversations that the module expectsfrom the relative party, i.e., SRML supports “syntactic” and “behavioural” interfaces. External interfacesare defined in a module through what we call business protocols.

The interconnections that are established among the components and between components and ex-

016004 (Sensoria) 9


Figure 3: SRML module for the on road car repair scenario

ternal parties, are modelled in a module through wires. A wire establishes a binding between the in-teractions that both parties declare to support and defines the interaction protocol that coordinates thoseinteractions. The coupling of service components within modules can be seen to be tight and performedat design time, reflecting the fact that components offer an (atomic) unit of business logic. The couplingestablished between components and external parties is looser and established at run time, or “just-in-time”, through the discovery, selection and binding mechanisms that are supported by the underlyingservice middleware.

Figure 3 illustrates the SRML module for the on road car repair scenario. The components are GP,OR and DR of type (business role) GPS, Orchestrator and Driver, respectively. The provides-interfaceis EF of type (business protocol) EngineFailure. The requires-interfaces are GA, TT, CR and BA of type(business protocol) Garage, TowTruck, CarRental and Bank, respectively.

Interactions

All interactions involve two parties and are described from the point of view of the party in which theyare declared, i.e. “receive” means invocations received by the party and sent by the co-party, and “send”means invocations made by the party. Some of them (the first two types), are are two-way conversationalinteractions, i.e. they involve a reply and other events. Interactions can be synchronous (the last fourtypes), implying that the party waits for the co-party to reply or complete, or asynchronous (the firstfour), in which case the party does not block.

In SRML, interactions can be declared to be of several different types: s&r interactions are initi-ated by the co-party, which expects a reply, r&s interactions are ion is initiated by the party, whichexpects a reply from its co-party, rcv where the co-party initiates the interaction and does not expect areply, snd where the party initiates the interaction and does not expect a reply, ask where the party syn-chronizes with the co-party to obtain data, rpl where the party synchronizes with the co-party to transmitdata, tll where the party requests the co-party to perform an operation and blocks and prf whre the partyperforms an operation and frees the co-party that requested it.

Entities

The different types of entities involved in a module—components, requires interfaces, provides inter-faces, and wires—are specified in SRML using three different but related languages. In this section, wepresent each of these languages separately.

Business Roles In SRML, components instantiate business roles. A business role is specified by declar-ing a set of interactions and the way they are orchestrated. As an example, consider the specification ofthe business role fulfilled by the orchestrator. The orchestrator can be involved in the following interac-tions, that can have -parameters for transmitting data when the interaction is initiated and� -parametersfor carrying a reply:

016004 (Sensoria) 10


Interactionsrcv engineFailures&r AskUsrDetails

� cust:customerID

ccID:bankAccountID

dest:location

workrelated:boolean

∆t:Time

s&r currentLocation app:LocationApproximation

� l:Location

s&r requestCharge cust:customerID

ccID:bankAccountID

amount:moneyVal

� certif:moneyVal

s&r orderGarage...

s&r rentACar...

s&r orderTowTruck...

snd confirmation

Components are linked to their co-parties within modules through explicit wires as described below.The way the declared interactions are orchestrated is specified through a set of variables that provide

an abstract view of the state of the component, and a set of transitions that model the activities performedby the component, including the way it interacts with its co-parties. For instance, the local state of theorchestrator is defined as follows:

local s:[0..8]

An initialisation condition may designate a specific initial state such as:

initialization s = 0

Similarly, a termination condition may be specified to specify situations in which the componentwill not engage in any further interactions. The behaviour of components is described by transitionrules. These rules can be derived from UML sequence or activity diagrams and refined with additionalinformation. Each transition has a name, and a number of other features:

transition startProcesstriggeredBy engineFailure ?

guardedBy s=0effects s’ = 1sends currentLocation ! ∧ askUsrDetails !

∧ currentLocation .app=10

1. A trigger is a condition: typically, the occurrence of a receive-event or a state condition. In theexample we engage in the startProcess transition when we receive the initiation of the interactionengineFailure.

2. A guard is a condition that identifies the states in which the transition can take place. For instance,the startProcess transitions should only be taken when we are in the initial state.

3. A sentence describes the effects of the transition in the local state. We use s′ to denote the valuethat state variable s has after the transition.

4. Another sentence describes the events that are sent, including the values taken by their parame-ters. In the example we invoke the currentLocation event to ask for the current location of thecar and askUsrDetails to ask for some details related to the trip and to the driver. We specify



the desired approximation of 10 meters for the GPS data as a parameter of the interaction eventcurrentLocation .

Notice that, even if it is relatively easy to model a state machine in SRML, the way we model controlflow is more flexible because transitions are decoupled from interactions and changes to state variables.

Business Protocols Besides components, a module in SRML may declare a number of (external) in-terfaces, i.e., abstractions (types) of parties that can be dynamically interconnected and that specify theservices that a module provides or possibly requires at run time.

External interfaces are specified through what we call business protocols. Like business roles, pro-tocols declare the interactions in which the external entities can be involved as parties. The differenceis that, instead of an orchestration, we provide a set of properties that describe (in the case of provides-interfaces) or specify (in the case of requires-interfaces) the protocol that the co-party adheres to.

For example, the behaviour of the external (provides-) interface EF of type EngineFailure offers ahigh level description of the dependencies between the supported interactions:Behaviour

initiallyEnabled engineFailure ?

engineFailure ? ensures confirmation !

The behaviour is described by two statements. The first one ensures that the interaction engineFailure ?is enabled since the beginning of the session and that it remains enabled until it occurrs. In the secondone, con f irmation ! will eventually occur after the occurrence of engineFailure ?.

Interaction Protocols A module consists of a number of components and external interfaces (provides/requires) wired to one another. Wires are labelled by connectors that coordinate the interactions inwhich the parties are jointly involved. In SRML, we model the interaction protocols involved in theseconnectors as separate, reusable entities.

Just like business roles and protocols, an interaction protocol is specified in terms of a number ofinteractions. Because interaction protocols establish a relationship between two parties, the interactionsin which they are involved are divided in two subsets called roles—A and B.

The “semantics” of the protocol is provided through a collection of sentences—what we call theinteraction glue—that establish how the interactions are coordinated. This may include routing eventsand transforming sent data to the format expected by the receiver.

Interaction Protocol Straight.I(d1)O(d2)

Role As&r S1

i1:d1

� o1:d2

Role Br&s R1

i2:d1

� o2:d2

CoordinationS1 ≡ R1

S1.i1 = R1.i1

S1.o1 = R1.o2

The interaction protocol above is a “standard” protocol that connects directly two entities over twointeractions with one - and one � - parameter and it is used for the wire OG in the diagram below.The wire OG connects the orchestrator component OR and the garage service GA. The wire uses theInteraction Protocol Straight and instantiates the types d1 and d2 with the actual types, vehicleId andLocation, of the interaction orderGarage. Interaction protocols can be much more complex as discussedand formalised in [ABFL07].



OROrchestrator � OG � GA

Garage

s&r orderGarage carId:vehicleId� l:Location

S1 Straight R1i1 I[vehicleId] i1o2 O[Location] o2

r&s orderGarage carId:vehicleId� l:Location

Service Level Agreement In addition to the modelling of the “static” aspects of service descriptionand composition, SRML offers primitives for modelling “dynamic” aspects concerned with configura-tion, session management and Service Level Agreement. In particular, SRML supports the definition ofattributes and constraints for Service Level Agreement (SLA) using the algebraic techniques developedin [BMR97, Bis04] for constraint satisfaction and optimization. The constraints presented therein canbe modeled in SRML using the following constraint system, where S is a c-semiring, D is a finite set(domain of possible elements taken by the variables) and V is a totally ordered set (of variables):Constraint System

S is <[0..1],max,min,0,1>

D is { n∈N:0≤ n ≤1000 }V is { GA.cost, GR.duration,...}

The variables GA.cost, GR.duration represent the cost and availability of the garage service, respec-tively. We show below the SRML specification of two constraints: fastRepair and cheapRepair. Theconstraint cheapRepair depends on the context variable DR.askUsrDetails� .workRelated, a Booleanvariable that defines if the trip is work related. The function de f2 returns the maximum value of satisfac-tion if DR.askUsrDetails� .workRelated is true, independently of the cost.

Constraints

fastRepair is <{GR.duration},def1> s.t. def1(n)=48/n

cheapRepair is <{GR.cost},def2> s.t. def2(n)=

if DR.askUserDetails.workrelated then 1 else 1/n

For each potential garage partner, the set of constraints has to be solved. The solution assigns adegree of satisfaction to each possible tuple of values for the variables in V. Negotiation in our frameworkconsists in finding an assignment that maximizes the degree of satisfaction and, hence, the outcome ofthe negotiation between onRoadCarRepair and the potential partner is any of those tuples that maximizethe degree of satisfaction. Then selection picks the partner with the sla that offers the best degree ofsatisfaction.

2.3 StPowla: integrating business policies and SOA

One of the goals of SENSORIA is the integration of Business Process Management (BPM) and SOA,since it is generally perceived as a promising solution to the design and development of the softwaresystems of the future. A key requirement in this respect is good support for flexibility, e.g. to customizea core model and adapt it to peculiar requirements of each stakeholder, and accommodate the variabil-ity of the business domain. To cope with flexibility and variability, we introduce a Service-TargetedPolicy-Oriented WorkfLow Approach, SP [GMRMS07]. SP is designed to support policy-driven business modelling over general Service Oriented Architectures. It addresses the integration ofbusiness processes and Service Oriented Architectures at a high level of abstraction, that is, close to thebusiness goals. SP also exploits this integration to cope with the variety and variability of businessrequirements, at the same time avoiding that these details obfuscate the essence of the business workflow.

SP integrates three main ingredients: a graphical workflow notation, a policy language, and theSOA. The business process core is defined composing building blocks called tasks, a la BPMN [Obj06].SP is intended to be independent of the workflow language, e.g., UML activity diagrams can beused. The finer details of the business process are expressed by policies. These can define functionaland non-functional requirements of a task. Furthermore, they can provide overarching business con-straints, that is a set of rules specified at a global, enterprise or project level and applicable to the whole



workflow. Here, we use A [TRMB+06], a general language for expressing policies in a variety ofapplication domains, which was designed to support a clear separation between the core language and itsspecialization for concrete domains. With respect to SOA, SP’s users, though informatically naıfs,should be aware that the business is ultimately carried out by services, i.e. computational entities that arecharacterized by two sets of parameters: the invocation parameters, related to the functionality, and theService Level Agreement (SLA) parameters. A key idea is that the stakeholders can use their policies toadapt the core workflow also by modifying these agreements.

Tasks, policies, and services

Tasks are the units where BPM, SOA and policies converge: the intuitive notion of task is revisited tooffer a novel combination of services and policies. To specify tasks, we specialize A to deal withservices, by introducing a special action, req(-, -, -), for service discovery and invocation. Thesemantics of this action is to find a service as described by the first and third arguments (specifyingservice type and SLA constraints), bind it, and invoke it with the values in the second argument (theinvocation parameters). This semantics is borrowed from lambda–req (D3.3.a section 6).

A default policy is associated with each task. It says that when the control reaches the task, a serviceis looked for, bound and invoked, to perform the functionality of the task (denoted by main):

appliesTo <taskName> when taskEntry(<args>)

do req(main, <args>, [])

where taskEntry denotes the policy trigger, whose arguments are the task parameters, if any.Adaptation occurs when the user overrides the default policy with his own, by specifying the SLA con-straints, or by using the composition operators of A. SLA constraints usually address different kindsof concerns, or SLA dimensions. Dimensions are specified in the domain description by their name, setof values, and applicable operators. For instance, dimension Automation takes values in {automatic,interactive}, where the former excludes the involvement of humans in the fulfillment of the task.Essentially, a dimension defines a type for service customization.

A is a policy language designed for end-users: its style is close to natural language, permittingordinary users to formulate and understand policies readily. A formal semantics [MRMS07] under-pins integration with workflows. In A a policy consists of a number of policy rules, grouped usinga number of operators (sequential, parallel, guarded and unguarded choice). A policy rule consists ofan optional trigger, an optional condition, and an action. The applicability of a rule depends on whetherits trigger has occurred and whether its conditions are satisfied. A condition expresses properties of thestate and of the trigger parameters. Conditions may be combined with and, or and not with the expectedmeaning. Actions are domain specific: in SP we introduce req. Triggers are also domain specific,like taskEntry, while conditions are either domain specific or more generic (e.g. time) predicates.

SP users can refer to the state of the execution of the workflow via attributes, i.e. propertiesof individual tasks or of the whole workflow. Attributes can be introduced at different times: a few ofthem are predefined, i.e. they come with SP and are applicable to any task or workflow. Most ofthe attributes are part of the domain specific specialization of the A component of SP, i.e. theycome from the ontology of a particular business domain. Finally, each task can have its own attributes.Attributes are the principal source of information used in policies to adapt the behaviour of a task: theyare used in conditions and SLA definitions.

StPowla policies for the car repair scenario

As an example of adaptation, we discuss a policy taking care of the fact that usually a driver alreadyknows and trusts some of the garage and towing truck services of his own town. In SP the scenariois described by a workflow, to which some policies apply. SP is meant to be independent onthe workflow language: we use here the activity diagram in Figure 4, where the 〈〈task〉〉 stereotype isintroduced in the SP profile defined in D1.4a.



Figure 4: The car repair business process.

The profile does not tackle the issue of describing compensations, and this is not supported by UML,as discussed in Section 2.1. Indeed, often compensation is a detailed design issue and should not bedescribed at the most abstract level.

P: If the car fault happens in the driver’s town, then he wants to select the services to be used. Otherwisehe wants them choosen automatically.

Of course it would be possible to write a detailed business process diagram that encapsulates the option,but it is typical that while the essential process remains the same, the policies change.

The first step is to define task and workflow attributes, and SLA dimensions. We focus our attentionon those attributes needed to define the policy:

SLA dimensions Automation = enum{automatic, interactive}

Domain Dependent Attributes myTown : String

Task findServices location : String

Then, we can formalize the policy which applies to task selectBest. It is defined as a sequence, thefirst argument being the request of an interactive choice and the second one dealing with the generalcase. Operator seq checks its second argument only if the first one is not applicable, i.e. if the locationis different from the drivers’ town.

P: appliesTo selectBest

when taskEntry([])

if findService.location = myTown

do req(main, [], [Automation = interactive])

seq

when taskEntry([])

do req(main, [], [Automation = automatic])

3 Session-based Core Calculi

An important group of calculi for modeling and proving properties of services is the one based on theexplicit notion of session. A session corresponds to a private channel that is instantiated when calling aservice: It binds caller and callee and is used for their communication. To manage inter-session commu-nication different mechanisms have been proposed that are at the moment under evaluation. We workedfirst on a single core calculus ( SCC) then studied variants based on different inter-session communica-tion mechanisms. SCC has been influenced by Cook and Misra’s Orc [MC07], a basic programmingmodel for structured orchestration of services, and by π-calculus [MPW92] the by now classical repre-sentative of name passing calculi. Indeed one could say that SCC combines the service oriented flavourof Orc with the name passing communication mechanism of π-calculus. In particular, Orc has been ap-pealing to us because of its simplicity and yet great generality: its three basic composition operators canbe used to model the most common workflow patterns, identified by van der Aalst et al. in [vdAtKB03];we aimed at a calculus with a descriptive power similar to Orc but with the mathematical cleanness ofπ-calculus.



SCC supports explicit modeling of sessions that are rendered as private bi-directional channels cre-ated upon services invocation and used to bind caller and callee. The interaction is programmed by twocommunication protocols installed at each side of the bi-directional channel. This session mechanismpermits describing and reasoning about interaction patterns that are more structured than the classicalone-way and request-response pattern. Essentially, SCC is a name passing process calculus with explicitnotions of service definition, service invocation and bi-directional sessioning.

Within SCC, services are seen as sort of interacting functions (and even stream processing functions)that can be invoked by clients. Service definitions take the form s ⇒ (x)P, where s is the service name,x is a formal parameter, and P is the actual implementation of the service. For instance, succ ⇒(x)x+1 models a service that, received an integer returns its successor. Service invocations are written ass{(x)P} ⇐ Q: each new value v produced by the client Q will trigger a new invocation of service s; foreach invocation, an instance of the process P, with x bound to the actual invocation value v, implementsthe client-side protocol for interacting with the new instance of s. As an example, a client for the simpleservice described above will be written in SCC as succ{(x)(y)return y} ⇐ 5: after the invocation x isbound to the argument 5, the client waits for a value from the server and the received value is substitutedfor y and hence returned as the result of the service invocation.

A service invocation causes activation of a new session. A pair of dual fresh names, r and r, identifiesthe two sides of the session. Client and service protocols are instantiated each at the proper side of thesession. For instance, interaction of the client and of the service described above triggers the session

(νr)(r B 5 + 1 | r B (y)return y

)(in this case, the client side makes no use of the formal parameter). The value 6 is computed on theservice-side and then received at the client side, that reduces first to r B return 6 and then to 6 | r B 0(where 0 denotes the nil process).

More generally, within sessions communication is bi-directional, in the sense that the interactingprotocols can exchange data in both directions. Values returned outside the session to the enclosingenvironment can be used for invoking other services. For instance, what follows is a client that invokesthe service succ and then prints the obtained result:

print{(z)0} ⇐ ( succ{(x)(y)return y} ⇐ 5 ) .

(in this case, the service print is invoked with vacuous protocol (z)0).A protocol, both on client-side and on service-side, can be interrupted (e.g. due to the occurrence of

an unexpected event), and interruption can be notified to the environment. More generally, the keywordclose can be used to terminate a protocol on one side and to notify the termination status to a suitablehandler at the partner site. For example, the above client is extended below for exploiting a suitableservice fault that can handle printer failures:

print{(z)0} ⇐fault ( succ{(x)(y)return y} ⇐ 5 ) .

The original proposal of SCC was somehow unsatisfactory with respect to the handling of inter-session communications, thus variants of SCC that make use of different communication mechanismshave been put forward.

• CaSPiS is dataflow oriented and makes use of a pipelining operator (a la ORC) to model thepassage of information between sessions [BBDL07]; return is used by sessions for passing valuesto the environment.

• SSCC is stream oriented and has primitives for inserting/retrieving data in/from streams [LVMR07]that are used both for inter-session communication and for communication with the environment.

• CSCC is message oriented and has explicit and distinct message passing primitives to model interand intra session communication [CVS07] and for communicating with the environment.

In the next sections we shall analyze in sequences the three variants of SCC mentioned above.



3.1 CaSPiS: a dataflow service centered calculus

CaSPiS is variant of SCC that is dataflow oriented and makes use of a pipelining operator to modelthe passage of information between sessions. The calculus makes use also of a new policy for handling(unexpected or programmed) session closures that in the original calculus was somehow ”rudimental”.Specific care is devoted to formal semantics and minimality of the operators. Like in [HVK98], asession is a chain of dyadic interactions whose collection constitutes a program. Services are seen aspassive objects that can be invoked by clients and service definitions can be seen as specific instancesof input prefixed processes. The two endpoints of the same session can communicate by exchangingmessages. A fresh shared name is used to guarantee that messages are exchanged only between partnersof the same session, so that two instances of the same persistent service (that was invoked from twodifferent sessions) run separately and cannot interfere. The central role assigned to sessions and thedirect use of operators for modeling sessions interaction renders the logical structure of programs moreclear and leads to a well disciplined service specification language that enable us to guarantee properhandling of session closures and in general simplifies reasoning on the specified services.

A gentle introduction to CaSPiS

Within CaSPiS, service definitions are rendered as

s⇒ P

where s is the service name and P is the body defining the service behaviour. P can be seen as a processthat receives/sends values from/to the client side and then activates the corresponding computationalactivities. For instance,

succ⇒ (?x)〈x + 1〉

models a service that, after receiving an integer, sends back the successor of the received value.Service invocations can be seen as specific instances of output prefixed processes and are rendered

ass⇐ P

where s is the name of the service to invoke while P is the process implementing the client-side protocolfor interacting with the new instance of s. As an example, a client for the simple service described abovewill be written in CaSPiS as

succ⇐ 〈5〉(?y)return 〈y〉

After succ is invoked, argument 5 is passed on to the service side and the client waits for a value fromthe server: the received value will be substituted for y and returned as the overall result of the serviceinvocation.

A service definition s.P and service invocation s⇐ Q running in parallel can synchronize with eachother: in doing so, they must agree on a fresh session name r. As a result, a new, private session r will becreated. The session has two ends, one at client’s side where protocol Q is running and one at service’sside where protocol P is running. For instance, the interaction of the client and of the service describedabove triggers the session

(νr)(r B 〈5 + 1〉 | r B (?y)return 〈y〉

)Values produced by a concretion (〈V〉P) at one side of a session are consumed by an abstraction

((F)P) at the other side. A concretion 〈V〉P can evolve to P by sending value V over the session. Anabstraction (F)P is a form of guarded command that relies on pattern-matching: (F)P can evolve to Pσretrieving a value V matching the pattern F with substitution σ (match(F,V) = σ). Here, the pattern-matching function match is defined as expected: match(F,V) = σ, if σ is the (only) substitution suchthat dom(σ) = bn(F) and Fσ = V .



In the example above, value 6 is computed at the service-side and then received at the client side; theremaining activity is then performed by the client-side of the session

r B return 〈6〉

that emits the value 6 outside of the session and becomes

r B 0

where 0 denotes the empty process. Indeed, the return primitive return 〈V〉P can be used to return a valueoutside the current session, if the enclosing environment is capable of consuming it.

Values returned outside of the session (to the enclosing environment) with the return operator return 〈.〉can be used for invoking other services. Indeed, processes can be composed by using the pipeline oper-ator

P > Q.

A new instance of process Q is activated in correspondence of each of the values produced by P thatQ can receive. For instance, what follows is a client that invokes the service succ and then prints theobtained result:

〈5〉 > (?x)succ⇐ 〈x〉(?y)return 〈y〉 > (?z)print⇐ 〈z〉

To improve usability, structured values are permitted; services are invoked using structured valuesthat drive usage of the exchanged information. Using this approach, each service can provide differentmethods corresponding to the exposed activities. For instance:

calculator⇒ (“sum”, ?x, ?y)〈“result”, x + y〉+ (“sub”, ?x, ?y)〈“result”, x − y〉+ (“mul”, ?x, ?y)〈“result”, x ∗ y〉+ (“div”, ?x, ?y)〈“result”, x/y〉

models a service calculator that exposes the methods for computing the basic arithmetic operations.This service can be invoked as follows:

calculator⇐ 〈“sum”, 2, 4〉(“result”, ?y)return 〈y〉

A similar approach is used for session interaction. Indeed, thanks to tags and pattern matching, moresophisticated protocols can be programmed for both the server and client side of a session. For instance,a service-side can reply to a client request with different values denoting the status of the execution:

r B (“fail”, ?x)P1 + (“result”, ?y)P2

In order to simplify the specification of many important patterns for service composition, someCaSPiS derived operators, defined as macros, have been presented in [BBDL07]. Here, we considertwo of these macros that will be used in the sequel.

We let wait F1, . . . , Fn from P1, . . . , Pn in Q be a process that waits for a tuple (V1, . . . ,Vn), whereVi is the first value emitted by Pi matching Fi, and then activates process Q. Variables in Fi occurring inW are replaced with corresponding values in Vi.

We will also use to s(V) for s⇐ 〈V〉(?x)return 〈x〉. This process implements a functional interactionthat invokes s, sends value v over the established session then waits for a value (the result of serviceinvocation) and publishes it locally.

The syntax of the basic fragment of CaSPiS is reported in Figure 5, where operators are listed indecreasing order of precedence.

We assume two disjoint sets

• a countable set of names N ranged over by n, n′, ...



P,Q ::=∑

i∈I πiPi Guarded Sum π ::= (F) Abstraction| s⇒ P Service Definition | 〈V〉 Concretion| s⇐ P Service Invocation | return 〈V〉 Return| r B P Session| P > Q Pipeline| P|Q Parallel Composition| (νn)P Restriction| !P Replication

V ::= u | f (V) ( f ∈ Σ) ValueF ::= ?x| u | f (F) ( f ∈ Σ) Pattern

Figure 5: Syntax of CaSPiS processes.

• a signature σ of constructors f , f ′, ..., each coming with an integer arity.

N is assumed to contain two disjoint countable sets Nsrv of service names s, s′, ... and Nsess of sessionnames r, r′ . . ., such that N \ (Nsrv ∪ Nsess) is infinite. The set N \ Nsess is ranged over by x, y, ..., u, v....

Concerning basic values, note that, for simplicity, we only consider value expressions V built outof constructors in Σ and names x, y, ..., u, v, ..., the latter playing the role of variables or basic valuesdepending on the context. We leave the signature Σ unspecified, but in several examples we shall assumeΣ contains tuple constructors 〈·, ..., ·〉 of arbitrary arity. Richer languages of expressions, comprisingspecific data values and evaluation mechanisms, are easy to accommodate. Finally, it is worth to notethat session names r, r′, ... do not appear in values or patterns: this implies that they cannot be passedaround, as it will be apparent from the operational semantics presented later in the section.

As expected, in (νn)P, the restriction (νn) binds free occurrences of n in P, while in (F).P any ?x in(F) binds free occurrences of name x in P. We denote by bn(F) the set of names x such that ?x occursin F. Processes are identified up to alpha-equivalence. The guarded sum with I = ∅ will also be denotedby 0. Trailing 0’s will often be omitted. We shall use · to denote sequences of terms.

We will let σ,σ′, σ1, ... range over substitutions, that is, finite partial functions from N to N . Inparticular, we let [u/x] denote the substitution that maps x to u. For any term T , we let Tσ denote theresult of the capture-avoiding substitution of the free occurrences of x by σ(x), for each x ∈ dom(σ).

The Car Repair Scenario

In this section we will show how Car Repair Scenario can be specified in CaSPiS. Once a users carbreaks down the on-board computer system invokes service crash passing the car identification number



(c id), user name (usr) and password (pwd). 1 Behaviour of service crash is described as follows:

Crash 4= crash⇒(?c id, ?usr, ?pwd)wait (?x, ?y), ?p idfrom gprs(“car”, c id), cc(usr, pwd) in

G(p id, x, y) >(“fail”)carloc(x, y)+

(“garage”, ?g id)revoke⇒ garage(“revoke”g id)|TT (p id, x, y) >

(“ok”)carloc⇐ gprs(“garage”, g id)+

(“fail”)carloc(x, y)|CR(p id)

First of all service crash invokes services gprs and cc. The former is used for determining thecurrent car position while the latter is contacted for charging the security amount needed for garage, towtruck and back-up car reservation.

Service gps, which implements a locator system, receives a pair (object type-identifiers), e.g. 〈“car”, c id〉or 〈“garage”, g id〉 , and returns a pair (x, y) representing the coordinates of the specified object. Servicecc receives a user name and a password and returns the payment identification number.

As soon as the car location and the payment identifier have been retrieved, two activities are executedin parallel. One activity aims at reserve both the garage and tow truck while the other contacts a car rentalservice for requesting a back-up car.

Garage reservation is performed by process G(p id, x, y) defined as follows:

G(p id, x, y) 4= garage⇐ 〈“reserve”, x, y〉(“ok”, ?g id)〈“pay”, p id〉return 〈“garage”, g id〉+

(“fail”)return 〈“fail”〉

This is a process that invokes service garage and then sends message (“reserve”, x, y). Two kinds ofreply messages are expected: (“ok”, ?g id) or (“fail”). The former indicates that a garage close to location(x, y) is available while the latter is received when no garage is available. When a garage is available, thepayment identification number is sent to confirm the reservation and the garage identifier is sent locallyotherwise message “fail” is propagated to enclosing the context.

If no garage is available, service redirect the back-up car to the current location. Otherwise, processTT (p id, x, y), which is used for reserving tow truck, is executed while service revoke is installed. Thisis a service that, when invoked, will revoke the garage reservation.

Process TT (p id, x, y) is defined as follows:

TT (p id, x, y) 4= towtruck⇐ 〈“reserve”, x, y〉(“ok”, ?tt id)〈“pay”, p id〉return 〈“ok”〉+

(“fail”)(return 〈“fail”〉|revoke⇐ 0)

Protocol for tow truck reservation is similar to the one used for garage reservation. However, in this case,when reservation fails (message (“fail”) is received), service revoke is invoked and garage reservation is

1We assume that these values are stored in the on-board computer system at car configuration stage.



cancelled. Moreover, back-up car is redirected at the car location. When both the tow truck and garageare reserved, the backup-car is directed to the garage location that is determined by using service gps.

Interaction with car-rental service (carrental) is described by the following process:

CR(p id) 4= carrental⇐ 〈“reserve”〉(“ok”, ?cc id)〈“pay”, p id〉carloc⇒ (?x, ?y)return 〈“get”, x, y〉〈“ok”〉+

(“fail”)carloc⇒ (?x, ?y)〈“fail”〉

Notice that final back-up car destination is determined by service carloc that is installed whithin thesession established by process CR with service carrental.

3.2 SSCC: Stream-based Service Centered Calculus

SSCC [LVMR07] (Stream-based Service Centered Calculus) has been developed to allow the modelingand analysis of web service-based systems. A prominent feature is that the calculus captures in a directway the main activities in service oriented computations: definition and invocation of services, long-running interactions between the invoker and the provider, and orchestration of complex computationsexploiting services as building blocks. SSCC builds on SCC [BBC+06], and tries to improve in particularthe suitability for modeling orchestration. To this end, it introduces a new construct, called stream, withthe aim of collecting the results from some ongoing computations and make them available for new ones.This is the main aspect that differentiates SSCC from CASPIS [BBDL07], the most direct evolutionof SCC. This design choice has been taken in order to simplify static analysis techniques, trying tofind a suitable trade-off between expressiveness of the chosen primitives and suitability to analysis. Inparticular, since stream names can not be communicated, their scope is known statically. An example onhow this feature can be exploited while developing a type system can be found in [LVMR07], where atype system for checking protocol compatibility between invoker and provider of a service is presented.Bisimilarity techniques for proving equivalence of service oriented systems modeled in SSCC are alsounder development.

A gentle introduction to SSCC

We present here in detail the stream construct; refer to CASPIS for the semantics of other primitives (thefull syntax of the calculus can be found in Figure 6). A stream f is declared using a process of the form

stream P as f in Q

Here P and Q are executed concurrently, but only P can insert data v in f , by executing

feed 〈v〉P′

Notice that the name of the stream is not explicitly mentioned in the left-hand-side of the construct:the nearest stream is used. This allows a process to send data to its context, without knowledge of thestructure of the context itself, thus enhancing code re-usability. Also, the feed operation is non-blocking,and f acts as a buffer. The context, represented by Q, can read from stream f via a process of the form

read f (x)Q′

In this case the name of the stream is explicit in the code, allowing a process to acquire data from multiplesources. Also, the read is blocking, allowing the context to wait for the necessary input. A main feature ofthe stream communication is that it is completely orthogonal w.r.t. the structure of sessions, allowing toeasily retrieve data from nested sessions. This reflects in the language the conceptual difference betweensession communication, based on the network infrastructure, and local communication, based e.g. onshared memory.



P,Q ::= Processes

P | Q Parallel composition

| (νa)P Name restriction

| 0 Terminated process

| X Process variable

| rec X.P Recursive process definition

| a⇒ P Service definition

| a⇐ P Service invocation

| 〈v〉P Value sending

| (x)P Value reception

| stream P as f in Q Stream

| feed 〈v〉P Feed the process’ stream

| read f (x)P Read from a stream

u, v ::= Values

a Service name

| unit Unit value

Figure 6: The syntax of SSCC

A typical example where the stream comes handy is that of a broker for hotel bookings. Supposethat this broker, aiming at providing better deals for its clients, asks prices to three hotels that it knowsof, waits for two results, and publishes the best offer of the two. Calling the services for a given date isas follows.

bologna ⇐ <date>(price1) ... |azores ⇐ <date>(price2) ... |lisbon ⇐ <date>(price3) ...

In order to collect the prices, we use the stream constructor, playing the role of a service orchestrator.The various prices are fed into the stream; a different process reads the stream. We write it as follows.

streambologna ⇐ <date>(price1) feed <price1> |azores ⇐ <date>(price2) feed <price2> |lisbon ⇐ <date>(price3) feed <price3>

as f inread f (x) read f (y) { publish−the−min−of−x−and−y}

The above pattern is so common that we provide a special syntax for it, inspired by Orc [MC07].

( call bologna<date> |call azores<date> |call lisbon<date>) >2

x y > { publish−the−min−of−x−and−y}

The various abbreviations used in this section are summarized in Figure 7. The first one modelsa synchronous request-response protocol. The second one is sequential composition with parameterpassing. The last one realizes persistent services. To complete the example we rely on a min service,chaining the first two answers, and publishing the result.

broker ⇒ (date)



call a<x1 ,..., xn> , a⇐ <x1> ... <xn>(y) feed<y>P >n x1 ... xn > Q , stream P as f in read f (x1) ... read f (xn) Qa *⇒ P , rec X. a⇒ (P|X)

Figure 7: SSCC macros

( call bologna<date> |call azores<date> |call lisbon<date>) >2

x y > call min<x,y> >1 m > m


To show the suitability of our calculus, and to highlight similarities and differences with the other Sen-soria calculi, we show how the Car Repair Scenario can be modeled in SSCC. The Car Repair Scenariosystem is composed by the following components:

System , SensorsMonitor | Orchestrator | LocalDiscovery | Reasoner |Bank | OnRoadRepairServices

Here Bank and OnRoadRepairServices are external services, while other services are located inside thecar. We show in detail the behavior of the Orchestrator .

Orchestrator , EngineFailure *⇒ (ν BankReply,GPSReply)BankReqCardCharge⇐ <CCNum,BankReply> |GPSReqLoc⇐ <GPSReply> |stream BankReply⇒ (ok) feed <ok> as fBank inGPSReply⇒ (loc)

FindServices ⇐ <loc> ( serviceList )read fBank (ok)call SelectServices ( serviceList ) >1 (Garage,Rent,Truck) >

Booking

It provides a permanent service, called EngineFailure, to manage engine failures, meant to be invoked bySensorsMonitor. More realistically, Orchestrator would provide for services to manage other failures.

Synchronous interactions are modeled by service invocations followed by a bidirectional sessioncommunication, such as for FindServices (provided by the component LocalDiscovery). Asynchronousinteractions instead are modeled by invocations that send the name of a freshly generated service local tothe invoker (namely, BankRep and GPSRep), which should be called by the provider to return the result.Notice also that streams (both the explicit ones and the ones hidden inside macro >x>) can be exploitedto synchronize and collect the results of the different activities.

In the first part two asynchronous invocations take place: to the bank and to the GPS (part ofLocalDiscovery). The location provided by the GPS is collected (in service GPSReply) and used to invokeFindServices . The process then awaits answers from both FindServices (synchronous, in ( serviceList ))and the bank (asynchronous, in read fBank(ok)) before invoking service SelectedServices . Such a servicereturns a tuple with services for booking a garage, renting a car and asking for a tow truck.

The structure of the Booking part is similar to the one above, with two services invoked asyn-chronously.

Booking , (ν GarageReply,RentReply)Garage⇐ <loc,GarageReply> |Rent ⇐ <loc, RentReply> |stream RentReply ⇒ (rentOk) feed <rentOk> as fRent inGarageReply⇒ (garageLocation)

Truck ⇐ <loc,garageLocation> (truckOK)



P,Q ::= 0| P | Q| (νn)P| out direction m(v1, . . . , vn).P| in direction m(x1, . . . , xn).P| !P

| n role [P]| here(x).P| n role s⇐ P| s⇒ P

| try P catch Q| throw.P

role ::= J | Idirection ::= � | � | �

Figure 8: The Conversation Calculus

read fRent (rentOk)End

Process End models some possible activity to be executed after the successful termination of the invoca-tions. Here error handling is not considered, otherwise error-recovery code would be needed to deal withfailures of all these services.

3.3 CSCC: The Conversation Service Centered Calculus

We briefly present the motivation, structure, and informal semantics of the Conversation Service Cen-tered Calculus. The Conversation Calculus integrates a small set of abstractions for expressing andanalyzing service based systems [CVS07]. It focuses on the aspects of distribution, process delegation,communication and context sensitiveness, and loose coupling, believed to be essential to the serviceoriented computational model. Distinguishing aspects of our model are the adoption of a very sim-ple, context sensitive, message passing, local communication mechanism, and a novel mechanism forhandling exceptional behavior. Technically, we proceed by extending a fragment of the π-calculus; theresulting calculus may nevertheless be seen as a possible evolution of the preliminary SCC presented in[BBC+06]. While focusing on the notion of process delegation, first class conversation contexts, and theloosely coupled message passing mechanism, the Conversation Calculus distinguishes itself from otherdescendants of SCC [LVMR07, BBDL07], which explore different interaction mechanisms. We infor-mally describe the several primitives of the Conversation Calculus. The abstract syntax of the calculus isgiven in Figure 8, where we assume given a set Λ of names (m, n, s).

Context A context is a delimited container where closely related computation and communicationhappen. In more general terms, a context is a general abstraction that may be used to model locations(e.g., a unit of distribution), service endpoints (e.g., a delimited scope of communication), contexts ofconversation (e.g., a correlated set of interacting partners), and other forms of localized interaction.Contexts encapsulate functionality and appear to the surrounding environment as a plain local process,thus allowing system descriptions to abstract away from particular implementation details. Any contextparticipates in one of two possible dual roles (initiator J and responder I).



role ::=J | IContextName role [Process]

For example, n J [P] represents a process P inside the initiator endpoint of the context n.

Service publication and instantiation A distinguishing feature of service oriented computing is theemphasis on the remote delegation of interactive processes, rather than on the remote delegation ofindividual operations. We consider service instantiation as a higher level mechanism, allowing a serviceclient to delegate to a remote server not just a single operation or task, but the execution of a wholeinteractive activity (technically, a process). By instantiating a service, a client is able to incorporate anew process in its workflow (a dynamic stateful interactive entity) that, although executing remotely inthe server environment, appears to the client as a local subsystem.

Any context may publish one or more service definitions. Service definitions are located in contexts– seen as sites. Published services may be instantiated upon clients request, resulting in the creation of anew context of conversation composed by two endpoints (initiator and responder). We must differentiateservice instantiation, that creates new process delegates in the service provider and client sites, fromservice invocation that is modeled by some communication mechanism, more concretely, message pass-ing. The interaction of these primitives with contexts and communication abstractions is inspired on, butdiffers from, the basic “session” mechanism of other session based service calculi, and allows contextsto be used with great flexibility (for example, to model multi-party interactions, abstract correlation, andsession delegation). Service definition and service instantiation are written respectively

ServiceName⇒ ServiceBodyServiceProvider role ServiceName⇐ ClientProtocol

Context awareness A process executing in a given context should be able to dynamically access theidentity of such context, in order to correlate its behavior with other partners, and act accordingly. Wethus introduce the primitive

here(x).Process

Communication Interaction between subsystems (e.g., contexts, endpoints, sites) is realized by mes-sage passing. However communication is only allowed between “adjacent” contexts. The possible com-munication paths are: between two dual endpoints (other, written �), between a context and its enclosingcontext (up, written �), and internally to a context (here, written �).

direction ::=� | � | �in direction Message(x, ..., x).Processout direction Message(v, ..., v).Process

Exception handling Exceptional behavior, in particular fault signaling, fault detection, and resourcedisposal, are aspects orthogonal to the existing communication mechanisms, for which specific abstrac-tions are provided.

try GuardedProcess catch HandlerProcessthrow S ignalingProcess

We illustrate CSCC with a simple example, inspired by the SENSORIA Car Break case study[BFGS06]. Briefly, the scenario describes the role of a car’s service planner that, activated by a carbreak, tries to automatically book a repair shop, call a tow truck and rent a car. We present a possiblespecification of the scenario in Figure 9. The CarBreak service starts by instantiating the booking ser-vice of the repair shop. Once the booking is performed, the CarBreak service proceeds to concurrentlyinstantiate both the booking service of the rental car and the call service of the tow truck. The locationof the repair shop is passed both to the tow truck service and to the car rental service.



ServicePlanner I [CarBreak ⇒in � LocalDiagnosis(data).in � GPSLoc(myLoc).

(RepairShop I BookRepair⇐out � BookRepairOperation().in � BookingAccepted(shopLoc, bookingRef).

(out � RepairShopBookingOK(shopLoc, bookingRef)|

out � LocalDiagnosis(data))|

in � RepairShopBookingOK(shopLoc, bookingRef ).(CarRental I Booking⇐out � RequestCar(shopLoc).in � CarAvailable(carId).out � CarRentalOK(carId)|

TowTruck I Order⇐out � CallTruck(myLoc, shopLoc).in � TruckAvailable().out � TowTruckOK()|

in � TowTruckOk().in � CarRentalOK(carId).out � ServicePlanCompleted()))]

Figure 9: Car Break Scenario (Implementation I)

We present a different specification of the same scenario in Figure 10, with the aim of illustratinga more loosely coupled design, and the important role of the local message passing interaction mech-anism in achieving such a design. A service based computation usually consists in (1) a collection ofremote partner service instances, to which functionality is to be delegated, (2) some locally implementedprocesses, and (3) one or more control (or orchestration) processes. The flexibility and openness of aservice based design, or at least an aimed feature, results from the loose coupling between these variousingredients. For instance, an orchestration describing a “business process”, should be specified in a quiteindependent way of the particular subsidiary service instances used, paving the way for dynamic bind-ing and dynamic discovery of partner service providers. In the orchestration language WSBPEL [ea06],loose coupling to external services is enforced, to some extent, by the separate declaration of “partnerlinks” and “partner roles” in processes. In the modeling language SRML [FLB06a], the binding betweenservice providers and clients is mediated by “wires”, which describe plugging constraints between oth-erwise hard to match interfaces. The CSCC idiom now described represents such specification styles inan abstract way.

To implement this alternative specification, we separate the remote interfaces from the orchestrationcode. Notice the separate introduction of three service instances (BookRepair, Booking, and Order),while the control flow is assured by the orchestration code. All interactions between the orchestrationand the local endpoints of the service instances are loosely coupled, and realized through messagesexchanged in the context of each particular CarBreak service instance. The body of the service definition



ServicePlanner I [CarBreak ⇒

RepairShop I BookRepair ⇐in � BookRepairShop(data).out � BookRepairOperation().in � BookingAccepted(shopLoc, bookingRef ).

(out � RepairShopBookingOK(shopLoc, bookingRef )|

out � LocalDiagnosis(data))|

CarRental I Booking⇐in � BookCarRental(loc).out � RequestCar(loc).in � CarAvailable(carId).out � CarRentalOK(carId)|

TowTruck I Order ⇐in � CallTowTruck(depLoc, destLoc).out � CallTruck(depLoc, destLoc).in � TruckAvailable().out � TowTruckOK()|

in � LocalDiagnosis(data).in � GPS Loc(myLoc).(out � BookRepairShop(data)|

in � RepairShopBookingOK(shopLoc, bookingRef ).(out � BookCarRental(shopLoc)|

out � GetTowTruck(myLoc, shopLoc)|

in � TowTruckOk().in � CarRentalOK(carId).out � ServicePlanCompleted())]

Figure 10: Car Break Scenario (Implementation II – Loosely Coupled Design)

follows the general pattern

Partner1 I S ervice1 ⇐ Wire1 | % instantiation of S ervice1 at Partner1· · ·

Partnern I S ervicen ⇐ Wiren | % instantiation of S ervicen at Partnern

OrchestrationProcess

where OrchestrationProcess is a process communicating with the several instances via messages, andthe Wirei descriptions adapt the remote endpoint functionalities (or protocols) to the particular rolesperformed by the instances in this local process.

In [CVS07] we illustrate how several service oriented patterns may be represented in CSCC in aquite natural way, including some abstract form of correlation, and also how other models (Orc [MC07],Distributed Objects [Cai06]) may be easily encoded. A particularly interesting example involves the useof the exception handling mechanism to encode compensatable transactions, in the style of [BHF04].We also discuss several idioms of the exception handling construct, in particular as a mechanism to abort



conversations, dispose resources in a controlled way, and in combination with possible time-sensitiveextensions of CSCC.

The semantics of CSCC is formally specified by means of a labeled transition system, and strongbisimulation defined in the standard way. We have shown that strong bisimilarity is a congruence for alllanguage constructs.

This property justifies the semantic status as full-right behavioral operators of the various primitivesconsidered. We may also prove other interesting behavioral identities, such as:

1. n I [P] | n I [Q] ∼ n I [P | Q].

2. m I [n I [o I [P]]] ∼ n I [o I [P]].

3. n I [out ↑ m(v).R] ∼ out ↓ m(v).n I [R].

Conversation contexts are natural candidates to be subject to interesting typing disciplines, both in termsof the message interchange patterns that may happen at its border (along the lines of behavioral orsession types), and in terms of the resources they use or expose to external clients. We would thus expecttypes (or logical formulas) specifying various properties of interfaces, of service contracts, of endpointsession protocols, of security policies, of resource usage, and of service level agreements, to be in generalassigned to context boundaries. Enforcing boundaries between subsystems is also instrumental to achieveloose coupling of systems. Along these lines, we are developing a compositional type system for CSCC,based on (spatial-) behavioral types, along the lines of [Cai06]. An interesting challenge addressed byour type system is the verification of the delegation of conversation references according to quite strictusage disciplines, involving the context-awareness primitive. This feature allows the static verification ofsystems where several (more that two) partners join and leave dynamically a conversation (representedby a context) in a coordinated way. For a simple example, consider the code fragment (from Figure 10)

RepairShop I BookRepair ⇐in � BookRepairShop(data).out � BookRepairOperation().in � BookingAccepted(shopLoc, bookingRe f ).

(out � RepairShopBookingOK(shopLoc, bookingRe f )|

out � LocalDiagnosis(data))

this code fragment is assigned type

! ↓ BookRepairShop(DataType).? ↓ RepairShopBookingOk(LocType,RefType)

in a typing environment of the form

RepairShop : I [BookRepair(? � BookRepairOperation().

! � BookingAccepted(LocType,RefType).?← LocalDiagnosis(DataType)) ]

Notice that the type assigned to the service instance is a behavioral type, describing the sequence ofmessages exchanged at the context border, while the type assigned to service BookRepair describes theprotocol of the conversations with its clients. The type assigned to context RepairShop specifies theinteractions that take place in the context and its published services.

4 Correlation-based Core Calculi

Service oriented computing (SOC) goes beyond the traditional function invocation (i.e. request-response)pattern introducing stateful interactions based on sessions. The calculi presented so far are based on



implicit sessions; in this section, we consider an alternative approach based on correlation information,that are data explicitly introduced in part of the exchanged messages in order to route the messages tothe correct process instances.

Correlation information is the basis of the Web Services interaction mechanisms which are imple-mented on top of stateless Internet protocols, such as the hyper-text transfer protocol HTTP. As an exam-ple of correlation information, consider the Internet Cookies used by web sites in order to relate an HTTPrequest to a user profile which permits to return, for instance, a customized HTML file.

Correlation information, besides beeing useful to implement stateful communication on top of state-less protocols, represent also a flexible and user programmable mechanism for managing the relation-ships among the collaborating partners. For instance, let us consider an orchestrator that must interactwith n different partners. In the calculi presented in the previous section, the orchestrator must activaten different sessions, one for each partner, and in order to exchange data among these sessions the in-terprocess communication primitives (pipeline, streams or message-exchange) must be exploited. Onthe contrary, the correlation approach allows the orchestrator to run only one process instance, at theprice of including in the exchanged messages, for instance, a process identifier to be used as correlationinformation.

As an example let us suppose a distributed game scenario where two main services are involved: themaster service and the game service. The master service invokes the game service for initiating a gameby sending a freshly created game id (gId) that will be used by the latter service for identifying the newgame session. When the game is started, the game service waits for two players univocally identified bytheir ids. Let us assume the players with ids pId1 and pId2 register themselves to the game. In this case,the game service will add their identifiers to the correlation set of the session game so that the data setformed by gId, pId1 and pId2 identify the session. From now to the end of the session game, the masterservice can interact with the service game by exploiting its id gId, whereas the two players can exploitthe pairs (pId1, gId) and (pId2, gId), respectively, assuming that a player can be involved in more thanone session game. As shown by this example, correlation set allows for the identification of a servicesession by means of a set of data which can be partially exploited by other participants for interactingwith the right session (e.g. the master service uses only its id without knowing the ids of the players).Moreover, correlation data can be communicated to other services in order to allow them to interact withthe right session. In the example above we can imagine that a player leaves the game by communicatingits id to a third player which will replace it.

At the programming level, linguistic mechanisms are necessary in order to specify which part of themessage contains the correlation information. A typical approach is to declare a correlation set, i.e. a setof identifiers of containers for the correlation information.

In order to investigate the impact of the correlation approach in SOC, we embed it in memorylessand memoryful services thus achieving two different calculi called COWS and SOCK, respectively. InCOWS variables can be assigned only once, and they are replaced with the assigned value; in SOCK,on the contrary, variables can be assigned more than once. The most visible consequence of these twodifferent approaches is that the processes instantiated upon service invocation are explicitly representedin SOCK, while this is not the case in COWS. More precisely, in SOCK, a newly instantiated processP is explicitly associated with its state S using the notation [P,S], while in COWS a newly instantiatedprocess P is simply added in parallel with the other processes.

Another more subtle difference is that in SOCK the correlation information can change during theexecution of one process simply by assigning new values to the containers indicated by the correlationset. In this way, for instance, it is possible for a process to dynamically change partners simply bymodifying the corresponding correlation information.

The remainder of this section is devoted to the presentation of the two calculi COWS and SOCK.We simply present the syntax and the modeling in the calculi of the SENSORIA car repair scenario; thereader interested in the definition of the operational semantics can refer to [LPT07] and [BGG+06].



4.1 COWS: Calculus for Orchestration of Web Services

COWS [LPT07] is a process calculus for specifying and combining services, while modelling their dy-namic behaviour. The design of the calculus has been influenced by the principles underlying WS-BPEL [ea06], the de facto standard language for orchestration of web services. Similarly to WS-BPEL,COWS supports service instances with shared states, allows a same process to play more than one partnerrole and permits programming stateful sessions by correlating different service interactions. However,COWS intends to be a foundational model not specifically tight to web services’ current technology.Thus, some WS-BPEL constructs, such as e.g. fault and compensation handlers and flow graphs, do nothave a precise counterpart in COWS, rather they are expressed in terms of more primitive operators (see[LPT06], Sect. 3). The design of COWS has also taken advantage of previous work on process calculi. Infact, it combines in an original way constructs and features borrowed from well-known process calculi,e.g. asynchronous communication, polyadic synchronization, pattern matching, protection, delimitedreceiving and killing activities, while however resulting different from any of them.

In the rest of this section, we first provide an overview of COWS−− (COWS minus minus), a subsetof COWS without the two primitive operators kill activity and protection, then we present its syntaxand a specification of the car repair scenario. COWS operational semantics, together with further exam-ples illustrating COWS peculiarities and expressiveness, and comparisons with other process-based andorchestration formalisms can be found in [LPT06].

The basic elements of COWS−− are partners and operations. Alike channels in the π-calculus withpolyadic synchronization [CM03], a communication endpoint is not atomic but results from the com-position of a partner name p and of an operation name o, which can also be interpreted as a specificimplementation of o provided by p. This results in a very flexible naming mechanism that allows a sameservice to be identified by means of different logic names. For example, the following service

pslow • o?w.sslow + pfast • o?w.sfast

accepts requests for the same operation o (with parameters w) through different partners with distinctaccess modalities: process sslow implements a ‘slower’ service provided when the request is processedthrough the partner pslow, while sfast implements a ‘faster’ service provided when the request arrivesthrough pfast. Additionally, the naming mechanism allows the names composing an endpoint to be dealtwith separately, as in a request-response interaction, where usually the service provider knows the nameof the response operation, but not the partner name of the service it has to reply to. For example, the‘ping’ service p • oreq?〈x〉.x • ores!〈“I live′′〉 will know at run-time the partner name for the replyactivity. This mechanisms is also sufficiently expressive to support implementation of explicit locations:a located service can be represented by using a same partner for all its receiving endpoints. Partner andoperation names can be exchanged in communication, thus enabling many different interaction patternsamong service instances. However, as in the localized π-calculus [MS04], dynamically received namescannot form the communication endpoints used to receive further invocations.

COWS−− computational entities are called services. Typically, a service creates one specific instanceto serve each received request. Instances may run concurrently. Each instance can be composed ofconcurrent threads that may offer a choice among alternative receive activities. Services could be ableto receive multiple messages in a statically unpredictable order and in such a way that the first incom-ing message triggers creation of a service instance which subsequent messages are routed to. Patternmatching is the mechanism used for correlating messages logically forming a same interaction ‘session’by means of their same contents. It permits locating those data that are important to identify serviceinstances and is flexible enough for allowing a single message to participate in multiple interaction ses-sions, each identified by separate correlation values.

Inter-service communication gives rise to substitutions of variables with values. However, to enableconcurrent instances or threads within an instance to share the state (or part of it), receive activities inCOWS−− do not bind variables. This is different from most process calculi and somewhat similar tothe update calculus [PV97]. The range of application of the substitution generated by a communication



s ::= (services)u • u′!e (invoke)

|∑l

i=0 pi • oi?wi.si (receive-guarded choice)| s | s (parallel composition)| [d] s (delimitation)| ∗ s (replication)

Figure 11: COWS−− syntax

is then regulated by the delimitation operator, that is the only binder of the calculus. Delimitation,additionally, can be used to generate fresh names (as the restriction operator of the π-calculus [MPW92]).

Syntax and informal semantics

The syntax of COWS−− is presented in Fig. 11. It is parameterized by two countable disjoint sets: theset of values (ranged over by v, v′, . . . ) and the set of ‘write once’ variables (ranged over by x, y, . . . ).The set of values is left unspecified; however, we assume that it includes the set of names, ranged overby n, m, o, p, . . . , mainly used to represent partners and operations. The language is also parameterizedby a set of expressions, ranged over by e, whose exact syntax is deliberately omitted; we just assume thatexpressions contain, at least, values and variables. We use w to range over values and variables, and bothu and d to range over names and variables. Notation · stands for tuples of objects.

Services are structured activities built from basic activities, i.e. invoke and receive, by means ofchoice among receive prefixed services, parallel composition, delimitation and replication. The onlybinding construct is delimitation: [d] s binds d in the scope s. The notions of bound/free name/variableand alpha-equivalence are defined accordingly. Terms are identified up to alpha-equivalence.

The operational semantics is defined only for closed services, i.e. services without free variables, interms of a structural congruence and of a labelled transition relation. Due to lack of space, here we onlyprovide an informal account of the semantics and refer the interested reader to [LPT07] for its formalpresentation. Invoke activities can proceed only when all the expressions in their argument can be evalu-ated, while receive activities can always proceed and can resolve choices. Communication can take placewhen two parallel services perform matching receive and invoke activities, and give rise to substitutionsfor replacing the variables argument of the receive with the corresponding values argument of the invoke.The substitution for a variable x is applied only when the delimitation for x is encountered, i.e. whenthe whole scope of the variable is determined, and to the term resulting from removing the delimitation.Execution of parallel services is interleaved, but when a communication is performed. Indeed, this mustensure that only the receive activity with greater priority progresses. That is, if more than one match-ing receive is ready to process a given invoke, then only the receive that generates the substitution with‘smaller’ domain progresses. This permits to correlate different service communications, thus implicitlycreating interaction sessions, and can be exploited to model the precedence of a service instance over thecorresponding service specification when both can process a same request.

In the sequel, we shall use 0 to denote empty choice. Moreover, we will omit trailing occurrencesof 0, writing e.g. p • o?w instead of p • o?w.0, and write [d1, . . . , dn] s in place of [d1] . . . [dn] s. We willwrite Z 4

= W to assign a symbolic name Z to the term W. We will use n to stand for the endpoint np • no

and, sometimes, we will write n for the tuple 〈np, no〉 and rely on the context to resolve any ambiguity.




The orchestration for the scenario described in the official SENSORIA case studies can be modelled bythe following COWS−− term:

[pcar] ( SensorsMonitor | Orchestrator | LocalDiscovery | Reasoner )| Bank | OnRoadRepairServices

where SensorsMonitor represents the behaviour of the low level vehicle platform. All services of thein-vehicle platform share a private partner name pcar, that is used for intra-vehicle communication and ispassed to external services (e.g. the bank service) for receiving data from them.

When a failure occurs, a signal (raised by SensorsMonitor) triggers execution of the Orchestrator, ac-tivates the corresponding recovery service and disables other incoming signals (we assume that Orchestratoris reinstalled at the end of the repairing activity).

Orchestrator 4= [x1, x2, . . .] (pcar • oengine?x1.seng + pcar • olowOil?x2.soil + . . . )

With abuse of notation, the prefix notation s1.s2 is adopted also if s1 is a structured COWS−− activity andnot a single receive to make it evident that, due to implicit synchronizations, s2 cannot start before allactivities in s1 are executed. We explicitly consider only one recovery service, that for engine failures:

seng4= [end, xloc, xlist, xok]

( ( ChargeCreditCard | RequestLocation. FindS ervices )| end?〈〉. end?〈〉.ChooseS ervices.

( OrderGarage.OrderTowTruck | RentACar ) )

seng is composed of the above COWS−− terms; seng concurrently contacts service Bank, to charge thedriver’s credit card with a security amount, and service LocalDiscovery, to get the car’s location (storedin xloc) and a list of on road services (stored in xlist). When both activities terminate (the fresh endpointend is used to appropriately synchronize their successful terminations), seng forwards the obtained list toservice Reasoner, that will choose the most convenient services by taking into account the policies andthe preferences of the driver. Finally, seng tries to order the selected services by contacting a car rentaland, concurrently, a garage and a tow truck. Such activities can all be modelled in a similar way, e.g.

FindS ervices 4= ( pcar • o f indS erv!〈xloc〉

| pcar • o f ound?〈xlist〉. end!〈〉 + pcar • onotFound?〈〉 )

Due to space limitation, we do not show the specification of the remaining components involved inthe orchestration, i.e. SensorsMonitor, LocalDiscovery, Bank, Reasoner and OnRoadRepairServices.

4.2 SOCK: Service Oriented Computing Kernel

Differently from COWS, the SOCK [BGG+06] calculus was developed not only taking inspiration buttrying to be more strongly related to the current Web Services technology. In particular, the followingaspects have been extracted:

• the interaction modalities: they directly deal with the communication patterns defined by theWSDL [ea01] specification (e.g One-Way and Request-Response);

• the workflow composition model: it deals with the emerging trend to compose services by meansof workflows experienced also in WS-BPEL [ea06];

• the computational ability: it deals with the characteristic of Web Services to provide any kind ofcomputational functionalities;



• the execution modality: it deals with the possibility to execute service sessions in a concurrent orin a sequential way;

• the correlated sessions: they cope with the characteristic of some Web Services to manage differentsessions related to different participants by means of a specific mechanisms (e.g. correlation set);

• the service state: it consists of execution state of the service, which can be a shared state amongall the service sessions or a session state that expires when the session terminates.

SOCK organises these basic Service Oriented Computing features in a stack of layers which allows forthe definition of the design life-cycle of service systems. Each layer is represented by a specific calcu-lus: the service behaviour calculus, the service engine calculus and the services system calculus. Thefirst one allows for the design of service behaviours by supplying computation and external communica-tion primitives inspired to Web Services operations and workflow operators (e.g. sequence, parallel andchoice). The service engine calculus is built on top of the former and allows for the specification of theservice declaration where it is possible to design in an orthogonal way three main features: executionmodality, persistent state flag and correlation sets. The execution modality deals with the possibility toexecute service sessions in a sequential order or concurrently; the persistent state flag allows to declareif each session (of the service engine) has its own independent state or if the state is shared among all thesessions of the same service engine. Since the interaction model is stateless the correlation sets is a mech-anism for distinguishing sessions initiated by different invokers by means of the values received withinsome specified variables. The services system calculus allows for the definition and for the reasoning onthe behaviour of the whole system (i.e. all the services involved in the application).

Syntax and layer features

The syntax of the service behaviour calculus provides the basic communication primitives, the functionalprimitive and the workflow operators. Let S ignals be a set of signal names exploited for synchronisingprocesses in parallel within a service behaviour. Let Var be a set of variables ranged over by x, y, z.We exploit the notations ~x = 〈x0, x1, ..., xi〉 and ~v = 〈v0, v1, ..., vi〉 for representing tuples of variables andvalues respectively. Let k ranges over Var ∪ Loc where Var ∩ Loc = ∅. For the sake of brevity, we donot present the syntax for representing expressions and logical conditions which are ranged over by eand χ, respectively; here we assume that they include all the arithmetic and logic operators, values andvariables.

P, Q, . . . ::= processes0 null processε outputx := e assignmentχ?P : Q if then elseP; P sequenceP|P parallel∑

i∈W εi; Pi non-det. choiceχ P iteration

ε ::= outputs output signalo@k(~x) Notificationor@k(~x, ~y) Solicit-Response

ε ::= input



s input signalo(~x) One-Wayor(~x, ~y, P) Request-Response

We denote with S C the set of all possible processes; S C is ranged over by P and Q. 0 is the null process.Outputs can be a signal s, a Notification o@k(~x) or a Solicit-Response or@k(~x, ~y) where s ∈ S ignals,o ∈ O, k ∈ Var ∪ Loc, ~x is the array of the variables which contain the information to send and ~y is thearray of variables where, in the case of the Solicit-Response, the received information will be stored. Du-ally, inputs can be an input signal s, a One-Way o(~x) or a Request-Response or(~x, ~y, P) where s ∈ S ignals,o ∈ O, ~x is the array of variables where the received information are stored whereas ~y is the array of vari-ables which contain the information to send in the case of the Request-Response; finally P is the processthat has to be executed between the request message and the response one in a Request-Response. Signalsare used for synchronising parallel threads within a service behaviour whereas One-Way, Notification,Request-Response and Solicit-Response are exploited for external communication. x := e assigns theresult of the expression e to the variable x. χ?P : Q is the if then else process, where χ is a logic condi-tion on variables. P is executed only if the condition χ is satisfied, otherwise Q is executed. P; Q, P | Qrepresent sequential and parallel composition respectively, whereas

∑+i∈W εi; Pi is the non-deterministic

choice restricted to be guarded on inputs. Such a restriction is due to the fact that we are not interestedto model internal non-determinism guarded on output processes because they do not actually model anyrelevant real language construct. Finally, χ P is the construct to model guarded iterations. It is worthnoting that simple input primitives can be programmed by setting an alternative choice with a singlebranch whose process Pi is the process 0.

The service engine calculus deals with the aspects that come into play when a behaviour is executed.A service engine is a machinery able to execute a service behaviour. When a service engine is invokeda particular instance of a service behaviour, called session, is created and executed. Since multipleinvocations can be concurrently done by different clients, it is important to define how the several sessionsare executed; they could be performed sequentially or concurrently. Such a feature is called executionmodality. Moreover, for each created session, it should be known and programmed how the service stateis managed by the different sessions. Each session could manage its own state that expires when thesession terminates or each session manage the same shared state that persist after session termination. Inthe former case the state is not persistent whereas in the latter case the state is persistent. We call thisfeature state persistence. Depending on the execution modality and the state persistence, four servicecategories are distinguished and summarised below:

1. concurrent/not persistent: they are services which concurrently execute their sessions where eachof them is equipped with its own state that expires when the session is terminated. Usually, WS-BPEL processes belong to this service category.

2. concurrent/persistent: they are services which concurrently execute their sessions. Sessions sharea common state which does not expire when session terminates but the stored information are avail-able for next session executions. Usually, services which allow for the management of databasesbelong to this service category.

3. sequential/not persistent: they are services whose sessions are forced to be executed following asequential order where each session is equipped with its own state that expires when the session isterminated. For example, a video game is accessed sequentially by each player and each game isdifferent from the previous one.

4. sequential/persistent: they are services whose sessions are forced to be executed following a se-quential order, where the state does not expire after a session termination but the stored information



are available for next session executions. A cash point machine could be considered as an exampleof service belonging to this category.

Another issue which is strongly related to the service engine calculus, is the message correlation whichdeals with the session identification within a service engine. In the case of multiple service invocations,which a set of sessions corresponds to, we need to program the engine in such a way that messagesare delivered to the right session instance. These aspects are usually in charge of the service executionengines which provide components for abstracting from these details. This is the case, for example, ofservices which exploit the SOAP communication protocol [SOA07] jointly with WS-Addressing [ea04]endpoint references. In general, it is not possible to assume that session identification is guaranteedby the execution platform and some mechanisms at the level of the application are needed. Messagecorrelation provides an application level mechanism for supporting session identification independentlyfrom the underlying executing framework.

The syntax of the service engine calculus is composed of a service declaration and a service executionenvironment. Within the service declaration it is possible to specify the service behaviour, the statepersistence, the correlation set and the execution modality whereas in the service execution environmentall the initiated service sessions will be executed.

The syntax of the service declaration follows:

U ::= P× | P•W ::= c . UD ::=!W | W∗

where P ∈ XS C is a service behaviour, flag × denotes that P is equipped with a not persistent state andflag • denotes that P is equipped with a persistent one. c is the correlation set which guards the executionof the sessions, !W denotes a concurrent execution of the sessions and W∗ denotes the fact that sessionsare executed in a sequential order. D is a service declaration. The syntax of a service engine follows:

Y ::= D[H]H ::= (P,S) | H | H

where Y is service engine and it is composed of a service declaration D and an execution environment H.H can be a service behaviour coupled with a state ((P,S)) or the parallel composition of them (H | H).

The services system calculus allows for the composition of different engines into a system. The ser-vice engines are composed in parallel and they are equipped with a location that allows us to univocallydistinguish them within the system. The calculus syntax follows:

E ::= Yl | E ‖ E

A service engine system E can be a located service engine Yl, where l is a location, or a parallel compo-sition of them. A message can be exchanged between two service engines only of an input operation andan output one with the same name are able to synchronize themselves. It is worth noting that the locationof the receiver must correspond to the location specified within the output operation primitive.


The car repair scenario is modelled in SOCK as follows:

S ystem ::= Car ‖ Bank ‖ OnRoadRepairS ervicesCar ::= Orchestrator ‖ GPS ‖ S ensorMonitor ‖ ReasonerOnRoadRepairS ervices ::= RegisterS ervice ‖ Garage ‖ TowTruck ‖ CarRental ‖ ExternalDiagnosis



The formalization of the service engine Orchestrator and the formalization of its service behaviourdenoted by OrchestratorB follow where, for the sake of brevity, we present only the branch which man-ages an engine fault:

OrchestratorB ::= engine(); EngineRepair + lowOil(); LowOilRepair

EngineRepair ::= (chargeCC@Bank(〈ccId, amount〉 , in f oB)| getLoc@GPS (〈〉 , coord)

);log@RegisterS ervice(〈coord, in f oB〉 , regId));f indS er@RegisterS ervice(〈regId, coord〉 , serList);chooseS er@Reasoner(serList, 〈gLoc, ttLoc, rLoc〉);(book@gLoc(regId, ackG); book@ttLoc(〈regId, coord〉 , ackTT )| book@rLoc(〈regId, coord〉 , ackR)

)

Orchestrator ::= (∅ . OrchestratorB×)∗[∅ . 0]

The service behaviour OrchestratorB starts with a non-deterministic choice which waits for a mes-sage from the S ensorMonitor service that signals a car fault. In this case, a session can be activated whenan engine or a low oil fault occurs by receiving a message on the operations engine or lowOil respec-tively. If the engine fault message is received the EngineRepair process is executed whereas if the lowoil message is received the LowOilRepair process is executed. The EngineRepair process, starts by con-currently invoking the bank service for performing the payment required for accessing the repair servicesand GPS of the local discovery service for retrieving the coordinates of the car; variable in f oB containsall the transaction data returned by the bank service whereas variable coord contains the coordinates.After that the orchestrator logs on the repair rgeister service RegisterS ervice by invoking operation logsending the information contained within in f oB and coord. As a response the RegisterS ervice sendsback a fresh identifier regId which will be exploited by the orchestrator for accessing the operationf indS er of the same service. The operation f indS er returns a service list (serList) which is exploitedby the reasoner (chooseS er@Reasoner(serList, 〈gLoc, ttLoc, rLoc〉)) for extracting the garage servicelocation, the tow truck service location and the renting a car service location. Finally, the orchestratorbooks the garage, the tow truck and it rents a car. Since the orchestrator has not to manage more thanone session, the service engine is deployed with no correlated variable, in a sequential order and with anot persistent state. In order to show how correlation mechanism works, in the following we present theformalization of the repair register service where we denote the service behaviour with label B:

RegisterS erviceB ::= log(〈coord, bankIn f o〉 , id, id := genId());f indS er(〈id, coord〉 , serList, serList := find(coord))

RegisterS ervice ::=!({id} . RegisterS erviceB×)[{id} . 0]

The repair register service start its sessions by receiving a log request. As a response it returns a freshid that we assume is generated by exploiting an internal function genId(). Sessions continue waiting fora service list request on the operation f indS er. It is worth noting that the engine is deployed withconcurrent execution modality, not persistent state and correlation set equal to {id}. When initialized,variable id allows us to distinguish among all the spawned sessions. Indeed, operation f indS er requiresalso the id value in order to route the message to the right invoker initiated session.



5 Handling the unexpected

One important issue in the design and modeling of service-oriented business processes is concerned withthe formalization of programmable handlers for unexpected events, like the sudden unreachability of aservice end-point, or the expiration of a time-out, or the decision of some parties to abandon an ongoingnegotiation or conversation.

At the level of languages for WP5, where composition issues are addressed in-the-large, these issuesare inherent to transactional aspects, where many participants can be involved in the commit or abortof long running activities, and business processes in particular. As it is explained in the companionthematic deliverable Th0.2a on Advanced Calculi for Services, the transactional level includes issueslike conformance check, undoability and compensation strategies. In particular, note that, in this context,atomicity of long running transactions (LRTs) does not imply the usual “all-or-nothing” property ofdatabase transactions. Instead, LRTs rely on a weaker notion of atomicity based on compensations: adhoc, user-programmed activities to be run when recovering from partial executions of LRTs. The purposeof a compensation is to undo most of the visible actions that have been performed and, in this case, theterm “undo” does not mean to exactly reverse the effects by restoring the original state, but just to leadthe system to a sound state. For example, the late canceling of a room booking can involve some fees tobe paid, i.e., it is not possible to restore the exact situation as it was prior to the reservation.

While the languages discussed and compared in the deliverable Th0.2a provide sophisticated highlevel primitives for programming transactions and compensations, at the level of WP2, where compo-sition issues are addressed in-the-small, the needs of core mechanisms for dealing with aspects such asabort and compensation has emerged. These mechanism are typically less abstract, less constrained,more general and defined at a lower conceptual level. In particular, they are neither necessarily tailoredto establish default compensation mechanisms nor to introduce the possibility of aborting transactions.Instead they are inspired by the specific mechanism selected for grouping partners in a conversation,like correlation sets and sessions. Moreover, their correct usage is not guaranteed by the raw languagegrammar, but left to the programmer’s skills (possibly supported by domain specific patterns, whosecorrectnes can be established once and for all).

Correspondingly, the rest of this section is devoted to overview the different primitives that have beeninserted in each main family presented in sections 3 and 4. We shall again structure the presentationaccording to the two main families of core calculi, the the session-based and the correlation-based ones.

5.1 Handler mechanisms in session-based calculi

CaSPiS: please close your session before exiting

In the case of session based calculi, we have seen that the proposals permit to define private dyadicsessions between a caller (client side) and a callee (service side). In principle, each side has a protocolto execute and the conversation is concluded when both protocols terminate. On the other hand, if someunexpected event happens on one side, then the session and the corresponding partner would be stuck.This motivates the introduction of suitable primitives for handling the proper closure of a session.

These primitives might be useful to garbage-collect terminated sessions. Most important, one mightwant to explicitly program session termination, or to manage abnormal events, or timeouts. Being ses-sions units of client-server cooperation, their termination must be programmed carefully. At least, oneshould avoid situations where one side of the session is removed abruptly and leaves the other sidedangling. CaSPiS comprises a disciplined mechanism for closing sessions.

The design of CaSPis has been driven by the following guidelines:

• a partner can abandon a session at any time, by taking unilateral decision;

• a side cannot force the other side to abandon the session, unless the other side is willing to;

• a side cannot force the other side to abandon the session, unless the other side is willing to;



• if a side abandon a session, then the partner must be informed;

• in case the abandoned session contains nested subsections, then they must be abandoned as well(and their partners must be informed);

• analogy “session as transactions”: the completion of a session is seen as the default commit, theunexpected abandon of one side as a failure to be handled by the remaining partner;

• each side must be given the possibility to program suitable counteractions to be activated if thepartner abandon the session.

The above requirements have been realized by introducing suitable primitives for closing the ownsession side, for installing the own termination handler, and for signaling the own decision of closing asession to the partner.

P,Q ::= ... | sk.P | sk.P | close | k · P | †(k) | r Bk P

The idea is that upon creation of a session, one associates with the session a pair of names (k1, k2),identifying a pair of termination handlers services, one for each side (k1 · P1 specified in the servicedefinition and k2 · P2 in the service call, respectively). Then: (a) a session side is unilaterally terminatedwhen its protocol executes the command close ; (b) the execution of close triggers a signal †(k) sent tothe termination-handler service ki listening at the opposite side of the session; (c) at the same time, thesession side that has executed close will enter a special closing state denoted I P, where all subsessionsof P will be gradually closed. In order to accomplish (b) the name ki must be known to the current side ofthe session. To this end, we introduce a new syntax for sessions r Bk P where the subscript k refers to thetermination handler of the opposite side. To sum up the above discussion, we have that r Bk

(close | P

)may evolve to †(k)| I P. Note that the operator I should stop any activity but invocations †(k) of otherhandlers. Information about termination handlers to be used is agreed upon by the two sides at invocationtime. To this purpose, the new syntax for invocation, sk1 .Q, mentions a name k1 at which the terminationhandler of the client-side is listening. Simmetrically, the new syntax service definition, sk2 .P, mentionsa name k2 at which the termination handler of the service-side is listening. Then sk1 .Q|sk2 .P can evolveto (νr)(r Bk2 Q|r Bk1 P): in this way, if Q terminates with close , the termination handler k2 of the calleewill be activated, and vice versa.

Note that the simple pattern (νk)sk.(Q|k · close ) defines a default protocol for closing the own sessionafter receiving the closure signal from the partner. As another example, the encoding of high level trans-actional constructs, such as compensation pairs S ÷ C, where S is a certain activity to be executed (e.g.a service call) and C is the corresponding compensation, could be encoded in CaSPiS as (νk)S k.(k ·C).

In the car repair scenario, termination handlers can be used, e.g., by the garage booking service tocontact different garages in the area and select the first available one.

GL 4= !(νk)garage⇒k (“reserve”, ?x, ?y).(νk1, k2, k3)(

BestRepair⇐k1 〈“reserve”, x, y〉.(?g1).return 〈“ok”, g1〉.†(k2).†(k3)|k1 · close )| CarHouse⇐k2 〈“reserve”, x, y〉.(?g2).return 〈“ok”, g2〉.†(k1).†(k3)|k2 · close )| TimeOut⇐k3 〈“time”, 10〉.(? f ).return 〈“fail”〉.†(k1).†(k2)|k3 · close )| k · close| (“pay”, ?p)

)The idea is to contact the garages concurrently, and let the first one to reply affirmatively close the

session with the other garage. A timeout is also started to terminate both sessions with the two garages iftheir replies arrive too late. The expiration of the timeout will issue the failure of the garage reservation.It is then convenient to modify the code of the crash manager so to terminate the session in case of failure:



Server I [Interruptible⇒. . . ServiceProto . . .| in � Stop().out � UrgentStop().throw]

Server I Interruptible⇐. . .ClientProto . . .| in � UrgentStop().throw

(a) (b)

Server I [Interruptible⇒try

. . . ServiceProto . . .| in � KillRequest().throw

catch out � UrgentStop().throw ]

rec Restart.try

Server I Interruptible⇐. . .ClientProto . . .| in � UrgentStop().throw

catch Restart

(c) (d)

Figure 12: Conversation Interruption Examples

G(p id, x, y) 4= garage⇐ 〈“reserve”, x, y〉(“ok”, ?g id)〈“pay”, p id〉return 〈“garage”, g id〉+

(“fail”)return 〈“fail”〉close

CSCC: Primitives for exception signaling and handling

The Conversation Calculus introduce two primitives to model general exceptional behavior, in particularfault signaling, fault detection, and resource disposal (such as proper session or conversation termina-tion). We recover the classical try − catch− and throw−, adapted to a concurrent setting. The primitiveto signal exceptional behavior is

throw.Exception

This construct throws an exception with continuation the process Exception, and has the effect of forcingthe termination of all other processes running in all enclosing contexts, up to the point where a try−catchblock is found (if any). The continuation Exception will be activated when (and if) the exception is caughtby such an exception handler. The exception handler construct

try P catch Handler

actively allows a process P to run until some exception is thrown inside P. At that moment, all of P isterminated, and the Handler handler process, which is guarded by try−catch, is activated, concurrentlywith the continuation Exception of the throw.Exception that originated the exception, in the context of agiven try−catch− block. By exploiting the interaction potential of the Handler and Exception processes,one may represent many adequate recovery and resource disposal protocols.

In Figure 12, the code fragments (a) and (b) show how session abortion can be tackled in CSCC bydefining appropriate handlers on both server and client endpoints. Dropping a Stop message inside theserver endpoint causes an UrgentStop message to be sent to the client endpoint. Upon synchronization onthe UrgentStop message, both endpoints will abort by throwing an exception. Notice that this behaviormay happen concurrently with any ongoing interactions between ServiceProto and ClientProto.

The decision to terminate the ongoing remote interactions shown in the previous example is encodedwithin the service. However, the combination of the exception handling primitives with the communica-tion message passing primitives allows for may different abortion and recovering protocols to be defined.



For example, in Figure 12 (c) we show a variation of the previous example, where the decision to ter-minate the ongoing service instance now comes from the external hosting environment of the serviceendpoint: the service provider may terminate any ongoing instance of the Interruptible service by drop-ping a message KillRequest in the endpoint’s context. Notice that each connected client will be signaledafter the corresponding server endpoint has aborted.

In Figure 12 (d) we show a possible pattern for the client side, where the recursion guarantees a retryin case of failure, while terminated sessions get garbage collected by the try catch block. In [CVS07]more examples involving the use of the exception handling are presented, including a mechanism toencode compensatable transactions, in the style of [BHF04].

5.2 Handler mechanisms in correlation-based calculi

COWS: to kill and to protect

In the case of correlation sets, the scope of a conversation and the involved partners are not explicitin the term, as they mainly arise from the analysis of previous communications. Still, the primitivefor delimitation introduces a naming mechanism for the scope of certain local activities, that mightbe interpreted as the partner of some conversations (not necessarily just one). Then it is possible toassociate with such scopes suitable termination primitives. The principles exploited by COWS to enrichCOWS−− with primitives to deal with loosely coupling in service oriented computing for guaranteeingtransactional properties of services include:

• the possibility to force immediate termination of concurrent threads within a named scope (killactivities);

• the possibility to preserve intact and running some sensitive sub-activities when their enclosingdelimitaton scope is abruptly terminated (protection operator);

• the possibility to program ad hoc fault and compensation handlers;

• the possibility to program the termination of activities that are correlated to a locally terminatedactivity.

The syntax of COWS that extends the given for COWS−− in Fig. 4.1 with

s ::= ... | kill(k) | {|s|}

Beside the sets of values and variables, we also use the set of (killer) labels (ranged over by k, k′, . . .).Notably, killer labels are not (communicable) values and cannot occur within expressions. We still use wto range over values and variables, u to range over names and variables, while we will use d to range overkiller labels, names and variables. Activity kill(k) forces termination of all unprotected parallel servicesinside an enclosing [k] (that stops the killing effect). We want to remark that kill activities are executedeagerly and that the scope of names and variables can be extended (alike that of restricted names in theπ-calculus), but that of killer labels cannot. Sensitive code can be protected from killing by putting itinto a protection {| |}; this way, {|s|} behaves like s.

Rewriting seng for our sample scenario above, when finding services fails, concurrent threads mustbe terminated, while possibly refund activities must be protected.

seng4= [end, xloc, xlist, xok, k]

( ( {|ChargeCreditCard|} | RequestLocation. FindS ervicesAndRe f und )| end?〈〉. end?〈〉.ChooseS ervices.

( OrderGarage.OrderTowTruck | RentACar ) )



FindS ervicesAndRe f und 4= ( pcar • o f indS erv!〈xloc〉

| pcar • o f ound?〈xlist〉. end!〈〉 + pcar • onotFound?〈〉.Re f und )

Re f und 4= ( kill(k) | {|pbank • ore f und!〈xok, pcar〉|} )

Notably, a refunding activity is only possible when the operation ocheckOK within service ChargeCreditCardsucceeds and initializes the control variable xok.

SOCK: dynamic handler installation

In the case of SOCK, the kinds of handlers taken into account and the delimitation of their scopes w.r.t.the running code has been inspired by BPEL. The main distinguishing feature is that SOCK allowsfor sophisticated dynamic installation and updating of such handlers. The main principles driving theextension of SOCK with mechanisms for fault and compensation handling are:

• the distinction between fault handlers and termination/compensation handlers (the compensationhandler is implicitly defined as the latest installed termination handler);

• the possibility to associate handlers to any portion of code using the scope construct;

• the possibility to dynamically define and update handlers;

• the occurrence of a fault inside a request-response pattern triggers the corresponding fault on theclient side.

Correspondingly, the syntax is extended as follows:

P,Q ::= ... | inst(H) | {P : H}q | throw( f ) | comp(q) | cH

We useH to denote a function from the (disjoint) domains of Faults and Scopes names to processes.We consider two kinds of handlers: fault handlers to deal with an internal fault and termination/-

compensation handlers to deal with compensations of an activity in case of an external fault. Handlersare installed by the primitive inst(H) where H is a partial function from faults and scope names to pro-cesses. The construct {P : H}q defines a process P that runs within a scope named q, with H definingthe currently installed handlers. Commands throw( f ) and comp(q) respectively raise fault f and ask tocompensate scope q. Finally, cH allows to refer to the previously installed handler in the expressions forhandler updates.

To illustrate the expressiveness of the dynamic installation of handlers, consider the process P ≡{true orr@z(~y, ~x)H ; inst([q 7→ C|cH]) : H0}q, where H0 is a function undefined on all fault namesand defined as 0 for all scope names. The process P repeatedly invokes the service or (using the request-response modality) and install as many compensations C as are the call to or. As soon as the first fault isarised by or, all the installed C are executed in parallel. Such a dynamic mechanism is difficult to encodein all previously discussed frameworks, where handlers are allocated statically.

6 Conclusion

We have reported the main activities conducted on the development of new linguistic tools for servicesspecification and verification by taking into account both abstract specification and more detailed one thatpermit analyzing and verifying properties of the considered services. To enable the reader to appreciatethe differences between the used formalisms, we consider a simple case study (a car repair service) as arunning example.

The formalisms presented here will be the basis for developing new techniques for qualitative andquantitative analysis of services. Thus, we plan to develop, with a collaboration between WP2 and



WP3, type systems for the core calculi and to extend these and their generalization with features (e.g.stochastic variants) that permit assessing quantitative aspects of services. Moreover, we will study thework on the deployment of services by considering the issues of implementability of the calculi withinWP6. Moreover, we have already started considering stochastic variants of the considered calculi incollaboration with WP4. Indeed, it will be the outcome of these extensions that will guide us towards theselection of the appropriate calculus for SOC.

Another issue that we will touch is the development of (semi-)automatic semantic preserving trans-formations from some of the abstract languages developed in WP1 (e.g. SRML) and some of the calculideveloped in WP2 (e.g. CaSPiS or COWS).

7 Relevant Papers

This deliverable is mainly based on the following papers.

[ABFL07] J. Abreu, L. Bocchi, J. Luiz Fiadeiro, and A. Lopes. Specifying and composing interactionprotocols for service-oriented system modelling. In Formal Methods for Networked andDistributed Systems (FORTE), LNCS, Springer, 2007. To appear.

[BBDL07] M. Boreale, R. Bruni, R. De Nicola, and M. Loreti. A service oriented process calculuswith sessioning and pipelining. Technical report, 2007. Draft.

[BBC+06] M. Boreale, R. Bruni, L. Caires, R. De Nicola, I. Lanese, M. Loreti, F. Martins, U. Mon-tanari, A. Ravara, D. Sangiorgi, V. Vasconcelos, and G. Zavattaro. Scc: a service centeredcalculus. In Web Services and Formal Methods, Third International Workshop, WS-FM2006, volume 4184 of Lecture Notes in Computer Science, pages 38–57. Springer, 2006.

[BGG+06] N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Sock: a calculus for serviceoriented computing. In Proc. of 4th Int. Conf. on Service-Oriented Computing, volume4294 of Lect. Notes in Comput. Sci. Springer, 2006.

[Cai06] L. Caires. Spatial-Behavioral Types for Distributed Services and Resources. In U. Mon-tanari and D. Sanella, editors, Proceedings of the Second International Symposium onTrustworthy Global Computing, Lecture Notes in Computer Science. Springer-Verlag,2006.

[CVS07] L. Caires, H. T. Vieira, and J. C. Seco. A Model of Service Oriented Oriented Computa-tion. TR-DI/FCT/UNL 6/07, Universidade Nova de Lisboa, 2007.

[DeN07] R. De Nicola Session Centered Calculus for Service Oriented Computing (Invited Talk)Proc. 10th Italian Conference on Theoretical Computer Science. pages 6-10, World Sci-entific, 2007.

[GMRMS07] S. Gorton, C. Montangero, S. Reiff-Marganiec, and L. Semini. StPowla: SOA, Policiesand Workflows. In 3rd Int. Workshop on Engineering Service-Oriented Applications:Analysis, Design, and Composition, Vienna, Sept 17 2007.

[LPT07] A. Lapadula, R. Pugliese, and F. Tiezzi. A calculus for orchestration of web services. InESOP, volume 4421 of Lect. Notes in Comput. Sci., pages 33–47. Springer, 2007.

[LVMR07] I. Lanese, V. T. Vasconcelos, F. Martins, and A. Ravara. Disciplining Orchestration andConversation in Service-Oriented Computing. In 5th IEEE International Conference onSoftware Engineering and Formal Methods, pages 305–314, 2007.



[WCG+06] M. Wirsing, A. Clark, S. Gilmore, M. Holzl, Al. Knapp, N. Koch, and A. Schroeder.Semantic-Based Development of Service-Oriented Systems. In E. Najn et al., editor,Proc. 26th IFIP WG 6.1 Internat. Conf. on Formal Methods for Networked and DistributedSystems (FORTE’06), Paris, France, volume 4229 of LNCS, pages 24–45. Springer, 2006.



References

[ABFL07] Joao Abreu, Laura Bocchi, Jose Luiz Fiadeiro, and Antonia Lopes. Specifying and com-posing interaction protocols for service-oriented system modelling. In Formal Methodsfor Networked and Distributed Systems (FORTE), LNCS. Springer, 2007. To appear.

[BBC+06] Michele Boreale, Roberto Bruni, Luıs Caires, Rocco De Nicola, Ivan Lanese, MicheleLoreti, Francisco Martins, Ugo Montanari, Antonio Ravara, Davide Sangiorgi, Vasco Vas-concelos, and Gianluigi Zavattaro. Scc: a service centered calculus. In Web Services andFormal Methods, Third International Workshop, WS-FM 2006, volume 4184 of LectureNotes in Computer Science, pages 38–57. Springer, 2006.

[BBDL07] Michele Boreale, Roberto Bruni, Rocco De Nicola, and Michele Loreti. A service orientedprocess calculus with sessioning and pipelining. Technical report, 2007. Draft.

[BDF06] M. Bartoletti, P. Degano, and G. Ferrari. Types and effects for secure service orchestra-tion. In Proc. of 19th IEEE Computer Security Foundations Workshop (CSFW’06) (2006),pages 57–69, 2006.

[BFGS06] M. Banci, A. Fantechi, S. Giannini, and F. Santanni. Automotive Case Study: a UMLDescription Scenario. Technical report, Sensoria, 2006.

[BGG+06] N. Busi, R. Gorrieri, C. Guidi, R. Lucchi, and G. Zavattaro. Sock: a calculus for serviceoriented computing. In Proc. of 4th Int. Conf. on Service-Oriented Computing, volume4294 of Lect. Notes in Comput. Sci. Springer, 2006.

[BHF04] M. J. Butler, C. A. R. Hoare, and C. Ferreira. A trace semantics for long-running transac-tions. In A. E. Abdallah, C. B. Jones, and J. W. Sanders, editors, 25 Years CommunicatingSequential Processes, volume 3525 of Lecture Notes in Computer Science, pages 133–150. Springer, 2004.

[Bis04] Stefano Bistarelli. Semirings for Soft Constraint Solving and Programming. LNCS 2962.Springer, Berlin, 2004.

[BMR97] Stefano Bistarelli, Ugo Montanari, and Francesca Rossi. Semiring-based constraint satis-faction and optimization. J. ACM, 44(2):201–236, 1997.

[Cai06] L. Caires. Spatial-Behavioral Types for Distributed Services and Resources. In U. Mon-tanari and D. Sanella, editors, Proceedings of the Second International Symposium onTrustworthy Global Computing, Lecture Notes in Computer Science. Springer-Verlag,2006.

[CM03] Marco Carbone and Sergio Maffeis. On the expressive power of polyadic synchronisationin π-calculus. Nordic J. of Computing, 10(2):70–98, 2003.

[CVS07] L. Caires, H. T. Vieira, and J. C. Seco. A Model of Service Oriented Oriented Computa-tion. TR-DI/FCT/UNL 6/07, Universidade Nova de Lisboa, 2007.

[ea01] Erik Christensen et al. Web services description language (wsdl) 1.1. Technical report,2001.

[ea04] Don Box et al. Web services addressing. Technical report, 2004.

[ea06] A. Alves et al. Web Services Business Process Execution Language Version 2.0. Technicalreport, OASIS, 2006.



[FGS06] G. Ferrari, R. Guanciale, and D. Strollo. Jscl: a middleware for service coordination. InProc. of FORTE’06, volume 4229 of Lect. Notes in Comput. Sci., pages 46–60. Springer,2006.

[FLB06a] J. L. Fiadeiro, A. L., and L. Bocchi. A formal approach to service component architecture.In M. Bravetti, M. N., and G. Zavattaro, editors, Web Services and Formal Methods, ThirdInternational Workshop,WS-FM 2006 Vienna, Austria, September 8-9, 2006, Proceedings,volume 4184 of Lecture Notes in Computer Science, pages 193–213. Springer-Verlag,2006.

[FLB06b] Jose Luiz Fiadeiro, Antonia Lopes, and Laura Bocchi. A formal approach to servicecomponent architecture. In Web Services and Formal Methods, volume 4184 of LNCS,pages 193–213. Springer, 2006.

[GMRMS07] S. Gorton, C. Montangero, S. Reiff-Marganiec, and L. Semini. StPowla: SOA, Policiesand Workflows. In 3rd Int. Workshop on Engineering Service-Oriented Applications:Analysis, Design, and Composition, Vienna, Sept 17 2007.

[HVK98] K. Honda, V. T. Vasconcelos, and M. Kubo. Language primitives and type discipline forstructured communication-based programming. In Proc. of ESOP’98, volume 1381 ofLect. Notes in Comput. Sci., pages 122–138. Springer, 1998.

[LPT06] Alessandro Lapadula, Rosario Pugliese, and Francesco Tiezzi. A calculus for orchestra-tion of web services. Technical report, Dipartimento di Sistemi e Informatica, Universitadi Firenze, 2006. http://rap.dsi.unifi.it/cows/papers/cows-esop07-full.pdf. An extended abstract appears in Proc. of ESOP’07.

[LPT07] Alessandro Lapadula, Rosario Pugliese, and Francesco Tiezzi. A calculus for orchestra-tion of web services. In ESOP, volume 4421 of Lect. Notes in Comput. Sci., pages 33–47.Springer, 2007.

[LVMR07] Ivan Lanese, Vasco T. Vasconcelos, Francisco Martins, and Antonio Ravara. DiscipliningOrchestration and Conversation in Service-Oriented Computing. In 5th IEEE Interna-tional Conference on Software Engineering and Formal Methods, pages 305–314, 2007.

[MC07] J. Misra and W. R. Cook. Computation orchestration: A basis for wide-area computing.Journal of Software and Systems Modeling, 6(1):83–110, 2007.

[MPW92] R. Milner, J. Parrow, and J. Walker. A Calculus of Mobile Processes, I and II. Informationand Computation, 100(1):1–40, 41–77, 1992.

[MRMS07] C. Montangero, S. Reiff-Marganiec, and L. Semini. Logic-based detection of conflictsin A policies. In F. Arbab and M. Sirjani, editors, IPM International Symposium onFundamentals of Software Engineering, FSEN07, Tehran, Iran, April 17–19 2007. Toappear in LNCS, Springer.

[MS04] Massimo Merro and Davide Sangiorgi. On asynchrony in name-passing calculi. Mathe-matical Structures in Computer Science, 14(5):715–767, 2004.

[Obj06] Object Management Group (OMG). Business Process Modeling Notation (BPMN) Spec-ification, Feb 2006.

[PV97] Joachim Parrow and Bj orn Victor. The update calculus. In AMAST, volume 1349 of Lect.Notes in Comput. Sci., pages 409–423. Springer, 1997.

[Sen] Sensoria Project. Public web site. http://sensoria.fast.de/.


http://rap.dsi.unifi.it/cows/papers/cows-esop07-full.pdf

http://rap.dsi.unifi.it/cows/papers/cows-esop07-full.pdf

http://sensoria.fast.de/


[SOA07] Soap version 1.2 part 1: Messaging framework. Technical report, 2007.

[TRMB+06] K. J. Turner, S. Reiff-Marganiec, L. Blair, J. Pang, T. Gray, P. Perry, and J. Ireland. Policysupport for call control. Computer Standards and Interfaces, 28(6):635–649, 2006.

[vdAtKB03] W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski, and A. P. Barros. Work-flow patterns. Distributed and Parallel Databases, 14(1):5–51, 2003.

[WCG+06] Martin Wirsing, Allan Clark, Stephen Gilmore, Matthias Holzl, Alexander Knapp, NoraKoch, and Andreas Schroeder. Semantic-Based Development of Service-Oriented Sys-tems. In E. Najn et al., editor, Proc. 26th IFIP WG 6.1 Internat. Conf. on Formal Meth-ods for Networked and Distributed Systems (FORTE’06), Paris, France, volume 4229 ofLNCS, pages 24–45. Springer, 2006.


Th0. 1. a: SENSORIA languages and calculi for modelling services

Documents