Describing and Reasoning on Web Services using ... - CiteSeerX

Describing and Reasoning on Web Services using Process Algebra Gwen Sala¨un, Lucas Bordeaux, Marco Schaerf DIS - Universit`a di Roma “La Sapienza” Via Salaria 113, 00198 Roma, Italia Email: salaun,bordeaux,schaerf
@dis.uniroma1.it

Abstract— We argue that essential facets of web services, and especially those useful to understand their interaction, are best described using process-algebraic notations. Web service description and execution languages such as BPEL are essentially process description languages; they are based on primitives for behaviour description and message exchange which can also be found in more abstract languages such as process algebras. One legitimate question is therefore whether the web services community can benefit from the sophisticated languages and tools developed in the process algebra area. Our investigations suggest a positive answer, and we claim that process algebras provide solutions to a number of challenges raised by the web services paradigm, among which are central issues of orchestration and choreography. We show on a case study that readily available tools based on process algebra are effective at verifying that compositions of services obtained by choreography and orchestration conform their requirements and respect properties. We suggest a general framework based on a mapping between process algebra and web services written in BPEL, and illustrate both the modelling of services by process algebra and the use of reasoning tools.

I. I NTRODUCTION Web services (WSs) are software applications which can be used through a network (intranet or Internet) via the exchange of messages based on XML standards. They are aimed at wild reusability and they are typically designed to interact with other services in order to build larger applications. This interaction can, depending on the situation, last for a short or longer duration. An example of a temporary and dynamic interaction occurs when one service contacts another one in response to an instantaneous need, like a car renting or a flight ticket (this, of course, presupposes the use of advanced search tools to enable the automatic discovery of a service matching the need). On the other extreme, interactions which involve a fixed number of services can arise when develop ping the information system of, say, a transportation company (one service for each stock and possibly each vehicle) or when a service is built by the orchestration of a well-defined number of existing services, provided an added value to their cumulated independent values (a search engine service which contacts a translation service, etc.). From a software engineering viewpoint, the construction of new services by the static or dynamic composition of This article is a revised, extended version of our homonymous paper published in the proceedings of the 2nd International Conference on Web Services, held in 2004, which were published by the IEEE. The research reported here was partially supported by Project ASTRO funded by the Italian Ministry for Research under the FIRB framework (funds for basic research).

existing services raises exciting new perspectives which can significantly impact the way industrial applications will be developed in the future — but they also raise a number of challenges. Among them is the essential problem of guaranteeing the correct interaction of independent, communicating software pieces. Due to the message-passing nature of web services interaction, many subtle errors can occur (message not received, deadlocks, incompatible behaviours1) when we put several of them together. These problems are well-known and recurrent in distributed applications, but they become even more critical in the open-end world of web services, which is ruled by the longer-term vision of “services used by services” more than by human users, and where this interaction should, ideally, be as transparent and automated as possible. This paper addresses the problems raised by the interaction of web services when they are composed together, be it in a dynamic or static way. Our proposal is, specifically, to use process algebra (PA) [5], [25] as a family of languages for formally describing the behaviour of web services. It has indeed already been argued by other authors (e.g., [24]) that WSs and their interaction are best described using process description languages, and it is clear that most emerging standards for describing and composing WSs are actually such languages — one example is BPEL4WS [1], hereafter shortened to BPEL. Being simple, abstract and formally defined, PAs make it easier to formally specify the message exchange between WSs, and to reason on the specified systems. Advanced automated tools have been developed to support both of these tasks, and we advocate their use to prevent significant errors. The two main classes of problems where process algebra can be helpful are in our opinion the following:  The development of web services raises a number of problems, much alike those encountered during the development of classical distributed systems. Process algebra can help: – During the design stage, PA can be used to describe an abstract specification of the system to be developed (a graphical front-end similar to the one described in [28] can ease this task), giving a preliminary model which can be validated by the reasoning tools, and then be used as a reference for the implementation. One can then imagine to use 1 A set of services is said to be compatible when they can interact together properly, see Section III.

A global picture of the framework we envision for the use of PA in a WS setting is shown in Fig. 1. Central to our approach is the need for sound, two-way mappings bridging the concrete layer (implementation level), the interface layer (published, XML description of the behaviour of the service) and to the most abstract one (algebraic representations used for reasoning).  It is clear that the interface layer must provide an abstract, yet faithful representation of the concrete behaviour of a service. This low-level conformance will be assumed in the paper since it goes beyond its scope. Let us

Pi−calculus...

public level (interface)

Abstract BPEL...

synthesis

edition tools graphical front−ends IDEs

refinement

private level (implementation) Java, C# , DB, Concrete BPEL...

Fig. 1.

theorem provers model checkers

mapping

WSDL, WS−CDL,

interface

verification tools

XML abstract descriptions

mapping

process algebra

CCS, LOTOS,

executable code

Abstract layer Concrete layer

a translation from the algebra into the executable language to automatically generate code skeletons. – For reverse engineering purposes, a translation in the other direction is needed to extract an algebraic description from existing web services. This allows the use of reasoning techniques to analyse running services. As a particular case, a promising way of developing a new service is through the orchestration of existing web services. In this context, the role of the new service is essentially to be a central process which sends and receives messages to/from each of the selected partners. One must guarantee that this interaction will work properly, which PA can help doing.  Choreography issues concern the interaction of web services with the other services which will use them. Choreography is a challenging problem, especially when a service establishes a dynamic, temporary transaction with a new service whose behaviour is not exactly known in advance. In this case, an abstract, process-algebraic representation of the behaviours of all participants can be used to perform the needed reasoning in an automated way. Common to orchestration and choreography problems are strong assumptions regarding the interface of the web services. When a service is published on the web, its implementation details are, of course, hidden to its users. If the interface is reduced to a list of message declarations and types, as in a WSDL file, then no information is given on the sequence of messages sent and received by the service. Such an interface allows a number of static verifications to be performed (notably type-checking), but makes it impossible to know how to interact with it and to check the dynamics of the system. As made explicit by the W3C choreography working group [37] it is now accepted that, in a near future, the interface of WSs should evolve and that a description of their observable behaviour similar to those described in the component software engineering literature [11] should be provided in addition to their sole WSDL interface. This description will be based on an XML-based standard similar to the former proposal WSCI [36] or the more recent WSCDL [35] and abstract BPEL [1]. Our proposal is thus based on the assumption that, even for existing services developed by others or found through the web, one has at hand an abstract description of their behaviour, from which a process-algebraic description can be extracted.

Our framework for the use of Process Algebra

just mention that conformance checking is an important problem which can be partially assisted by automated tools. An exciting perspective is to automatically extract interfaces from executable code (interface synthesis). An other approach is to start from the high-level specification provided by the interface and to progressively obtain an implementation of this interface by refinement [11].  The correspondence between the concrete layer (running code together with its XML-based, publicly available description) and the abstract one (process-algebraic notation), must be guaranteed by a formal mapping, which we briefly outline in the paper. This paper is structured as follows. In Section II, we introduce PA and the way we use them to describe and reason on web services. Section III investigates the use of process algebra for choreography issues on a case study, while Section IV discusses their interest for orchestration. Section V gives some guidelines to map process-algebraic descriptions from/into more concrete ones; we especially illustrate this point with CCS and WSDL/BPEL. Related work is discussed in Section VI and concluding remarks are drawn up in Section VII.

II. P ROCESS A LGEBRA ON

FOR D ESCRIBING W EB S ERVICES

AND

R EASONING

PAs [5] are formal description techniques to specify software systems, particularly those constituted of concurrent and communicating components. Numerous PAs have been proposed; well-known calculi are CCS [25], ACP [3], CSP [16] and all their extension like the -calculus [29], LOTOS [6], Promela [17] or Timed CSP [32]. These languages share the same ingredients: simple constructs to describe dynamic behaviours, compositional modelling, operational (and/or axiomatic, denotational) semantics, behavioural reasoning via model checking and process equivalences.

A. What is a Process Algebra? In this subsection, our purpose is to give a flavour of what a PA is made up of. The algebra chosen in this paper is CCS [25] whose set of operators is small yet sufficiently expressive for the presentation of our approach. 1) Basic operators: Defining processes in CCS requires to first agree on a set of action names which represent the messages used in the system, for instance askProductInfo,   
. The basic actions in CCS are to buy, cancel
, or receive a message (this is noted by simply writing its name) or to emit a message (this is written by its name prefixed by  the quote symbol, e.g.,  ). Processes are constructed as follows. A process which is terminated is written  : “do  nothing”. A process can execute a sequence of the form , where is an action and  a process: “execute then ”. A process can perform  : “execute or execute a nondeterministic choice (      ”). The coexistence of several processes whose           execution is interleaved is written (“run  in parallel”). The “ ” symbol, called parallel composition, is therefore used to define a global process made up of several subprocesses. Last2 , the restriction operator, noted   where is a process and   is a set of names, imposes that an emission of  (  ) by one subprocess of can occur only if another subprocess does a reception of the same message name (synchronisation). In practice, it is used to declare all the names on which synchronisations occur in the whole system. Here is an example of CCS process:                      


This process is the parallel composition of two simple behaviours. The first subprocess  can evolve either through  (“receive then receive the sequence of input messages    ”) or through the sequence . The second can perform   
) the sequence of output messages   . The restriction ( means that all exchanges of message must be internal to the  system: message cannot leave the system or be received from   outside the system. On the contrary, and are not restricted, which means that one can interact with the system by sending it or receiving from it any of these messages. 2) Hidden actions: In some cases we need an additional symbol  denoting hidden actions.  actions allow some level of abstraction in the description of the processes, since they can hide an arbitrarily complex sequence of actions whose details are kept private. A specification, or an interface, will typically describe part of the behaviour of the concrete process, but will allow itself to specify at some points that “here, some computation is done”, without further details. The use of  actions can in many cases be avoided, but they are needed when one process exhibits “internal non-determinism”, i.e., when its state can change due to computations executed secretly, in a non-observable way. An example of a service whose modelling requires  actions is the following:      

 



request   confirmation 

This process first receives a request. Then two different things can happen, reflecting the two possible outcomes of a hidden query to a local database or a hidden communication with other processes aimed at checking whether the request can be satisfied. Either the process checks that the request can indeed be satisfied and it moves to a state where it is ready to send a confirmation, or it finds out that there is a problem and moves to a state in which it will send a refusal. Between the preceding process and the same process where the  actions would not be explictly written, a subtle difference appears after the request has been received. If we do not write the  actions,  then another process can synchronise with  and impose its choice between the two alternatives, which hardly conforms realistic situations. With the  actions, we express the fact that the process will internally perform a computation which can give different results, and this result will determine which branch of the choice is effectively chosen. of this Making the  actions explicit in the description

process is therefore needed whenever a choice ( ) occurs, because we chose a calculus which does not make the distinction between the two types of non-determinism, one internal (the process determines which branch the computation takes) and external (the choice depends on a message sent by another process). Some process algebras define two operators

instead of the unique , but we favoured CCS because of its simplicity, and of the ability of  actions to model abstraction. 3) Operational semantics: CCS is formalised using axiomatic and operational semantics [25]. The operational semantics describes the possible evolutions of a" process; more # precisely, it defines a transition relation  meaning intuitively that “ can evolve to  in one step through action $ $ ” (where is the emission of a message, the reception of a message or a  action). This relation is defined by the set of rules presented below3 , which give a precise meaning to each operator. Note that  %actions can occur when two & processes communicate (rule ). This reflects that fact that both processes will change state, but that the action they have performed is not observable by a third party. ' () + * ) ) + * )/ ' 1 0 2 ) 32 + * ) / 32

4- ,

7 89

) + * )/ ) :6 + * ) / :6

;9
= 6 / ) :6 + ? ) / :6 /

; 9@

A 

B

For instance, the B rule states that a process $ % can evolve to a process by performing $ , and the C D rule states that a process involving a choice can evolve following one of the processes of the choice — this discards the other alternative. Let us illustrate how these rules can be used to  figure out a possible trace starting from the behaviour introduced before. A possible trace is the following:

    refusal  

2 Let us mention that two other primitives exist - the summation    and ! the renaming - but they are not used in the paper.

,-.

) + * )/ ) 56 + * )/

 # E          #      ># H F      
F G
F  3 Both

“ :” and 5 are commutative, the symmetrical rules are omitted here.

In other words, one way for the system to evolve is through a visible action, followed by an unobservable evolution (corresponding to an internalsynchronisation of the two processes of the system on action ), and ending with the emission of a  message . To understand, for instance, why the second step of this evolution is possible, let us show formally that it can be obtained by a legal application of the CCS rules: 

SEQ #   >#    F     F          #         F G          #      F    
G  


SEQ

PC2 RES

B. Specifying Web Services as Processes We already claimed that WSs are essentially processes and that any meaningful representation of services should take into account behavioural information (this need has already been pointed out by several people in the community [24], [4], [18], [1]). An essential reason behind this need is that the interaction between WSs is typically more complex than, for instance, simple (Remote) Procedure Calls, which do a job and terminate, possibly returning a value. Knowing the signature of the parameters expected by a RPC is essentially sufficient to use it, and a WSDL file would in this case be sufficient. On the contrary, a web service is very much alike an object in OO-programming in that it has an internal state which is affected by the messages it sends and receives. Some actions are possible in some states and not possible in some others, and reasoning on stateful interaction needs to keep track of the transitions performed by the system. 1) Modelling simple services: Even a simplistic service, like the basic hotel booking service shown on Fig. 2 involves complex interactions, since the service can dialogue with the caller, for instance to ask for complementary information.

proc Hotel = request.InteractionLoop proc InteractionLoop = ’askInfo.recInfo.InteractionLoop + ( ’refusal.Hotel +’acceptance.confirmation.Hotel))

The textual syntax is more adapted to proof-writing and formal reasoning, as well as to the description of large-scale systems. Graphical notations are anyway complementary and can be used by user-friendly front-ends [28]. We use them in this section for illustration purposes. 2) Using expressive process algebra: When describing software, the question of the level of details reflected by the abstract description always arises, and WSs are no exception. Behavioural aspects are unavoidable, they are the strict minimum of what needs be represented. In our opinion, there is usually little need to model implementation or networking issues (e.g., server location, URL or URI) because these concepts are too low-level and do not add to the global understanding of a system. But in some cases, other features like data or mobility allow to have a more faithful representation of a service. In all cases where messages and action names are enough, simple algebras like CCS can be recommended. Richer languages exist which can be used, for instance, to address the following needs:
Abstract data can be manipulated by algebras like LOTOS [6] or, to some extent, Promela [17]. They are used if there is a need to describe values of message parameters, local data (attached to a specific WS), or predicates guarding a piece of behaviour. In the case of a business trip, we can imagine a WS whose task is to book a hotel (among several ones) while respecting a limit price which guards the application of some of the actions (Fig. 3). recLimit

[p>lp] askPrice

[p