Reliable, Secure, and Transacted Web Service Compositions with AO4BPEL

Web service compositions in BPEL have several nonfunctional requirements such as security, reliable messaging, and transactions. Although many WS-* specifications address such non-functional concerns in the Web service context, they focus only on the messaging-level requirements without addressing the process-level requirements. In this paper, we discuss different non-functional requirements in BPEL workflows and observe that current orchestration engines lack support for the specification and enforcement of such requirements, especially for process-level requirements. To solve this problem, we present a container framework, which introduces an XML-based deployment descriptor to specify the non-functional requirements in a declarative way. To enforce these requirements, a process container intercepts the process execution and calls dedicated middleware Web services. We implemented the process container as a lightweight container using a set of A04BPEL aspects that are automatically generated from the deployment descriptor. In addition, we have implemented BPEL middleware Web services for reliable messaging, security, and transactio

Coordination fiable de services de données à base de politiques actives

We propose an approach for adding non-functional properties (exception handling, atomicity, security, persistence) to services' coordinations. The approach is based on an Active Policy Model (AP Model) for representing services' coordinations with non-functional properties as a collection of types. In our model, a services' coordination is represented as a workflow composed of an ordered set of activities, each activity in charge of implementing a call to a service' operation. We use the type Activity for representing a workflow and its components (i.e., the workflow' activities and the order among them). A non-functional property is represented as one or several Active Policy types, each policy composed of a set of event-condition-action rules in charge of implementing an aspect of the property. Instances of active policy and activity types are considered in the model as entities that can be executed. We use the Execution Unit type for representing them as entities that go through a series of states at runtime. When an active policy is associated to one or several execution units, its rules verify whether each unit respects the implemented non-functional property by evaluating their conditions over their execution unit state, and when the property is not verified, the rules execute their actions for enforcing the property at runtime. We also proposed a proof of concept Active Policy Execution Engine for executing an active policy oriented workflow modelled using our AP Model. The engine implements an execution model that determines how AP, Rule and Activity instances interact among each other for adding non-functional properties (NFPs) to a workflow at execution time. We validated the AP Model and the Active Policy Execution Engine by defining active policy types for addressing exception handling, atomicity, state management, persistency and authentication properties. These active policy types were used for implementing reliable service oriented applications, and mashups for integrating data from services.Nous proposons une approche pour ajouter des propriétés non-fonctionnelles (traitement d'exceptions, atomicité, sécurité, persistance) à des coordinations de services. L'approche est basée sur un Modèle de Politiques Actives (AP Model) pour représenter les coordinations de services avec des propriétés non-fonctionnelles comme une collection de types. Dans notre modèle, une coordination de services est représentée comme un workflow compose d'un ensemble ordonné d'activité. Chaque activité est en charge d'implante un appel à l'opération d'un service. Nous utilisons le type Activité pour représenter le workflow et ses composants (c-à-d, les activités du workflow et l'ordre entre eux). Une propriété non-fonctionnelle est représentée comme un ou plusieurs types de politiques actives, chaque politique est compose d'un ensemble de règles événement-condition-action qui implantent un aspect d'un propriété. Les instances des entités du modèle, politique active et activité peuvent être exécutées. Nous utilisons le type unité d'exécution pour les représenter comme des entités dont l'exécution passe par des différents états d'exécution en exécution. Lorsqu'une politique active est associée à une ou plusieurs unités d'exécution, les règles vérifient si l'unité d'exécution respecte la propriété non-fonctionnelle implantée en évaluant leurs conditions sur leurs états d'exécution. Lorsqu'une propriété n'est pas vérifiée, les règles exécutant leurs actions pour renforcer les propriétés en cours d'exécution. Nous avons aussi proposé un Moteur d'exécution de politiques actives pour exécuter un workflow orientés politiques actives modélisé en utilisant notre AP Model. Le moteur implante un modèle d'exécution qui détermine comment les instances d'une AP, une règle et une activité interagissent entre elles pour ajouter des propriétés non-fonctionnelles (NFP) à un workflow en cours d'exécution. Nous avons validé le modèle AP et le moteur d'exécution de politiques actives en définissant des types de politiques actives pour adresser le traitement d'exceptions, l'atomicité, le traitement d'état, la persistance et l'authentification. Ces types de politiques actives ont été utilisés pour implanter des applications à base de services fiables, et pour intégrer les données fournies par des services à travers des mashups

Formalising non-functional requirements embedded in user requirements notation (URN) models

The growing need for computer software in different sectors of activity, (health, agriculture, industries, education, aeronautic, science and telecommunication) together with the increasing reliance of the society as a whole on information technology, is placing a heavy and fast growing demand on complex and high quality software systems. In this regard, the anticipation has been on non-functional requirements (NFRs) engineering and formal methods. Despite their common objective, these techniques have in most cases evolved separately. NFRs engineering proceeds firstly, by deriving measures to evaluate the quality of the constructed software (product-oriented approach), and secondarily by improving the engineering process (process-oriented approach). With the ability to combine the analysis of both functional and non-functional requirements, Goal-Oriented Requirements Engineering (GORE) approaches have become de facto leading requirements engineering methods. They propose through refinement/operationalisation, means to satisfy NFRs encoded in softgoals at an early phase of software development. On the other side, formal methods have kept, so far, their promise to eliminate errors in software artefacts to produce high quality software products and are therefore particularly solicited for safety and mission critical systems for which a single error may cause great loss including human life. This thesis introduces the concept of Complementary Non-functional action (CNF-action) to extend the analysis and development of NFRs beyond the traditional goals/softgoals analysis, based on refinement/operationalisation, and to propagate the influence of NFRs to other software construction phases. Mechanisms are also developed to integrate the formal technique Z/Object-Z into the standardised User Requirements Notation (URN) to formalise GRL models describing functional and non-functional requirements, to propagate CNF-actions of the formalised NFRs to UCMs maps, to facilitate URN construction process and the quality of URN models.School of ComputingD. Phil (Computer Science