Keywords:

Over the last decade, companies have increasingly search for managing their processes from technical and business perspectives. Management, in this case, can be of three types: technical management, business goals-based management, and business environment-aware management. While a lot of work has been done on technical and business goals-based management, only few work dealt with business environmentaware management (BEAM).

However, there is also a great need to manage business processes from a business environment point of view due to continuous business environment changes. Indeed, companies struggle to find a balance between adapting their processes and keeping competitiveness. While the imperative nature of business processes is too rigid to adapt them at run-time, the declarative one of the purely rule based business processes is, however, very time consuming. Hybrid approaches in turn try to reconcile between these approaches aiming to reach the market requirements. Nevertheless, they also need an effort for aligning business logic and process logic.

Therefore, in this thesis, we focus on business environment-aware management of service-based business processes (SBPs) aiming at conciliating imperative and declarative approaches. Our challenge is to develop a hybrid management approach that preserves industry standards to describe and to manage SBPs as well as minimizes designers' efforts. Based on a semantic modeling of business environment, business processes as well as their relationships, and a control dependency analysis of business processes, we are able to synthesize a controller, itself modeled as a process, connected to the business process to be monitored and configured at run-time. We also validated the feasibility of our management approach by implementing the framework Business Environment-Aware Management for Service-based Business processes (BEAM4SBP). Experimentations show the efficiency of our approach with respect to other BEAM approaches.

Résumé

" Les entreprises adoptent de plus en plus les processus métiers pour automatiser leurs activités. Cependant, ces entreprises opèrent dans un environnement métier très dynamique. Un environnement métier représente tous les facteurs externes à l'entreprise qui influencent son fonctionnement tels que les facteurs sociaux, économiques, etc. En opérant dans un environnement métier dynamique, les politiques des entreprises changent. Par conséquent leurs processus doivent être gérés et adaptés de point de vue métier. Ainsi, nous référons dans cette thèse par gestion sensible aux changements de l'environnement métier pour les processus métiers qui consiste à configurer ces processus afin de changer leurs comportements en réponse aux évènements de l'environnement métier.

Il existe trois types d'approche de gestion sensible aux changements de l'environnement métier : à savoir les approches impératives, déclaratives et hybrides. Les approches déclaratives sont basées sur les règles. Ainsi, elles sont très flexibles puisqu'on peut ajouter, supprimer ou modifier une règle lors de l'exécution. Cependant, elles sont très couteuses en termes de temps à cause de l'inférence de l'environnement métier. De plus, le processus doit être re-modéliser en règles. En contre partie, les approches impératives sont très efficaces mais trop rigide puisqu'il faut spécifier les actions de gestion lors de la modélisation des processus. Les approches hybrides, à leur tour, essaient de concilier entre les approches impératives et déclaratives afin d'augmenter le niveau concurrentiel des entreprises. Néanmoins, elles nécessitent un effort d'alignement entre la logique métier et la logique du processus. En outre, nous constatons que certaines approches ne sont pas faisables en pratique puisqu'ils n'utilisent pas les standards des processus. De plus, l'efficacité et la flexibilité sont antagonistes.

Pour résoudre ces problèmes, nous fixons les objectifs suivants : (1) concilier les techniques déclaratives et les techniques impératives en une approche hybride pour tirer profit de leurs avantages, (2) préserver les standards des processus, et (3) minimiser l'effort des concepteurs. Nous avons ainsi proposé une nouvelle approche hybride pour la gestion des processus métiers. Nous avons modélisé la gestion d'un processus métier par un processus de gestion connecté au premier qui permet de le superviser et le configurer. Ce processus de gestion est généré grâce à une modélisation sémantique des relations entre les processus métiers, les services et l'environnement métier. Nous avons également implémenter cette approche et l'évaluer en comparaison avec les approches existantes de gestion sensible aux changements de l'environnement métier.

Mots clés: processus métiers, environnement métier, efficacité, flexibilité i [4]. . . . . . . . . . . . . 2.7 Relationship between decision services and assistant services [4]. . . . 2.8 Definition of a variation point in VxBPEL [START_REF] Koning | Vxbpel: Supporting variability for web services in bpel[END_REF]. . . . . . . . . . . . . .

Research context and problem statement

More and more companies are using business processes in order to automate their activities [8].

Over the last decade, companies were interested in managing their business processes from technical and business perspectives. Indeed, business processes encounter highly dynamic business and execution environments. Therefore, in order to keep high level of competitiveness within markets, companies have ever been interested in managing performance and quality of their processes to face business and technical changes at runtime [START_REF] Aschoff | Qos-driven proactive adaptation of service composition[END_REF][START_REF] Bartolini | Business-driven it management[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF][START_REF] Wil | Business process management: A survey[END_REF][START_REF] Karagiannis | Business process management: A holistic management approach[END_REF].

Management of business processes can be performed according to three different sides: business goals, business environment and execution environment. The business goals of a process define the targets of a business enterprise such as increasing revenues or reducing outgoings. The execution environment represents the Information Technology (IT) where the service operates. It includes process engines, applications, servers, machines, network and their properties, etc. Whereas, the business environment connotes all factors external to the business enterprise that greatly influence its functioning. It covers economic, political, natural, social factors (e.g. during a sales promotion, there is a decrease of clothes prices), etc.

Accordingly, we identify three types of business process management at run-time: technical management, business goals-based management, and business environmentaware management (BEAM). The technical management [START_REF] Zheng | QoS management of web services[END_REF] focuses on monitoring and configuring execution environments of business processes (e.g. process containers, memory, CPU). Business goals-based management [START_REF] Bartolini | Business-driven it management[END_REF][START_REF] Branimir Wetzstein | Towards measuring key performance indicators of semantic business processes[END_REF]16] aims at aligning business goals with IT services. It is often specified using Key Performance Indicator (e.g. order fulfillment lead time < 3 days). However, BEAM [START_REF] Boukhebouze | A rule-based modeling for the description of flexible and selfhealing business processes[END_REF][START_REF] Gottschalk | Configurable workflow models[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]4] connotes monitoring and configuring business processes in order to change their behavior in reaction to business environment events.

We notice that there were great efforts in dealing with technical management of business processes (e.g. [START_REF] Aschoff | Qos-driven proactive adaptation of service composition[END_REF], [START_REF] Zheng | QoS management of web services[END_REF] and [START_REF] Ghezzi | Run-time monitoring in service-oriented architectures[END_REF]). There were also great efforts in managing business processes from a business goal point of view that aims to align business goals and IT aspects of business processes (e.g. [START_REF] Branimir Wetzstein | Towards measuring key performance indicators of semantic business processes[END_REF], [16], [START_REF] Bartolini | Business-driven it management[END_REF], [START_REF] Casati | Businessoriented management of web services[END_REF] and [START_REF] Bratanis | Towards run-time monitoring of web services conformance to business-level agreements[END_REF]).

Beside technical management as well as alignment of IT and business goals, we argue, in this thesis, that there is also a great need to manage business processes from a business environment point of view (i.e. BEAM). Indeed, enterprises are more and more within highly competitive and constantly changing business environments.

Introduction

Thus, they need to focus on adapting their business processes to address competitions and changes within such environments.

We distinguish two main types of approaches of BEAM: imperative and declarative. On one hand, declarative approaches describe both the business process and its management based on rules (e.g. Event-Condition-Action rules) (see for example [START_REF] Boukhebouze | A rule-based modeling for the description of flexible and selfhealing business processes[END_REF][START_REF] Weigand | Business policy compliance in service-oriented systems[END_REF]). They are flexible, since their managing rules are well adapted to be added, removed or changed at runtime. Nevertheless, they are time consuming because of inference over rules that should be made in reaction to each change in a business environment. In addition, declarative approaches may not adopt standard notations for business process modeling such as Business Process Model and Notation (BPMN) [START_REF]Business process model and notation 2[END_REF] or Business Process Execution Language (BPEL) [24]. As a result, the process designer ought to re-model the process based on rules. On the other hand, imperative approaches describe both the business process and its management as an imperative process. It consist in hard coding management actions into the managed business processes. Consequently, they may preserve standard notation for business process modeling and may be very efficient, in terms of execution time. Nevertheless, they are too rigid due to over-specifying processes at design time. It is then difficult if not impossible to change the management rules at runtime. Therefore, different approaches (e.g. [START_REF] Gottschalk | Configurable workflow models[END_REF][START_REF] Koning | Vxbpel: Supporting variability for web services in bpel[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]4]) put forward hybrid techniques by separating business logic which defines the company's policies (described using Business Rule) and the process logic (described using imperative business process). This separation needs an effort of business process and business rule integration by using for example aspect-oriented approaches which later on raises issues on maintainability and transformation [25]. Furthermore, some approaches may need designers efforts (e.g. [3,[START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]) or did not preserve industry process standard language (e.g. [START_REF] Milanovic | Towards a language for rule-enhanced business process modeling[END_REF]).

Hence, declarative approaches may be flexible in general and may not utilize process standards which make them difficult to use in practice. Furthermore, they are very time-consuming. Imperative approaches are efficient but they are not flexible enough to easily address changes in business environments. Hybrid approaches that separate business process and business rule need efforts of alignment at run-time. approach allows getting benefit from both of them. This could become necessary in order to keep a high level of competitiveness by reconciling between the efficiency and the flexibility of business processes.

Preserving business process industry standards when describing and managing business processes makes the BEAM approach feasible in practical use. Indeed, companies are more and more using business process standards. Hence, instead of proposing new languages for managing business processes, there is a great need to keep using industry standards.

Minimizing process designers efforts makes the BEAM approach easier in practice for companies. The main goal is to discharge the process designer from additional tasks such as re-modeling business processes using new language or adding some configuration information such as variability points.

Approach

To achieve our targeted goals, we propose a novel hybrid approach for business environment-aware management of service-based business processes. Our proposed approach consists in modeling, monitoring and configuring actions as a management process connected to the business process to be managed (that we call managed process). Monitoring reads properties of services that compose the business process while configuration alters values of these properties. Our main challenge is to generate the management process based essentially on a semantic model describing business environment events, business processes, services and their relationships.

As a result, contrary to the imperative approaches, in our approach, the management process defines several management paths. Therefore, it can encapsulate different management behaviors. The choice of a management path is based on events of the business environment which are semantically described. Consequently, our approach presents a degree of flexibility inherited from declarative approaches. In addition, our approach is proved efficient, compared to declarative approaches, since it models the management of a business process as a process connected to it. Moreover, our approach minimizes process designers efforts since it doesn't define new management rules but generates automatically the management process based only on semantic annotations. Third, as opposite to hybrid approaches separating business processes and business rules, our approach is based on a synergic use of semantic services and an upper management ontology which facilitates the alignment between the business environment and business processes.

Introduction

we investigated, throughout this thesis, how to generate the management process automatically. The issue is how to compose management operations in order to alter service properties.

In order to generate this management process, we propose a semantic model. We also adopted and adapted a dependency analysis strategy in order to explicitly describe the structure of the managed process.

Hence, the second contribution of this thesis is a semantic model describing business processes, services, business environment and relationships between them. It describes essentially an upper management ontology correlated with a domain ontology. It is used for annotating semantic services and facilitating the management process generation.

The third contribution consists in adapting a dependency analysis strategy in order to identify dependency analysis relationships between services or activities of a managed process written in BPMN. In fact, generally, data and control dependencies are dimensions solely for programming (or programming-like) langages. However, we argue that the unstructured and highly parallel real world processes written in BPMN render them inadequate which requires some adaptations. Thereby, in this thesis, we adapted and tailored their dependency analysis strategy according to BPMN 2 requirements.

To test the feasibility of the proposed approach, we implemented a business environment-aware management framework getting as input the managed process and the corresponding domain ontology, while resulting the adequate management process.

To evaluate the expressiveness of our approach, its efficiency and flexibility, we established qualitative and quantitative evaluations.

Outlines

This thesis includes 8 chapters organized in three parts.

The first part includes chapters 1 and 2 which present the state of the art and the background of our research work. In chapter 1, we discuss briefly the service and SBPs facets and their different management types. We also present a typical scenario to motivate and illustrate our approach. In chapter 2, we review the work related to our thesis. We study different approaches on business environment-aware management. We introduce their models and analyze their solutions. This analysis allows us to identify the objectives of our research work.

Chapters 3, 4 and 5 represent the second part which details the contributions of our thesis. Chapter 3 overviews our approach to manage service-based business processes against business environment events and represents the proposed semantic model used for facilitating the management process generation. In chapter 4, we present our adopted and adapted dependency analysis strategy for facilitating the management process generation. It explicits both control and data dependencies for BPMN business processes. Chapter 5 shows how to generate a management process based on both the proposed semantic model and the dependency analysis of a managed process.

In the third part of this thesis (chapters 6, 7 and 8), we present applications and experiments to validate and evaluate our approach. Indeed, in chapter 6, we present our BEAM4SBP framework and its integration into the Activiti business process engine. Both chapters 7 and 8 represent qualitative and quantitative experiments of our approach compared to the existing business environment-aware management approaches.

Finally, we summary our work and give an outlook to the future work.

Part I

State of the art

Chapter 1

Facets and management types of service-based business processes

Introduction

Business processes represent a key concept for automating companies' activities [8].

The Workflow Management Coalition (WfMC) defines a business process by: "A set of one or more linked procedures or activities which collectively realise a business objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships" [START_REF]Workflow management coalition terminology & glossary[END_REF]. Service-based business processes (SBPs) are business processes where some activities are realized by services. Business processes and their services have two types of facets: business and technical facets. The business facet represents business goals and business environments of processes and services, while the technical facet represents the implementations and the execution environment of services and processes.

SBPs are more and more encountering highly dynamic business and execution environments. Therefore, companies have ever been interested in managing performance and quality of their processes to face business and technical changes at run-time [START_REF] Aschoff | Qos-driven proactive adaptation of service composition[END_REF][START_REF] Bartolini | Business-driven it management[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]. In fact, managing processes and services in this case consists in two main activities: monitoring and configuration.

According to facets of SBPs, we distinguish three types of management: technical management, business goals-based management and business environment-aware management. The technical management monitors service/business process implementation (e.g. QoS) and configures accordingly the execution environment [START_REF] Ben Halima | A largescale monitoring and measurement campaign for web services-based applications[END_REF]. The business goals-based management monitors business goals and configures technical facets [START_REF] Bartolini | Business-driven it management[END_REF]. However, the business environment-aware management monitors changes in the business environment and configures technical facets.

In the following sections, we briefly discuss issues on service and business process facets. Besides, we introduce an overview of their different management sides based on a running example in order to give general bases for the upcoming chapters.

10

Facets and management types of service-based business processes

Facets of service-based business processes

SBPs, we are dealing with, are used to meet a specific business goal by executing a set of coordinated activities where some of them are realized through services. Thereby, before introducing business process facets, we start by depicting service facets.

Service facets

As shown in Figure . 1.1, a service has business facets and technical facets. Business facets include business goals and a business environment. In addition, technical facets comprise both an implementation and an execution environment. In the following, we detail each facet:

• Business goals represent what the service achieves from a business perspective.

They are clear targets that need to be reached to satisfy a business solution.

• Business environment connotes all factors external to the business company that greatly influence its functioning. It covers economic, social, political, natural, etc. factors.

• Execution environment represents the Information Technology (IT) where the service operates. It includes process engines, applications, servers, machines, network and their properties, etc.

• Service implementation includes technical and operational aspects. The technical aspects tell "what the service does" (e.g. interface, operation, input, output, pre-condition...) as well as "how to access to it" (e.g. binding, protocols...). Whereas, the operational aspects describe how the service works internally. They comprise functional and behavioral characteristics. They can be described imperatively (e.g. C, JAVA) or delaratively (e.g. rule-based: ECA-rule, ECAPE-L [START_REF] Boukhebouze | A rule-based modeling for the description of flexible and selfhealing business processes[END_REF]). The service behavior can change by modifying the behavior of its operations or by changing their coordination.

Business process facets

Similarly to a service, a business process has business goals and an implementation including its operational aspects and technical aspects (Figure . 1.1). It operates within an execution environment and interacts with a business environment. The business goals of a process define the targets of a business enterprise such as increasing revenues or reducing losses. The operational aspects which represents the functional and behavioral aspects can also be written in imperative description by service compositions or processes such that some activities are implemented by services (e.g. BPEL [24], XPDL [28]) or declarative description based on rules.

Business

Imperative description of business process operational aspects

The operation aspects of business processes are described using modeling languages. A first family of modeling languages for business processes consists in imperative languages (or procedural languages) which focus on how different process activities are performed (i.e. the execution scenario which represents an ordered sequence of activities is described in an explicit way). There are many imperative business process modeling languages. We distinguish high level process languages (e.g. BPMN, UML) and execution process languages (e.g. XPDL, BPEL). UML is also used to model business processes using the activity diagram [START_REF] Russell | On the suitability of UML 2.0 activity diagrams for business process modelling[END_REF]. This latter has been revised to be more suitable for process modeling in UML 2.0.

High level business process languages

Business process execution languages

• XML Process Definition Language (XPDL) is proposed by the Workflow Management Coalition which consists of many workflow system providers. XPDL specify business processes by defining activities, transitions, partners and interactions between them [START_REF]Process definition interfacexml process definition language[END_REF]. XPDL is adopted by many workflow engines.

• Business Process Execution Language (BPEL) is an OASIS standard executable language for specifying actions within business processes with web services [24]. BPEL messages are typically used to invoke remote services, orchestrate process execution and manage events and exceptions. Figure 1.2 illustrates a portion of BPEL purchase order process.

Declarative description of business process operational aspects

The operational aspects of business processes can be described declaratively such that a process is considered as a set of states and a set of constraints controlling transitions between states. In order to present these states and constraints, declarative languages use different paradigms.

Case-handling paradigm

The case-handling is a new paradigm proposed by Van der Aalst et al. in [START_REF] Wil | Case handling: a new paradigm for business process support[END_REF] in order to model business processes flexibly. Contrary to the imperative modeling using predefined process control structures to identify what should be done, case handling focuses on what can be done to achieve a business goal. It is strongly based on data as the typical product of these processes (called cases) allowing designers to Execute, Skip or Redo process activities according to cases availability. The case-handling paradigm was adopted in the workflow management system called FLOWer [START_REF] Dumas | The FLOWer Case-Handling Approach: Beyond Workflow Management[END_REF]. Linear Temproral Logic (LTL) paradigm The Linear Tempral Logic can be used to model business processes declaratively. The LTL is a modal temporal logic with modalities referring to time. i.e. A proposition could be false at one point of time, then becomes true later on. This paradigm was used in the ConDec language propsed by Pesic et al. [START_REF] Pesic | A Declarative Approach for Flexible Business Processes Management[END_REF].

Deontic Logic paradigm

The deontic logic can also be used to model business process in declarative manner. This logic formalizes the possible variants of business activity execution: the obligation, prohibition and permission. This will take into account obligations and permissions in business interactions. The deontic logic has been used in the PENELOPE language proposed by Goedertier et al. [START_REF] Goedertier | Designing compliant business processes with obligations and permissions[END_REF].

Facets and management types of service-based business processes

Event-Driven process paradigm The Event-Driven process paradigm is proposed to model and manage processes based on events by using the complex Event processing (CEP) formalism. This latter identifies the situations of a business process by selecting or aggregating events to launch the execution of a specific activity. This paradigm is used in the EPC (Event-driven Process Chain) method to specify business processes [START_REF]The Event-driven Process Chain[END_REF].

Rule-based modeling paradigm The rule-based modeling paradigm proposes to model the operational aspects by a set of rules using declarative languages. The Object Management Group (OMG) defines a business rule as "a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules which concern the project are atomic that is, they cannot be broken down further." [START_REF] Hay | Defining Business Rules -What Are They Really[END_REF].

According to [START_REF] Wagner | Rule Modeling and Markup[END_REF], we distinguish four categories of business rules: integrity, derivation, reaction and production.

• Integrity rules describe constraints. They consist of a constraint modality and a constraint assertion, which is a sentence in some logical language [START_REF] Wagner | Rule Modeling and Markup[END_REF].

• Derivation rules are also known as deduction rules. They express conditions that result in conclusions. These rules define the validity of facts and can be used to infer new facts based on known facts [START_REF] Michael Zur Muehlen | Modeling Languages for Business Processes and Business Rules: A Representational Analysis[END_REF].

• Reaction rules are also known as Event-Condition-Action (ECA) rules, alternativeaction rules, or post-conditions. They specify the event which occurs and express a specific situation. Then, the condition is evaluated and a subsequent of actions will react.

• Production rules consist of a condition and a produced action. They do not contain an event as the reaction rules.

There exist various rule modeling languages. Each one has its own expressive power. In the following, we shortly present these rule languages:

• REWERSE I1 Rule Markup Language (R2ML) The REWERSE I1 Rule
Markup Language is developed by REWERSE Working Group I1 in 2007. It is a comprehensive and user-friendly XML rule format that allows: (i) interchanging rules between different systems and tools, (ii) enriching ontologies by rules, (iii) connecting rule system with R2ML-based tools for visualization, verbalization, verification and validation [START_REF] R2ml | The REWERSE I1 Rule Markup Language Working Group I1[END_REF]. R2ML can support the four categories of rules which are integrity, derivation, reaction and production.

• Simple Rule Markup Language (SRML) The Simple Rule Markup Language was announced by ILOG in 2001. It describes a generic rule language consisting of a subset of language constructs common to the popular forwardchaining rule engines [START_REF] Srml | Simple Rule Markup Language[END_REF]. It does not use vendor-specific proprietary languages; therefore, rules can easily be translated to any other rule engine language. This makes it useful as an Interlingua for rule exchange between Java rule engines [START_REF] Srml | Simple Rule Markup Language[END_REF].

• Production Rule Representation (PRR) Production Rule Representation is an OMG standard published in 2002. As stated in [START_REF] Omg | Production Rule Representations[END_REF], the goals of PRR are : (i) accelerating adoption of production rule components in everyday software systems, (ii) improving the modeling of production rules, especially with respect to UML, (iii) allowing interoperability across different vendors providing production rule implementations. The PRR supports production rules in a forward chaining inference engine.

• Semantics of Business Vocabulary and Business Rules (SBVR) Semantics of Business Vocabulary and Business Rules [START_REF] Sbvr | Semantics of Business vocabulary and Rules[END_REF] is an adopted standard of the OMG. It provides a formal representation to business rules written in plain English or any other natural language. The SBVR specification is applicable to the domain of business vocabularies and business rules of all kinds of business activities in all kinds of organizations.

• Semantic Web Rule Language (SWRL) The Semantic Web Rule Language is a product of the World Wide Web Consortium (W3C). The SWRL supports the integrity rule. However, it is not yet standardized [START_REF] Chi | A Combination of Business Rule and Modeling Languages for Semantic Business Processes Modeling[END_REF].

Running example

Service and Business process facets are illustrated here by considering a representative example of ClothStore (fictitious name), a clothing store holding an e-commerce site. ClothStore offers products to its customers, interacts with two suppliers and a shipper for processing orders. It holds certain products in stock, and orders others from suppliers in case of product lack. The business process of the online shopping purchase order processing related to ClothStore is illustrated in the BPMN diagram shown in Fig. 1.3. This process behaves as follows: The customer sends a purchase order request with details about the required products and the needed quantity. Upon receipt of customer order, the seller checks product availability. If some of the products are not in stock, the alternative branch "ordering from suppliers" is executed. When all products are available, the choice of a shipper and the calculation of the initial price of the order Facets and management types of service-based business processes are launched. Afterwards, the shipping price and the retouch price are computed simultaneously. The total price is then computed in order to send invoice and deliver the products to the customer. Finally, a notification is received by the shipper assuring that the order is already delivered. The BPMN process shown in Fig. 1.3 represents an imperative business process implementation of the business process described above. It can be described declaratively based for instance on rules. For example, the activity "Check availability" can be described using an ECA-rule: ON order Receipt IF the order is valid Do check availability This latter business process of the ClothStore e-commerce site is running on top of three data center to store products and customers information. These data center represent the business process execution environment.

ClothStore fixes its revenues to be above 100.000 e per three months.In order to reach this busines goal, the ClothStore business process should be adapted in response to business environment changes. For example, during festive seasons, there is an increase in the demand for new clothes. Consequently, there is a need for much more servers and machines to execute the huge number of customers' requests.

Based on the service and business process facets illustrated above, we present in Section 1.3, the different types of management of SBPs.

Management of service-based business processes

Today, the maturation of Business Process Management (BPM) has enabled the linkage of business processes to IT services. Thereby, the management of a business process is highly relying on the management of its services.

As stated earlier, the management step consists of two main activities: monitoring and configuration. The monitoring aims at capturing and measuring required information. Subsequently, the configuration acts by setting or modifying some characteristics based on the monitored information. There are four source facets to retrieve information and two target facets to act on (Figure 1.4). In fact, information can be retrieved from the execution environment, the business environment, business goals and operational aspects. In case of deficiency or inadequacy, the execution environment or the operational aspects should be reconfigured. Indeed, the configuration of a business process includes: substituting a service by another one, configuring a service behavior or configuring the process control flow (e.g. an operator of the service composition). According to the business service/process facets that are involved in the management, we distinguish three types of service-based business process management at run-time (Figure 1.4): technical management, business goals-based management and business environement-aware management.

In the following subsections, we detail these management types.

Technical Management

The Technical Management (TM) of SBPs aims at monitoring technical facets and configuring accordingly the execution environment in case of quality degradation (Figure 1.4). As stated in Section 1.1, the operational aspects of SBPs are based on Service Oriented Architecture (SOA) [START_REF] Papazoglou | Service-oriented computing: State of the art and research challenges[END_REF]. Since services constitute among others the building blocks of a SBP, the global QoS of a business process depends on the QoS of its services as well as their coordination. Indeed, TM is usually engaged in measuring non-functional (e.g. QoS related) properties [START_REF] Ghezzi | Run-time monitoring in service-oriented architectures[END_REF] (Figure 1.4). For each service in the example introduced in Section 1.2, we can compute its response time, availability rate, etc. These characteristics are considered in the Service Level Agreement (SLA).

In case of SLA violation, the execution environment should be reconfigured. For instance, the operational aspects of a process can be configured by substituting the low quality service by a new one having the same functionality [START_REF] Aschoff | Qos-driven proactive adaptation of service composition[END_REF]. The goal is then to select the best service available at run-time, taking into consideration process constraints and the execution context [START_REF] Raman Kazhamiakin | Adaptation of service-based systems[END_REF]. Thereby, the adaptation in this case relies on service selection and binding.

When monitoring the process load, in case of degradation, IT managers can adopt an elasticity solution by reconfiguring virtual machines. In [START_REF] Nguyen | A framework for dynamic resource provisioning and adaptation in iaas clouds[END_REF], Duong et al. propose to add or remove virtual machines on demand. In [START_REF] Bi | Dynamic provisioning modeling for virtualized multi-tier applications in cloud data center[END_REF][START_REF] Han | A deployment platform for dynamically scaling applications in the cloud[END_REF], the authors propose to compute the optimal number of virtual machines to be deployed according to variations of demands. Authors in [START_REF] Weissman | A framework for dynamic service adaptation in the grid: Next generation software program progress report[END_REF][START_REF] Amziani | Formal modeling and evaluation of stateful service-based business process elasticity in the cloud[END_REF] use duplication/consolidation mechanisms to provide elasticity of dynamic service deployment. Indeed, if the availability of a service is of low quality, the execution environment can deploy a new service replicate. While, the consolidation decision aims at removing an unnecessary copy of a service in order to meet its workload decrease.

Besides, in order to provide better quality, process instances can be migrated

Facets and management types of service-based business processes from one site to another. Indeed, process instance migration consists in transferring a running process instance to another engine in order to continue process execution at another site if any issue affects the initial hosting site. This may help the resolution of execution problems when mobile devices change local contexts or when process resource requirements increase dynamically [START_REF] Hamann | Process instance migration: Flexible execution of distributed business processes[END_REF].

Business Goals-based Management

Business Goals-based Management (BGM) of SBPs is the configuration of their technical facets based on the monitoring of business goal metrics (Figure 1.4). Over the last decade, companies have increasingly search for managing their processes from a business perspective. In fact, a major concern for companies is to ensure the efficiency and performance of their business processes relatively to business goals. More precisely, it consists in aligning business goals with IT infrastructure and service/ business process quality [START_REF] Bartolini | Business-driven it management[END_REF][START_REF] Casati | Businessoriented management of web services[END_REF][START_REF] Bratanis | Towards run-time monitoring of web services conformance to business-level agreements[END_REF]. For example, the business goal of a shipping service can be: "the number of undelivered orders may not exceed 2 per month". To meet this goal based on the business goal metric "undelivered orders ≤ 2", the availability of the shipping service should be 99%. Since 2003, the term "business oriented management" has been used to name aligning business goals with IT services [START_REF] Casati | Businessoriented management of web services[END_REF]. Alternative used terms include: "Business-Driven IT management [START_REF] Bartolini | Business-driven it management[END_REF], "Business centric monitoring" [START_REF] Geetika | A business centric monitoring approach for heterogeneous service composites[END_REF], business/IT alignment, etc. In [START_REF] Jacques | Looking at business through a keyhole[END_REF], authors present the challenge of business/IT alignment by presenting weaknesses of Service Level Agreement (SLA) in capturing the different service business needs. Thereby, Bratanis et al. [START_REF] Bratanis | Towards run-time monitoring of web services conformance to business-level agreements[END_REF] introduce the Business Level Agreement (BLA) which is a contract combining non-functional and functional characteristics of a service.

At business process level, process quality goals are specified in terms of Key Performance Indicator (KPI) [START_REF] Branimir Wetzstein | Towards measuring key performance indicators of semantic business processes[END_REF]16]. The used KPIs are key metrics (with technical or business meaning) with target values which are to be achieved in certain analysis period (e.g., order fulfillment lead time < 3 days). They are monitored using Business Activity Monitoring (BAM). In [START_REF] Branimir Wetzstein | Identifying influential factors of business process performance using dependency analysis[END_REF][START_REF] Branimir Wetzstein | Monitoring and analyzing influential factors of business process performance[END_REF][START_REF] Raman Kazhamiakin | Adaptation of service-based applications based on process quality factor analysis[END_REF], authors propose a method to adapt processes by identifying influential factors of business process performance. Since KPIs potentially depend on numerous lower level PPMs (Process performnace metrics) [16] and QoS metrics, the adaptation action "substitute a service with another service" may be realized.

Business Environment-Aware Management

Business Environment-Aware Management (BEAM) of SBPs is the configuration of their technical facets based on the monitoring of business environment metrics (Figure 1.4). In fact, the competitiveness of business enterprises is deeply related to adapting their processes against business environment changes [START_REF] Boukhebouze | A rule-based modeling for the description of flexible and selfhealing business processes[END_REF][START_REF] Gottschalk | Configurable workflow models[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]4]. The business environment is dynamic in nature. It keeps on changing and differs from place to place according to social, political, technological... factors.

These changes have a direct impact on the service and process behaviors. Subsequently, it affects the operational aspects (Figure 1.4). For example, during sales promotions, there is a contestable and non-constant decrease of prices. In that case, the behavior of the service "calculate initial price" will change frequently since the discount rate can be modified constantly. Then, the purchase order process changes its behavior accordingly. Besides, during a festive season the execution path can change when choosing suppliers in response to the higher demand of clothes. Configurable services or business rules may be used to take into account these changes.

Conclusion

In this chapter, we identified three types of business process management namely, technical management, business goals-based management and business environmentaware management. However, we notice that there was a great effort in adopting 20

Facets and management types of service-based business processes

technical management. There were also efforts in managing SBPs from a business point of view. Nevertheless, this type of management is effectively a business goalsbased management, often called business/IT alignment.

Beside technical management and alignment of IT and business goals, we argue that there is also a great need to manage business processes from a business environment point of view (i.e. BEAM). Indeed, enterprises are more and more within highly competitive and constantly changing business environments. Thus, they need to manage their BPs to address competitions and changes within business environments.

In this thesis, we focus on BEAM of SBPs. More details about existing approaches of BEAM of SBPs are given in the following chapter.

Introduction

In this thesis, we are interested in BEAM of SBPs. As we stated in Section 1.3, the management of SBPs consists in two main activities: monitoring and configuration. The monitoring captures business events sent by the business environment, while the configuration alters operational aspects accordingly.

The operational aspects of business processes can be described by imperative processes (e.g. BPMN, BPEL) (see Section 1.1.2.1). They can also be described declaratively based on case-handling paradigm, Linear Temporal Logic paradigm, deontic logic paradigm, event-driven process paradigm or rule-based modeling paradigm (see Section 1.1.2.2). In this thesis, we focus on declarative descriptions based on rules.

The configuration of a business process can also be described using rules, imperative processes or both of them. The management of a business process (called later-on managed process) can be accordingly defined by three different approaches: declarative, imperative or hybrid.

The imperative approach describes both the managed process and its configuration based on an imperative process. Regarding the declarative approach, the managed process and its configuration are described based on rules. As for hybrid approaches, they integrate imperative and declarative approaches. Most hybrid approaches integrate imperative business processes and business rules [START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]. The managed process and its configuration are respectively described based on an imperative process and rules.

In the following sections, we present these management approaches illustrated by the running example. Besides, we review existing businesss environment-aware management approaches.

22

Business Environment-Aware Management approaches 2.1 Types of business environment-aware management approaches

The imperative approach

In the imperative approach, the operational aspects (Figure 1.1) of the managed process are described based on an imperative process (Section 1.1.2). The configuration is described as an imperative process, too. Indeed, it consists in adding a set of process fragments to the managed process. Hence, all the configurations are modeled within the managed process as process fragments described imperatively.

In imperative approaches, managed processes and their configuration are described using process languages such as BPEL, XPDL and BPMN.

Coming back to the running example, the configurations of the purchase order process are shown in bold in Figure 2.1. The operational aspects of the managed process represent the rest of activities. Indeed, in case of sales promotions, the configuration represents the fragment consisting of five activities computing the discount rate delimited with two gateways: Event based gateway and exclusive gateway.

The declarative approach

In declarative approaches, the operational aspects of the managed process are described declaratively (rule-based). Alike, its configuration is described declaratively based on rules. In fact, the configuration consists in adding, modifying or deleting a rule in case of business environment change. The declarative approaches are then purely based on rules.

In declarative approaches configuration may be described using many rule modeling languages such as Semantics of Business Vocabulary and Business Rules [START_REF] Sbvr | Semantics of Business vocabulary and Rules[END_REF], Simple Rule Markup Language [START_REF] Srml | Simple Rule Markup Language[END_REF], Rewerse l1 Rule Markup Language [START_REF] R2ml | The REWERSE I1 Rule Markup Language Working Group I1[END_REF], ECAPE-L [START_REF] Boukhebouze | Towards an approach for estimating impact of changes on business processes[END_REF], etc. Resuming with the running example reported in Section 1.2, Figure 2.2 shows the activities of the purchase order process modeled based on rules according to the ECAPE model of the ECAPE-L rule language [START_REF] Boukhebouze | Towards an approach for estimating impact of changes on business processes[END_REF]. For example, Rule 1 expresses the policy of receiving an order. This rule is activated by "begin process" event that represents customer order. The execution of "receive order" activity triggers "order received" event. The latter will activate Rule 2 that expresses the policy of checking availability (Figure 2.2). Hence, the activities "Receive order" and "check availability" of the purchase order process are implemented by Rule 1 and Rule 2. During a sales promotion, a discount rule (Rule 13) is added and the relationships with the existing rules are established (Figure 2.2).

The hybrid approach

Generally speaking, hybrid approaches combine declarative and imperative approaches. Indeed, the operational aspects are described as an imperative process where some activities are described declaratively based on rules.

The configuration of the managed process is then based on rules that are integrated in some activities (called business rule tasks). Hence, the configuration consists in adding, modifying or deleting business rules in business rule tasks.

The managed process is then described using for example BPMN 2.0, which include business rule task.

Figure 2.3 shows the purchase order process written in BPMN 2.0 such that certain activities are described declaratively based on business rule tasks. Indeed, instead of implementing five activities for computing the discount rate in the imperative approach or adding a discount rule in the declarative approach, the activity "compute initial price" is performed by business rule task invoking a discount rule (Rule 2).

Review of existing business environment-aware management approaches

As today's business environments keeps changing, there is a need for business processes to be adaptive yet competitive. Unfortunately, the static nature of business process definitions (imperative description) makes it impossible to configures them at run-time and the redeployment of a modified process is required. On the other hand, all the rule based approaches apply pure rule based methodology (declarative approches) which can be time-consuming. Therefore, different approaches try to add a dimension of flexibility while keeping efficiency. This is done by using rules, variability, etc.

Rule-based approaches

Different approaches [START_REF] Gottschalk | Configurable workflow models[END_REF][START_REF] Koning | Vxbpel: Supporting variability for web services in bpel[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]4] try to integrate these two techniques in a joint approach by separating business logic (described by Business rules) and process logic (described by imperative BP). This separation needs in turn an effort of BP and BR integration.

Charfi et al. [25] focus on Aspect Oriented Programming(AOP) in order to integrate Business rules and the process logic at run-time. Indeed, the business rules are proposed to be implemented in an aspect-oriented extension of BPEL called AO4BPEL. AO4BPEL is used to weave the adaptation aspects into the process at run-time. Although they preserve BP standards, the weaving phase can strongly limit the process efficiency at run-time since it can raise issues on maintainability and transformation. The business rules actions and results are translated to business process constructs and to so-called "point-cuts" (statements to relate the aspect to specific points in the code such as every assign activity). This requires a modified BPEL engine to be able to cope with the additional aspects.

Ouyang et al. [START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF] introduce an ECA-based control-rule formalism to modularize the monolithic BPEL process structure. Only one classification of rules is defined that handle the control flow part of the composition linking activities together. In this work, the designer should also take into account the defined ECA-control rule and specifies his process accordingly.

Authors in [START_REF] Milanovic | Towards a language for rule-enhanced business process modeling[END_REF], propose a hybrid solution presenting a modeling language that integrates both rule-and process-oriented modeling perspectives. As shown in Figure 2.4, the language (Rule-based BPMN -rBPMN) is based on the integration of the Business Process Modeling Notation with the REWERSE Rule Markup Language (R2ML). The integration is based on the RuleGateway. This element is an extension of the BPMN Gateway class and refers to one or more R2ML Rules. Thus, an R2ML Rule can be placed into a process as a Gateway. Each rBPMN rule gateway might be associated with more than one rule. In [START_REF] Milanovic | Modeling flexible business processes with business rule patterns[END_REF], authors use the rule patterns of this new language to create flexible processes: control flow decision pattern, data constraints and dynamic business process composition. Although this approach provides a dimension of flexibility and efficiency, proposing a new language remains a handicap for companies that use existing business process standards.

In [3], Cheng et al. provided a bottom-up approach to integrate process models and business rules models in both design and analysis stages (Figure . 2.5). This approach is specific to integrate BPMN process models with SBVR rules models. It used XPDL to translate the BPMN diagrams to text representation and then used these tags to map the business rules models, and finally producing a new model that includes both the process and the rules. The approach did not invent a new language. It made use of XPDL and its ability to translate BPMN diagrams into XML tags. The main contribution is providing a list of the main components of the process language (BPMN) and the rules language (SBVR), and using XPDL to map these components to each other. Nevertheless, the mapping phase might be time-consuming at run-time.

In [START_REF] Zoet | Alignment of business process management and business rules[END_REF], Zoet et al. aligns business process management with business rules. Indeed, they propose business rule categorization that is aligned to the business process management lifecycle. BRM formulates constraints based on descriptions and facts while BPM addresses business operations from an activity approach. In this paper, authors propose to synchronize them based on rule categorization. They distinguish between: structural sequencing rule, Actor Inclusion rule, Outcome control rule.

Gong and Janssen introduce in [4] a combination between semantic services and business rules in order to manage business processes at run-time. They create business processes dynamically (Figure 2 orchestrated with the managed business process. This approach increases the flexibility at run-time while the process efficiency decreases since services are composed on the fly based on a domain ontology.

Variability-based approaches

Rule-based management/adaptation is not the only mechanism to provide flexibility in a process-aware information system.

The service based business process can also be adapted by explicit variability modeling [START_REF] Raman Kazhamiakin | Adaptation of service-based systems[END_REF].

Variability represents the key concepts of product-line technology which can be used to make service-oriented applications more flexible. It allows among others runtime flexibility. Authors in [START_REF] Galster | Variability in web services[END_REF] distinguish two categories of variability in service based systems: variability inside a service and variability in the service based architecture (i.e. the composition of services / service based business processes).

The first category focuses on the variability inside a service with services as reconfigurable units that can be adapted for different contexts. Going into more details with variability inside a service, Galster et al. identify two main types: (1) variability in parameters required by a service and (2) variability in parameter values. The first type consists in varying the type of data sent at service invocation. For example, data sent to a service might be a single variable or an array of variables. This type of variation is usually expressed in Web Service Definition Language (WSDL) documents. The second type consists in varying the value of a parameter used at invocation. For example, the discount rate of a product differs from one sales season to another.

The second category, variability in the service based architecture, consists of three main types: logic variability, variability in the web service flow, and composition variability.

Authors in [START_REF] Koning | Vxbpel: Supporting variability for web services in bpel[END_REF], present an adaptation of BPEL language called VxBPEL. They emphasize on the lack of flexibility and variability when deploying BPEL processes. Thus, they propose to extend BPEL language by adding Variation Points and Variants (Figure . 2.8). The former represents the places where the process can be configured, while the latter defines the alternative steps of the process that can be used. According to the running example, the VxBPEL fragment shown in Figure 2.8 could contain a Variation Points name="Discount Rate". This variation point shows variability in the way dicount rate is determined. Variants for this variation Business Environment-Aware Management approaches point are Variants name="Fisrt Discount" and Variants name="Second Discount". Based on the selected variant, either a service for First discount is envoked or the second Discount service is processing. In this work, the variability is focused on BP aspects written in VxBPEL language. The designers should consider this extension and add their variation when designing the BP. VxBPEL supports service replacement, different service parameters, and changing system composition.

Other approaches, such as [START_REF] Gottschalk | Configurable workflow models[END_REF][START_REF] Koning | Vxbpel: Supporting variability for web services in bpel[END_REF], address management issue by process variants. When modeling process and their variants, one has to decide which control flow alternatives are variant-specific and which ones are common for all process variants. However, these process variants ought to be configured at configuration time which leads to a static instance of the process model at run-time.

Synthesis

Table 2.1 summarizes the surveyed approaches and derives the following synthesis. The defined criteria are rated as high level support (++), support (+), partial sup-Figure 2.7: Relationship between decision services and assistant services [4]. port (+/-) and no support(-). We notice that efficiency and flexibility almost in all approaches in the table are antagonistic. In fact, when increasing the flexibility, the efficiency decreases accordingly and vice versa. Furthermore, none of approaches presented in [START_REF] Boukhebouze | A rule-based modeling for the description of flexible and selfhealing business processes[END_REF][START_REF] Gottschalk | Configurable workflow models[END_REF]4] utilizes BPEL or any other process standard, which renders them difficult to use.

For this sake, we recall the following challenges addressed in this thesis:

• How to conciliate between imperative and declarative techniques in an integrated hybrid approach while aligning operational and business perspectives?

• How to develop a hybrid management approach that preserves industry standards to describe and systems to manage SBPs?

• How to minimize designers efforts?

Conclusion

As business environment changes keep increasing, enterprises are always seeking for a balanced solution to manage their BPs. However, most research works have focused on efficiency or flexibility using either imperative or declarative techniques. Therefore, different approaches [START_REF] Gottschalk | Configurable workflow models[END_REF][START_REF] Koning | Vxbpel: Supporting variability for web services in bpel[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]4] try to integrate these two techniques in a joint approach by separating business logic (described by Business rules) and process logic (described by imperative BP). In this chapter, we presented these different business environment aware management approaches. We showed that existing approaches are efficient or flexible. We also presented the differences between current approaches and our targeted approach. In the next chapter 3, we introduce an overview of our approch consisting in generating a management process connected to the managed process to be monitored and configured. Besides, we present a semantic model which facilitates the management process generation.

Contributions Introduction

This chapter presents our contributions for business environment-aware management of service-based business processes (SBPs). The main idea is to manage SBPs against business environment changes, while conciliating imperative and declarative approaches, preserving business process standards and minimizing designers efforts. Only a SBP and its corresponding domain ontology are the input of our contributions. We do not ask process designers to re-model their processes. Hence, our approach is based essentially on semantic descriptions.

In this chapter, we firsltly present our approach overview. Then, we detail our propsed semantic model. The work of this chapter has been published in [START_REF] Bouchaala | A hybrid approach for business environment-aware management of service-based business processes[END_REF].

Approach overview

In our research work, we focus on SBPs where some activities are realized by services. We consider that the management of a composition of services that offer management operations (for their monitoring and configuration) can be realized through the composition of the offered management operations [START_REF] Bouchaala | A hybrid approach for business environment-aware management of service-based business processes[END_REF]. The enactments of management operations are triggered by events that are captured from the business environment. The integration of management operations and business environment events forms a business process called the management process.

Indeed, for a given managed process, our approach generates the corresponding management process. Figure 3.1 illustrates the purchase order process and its corresponding generated management process.

38

A hybrid approach for business environment-aware management of service-based business processes

In fact, to take into account the business environment changes into the managed process, we use service properties that can be adjusted. Service properties allow for the configuration of an implementation with externally set values. The value for a service property is supplied to the implementation of the service each time the implementation is executed. In particular, the internal value of a property can be altered at any time through business management operations which enable its monitoring and configuration. The monitoring step reads properties while the configuration one updates them if necessary. When altering the property value, the corresponding service changes its behavior. For example, the service "Compute initial price" (Figure 3.1) has a property named "DiscountRate" which can change its behavior by a setter operation when a sales promotion is triggered. Besides, during a festive season the execution path can vary when choosing suppliers in response to the higher demand of clothes. In fact, the service "Choose supplier" changes its behavior by updating its property "CriteriaList".

As we already mentioned, when changing a service behavior, the corresponding business process is reconfigured and its behavior is accordingly modified.

Thus, the first step towards the automation of the management operations composition is to identify the semantic concepts of service properties from the managed business process. The issue is how to modify these properties and to follow which order to compose management operations. To deal with this issue, we consider three statements:

• Statement 1: Events represent the glue between business environments and SBPs. Events may trigger the update of service properties. Hence, there is an Environment-Service relationship.

• Statement 2: Service properties may depend on each others. Accordingly, modifying a service property may engender changes of others depending on it. Consequently, there is a Service-Service relationship.

• Statement 3: The structure of the managed business process may guide the order of management operations that modify properties.

Based on these statements, we propose an algorithm for generating the management process. This latter is based on three main phases: (1) constructing subprocesses based on Environment-Service relationships, (2) constructing sub-processes based on Service-Service relationships, (3) connecting the resulting sub-processes into the management process based on the structure of the managed business process.

As shown in Figure 3.1, the first phase builds sub-processes illustrated with dashed rectangles. The second one generates sub-processes represented in dashed ellipses. The third phase adds operators and connections shown in bold.

Semantic modeling of service-based business processes and business environment 39

In order to facilitate the management process generation, there is a need for (1) an appropriate semantic model of business environments, business processes and relationships between them as well as (2) a dependency analysis of the managed business process. The semantic model represents an upper management ontology, which correlated with a domain ontology, depicts a declarative description of the company management strategy against dynamic change of the business environment. It involves Environment-Service and Service-Service dependencies. In addition, the dependency analysis aims at describing explicitly control dependencies between services of the managed business process in order to deduce the composition of their corresponding management operations [START_REF] Bouchaala | Dat: Dependency analysis tool for service-based business processes[END_REF].

More details for the proposed semantic model and the dependency analysis of the managed process are given respectively in Section 3.2 and Chapter 4.

Management process

Purchase Order process

Semantic modeling of service-based business processes and business environment

The management process generation requires semantic descriptions of business environment, SBPs and relationships holding between them. Indeed, as shown in Figure 3.2, there are three main actors in BEAM: business environment, business process and services. The business process has a service composition which consists of activities and gateways. Activities are realized by services. Services may have service properties and management operations. Services interact with the business environment. This latter engenders events that trigger management operations which act in turn on service properties. These three concepts represented in grey ellipses in Figure 3.2 describe, at a high level of abstraction, the A hybrid approach for business environment-aware management of service-based business processes main concepts of the management ontology.

In the following subsections, we start by depicting the upper management ontology (section 3.2.1). Then, we describe the SBP by giving a semantic service model (section 3.2.2).

Upper management ontology

Based on the BEAM meta-model (Figure 3.2), we define an upper management ontology (UMO) correlated with a domain ontology (Figure 3.3). Top-level ontologies or Upper ontologies are models of the common objects that are generally applicable across a wide range of domain ontologies. It contains a core glossary in whose terms objects can be described. A domain ontology (or domain-specific ontology) models a specific business domain, or part of the world (e.g. e-commerce domain, medical domain, etc.). It represents the particular meanings of terms as they apply to that domain.

The UMO correlated with the domain ontology, is used for annotating semantic services and facilitating the management process generation as well. The UMO main Semantic modeling of service-based business processes and business environment 41 concepts are events, properties and management operations. They represent an ontological modeling of the relationships between business environment, processes and services. They are described against a domain ontology defined by domain experts. The UMO includes also two main relationships:

• Environment-Service relationship (Event-based relationship): Events trigger Actions (management operations) which act on services properties (e.g. the "Festive Season" event triggers "SetCriteriaList" operation which updates the "CriteriaList" property).

• Service-Service relationship (Data-based relationship): Each service property has service properties that may depend on it (e.g. "ShippingPrice" and "RetouchPrice" service properties depend on "DiscountRate" property).

In the following, we detail the main concepts of the upper management ontology as well as their relationships.

Events

Events play a prominent role in BEAM, since they are the glue between situations in the real world and SBPs. Thus, in the following, we detail event semantics and definitions based on the expressiveness of BPMN 2.0 [START_REF]Business process model and notation 2[END_REF]. Events are used to model something happening in the process lifetime (e.g. festive seasons, sales promotions). They affect the flow of the process by catching a trigger or throwing a result. Event definitions represent the semantics of events. In BPMN 2.0, there are 10 event definitions among them we use: Message, Signal, Timer and Conditional.

For instance, refering to Figure 3.3, the event "FirstSalesPromotion" is composed of two atomic events having respectively timer and message event definition. The timer event "PromotionTimeDate" is used to detect that the promotion time date is reached. While, the message event "DiscountRateMessage" is used to define a discount rate message in order to catch the discount rate information.

Alike, the event "FestiveSeason" consists of two atomic events having message and timer event definitions. The timer event "FestiveTimeDate" catches the beginning of the festive season. The message event "CriteriaListMessage" catches the criteria list to choose the adequate supplier.

Service Properties

A single business service operation can have different behaviors depending on the business context (e.g. the service "choose supplier" selects supplier 1 or supplier 2 according to the existence or not of a festive season (Figure 3.1)). The more business contexts increases, the more the variability of the service operation is crucial. When business processes specifying service operations, it is necessary to define the various contexts of use to model variabilities. In this work, we define service properties which represent the variability of services composing business processes. Once set, the operation is able to take account of its business context to adapt its behavior.

Regarding the Service-Service relationship, services properties may or not depend on each other . For example, both "ShippingPrice" and "RetouchPrice" service properties depend on the "DiscountRate" service property. Whereas, "ShippingPrice" and "RetouchPrice" do not depend on each other (Figure 3.3). In case of dependency, we can distinguish three types of relationships namely: sequence, mutuality and exclusivity. For instance, a "SupplementaryDiscountRate" property is applied sequencially after the "DiscountRate" property (Figure 3.3). A "DiscountRate" property and a "LoyalDiscount" property are exclusive and can not be combined in a public sales promotion. These relationships can be identified from the ontology through RDF containers such as RDF:Seq, RDF:Bag and RDF:Alt.

Management operations

Management operations represent actions triggered by business environment events to alter or read service properties. They are means to perform the configuration and the monitoring of services and business processes in turn. The management operations are given by the service provider since they are related to the business of the service. However, we can help the service provider to generate these operations through semantic annotations. Nevertheless, in this thesis, we are limited to setter and getter operations generated automatically.

The relationships with business operations represent the management operation types:

• Transformation (Configuration): The management operation can configure a service by updating the property (setter: set operation) (e.g. setDiscountRate, setCriteriaList (Figure 3.3 and Figure 3.1)).

• Consultation (Monitoring): The management operation can also monitor the service property (getter: get operation (e.g. getDiscountRate (Figure 3.3 and Figure 3.1)).

Semantic modeling of service-based business processes

Services represent the building block of SBPs. Hence, we start by presenting the service model. Then, we introduce the business process model. Accordingly, a service is defined as follows:

Definition 1. Semantic Service Model. We refer to each service by a tuple S = (p, T A, OA) such that:

• p = (name, value, concept) is the service property

Service-based business process model

A SBP is represented by a set of activities, gateways and possibly events. Certain activities are realized by semantic services. The service composition of a SBP may be described using a business process standard (e.g. Event-driven Process chains (EPC),

Semantic modeling of service-based business processes and business environment 45

Business Process Execution Language (BPEL), Business Process Modeling Notation (BPMN), etc). Hence, we define a SBP as a process graph (Definition 2). Definition 2 is inspired from the business process graph definition given in [START_REF] Remco | Graph matching algorithms for business process model similarity search[END_REF].

Definition 2. Process graph. Let Γ 1 be a set of node types. Let Θ 1 be a set of node labels. A process graph P G is represented by a tuple P G = (V 1 , E 1 , τ 1 , θ 1 ) where:

• V 1 is a set of vertices
• E 1 is a set of edges modeling the control flow of the business process

• τ 1 : V 1 → Γ 1 is
a function that maps vertices to types.

• θ 1 : V 1 → Θ 1 is a function mapping vertices to labels comprising <(vertex type,vertex name), unique number in the business process>

Each vertex is annotated with a pair indicating the vertex type, name and its corresponding unique number in the business process. As stated earlier, the available types of vertices depend on the adopted business process standard notation. In this thesis, we consider the BPMN notation which distinguishes between activities ('a'), gateways ('g'), and events ('e'). There are also different types of BPMN gateways and events.

Based on Definition 2, Figure . 3.4 shows the process graph of the purchase order process (Figure 1.3). The activity name, the gateway type and the event type represent possible vertex labels (e.g. <('a', 'receive order'),1>, <('g','AND-split'),11>, <('e','start event'),0> ).

Conclusion

In this chapter, we presented a novel hybrid approach for business environmentaware management of service-based business processes. Our approach consists in generating automatically a management process to monitor and configure a given managed process. Indeed, automated composition of management operations and business events is one of the most promising challenges in our approach for BEAM of SBPs. The management process generation is performed thanks to a semantic model of SBPs and business environments as well as a dependency analysis of the managed process.

The semantic model involves an upper management ontology, describing relationships between SBPs and business environments. This ontology aligns business processes, services and business environments. In order to evaluate the expressiveness and the semantic richness of our upper management ontology, we compare it to existing business rules languages with respect to a representation theory. Details about this qualitative evaluation are given in Chapter 7. business processes <(e, 'start event'),0> <(a, 'receive order'),1> <(g, 'OR-split'),3> <(a, 'Check availability'),2> <(a, 'choosesupplier'),4> <(g, 'OR-split'),5> <(a, 'contactsupplier 1'),6> <(a, 'contact supplier 2'),7> <(g, 'OR-join'),8> <(a, 'receive products'),9> <(g, 'OR-join'),10> <(g, 'AND-split'),11> <(a, 'compute initial price'),12>

<(e, 'End event'),20> <(a, 'send order and invoice'),18> <(a, 'compute total price'),17>

<(a, 'compute retouch price'),13> <(a, 'compute shipping price'),15> <(a, 'choose shipper'),14> <(g, 'AND-split'),16> <(a, 'Receive delivery notification'),19> Semantic modeling of service-based business processes and business environment 47

The dependency analysis explicits the structure of the managed process. This latter is based on identifying control and data dependencies to facilitate the organization of the whole management process. In the next chapter, we present the dependency analysis of a given managed process.

Introduction

Control and data dependencies represent prominent information that supports business process management. However, sequencing constraints described by the control structures befog the true source of dependencies. Therefore, they are often not explicitly presented and are rather implicitly contained in the business process description. A description of a SBP is written in a business process standard language such as Business Process Execution Language (BPEL) [START_REF]Bpel: Who needs it anyway?[END_REF], XML Process Definition Language (XPDL) [28], etc.

Nowadays, there has been an increasing trend toward the direct execution of business processes modeled in Business Process Modeling Notation (BPMN) [START_REF]Business process model and notation 2[END_REF] on engines such as jBPM [67] and Activiti [START_REF]Activiti[END_REF]. Indeed, more than 70 tools support BPMN 2 (see www.bpmn.org). The purpose of BPMN 2 is twofold: (1) facilitating the communication and decision making between domain analysts by enhancing the expressiveness against the business environment (models can be as precise as required by the business context), (2) executing these models directly without mapping problems. The first purpose targets business analysts since real world business processes are able to be modeled directly using directed graphs.

However, there is neither tailored support nor implemented tool for dependency analysis of such processes. In fact, most research works [START_REF] Mao | Slicing web service-based software[END_REF][START_REF] Zhou | Control and data dependencies in business processes based on semantic business activities[END_REF][START_REF] Wu | Categorization and optimization of synchronization dependencies in business processes[END_REF][START_REF] Spassov | Ddat: Data dependency analysis tool for web service business processes[END_REF][START_REF] Winkler | Analysing dependencies in service compositions[END_REF][START_REF] Henniger | Test generation based on control and data dependencies within multi-process sdl specifications[END_REF][START_REF] Monsieur | Managing data dependencies in service compositions[END_REF] define dependency information for BPEL programs. Indeed, BPEL is a structured, more programming-like language having the same kind of logic and control structures [START_REF] Ouyang | From business process models to process-oriented software systems[END_REF]. Nevertheless, business analysts have to deal with the real world, which might be not only unstructured but highly parallel. The fact is that there are parallel unstructured SBPs that cannot be expressed directly into a parallel structured ones [START_REF] Vigneras | Why bpel is not the holy grail for bpm[END_REF][START_REF]Bpel: Who needs it anyway?[END_REF][START_REF] García-Bañuelos | Pattern identification and classification in the translation from bpmn to bpel[END_REF].

Hence, in general, data and control dependencies are dimensions solely for programming (or programming-like) langages. However, we argue that the unstructured and highly parallel real world processes written in BPMN render them inadequate which requires some adaptations. Thereby, in this chapter, we adapted and tailored their dependency analysis strategy according to BPMN 2 requirements [START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF].

In order to explicitly describe the structure of a SBP written in BPMN, we analyze its dependencies (section 4.1) and model them as a dependency graph (section 4.2).

The work of this chapter has been published in [START_REF] Bouchaala | Dat: Dependency analysis tool for service-based business processes[END_REF].

Dependency analysis

Dependency analysis identifies execution-order constraints between activities and services in a business process program. Broadly speaking, an activity A 2 depends on A 1 if A 1 must be executed before A 2 . There are two main classes of dependencies: control dependencies and data dependencies. In order to analyze control and data dependencies in business process programs, we build on the process graph definition (Definition 2) where nodes are labeled distinguishing node types.

In the following subsections, we conduct the example of the purchase order process written in BPMN 2 (Figure 1.3) in order to illustrate the control and data dependencies.

Control dependency analysis

The control dependency is a situation in which a program's instruction executes if the previous instruction evaluates in a way that allows its execution [START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF]. For example, the activity "choose supplier" is executed if some of the products are not available in stock.

For each program, a control flow graph (CF G) is usually generated in order to facilitate the dependency analysis. A CF G is a graphical representation of all paths that might be traversed through a program during its execution [START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF]. However, such CF G needs extensions for business process languages. Indeed, in BPMN programs (similarly in BPEL programs as discussed in [START_REF] Mao | Slicing web service-based software[END_REF]) there are parallel executions as well as synchronized executions which can obfuscate the true control dependency that we call here "common control dependency". In particular, BPMN (real world) processes present unstructured and highly parallel situations. Therefore, we propose to model business process as process graphs (Definition 2) where nodes are labeled distinguishing between gateway types.

Intuitively, given a P G, a node w is commonly control-dependent on a node u if node u determines whether w is executed. Generally, the common control dependency is defined in terms of post-dominance [START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF]. In fact, combining control flow and dominance information produces control dependence information. Definition 3. Post-Dominance [START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF]. Given a process graph P G, node B is said to post-dominate node A if every path from A to exit contains B.

For example, in Figure 3.4 and Figure 1.3, node <('a',"Compute total price"),17> post-dominates <('a',"Check availabilty"),2>. However, <('a',"receive products"),9> doesn't postdominate <('a',"Check availability"),2>. Definition 4. Common Control dependency [START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF]. Let P G be a process graph. Let X and Y be nodes in P G. Y is control dependent on X iff • There exists a directed path P from X to Y with any Z in P post-dominated by Y

• X is not post-dominated by Y For example, Y =<('a',"receive products"),9> is control dependent on X =<('g',"ORsplit"),3> where the condition is the availability or not of the products order. A direcrt path P from X to Y contains: <('a',"choose supplier"),4>, <('g',"OR-split"),5>, <('a',"contact supplier 1"),6>, <('g',"OR-join"),8>. Each Z in P is postdominated by Y . X=<('g',"OR-split"),3> is not postdominated by <('a',"receive products"),9> as illustrated in Definition 4.

Based on Definition 2, we can identify the parallel executions which represent sub-graphs between ('g', "AND-split") and ('g', "AND-join") nodes in BPMN.

Example of Parallel subgraph: {<('a',"compute initial price"),12>, <('a',"compute retouch price"),13>, <('a',"choose shipper"),14>, <('a',"compute shipping price"),15>, <('a',"compute initial price"),12>, <('a',"compute retouch price"),13>), (<('a',"choose shipper"),14>, <('a',"compute shipping price"),15>}.

The control dependency graph (CDG) represents an explicit description of control dependencies between activities as well as their types. We distinguish three types of control dependencies: "common control-dependency", "parallel dependency" and "synchronized-dependency". As claimed in [START_REF] Mao | Slicing web service-based software[END_REF], the "synchronized-dependency" connects the first node of a parallel branch with the first node of the other. Similarly, it connects the last nodes of parallel branches. Thereby, a CDG is defined as follows: Definition 5. Control dependency graph. Let Ψ 2 a set of edge types. Let Θ 2 be a set of node labels and Ω 2 a set of edge labels. A CDG is a labeled typed directed graph CDG = (V 2 , E 2 , ψ 2 , θ 2 , ω 2 ) with:

• V 2 represents the nodes of P G graph • E 2 represent a set of edges • ψ 2 : E 2 → Ψ 2 is
a function that maps edges to types: common-control dependency, parallel dependency, synchronized dependency

• θ 2 : V 2 → Θ 2 is a function that maps vertices to labels (numbering function)

• ω 2 : E 2 → Ω 2 is a function that maps edges to labels

Coming back to the purchase order process, its control dependencies are coherently represented in Figure 4.1.

Data dependency analysis

Data dependency analysis identifies the potential for a value returned from a service to affect the computation in another. It is used to represent the relevant data flow relationships of a business process program. Indeed, it arises between two activities and/or services such that the first one is a data producer and the second is a data consumer. This type of data dependency is called Definition-Use (Def-Use). It represents the dominant data dependency type in process programming. In this section, we use the Def-Use graph in order to abstract data dependencies for business process standards. Hence, we start by reviewing the concept of Def-Use relation as discussed in [START_REF] Mao | Slicing web service-based software[END_REF][START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF][START_REF] Stafford | A Formal, Language-Independent, and Compositional Approach to Interprocedural Control Dependence Analysis[END_REF]. Then, we illustrate data dependencies with respect to the BPMN process illustrated in Figure 1.3. Definition 6. Variable Definition [START_REF] Mao | Slicing web service-based software[END_REF]. The assignment of a value to a variable x represents its definition: Def (x) e.g. The node <('a',"compute initial price"),12> outputs the variable initialprice: Def (initialprice) Definition 7. Variable Use [START_REF] Mao | Slicing web service-based software[END_REF]. The use of a variable x represents the use of its value: U se(x) e.g. the node <('a',"compute retouch price"),13> uses the variable initialprice: U se(initialprice) Definition 8. Def-Use graph [START_REF] Stafford | A Formal, Language-Independent, and Compositional Approach to Interprocedural Control Dependence Analysis[END_REF][START_REF] Wu | Categorization and optimization of synchronization dependencies in business processes[END_REF]. The Def-Use graph is a labeled directed graph DU G = (V, E, θ) such that:

• V is the set of process graph vertices (services)

• E is the set of edges

• θ : V → (n, l
) is a function that maps vertices to ordered pair (n,l) where:

l: a label illustrating the Def and/or Use of variables n: represents the corresponding node number in P G as defined in Definition 2

The Def-Use graph of the purchase order process is depicted in Figure 4.2. (e.g. The node <('a',"compute initial price"),12> in P G has its corresponding number n = 12 in DU G. It uses variable unitP rice and defines variable initialP rice. It is then labeled with l = U se(unitP rice), Def (initialP rice).

Based on the Def-Use graph, the data dependency of two given nodes is defined as follows: Definition 9. Data dependency [START_REF] Mao | Slicing web service-based software[END_REF].

Let v u , v d ∈ DU G. v u is data dependent on v d iff:
• there exists a variable x such that v d contains Def (x) and v u contains U se(x)

• there doesn't exist variable redefinition of x within the path from v d to v u For instance, node 13 is data dependent on 12. Indeed, there exists a variable initialP rice such that node 12 contains Def (initialP rice) and node 13 contains U se(initialP rice) (see Figure 4.2).

The data dependency relationships are recorded in the data dependency graph defined as follows: Definition 10. Data dependency graph. Let Ψ 3 a set of edge types. Let Θ 3 be a set of node labels and Ω 3 a set of edge labels. A DDG is a labeled typed directed graph DDG = (V 3 , E 3 , ψ 3 , θ 3 , ω 3 ) with: • ψ 3 : E 3 → Ψ 3 is a function that maps edges to the type: data dependency

• V 3 ⊂ V 1
• θ 3 : V 3 → Θ 3 is a function that maps vertices to labels (numbering function)

• ω 3 : E 3 → Ω 3 is a function that maps edges to labels

Based on the DU G represented in Figure 4.2, the DDG of the purchase order process is described in Figure 4.3.

Dependency graph generation

Dependency graph generation

The results of data and control dependency analysis can be recorded in a directed labeled graph that we call Dependency graph. If an edge of control dependencies and/or data dependencies leads from one vertex to another in a dependency graph, then there is a dependency between the activities represented by the vertices. The dependency graph of the purchase order process is shown in Figure 4.4.

Control dependency graph generation

CDG is generated according to Algorithm 1 which takes as input the P G of a given business process. Indeed, given the P G of the purchase order process (Figure 3.4), Algorithm 1 outputs the CDG illustrated in Figure 4.1. This algorithm is inspired from [START_REF] Ferrante | The program dependence graph and its use in optimization[END_REF][START_REF] Mao | Slicing web service-based software[END_REF]. In the following, we detail its different parts consisting in identifying (1) common control dependency (Line 1-6)(2) parallel dependency (Line 7) and (3) synchronized dependency (Line 26-32).

As discussed in section 5, the first part is based on post-dominance. It comprises in turn three steps which we detail in the following subsections: (a) computing postdominators (Line 1), (b) generating PDT, (c) computing S, L and Marked (Line 3-6). In order to determine parallel dependencies, we search parallel sub-processes in P G (Line7). Based on parallel sub-graphs, synchronized dependencies are identified as stated in section 5.

The creation of CDG starts by adding the "entry" node (Line 8). Based on the resulting lists (marked nodes and their corresponding control dependent node), nodes that do not depend on any other node is added to CDG and linked with "entry" node (Line 9-12). Similarly, the rest of nodes are created and added in CDG while distinguishing between "parallel-dependency" and "common control dependency" (Line 13-24). Finally, edges labeled "synchronized-dependency" are added between: first nodes and last nodes of parallel branching (Line 26-32).

Computing post-dominators:

The first step towards identifying common control dependencies consists in computing post-dominators of each node v in P G. Based on Definition 4, the post-dominators of a node v represent the intersection of all paths containing no cycles from v to exit node.

Generating post-dominators Tree:

The second step creates the post-dominators Tree P DT . PDT involves all descendants of a node that are immediately postdominated by this latter. As a consequence, the tree root is always the node "exit". In order to generate the PDT, we define Algorithm 2 taking as input the list of post-dominators of each node. In each iteration, we remove the last added node from Postdom list (Line 6,7). If the post-dominators of the corresponding node are already added to P DT (Line 8), then it will be in turn added to the vertex set of P DT and linked to the last erased node (Line 9-13). The running node will be removed from nonDesigned and added to LastErased.

3.

Computing S, L, M arked and CD: After constructing the P DT , we identify the list of nodes M arked that are control dependent on CD. Prior to identify these two sets, we compute S defined as the set of edges (A, B) in P G such that B is not an ancestor of A in P DT . Algorithm 4 details these steps. We start by identifying edges (i, j) in P G such that j is not an ancestor of i in P DT (Line 8:

V 2 (CDG) ←-V 2 (CDG) ∪ {"entry"} 9: V 2 (CDG) ←-V 1 (P G)\ {marked(i)\CD(i)} 10: for all v ∈ V 2 (CDG) do 11: E 2 (CDG) ←-E 2 (CDG) ∪ {("entry", v)}
12: end for 13: for all i ∈ CD do 14:

if CD(i) ∈ V 2 (CDG) then

15:

for all j ∈ M arked(i) do 16:

V 2 (CDG) ←-V 2 (CDG) ∪ {j}
17:

E 2 (CDG) ←-E 2 (CDG) ∪ {(CD(i), j)} 18: if (j ∈ V (SG) | SG ⊂ SGs) then

19:

CDG.ω 2 ((CD(i), j)) = "parallel -dependency"

20:

else 21:

CDG.ω 2 ((CD(i), j)) = "commoncontrol -dependency"

22:

end if

23:

end for

24:

end if 25: end for 26: for all SG ∈ SGs do 27:

{P 1 , P 2 } ←-Searchpaths(SG, ( g , "AN D -Split"), ( g , "AN D -Join"))

28:

E 2 (CDG) ←-(P 1 (0), P 2 (0))

29:

CDG.ω 2 ((P 1 (0), P 2 (0))) = "synchronized -dependency"

30:

E 2 (CDG) ←-(P 1 (P 1 .length), P 2 (P 2 .length))

31:

CDG.ω 2 ((P 1 (P 1 .length -1), P 2 (P 2 .length -1))) = "synchronized -dependency"

32: end for

Algorithm 2 GeneratingPDTGraph

Require: List P ostdom, P G Ensure: PDT

1: SetnonDesingned ←-V (P G) \ {exit} 2: LastErased ←-{exit} 3: while nonDesingned = ∅ do 4:
for all i ∈ LastErased do

5:

for all j ∈ nonDesingned do 6:

if (i ∈ P ostdom(j)) then

7:

P ostdom(j) ←-P ostdom(j) \ {i} 8:

if (sizeof (P ostdom(j)) = 0) then

9:

nonDesingned ←-nonDesingned \ {j} 10:

V (P DT ) ←-V (P DT ) ∪ {(i), (j)}
11:

E(P DT ) ←-E(P DT ) ∪ {(i, j)} 12: N V ←-N V ∪ {j}

13:

end if

14:

end if

15:

end for

16:

end for

17:

LastErased ←-N V 18: end while In iteration i, all marked nodes are saved in M arked(i) (Line 18). Nodes of M arked(i) are control dependent on CD(i) (Line 19).

Data dependency graph generation

The data dependency graph generation is based on both the process graph (Figure 3. For each process variable x (Line 1), we find nodes in DU G such that their labels contains Def (x) (Line 2). By the same way, we fetch nodes in DU G where labels contains U se(x) (Line 3). Nodes labeled respectively Def (x) and U se(x) are added in DDG if the corresponding number of the first is smaller than the corresponding one of the second (Line 5,9).

Algorithm 3 ConstructSLMarkedCD

Require: PDT, PG.

Ensure: S = m i=1 {S i }, M arked = m i=1 {marked i }, CD = m i=1 {CDon i }, L = m i=1 {L i } 1: for all i ∈ N odeSet do 2:
for all j ∈ P G.adjacentT o(i) do

3:

if ( Ancestor(pdt, j, i)) then

4:

S ←-(i, j)

5:

end if

6:

end for 7: end for 8: for (i = 0 → sizeof (S)) do 9:

A ←-S(i)(0)
10:

B ←-S(i)(1)
11:

L(i) ←-Least(A, B)

12:

Bool inclus

13:

if (L(i) = A) then

14:

inclus ←-true 15:

else 16:

inclus ←-f alse

17:

end if

18:

M arked(i) ←-mark(inclus, L(i), B)

19:

CD(i) ←-A

20: end for

Algorithm 4 GeneratingDataDependencyGraph

Require: List P rocessV ariables, DU G Ensure: DDG 1: for all x ∈ P rocessV ariables do 2:

Find {v 1 } ∈ V (DU G) such that v 1 .θ.l contains Def (x)
3:

Find {v 2 } ∈ V (DU G) such that v 2 .θ.l contains U se(x)
4: end for 5: for all i ∈ {v 2 } do 6:

Find j ∈ {v 1 } such that v 1 .θ.n < v 2 .θ.n and v 1 .θ.n = M ax(v.θ.n)|v ∈ {v 1 } 7: V 2 (DDG) ←-V 2 (DDG) ∪ {v 1 , v 2 }
8:

E 2 (DDG) ←-E 2 (DDG) ∪ {(v 1 , v 2 )}

9: end for

Conclusion

Dependency analysis of SBPs provides relevant information for managing SBPs. In this chapter, we presented control and data dependencies for BPMN processes which describe explicitly their structure. BPMN 2.0, as a twofold-purpose language, can be used to both model and execute these SBPs. However, there is no tailored support for dependency analysis of such processes. Hence, we adopted and adapted definitions and algorithms of dependency analysis of programming languages in order to generate the dependency graph of a given SBP.

In order to validate these algorithms, we designed and implemented DAT, a dependency analysis tool for SBPs written in BPMN. Details of this framework are given in Chapter 6, Given a managed process, DAT generates its corresponding dependency graph which explicits its structure. This dependecny graph together with the semantic model facilitates the management process generation. In the next chapter, we present how to generate this management process.

Introduction

In this chapter, we show how to generate a management process to handle a SBP during its execution. We recall that properties of services that composed the management process frequently change due to business environment events. When a new event occurs, the adequate properties should be updated. Therefore, the management process consists in a composition of management operations that read and/or alter services' properties. To do this, we define a getter and a setter for each property (see Section 3.2.1.3).

The construction of the management process (composition of management operations) is performed using semantic descriptions over domain ontology (see Section 3.2) as well as the structure of the managed business process (see section 4.1). Thereby, the construction of the composition comprises three main phases: (1) constructing sub-processes based on the Environment-Service relationship, (2) constructing subprocesses based on the Service-Service relationship and (3) connecting generated subprocesses.

Algorithm 5 describes the statements executed for handling these phases which we detail in the following illustrated by the running example.

Properties externalize service behaviors. Thus, the first step towards the automation of the management operations composition is to capture the semantic concepts of services properties from the managed business process (Line 1). Each service property can have possible events that trigger the update of its value (Line 3). Thus, Con-structESR method (Line4) is called with p as parameter for building sub-processes relating configuration operations with events (Algorithm 6 in Section 5.1). Configuring a service property may engender the update of other properties related to it. Besides, the service property can have other relationships with other service properties. ConstructSSR (Line 5) is called in turn to build a sub-process connecting management operations with each other (Algorithm 7 in Section 5.2). Finally, ConnectSP (Line 7) is performed to connect resulting subprocesses based on both the structure of the managed SBP and semantic relationships between properties (Algorithm 10 in Section 5.3).

62

Management process generation

Doing so, we are based on the following BPMN patterns [START_REF] Wil | Workflow patterns[END_REF]:

• Basic control-flow patterns -Sequence: the ability to depict a sequence of activities -Parallel split: the divergence of a branch into two or more parallel branches executed concurrently.

-Synchronization: the convergence of multiple parallel branches into a single thread of control thus synchronising multiple threads.

-Exclusive choice: a decision point in a process process where one of several branches is chosen.

-Simple merge: a point in a process where two or more alternative branches come together without synchronisation.

• State-based pattern -Deffered choice: a divergence point in a process where one of several possible branches should be activated by the environment. In BPMN, this pattern is supported via an event-based exclusive gateway followed by either intermediate events using message-based triggers or receive tasks.

Algorithm 5 GeneratingManagementProcess

Require: Process Graph P G Ensure: Managing Graph M G 1: List P ←-{S.p.concept, S ∈ V1(P G)} 2: for all Properties p ∈ P do 3:

List L1 ←-FindEvents(p) 4: M G ←-ConstructESR(p, M G, L1) 5: M G ←-ConstructSSR(p, M G) 6: end for 7: M G ←-ConnectSP(P G, M G) 8: return M G

Constructing sub-processes based on Environment-Service relationship

In this first phase, the issue is to alter a service property based on the Environment-Service relationship introduced in Section 3.2.1. Indeed, when an event occurs the corresponding service property is updated according to dependencies between business environment events and services.

Constructing sub-processes based on Service-Service relationship

63

In accordance with the running example, when a "FestiveSeason" happens, the criteria for choosing suppliers change. Subsequently, the property named "CriteriaList" is altered. As stated in Section 3.2.1, the event "FestiveSeason" is composed of atomic events having event definitions: CriteriaListMessage and FestiveTimeDate.

In order to create sub-processes aiming at modifying a service property, Algorithm 6 is performed. These subprocesses relate a service management operation with possible events that can trigger it.

Figure 5.1(a) is the resulting sub-process for p="CriteriaList". Similarly, with p="DiscountRate" the sub-process described in Figure 5.1(b) is generated. Indeed, when a "Sales promotion" happens, there is a decrease in clothes prices (FirstDiscount). Subsequently, the property named "DiscountRate" is altered. As stated in section 3.2.1, the event "FirstSalesPromotion" is composed of atomic events having event definitions: DiscountRateMessage and PromotionTimeDate.

The list of possible events as well as their definitions (input of Algorithm 6) result from calling the procedure FindEvents(p) that executes the following SPARQL query: SPARQL Query 1: "SELECT ?atomicEvent ?eventdefinition WHERE { ?event :trigger ?action.

?action :act-on ?property. ?property rdf:type :p. ?event :hasEventstructure ?events. ?events :com-posedOf ?atomicEvent. ?atomicEvent :hasEventDefinition ?definition. ?definition rdf:type ?eventdefinition.}".

When an event occurs, the service property p will be altered automatically using a set operation. A vertex ("a", "set(p)") is added to the vertex-set of the managing graph MG (Line 2). If the list of possible events that can modify the property comprises only one event, we add this event to the set of vertices of MG graph (Line 4). A single edge between the event and the "set" operation is also added (Line 5). Otherwise, a node of gateway type labeled "Event-based XOR" is added (Line 7). Then, a node for each event and edges relating it to the gateway as well as the set operation are identified (Line 9, 10, 11).

In case there are no event related to p (Line 14), the events related to its super-ServiceProperty are identified (Line 15,16). Algorithm 6 is then recalled taking as input the list of these events (Line 18).

Constructing sub-processes based on Service-Service relationship

A service property may depend on others. Hence, updating a service property may engender the modification of others depending on it. Therefore, in this second phase, the concern is to properly identify the semantic relationship holding between service properties. For example, the service properties named "ShippingPrice" and "RetouchPrice" depend on "DiscountRate" property (Figure 3.3). Thus, if "DiscountRate" is up-

Management process generation

Algorithm 6 ConstructESR(ServiceProperty p, Managing Graph M G, List L 1 )

Require: Managing Graph M G Ensure: Managing Graph M G 1: if L1 = ø then 2: V3(M G) ←-V3(M G) ∪ {("a", "set(p)")} 3: if L1 = {l1} then 4:
V3(M G) ←-V3(M G) ∪ {("e", "l1")} 5:

E3(M G) ←-E3(M G) ∪ {(("e", "l1"), ("a", "set(p)"))} 6:

else 7: V3(M G) ←-V3(M G) ∪ {("g", "Event -basedXOR")} 8:
for all l1 ∈ L1 do 9:

V3(M G) ←-V3(M G) ∪ {("e", "l1")} 10:

E3(M G) ←-E3(M G) ∪ {(("g", "Event -basedXOR"), ("e", "l1"))} 11:

E3(M G) ←-E3(M G) ∪ {(("e", "l1"), ("a", "set(p)"))} 12:

end for 13:

end if 14: else 15:

String SuperServiceP roperty ←-FindSuperClassServiceProperty(p) 16:

SuperList ←-FindEvents(SuperServiceP roperty) 17:

if SuperList = ø then 18:

ConstructESR(p, M G, SuperList); 19:

end if 20: end if 21: return M G dated, both "ShippingPrice" and "Retouch price" should be updated. The corresponding resulting subprocess is depicted in Figure 5.1(c).

In order to generate this subprocess, Algorithm 7 explores the different dependency relationships between concepts of services' properties from the domain ontology. Two services properties have a relationship if they are related with "depends-on" relationship in the domain ontology. A SPARQL query is then sent to the domain ontology to enquire for the sources of the property p : SPARQL Query 2: "SELECT ?sourceType WHERE ?source :depends-on ?a. ?a rdf:type :p. ?source rdf:type ?sourceType. ?sourceType rdfs:subClassOf :ServiceProperty.".

The result of this query is performed by calling the procedure ServiceSourceOfDepends-On(p) (Algorithm 3, Line 1). If p has properties that depend on it (Line 2), then the get(p) operation is automatically invoked (Line 3). As a result, a setter for each property depending on p is defined (Line 4-6). If there is only one property, then a simple edge links its setter with get(p) (Line 7-8). Otherwise, the adequate gateway relating properties setters with get(p) is identified using Algorithm 8. In this latter algorithm, we rely on dependencies between services in the managed BP represented in the control dependency graph (see section 3.2.2.2). For example, the services "Compute retouch price" and "Compute shipping price" are synchronized according to the dependency graph of the purchase order process (Figure 4.1). Therefore, a gateway Connecting sub-processes 65 labeled ('g','AND-Split) is added. As for a well structured BP, when starting with a gateway type, we finish by the same one (Line 14 -17).

The relationship between services properties could be also clearly identified through the ontology via RDF containers (see section 3.2.1.2). Indeed, sequence, exclusivity and mutuality are described respectively via RDF:Seq, RDF:Alt, RDF:Bag. For example, the property "SecondDiscount" is composed of a sequence of "DiscountRate" and "SupplementaryDiscountRate". By calling ContainersRelationships(p), we execute SPARQL Query 3 in order to identify all containers in which p represents a member (Line 20). We identify the container type and the mother service property "MotherConcept" which includes container members among them p (Line [START_REF]Business process model and notation 2[END_REF]24). The containers members other than the current property p are identified by executing SPARQL Query 4 (Line 25). For each member concept, a new vertex representing an activity calling the management operation set(l) (l=member concept) is added (Line 26-28). According to the container type, we identify the connector type by executing Algorithm 9. If the container type is RDF:Seq, the connector type will be a sequence flow. The BPMN sequence pattern is then used in order to link the management operations (Line 31-33). Otherwise, the corresponding gateway is added and the links to the management operations are established (Line 37-39).

SPARQL Query 3: "SELECT ?containerType ?MotherIndividual ?MotherConcept WHERE {?container rdfs:member ?member. ?member rdf:type :p. ?container rdf:type ?containerType. ?Moth-erIndividual rdf:object ?container. ?MotherIndividual rdf:predicate ?MotherConcept.}". SPARQL Query 4: "SELECT ?memberType WHERE {?container rdfs:member ?member. ?member rdf:type ?memberType. ?container rdf:type ?containerType. ?MotherIndividual rdf:object ?container. ?MotherIndividual rdf:predicate :p.}".

Connecting sub-processes

So far, a set of sub-processes are created. Indeed, for each property sub-processes based on the Environment-Service and/or Service-Service relationship are built. How to connect them? How to determine their order? Resuming with the running example, till now, four sub-processes are built (see Figure 5.1). In order to connect them aiming to generate the whole management process (Figure 3.1), in this phase, we add necessary links and gateways based on both the upper management ontology and the explicit dependency description of the managed BP.

As a first step, we start by linking Event-based sub-processes according to the relationships between services properties. Hence, SPARQL Query 3 and 4 are respectively executed in Algorithm 10 to identify (1) the RDF container which determine relationships between these service properties (Line 4) and (2) container members (Line 5). if (ω1(e) = "synchronized -dependency") then 7:

GatewayType="AND-Split" 8:

end if 9:

if (ω1(e) = "commoncontrol -dependency") then 10:

GatewayType="OR-Split" Finally, the corresponding sub-processes are linked by choosing the adequate gateway (Line 7-9). For example, both sub-processes in Figure 5.1(b) and Figure 5.1(d) represent two discount strategies depicted in the domain ontology. These strategies, represented by the service properties "FisrtDiscount" and "SecondDiscount", are applied exclusively.

Figure 5.2 shows the resulting sub-process. Afterwards, we link the new list of sub-processes based on the control dependency analysis of the managed BP. To do so, we adopted the following phases: (1) identifying management process ends, (2) capturing their correspondings in the managed BP, (3) determining control dependencies for each activity in order to add corresponding gateways and (4) organizing results based on the control flow of the managed BP.

Formalisation of these phases is given in Algorithm 10. The first phase consists in finding nodes having no targets (set operations) and nodes having no sources (get operations) (Line 13). The second phase identifies nodes corresponding to these activities having p as property in the process graph (Line 14). Afterwards, the control dependency of each node is determined (Line 15). Control dependencies for each node are then compared in order to identify the existence or not of control dependency between sub-processes (Line 16-26). Then, according to control-flow relations between activities in the process graph, the sub-processes are organized and control flow edges are added to the managing graph (Line 28). Finally, nodes having no sources are linked to the start event, and those having no targets are connected to the end event (Line 31-35).

Resuming with the running example, in the first phase, the corresponding activities "Choose supplier" and "Compute initial price" of the management operations (Set(CriteriaList), Set(DiscountRate), Get(DiscountRate)) are identified. Coming back to the control dependency graph (Figure 4.1), "choose supplier" is control dependent on node 3. Thus, an "OR-split" gateway is added to the management process. By checking the non dependencies between both activities "Choose supplier" and "Compute initial price", an "Or-join" gateway is added to the management process. Then, based on the correspending unique numbers, we determine the order of the management operations and we add links. Figure 3.1 depicts the resulting management process.

Conclusion

In this chapter, we answer the following reseach question raised in Section 3.1: How to modify service properties and which order to follow to compose management operations? To do so, we defined three main phases for automatically compose management operations based on the semantic model and the dependency analysis of the managed process. The first phase consists in building sub-rocesses based on Environment-Service relationships. The second phase builds subprocesses based on the Service-Service relationships. Finally, the third phase connects the resulting sub-processes based on both the structure of the managed process and semantic description of service properties and events.

To validate our work, we implemented a framework that monitors and configures a given managed process. We also performed experiments using not only the running example but also BPMN control flow patterns. Details on implementation and experiments are presented in Chapter 6 and Chapter 8, respectively.

Introduction

To test the feasibility of our approach, we implemented a Business Environment-Aware Management Framework BEAM4SBP1 . In the following subsections, we start by presenting an overview of the BEAM4SBP architecture. Then, we present the Dependency Analysis Tool (DAT), plug-in of BEAM4SBP framework. Afterwards, we present the integration of BEAM4SBP into the Activiti process engine.

The BEAM4SBP framework

BEAM4SBP is a java library that enables to generate a management process connected to the managed business process allowing for its monitoring and configuration. Given the purchase order process (Figure . 1.3) and the purchase order ontology (Figure. 3.3), BEAM4SBP outputs the expected management process to connect to the purchase order process (Figure . 3.1). In the following, we present the framework's architecture.

As shown in Figure . 6.1, the architecture of BEAM4SBP is composed of four main components: (1) Process Graph Generator (2) Dependency Graph Generator (3) Jena module (4) Managing Graph Generator.

The first component involves a BPMN Parser developed to enable the process graph creation and takes as input a valid BPMN process (Section 3.2). It is developed using EMF [START_REF]Eclipse modeling framework project[END_REF] to generate a Java Model for the BPMN 2.0 specification described in XSD files. Indeed, EMF can easily generate a parser for any language specification given its meta-model. Based on the BPMN java model, we extract events and tasks. The extracted information are used to create the process graph (Definition. 2, Chapter 3) based on the Jgrapht java library [START_REF]Jgrapht[END_REF].

This latter represents the input of the Dependency Graph Generator component which outputs its corresponding dependency graph (Figure. explicit dependencies between activities. This component is also based on the Jgrapht library. It is implemented as a plug-in of BEAM4SBP (see Section 6.3).

The resulting dependency graph and the Jena module represent the inputs of the Algorithm 5 implemented by the Managing Graph Generator. This latter module outputs a managing graph representing the management process model (Section 3.2). The Jena Module implements the procedures FindEvents and FindSourceofDepend-sOn called, respectively, in Algorithm 6 and Algorithm 7.

The resulting managing graph is translated into a process description with flow nodes by the Management Process Generator module. Finally, the BPMN Writer outputs a BPMN file connecting the management process to the managed business process (Figure 6.2).

The Dependency Analysis Tool (DAT)

In this section, we present the Dependency Analysis Tool (DAT)2 which implements the Dependency graph Generator component depicted in Figure 6.1. We start by giving an overview of the DAT's architecture (Section 6.2.1). Then, we present its main functionalities (Section 6.2.2).

Architecture overview

DAT is a java library aiming at generating a dependency graph for a given business process. Given the BPMN business process, the DAT outputs the dependency graph shown in Figure The first module implements a Parser taking as input a well formed executable business process. The extracted information are used to create the process graph as well as the Def-use graph based on the Jgrapht java library [START_REF]Jgrapht[END_REF]. In this work, we developed a BPMN parser. BPMN processes are syntactically verified under Activiti 5.12 process engine [START_REF]Activiti[END_REF]. The BPMN file purchaseorderprocess.bpmn20.xml as well as a tutorial for creating executable BPMN processes are provided in the tab DOWNLOADS of the DAT's web site.

The Process Graph Generation module generates the process graph based on the parsing results. In case of BPMN processes, the extracted information are events, tasks, gateways, etc. The process graph involves event, gateway and task nodes (e.g. ('e', "startevent"), ('e', "AND-split")) (see Figure . 3.4).

The process graph represents the input of the Control dependency graph Generator module and outputs a control dependency graph allowing to get the explicit dependencies between activities. This module implements Algorithm 1 and is also based on the Jgrapht library. The resulting dependency graph involves labelled edges representing the edge type: "Common control dependency", "Parallel dependency", "Synchronized dependency". We extended the Jgrapht library by defining labelled edges inspiring from weighted edges. The identification of common control dependencies is done with three modules Compte Post dominators, PDT generator and Compute S, L and Marked that implements Algorithm 2 and Algorithm 5.

The third module outputs the Def-use graph which is created based on the extracted input/output of activities as well as the process graph. The created Def-use Graph correlated with the process graph represents the input of the Data Dependency Graph Generator module. This latter implements Algorithm 4.

DAT's functionalities

The framework provides two main functionalies aiming at identifying (1) data and control dependencies of one activity against all existing ones and particularly [START_REF] Milanovic | Towards a language for rule-enhanced business process modeling[END_REF] dependencies existing between two given activities.

Dependencies of an activity: Given the dependency graph, control and data dependencies relationships of one activity can be determined. In fact the framework takes as input an activity and outputs its different data and control dependencies. This functionality can be used in slicing programs [START_REF] Mao | Slicing web service-based software[END_REF] as well as managing SBPs [START_REF] Bouchaala | A Hybrid Approach for Business Environment-Aware Management of Service-Based Business Processes[END_REF].

Dependencies between two given activities: Introducing two activities, DAT provides control and data dependencies between them. This functionality can be used in modeling and managing business processes [START_REF] Bouchaala | A Hybrid Approach for Business Environment-Aware Management of Service-Based Business Processes[END_REF].

Integrating BEAM4SBP into Activiti

BEAM4SBP is generic and may be integrated with any process engine developed in Java (e.g. Activiti, jBPM, etc.). In order to test the resulting management process and the configuration at run-time of the managed process, we integrated the BEAM4SBP framework as a plug-in in the Activiti business process engine [START_REF]Activiti[END_REF].

In the subsequent subsections, we present the Activiti engine, the integration as well as a scenario of the process configuration.

Activiti Engine

Activiti [START_REF]Activiti[END_REF] is a framework that provides an environment for designing, implementing, deploying and running processes described in BPMN 2.0. It is an open source project distributed under the Apache license. Activiti is written in java; hence its core is a super-fast and rock-solid BPMN 2.0 process engine. The project of Activiti is funded by Alfresco and established by jBPM founder Tom Baeyens [START_REF] Rademakers | Activiti in Action: Executable Business Processes in BPMN 2[END_REF].

|P a g e 34

Activiti [START_REF] Hay | Defining Business Rules -What Are They Really[END_REF] is a framework that provides an environment for designing, implementing and running processes described in BPMN 2.0. It is an open source project distributed under the Apache license. One of its strengths is that it is written in java; hence its core is a super-fast and rock-solid BPMN 2.0 process engine. The project of Activiti is funded by Alfresco and established by jBPM founder Tom Baeyens [START_REF]The Event-driven Process Chain[END_REF].

Figure 2 shows a general overview of the Activiti components which make the whole framework. (The figure is adopted from [START_REF] Srml | Simple Rule Markup Language[END_REF]) there is Activiti Engine which is the core component of the Activiti project. It performs the process engine functions [START_REF]The Event-driven Process Chain[END_REF] such as deploying the business processes, starting instances, creating and executing workflow tasks.

In our work, the BEAM4SBP is accessible via Activiti Explorer as it provides an easy-to-use web interface. By definition, Activiti Explorer is a web-based application that can be simply used for various tasks in conjunction with Activiti Engine [START_REF]The Event-driven Process Chain[END_REF]. It is destined to both technical and nontechnical persons. From its interface, we can model a BPMN 2.0 process through the Activiti Modeler. We can also, deploy and run business processes thanks to the Activiti Engine.

Technically, the Activiti Explorer is a war file that should be deployed in a web server. So, we select the Apache Tomcat [START_REF] Bi | Dynamic provisioning modeling for virtualized multi-tier applications in cloud data center[END_REF] and it becomes accessed by using a web browser through: http://localhost:8080/activiti-explorer. As shown in Figure 6.4, Activiti is divided into three different parts. Activiti Modeler, Activiti Designer and Activiti Kickstart compose the modeling part applied to design BPMN 2.0 processes. The management part consists of Activiti Explorer and Activiti Rest. While, the runtime part comprises the Activiti Engine which is the core component of the Activiti project. It performs the process engine functions [START_REF] Rademakers | Activiti in Action: Executable Business Processes in BPMN 2[END_REF] such as deploying the business processes, starting instances, creating and executing workflow tasks.

Our BEAM4SBP framework will be accessible via Activiti Explorer as it provides an easy-to-use web interface. Activiti Explorer is a web-based application that can be simply used for various tasks in conjunction with Activiti Engine. It is developed to both technical and non-technical users. On one hand, they can model BPMN 2.0 processes through the Activiti Modeler. On the other hand, they can deploy and run business processes thanks to the core component Activiti Engine.

Technically, the Activiti Explorer is a war file that can be deployed in a web server such as Apache Tomcat [85]. Then, it is accessible through the following address: http://localhost:8080/activiti-explorer.

The integration

First and foremost, we conducted a deep study of the source code of Activiti Explorer. Then, we pointed out the files to be modified. The major challenge we encountered was keeping the proper functioning of Activiti Explorer since some files have been either changed or added.

In order to integrate BEAM4SBP into Activiti, we need the following software to be installed:

• Eclipse [86]: is an integrated development environment (IDE). It is an extensible plugin system for adapting the applications.

• The plugin m2eclipse [START_REF]Maven integration for Eclipse[END_REF]: manages Maven projects, executes Maven builds via the Eclipse interface, and interacts with Maven repositories. It makes the development easier with Eclipse IDE.

• Source code of Activiti: is downloadable from the following address: https: //github.com/Activiti/Activiti/releases

• Apache Maven [START_REF]Apache Maven[END_REF]: is a software project management and comprehension tool.

Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

• Apache Ant [START_REF]Apache Ant[END_REF]: is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications.

• Apache Tomcat [85]: is an open source web server and servlet container developed by the Apache Software Foundation (ASF). It implements the Java Servlet and JavaServer Pages technologies.

Details of the integration are described in a technical report for both developers and users [START_REF] Hadj | Technical report for beam4sbp integration[END_REF].

After having accomplished the integration, we generate a new war file for Activiti Explorer called "activiti-explorerM.war" including the BEAM4SBP framework. It can be downloaded from the following address: http://www-inf.int-evry.fr/ SIMBAD/tools/BEAM4SBP0.2/Integration/download.html.

The user has to copy this file into the webapps directory of Tomcat server and run the startup.bat from the bin folder. When Tomcat is started, Activiti Explorer becomes accessible via this new URL: http://localhost:8080/activiti-explorerM. Then, the user logs in with Kermit/Kermit.

After clicking on the "Manage" menu, the user should select the third sub-menu item "Upload with Business Management" from the "Deployments" menu bar (See Figure 6.5).

For example, supposing the file "PurchaseOrderProcess.bpmn20.xml" is uploaded. The purchase Order process is then deployed as shown in Figure 6.6.

At this step, instead of deploying this process lonely, the selected file will be the input of the plug-in BEAM4SBP in order to generate the management process. The output file of the plug-in is called "sortie.bpmn20.xml" and includes the initial business process together with the management process. Then, this output file will be deployed via Activiti Engine.

As depicted in Figure 6.7, in the "Process Definitions" side, there are two process "id" which represent, respectively, the managed process and the management process.

Finally, the user can run these processes through "Start Process" in the "Processes" menu.

For more details, we developed a web site including informations about the BEAM4SBP, the required tools and some instructions of how to use it. Also, we provide a demonstration video which could be found via this address: http://www-inf.int-evry. fr/SIMBAD/tools/BEAM4SBP0.2/Integration/demo.html

A scenario of the process configuration

The generated management process includes timer events and catch message events (Figure . 3.1). However, while deploying this process into Activiti, we noticed that its current versions have not supported catch message events, yet. Hence, we replace the catch message event by a catch signal event and a service task reading e-mail in order to take into account the new values of the service properties. We modeled the business environment as a SBP deployed in turn in the Activiti engine. The business environment consists of a service task sending e-mails and signals to alert and throw data to the management process.

The business environment is then deployed and started sending signals and emails. The management process catches the corresponding signal triggering a business environment event and reads an email containing the value of the event. A demo and a real test can be found, respectively, in [START_REF]Integration demo[END_REF] and [START_REF]Integration real test[END_REF].

Conclusion

This chapter was dedicated to the implementation and validation of our approach of business environment-aware management. We started by implementing the BEAM4SBP framework executing the management process generation algorithms presented in

Introduction

In Chapter 3, we presented our approach for business environement aware management. We used an upper management ontology. In this chapter, we aim to assess qualitatively our approach compared to the existing BEAM approaches presented in Chapter 2. Indeed, we assess the expressiveness of each approach with respect to the real world interactions. Each approach is based on a modeling technique (e.g. business processes (BPs), business rules (BRs), etc.). The expressiveness evaluation of a modeling technique is handled based on a representation theory. In the following sections, we present the adopted representation theory. Then, we detail the adopted evaluation methodology.

The BWW representation theory

According to zur Muehlen and Indulska [START_REF] Michael Zur Muehlen | Modeling Languages for Business Processes and Business Rules: A Representational Analysis[END_REF], a representation theory can be used as a benchmark to make predictions about the capabilities of a grammar to provide complete and clear representations of real world interactions. In this study [START_REF] Michael Zur Muehlen | Modeling Languages for Business Processes and Business Rules: A Representational Analysis[END_REF], authors studied the following theories: Chisholm's ontology [START_REF] Roderick | The basic ontological categories[END_REF], the Enterprise ontology [START_REF] Uschold | The enterprise ontology[END_REF] and the Bunge-Wand-Weber ontology [START_REF] Wand | On the ontological expressiveness of information systems analysis and design grammars[END_REF][START_REF] Wand | On the deep structure of information systems[END_REF].

They argued that the Bunge-Wand-Weber (BWW) is more adapted for Information System (IS) domain. Indeed, the use of BWW is motivated and justified by: (1) its considerable level of maturity [START_REF] Recker | Business Process Modeling -A Comparative Analysis[END_REF], (2) its set of constructs that are considered as necessary and able to accurately describe the structure and behavior of the real world, and (3) its success in the evaluation of over thirty analysis projects that spanned various representational grammars [START_REF] Green | Candidate Interoperability Standards: An Ontological Overlap Analysis[END_REF]. Indeed, many of the most popular modeling techniques have now been discussed in the light of their comparability with respect to the BWW models [START_REF] Green | Candidate Interoperability Standards: An Ontological Overlap Analysis[END_REF]. Including but not limited to, we mention: Unified Modeling Language (UML)( [START_REF] Opdahl | Ontological Evaluation of the UML Using the Bunge-Wand-Weber Model[END_REF]), Merise [START_REF] Recker | Business Process Modeling -A Comparative Analysis[END_REF], Petri Nets [START_REF] Jan | An ontology-based evaluation of process modeling with petri nets[END_REF], ebXML Business Process Specification Schema (ebXML BPSS) [START_REF] Green | Candidate Interoperability Standards: An Ontological Overlap Analysis[END_REF], Web Service Choreography Interface (WSCI) [START_REF] Green | Candidate Interoperability Standards: An Ontological Overlap Analysis[END_REF], etc.

As for us, we use the BWW representation model (BWW model for short) to evaluate the expressiveness of modeling techniques used in the mentioned BEAM approaches (see Section 2.1). The BWW model defines a set of constructs which can be clustered into four main groups represented by bold rectangles in Figure 7.1: things and their properties, states of things, events and transformations occurring on things, and systems structured around things.

Our objective is not to evaluate a management approach by comparing it to BWW independently of other approaches. Our objective is rather to compare three management approaches that use different modeling languages. To do so, we should map the concepts of these languages into a common ontology. Since the concepts of the considered approaches are not close enough to each other, we have to use a rather generic ontology to allow such mapping and make the comparison possible and feasible. In addition to that, BWW was used successfully for this purpose and particularly to compare BPMN and rule-based languages [START_REF] Michael Zur Muehlen | Modeling Languages for Business Processes and Business Rules: A Representational Analysis[END_REF]. Besides, results of many BWW-based studies indicate that the model is good enough to be considered as basis to study the representational capabilities of conceptual modeling languages (for example, see [START_REF] Opdahl | Ontological evaluation of the UML using the bunge-wand-weber model[END_REF][START_REF] Peter | Perceived ontological weaknesses of process modeling techniques : Further evidence[END_REF][START_REF] Recker | How good is BPMN really? insights from theory and practice[END_REF][START_REF] Recker | Do process modelling techniques get better? a comparative ontological analysis of bpmn[END_REF] among others).

The adopted evaluation methodology

In order to determine the expressive power of BEAM approaches, our evaluation strategy consists of three phases. The first phase is the representational analysis of each modeling technique used in the imperative and declarative BEAM approaches presented in Chapter 2, Section 2.1. It consists in comparing the constructs of the BWW model with the constructs of the considered modeling languages. The second phase compares between the representation analyses of the adopted modeling techniques (i.e. BPs, BRs and the Upper management ontology (UMO)). Based on the obtained results, the third phase establishes an overlap analysis consisting in evaluating the conbination of modeling techniques used in declarative and imperative BEAM approaches. Hence, we evaluate the expressiveness of hybrid BEAM approaches introduced in Section 2.1.

Representational analysis

The aim of this step is to provide a rigorous evaluation of the expressiveness of a modeling technique (e.g. BPMN, SBVR, UMO, etc.), used in imperative or declarative approaches, with respect to the BWW model. To achieve this goal, we follow the reference methodology proposed in [START_REF] Michael Rosemann | A reference methodology for conducting ontological analyses[END_REF] providing strategic guidelines. These guidelines make more efficient the analysis procedure and increase objectivity.

As stated by Wand and Weber [START_REF] Wand | On the ontological expressiveness of information systems analysis and design grammars[END_REF], two main evaluation criteria may occur after In order to compare a modeling language to BWW model, the Rosemann's methodology [START_REF] Michael Rosemann | A reference methodology for conducting ontological analyses[END_REF] consists in representing the modeling language and BWW model in metamodels using a common meta-language (e.g. UML). This is done in order to overcome the lack of understandability, lack of comparability, lack of guidance, lack of objectivity, etc. Hence, by using a common meta-language, we are able to easily make comparison between models constructs while increasing the rigor, the overall objectivity and the level of detail of the representational analysis.

Figure 7.1 shows a meta-model of the BWW model [7]. It expresses the complete representation model in the UML class diagram notation.

Based on both meta-models of BWW and the evaluated modeling technique, two mappings must be created [START_REF] Wand | On the ontological expressiveness of information systems analysis and design grammars[END_REF]:

• Representation mapping: maps each construct in the BWW model to its corresponding construct in the evaluated modeling technique.

• Interpretation mapping: requires mapping each construct in the evaluated modeling technique to its corresponding construct in the BWW model.

In order to evaluate the declarative and imperative approaches presented in Section 2.1, we consider 7 corresponding modeling languages: 5 business rule modeling languages (R2ML, SRML, PRR, SBVR, SWRL), the BPMN business process modeling language and the upper management ontology (UMO).

In the following, we exemplify the representational analysis by considering UMO as the evaluated modeling technique. We create a meta-model of the UMO using the UML class diagram to facilitate the mapping (Figure 7.2). This meta-model is then mapped with the BWW meta-model shown in Figure 7.1.

Qualitative assessment

According to the two mappings carried out above, Table 7.1 summarizes our results of ontological completeness and clarity for UMO expressed as rates. The results of the mappings are as follows: the construct deficit of the UMO is 57.15% which means that its completeness represents 42.85%. Indeed, 15 constructs among 28 of BWW are in UMO. These constructs are enumerated in the grey column of Table 7.2. The correspondence between BWW model constructs and the constructs in UMO are rated as supported (+) or no supported (-). For the ontological clarity, despite the high value of the construct excess (64.7%, i.e. 18 constructs in UMO over 28 do not exist in BWW meta-model), it becomes balanced thanks to the low value of construct redundancy (11.76%, i.e. 3 costructs in BWW are represented by many constructs in UMO meta-model) and overload (35.29%, 9 constructs among 28 of BWW are compared to one construct in UMO). Overall, these results show that the UMO has an acceptable ontological expressiveness.

By the same way, the representational analyses of the considered modeling techniques are handled. The mapping result is represented in Table 7.2. The correspondence between BWW model constructs and the constructs of the evaluated technique are rated as supported (+) or no supported (-). In the following subsection, we compare these representational analyses in order to identify the BEAM approach with the highest expressive power.

Comparison of representational analyses of adopted modeling techniques

In this section, we compare the representational analysis of adopted modeling techniques (i.e. BPs, BRs and UMO). The comparison is based on previous representation analyses conducted by different researchers. Most notably, we select the representational analyses of SRML 2001, PRR v1.0 and SBVR 2006 from [START_REF] Michael Zur Muehlen | Modeling Languages for Business Processes and Business Rules: A Representational Analysis[END_REF]. The techniques R2ML v0.5, SWRL v1.0 and BPMN v2.0 are adopted from [START_REF] Prezel | Representational Analysis of Business Process and Business Rule Languages[END_REF]. Then, we compare the findings of UMO to those of business rule languages and business process languages. This comparison is handled with respect to the BWW model (see Table 7.

2).

Based on the results given in Table 7.2, BPMN v2.0 offers the highest completeness value with a score of 19/28 such that 28 represents the number of constructs of BWW (67.85%). In the second place, the UMO's score is equal to 12/28 (42.85%) followed by R2ML v0.5 and SRML 2001 with the same score of 10/28 (35.71%). After them, PRR v1.0 and SBVR 2006 cover only of 7/28 (25%), and finally SWRL v1.0 with the lowest score (21.42%) with respect to the analyzed languages.

Generally, all the representational analyses depicted in Table 7.2 on the following page have scores which are so far away from the total which imply their incompleteness. For this reason, we resort to the next phase consisting in the overlap analysis (see Section 7.2.3).

Overlap Analysis

In case none of the studied languages provides a complete representation capability of the real world, the overlap analysis is performed [START_REF] Prezel | Representational Analysis of Business Process and Business Rule Languages[END_REF]. In the previous section, we argued that declarative and imperative approaches are not sufficient to express the real world interactions. In this phase, our goal is to evaluate the expressiveness of hybrid approaches presented in Section 2.1. We aim to identify the best combination of business process modeling language, business rule modeling language and the upper management ontology. We select BPMN v2.0 as a business process modeling language. We combine BPMN with the 5 business rule modeling languages as well as UMO presented in Table 7.2.

According to [START_REF] Peter | Complementary Use of Modeling Grammars[END_REF], two important characteristics are useful for evaluating these combinations, with respect to the BWW model:

• Maximum Ontological Completeness (MOC): represents the maximum ontological expressiveness afforded by a combination of modeling languagees.

• Minimum Ontological Overlap (MOO): occurs when a construct of BWW model has a correspondence in both modeling languages that make the combination.

MOC and MOO are computed based on symmetric difference, intersection and relative compliment as defined in [START_REF] Michael Zur Muehlen | Modeling Languages for Business Processes and Business Rules: A Representational Analysis[END_REF] Based on the results shown in Table 7.3, the combination of BPMN v2.0 with UMO offers the highest ontological completeness with a score of 24 from 28; that is 85.71%. Even though its MOO is the highest value, it remains quite comparable with respect to the other combinations. Indeed, MOC is proportional to MOO. According to the results shown in Figure . 7.3, the hybrid approaches offer the highest scores. Then, the imperative approach followed by the declarative approach.

Conclusion

In this chapter, we conducted a qualitative evaluation comparing the expressivenes of existing BEAM approaches. More precisely, we compare our approach to hybrid approaches integrating business processes and business rules. Doing so, we answered the following research question: which are more expressive the business rules or our upper management ontology?

In the next chapter, we assessed our approach quantitatively with respect to the presented BEAM approaches by experimenting their efficiency and studying their flexibility.

Introduction

As companies are becoming much more involved in business environments, they hope to become more aware of business impact of their decisions. Hence, choosing an adequate BEAM approach to address critical business opportunities and challenges facing companies remains arguably an awkward task. Indeed, with more competitive markets (i.e. subdued demand, competitive pricing pressures and dynamic business environment changes) companies must seek the efficiencies needed to protect them. Flexibility is also fundamental to deliver high levels of customer service and satisfaction. The problem with business process flexibility is that the changes required are often unknown until the need for that change arises. Besides, companies aim to use existing business process standards in order to be feasible in practical use.

Thereby, this chapter is dedicated to assess the efficiency and flexibility of our approach compared to three other approaches: imperative, declarative and hybrid approaches based on integrating rules in BPs. Although there are existing research works in the area of variability in processes [START_REF] Gottschalk | Configurable workflow models[END_REF][START_REF] Koning | Vxbpel: Supporting variability for web services in bpel[END_REF][START_REF] Ouyang | An eca-based control-rule formalism for the bpel process modularization[END_REF]4,25,[START_REF] Milanovic | Towards a language for rule-enhanced business process modeling[END_REF]3] that may be assessed and we believe on their importance, the BEAM approaches discussed in this chapter are complex enough in themselves to deserve separate treatment.

Our experimentation work was achieved in three stages: (8.1) preparing the testbed, (8.2) testing the efficiency of BEAM approaches and (8.3) studying their flexibility.

Preparing the test-bed

In order to assess the BEAM approaches, a business process engine and a rule engine are required. We are aware that the choice of these engines can influence the efficiency values. However, we believe that this influence remains limited since it does not radically change the ratio of comparisons between approaches. We opted for Activiti process engine and Drools rule engine since they are available, open source and widely used by companies [START_REF] Rademakers | Activiti in Action: Executable Business Processes in BPMN 2[END_REF][START_REF] Proctor | Drools: A rule engine for complex event processing[END_REF].

Quantitative assessment

On one hand, Activiti [START_REF]Activiti[END_REF] is a framework that provides an environment for designing, implementing and running processes described in BPMN 2.0. It is an open source project distributed under the Apache license. On the other hand, Drools is a Business Rules Management System (BRMS) based on forward and backward chaining inference engine. It uses an optimized implementation of the Rete algorithm called ReteOO (Rete algorithm for Object-Oriented systems).

Each BEAM approach requires a specific environment to be tested.

The suitable environment to test the imperative approach is a process engine. Hence, we select the Activiti engine. We start by writing the business process in BPMN then we deploy and execute it in Activiti. Then, we add to this process, management actions and events in order to re-depoy and re-execute it.

For the declarative approach which is purely based on rules, we need a rule engine. We choose the well-known Drools rule engine [START_REF] Proctor | Drools Documentation[END_REF]. The project of Drools is an open source written in Java. We use precisely Drools Workbench [START_REF]Drools workbench[END_REF], a web application composed of all Drools related editors, screens and services. It is equivalent to the old Guvnor [START_REF] Browne | JBoss Drools Business Rules[END_REF]. Drools Workbench includes Drools Expert (business rule engine) and Drools Fusion (Complex Event processing features) representing an environment to author, test and deploy rules. As shown in Figure 8.1, the rule engine applies the rules to the facts. Hence, it takes as inputs: facts, a fact model and a set of rules. The facts are the data records to be processed. The fact model tells the rule engine how to interpret the facts. It contains data records as well as their setters and getters. The rules use these facts to tell the rule engine what actions to take when certain conditions are met. Hence, we start by creating the JAR file containing the fact model consisting of Java classes used by rules. The JAR file is then uploaded into the Drools Workbench. Afterwards, we create a set of rules written based on the DRL (Drools Rule Language). Finally, we run the scenario by introducing facts and expected rules. For example, for our running example we introduce values of unitPrice and quantity. We also expect that the discount rule will be executed at least once.

Finally, we test two different hybrid approaches: (i) The first one consists in integrating business rules with business processes. Therefore, we need two engines for running rules and processes at the same time. For this purpose, we integrate Drools with Activiti. Doing so, we create a maven project in eclipse including the business process written in BPMN, the fact model and the rules related to the business rule tasks. Then, we test based on the Junit. (ii) The second one represents our approach. We have already prepared our environment for testing our hybrid approach by integrating the plug-in BEAM4SBP into Activiti (see Chapter 6).

Testing efficiency

We characterize a given management approach as efficient when the management overhead of the management on the process performance is limited. Consequently, comparing the efficiency of two or more management approaches consists in comparing their management overheads. Hence, for each test we perform the following steps:

1.

Step 1: Calculate two different execution times (t 1 and t 2 ): t 1 is the execution time of the initial BP without including the management time and t 2 represents the execution time of the whole process including the management time.

2.

Step 2: Compute the Overhead using the values of t 1 and t 2

Overhead =t 2 -t 1

3.

Step 3: Express the Overhead in form of percentage (Overhead p ) relatively to the whole execution time t 2 . The goal of this step is to provide a clear idea about the rate of the time taken for the management.

Overhead p = Overhead × 100 t 2

In the following, we start by testing efficiency value of each BEAM approach using the running example. Then, we compute efficiency values using control-flow BPMN patterns.

Testing using the running example

The running example presented in Section 1.2 is implemented and experimented in the four considered BEAM approaches. . It shows that the value of the management spent in the imperative approach is equal to 9.35%, while, the management in the declarative approach takes 45.10%. This value shows the time-consuming problem with the declarative approach. The hybrid approaches in which the configuration is described based on rules has an overhead p equal to 39.89%, and the hybrid approach with a configuration based on management process has an overhead p equal to 20.08%. The difference between these two latter values is significant since the configuration of the second hybrid approach is described imperatively. This leads to a better value of efficiency.

Testing using BPMN patterns

An obvious approach of experimentation consists in developping a set of real BPs of a large public dataset (e.g. the dataset shared by the Business Integration Technologies (BIT) research group at the IBM Zurich Research Laboratory1 ). However, the results based on these experimentations could be confusing since they depend on the manner of implementation of these processes according to the four experimented approaches. Hence, the efficiency value can come from the implementation of these processes rather then the evaluated BEAM approaches.

As for us, we consider another way of testing these approaches based on the following assumption: business processes can be built based on workflow patterns [START_REF] Wil | Workflow patterns[END_REF]. The result of comparision of BEAM approaches on these patterns based on their behavior could be very close to the result of comparison of these approaches on a set of processes which are compositions of patterns.

We have conducted 12 tests. Indeed, we experimented the three basic patterns ((1) sequence, (2) parallel split + synchronization and (3) exclusive choice + simple merge) on the implementations of the four considered BEAM approaches based on the purchase order ontology. In fact, these BPMN patterns are commonly used specially with structured workflows [START_REF] Kiepuszewski | On structured workflow modelling[END_REF]. Figure 8.4 shows results of these experimentations. More details are given in the following web site: http://www-inf.int-evry.fr/ SIMBAD/tools/BEAM4SBP0.2/Experimentation/ontology1.html Figure 8.4 illustrates the same shape as Figure 8.3. Indeed, the declarative approach represents always the higher overhead value: for the sequence pattern 70%, for the parallel split and synchronization pattern 67.74%, for the exclusive choice and simple merge 60.86%. The hybrid approach in which the configuration is described based on rule represents the overhead values 39%, 40.65%, 36.86% respectively for the sequence pattern, the parallel pattern and the exclusive choice pattern. Our hybrid approach where the configuration is described by a management process has overhead values of: 33.31% for the sequence pattern, 33.55% for the parallel split pattern and 33.39% for the exclusive choice pattern. Finally, the impearative approach represent the best overhead values. In fact, for the sequence pattern we obtained 4%, while for the parallel split pattern and exclusive choice pattern we get respectively 5.42% and 5.78%.

In addition to that, we conducted 12 tests based on the three basic BPMN patterns mentioned above. These tests are based on the pathology ontology. More details are given in the following web site: http://www-inf.int-evry.fr/SIMBAD/tools/ BEAM4SBP0.2/Experimentation/ontology2.html. Hence, we notice that both resulting histograms based on the purchase order ontology and the pathology ontology have similar shapes.

As a result, the lower the Overhead p value is, the more efficient the approach will be. Therefore, as expected, the imperative approach is the most efficient one and the declarative approach is the most time-consuming approach. The hybrid approaches are classified between these two extremities. We recall that our hybrid approach, describing its configuration based on the management process, represents a good value of efficiency thanks to modeling the management process imperatively.

Studying flexibility

Flexibility is the second quantitative criterion upon which we assess the BEAM approaches. It is the ability to modify the process model at design, deployment and The management in declarative approaches is made at design time, deployment time or run time as it is based on inference on rules. Indeed, a business rule may be added, modified or deleted at any time. Hence, declarative approaches have a high level of flexibility.

As for the hybrid approaches where the configuration is described based on rules (CBR), the management is implemented using rules that are integrated in some activities (called business rule tasks) in the managed process. Then the management consists in adding, modifying or deleting business rules in business rule tasks. After the design, this ability of modifying the management is limited to business rule tasks. The management can affect neither non business rule tasks nor control flow in the managed process.

Regarding the hybrid approach in which the configuration is based on a management process (CBMP), the management consists in annotating BP using the upper management ontology (UMO) and business (domain) ontology. Beside the design time, in this approach, the management process is generated at deployment time. At the run-time, it allow different scenarios of management (the different management paths in the management process). Nevertheless, this way of management is not as flexible as the one of declarative approaches since the management of this current approach consists in a limited set of management paths. In fact, declarative approaches can deal with much more possibilities of rules.

In imperative approaches, the management consists in over-specifying BPs at design time. When designed a managed process cannot be changes neither at deployment time nor at run-time.

Guidelines for choosing the adequate BEAM approach

Both efficiency experimentations and flexibility studies show that the declarative approach represents a high level of flexibility but it is very time consuming. On the contrary, the imperative approach as intended is very efficient, however, it is very rigid. Hence, hybrid approaches prove good opportunities in practical if conciliating between flexibility and efficiency is a need.

We think that the choice of a BEAM approach should be based on the dependency of the business process behavior, on one hand, and the frequency of changes in the business environment, on the other hand.

The frequenter the change is, the higher the motivation to use a declarative approach. For example, a declarative approach would be adequate to manage socialbased business processes. In such processes, human intervenes frequently to enact and change the behavior of processes based on the behavior of other human activities. Control flow and behaviors of activities of social business processes can be changed frequently, which needs to adopt a declarative approach.

Contrary, an imperative approach is adopted when the business process tends to be insensitive to the business environment change. Business processes of embedded systems are a good example of processes where it is convenient to adopt an imperative BEAM approach.

A hybrid approach, in which the configuration is described based on rules, is used when the behavior of some activities could be modified, whereas the control flow remains unchanged. It is the case of administrative processes where the control flow is defined by law or decree and behaviors of activities depend on citizen situations. Last but not least, a hybrid approach where the configuration is described by a management process can be adopted when the management of control flow and activities of business processes depends on business environment. It is the case of hospital service processes where activities and control flow depend on the situation of other hospital services and patients situations considered as business environments.

Conclusion

In this chapter, we experimented the efficiency and flexibility of our approach compared to the imperative, declarative and hybrid BEAM approaches. To realize our experimentations, we started by preparing the test bed of each BEAM approach. The comparision of these approaches are based on a running example and control flow BPMN patterns.

Hence, our quantitative evaluation offers to designers or system administrators, guidelines that may help them to decide about the adequate modeling approach to adopt for a given context or case. Indeed, we showed that there is not a best approach that might be applied in any case and we provided guidelines to choose the suitable approach for each case/context.

Conclusion and future work

"

Conclusion

In this thesis, we proposed a novel hybrid approach for managing SBPs against highly dynamic business environments. This approach conciliates between imperative and declarative approaches while addressing the following issues: preserving standards for describing SBPs and minimizing the designer efforts. Our approach consists in generating, at deployment time, a management process for a managed BP connected to it allowing its monitoring and configuration. The management process generation is performed thanks to a semantic module and a control dependency analysis module. The first module involves an upper management ontology describing relationship between SBPs and business environments. While, the second module describes an explicit description of the managed BP by identifying control dependencies to facilitate the organization of the whole management process. We also tested the feasibility of our approach and experimented its efficiency and flexibility.

Indeed, meeting the market requirements within a highly dynamic business environment remains a challenge for companies. Hence, choosing the adequate business environment management approach represents a challenging issue. Therefore, we handled, throughout this thesis, qualitative and quantitative evaluations of existing types of business environment-aware management approaches. The qualitative evaluation revealed the expressiveness of each approach based on the BWW representation theory. As to the quantitative evaluation, we experimented the efficiency and studied the flexibility based on basic control-flow patterns. Furthermore, we verify the feasibility of existing approaches in practical use by preserving or not the business process standards. As a result, through this thesis, we argue that declarative approaches are very time consuming but are very flexible. Thus, declarative approaches are suitable for highly frequent management changes (e.g. social based processes). Imperative approaches, by contrast, are proved very efficient, however, they are too rigid due to over-specifying processes at design time. It is then nearly infeasible to change the management rules at run-time. Hence, the imperative approaches are suitable when the business process is insensitive to the business environment (e.g. processes of embedded systems). The evaluation, both qualitative and quantitative, prove good opportunities for hybrid approaches in practical use. On one hand, the hybrid approach where the configuration is described based on rules, is used in case some activities change their behaviour by opting for business rule tasks (e.g. administrative processes). On the other hand, the hybrid approach in which the configuration

3. 1

 1 Purchase order process with its corresponding management process. . 3.2 BEAM meta-model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Upper management ontology. . . . . . . . . . . . . . . . . . . . . . . . 3.4 The process graph of the purchase order process. . . . . . . . . . . . 4.1 Control dependency graph of the purchase order process . . . . . . . . 4.2 Def-Use graph of the purchase order process. . . . . . . . . . . . . . . 4.3 Data dependency graph. . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Dependency graph of the purchase order process . . . . . . . . . . . . 4.5 Post dominators tree of the purchase order process . . . . . . . . . . . 5.1 Result of phase 1 and phase 2 . . . . . . . . . . . . . . . . . . . . . . . 5.2 Result of connecting subprocesses based on the upper management ontology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1 . 1 :

 11 Figure 1.1: Business service/process facets.

Figure 1 . 2 :

 12 Figure 1.2: A BPEL subprocess for purchase Order process [1].

Figure 1 . 3 :

 13 Figure 1.3: A BPMN Purchase order process.

Figure 1 . 4 :

 14 Figure 1.4: Business service/process management types.

  Figure 2.4: rBPMN meta-model [2].

Figure 2 . 5 :

 25 Figure 2.5: Integration Framework for design and analysis [3].

Figure 2 . 6 :

 26 Figure 2.6: Architecture for integrating BRs and SWSs [4].

Figure 2 . 8 :

 28 Figure 2.8: Definition of a variation point in VxBPEL [5].

Figure 3 . 2 :

 32 Figure 3.2: BEAM meta-model.

•

  T A = (I, O, P re, P ost, A, E) are technical aspects where: -I: set of Inputs -O: set of Outputs -Pre: set of Pre-conditions -Post: set of Post-conditions -A: set of Assumptions -E: set of Effects • OA = (F p , M ) connotes operational aspects -F p represents the business operation of S F p : A × I × P re -→ p O × P ost × E -M = (M m , M c ) is the set of managing operations

Figure 3 . 4 :

 34 Figure 3.4: The process graph of the purchase order process.

Figure 4 . 1 :

 41 Figure 4.1: Control dependency graph of the purchase order process (1: Receive order, 2: Check availability, 3: OR-split, 4: Choose supplier, 5: OR-split, 6: Contact supplier 1, 7: Contact supplier 2, 8: OR-join, 9: Receive products, 10: OR-join, 11: AND-split, 12: Compute initial price, 13: Compute retouch price, 14: Choose shipper, 15: Compute shipping price, 16: AND-join, 17: Compute total price, 18: Send order and invoice, 19: Receive delivery notification)

  represents a subset of PG nodes having data dependencies • E 3 represent a set of edges Analysis of the structure of the managed business process Use(unitPrice), Def(initialPrice) Use(initialPrice), Def(RetouchPrice), Def(NetPrice) Use(meansofDelivery), Def(ShippingPrice)

Figure 4 . 2 :

 42 Figure 4.2: Def-Use graph of the purchase order process.

Figure 4 . 3 :

 43 Figure 4.3: Data dependency graph.

Figure 4 . 4 :

 44 Figure 4.4: Dependency graph of the purchase order process (1: Receive order, 2: Check availability, 3: OR-split, 4: Choose supplier, 5: OR-split, 6: Contact supplier 1, 7: Contact supplier 2, 8: OR-join, 9: Receive products, 10: OR-join, 11: ANDsplit, 12: Compute initial price, 13: Compute retouch price, 14: Choose shipper, 15: Compute shipping price, 16: AND-join, 17: Compute total price, 18: Send order and invoice, 19: Receive delivery notification)

Algorithm 1

 1 GeneratingControlDependencyGraph Require: Process Graph P G Ensure: Control Dependence Graph CDG 1: P ostdom ←-ComputeP ostdoms(P G) 2: P DT ←-GenerateP DT (P ostdom, V 1 (P G)) 3: S ←-ConstructSLM arkedCD.S 4: L ←-ConstructSLM arkedCD.L 5: CD ←-ConstructSLM arkedCD.CD 6: M arked ←-ConstructSLM arkedCD.M arked 7: List SGs ←-SearchSubgraphs(P G, ( g , "AN D -Split"), ( g , "AN D -Join"))

Figure 4 . 5 :

 45 Figure 4.5: Post dominators tree of the purchase order process (1: Receive order, 2: Check availability, 3: OR-split, 4: Choose supplier, 5: OR-split, 6: Contact supplier 1, 7: Contact supplier 2, 8: OR-join, 9: Receive products, 10: OR-join, 11: ANDsplit, 12: Compute initial price, 13: Compute retouch price, 14: Choose shipper, 15: Compute shipping price, 16: AND-join, 17: Compute total price, 18: Send order and invoice, 19: Receive delivery notification)

  4) and the Def-Use graph (Figure 4.2). The DDG is created according to Algorithm 4 based on the data dependency definition (Definition 10) presented in section 4.1.2.

Algorithm 8

 8 ChooseGateway(List L 2 , ServiceProperty p) Require: Process graph P G Ensure: String GatewayType 1: for all l ∈ L2 do 2: for all h ∈ L2 do 3: Let S1 ∈ V1(P G) such that S1.p.concept = l 4: Let S2 ∈ V1(P G) such that S2.p.concept = h 5: Let e ∈ V1(P G) such that e = (S1, S2) 6:

Figure 5 . 1 :

 51 Figure 5.1: Result of phase 1 and phase 2

Figure 5 . 2 :

 52 Figure 5.2: Result of connecting subprocesses based on the upper management ontology.

  4.4) allowing to get the

Figure 6 . 1 :

 61 Figure 6.1: Business environment-aware management framework for SBPs.

Figure 6 . 2 :

 62 Figure 6.2: The generated BPMN file.

  .

4 . 4 .

 44 In the following, we present the framework's architecture. The architecture of DAT comprises six main modules: (1) Parser, (2) Process Graph Generator, (3) Def-use Graph Generator, (4) Data Dependency Graph Generator, (5) Control Dependency Graph Generator, (6) Dependency Graph Generator.

Figure 6 . 3 :

 63 Figure 6.3: Dependency Analysis Tool (DAT) Architecture.

Figure 6 .

 6 Figure 6.4 shows a general overview of the Activiti components which make the whole framework.

Figure 2 :

 2 Figure 2: Activiti components

Figure 6 . 4 :

 64 Figure 6.4: Activiti components [6].

Figure 6 . 5 :

 65 Figure 6.5: Upload with Business Management.

Figure. 7 .

 7 Figure. 7.3 shows a synthetic histogram of the best modeling techniques in each BEAM approach, according to their scores of completeness with respect to the BWW model. The results shown herein are extracted from Tables 7.2 and 7.3.

Figure 7 . 3 :

 73 Figure 7.3: Completeness score of the assessed BEAM approaches.

Figure 8 . 1 :

 81 Figure 8.1: The test environment for declarative approaches.

Figure 8 .

 8 Figure 8.3 depicts a synthetic histogram representing the average value of overhead p (called Overhead AV G ) through running 20 tests while varying the input "quantity" value (we selected 5 values: 10, 30, 50, 70, 80, 90 (Figure 8.2)). It shows that the value of the management spent in the imperative approach is equal to 9.35%, while, the management in the declarative approach takes 45.10%. This value shows the time-consuming problem with the declarative approach. The hybrid approaches in which the configuration is described based on rules has an overhead p equal to 39.89%, and the hybrid approach with a configuration based on management process has an overhead p equal to 20.08%. The difference between these two latter values is significant since the configuration of the second hybrid approach is described imperatively. This leads to a better value of efficiency.

Figure 8 . 2 :Figure 8 . 3 :

 8283 Figure 8.2: Histograms of BEAM approaches.

Table of contents x Table of contents

 ofxof List of Figures1.1 Business service/process facets. . . . . . . . . . . . . . . . . . . . . . 1.2 A BPEL subprocess for purchase Order process [1]. . . . . . . . . . . 1.3 A BPMN Purchase order process. . . . . . . . . . . . . . . . . . . . . 1.4 Business service/process management types. . . . . . . . . . . . . . . 2.1 Imperative approach for managing purchase order process. . . . . . . 2.2 Declarative approach for managing purchase order process. . . . . . . 2.3 Hybrid approach for managing purchase order process based on business rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 rBPMN meta-model [2]. . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Integration Framework for design and analysis [3]. . . . . . . . . . . . 2.6 Architecture for integrating BRs and SWSs

  6.1 Business environment-aware management framework for SBPs. . . . . 6.2 The generated BPMN file. . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Dependency Analysis Tool (DAT) Architecture. . . . . . . . . . . . . 6.4 Activiti components [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Upload with Business Management. . . . . . . . . . . . . . . . . . . . 6.6 Purchase order process. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Deployment of the output file. . . . . . . . . . . . . . . . . . . . . . . . UMO meta-model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Completeness score of the assessed BEAM approaches. . . . . . . . . . 8.1 The test environment for declarative approaches. . . . . . . . . . . . . 8.2 Histograms of BEAM approaches. . . . . . . . . . . . . . . . . . . . . 8.3 Histograms of BEAM approaches. . . . . . . . . . . . . . . . . . . . . 8.4 Histograms of BEAM approaches with respect to BPMN control flow patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results of ontological completeness and clarity of the UMO. . . . . . . 7.2 Summary of the representation analyses of R2ML, SRML, PRR, SBVR, SWRL, UMO and BPMN . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Comparison of overlap analyses results . . . . . . . . . . . . . . . . . . 8.1 Flexibility results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	xii xiv xvi	List of Figures List of Tables
	7.2 List of Tables List of abreviations Introduction
	"
	2.1 Review of existing business environment aware management approaches
	xi Aspect Oriented Programming Business Environment Aware Management Business Environment-Aware Management for Service-based Business Processes Business Goals-based Management Business Process Execution Language Business Process Execution Language Business Process Model and Notation Service-based Business Processes Business Process Specification Schema Bunge-Wand-Weber Control Dependency Graph Complex Event Processing Control Flow Graph Dependency Analysis Tool Data Dependency Graph. Drools Rule Language Event-Condition-Action Event-driven Process Chain Information System Information Technology Key Performance Indicator Linear Temporal Logic Maximum Ontological Completeness Minimum Ontological Overlap Object Management Group Post-Dominators Tree Process Performance Metric Production Rule Representation REWERSE I1 Rule Markup Language Rete algorithm for Object-Oriented systems Semantics of Business Vocabulary and Business Rules Service Level Agreement Service Oriented Architecture Simple Rule Markup Language Semantic Web Rule Language Technical Management 7.1 xiii AOP BEAM BEAM4SBP BGM BPEL BPEL BPMN SBP BPSS BWW CDG CEP CFG DAT DDG DRL ECA EPC IS IT KPI LTL MOC MOO OMG PDT PPM PRR R2ML ReteOO SBVR SLA SOA SRML SWRL TM xv

7.1 BWW meta-model [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . .

  Facets and management types of service-based business processes agement Initiation) in 2004 and then becomes maintained by OMG (Object Management Group) in 2006. The current version BPMN 2.0 was published in 2011. Its full specification is provided at[START_REF] Omg | Business Process Modeling Notation, Final Adopted Specification[END_REF].• UML Activity diagram UML (Unified Modeling Language) is a standard proposed by OMG for graphical modeling used in object-oriented development.It has become a key language in software engineering since it expresses the needs and requirements using several diagrams (class diagram, activity diagram, etc.).

	• Business Process Model and Notation (BPMN) standard Even though
	there is a large variety of modeling techniques, the most well-known is Business
	Process Model and Notation (BPMN). It is a standard with a graphical notation
	which provides companies with the capability of understanding their internal
	business procedures.

The first version of BPMN was developed by BPMI (Business Process Man-

Choose supplier Contact supplier 1 Contact supplier 2 Receive products yes Compute initial price Compute retouch price Choose supplier

								Receive	delivery	notification
								Send order	and invoice
	Rule 3	ON Discount Rate computed	IF True	DO Compute retouch price	Raise Retouch price computed	Compute	total price	Compute	shipping price	Rule 4	ON Discount Rate computed	IF True	DO Compute shipping price	Raise Shipping price computed
	Rule 2	Sales promotion	True	Compute discount	rate	Discount Rate	computed
		ON	IF	DO	Raise
	Rule 1	Festive Season		Update Criteria	list	Criteria list updated
		ON	IF	DO	Raise

True

Figure 2.3: Hybrid approach for managing purchase order process based on business rules.

  Semantic modeling of service-based business processes and business environment 43 Figure3.2). In this work, a service S is mainly characterized by its property p, which, being adjusted, changes the service behavior. A service property has a name, a value, and is annotated with a concept from the domain ontology. The technical aspects TA represent the set of: Inputs I, Outputs O, Pre-conditions P re, Post-conditions P ost, Assumptions A and Effects E. The operational aspects OA comprise the business operation F p and its corresponding management operations M . We distinguish two types of management operations: monitoring operations M m and configuration operations M c . Furthermore, among management operations, we generate automatically a setter and a getter for each service property. The other management operations are set by the service provider. Thereby, changing the service behaviour can be made by changing the value of its property p through management operations which changes the behaviour of the business operation F p (e.g. F p=v 1 ...).

																		business processes
	3.2.2.1 Semantic Service model
	A service has an implementation including its property, its technical aspects, and
	operational aspects (
	Management Service Property operations Event	Event	structure	Atomic Composite Event Event	EventDefinition	Message Conditional Event Event Signal Timer	Event Event	Message Signal timeDuration timeDate	timeCycle	Item	Definition	Xsd:string Xsd:string	Discount	First SetOperation SalesPromotion Rdf:Alt	DiscountRate Promotion SecondDiscount FirstDiscount	Message TimeDate	Rdf:Seq	DiscountRate Second SalesPromotion Supplementary DiscountRate Promotion SetOperation	DiscountRate/ TimeDate	RetouchPrice ShippingPrice SupplementaryRate Message Festive	Season SetOperation CriteriaList	FestiveTime	CriteriaList Date	Message	Figure 3.3: Upper management ontology.
			Upper Management Ontology							Domain ontology

  The adopted evaluation methodology 85 a representational anaysis, ontological completeness and ontological clarity. On one hand, the ontological completeness is violated if there exists a construct deficit. The construct deficit happens once one construct in the BWW model does not have any correspondence construct in the evaluated modeling technique. It represents one to zero mapping (1:0). On the other hand, the ontological clarity is determined by identifying the overload, redundancy and excess construct rates. The construct overload occurs when two or more distinct constructs of the BWW model can be compared to the same construct of the evaluated modeling technique. In other words, one construct of the modeling technique can be used to represent many constructs of the BWW model. It can be described by (m:1) relationship mapping. The construct redundancy results when one construct of the BWW model can be compared to two or more distinct constructs of the evaluated modeling technique. This means that many constructs of the modeling technique can be used to represent one construct of the BWW model. It depicts (1:m) relationship mapping. The construct excess results when the BWW model has no constructs that can be compared to some constructs of the evaluated modeling technique. It represents zero to one mapping (0:1).

Table 7 .

 7

1: Results of ontological completeness and clarity of the UMO.

  .

	BPMN v2.0	R2ML	SRML	PRR	SBVR	SWRL	UMO
	+	v0.5	2001	v1.0	2006	v1.0
	MOC	82.14% 82.14%	75%	71.42% 71.42% 85.71%
	MOO	21.42% 21.42% 17.85% 21.42% 17.85%	25%

Table 7 . 3

 73

: Comparison of overlap analyses results

Hybrid Approach : Configuration based on rules

													AVG										AVG
													90
	(b) Declarative Approach												30 50 70 80	Quantity Value Variation									Quantity Value Variation
													10
	(a) Imperative Approach	100%	90%	80%	40% Overhead p 50% 60% 70%	30%	20%	10%	0%	10 30 50 70 80 90 AVG	Quantity Value Variation	10% (c) 0% 20% 30% 40% 50% 60% 70% 80% 90% 100% Overhead p	AVG	Quantity Value Variation
		100%	90%	80%	70%	60%	50%	40%	30%	20%	10%	0%			100%	90%	80%	70%	60%	50%	40%	30%	20%	10%	0%
					Overhead p										Overhead p

Table 8 .

 8 Figure 8.4: Histograms of BEAM approaches with respect to BPMN control flow patterns. run time. While implementing the four assessed BEAM approaches, we argue the ascertainments summarized in Table 8.1. 1: Flexibility results.

	Studying flexibility

BEAM4SBP can be found at http://www-inf.int-evry.fr/SIMBAD/tools/BEAM4SBP0.2/ Framework.

DAT can be found at http://www-inf.int-evry.fr/SIMBAD/tools/DAT.

Figure 6.6: Purchase order process.

Figure 7.2: UMO meta-model.

http://www.research.ibm.com/labs/zurich/csc/

Chapter 5

Management process generation

, support, encouragement and invaluable guidance to make my Ph.D. I would like to express my deep gratitude to my supervisor, Professor Mohamed JMAIEL at National Engineering School of Sfax, Tunisia for his generous support and consistent kindness throughout the course of the work. I would like to thank all my colleagues in the ReDCAD laboratory at National

availability All available? No

Contributions

The major contribution of this thesis is an algorithm for generating a management process for monitoring and configuring a given managed process. Therefore, Chapter 5. Then, we implemented the DAT (Dependency Analysis Tool) plug-in for BEAM4SBP. DAT outputs the dependency graph of the managed process. It implements algorithms introduced in Chapter 4. The whole framework is then integrated into the Activiti business process engine. As a result, the BEAM4SBP framework becomes accessible via the Activiti Explorer interface. Doing so, we prepared the test bed for testing our approach. In order to assess the efficiency and flexibility of our approach compared to the existing BEAM approaches, we will prepare their specific execution environments in Chapter 8. In the next chapter, we will assess these BEAM aproaches qualitatively.

Chapter 7

Qualitative assessment

Qualitative assessment

Future work

The upper management ontology details events and service properties. The management operations are not yet detailed. Indeed, at this level, our approach involves only getters and setters as managing operations. Thus, we plan to specify a composition for managing operations given by the service provider. As for the experimentation, we aim at testing other BPMN control-flow patterns. Besides, we foresee to test these patterns based on a large ontology. As for long-term perspective, we aim at using our approach for managing multi-tenant BPs. For a given modeled BPs having one tenant, there is a dedicated management. Title : Business-aware management of service-based business processes Keywords : business processes, business environment, efficiency and flexibility Abstract: Continuous business environment changes urge companies to adapt their processes from a business environment point of view. Indeed, companies struggle to find a balance between adapting their processes and keeping competitiveness. While the imperative nature of business processes is too rigid to adapt them at run-time, the declarative one of the purely rule based business processes is, however, very time consuming. Hybrid approaches in turn try to reconcile between these approaches aiming to reach the market requirements. Nevertheless, they also need an effort for aligning business logic and process logic. Therefore, in this thesis, we focus on business environment-aware management of service-based business processes aiming at conciliating imperative and declarative approaches.

Our challenge is to develop a hybrid management approach that preserves industry standards to describe and to manage SBPs as well as minimizes designers' efforts. Based on a semantic modeling of business environment, business processes as well as their relationships, and a control dependency analysis of business processes, we are able to synthesize a controller, itself modeled as a process, connected to the business process to be monitored and configured at run-time. We also validated the feasibility of our management approach by implementing the framework Business Environment-Aware Management for Service-based Business processes (BEAM4SBP). Experimentations show the efficiency of our approach with respect to other BEAM approaches.