Monitoring and recovery for web service applications

Abstract

Web service applications are distributed processes that are composed of dynamically bounded services. In this paper, we give a definitive description of a framework for performing runtime monitoring of web service applications against behavioural correctness properties described as finite state automata. These properties specify forbidden and desired interactions between service partners. Finite execution traces of web service applications described in BPEL are checked for conformance at runtime. When violations are discovered, our framework automatically proposes adaptation strategies, in the form of plans, which users can select for execution. Our framework also allows verification of stated pre- and post-conditions of service partners and provides guarantees of correctness of the generated recovery plans.

Appendix

This appendix gives additional background information on BPEL’s activities and variables. We also provide an overview of the WSCoL subset used in this article.

1.1 BPEL activities and variables

The basic BPEL activities for interacting with partner web services are $<$receive$>, <$invoke$>$ and $<$reply$>$, which are used to receive messages, execute web services and return values, respectively. Conditional activities are used to define the control flow of the application: $<$while$>,\,<$if$>$ and $<$pick$>$. The $<$while$>$ and $<$if$>$ activities model internal choice, as conditions are expressions over process variables. The $<$pick$>$ activity is used to model external choice: the application waits for the first occurrence of one of several possible events (specified using $<$onMessage$>$), executing the activities associated to the corresponding event. The $<$pick$>$ activity completes once these activities are completed.

The structural activities $<$sequence$>$ and $<$flow$>$ are used to specify sequential and parallel composition of the enclosed activities, respectively. $<$scope$>$ is used to define nested activities. In IBM WebSphere Integration Developer v7, developers can also add $<$collaboration$>$ scopes, inspired by the work on dynamic workflows [1], which can be used to alter the application logic at runtime.

The $<$assign$>$ activity is used to update the values of variables. Assignment activities consist of multiple $<$copy$>$ rules, each with their own $<$from$>$ and $<$to$>$ parts, representing the source and destination data, respectively. $<$copy$>$ rules can include data modification expressions, e.g., $<$copy$><$from$> \mathtt{\$ i + 1} <$/from$><$to$> \mathtt{\$ i} <$/to$>\,<$/copy$>$ increments the value of $\$\mathtt{i }$ by one, but can also be simple assignments.

BPEL has both global and local variables. Global variables are available throughout the process, while local variables are only available within the $<$scope$>$ in which they are defined. Variable types can be simple or complex XSD (XML Schema Definition) types, schema elements, or WSDL message types, declared using the keywords type, element and messageType, respectively. Multiple schema elements can refer to the same complex XSD type.

Figure 17a shows the definition of the simple and complex XSD types used by the $\mathtt{{TAS}}$ application. For example, $\mathtt{fromDate }$ and $\mathtt{sourceCity }$ are of the simple XSD types $\mathtt{xsd:int }$ and $\mathtt{xsd:string }$, respectively. On the other hand, $\mathtt{tTripData }$ is a complex XSD type and includes a reference to every simple type declared in the same figure. These type definitions are then available from the BPEL process by importing the XSD file in which they are defined.

Fig. 17

a Part of the schema file $\mathtt{tas.xsd }$, showing the definition of the $\mathtt{{TAS}}$ simple and complex XSD types; b part of the WSDL file $\mathtt{tas.wsdl }$, showing the definition of the WSDL message types for the $\mathsf{bc}$ service; and c the declaration of various BPEL global variables

WSDL message types define abstract messages that can serve as the input or output of an operation, and are thus defined in the corresponding WSDL file. WSDL messages consist of one or more $<$part$>$ elements, where each $<$part$>$ is associated with an existing XSD element. For example, as shown in Fig. 17b (copy of Fig. 5a), the message type $\mathtt{in }\_\mathtt{bc }$, which is the input message for the $\mathsf{bc}$ service, consists of three parts: $\mathtt{city },\,\mathtt{fromDate }$ and $\mathtt{toDate }$.

Once the necessary variable types are defined and imported, we can declare the required BPEL variables. Figure 17c (copy of Fig. 5b) shows the definition of three variables of the $\mathtt{{TAS}}$ system: $\mathtt{tripData },\,\mathtt{inputBookCar }$ and $\mathtt{outputBookCar }$. The first variable is used to maintain the state of the application, while the second two are the input and output variables of the $\mathsf{bc}$ service. We have defined similar input and output variables for the rest of the services used by the $\mathtt{{TAS}}$ application.

1.2 WSCoL

The grammar of the WSCoL subset used in this article is given in Fig. 18, where $\mathtt{identifier }$ represents a valid BPEL variable identifier and $\mathtt{xpath }\_\mathtt{expr }$ represents a valid XPath expression. $LIT$ and $NUM$ are sets of BPEL literals and numbers, respectively, while $\mathbf{true}, \mathbf{false}, \backslash \mathbf{forall}, \backslash \mathbf{exists}, \backslash \mathbf{avg}, \backslash \mathbf{sum}, \backslash \mathbf{product}, \backslash \mathbf{min}, \backslash \mathbf{max}, \backslash \mathbf{returnInt}, \backslash \mathbf{returnBool}$, and $\backslash \mathbf{returnString}$ are terminal symbols. The full WSCoL grammar is available in [9].

Fig. 18

Grammar of the subset of the WSCoL language used in this work

In WSCoL, we can write predicates about the state of a BPEL process by accessing its internal variables using XPath expressions. For example, the expression $\$\mathtt{tripData/carBookingNo }$ retrieves the car booking number for the current trip, where $\mathtt{tripData }$ is the associated BPEL identifier and $\mathtt{/carBookingNo }$ is the XPath expression pointing to the XSD type to be queried.

External data is accessed by invoking other web services. For example, the expression

$$\begin{aligned} \begin{array}{l} \backslash \mathbf{returnInt} (\text{`}\mathtt{WSDL }\text{'}, \text{`}\mathtt{subtractDates }\text{'}, \\ \quad {(\$\mathtt{tripData/fromDate },\$\mathtt{tripData/toDate }), } \\ \quad \text{`}\mathtt{//parameters/subtractDatesResult/days \text{'}) } \end{array} \end{aligned}$$

returns the difference between the trip start and end dates as an integer. This is done by invoking the $\mathtt{subtractDates }$ service with parameters $\$\mathtt{tripData/fromDate }$ and $\$\mathtt{tripData/toDate }$, corresponding to the trip start and end dates, respectively. The difference is stored in the variable $\mathtt{//parameters/subtractDatesResult } \mathtt{/days }$, and the $\mathtt{subtractDates }$ service definition is available in a preconfigured WSDL file.

The typical Boolean, relational and mathematical operators, as well as some pre-defined functions, are used to build more complex expressions. For example, the assertion

$$\begin{aligned}&{(\$\mathtt{tripData/carBookingNo }) >= 1000} \\&\quad \&\&~ \$\mathtt{tripData/fromDate } < \$\mathtt{tripData/toDate } \end{aligned}$$

checks that the car booking number is at least four digits long and that the trip end date occurs after the trip start date.

Predicates on sets of variables are defined through the use of general quantifiers of the form $( \mathtt{Q }~ \$\mathtt{V }~ \mathtt{in }~ \mathtt{R };~ \mathtt{C })$, where $\mathtt{Q }$ is one of the quantifiers listed in Fig. 18, $\mathtt{R }$ is an XPath expression that represents a set of finite nodes, $\$\mathtt{V }$ is the identifier used to access each node, and $\mathtt{C }$ is a WSCoL predicate.

For example, the predicate

$$\begin{aligned}&(\backslash \mathbf{forall} \ \$\mathtt{L } \ \mathbf{in}\ \$ \mathtt{(outputGF/flights/flight/) }; \\&\quad \$\mathtt{(L/destCity) } == \$(\mathtt{tripData/destCity })) \end{aligned}$$

checks that all the flights returned by a $\mathsf{getFlights}$ service have the same destination city as the one stored in $\$\mathtt{tripData }$.