Optimizing Computation of Recovery Plans for BPEL Applications

Web service applications are distributed processes that are composed of dynamically bounded services. In our previous work [15], we have described a framework for performing runtime monitoring of web service against behavioural correctness properties (described using property patterns and converted into finite state automata). These specify forbidden behavior (safety properties) and desired behavior (bounded liveness properties). Finite execution traces of web services described in BPEL are checked for conformance at runtime. When violations are discovered, our framework automatically proposes and ranks recovery plans which users can then select for execution. Such plans for safety violations essentially involve "going back" - compensating the executed actions until an alternative behaviour of the application is possible. For bounded liveness violations, recovery plans include both "going back" and "re-planning" - guiding the application towards a desired behaviour. Our experience, reported in [16], identified a drawback in this approach: we compute too many plans due to (a) overapproximating the number of program points where an alternative behaviour is possible and (b) generating recovery plans for bounded liveness properties which can potentially violate safety properties. In this paper, we describe improvements to our framework that remedy these problems and describe their effectiveness on a case study.Comment: In Proceedings TAV-WEB 2010, arXiv:1009.330

Automated Analysis and Implementation of Composed Grid Services

Service composition allows web services to be combined into new ones. Web service composition is increasingly common in mission-critical applications. It has therefore become important to verify the correctness of web service composition using formal methods. The composition of grid services is a similar but new goal. We have previously developed an abstract graphical notation called CRESS for describing composite grid services. We have demonstrated that it is feasible to automatically generate service implementations as well as formal specifications from CRESS descriptions. The automated service implementations use orchestration code in BPEL, along with the service interfaces and data types in WSDL and XSD respectively for all services. CRESS-generated BPEL implementations currently do not useWSRF features such as implicit endpoint references for WS-Resources and interfacing to standard WSRF port types. CRESS-generated formal models use the standardised process algebra LOTOS. Service behaviour is modelled by processes, while service data types are modelled as abstract data types. Simulation and validation of the generated LOTOS specifications can be performed. In this paper, we illustrate how CRESS can be further extended to improve its generation of service compositions, specifically for WSRF services implemented using Globus Toolkit 4. We also show how to facilitate use of the generated LOTOS specifications with the CADP toolbox

A Rigorous Methodology for Composing Services

Creating new services through composition of existing ones is an attractive option. However, composition can be complex and service compatibility needs to be checked. A rigorous and industrially-usable methodology is therefore desirable required for creating, verifying, implementing and validating composed services. An explanation is given of the approach taken by CRESS (Communication Representation Employing Systematic Specification). Formal verification and validation are performed through automated translation to LOTOS (Language Of Temporal Ordering Specification). Implementation and validation are performed through automated translation to BPEL (Business Process Execution Logic) and WSDL (Web Services Description Language). The approach is illustrated with an application to grid service composition in e-Social Science

Service adaptation with probabilistic partial models

Web service composition makes use of existing Web services to build complex business processes. Non-functional requirements are crucial for the Web service composition. In order to satisfy non-functional requirements when composing a Web service, one needs to rely on the estimated quality of the component services. However, estimation is seldom accurate especially in the dynamic environment. Hence, we propose a framework, ADFlow, to monitor and adapt the workflow of the Web service composition when necessary to maximize its ability to satisfy the non-functional requirements automatically. To reduce the monitoring overhead, ADFlow relies on asynchronous monitoring. ADFlow has been implemented and the evaluation has shown the effectiveness and efficiency of our approach. Given a composite service, ADFlow achieves 25 %–32 % of average improvement in the conformance of non-functional requirements, and only incurs 1 %–3 % of overhead with respect to the execution time.No Full Tex

Rigorous Development of Composite Grid Services

CRESS (Communication Representation Employing Systematic Specification) is introduced as notation, a methodology and a toolset for service development. The article focuses on rigorous development of composite grid services, with particular emphasis on the principles behind the methodology. A straightforward graphical notation is used to describe grid services. These are then automatically specified, analysed and implemented. Analysis includes formal verification of desirable service properties, formal validation of test scenarios, testing of implementation functionality, and evaluation of implementation performance. The case study that illustrates the approach is document content analysis to compare two pieces of text. This involves two composite services supported by two partner services. The usability of the service design notation is assessed, and a comparison is made of the approach with similar ones. These show that the CRESS approach to developing services is usable and more complete than other comparable approaches

Workflows for Quantitative Data Analysis in The Social Sciences

The background is given to how statistical analysis is used by quantitative social scientists. Developing statistical analyses requires substantial effort, yet there are important limitations in current practice. This has motivated the authors to create a more systematic and effective methodology with supporting tools. The approach to modelling quantitative data analysis in the social sciences is presented. Analysis scripts are treated abstractly as mathematical functions and concretely as web services. This allows individual scripts to be combined into high-level workflows. A comprehensive set of tools allows workflows to be defined, automatically validated and verified, and automatically implemented. The workflows expose opportunities for parallel execution, can define support for proper fault handling, and can be realised by non-technical users. Services, workflows and datasets can also be readily shared. The approach is illustrated with a realistic case study that analyses occupational position in relation to health

Web services recovery mechanisms

Dissertação de Mestrado em Engenharia InformáticaIn web services context it is not possible to use the usual concept of ACID transactions because of several factors. For instance, business transaction in general have a long duration that can be extended to several months or can involve the coordination and interaction of activities executed by different partners. In these cases, atomicity is not preserved, therefore the usual recovery mechanisms cannot be used, like the rollback. In business transaction, failure treatment can be made by compensation mechanisms in which are defined actions of compensation for the actions that cannot be reverted automatically. The goal of this dissertation is to define a set of patterns that represent the common use of the recovery mechanisms at business level. A graphical notation of easy comprehension will be developed to show how the recovery mechanisms work to all kind of people with different background formation

Recovery within long running transactions

As computer systems continue to grow in complexity, the possibilities of failure increase. At the same time, the increase in computer system pervasiveness in day-to-day activities brought along increased expectations on their reliability. This has led to the need for effective and automatic error recovery techniques to resolve failures. Transactions enable the handling of failure propagation over concurrent systems due to dependencies, restoring the system to the point before the failure occurred. However, in various settings, especially when interacting with the real world, reversal is not possible. The notion of compensations has been long advocated as a way of addressing this issue, through the specification of activities which can be executed to undo partial transactions. Still, there is no accepted standard theory; the literature offers a plethora of distinct formalisms and approaches. In this survey, we review the compensations from a theoretical point of view by: (i) giving a historic account of the evolution of compensating transactions; (ii) delineating and describing a number of design options involved; (iii) presenting a number of formalisms found in the literature, exposing similarities and differences; (iv) comparing formal notions of compensation correctness; (v) giving insights regarding the application of compensations in practice; and (vi) discussing current and future research trends in the area.peer-reviewe

Vérification de processus BPEL à l'aide de promela-spin

L'objectif de notre travail de recherche est de vérifier si un processus BPEL satisfait sa spécification d'interface représentant son comportement externe en utilisant la vérification de modèles. Dans ce mémoire, nous présentons essentiellement l'approche de notre logiciel qui permet dans un premier temps de traduire un processus BPEL en modèle Promela et une expression d'interface en assertion de traces, et par la suite, il lance la vérification en utilisant l'outil Spin. Cette vérification du comportement du processus concret se fait par rapport à une spécification abstraite de son interface comportementale, c'est-à-dire, nous vérifions uniquement ce qui est visible à l'exterieur du processus. Nous expliquons les étapes franchies pour atteindre notre objectif et nous montrons à l'aide d'exemples que notre logiciel est fonctionnel