European Community under the “Information Society Technologies”

Sensoria016004Software Engineering for Service-OrientedOverlay Computers D2.1.a:Core calculi for Service Oriented Computing Lead contractor for deliverable:UNIBO,Universit`a di BolognaAuthor(s):G.L.Ferrari(PISA),nese(UNIBO),R.Lucchi(UNIBO),R.Pugliese(DSIUF),and G.Zavattaro(UNIBO)Due date of deliverable:August31,2006Actual submission date:October10,2006Revision:FinalDissemination level:PUContract start date:September1,2005Duration:48monthsProject coordinator:LMUPartners:LMU,UNITN,ULEICES,UWARSAW,DTU,PISA,DSIUF,UNIBO,ISTI,FFCUL,UEDIN,ATX,TILab,FAST,BUTE,S&N,LSS-Imperial,LSS-UCLIntegrated Project funded by theEuropean Community under the“Information Society Technologies”Programme(2002—2006)Executive SummaryThe objective of Work Package2is the development of a foundational methodology for describing service specifications and for developing a discipline for their composition.This document reports on the work conducted inside the SENSORIA project on the definition of foundational calculi that rely on services as the fundamental elements for modelling applications conforming to the Service-Oriented Computing(SOC)paradigm.Relevant SOC idioms that have been considered are:service description,service invocation,service composition and orchestration.The fundamental vehicle undertaken within the project work plan is provided by the theory of process calculi,intended as the collection of linguistic constructs,tools and models that have been developed for designing,analysing,and experimenting with open components interactions.Two intertwined approaches have been followed in the design of core calculi for SOC:bottom-up and top-down.The bottom-up approach consists of electing one specific service oriented technology as the starting point,and extract from it a corresponding core model.The opposite top-down approach consists of designing an abstract model of services that do not tight to a specific technology.The advantage of the latter is that the designed calculi are general enough to be applied to different global computers on which services run.The calculi developed according to the former approach,on the other hand,will be fundamental to crosscheck whether the proposed general calculi actually adhere to the specificities of the currently available service oriented technologies.Contents1Introduction4 2Overview on the Calculi5 3SCC:Service Centered Calculus93.1Motivation (9)3.2Calculus description (9)3.3Discussion and future work (11)4SOCK:Service Oriented Computing Kernel114.1Motivation (11)4.2Calculus description (12)4.3Discussion and future work (14)5C˘o WS:Calculus for Orchestration of Web Services155.1Motivation (15)5.2Calculus description (15)5.3Discussion and future work (18)6SC:Signals Calculus196.1Motivation (19)6.2Calculus description (19)6.3Discussion and future work (21)7Relevant SENSORIA Publications and Reports22 8Conclusion and further plans221IntroductionThe main aim of Work Package2is to seek for a small set of primitives that might serve as a basis forformalising and programming service oriented applications over global computers.As an outcome of this study we describe here four different process calculi:SCC[BBC+06]which isthe result of a joint effort of four different sites(UNIBO,DSIUF,FFCUL,and PISA),SOCK[BGG+06b], C˘o WS[LPT06],and SC[FGS06a]developed in local smaller groups(UNIBO,DSIUF,and PISA,re-spectively).The advantage of working in a larger group,including different project sites,is that differentexpertises,knowledges and experiences merge.This revealed the most appropriate approach for devel-oping a general purpose service oriented calculus able to capture the essence of SOC independently ofspecific technological aspects.On the other hand,the work in smaller local groups permitted to achievemore focused calculi inspired by specific service oriented computing technologies.The research activity devoted to the definition of the core calculi was done in strict collaboration withthe group of researchers responsible for the definition of the SENSORIA ontology.In particular,the corecalculi are mainly focused on View1:Service Description for Coordination and Composition describedin the Deliverable D1.1.a where concepts such as Service,Session,and Orchestration are informallydescribed.For some of these terms,the calculi reported in this Deliverable represent a formal definitionuseful to clarify their actual meaning within the project activities.The general purpose calculus that we developed is SCC(Service Centered Calculus).SCC en-riches the name passing communication mechanism of traditional process calculi,such as theπ-calculus[MPW92],with an explicitic notion of service intended as an entity that can be invoked and that returnsvalues as the result of a client-service bidirectional interaction that we call session.One may argue thatwe could,in our analysis of service oriented computing,exploit directly theπ-calculus instead of intro-ducing yet another process calculus.According to our experience,if we use directly a communicationbased calculus such asπ-calculus,all the information pertaining to sessioning and client-service proto-cols get mixed up(if not lost)with the other communication primitives,making it difficult to reason onthe resulting processes.The motivation behind the introduction of a new calculus is that a small set ofwell-disciplined primitives will favor and make more scalable the development of typing systems andproof techniques centered around the notions of service and session,for ensuring,e.g.,compatibility ofclient and service behaviour,or the absence of deadlock in service composition.The other calculi are directly inspired by some specific technology.SOCK(Service Oriented Computing Kernel)proposes a three layered calculus inspired by theWeb services protocol stack.The service description layer consists of a simple calculus for serviceinterface description which takes inspiration from WSDL[W3Cc]and the abstract fragment of WS-BPEL[BCG+05].At the service engine layer,additional information can be added that indicates how aservice is actually run;this layer is inspired by the full(executable)WS-BPEL language.Finally,at theservice network layer,the modeling of an overall network of interacting services is permitted;the source of inspiration at this level is given by the SOAP[BEK+]protocol for message exchange among Web services.C˘o WS(Calculus for Orchestration of Web Services)considers in a more detailed manner WS-BPEL, the most credited service orchestration language.In particular,more expressive linguistic constructs are considered such as those permitting to interrupt arbitrarily complex processes and activate the needed compensation activities.Finally,SC(Signals Calculus)considers publish/subscribe service interaction instead of messagebased client-service communication.Publish/subscribe is an important paradigm that recently attracteda lot of research effort in the context of peer-to-peer interaction in structured as well as in unstructuredmobile ad hoc networks.The motivation behind the introductin of this calculus is that we intend toinvestigate the impact of service oriented computing also in this class of unstructured network.The remainder of the document is organized as follows.Section2provides an overview of themain characteristics of each calculus,focusing on their basic liguistic constructs and their similari-ties/differences.In Sections3,4,5,6we present the four calculi in more detail.For each calculuswe discuss the motivation for its introduction,its basic linguistic primitives,and the expected future work and results.We have opted for an informal and more gentle presentation of the semantics by means of examples.The advantages of the examples is that they allow us to show the different styles of pro-gramming supported by the different calculi.The formal definition of the semantics can be found in the papers attached to the document.Finally,in Section7we report some conclusive remark and we discuss how we intend to assess our proposals in the second year of SENSORIA project.2Overview on the CalculiThe aim of this section is to introduce the reader to the basic characteristics of each calculus.This permits us to give a look to the differentflavours of the calculi without going into technical details,and to discuss their similarities,differences and mainly their complementarity.Indeed,service oriented computing is a vast area and,at least during thefirst year of SENSORIA,we have found inconvenient to focus our attention on only one calculus with the risk to lose some relevant aspects.Thefirst calculus is the Service Centered Calculus SCC.It is based on some of the basic concepts of the SENSORIA ontology:Functional Description,Session,and Conversation.In SCC services are described via their functional description.This description defines how the service reacts to invocations. As an example,let us consider the service double defined as follows:double⇒(x)x+xThis service receives the value x and computes its double x+x.In SCC services are invoked sending them an invocation value,that is thefirst value passed from the client to the service.For instance,a client that invokes the service double with invocation value5is denoted as follows:double⇐5Given the above definition of the service double,this client reduces to the value10.According to this simple example,services strongly recall the notion of objects in the context of object oriented computing:the client invokes the service/object passing the actual parameter5,and the service/object produces the result10that is passed back to the client.This is only the simplest pattern of interaction in the context of service oriented computing,the so-called request-response pattern.Differ-ently from object oriented computing,in service oriented computing clients and services can interact via more complex patterns activating sessions after thefirst invocation.Within a session several values can be exchanged from the service to the client and vice versa.Moreover,also other services can be involved giving rise to a multi-party conversation.SCC permits to describe sessions specifying the protocols that are performed by clients and services. For instance,a ticket service that sells either economy or business tickets can be specified as follows:1 ticket⇒(x)if(x==economy){100.(resp)if(resp==accept)confirmelse if(resp==reject)cancel}else if(x==business){200.(resp)if(resp==accept)confirmelse if(resp==reject)cancel}The ticket service receives an invocation value that could be either economy or business.After invocation,the service communicates the corresponding price(100for economy ticket,200for business). After,the client is expected to indicate whether it accepts or rejects the offer;if it sends to the service the value accept then the ticket is confirmed,if it sends reject the ticket is cancelled.1We use an if,else if construct to make the example more readable even if this operator is not part of SCC.The specification of a client that invokes the ticket service in order to buy an economy ticket only if it costs less than110is as follows:ticket{(x)(price)if(price≤110)accept else reject}⇐economyNotice that the actual invocation value economy is reported after the⇐operator.The protocol run by the client is reported inside curly brackets and it always starts with an abstraction(x)used to refer to the actual invocation value(this will be described in more details in Section3).The simpler version of invocation a⇐v without any protocol specified inside curly backets is a shorthand notation for an invocation that simply returns thefirst value issued by the service.As already anticipated above,another interesting aspect of SCC is that other services can be invoked during the execution of a session thus giving rise to a multi-party conversation.As an example,let us consider the following travelAgency:travelAgency⇒(x)if((airplane⇐x)==ok)and((hotel⇐x)==ok)confirmelse cancelThe aim of the travelAgency is to organize a travel to a location x indicated by the client.Upon invocation the airplane and the hotel services are invoked in order to reserve an airplane ticket to the location x and a room in some hotel in the location x,respectively.If both reservations succeed,the travel is confirmed otherwise it is cancelled.SCC comprises also other more specific operators that permits,for instance,to interrupt the execu-tion of one session or to cancel/update service definitions.The interested reader canfind in Section3a more detailed description of the calculus.The SCC calculus is an abstract model that can be used to reason about concepts such as services, sessions,coonversations,etc.independently of any specific service oriented technology.In order to avoid to lose the contact with current technologies,in particular Web services,we have developed also another calculus called Service Oriented Computing Kernel SOCK.The Web services technology adds on top of the traditional Internet protocol stack new XML-based protocols that support interoperability among heterogeneous components.In particular,SOAP[BEK+] is the protocol for message exchange among Web services and WSDL[W3Cc]is the standard language for the description of the service interfaces.The WSDL language essentially permits to describe the kinds of messages that a service can receive,but it is not expressive enough to describe patterns of interaction that are more complex than,for instance,the basic request-response pattern described above. One of the main challange in the Web services area is to enrich the interface description language with behavioural information that can be effectively used to check the compatibility of services,not only at the static signature level,but also from a dynamic perspective.For instance,it could be relevant to check whether the composition of services is deadlock–free or not.SCC is not adequate to be applied directly to investigate the problem of composition of services based on their interface.Indeed,it does not provide the notion of service interface as afirst-class citizen. On the contrary,the calculus SOCK directly inspired by the Web services technology,separates the behavioural interface of services from their actual execution.We describe this separation by means of an example of service described using SOCK.Consider a service BOOK SHOP that permits to buy books on the Web.To this aim it can accept buy requests that contains,besides the client identifier,the code of the book the client is interested in.After, the service replies to the client with either a cancel(if,for instance,the book is not available)or a confirm message.On confirmation,the client indicates the credit card number for the payment;the book shop subsequently sends thefinal confirmation.The interface of the BOOK SHOP service is specifiedin SOCK as follows:BOOK SHOP=buy( client,book code );cancel@client( client,book code )+(confirm@client( client,book code,cost );payment( client,book code,credit card number );book@client( client,book code ))The basic activities in SOCK are receive and invoke operations.For instance,in the example abovecancel@client( client,book code )is an invoke operation(the overline distinguishes invoke from re-ceive operations)composed of a port name(cancel),a localization of the port(client),and a tuple ofparameters.The parameters denote variables:they are used to compose the message to be sent in thecase of invoke operations,or to store the received values in the case of receive.In order to describe morecomplex operations,sequential(;)and choice(+)composition operators can be used.The above specification is intended to be non executable.This because further information mustbe added in order to indicate how the service interface is actually run by an actual service executor.The information that must be added specifies if different instances of the same service are run either inparallel or sequentially,and how the variables are managed(they can be either persistent,that is they arekept also after the execution of a service instance,or they are volatile).An actual executor of the BOOK SHOP service can be specified as followsE BOOK SHOP=!({client,quantity} BOOK SHOP×)where!(the equivalent of the bang operator of theπ-calculus)denotes that different service instancescan be run in parallel and the subscript×indicates that variables are not persistent.Another relevant information in the specification of the E BOOK SHOP is the correlation set,givenby{client,quantity}.Correlation sets are a fundamental information in case of parallel execution ofdifferent instances of the same service.In fact,when messages are received by the executor of theservice,they must be delivered to the corresponding instance.The correlation set indicates which part ofthe message is used to identify the correct instance.Summarizing,the SOCK calculus has been developed to focus on the problem of composition ofservices not only based on the abstract protocol description(as done in SCC)but on the service interfacedescription as it happens,for instance,in the context of Web services.A more detailed presentation ofSOCK can be found in Section4.The travelAgency service reported above is a typical orchestrator,that is,a process that exploitsother already available services in order to provide a new more complex service(see the glossary in theDeliverable D1.1.a for a more detailed description of the meaning of orchestrator).In the context of Webservices,new languages called orchestration languages have been developed to program orchestrators.The most prominent orchestration language is WS-BPEL[BCG+05].This language comprises linguisticconstructs that are not usually available in process calculi.In particular,mechanisms are provided thatpermit to group operations in a so-called scope.Operations in one scope can be interrupted in case anunexpected event occurs during the execution of the scope,or they can be compensated in case a failureoccurs after the completion of the scope.Due to the high relevance of orchestration in the context of service oriented computing,we haveincluded in the core calculi of SENSORIA also a Calculus for Orchestration of Web Services(called C˘o WS),which takes directly inspiration from these new linguistic constructs of WS-BPEL.C˘o WS shares some basic aspects with SOCK,such as the notion of correlations or the exploitation of receive andinvoke operations as the basic activities,but it also comprises new operators.The main novelties areoperators that permits to define scopes,to interrupt scopes,and to protect part of the operations includedin one scope that are not affected by interruptions.We describe these basic aspects of C˘o WS by means ofan example.Consider an orchestrator that,in order to buy an airplane ticket to lisbon,contacts three differentairplane companies in order to collect their offers.This can be simply achieved putting in parallel threerequests with the three corresponding receive operations:lufthansa·req! lisbon |british·req! lisbon |alitalia·req! lisbon |lufthansa·resp? l |british·resp? b |alitalia·resp? aNote that the invoke operations are denoted with!while the receive operations with?.The above orches-trator collects in the three variables l,b,and a the three offers of Lufthansa,British Airways and Alitalia, respectively.Due to possible communication failures this orchestrator is not completely satisfactory.Indeed,if one of the replies is lost(or delayed indefinitely)the overall orchestrator will not complete due to the fact that one of the receive operations blocks.In order to overcome this problem,in C˘o WS it is possible to include the orchestrator within a scope k and use the kill(k)action in order to interrupt all pending activities:[k](lufthansa·req! lisbon |british·req! lisbon |alitalia·req! lisbon | lufthansa·resp? l .kill(k)|british·resp? b .kill(k)|alitalia·resp? a .kill(k))This enhanced version of the orchestrator interrupts pending receive operations when at least one of the receive succeeds.As afinal version of orchestrator,we assume that among the three requests there exists one,for instance Lufthansa,which is more important than the other ones in the sense that it is mandatory to wait for its offer.This can be achieved in C˘o WS using the protection operator↑↑to indicate that the interactions with Lufthansa are not interruptable.The new version of the orchestrator is:[k](↑lufthansa·req! lisbon ↑|british·req! lisbon |alitalia·req! lisbon |↑lufthansa·resp? l .kill(k)↑|british·resp? b .kill(k)|alitalia·resp? a .kill(k)) Details about C˘o WS can be found in Section5.The last calculus reported in this document is the Signals Calculus SC.It has been developed in order to investigate service composition under a different paradigm of interaction.The calculi described so far consider end-to-end interactions:one process can interact with only one service at a time.This form of communication is typical of wide area networks such as the Internet.In different contexts such as wireless mobile ad hoc networks,the absence of structure implies that clients are usually unaware of the currently available services.This requires to adopt different interaction paradigms,such as publish-subscribe,according to which a process emits requests without knowing a priori who is going to capture and replies to the request.More precisely,in the publish-subscribe paradigm,messages are emitted with an associated topic,and they are delivered to all the reachable process that previously registered their interest in the topic.SC is a calculus whose aim is to investigate service oriented computing under this alternative communication paradigm.In order to appreciate the novelty of this calculus with respect to the previous ones,we revisit the above example of orchestrator that collects the requests coming from three different aiplane companies:orchestrator[ req,lisbon :airplaneComp]∗( resp,x :response→store(x))airplaneComp lufthansa,british,alitaliaNote that only one request operation is done by emitting the message req,lisbon .This message has airplaneComp as the associated topic.The services interested in this topic that will receive the mes-sage are indicated in subscript position and they are given by the three airplane companies lufthansa, british,and alitalia.On the contrary,the superscript specifies how client reacts to the received messages;namely,when it receives messages with structure resp,x and topic response,it reacts by storing the received answer x.22We do not fully specify how the answers are actually stored;we simply denote this operation with store(x).P,Q::=0Nil|a.P Concretion|(x)P Abstraction|return a.P Return Value|a⇒(x)P Service Definition|a{(x)P}⇐Q Service Invocation|r P Session|P|Q Parallel Composition|(νa)P New NameFigure1:SCC:syntax of processes.3SCC:Service Centered Calculus3.1MotivationSCC is a calculus developed around the notions of service definition,service invocation and bi-directional sessioning.SCC has been influenced by Cook and Misra’s Orc[MC06],a basic programming model for structured orchestration of services.In particular,Orc is appealing because of its simplicity and yet great generality:its three basic composition operators can be used to model the most common workflow patterns,identified by van der Aalst et al.in[vdAtKB03].SCC has novel features for programming and composing services,while taking into account their dynamic behaviour.In particular,SCC supports explicit modeling of sessions both on client-and on service-side,including protocols executed by each side during an interaction and mechanisms for session naming and scoping,the latter inspired by theπ-calculus[MPW92].Sessions allow us to describe and reason about interaction modalities more structured than the simple one-way and request-response modalities provided by Orc and typical of a producer/consumer pattern.Moreover,in SCC sessions can be closed thus providing a mechanism for process interruption and service cancellation and update which has no counterpart in most process calculi.Summarising,SCC combines the service orientedflavour of Orc with the name passing communi-cation mechanism of theπ-calculus.3.2Calculus descriptionWithin SCC,services are seen as sort of interacting functions(and even stream processing functions) that can be invoked by clients.The syntax of(the kill-free fragment of)SCC is reported in Figure1. The operational semantics is not reported for space constraints,it can be found in[BBC+06].Service definitions take the form a⇒(x)P,where a is the service name,x is a formal parameter,and P is the actual implementation of the service.For instance,succ⇒(x)x+1(here and in the following we omit trailing0)models a service that,received an integer returns its successor.Service invocations are written as a{(x)R}⇐Q:each new value v produced by the client Q will trigger a new invocation of service a;for each invocation,an instance of the process R,with x bound to the actual invocation value v,implements the client-side protocol for interacting with the new instance of a.As an example, a client for the simple service described above will be written in SCC as succ{(x)(y)return y}⇐5: after the invocation x is bound to the argument5,the client waits for a value from the server and the received value is substituted for 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,identifies the 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 5+1|r (y)return y)(in this case,the client side makes no use of the formal parameter).The value6is computed on the service-side and then received at the client side,that reducesfirst to r return6and then to6|r 0 (where0denotes the nil process).More generally,within sessions communication is bi-directional,in the sense that the interacting protocols can exchange data in both directions.Values returned outside the session to the enclosing environment can be used to invoke other services.For instance,a client that invokes the service succ and then prints the obtained result follows:print{(z)0}⇐(succ{(x)(y)return y}⇐5).(in this case,the service print is invoked with vacuous protocol(z)0).Example1(Service orchestration)As a more significant example than those reported above,we present a simple orchestrator written in SCC whose aim is to invoke two services,collect the produced results, and then invoke a third service with those results.Assume that there are the following available services:service emailMe that expects a value and then sends it to your email address;services BBC and CNN that produce the latest news.Then the processemailMe{(−)0}⇐(BBC{(x)(y)return y}⇐•|CNN{(x)(y)return y}⇐•)will send you an email for each news item collected from either BBC or CNN.Note that we use the names•and−to denote an unused name and a binder for an unused name,respectively.The full SCC comprises also mechanisms for session interruption.The full syntax is not reported here for space constraints,but can be found in[BBC+06].Nevertheless we describe informally how the interruption mechanism can be used.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 keyword close can be used to terminate a protocol on one side and to notify the termination to a suitable handler at the partner site.For example,the above client is extended below for exploiting a suitable service fault that can handle printer failures:print{(z)0}⇐fault(succ{(x)(y)return y}⇐5)|fault⇒(code)ErrorHandling. where ErrorHandling is a protocol able to manage printer errors according to their identifier code.Suppose that P is the printer protocol and that the keyword close occurs in P.When invoked by the above client,a service-side session of the form r fault P[fault/close]is created,where fault is substituted for close.In case of printer failure the protocol P should invoke the service close(in-stantiated to fault),with an error code err as a parameter.As effect of this invocation,the whole service-side session r is destroyed.The invocation will instantiate an error recovery session that exe-cutes ErrorHandling[err/code].Example2(Service update)Session closing can be used also for service update.Consider,for in-stance,the servicesoccerWorldChampion⇒(−)brasilthat returns the name of the last winner of the soccer world championship.The service must be updated as soon as a new team becomes the new world champion.In the kill-free fragment of SCC reported in Figure1there is no way to cancel a definition and replace it with a new one.By contrast,in the full。