A Methodological Approach for the Dynamic Adaptation of Web

Services to the Context

Omnia Saidani Neffati

, Rim Samia Kaabi

and Naoufel Kraiem

1,2

RIADI Laboratory, National School of Computer Science, University of Manouba, Manouba, Tunisia

Computer Science Department, University of Sultan Qaboos, Muscat, Oman

Keywords: Web Service Composition and Orchestration, BPEL, BPMN, Context-awareness, Dynamic Adaptation.

Abstract: The dynamic nature of environnments in which Web services are executed require that these ones must be

reactive and adaptive in order to meet changing requirements.These changing requirements have to be taken

into account in the Web service composition process. BPEL (Business Process Execution Language), the

de-facto standard language used to define processes through the composition of Web services, doesn’t

support dynamic changes. Therfore, BPEL dosen’t support the dynamic adaptation of Web service

composition according to the context. In this paper, we propose solution in order to support the dynamic

adaptation of service composition through BPEL.

1 INTRODUCTION

Web Services are self-contained, modular,

distributed and dynamic applications that can be

described, published, located, or invoked over the

network in order to create products, processes, and

supply chains. These applications can be local,

distributed, or Web based (IBM, 2015).

Web services can be combined in order to

achieve specific functionalities. The process of

assembling of these services together is called

service composition (Alférez et al., 2013). The

service composition can be defined as the process of

constructing a complex service from atomic ones to

achieve a specific task (Szyperski, 2000).

Web services are executed in dynamic

environments in which several exceptional situations

may arise continuously. We find out as cited in

(Zeginis and Plexousakis, 2010) that the dynamic

nature of these environnments requires that Web

services

must be reactive and adaptive in order to

meet changing requirements.Therefore, these

changing requirements have to be taken into account

in the Web service composition process.

Furthermore, a support for the Web service

adaptation according to the context is required.

Among the most popular composition languages

for Web services we note BPEL (Business Process

Execution Language) (BPEL, 2007). BPEL is the

de-facto standard language used to define processes

through the composition of Web services (Domingos

et al., 2013). Nevertheless, BPEL neither supports

dynamic changes (Charfi and Mezini, 2007) nor

does it offer a support for the dynamic adaptation of

the orchestration logic according to the context

(Boukadi et al., 2009; Yamato et al., 2010). This fact

is triggered by the static nature of BPEL process

definitions which makes it difficult to adapt Web

services at runtime (Domingos et al., 2013).

In (Boumhamdi and Jarir, 2010), the authors

confirms the inability of BPEL engine to monitor

running processes and thereafter to decide which Web

service has to be replaced or omitted from a given

composition in certain circumstances (e.g. when a

service execution failure happens). BPEL needs to be

redeployed in order to be adapted. The redeployment

of the BPEL process implies the downtime of all the

system since all services should be stoped until the

modification process is done (Tout et al., 2015).

In this paper, we propose a methodological

approach allowing to support the dynamic

adaptation of service compositions according to the

context based on BPEL.

The remainder of this paper is organized as

follows: Section 2 introduces the background

Section 3 presents an illustrative example. Section 4

presents the proposed approach. Section 5 provides

architecture for a support tool. Section 6 intoduces a

case study in order to validate our approach. And

finally, Section 7 concludes the paper.

614

Neffati, O., Kaabi, R. and Kraiem, N.

A Methodological Approach for the Dynamic Adaptation of Web Services to the Context.

In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 2, pages 614-624

ISBN: 978-989-758-187-8

2 BACKGROUND

This section will focus on the definition of the basic

concepts that are related to our approach.

2.1 Context and Context-awareness

The concepts of context and context-awareness are

defined and used in several approaches (Dey, 2001;

Han et al., 2013; Kim et al., 2012).

According to (Dey, 2001), the context is all

information that can be used to characterize an

entity. An entity can be a person, a place, or a

relevant object for the interaction between a user and

an application, including the user and the application

itself. (Chihani et al., 2011) consider that the

context-awareness is a particular type of formal

logic on which theories and artificial intelligence

algorithms (e.g. inference rules) can be applied in

order to automate the deduction of new contextual

knowledge and reasoning about the facts that

represent the situation of the user.

Context-aware service oriented systems refer to

applications that use context information to provide

appropriate services to the user (Guermaha et al.,

2014).

2.2 Dynamic Adaptation

According to (Chaari, 2007), the adaptation consists of

making changes to a software or a computer system in

order to perform its features and, if possible, to improve

its performance in an environment of use.

Software adaptation can be seen as the ability for

humans to reconfigure the software and then to

restart it (static adaptation), or the ability of the

software to reconfigure itself during execution

(dynamic adaptation) (Akkawi et al., 2007).

According to (Keeney, 2004), the dynamic adaptation

of software behavior can be defined as the act of

changing the behavior of some part of a software

system as it executes, without stopping or restarting it.

3 ILLUSTRATIVE EXAMPLE

In order to illustrate our work, we use the example

of a hotel booking process (Figure1). The business

rules are described as follows: the customers can

make booking according to their preferences (e.g.

Arrival and departure dates, room type, service

type). They can check the availability of rooms

according to their arrival and departure dates. The

booking is made and the payment is done on the

basis of room’s availability.

We distinct four different payment methods:

credit card payment, cash payment, bank transfer

payment and check payment.

 Check the Room Availability: it aims at checking

the room availability overlooked the arrival and the

departure dates set by the customer.

 Make Booking: it corresponds to the assignment of

a room to the customer according to his preferences.

This task is a composite task (sub-process) that is

composed of the following tasks:

• Provide the Personal Information: It consists at

giving the information related of the customer i.e.

name, address, etc.).

• Specify the Arrival and the Departure Dates.

• Specify the room type. The room type can be

single, double, etc.

• Specify the Service Type. The customer has to

precise the service type: full board, half board, etc.

 Pay Booking: it corresponds to the payment of the

booking fees. The payment can be done by credit

card, by bank transfer, by check or cash.

We have chosen to model a given BPEL process

through the BPMN diagram (Business Process

Modeling Notation) (BPMN, 2011) for the following

reasons: BPMN tasks can express Web service

operations while BPMN sub-processes can express

composite service operations. Moreover, several

approaches (Ayora et al., 2012; Alférez et al., 2013;

Angles, 2014) have adopted BPMN model to represent

the elements in a service composition since BPMN is

suitable to express sequences and dependencies among

Web services, on the one hand, and BPMN diagram

can be transformed to an executable BPEL process

through several dedicated tools, on the other hand.

In this example, we will focus on the payment

service. We assume that the customer has chosen to

pay the reservation by credit card. At runtime, a

number of unexpected contextual changes can occur

such as the lack of money needed to cover the

booking fees, the expiration of the credit card, the

network failure, the service unavailability due to

fluctuations in available bandwidth and throughput

rates, etc. These facts make impossible the

achievement of the booking payment with the given

mean (i.e. by credit card). As consequence, the

payment process may not finish correctly.

Nevertheless, the booking process has not to be

stopped until the customer does not wish to finishes

it. For this, we need to propose a solution in order to

adapt the hotel booking process to the unexpected

changes that can occur at runtime in order to satisfy

the customer without shutting down the system.

A Methodological Approach for the Dynamic Adaptation of Web Services to the Context

615

Figure 1: The hotel booking example.

4 THE PROPOSED APPROACH

In order to adapt the hotel booking process to the

unexpected changes that can occur at runtime, we

present a methodological approach for the dynamic

adaptation of service compositions according to the

context. The proposed approach consists mainly of

two steps: “the context management” step and “the

adaptation actions” step.

The context management consists on the context

modeling, capture and reasoning. The adaptation

action consists of dealing with the context changes

by applying a set of adaptation rules which are

useful in order to adapt the BPEL process behavior

according to the context changes. Details will be

presented in section 4.1 and section 4.2.

4.1 The Context Management Step

This step is crucial especially in order to identify and

to model the contextual information pertinent for

services, to determine the current context.

4.1.1 A Context Model for Services

In order to use the contextual information in an

adequate manner, we need to define a context model

for the representation of the service context called:

CM4S (Context Model for Services). The proposed

model aims to represent the contextual factors

related to the service adaptation. The different

concepts for describing the contextual information

and the relationships between them are described

through the meta-model represented by Figure 2.

It should be noticed that only the elements with

the gray color belong to the proposed context meta-

Figure 2: The context meta-model for services.

model. The “Context” class is represented in order to

show its relationship with the concepts of the

proposed context meta-model. The concepts of the

CM4S are described as follows:

 Context Element: it represents a part of the

knowledge related to the context. The service user

context, the service context, the service execution

environment are examples of context elements.

 Context Property: it is considered as an attribute

that characterizes a context element. Indeed, a

context element is featured by one or more property

(ies) context. For example, the context element

“User context” has the following context properties:

profile and preferences (Figure 3). The context

property can be itself featured by other context

properties. For example, the “Profile” context

property can be featured by the context properties:

“age”, “nationality”, and “gender” (Figure 3).

We distinguish two types of context properties;

static context property which refers to a property

whose value is always fixed (e.g. the context

property “sex”) and dynamic context property which

refers to a property whose value can change(e.g. the

context property (e.g. the context property “time”).

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

616

4.1.2 A Context Ontology for Services

Ontologies are widely accepted for modeling context

information in many fields such as pervasive

computing, service engineering and business process

management. Ontology can be defined as a formal

explicit specification of a shared conceptualization.

A conceptualization is an abstract, simplified view

of the world that we wish to represent for some

purpose (Gruber, 1993; Studer et al., 1998).

We choose to use ontologies in order to

instantiate the context meta-model already proposed

in section 4.1.1(Figure 2).

Our choice is motivated by the following

reasons:

The context can be modeled as ontology since

the use of ontologies allows not only the context

modeling, but also the reasoning on the collected

contextual data based on an inference engine

(Guermaha et al., 2014).

Ontologies provide a formal and semantic

description of context information in terms of

objects, concepts, properties and relationships

(Najar, 2014). According to (Bettini et al., 2010), by

providing a formal semantics to context data, it

becomes possible to share and/or integrate context

among different sources. Also, many available

reasoning tools can be used both to check

consistency of the set of relationships describing a

context scenario, and to recognize higher level

context information. Thus, we propose an ontology-

based model (Figure 3) in order to show the

contextual information. Furthermore, in order to

provide an extensible, well structured and easily

understood ontology, we choose to use a multi-level

ontology. In fact, the context is modeled according

to two levels: (i) the general level (upper ontology)

and (ii) the specific level (lower ontology).The

upper ontology describes the basic context

information which is quite generic and common to

several areas while the lower ontology includes

specific context information which is related to a

particular domain.

According to the illustrative example, the

presented lower ontology is specific to the booking

area. We distinguish three categories for contextual

elements:

The User Context: it represents the contextual

information related to the service user. Examples of

the user context are: profile, preferences, etc.

The Web Service Context: it represents the

contextual information related to the service itself

such as the availability. We identify two general

types of Web service contextual information: the

first one is related to the business side of the service

such as its goal (service of electronic payment for

example) and its business rules. We qualify this type

as “functional requirements”. The second one is

related to the “non-functional” considerations of

Web services such as its availability, used security

protocol, etc.

The Environment Context: it represents the

information that characterizes the service runtime

environment such as the spatial and the temporal

factors.

Figure 3: The context based ontology model.

A Methodological Approach for the Dynamic Adaptation of Web Services to the Context

617

4.1.3 The Context Capture and Reasoning

The capture of the contextual information can be

made through several methods such as access to the

Information System (IS), access to the system

calendar, input by the user through an interface, etc.

A sensor can be defined as a hardware or

software source which can generate contextual

information (Indulska and Sutton, 2003). We

distinguish two main types of sensors, the physical

sensors that represent hardware devices which are

able to provide context data (e.g. GPS) and the

virtual sensors that provide contextual information

from software applications or services. Context

reasoning is used in order to deduce new contextual

information from existing one.

4.2 The Adaptation Actions

This section introduces a methodology in order to

express where and how a BPEL process can be

adapted at runtime, according to the context. This

methodology is represented using a BPMN diagram

and shown in Figure 4. The methodology, that we

propose, addresses the BPEL process dynamic

adaptation through two axes. The first one is

interested by the adaptation of the BPEL process

before the detection of an execution failure. We

qualify this type of adaptation as “preventive

adaptation”. It aims to minimize the chances of the

execution failure emergence. The second axe aims to

adapt the BPEL process after the detection of an

execution failure and determines a solution through

the change of the current BPEL process behavior.

We qualify this type of adaptation as “curative

adaptation”.

4.2.1 Preventive Adaptation

This mechanism is applied on each “switch” activity

in a given BPEL process (Exclusive gateway in

BPMN). The “switch” activity evaluates the state of

the business process and, based on the condition,

breaks the flow into one of the two or more mutually

exclusive paths. We qualified the “switch” activity

as a “decision point”. A BPEL process can contain

one or more decision point.

According to the booking process presented in

section 3, the decision point corresponds to the

exclusive gateway related to the payment method

choice. This gateway allows the customer to pay the

booking fees by credit card, check, bank transfer or

cash. The proposed alternatives as shown in the

BPMN diagram (Figure 3) are: “pay booking by

credit card”, “pay booking by check”, “pay booking

by bank transfer” and “pay booking cash”. We

assume that the offered Web services that participate

in this BPEL process and which can accomplish

these alternatives are respectively: “PayCard”,

“PayCheck”, “PayBankTransfer” and “PayCash”.

Depending on the current context zero, one or

more alternatives may be suitable to be offered to

the user who will choose, thereafter, only one

alternative to make the booking payment. Hence, it

is not necessary that all the Web services that are

associated with these alternatives are adequate to the

current context.

A context-based selection should be performed

in order to provide to the user only the services that

can be executed depending on such context. This

fact allows to minimize the chance of the BPEL

execution failure caused by the incoherence of some

Web services with the current context, on the one

hand, and reduces the time allocated to the execution

of the BPEL process due by the providing of

unusable Web services, on the other hand.

For example, in a given context in which the user

credit card is expired, it is impossible to execute the

service “PayCard”. This Web service should not be,

therefore, offered to the user from the beginning.

Figure 4: The adaptation methodology.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

618

Only the Web services “PayBankTransferCard”,

“PayCheck” and “PayCash can be offered to the

user. Indeed, being informed about the expiration

date of the credit card before the service running

allows to know at an early stage if the service can be

executed or not. Hence, this fact prevents the

execution failures which can arise thereafter.

Besides, it is beneficial in terms of time to avoid the

proposal of unusable Web service in a given context.

In order to select the appropriate alternatives that

can be offered to the user according to the context,

we propose the following method which includes the

following five steps:

(i) Identify each switch activity in BPEL (XOR

gateway in BPMN) as a “decision point”.

This

activity evaluates the state of the business

process and based on the condition breaks the

flow into one of the two or more mutually

exclusive paths.

(ii) Identify, for each decision point, the relevant

contextual elements.

(iii) Capture the values of the contextual elements,

already identified, for the current context.

(iv) Determine, for each proposed alternative, if its

execution is possible with reference to the

values of the current contextual elements or not.

(v) Keep only the adequate alternatives and ignore

the inadequate ones from the process schema.

Zero, one or several alternatives can be selected to

be kept in the process schema. The aim of this

adaptation is to adapt the BPEL process to the

current context in order to prevent failure execution

cases caused by the context negligence.

4.2.2 Curative Adaptation

The curative adaptation is useful when no alternative

is adequate to the current context after the

application of the “preventive adaptation”. This fact

implies that the current BPEL process will not be

finished correctly since a Web service that

participates to this process cannot be executed.

This category of adaptation proposes to use

additional Web services (i.e. new functionalities

offered by Web services) which are not included in

the initial BPEL process. The use of the additional

Web services leads to the modification of the initial

process schema by the emergence of other

alternatives initially absent. We qualify the

additional Web services as “adaptation services”.

Their usefulness is to ensure the dynamic adaptation

of the BPEL process at runtime, according to the

current context. The adaptation services are Web

services which are published by the service provider

and stored at the UDDI repository (UDDI, 2004). They

will be invoked in the situation of no proposed

alternative within the initial process is suitable to the

current context. The definition of the adaptation

services is made at each decision point when one or

more adaptation services can be associated with the

decision point. In the case when only one adaptation

service is associated with the decision point, this

service adaptation will be directly invoked to be

inserted into the current BPEL process. Else, in the

case where several adaptation services are associated

with the decision point, an association <context,

adaptation service> (i.e. for each given context there is

a corresponding adaptation service) will be created by

the service provider, and the selection of the best

adequate adaptation service is therefore based on this

association. The execution of the already invoked

service leads to a particular state in the process

(BPMN, 2011), e.g. the execution of the Web service

“confirm registration” in the university registration

process leads to the generation of the state “registration

is confirmed”. If the state generated after the execution

of the invoked service is the same generated at the end

of the process, then the process will take end. Else if

the state generated after the execution of the invoked

service is the different to the generated one at the end

of the process, then the process have to return again to

the already defined decision point.

5 ARCHITECTURE OF SUPPORT

TOOL

In order to provide a potential implementation of the

proposed approach, we propose the architecture

shown in Figure 5. This architecture is composed of

three modules:

 The Context Management Module

 The Adaptation Service Management Module

 The Adaptation Management Module

The role of each identified module and the

interaction between them is detailed as follow:

1) Context Management Module: it is mainly

responsible for the capture, the modeling, the

interpretation and the storage of the contextual

information (user context, service context, etc.).

This module consists of the following sub-modules:

(i)The Context Capture Sub-module: it is responsible

for the capture of the contextual information values

and its interpretation.

(ii)The Context Storage Sub-module: it is

responsible for the storage of the contextual

information. It consists of a context register.

A Methodological Approach for the Dynamic Adaptation of Web Services to the Context

619

Figure 5: The support tool architecture.

2) The Adaptation Service Management Module:

it is responsible for the storage and the management

of the adaptation services which are invoked when

required in order to adapt the running BPEL process.

3) The Adaptation Management Module: it is

responsible for the adaptation process of the BPEL

process by applying the adaptation rules. It is related

to both the Context Management Module in order to

extract the contextual information already stored and

the Adaptation Service Management Module in

order to select and to invoke the adaptation service.

This module consists of the following sub-modules:

(i)The Extraction Contextual Information Sub

module: it extracts the contextual information

already stored in the context register.

(ii)The Adequate Service Selection Sub-module: it is

responsible for the selection of the adequate services

to be allowed to the user according to the context.

(iii)The Adaptation Service Selection and Invocation

Sub-module: it is responsible for the selection and

the invocation of the adaptation service.

The interaction between the different modules of

the proposed architecture is as follows:

The Context Capture sub-module captures

changes in contextual information related to the Web

service, to the user and to the environment (1). The

captured contextual information will be stored,

thereafter, in the context register (2). The Extraction

Contextual Information sub-module extracts the

contextual information already stored in the context

module selects the adequate services to be allowed

to the user according to the context (4). If it is

necessary (any service can be selected), the

Adaptation Service Selection and Invocation sub-

module selects and invokes the suitable adaptation

service (5).

6 CASE STUDY

We propose to implement our approach on the hotel

booking process (Section 3).

6.1 The Proposed Scenario

We take the following scenario: the customer

consults the hotel website in which he wants to

spend the holiday. He checks the room availability

overlooked the arrival and the departure dates.

Thereafter, he provides his personal information,

confirms the arrival and the departure date and

chooses a single room for his accommodation.

Thereafter, he chooses a half board accommodation.

Finally, the customer is redirected to the booking

fees payment space in order to pay the booking fees.

According to the initial process, the customer can

pay by card, by bank transfer, by check or cash. By

using our adaptation approach, the payment method

choice is a decision point in which only the adequate

Web services should be offered to the user.

6.2 Relevant Contextual Element

Definition

In order to identify the adequate Web services on the

basis of the proposed method explained in section

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

620

4.2.1, the exclusive gateway concerning the payment

method choice (Figure 1) is considered as a decision

point. Table 1 presents the defined relevant

contextual elements associated to the “payment

method choice” decision point.

Table 1: Relevant contextual elements related to the

“payment method choice”.

Decision

point

Relevant contextual elements

Payment

method

choice

Credit card possession

Checkbook possession

Cash possession

Bank account possession

Credit card status

Preference to pay by credit card

Preference to pay by check

Preference to pay by cash

Preference to pay by bank transfer

Client type

Current day

Pay by credit card service availability

Pay by check service availability

Pay by cash service availability

Pay by bank transfer

Service availability

The description of the relevant contextual

elements defined in Table 1 is as follow:

 Credit Card Possession: it indicates if the client

has a credit card or doesn’t.

 Checkbook Possession: it indicates if the client

has a checkbook or he doesn’t.

 Cash Possession: it indicates if the client has cash

or he doesn’t.

 Bank Account Possession: it indicates if the

customer has a bank account or he doesn’t.

 Credit Card Status: it indicates if the credit card

is valid or expired.

 Preference to Pay by Credit Card: that indicates

if the customer prefers to pay the booking fees by

his credit card or not.

 Preference to Pay by Check: it indicates if the

customer prefers to pay the booking fees by check or

not.

 Preference to Pay by Bank Transfer: it indicates

if the customer prefers to pay the booking fees by

bank transfer or not.

 Preference to Pay by Cash: it indicates if the

customer prefers to pay the booking fees by cash or

not.

 Customer Type: it indicates whether the customer

is accustomed to make bookings at this hotel or not.

If the number of bookings per year is more than five,

then the client is described as “faithful” otherwise he

is described as “normal”.

 Current Day: it indicates the current date.

 Pay by Credit Card Service Availability: it

indicates if the payment by credit card service is

available or not.

 Pay by Check Service Availability: it indicates if

the payment by check service is available or not.

 Pay by Cash Service Availability: it indicates if

the payment by cash service is available or not.

 Pay by Bank Transfer Service Availability: it

indicates if the payment by bank transfer is available

or not.

The selection of the adequate alternative requires

a given context. A context representation can be

defined as a conjunction (AND) of contextual

assertions which may be negative by a negation

operator (NOT) (Angles, R., 2014). The required

contexts related to the proposed alternatives are

described as follow:

 Pay Booking by Credit Card= ((Credit card

possession= yes) AND (Credit card status= valid)AND

(Preference to pay by credit card=yes) AND (Payment

by credit card service availability=yes)

This assertion implies that in order to use the

“PayCard” Web service, the customer should have a

valid credit card and the use of the card has not to be

out of his preferences. Besides, the “PayCard” Web

service should be available at the current time.

 Pay Booking by Check= (Check book

possession=yes) AND (Preference to pay by

check=yes) AND (Payment by check service

availability=yes)

This assertion implies that in order to use the

“PayCeck” Web service, the customer should have a

check book, and the use of the check book has not to

be out of his preferences. Finally, the “PayCeck”

Web service should be available at the current time.

 Pay Booking by Bank Transfer= (Bank account

possession=yes) AND (Preference to pay by bank

transfer=yes) AND (Payment by bank transfer

service availability=yes) AND NOT ((day =

Saturday) OR (day= Sunday))

This assertion implies that in order to use the

“PayBankTransfer” Web service, the customer

should have a bank account, and the use of the bank

transfer has not to be out of his preferences. Besides,

the “PayBankTransfer” Web service should be

available at the current time. Also, it should not be a

Saturday or Sunday day since most banks are closed

these days.



Pay Booking by Cash=(Cash possession=yes)

AND (Preference to pay by cash=yes) AND

(Payment by cash service availability=yes)

This assertion implies that in order to use the

“PayCash” Web service, the customer should have

A Methodological Approach for the Dynamic Adaptation of Web Services to the Context

621

cash, and the use of cash has not to be out of his

preferences. Finally, the “PayCash” Web service

should be available at the current time.

6.3 The Relevant Contextual Element

Capture

We assume that, in the current context, the capture

of the relevant contextual elements values shows the

following elements (see Table 2). These values can

be captured explicitly or implicitly. We give just a

preview.

Table 2: Relevant contextual elements values.

Relevant

contextual

element

Value Capture method

Credit card

possession

Yes Explicit (provided by

the user)

Credit card

status

valid Implicit (by the access

to the calendar)

... ... ...

6.4 Adequate Web Services Definition

We assume that the current context allows using

only the credit card in order to pay the booking fees.

Figure 6: The new process schema after the “preventive

adaptation”.

Hence, only the “PayCard” Web service will be

offered to the user in this context. This “preventive

adaptation” modifies the initial booking process

(Figure 6).

6.5 Adaptation Services Definition

As mentioned in section 4.2, each decision point is

associated with one or more adaptation services.

We assume that the service provider associates

the following adaptation services to the “payment

method choice” decision point:

 “KeepingReservation2Days” adaptation service:

allows keeping the booking process for two

additional days.

 “KeepingReservation4Days” adaptation service:

allows keeping the booking process for additional

four days. It is used especially when it is a weekend

period for example and keeping the reservation

process only for two days is not enough.

 “ValidateReservation” adaptation service: allows

validating the booking process as if the customer

paid the booking fees. This adaptation service can be

used in rare cases where a customer is considered

“faithful customer” (i.e. who’s the number of

booking made during the year exceeds five times).

This service does not replace the booking payment

service but rather to validate the booking in order to

satisfy a “faithful customer” and terminates the

process as well. The specification of the payment

procedure in this case is left to the enterprise

business expert. For example, when a new booking

process is launched by the “regular customer”, the

fees payment of this booking is made.

The already defined adaptation services and their

required contexts (defined by the business expert of

the enterprise) are presented in Figure 7.

Figure 7: The adaptation services and their required contexts.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

622

Currently, we do not have need to use an

adaptation service from the three proposed ones

since the definition of adequate alternatives step

implies that the “PayCard” service is adequate to the

current context and it can be used by the customer.

6.6 Context Change and Adaptation

Service Selection

When the user enters the credit card number to make

the booking payment, an alert notifies him that his

credit card amount is not sufficient to cover the

accommodation fees. Hence, the payment cannot be

made with this credit card. The alert is an event that

will trigger either the proposal of another alternative

(i.e. the use of another allowed Web service if it

exists) or the looking for a suitable adaptation

service in the case of the absence of another

alternative. In our case, there are no other

alternatives offered to the customer since the only

possible way is “Pay booking by credit card”. The

call for an adaptation service remains the only

possibility in order to adapt the BPEL process.

According to the new context, the adaptation

service “KeepingReservation4Days” will be selected

and invoked (see Figure 8).

Figure 8: The adapted process after the “curative

adaptation”

7 CONCLUSION AND FUTURE

WORK

In this paper, we have presented a solution to

support the dynamic adaptation of service

compositions. The “preventive adaptation” is carried

out before the execution of the services that

participate to the process. This adaptation is based

on the selection of adequate services depending to

the current context. The “curative adaptation” is

carried out at the service runtime and it is based on

the invocation of the “adaptation service”. Our

solution is validated by a hotel booking case study

and illustrated by a support tool architecture.

Actually, we are working on the implementation

of the proposed support tool architecture. Also, we

look to extend our approach in order to handle with

the service composition issue in unknown contexts.

REFERENCES

IBM, 2015. Available at: < http://www 01.ibm.com/sup

ort/knowledgecenter/SSBTEG_4.3.0/com.ibm.wbia_a

dapters.doc/doc/webservices/webservices17.htm%23H

DRI1020534?lang=fr > [Accessed December 2015].

Alférez, G.H., Pelechano, V., Mazo, R., Salinesi, C. and

Diaz, D., 2013. Dynamic adaptation of service

compositions with variability models. J. Syst.

Software.

Szyperski, C, 2000. Component Software and The Way

Ahead, chapter 1, pages 1–20. Cambridge University

Press.

Zeginis, C and Plexousakis, D., 2010. Web Service

Adaptation: State of the art and Research Challenges.

Technical Report. ICS-FORTH.

BPEL, 2007. Available at: < http://docs.oasis-open.org

/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf> [Accessed

December 2015].

Domingos, D., Martinho. R. and Cândido.C., 2013.

Flexibility in cross-organizational WS-BPEL business

processes. Journal of Procedia Technology. Elsevier.

Charfi, A and Mezini, M., 2007. AO4BPEL: An Aspect-

Oriented Extension to BPEL. World Wide Web., 10(3),

pp 309-344.

Boukadi.K., Ghedira, C., Maamar, Z., Benslimane, D. and

Vincent.L., 2009. Context-Aware Data and IT

Services Collaboration in E-Business. Transactions on

Large-Scale Data- and Knowledge-Centered Systems

I. Volume 5740 of the series Lecture Notes in

Computer Science pp 91-115.Springer.

Yamato, Y., Nakano, Y. and Sunaga, H., 2010.Context-

aware Service Composition and Change-over Using

BPEL Engine and Semantic Web. Book

ISBN9537619540, 9789537619541. INTECH Open

Access Publisher.

Boumhamdi, K. and Jarir, Z., 2010. A Flexible Approach

to Compose Web Services in Dynamic Environment.

International Journal of Digital Society (IJDS),

Volume 1, Issue 2.

Tout, H., Mourad, A., Talhi, C. and Otrok, H., 2015.

AOMD approach for context-adaptable and conflict-

free Web.

services composition. Computers and Electrical

Engineering. Elsevier.

Dey, A.K., 2001. Understanding and Using Context.

Personal and Ubiquitous computing. vol. 5, n° 1.

Springer Verlag.

Han, S.N., Lee, G. and Crespi, N., 2013. Semantic

Context-aware Service Composition for Building

A Methodological Approach for the Dynamic Adaptation of Web Services to the Context

623

Automation System. IEEE Transactions on Industrial

Informatics, Vol: PP, no. 99. IEEE.

Kim, J.D., Son, J. and Baik, D.K., 2012. CA5W1H onto:

ontological context-aware model based on 5W1H.

International Journal of Distributed Sensor Networks.

Chihani, B., Bertin, E. and Jeanne. F., 2011.Context-

Aware Systems: A Case Study. Digital Information

and Communication Technology and Its Applications,

Communications in Computer and Information

Science, Volume 167, pp 718-732. 2011.

Chaari, T., 2007. PhD thesis. Adaptation of pervasive

applications in multi-contexts environments. The

National Institute of Applied Sciences in Lyon.

Akkawi, F., Akkawi, K., Bader, A., Ayyash, M., Fletcher,

D. and Alzoubi, K., 2007. Software adaptation: A

conscious design for oblivious programmers. In:

Proceedings of the IEEE Aerospace Conference. pp.

1–12.

Keeney, J., 2004. Completely unanticipated dynamic

adaptation of software. Ph.D. thesis, Trinity College

Dublin.

BPMN, 2011. Available at <http://www.omg.org/spec/BP

MN/2.0/> [Accessed December 2015].

Ayora, C., Alférez, G. H., Torres, V. and Pelechano, V.,

2012. Applying CVL to business process variability

management. In: Proceedings of VARiability for You.

MODELS pp. 24–29.

Angles, R., 2014. Adaptation Dynamique des Processus

Métier. Adaptation of Business Process. Ingéniere des

Systèmes d'Information, Volume 19.

Gruber, T.R., 1993. Toward principles for the design of

ontologies used for knowledge sharing. Presented at

the Padua workshop on Formal Ontology.

Studer, R., Benjamins, R. and Fensel, D., 1998.

Knowledge engineering: Principles and methods. Data

& Knowledge Engineering 161–198.

Guermaha, H., Fissaaa, T., Hafiddia, H., Nassara, M. and

Kriouilea, A., 2014. A Semantic Approach for Service

Adaptation in Context-Aware Environment.

International Symposium on Emerging Inter-networks,

Communication and Mobility. Elsevier.

Najar, S., 2014. Adaptation of sensitive services to the

context according to an intentional approach. PhD

thesis, University of Paris I –Pantheon Sorbonne.

Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J.,

Nicklas, D., Ranganathan, A., and Riboni, D., 2010. A

survey of context modelling and reasoning techniques.

In Pervasive Mobile Computing 6(2), pp. 161–180.

UDDI, 2004. Universal, Description, Discovery and

Integration. Version 3.0.2. Available at <

http://www.uddi.org/pubs/uddi-v3.0.2-20041019.htm

> [Accessed December 2015].

Indulska, J., and Sutton, P., 2003. Location management

in pervasive systems. In Proceedings of the

Australasian Information Security Workshop

Conference on ACSW Frontiers, pp. 143–

151.Paris.France.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

624