Session types for safe Web service orchestration

Jonathan Michaux, Elie Najm, Alessandro Fantechi
2013 The Journal of Logic and Algebraic Programming  
Highlights • We give a novel formal semantics of the BPEL orchestration language. • We extend BPEL to support sessions. • We provide behavioural typing of services by using typed sessions. • We provide a solution to check the well-typedness of services and service configurations. • We prove the property of safe interaction for well-typed service configurations. Abstract We address the general problem of interaction safety in Web service orchestrations. By considering an essential subset of the
more » ... PEL orchestration language, we define SeB, a session based style of this subset. We discuss the formal semantics of SeB and present its main properties. We take a new approach to address the formal semantics which is based on a translation into so-called control graphs. Our semantics accounts for BPEL control links and addresses the static semantics that prescribes the valid usage of variables. We also provide the semantics of service configurations. During a session, a client and a service can engage in a complex series of interactions. By means of the provided semantics, we define precisely what is meant by interaction safety. We then introduce session types in order to prescribe the correct orderings of these interactions. Service providers must declare their provided and required session types. We define a typing algorithm that checks if a service orchestration behaves according to its declared provided and required types. Using a subtyping relation defined on session types, we show that any configuration of well-typed service partners with compatible session types are interaction safe, i.e., involved partners never receive unexpected messages. Informal introduction to SeB Session initiation. The main novelty in SeB, compared to BPEL, resides in the addition of the session initiation, a new kind of atomic activity, and in the way sessions impact the invoke and receive activities. The following is a typical sequence of three atomic SeB activities that can be performed by a client (we use a simplified syntax): s@p; s!op 1 (x); s?op 2 (y). This sequence starts by a session initiation activity, s@p, where s is a session variable and p a service location variable (this corresponds to the endpoint reference of a BPEL partnerlink). The execution of s@p by the client and by the target service (the one whose address is stored in p) has the following effects: (i) a fresh session id is stored in s, (ii) a new service instance is created on the service side and is dedicated to interact with the client, (iii) another fresh session id is created on the service instance side and is bound to the one stored in s on the client side. The second activity, s!op 1 (x), is the sending of an invocation operation, op 1 , with argument x. The invocation is sent precisely to this newly created service instance. The third activity of the sequence, s?op 2 (y), is the reception of an invocation operation op 2 with argument y that comes from this same service instance. Note that invocation messages are all one way and asynchronous: SeB does not provide for synchronous invocation. Sessions in lieu of correlation sets. The mechanism used in BPEL to relate and route distinct messages from one or more clients towards a particular service instance is called correlation. Correlation sets are application-level message fields whose values are used as a basis for correlation. Note that the purpose of both sessions and correlation sets is to maintain long-lasting interactions between process instances, but correlation sets are more implicit by nature. For example, with correlation sets, a service's lifecycle is hidden from clients, and the initiation of and reference to a specific instance of an interaction cannot be done explicitly and with any certainty. SeB does not feature correlation sets and instead relies on sessions as an explicit language
doi:10.1016/j.jlap.2013.05.004 fatcat:fdimbjgfmjgarffarwvacqvdzm