Chouki Tibermacine
email: chouki.tibermacine@lirmm.fr

Tarek Zernadji
email: zernadji@yahoo.fr

Supervising the Evolution of Web Service Orchestrations using Quality Requirements

Since many years, Web services have confirmed their status of one of the most pertinent solutions for a given service provider, like Google, Amazon or FedEx, to open its solutions for third party software development. New business logic can be implemented through orchestrations of existing Web services. This helps development teams in capitalizing resources held by the providers of these services. Nonetheless, these service-oriented software architectures, like any other software artifact, are subject to changes during their lifecycle, and thus can undergo an evolution phenomenon. In this phenomenon, it is argued that quality can be weakened after successive changes (Lehman's 7th law of software evolution), and this is mainly due to the lack of architecture documentation and tool support to supervise architecture changes. In this paper, we present an approach to supervise the evolution of Web service orchestrations, with quality requirements considered as a support documentation. First, we show how important design decisions, like the choice of a service-oriented architecture pattern can be formalized as a documentation for the quality they implement. Then, we detail how this documentation can be used to supervise architecture changes. In this way, the impact of changes made on a software architecture are analyzed on-the-fly to determine which quality is affected.

Introduction: Context and Motivation

Building distributed software by orchestrating existing Web services is a new paradigm, which has been proposed as a possible implementation for the serviceoriented architecture specification. It has been greatly influenced by the wellknown business process engineering field, where processes can be designed as collaborations between a set of services published by some providers. New business logic can thus be implemented, as an extension of existing Web services, through these orchestrations. This helps development teams in capitalizing resources held by the providers of these services. Indeed, Web service providers, which hold some precious resources (like large databases of products to retail of Amazon, or weather forecast data of Meteo France), offer third party developers the opportunity (for free or not) to build new applications by extending their public services, and thus capitalize on these resources.

Nonetheless, these service-oriented software architectures, like any other software artifact, are subject to changes during their lifecycle, and thus can be affected by the consequences of an evolution phenomenon [START_REF] Lehman | Software evolution[END_REF]. In this phenomenon, it is argued that quality can be weakened after successive changes (Lehman's 7th law of software evolution [START_REF] Lehman | Software evolution[END_REF]). This is mainly due to: i) the lack of architecture documentation that can be used by developers to better understand the design decisions made on the system, and ii) the lack of tool support to supervise architecture changes.

In this paper, we present an approach to supervise the evolution of Web service orchestrations, with quality requirements considered as a support documentation. First, we show how important design decisions, like the choice of a service-oriented architecture pattern can be formalized as a documentation for the quality they implement. Then, we detail how this documentation can be used to supervise architecture changes. In this way, the impact of changes made on a software architecture are analyzed on-the-fly to determine which quality is affected.

In the following section, we show an example that illustrates the problems which we tackle in this paper. In Section 3, we expose the overall approach that we propose in this paper to solve the identified problems. Then, in Section 4, we detail how the quality documentation is specified in our approach. This documentation is used by an evolution assistance algorithm, which is described in Section 5. Section 6 illustrates the use of our approach through an example. Before concluding this paper, we present in Section 7 the related work.

Illustrative Example

In this section we show, through an example of a Web service orchestration -a BPEL (Business Process Execution Language [START_REF]Web services business process execution language version 2[END_REF]) process, how some evolution scenarios can have consequences on quality requirements. Let us suppose that we have an Appealed Assessments System [START_REF] Erl | SOA Design Patterns[END_REF] built using Web services. This system is responsible for managing and enforcing policies that pertain to private companies involved with the forestry and lumber trade. Briefly, this service is dedicated to producing a range of reports related to already assessed claims that have been successfully or unsuccessfully appealed.

The decisions made by the architects to design this service-oriented architecture involved the use of a Data Controler service. This one provides all the logic required to fulfill the capabilities of the assessment reports service. It allows access up to six different repositories in order to gather all of the required data depending on the requested reports.

Furthermore, the architects observe that they may have to access additional databases in the future and therefore the Data Controler service have to undergo some changes. This results in a portability problem in the service architecture design. Consequently, the architects decide to design a facade service (architecture decision AD1) using the service facade pattern [START_REF] Erl | SOA Design Patterns[END_REF], to ensure the portability requirement (quality attribute QA1) into the service architecture. The facade service is named Data Relayer, and its role is to receive service consumer requests, relay them to the Data Controler service, and then relay the responses back to the service consumer. The facade service ensures the adaptation between the message format used by the Appealed Assessments Service and the data format managed by the Data Controler service. Also, it validates the reports received from the Data Controler service. The facade service decouples then the consumers of the Appealed Assements Service from the changes that may occur on the Data Controler, and compensates its behavior modifications so that the consumers are not impacted.

Preventing from unauthorised access to the ressources of the Appealed Assessments service, the architects decide to establish a service account (based on the Trusted Subsystem Pattern [START_REF] Erl | SOA Design Patterns[END_REF] (AD2)) to secure the service from direct access to the databases. The security requirement (QA2) is thus defined and implemented inside the whole service orchestration.

Let us assume now, that the maintenance team receives two changes requests. The first concerns the performance enhancement of the overall service (Appealed Assessments Service). So, the developer team proceeds by short-circuiting the authentication service account in the orchestration (removing simply the invoke activity). The architect performing this change, ignore that the usefulness of that service was also (as imposed by the Trusted Subsystem pattern) to prevent direct access to the service resources from malicious attackers. Therefore, this change breaks AD2 and thus the quality requirement that it implements (QA2).

Over the years, the company providing these services has significantly expanded, and consequently more users requested the Appealed Assessment Service. In such a highly concurrent environment, the service may manage a large amount of data and thus increasing resources consumption which may compromise the overall service performance and availability. The architects realize that the service-oriented architecture has to adapt to this scalability requirement problem keeping the performance of the service unaffected. Hence, they examine different kinds of data used by the service and find out that, the policy data remains frequently unchanged during the working days. Therefore, the architects decide (AD3) to use the Partial State Deferral Pattern [START_REF] Erl | SOA Design Patterns[END_REF] to temporarily hold a copy of data on a local database server increasing the performance of the service (QA3). This scenario implies some architectural changes: first, invoking directly the Data Controler after an authentication through the service account service; second, designing a new standardized contract for an archival service that takes the responsibility of populating the data in the database server; finally, for performance optimization purpose, moving the functionality of the Data Relayer service into the Archival service which results in removing the later from the architecture. This breaks the facade design pattern (AD1) and causes the loose of the portability quality requirement. Figure 1 shows a simple micro-process of service-oriented architecture evolution 3 . In this process, the triggers for requesting architecture evolution can be either new business requirements (for perfective evolution), bug reports (for corrective evolution) or quality enhancement (for perfective, adaptive or preventive evolution). Then the developer has to go through multiple steps, ranging from architecture comprehension to the proposition of a new architecture.

Among these steps, the developer perform some testing to check if there is a "clean" progression (verify if the additional services, operations or activities work correctly) and no regression (existing features are not negatively impacted by the additions). In this paper, we address exclusively quality-related regression testing. In practice there are few works that dealt with this aspect by proposing some automatic support. Even with the existence of such approaches, if some tests fail, the developer iterates (eventually many times) to fix the problems. She/He is asked to look for the architecture changes to be applied, and sometimes she/he is led to the step of "Architecture comprehension".

The proposed approach aims at assisting this process by notifying the developer on-the-fly if there are some architecture changes that affect quality requirements. This is illustrated in Figure 2. The approach introduces two concepts: an architecture documentation (bottom left of Figure 2) and an assistance algorithm. The assistance algorithm is used when developers apply changes on an architecture to notify them with the possible impact of their changes on quality requirements. Then, it is the developer's responsibility to validate or undo changes. If changes are validated the developer is asked to document the new decisions taken while evolving the service-oriented architecture. These two concepts are detailed in the following two sections.

Architecture Decision Documentation

The concept of architecture decision documentation has been firstly introduced in [START_REF] Tibermacine | Nfrs-aware architectural evolution of component-based software[END_REF]. In this paper, we present an improvement to the old version of this documentation. It defines in a formal way the links between architecture decisions and quality attributes implemented by these decisions. We consider thus architecture decisions, which are entities that can be formalized, as a way to indirectly check automatically quality requirements, which are properties that cannot generally be formalized directly (or are very difficult to formalize 4 ).

An architecture decision documentation abstracts the links between a given quality attribute and an architecture decision associated to this attribute. Figure 3 shows how these links are organized. We associate to a link a degree of satisfaction. An architecture decision in collaboration with other decisions contribute to the satisfaction of a given quality attribute. Each degree of satisfaction represents a percentage. In the ideal situation (where the developers are confident in the pertinence of their design decisions), the sum of all degrees associated to the same quality attribute (within the same architectural element) would be equal to 100%. For example, a portability quality attribute can be concretized by three different architecture decisions: the choice of the facade service pattern [START_REF] Erl | SOA Design Patterns[END_REF] 5 , the choice of the MVC pattern [START_REF] Buschmann | Pattern Oriented Software Architecture: A System of Patterns[END_REF] and the use of an API. If the developers consider that the two first decisions contribute more, in the concretization of the portability quality attribute, than the third one, because they are critical, they can associate to them high scores (for example 40 % to each decision) and the last architecture decision a lower score (20 % for example). This is done in the same manner as in software requirements engineering where the project manager assigns values like high, medium or low for the technical difficulty of the realization of each requirement or for their functional priority. In our case, we chose to give them numerical values voluntarily because of the complementarity which exists between architecture decisions to reach a quality goal, as illustrated in the example above. We voluntarily simplify, in this documentation, the specification of architecture decisions. An architecture decision is thus formalized by an architecture constraint (see the "Related Work" section for richer specifications of architecture decisions). Here again, a formalization degree is a percentage associated to the link between an architecture decision and an architecture constraint. This score represents the extent to which the constraint formalizes the design decision. If we consider that several constraints formalize the same architecture decision, it is possible for the developer to state how the different constraints share the formalization of the design decision. In some cases, a given constraint may have a degree of formalization more important than others. In the ideal situation (where the developers are sure of the completeness of their formalization), the sum of all degrees associated to the same architecture decision would be equal to 100%. The constraints written in a given documentation are defined with a predefined constraint language.

+
A quality attribute in this documentation is a non-functional property representing an ISO 91266 characteristic or sub-characteristic (Reliability, Maintainability, Portability, ...). It has a degree of criticality (inspired from Kazman's quality attribute scores and Clements' quality attribute priorities [START_REF] Clements | Evaluating Software Architectures, Methods and Case Studies[END_REF]) which is specified by developers and represents the importance of this quality attribute in the architecture. Its possible values are: very high, high, medium, low and very low.

Associated to a given architecture decision, a quality attribute can enhance (affect positively) other quality attributes. For example, the choice of the pipeline architecture style targets the maintainability quality attribute, which enhances in this case the efficiency attribute of the system. Contrarily, a given quality attribute can collide with (affect negatively) other quality attributes. For example, the security quality attribute collides generally with the efficiency attribute. This depends of course on the documented architecture decision and the application context. It is on the responsibility of developers, fully aware of the application's context and the architecture decisions they made, to document these optional parts (the other quality attributes that collide-with or enhance the documented quality attribute) of an architecture contract.

A given quality attribute can be tightly-or weakly-coupled to another one. In the first case, if a quality attribute A affects positively another attribute B, if we enhance A, B will B enhanced; and if A is weakened, B will be weakened too. In the second case (weakly-coupled attributes), if A affects positively another attribute B, if we enhance A, B will be enhanced; and if A is weakened, B will not be affected. Inversely, the same thing can be considered, if A affects negatively B. This is illustrated in Figure 4.

For example, in a service orchestration, adding an invocation to an encryption service before transmitting information to a remote server is a simple architecture decision taken to enhance the security quality attribute. This makes less efficient the whole orchestration (affects negatively the efficiency attribute). If we decide in another context, to remove a binding to an authentication service which is invoked before a given business service, this will obviously affect positively the efficiency quality attribute (there is less time to execute the business service). We conclude here that the two quality attributes, in the two contexts, are tightly coupled.

In another illustrative example, designing a system using the facade service design pattern aiming to enhance its portability affects negatively the reliability quality characteristic (more precisely, the availability sub-characteristic). Indeed, in the presence of a unique service providing the business service to clients, if this service crashes, the provided functionality will not be anymore available.

Let us suppose now that a given service is provided by a component within a web application in order to abstract details of the different Internet browsers in which the application is executed at the client side (portability purpose). The removal of such a service will not affect in any way the reliability attribute. This is an example of two quality attributes which are weakly coupled.

Between weakly coupled quality attributes, we identified two kinds of relationships. There can be a positive or a negative influence. In the first case (positive influence), it is the enhancement of the first attribute which influences on the second one; however in the other case, it is its weakness which produces an effect on the second. This is shown on Figure 4 In the current implementation of architecture decision documentation, architecture constraints are specified using a modified version of OMG's OCL [START_REF] Omg | Object constraint language specification, version 2.0, doc[END_REF]. An architecture constraint in this language navigates in a metamodel of BPEL Web service orchestrations, but apply to only one instance of that metamodel (a model which represents a BPEL process). The evaluation of a given constraint tells the developer whether the architecture description conforms to the constraint or not.

In addition to architecture decision documentation, we propose (as an optional feature) to build a catalog of quality attribute relationships. Designing such a catalog consists in :

1. Identifying the quality attributes defined in the quality model of the company 2. Identifying the attributes defined in the quality plan of the software project 3. Building a bi-dimensional table with all the quality attributes (one per line and one per column)

4. Completing progressively the correlation between the quality attributes (on the basis of information gathered from previous projects and the experience of developers) 5. Each time, adapting the table to the service-oriented architecture context Once this table validated by the project manager, the assistance algorithm can exploit it in accompanying developers in the architecture change step.

Change Assistance Algorithm

During architecture change, the information encapsulated in the architecture documentation is exploited by an assistance algorithm in order to assist developers. The main purpose is to drive software architecture evolution to a situation where the initially required quality is minimally affected. This algorithm is presented throughout this section as several functions. and affectedQAs := { } //an empty set (09) function main() { [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Sofware[END_REF] on RequestForAssistance {// an event listener [START_REF] Jansen | Software architecture as a set of architectural design decisions[END_REF] for-each (AT in Doc) { [START_REF] Kim | Quality-driven architecture development using architectural tactics[END_REF] QA := QA in AT [START_REF] Kruchten | An ontology of architectural design decisions in software intensive systems[END_REF] AD := AD in AT [START_REF] Lehman | Software evolution[END_REF] checkArchitecturalConstraint (AD) (15) } ( 16) let newAD := ask for AD associated to the new architecture, if any [START_REF]Web services business process execution language version 2[END_REF] if(newAD != null) let newQA := ask for the QA associated to newAD [START_REF] Omg | Object constraint language specification, version 2.0, doc[END_REF] addNewArchitecturalTactic (newAD,newQA)

(19) } (20) checkAffectedQAs () (21) } (22) }
During the step of architecture change application (Figure 2) the developer can ask for an assistance. This triggers the listener on Line 10 in the algorithm above. The algorithm starts first by looking for the architecture documentation associated to the architectural element (the orchestration or the Web service description) which has been changed. Then, the algorithm checks each constraint in the documentation (by calling a function which is detailed in the following paragraphs). After that, the developer is asked to pinpoint the architecture decision and the quality attribute associated to the changes, if any (Lines 16 and 17). At last, if the changes generate a new architecture decision, the algorithm try to add, to the documentation, the couple composed of this new decision associated to its quality attribute, which is called in this work an architectural tactic (Line 18). In addition the algorithm tries to infer the quality attributes affected by this new tactic (Line 20).

The function detailed in the listing below, checks the constraints associated to a given architecture decision received as an argument. It starts by checking the constraint expressions associated to the decision. If the checking does not succeed for a given constraint, a set of warnings are displayed to the developer. The displayed information includes the architecture decision, the precise architectural element impacted by the change, the degree of formalization of the decision, the quality attribute, its degree of satisficing and its criticality degree (Lines 11 to 14 in the algorithm below). In addition this function shows to the developer the list of quality attributes which are eventually impacted by this change (Lines 15 and 16). For doing so, it uses the table of relationships between quality attributes presented in the previous section. It limits the selected quality attributes to the ones which are tightly coupled with an "enhacing" relationship. This ensures the selection of the most pertinent quality attributes in this situation. warn "The following architecture decision " +AD+" is affected." (08)

warn "This concerns the architectural element: "+AE (09)

warn "The affected architecture decision is formalized [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Sofware[END_REF] by the constraint up to " + degreeOfFormalization (AD,AC)+ "%" [START_REF] Jansen | Software architecture as a set of architectural design decisions[END_REF] warn "The affected architecture decision is satisficing "+QA [START_REF] Kim | Quality-driven architecture development using architectural tactics[END_REF] + " up to " +degreeOfSatisficing(AD,QA)+"%" [START_REF] Kruchten | An ontology of architectural design decisions in software intensive systems[END_REF] warn "The degree of criticality of this QA is: " [START_REF] Lehman | Software evolution[END_REF] + degreeOfCriticality(QA) [START_REF] Marew | Tactics based approach for integrating nonfunctional requirements in object-oriented analysis and design[END_REF] warn "Other QAs may be affected. This concerns: " + ( 16)

QA_Relationships (QA,"enhances", "tight") [START_REF]Web services business process execution language version 2[END_REF] ask to validate the new architecture or undo changes [START_REF] Omg | Object constraint language specification, version 2.0, doc[END_REF] according to the warnings above [START_REF] Tibermacine | Nfrs-aware architectural evolution of component-based software[END_REF] if(new architecture maintained) { [START_REF] Tyree | Architecture decisions: Demystifying architecture[END_REF] affectedQAs := affectedQAs + QA (21) + QA_Relationships(QA, "enhances", "tight") (22) warn "Architecture documentation will be changed . Then, the developer is asked to validate the new architecture fully aware with the possible consequences of her/his changes, or to undo changes. In this last case, the architecture documentation should be updated by the algorithm (this is the second important role of this assistance algorithm). The affected decisions and their associated quality attributes are removed from the documentation (Line 23 in the algorithm above). The developer is at last asked to review the degrees in the documentation as some tactics are removed. In addition, she/he is invited to review the non-functional (or quality) requirements specification.

The function addNewArchitecturalTactic(...) creates a new architectural tactic and adds it to the documentation. Before that, if the quality attribute has been voluntarily added by the developer, it is removed from the set of affected quality attributes (Line 04 in the listing below). Else this attribute is considered as a new quality and a checking is performed to alert the developer of the other qualities that are possibly affected by this attribute (Lines 06 -07). At last, the algorithm asks the developer to change the quality requirements specification. warn "Other QAs may be in conflict with "+QA+": " (07) + QA_Relationships (QA,"collidesWith","both") (08) } (09)

warn "Architecture documentation will be changed ..." [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Sofware[END_REF] Doc := Doc + newAT [START_REF] Jansen | Software architecture as a set of architectural design decisions[END_REF] ask to change Non-Functional Requirements specification (12) }

The last function (see below) just recalls to the developer that there still remain some affected quality attributes, if any. The developer is asked to review the architecture documentation and the quality requirements specification. The overall goal of this algorithm is twofold. First, it assists developers during architecture evolution with information about the impact of their changes on architecture design decisions and on quality attributes. Second, it helps to maintain the documentation of non-functional (or quality) requirements up-to-date in a semi-automatic fashion. This can be observed in updates made automatically on the documentation, requests to review satisficing degrees of the affected quality attributes, and requests to change or review NFRs specification.

In this section, we show an example of an architecture documentation and its use by the evolution assistance algorithm. Let us take the example of Section 2. Its architecture documentation is presented in a synthetic way (in order to not be too verbose with its original XML-based description) in the listing below:

Architecture-Documentation : 1. Architecture-Tactic :

This tactic guarantees the Portability quality requirement by using a Service facade pattern -Quality-Attribute name="Portability" degreeOfCriticality="high" -Related-Quality name="Performance" relationship="CollidesWith" relationType="tight" -Architecture-Decision name="Service facade pattern" degreeOfSatisficing="90" -Architecture-Constraint profile="BPEL" degreeOfFormalizing="80" 2. Architecture-Tactic :

This tactic ensures the Security quality requirement by using a Trusted subsystem pattern -Quality-Attribute name="Security" degreeOfCriticality="very high" -Related-Quality name="Availability" relationship="Enhances" relationType="weak" influence="negative" -Architecture-Decision name="Trusted subsystem pattern" degreeOfSatisficing="70" -Architecture-Constraint profile="BPEL" degreeOfFormalizing="90"

Architecture-Tactic :

This tactic ensures the Performance quality requirement by using a Partial state deferral pattern -Quality-Attribute name="Performance" degreeOfCriticality="high" -Related-Quality name="Security" relationship="CollidesWith" relationType="tight" -Architecture-Decision name="Trusted subsystem pattern" degreeOfSatisficing="60" -Architecture-Constraint profile="BPEL" degreeOfFormalizing="70"

The architecture documentation contains three architectural tactics. They document the links between architectural decisions (AD1, AD2, AD3) presented in Section 2 and their corresponding quality attributes (QA1, QA2, QA3). In this documentation we can see among others the different relations between quality attributes (Related-Quality element in the listing above). For example, in the first tactic 7 , the Related-Quality element shows that the portability and performance quality attributes are colliding and are tightly coupled.

Let us see now the use of the assistance algorithm, given the evolution scenario described in the example of Section 2: short-circuiting the authentication service. The assistance algorithm checks the constraints8 formalizing the architectural decisions for each architectural tactic, and detects that the constraint formalizing the decision AD2 (The Authentication service implementing the Trusted subsystem pattern) was violated. Therefore, the security quality attribute (QA2) is affected. It then notifies the developer that the violated constraint formalizes AD2 up to 90% (an important constraint in the formalization of this decision), the affected architecture decision satisfies Security up to 70% with a very high degree of criticality, and that the security is weakly coupled to the availability quality attribute by an enhancement relation with a negative effect. This means that the availability quality attribute is directly affected by this change. Based on this notification, the developer decides to abort the change she/he made, aware that short-circuiting the authentication service makes the service not secured.

The second change to the orchestration consists of adding a new functionality service namely the Archival service which leads to remove the Data Relayer service. This change aims to improve the performance and the availability of the service. The algorithm detects that the constraint representing the decision AD1 (service facade pattern) does not hold any more, which means that the portability quality attribute (QA1) is affected. Hence, it informs the developer that the violated constraint formalizes AD1 with a degree of 80%, satisfies QA1 up to 90% which has a high degree of criticality, and that QA1 and QA3 (performance) are colliding but tightly coupled. The developer concludes that wanting to improve the performance of the service she/he will probably loose the portability quality attribute, and therefore, decides that performance is more important than portability and validates the change. The corresponding tactic of the affected decision is removed from the documentation and a new tactic is added. The developer is invited to update the NFRs specification and to review the satisficing degrees for the affected qualities. These information serve for possible changes that may occur on the service architecture in the future.

Related Work

In the literature, there are many works on the documentation of architeure design decisions. Clements et al. in [START_REF] Clements | Documenting Software Architectures, Views and Beyond[END_REF] present an approach which provides a framework for documenting different views of a software architecture. The authors propose a template for architecture description encompassing the documentation of architectural decisions. In [START_REF] Tyree | Architecture decisions: Demystifying architecture[END_REF], Tyree and Akerman discuss the importance of documenting architecture decisions and their specification as first-class entities in architecture description. They present a template specifically designed for architecture decision documentation, which embeds interesting information characterizing architecture design decisions (status, assumptions, implications, related artifacts, constraints, ...). Philippe Kruchten introduced a taxonomy of design decisions [START_REF] Kruchten | An ontology of architectural design decisions in software intensive systems[END_REF]. He presents a model for describing architecture decisions, including rationale, scope, state, history of changes, categories, cost and risk. He identifies in this ontlogy the different possible relationships between design decisions and links between design decisions and design artifacts. In [START_REF] Jansen | Software architecture as a set of architectural design decisions[END_REF], Jansen and Bosch present a new way of building software architectures. They propose to define these design models as a composition of architecture design decisions. The authors introduce a model for architecture design decisions, including a description, the rationale, the design rules, the design constraints, the consequences, the pros and cons. In [START_REF] Capilla | Modeling and documenting the evolution of architectural design decisions[END_REF], the authors proposed a way to characterize architectural decisions. They defined attributes to describe architectural decisions by separating mandatory and optional attributes according to their degree of importance. The first class introduces information associated to architectural decisions that must be defined throughout the system life cycle, including a decision name and description, the constraints, the dependencies, the status, the rationale, the design patterns, the architectural solution, and the requirements. The second class provides additional information that can be choosen according to user preferences such as, the alternative decisions, assumptions, pros and cons, category of decision, or quality attributes. In addition to these attributes, they have defined attributes to support the evolution of architectural decisions, including the date and version, the obsolete decision, the validity, the reuse times and rating, and the trace links.

As in these approaches, our work proposed a new way to document architecture decisions. But contrarily to these works, we focused on the use of this documentation in the architecture change assistance. These works can complement our proposed documentation in order to make it richer.

Many works have been proposed on Non-Functional Requirements capture and specification. One of the major works in the literature is that of Mylopoulos et al. [START_REF] Mylopoulos | Representing and using nonfunctional requirements: A process-oriented approach[END_REF]. Following a process-oriented approach the authors propose a framework for the representation and use of Non-functional requirements during the development process. The framework includes five components allowing, following a goal-oriented process, to justify and argue design choices made to satisfy certain software quality requirements. The authors consider Non-functional requirements as goals to be achieved by validating the right design decisions and their rationale, considered in turn as goals. In [START_REF] Cysneiros | Nonfunctional requirements: From elicitation to conceptual models[END_REF] Cyneirios et al. propose an approach based on Mylopoulos's framework for capturing and representing NFRS and their interdependencies. Their approach shows the integration of NFRs in functional requirements models. The authors were interested in conceptual models expressed in UML by incorporating NFRs descriptions in class, sequence, and collaboration diagrams. Bass et al. [START_REF] Bass | Quality attribute design primitives and the attribute driven design method[END_REF], proposed ADD method (Attribute-Driven Design) that follows an architectural design process guided by quality requirements. It uses the concept of attribute primitives, which are collections of components and connectors collaborating to satisfy some quality attributes. These attributes are documented as general scenarios. In [START_REF] Bass | Software Architecture in Practice[END_REF], the authors proposed Ar-chitectural tactics, in the same spirit as the primitive attributes to guarantee quality characteristics in software architectural design. Kim et al. [START_REF] Kim | Quality-driven architecture development using architectural tactics[END_REF] presented an approach for representing NFRs in software architecture using architectural tactics as reusable architectural building blocks. The later and their relationship are represented as Feature Models and their semantics is defined with the RBML language (Role-Based Metamodeling Language). Architectural tactics satisfying quality attributes are selected and composed into one tactic encompssing all the desired qualities. The resulting tactic is then instantiated to create a software architecture that incorporates NFRs for the system under development. In [START_REF] Marew | Tactics based approach for integrating nonfunctional requirements in object-oriented analysis and design[END_REF], the authors present an approach inspired from [START_REF] Mylopoulos | Representing and using nonfunctional requirements: A process-oriented approach[END_REF][START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF]. It aims at integrating NFRs handling in analysis and design phases as with functional requirements to fill the gap between the elicitation and implementation of NFRs.

All these approaches focus on the design stage of software development. Our work is complementary to these approaches, since it addresses a stage which is situated downstream in the development process, the evolution stage.

Conclusion and Future Work

Since some years, architecture decision and design rationale are two topics which received a lot of attention from the software architecture research community. In this paper, we proposed an approach which provides: i) a language to document a basic form of architecture decisions as architecture constraints, and the rationale of these decisions, which are quality attributes, together with some fine-grained information about the relationships between these two concepts; ii) a method which makes operational this documentation through its use during architecture evolution; and iii) an algorithm which implements the supervision of architecture evolution. This supervision aims at deducing on-the-fly the possible impact of a given architectural change on design decisions and consequently identify the affected quality requirements.

Our approach has been applied on a specific kind of software architectures, which are service-oriented ones. A concrete implementation of this kind of software architectures has been considered in our work, which are Web service orchestrations.

On the conceptual aspect, we plan in the near future to separate functional from non-functional evolution in the assistance algorithm. Indeed, these two imply different considerations. Non-functional (or quality) evolution have direct impact on existing decisions and quality, and the developer has some knowledge about the existing quality requirements. In the case of functional evolution, the developer has a different profile, and should be assisted differently.

On the tool and experimental aspect, we will conduct the creation of a catalog of predefined service-oriented architecture design decisions in order to help the developers in the initial documentation of their architectures. This will be based on existing works on patterns or quality models for service-oriented architectures, among others.

Fig. 1 .

 1 Fig. 1. A Micro-Process of Architecture Evolution

Fig. 2 .

 2 Fig. 2. The Proposed Micro-Process of Architecture Evolution

FormalizingFig. 3 .

 3 Fig. 3. Links between Architecture Decisions and Quality Attributes

Fig. 4 .

 4 Fig. 4. Relationships between Quality Attributes

  and AT := Architecture Tactic //a couple composed of a QA and an AD (07)and Doc := architecture documentation associated to changed AE (08)

(

  01) function addNewArchitecturalTactic (AD,QA) { (02) newAT := new AT(AD,QA) (03) if (QA is in affectedQAs)

(

  01) function checkAffectedQAs () { (02) if (affectedQAs <> {} ) { (03) for-each (QA in affectedQAs) { (04) warn QA + "is still affected by your changes" (05) ask to review satisficing degrees of ATs implying QA (

This micro-process addresses software evolution in general, and not service-oriented architectures in particular. Adaptations to this specific context are detailed later.

By "formalization", we simply mean here the specification of a given artifact in an unambiguous and structured or semi-structured way using a language that can be processed by tools (not using the natural language).

This pattern is originally inspired from[START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Sofware[END_REF].

Software engineering -Product quality -Part 1: Quality model. The

We recall that a tactic is the couple composed of an architecture decision and its quality attribute.

For reasons of space limitations, constraints are not presented here. They are defined using a modified version of OCL and navigate in a metamodel of BPEL.


Aymen Baouab

Olivier Perrin

Claude Godart

An event-driven approach for runtime verification of inter-organizational choreographies

Keywords: Inter-organizational flow, Business process, Choreography, Service notification, event

In todays economy, collaborative computing grows in importance. Inter-organizational service-based processes are increasingly adopted by different companies when they cannot achieve goals on their own. As a result, conformance problems arise and it must be ensured that the integrity of processes execution remains guaranteed. In this paper, we propose new components, to be deployed along the boundaries of each participating organization, offering external flow control, and notification in case of violation detection, while providing process execution traceability. To achieve our goals, we propose an event-based approach in which inter-organizational exchanges are perceived as events. We define event patterns for filtering the desirable incoming and outgoing messages.

I. INTRODUCTION

The ability of linking inter-organizational business processes is receiving increased attention in an ever more networked economy [START_REF] Grefen | Towards dynamic interorganizational business process management. Enabling Technologies: Infrastructure for Collaborative Enterprises[END_REF]. Nowadays, using electronic data interchange (EDI) for trading relationships among businesses does not meet the demands as EDI mainly enables bi-lateral relationship specific linkages without supporting dynamic collaboration and inter-process interactions. However, many cross-organizations projects have a need for business-process collaboration support.

As opposed to intra-organizational centralized processes, the decentralized setting of those deployed across organizational boundaries raises new control requirements. Without a centralized coordinator that can be a performance bottleneck in some business scenarios, collaborating parties must be able to set up an inter-organizational business process by disclosing to each other only as much as necessary.

In this paper, we consider that the collaborating parties reveal only part of their behavior and processes, keeping internal business activities invisible to other parties. Thus, the global process can be seen as a choreography, which defines re-usable common rules that govern the ordering of exchanged messages, and provisioning patterns of collaborative behavior, as agreed upon between two or more interacting participants [START_REF] Kavantzas | Web services choreography description language version 1.0. W3C[END_REF]. In this context, a first important aspect deals with the conformance. A choreography can sometimes fail as a result of an exceptional circumstance or an error that occurred during its execution. The number of exceptions may increase when the coordination is not well supervised. Indeed, when participants cannot rely on a trusted centralized coordinator to manage basic execution primitives such as message routing, basic security features such as the integrity of the process execution are no longer guaranteed. In fact, additional verifications must be added within each business partner in order to ensure the conformance of the overall sequence of operations with the predefined process execution plan.

A second aspect deals with the way to ensure that a choreography is conform to what is expected, without too much overhead to the in-place architecture. To meet this need, additional components have to be deployed in an agile and flexible way within each organization's boundaries. Hence, there is a need of separating these non-functional aspects from the business-process, following the principle of separation of concerns as we proceeded in a previous work [START_REF] Baouab | Security meta-services orchestration architecture[END_REF].

The aim of this paper is to address these issues by exploring inter-organizational business collaborations in a technology-independent way and by providing a new conceptual model. We are focusing, on the one hand, on a distributed, agile and flexible manner to ensure the conformance of the overall sequence of inter-organizational choreography operations with a predefined process execution plan and, on the other hand, on a dynamic and efficient decentralized architecture for errors notifications, while providing process execution traceability.

The approach we introduce in this paper consists in providing new components to be deployed within each participating organization. The purpose of these components is threefold :

1) Message interception : Being deployed along the boundaries of each participating organization, our components have to be able to intercept all exchanged messages with the outside environment. These intercepted messages are then filtered and controlled.

2) Message ordering verification : Ensuring that the sequence of sent and received messages is consistent with the predefined plan. The purpose is to verify whether participating parties have performed their tasks according to the used control flow constructs of the choreography (i.e. the control-flow is proceeded correctly by known participants who behave as expected). 3) Event-driven notification : Selective notification of the involved partner(s) in case of inconsistent flow detection. To achieve these goals, we propose an event-based approach in which inter-organizational exchanges are perceived as events. Indeed, dealing with issues mentioned above in an event-based way allows for more flexible, scalable and dynamic scenarios running in a highly-reconfigurable infrastructure. Following the principle of Complex Event Processing (CEP) [START_REF] Luckham | The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems[END_REF], we use event patterns to filter, monitor, and check for the desirable incoming and outgoing calls.

This paper presents a motivating scenario in Section II, then proposes an architecture and a policy generation mechanism in Section III, and describes the proposed event-based approach in Section IV . Section V presents some deployment guidelines. Section V I describes some related work. Finally, Section V II concludes the paper and outlines future directions.

II. SCENARIO AND MOTIVATION

This section presents a classical scenario and discusses the motivation behind the proposed research.

A. Motivating example

For explaining the motivation and concepts of our work we have chosen a classical purchase order scenario as illustrated in the diagram shown in Figure 1. The diagram shows a choreography between a reseller, a supplier and two shippers (other involved participants such as banks have been omitted for space reasons). The reseller sends a purchase order request with details about the required products and the needed amounts to the supplier [START_REF] Albek | An event processing language (epl) for building sense and respond applications[END_REF]. The supplier checks the order, then notifies the reseller if and only if there is no more available products (2c). Otherwise, the supplier processes the order and selects one out of two shippers to deliver the selected products (2a or 2b). In this case, the chosen shipper finishes the process by sending the products to the reseller (3a or 3b).

Without any trusted coordinator to refer to, each business partner participating in the choreography needs to be able to verify, at any given point in time, that all incoming and outgoing messages conform to the expected ones according to the predefined process plan. Thus a control-flow aware policy is needed. For instance, when considering the scenario of Figure 1, the supplier has to choose between three service calls (i.e. 2a, 2b or 2c) depending on its internal subprocess execution (which is not visible to other participants). In return, the reseller will receive one, and only one of the messages (2c, 3a or 3b). If it is not the case, the Reseller must detect a non compliant behavior regarding the predefined execution plan and may have to inform other involved partners. Indeed, in such a case, the Reseller may be the only collaborating party that is aware of what happened and able to notify the other parties, what is of first interest in the absence of a central coordinator.

B. Motivation of the approach

During the execution phase, many choreographies shared between different business partners may be instantiated. Indeed, each organization may have multiple external interactions associated with different choreographies instances. Thus, there is a need to check the consistency of all incoming and outgoing calls with respect to the current step in each choreography that an organization is participating to. Access to resources must be restricted pursuant to the principle of least privilege [START_REF] Saltzer | The protection of information in computer systems[END_REF]. When data is passed between participants, there must be access restrictions according to the tasks. The set of allowed service calls at any given point in time should be dynamic and minimal. For instance, a call that is not associated with any current expected step of the instantiated choreographies should be reported to the monitoring applications as a potential violation. Controlling incoming calls at earlier stage may reduce some of common attacks (e.g. DoS attack) and acts as a defense against malicious attacks that may aim to exploit external flow authorizations. Furthermore, it represents a crucial requirement to prevent any malicious peer from forging a workflow instance.

Our approach aims at providing a simplified mechanism that ensures the conformance of the inter-organizational flow and the correctness of the execution order of the choreography. Before presenting the approach, we model a choreography as a set of interactions and control-flow elements (sequence, parallel, choice, etc.). In order to be able to control the whole process execution in a decentralized way (i.e. without a coordinator), a global state could be permanently maintained and shared among the participants during the execution phase. In such a case, additional exchange of messages would be required which would complicate our task. To address this issue, we chose to have each party only controlling its own interactions, and thus no current global states are exchanged. Thus, parties that are not involved in the current interactions only approximate the current view. Certainly, this may relax the achievement of our goals but frees us from a synchronization overhead.

To control its own interactions, the global view is no more needed and each party computes its own local view of the choreography. As shown in [START_REF] Kerschbaum | Security architecture for virtual organizations of business web services[END_REF], each participant can do this by simply filtering all interactions that do not have itself as a source or a destination. Afterwards, unnecessary nodes and control-flow elements are removed.

III. OVERVIEW OF THE APPROACH

In this section, a policy generation mechanism that have to be executed during the set-up phase of the choreography is presented. Afterward, a short overview of the proposed architecture is provided.

A. External flow policy generation

After the creation of the local view of each choreography, a local policy for external flow control is automatically created within each participant. This policy specifies additional constraints for the received and sent messages based on the control-flow dependencies. These dependencies are generated from the local view of the choreography by a simple calculation of the predecessor(s) of each incoming and outgoing message. Based on the preceding control-flow pattern, this can be achieved automatically by using any predecessor calculator depending on the used choreography language. The policy is defined as follows.

Definition. An external flow policy (EFP) is 5-tuple of < id, S/R, M type , Src/Dst, P red cond > where id is the policy identifier, S/R is the message direction (Receive or Send), M type is the message type (e.g. XML Schema), Src/Dst is the involved partner (as source or destination), and P red cond is the predecessor condition to be satisfied (i.e. the list of the messages that must be detected before).

This policy allows to accept only the right message from/to the right partner at the right step of the choreography execution. Messages that do not match any entry of the policy table must be pointed out. In order to make it more explicit, Figure 3 shows the locally generated policy of each organization involved in the scenario presented in Section II-A. As opposed to dynamic policies such as [START_REF] Kerschbaum | Security architecture for virtual organizations of business web services[END_REF] and [START_REF] Vagts | Control flow enforcement in workflows in the presence of exceptions[END_REF] Figure 3. External flow policies that suffer from scalability problems, since for each process instance a new policy have to be instantiated, our policy is static and, thereby, shared by all the instances. Indeed, one, and only one, policy is generated after the creation of the choreography.

B. Proposed architecture

In order to present the concept in a technologyindependent way, we prefer to outline a general architecture rather than describing technical details related to any service choreography languages, such as WS-CDL 1 , BPEL4Chor [START_REF] Decker | Bpel4chor: Extending bpel for modeling choreographies[END_REF] or Let's Dance [START_REF] Zaha | Let's dance: A language for service behavior modeling[END_REF]. We propose to extend any organization architecture with two components :

The External Flow Controller (EFC) : Responsible for intercepting, controlling and monitoring incoming and outgoing messages. Two types of control are depicted: incoming message control in order to restrict the access to internal resources taking into account the context of the call and the control-flow of the involved inter-organizational process, and outgoing message control aiming to prevent from divulging sensitive information in unexpected ways (i.e. without a consistent inter-organizational process context).

The External Flow Policy (EFP) Repository : In which external flow policy is generated and stored. To allow for a policy-based approach, it is important to separate this component from the EFC. The EFP Repository can be managed centrally by a governance layer. The policies can be then audited, traced, and historically managed.

From a technical point of view, each component can be implemented as a set of specialized services.

IV. EVENT-DRIVEN MESSAGE VERIFICATION

Instead of periodically checking (with a request/response) whether a situation have been detected or not, verifications and notifications are performed only when they need to (i.e. when there is a new message or an interesting information to report). To do so, we propose an event-based approach in which each message received or sent can be associated to an event.

First of all, event patterns have to be defined in order to intercept desirable incoming and outgoing calls. Then, 1 Web services choreography description language these patterns have to be implemented into event processing agents within each organization boundaries. To do so, we use the RAPIDE Event Pattern Language [START_REF] Luckham | The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems[END_REF], a strongtyping declarative computer language for writing patterns of events. It was designed to be commonly used for Complex Event Processing (CEP) [START_REF] Leavitt | Complex-event processing poised for growth[END_REF], which is a layer built on top of Event Driven Architecture (EDA). Even if there are many others event processing language projects [START_REF] Leavitt | Complex-event processing poised for growth[END_REF] (e.g. STRAW-EPL, StreamSQL, Infospheres [START_REF] Albek | An event processing language (epl) for building sense and respond applications[END_REF], AMiT [START_REF] Magid | Industry experience with the ibm active middleware technology (amit) complex event processing engine[END_REF]), the choice of this language is motivated by its notational simplicity and efficiency of pattern matching versus power of expression. However, the use of any other EPL remains possible. It should be noticed that each EPL has a pattern matcher which is a program that processes one or more event executions in real time and picks out all, and only, posets that match a defined pattern. In our case, the pattern matcher is implemented within the EFC.

A. Definition of events

The patterns specify sets of events together with their parameters, timestamps, and eventual causal dependencies. Defining events consists of declaring the types of parameters followed by the events templates. In our approach, we first distinguish three input types of event : Send (outgoing call), Receive (incoming call), RecNotf (incoming notification), and one output type : Notify (generated notification). Then we discern five parameters : the choreography instance identifier, the destination or the source partner identifier, the message type (e.g. an XML schema identifier), the message identifier and an optional field for eventual error information. Figure 5 shows how to define these events and their parameters using the RAPIDE-EPL syntax.

B. Definition of Event Pattern Rules

An event pattern rule is a reactive rule with two parts: a left side called the trigger (which is a RAPIDE-EPL pattern) and a right side called the body (which is a list of statements). Each rule has the following syntax :

pattern => body(list -of -statements);

We propose to set up a trigger for each type of event (Send, Receive and RecN otif y). In case of each Send or Receive, the pattern matcher matches the corresponding entry in the local EFP table and checks whether the predecessor condition is satisfied. If not, a notification event is generated. Our basic rules are shown in Figure 6. The use of "?" as a prefix to a pattern parameter helps distinguish the variable parts of a pattern from the constant parts. A generate statement in a rule's body creates new events that usually belong to the output action set. In our case, the Notify() event, which is fired in case of each policy violation, is the only output event. The P olicy.f ind() function, defined on line 5, accepts three parameters : the action (which is send or receive), the organization as a source or a destination (depending on the action) and the message type. This boolean function checks whether an action defined by these three parameters exists in the local EFP table. We remind that the latter takes the form shown in Figure 3.

The P olicy.getdependencies() function, defined on line 7, accepts two parameters : the instance identifier and the message type. This function returns the list of the predecessors related to that message type from the local EFP table.

The Set.F ind() function, defined on line 9, accepts a list of events as parameter and returns whether the events of this list exist in Set (i.e. the set of events, defined on line 1, which contains the history of all accepted events and which can be used also for traceability issues).

Finally, the Set.Store() function, stores the event associated to each accepted message in the list of events Set.

After the definition of these functions, event pattern rules are depicted with the implementation of a list of statements for each defined trigger. We distinguish three basic event triggers :

Outgoing calls trigger (line 12): This trigger is matched whenever an outgoing call is detected. For each match, the body (lines 13 to 19) is executed. First, a policy enforcement is fulfilled by checking whether a corresponding entry exists in the local EFP table. Then, the execution order is checked by verifying that all events that should happen before (referring to the corresponding Predecessor field in the policy) have been already matched and stored in the event history set.

Incoming calls trigger (line 22): This trigger is matched whenever an outgoing call is detected. For each match, the body (lines 23 to 29) is executed. The body statements are almost the same as those of outgoing calls rules. The unique difference is that the action field is instantiated to Receive instead of Send.

Received notifications trigger (line 32): This trigger is matched whenever an external notification is received. For each match, the notification is simply forwarded by generating an internal notification.

C. Extensibility : Additional Rules

Flexibility represents an important non functional aspect of our approach. Indeed, it is important that the EFC offers the ability to be changed whenever the security requirements of the organization change evolve. Thus, an interface for rules management is advised in order to permit easy implementation of additional rules. Each additional rule should have a security purpose behind it. Thus, adding new rules fixes additional constraints with the intention of denying some attacks or avoiding conflicts.

Figure 7 shows an example of additional rules. The independence operator, pattern1 II pattern2, indicates that all the events matching pattern1 must be independent of all the events matching pattern2. For instance, Rule 4 (line 37) verifies whether each message identifier is unique. If it is not the case (i.e. when two messages having the same ID are detected), a new notification event is fired.

Furthermore, Rule 5 (line 42) verifies whether messages having the same message type within the same choreography instance (i.e. same instance identifier) are detected. This can Figure 7. Additional Rules be a result of a Retry action when a message is lost and a reliable messaging mechanism is used, or in case of a rollback action when a global exception occurs. Hence, more sophisticated verifications and actions dealing with these issues can be added in the body of the rule.

D. Notifications

We distinguish two types of notifications : internal notifications that are typically generated by the EFC and bound for an internal monitor (i.e. within the same organization) and external ones that are exchanged by EFCs of different organizations (i.e. crossing organization boundaries).

Internal notifications: For each detected noncompliance with the predefined process execution plan, the EFC notifies its own organization by sending an error message and an overview of the involved calls to an internal monitor. As explained previously, the EFC stores information related to all incoming and outgoing calls of its organization. This information can be useful for some internal components of the organization the EFC belongs to.

External notifications: In some case of errors, it deems advisable that the EFC notifies the involved partner(s). This may permit to detect not viable parts of the global business process in a earlier stage. A notification message may at least contain an identification of the message of origin and an error code. Such information will be useful for the involved partner in order to raise and handle an exception in the main choreography. This may save time compared to the traditional way (i.e. when exceptions are managed by the choreography language) especially in the case of internal exceptions that cannot be detected from the outside. In such a case, timeout counters are traditionally used but are not well adapted to long-running collaborations.

In counterpart, received notifications are transformed into internal ones in order to be forwarded inside the organization.

V. DEPLOYMENT GUIDELINES

To demonstrate the feasibility of our concept, a preliminary reference architecture is proposed in Figure 8.

Typically, the EFC may be deployed as a gateway service intercepting all incoming and outgoing messages and notifying when necessary. Allowed incoming messages, after being verified by an authorization system (e.g. PEP/PDP2 such as defined in XACML [START_REF] Godik | Extensible access control markup language (xacml) version 1.0. OASIS Standard[END_REF]), can then be forwarded within the secure zone in which resources have been deployed. In the other direction, outgoing messages are checked for authorization then intercepted by the EFC before being sent outside. In case of complex architectures, it is advisable to Figure 8. Deployment within an organization follow the principle of Separation of Concerns by deploying each functionality as a separate service (e.g. message intercepter, message analyzer, notifier, etc.) and making them collaborating together. Moreover, the EFP Repository may also be deployed as a set of services offering interfaces to access, monitor and manage generated policies. This strategy may increase the agility of our components allowing for simpler future upgrades.

In order to allow for the possibility that some of our services combine request/response (i.e. choreography messages) and event-oriented (i.e notifications) message exchanges, a single infrastructure is a necessity. The OASIS Web Services Notification (WSN) family of specifications [START_REF] Niblett | Events and service-oriented architecture: The oasis web services notification specification[END_REF] illustrates how event-based programming can be introduced in SOA in a standardized way. The WS-Base Notification specification, which is the base document of WSN and often referred to as the SOA notification pattern, unifies the principles and concepts of SOA with those of event-based programming. Following this pattern, we can configure and deploy the different entities as event-oriented services. For instance, a notification producer may be deployed within the EFC. Depending on the granularity of the latter, this service may be responsible for detecting violations and creating notification messages instances while assuming the role of publisher of events. In the other side, notification consumers may be configured for internal monitoring applications.

An ESB 3 can be used here to mediate between request/response services and the new created event-oriented services helping for delivering notifications from producers to consumers. Nowadays, ESBs offer techniques for analyzing and controlling the complex series of interrelated events in order to allow for the implementation of both the SOA and the EDA concepts. The ESB may also provide additional added-value function such as transforming notification message content or logging notification messages in a relational database.

Furthermore, the ESB gateway pattern provides an XML firewall in addition to the desired gateway functions. Depending on security requirements, this ESB can be inside the Enterprise Demilitarized Zone (DMZ). Such a solution is well suited for serving on the boundaries of each organization as it is quite agile and flexible, thus permitting easy deployment of our designed components as services. However, this step needs more investigations and time and is part of our future work.

VI. RELATED WORK

The security of decentralized inter-organizational process has been an active research field in the last years. This section discusses different approaches and existing technical solutions in the field of access control, integrity of process execution, secure execution order and monitoring of choreographies.

Mendling et al. [START_REF] Mendling | An approach to extract rbac models from bpel4ws processes[END_REF] presented an approach to integrate Role-Based Access Control (RBAC) and WS-BPEL [START_REF] Evdemon | Web services business process execution language version 2[END_REF] (Business Process Execution Language) at the meta-model level. Such approach, which is based on extending WS-BPEL with mappings to RBAC, can be used to automate steps of the role engineering process.

Thomas and Sandhu [START_REF] Thomas | Task-based authorization controls (tbac): A family of models for active and enterprise-oriented authorization management[END_REF] proposed an extension of the RBAC called TBAC (Task-based Authorization Control). TBAC permits to grant or revoke permissions based on when tasks are scheduled in order to make related capabilities valid only for a specified duration. To make this possible, authorization policy had been extended with two new fields for enabling and disabling authorization at runtime, taking the form < s, o, a, usage, authorization -step >.

Using OrBAC (Organization based Access Control), Ayed et al. [START_REF] Ayed | Managing access and flow control requirements in distributed workflows[END_REF] suggested a dynamic decentralized approach to handle a security policy in inter-organizational workflows taking into account access and flow control. An OrBAC security rule takes the form < type, organization, role, activity, view, context > where type can be : permission, prohibition or obligation. Like in TBAC, security rules here do not apply statically and their activations depend on contextual conditions. The algorithm defined in [START_REF] Ayed | Managing access and flow control requirements in distributed workflows[END_REF] shows how to use this model in a distributed WFMS environment. However, it needs further work on how to handle exchanging flows between different organizations.

In [START_REF] Kerschbaum | Security architecture for virtual organizations of business web services[END_REF], the inter-organizational flow control is implemented with the same PEP/PDP mechanism. Indeed, the authorization specification is extended and takes the form of 7-tuple < policy -id, s, o, a, l enable , l disable , state >. The idea behind this is to enable and disable policies with respect to the current step in the choreography in order to ensure the correct execution order of the inter-organizational workflow. Each organization hosts a new component called Policy Generator or PGC which is responsible for generating a local policy during the workflow instantiation step. The generation depends on the workflow patterns. One drawback is that the parallel pattern needs the generation of extra policies (n * 2 n-1 policies for n parallel branches). Vagts [START_REF] Vagts | Control flow enforcement in workflows in the presence of exceptions[END_REF] extends this solution and proposes a decentralized framework for workflow execution that ensures exception safety and considers security issues.

Montagut and Molva [START_REF] Montagut | Bridging security and fault management within distributed workflow management systems[END_REF] used onion encryption techniques to enforce the execution integrity of distributed workflows. The proposed solution ensures that the access to workflow data is performed with respect to the workflow execution plan and provides proofs of execution to the involved business partners. However, this technique may decrease performance and greatly increase the size of message.

Secure execution orders are also considered by Biskup et al. [START_REF] Biskup | Towards secure execution orders for compositeweb services[END_REF] supporting the case of a decentralized system by proposing a container structure with authentication mechanisms for data access. In other words, they introduce a framework for providing middleware support based on a process container, which calls dedicated middleware services to add support for security, persistence and reliable messaging. A similar approach is shown in [START_REF] Rudolph | Secure web service workflow execution[END_REF]. In these two approaches the container is passed along the execution path of the workflow in order to verify the correct execution of interorganizational choreographies. However, this technique does not address the exceptions that may occur, i.e. corruption or loss of the message or the container itself.

In [START_REF] Rouached | Web Services Compositions Modelling and Choreographies Analysis[END_REF], verification and validation techniques for Web service conversations and their choreographies are exposed. Nevertheless, the verification task is managed centrally and therefore not adapted to inter-organizational choreographies when there is no common trusted parties among all participants.

VII. SUMMARY AND FUTURE DIRECTION

Despite the numerous benefits attainable after adopting dynamic and flexible choreographies across collaborating parties, a major concern is the lack of security conventions after changing to an open and exposed environment. Without a coordinator, a decentralized control of these choreographies is a challenge. In this paper, we propose an architectural framework and a policy-based mechanism to verify the compliance of the overall sequence of interorganizational choreography operations with the predefined process execution plan. Indeed, our approach aims to restrict the access to internal resources by filtering incoming calls taking into account the context of the call and the controlflow of the involved inter-organizational process. Further-more, outgoing calls are also controlled aiming to prevent from divulging sensitive information in unexpected ways (i.e. without a coherent inter-organizational process context).

We first argue that our components should be policy-based as well as separated from the business application. This allows components to be managed centrally by a governance layer. The policies can be then audited, stored, traced, and historically managed.

The value added by this paper is that it deals with these issues in an event based way. In our approach, each message received or sent is associated to an event. Following the principle of Complex Event Processing (CEP), we use event patterns to filter and monitor desirable incoming and outgoing calls. This allows processing to be performed asynchronously which leads for a better responsiveness and less network traffic than the alternative request/response message exchanges. Furthermore, event processing, which becomes commonly used for monitoring and notification issues, helps us to get a dynamic and efficient decentralized way for errors notifications, along with providing execution traceability. At the time of writing this paper, there are no standards for event processing programming languages. Motivated by its notational simplicity, we have chosen RAPIDE-EPL to give an idea about how to implement our rules in practice. However, there are various languages and programming styles that can be used.

As future work, we intend to extend the architecture by additional event-driven components responsible for exceptions detection and reporting by sending external notification to the involved partners when an internal exception is raised. Moreover, and in order to further improve our message control, we are planning to extend the EFP table with additional fields imposing temporal and cardinality constraints.

Figure 1 .

 1 Figure 1. Motivating scenario.

  Figure 2.a. shows the global view of the choreography presented in the previous scenario.

  Figures 2.b

  , 2.c, 2.d and 2.e show the calculated local view of each organization participating in our scenario.

Figure 2 .

 2 Figure 2. Choreography views.

  Figure 4 presents an abstract view of the organization architecture. A further technical description follows.

Figure 4 .

 4 Figure 4. Organization architecture.

Figure 5 .

 5 Figure 5. Events definition using RAPIDE-EPL.

Figure 6 .

 6 Figure 6. Event Pattern Rules definition

Policy Enforcement Point / Policy Decision Point