Adaptation Services-oriented Systems LifeCycle

I. Elmagrouni

, A. Kenzi

, M. Lethrech

and A. Kriouile

SIME Laboratory, ENSIAS, Mohammed V University, Rabat, Morocco

Sidi Mohamed Ben Abdellah University, Fes, Morocco

Keywords: Development Process, SOC, CAC, SOA / Web Services, MDA.

Abstract: This work presents the approach of the Development of adaptable Services-oriented Systems. Not the only

adaptability is important for the survival and success of Services-oriented Systems, but it is also important

for the rapid changes in technology, organizational structure, human perception and needs. This paper

discusses the shortcomings of current solutions for adaptive service-oriented System. To address those

shortcomings, some techniques are used to build and evolve proactive Services-oriented Systems. Using

those techniques in an integrated way is described along the phases of the service lifecycle.

1 INTRODUCTION

The service-oriented computing (SOC) uses services

as basic constructs to support the rapid development

of low cost, and easy composition of distributed

applications even in heterogeneouscomputing

environments.SOCperspectiveis to join services in a

network of loosely coupled services, create flexible

business processes and agile applications that can

span different organizations and computing

platforms.Besides, CAC (Context-Aware

Computing) has been proposed to adapt applications

and software systems to different useful contexts.

These cover all the information that characterizes the

situation of an entity. An entity can be a person,

place, or object that may be relevant to the

interaction between the user and the application.

One of the challenges oflifecycleservicesis the stage

that identifies the services that support the business

activities of the organization.There are many

objectives of this paper. Firstly,is the definition of a

development process to guide the development of

adaptable SOS from business requirements.

Secondly, is the definition of phases, activities, and

artifacts that allow the identification, specification

and implementation of adaptive services.The life-

cycle models; for Service-Based applications that

have been presented in the literature (examples

include SLDC, RUP for SOA, SOMA, and SOAD)

are mainly focused on the phases that precede the

release of software; and even in the cases in which

they focus on the operation phases, they usually do

not consider the possibility for to adapt dynamically

to new situations, contexts, requirement needs,

service faults, etc.Specifically, the following aspects

have not been yet considered in those life-cycle

models: Requirements elicitation, design for

adaptation.

The first section briefly presents the work and

the approaches that are related to the study. The

second section describes the case study to illustrate

the approach. The Third section focuses on the

process definition which will enable the

development of adaptive services. Last but not least,

the article will be summed up with a conclusion and

outlook.

2 RELATED WORK

(S.Lane et al., 2011).conducted identified adaptation

activities that could be used to adapt Service

oriented system (SOS). These activities combined

with a skeleton life-cycle model; proposed by the S-

Cube consortium, formed the basis of reference

process model’ frame for adapting Service-Based

applications (SBA). This frame of reference was

used to guide interviews with development

practitioners who had experience and could provide

expert’ opinion Service-Based applications’

adaptation. Thecollected data of these interviews

was transcribed and analyzed by using qualified

content analysis techniques. The result of adaptation

activities and tasks were constructed into a detailed

Elmagrouni, I., Kenzi, A., Lethrech, M. and Kriouile, A.

Adaptation Services-oriented Systems LifeCycle.

In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 1, pages 223-231

ISBN: 978-989-758-187-8

223

process model identifying the relevant stakeholders

and development artifacts for each stage of the

process. The model’s transfer and ability were

demonstrated during an evaluation process where

the model was systematically compared to a

component-based application adaptation model and

an empirically based SBA development life-cycle.

The approach’s advantages are over similar

approaches because it focused and based on input

provided by experts from the field.

A method proposed by Azevedo et al. [14] with

activities to guide the designer to identify the

most suitable set of services to support the

business activities of the organization. The method

consists of the following steps: (1) Selection of

activities subject to automation - this stage selects

process activities TO-BE where can be identified

candidate services, (2) Process models are

represented using the Event-driven Process

Chains (EPC) and Function Allocation

Diagram (FAD), (3) Candidate services

identification and classification - activities

identified in the previous step are analyzed

within their contexts in process models according

to a set of heuristics, and (4) Consolidation of

candidate services supported by the use of heuristics.

A guideline is proposed by Shirazi et al. [15]

for the service identification using two

approaches: top-down and bottom-up. The bottom-

up approach is used to identify applications and

entities services; while top-down approach’s goal

is to recognize the business services and services

oriented tasks. The method consists of the

following steps: identifying business processes,

making business use-case model, identifying

entity-centric services, recognizing application

services, identifying task-centric services and

recognizing process centric services. Marks and Bell

proposed a Service Lifecycle; this cycle includes the

service evolution from conception to maturity along

its execution. The identification of business services

is performed using a top-down and bottom-up

approach in iterative cycles. In order to identify new

candidate business services, the author proposes

an analysis of the following sources: business

process, entities (interest and principal), budgeted

projects, business experience, preexisting services

and existing business applications. Arsanjani et al.

[8] presented a method for service-oriented solutions

developing called Service-Oriented Modeling and

Architecture (SOMA). Specifically for services

identification phase, the paper points out that a good

practice uses a set of complementary techniques to

identify services and cites three service

identification techniques: (1) Goal-Service

Modelling (GSM), treats the services aligned to the

business goals, (2) Domain decomposition is

performed through a top-down analysis of

business domains and business processes

modelling that are identified services, components

and flows. The aim is to consider the static and

dynamic view of the business including information

rules and variations.

(3) Analysis of the existing asset is performed by

bottom-upanalysis of the existing application

portfolio and other assets and patterns that can be

used to identify candidate services. After the

application of the described techniques, the method

also comprises the following step:

refactoring and rationalization of the service

whose service granularity is determined. Finally, a

series of criteria are applied to determine

which service is appropriate for candidates’

publication.

3 E-TOURIST MOTIVATING

SCENARIOS

Let us consider the following scenarios. Assume that

a user would like to use a mobile device (e.g., PDA,

iPhone, Smartphone, BlackBerry, etc.) with

thedifferent operating system (IOS, Android, etc.)

which is equipped with a GPS (Global Positioning

System) to find relevant restaurants with/without

open gardens. Figure 1 shows a model of application

mobile “Restaurant Finder”. Customers want to

browse available restaurants to view offered food

items and their cost. To this aim they must search a

set of potential restaurants and select one among

them. This application also aims to collect the

customers’ feedbacks regarding selected restaurants.

Finally, the average satisfaction of all customers

must be high. It can utilize various other services,

such as the Reverse Geocoding for mapping GPS

information to addresses, the Google Map for

finding businesses close to an address, the

Restaurant Data Service for searching restaurants

based on the user preferences, and the Weather

Information Service for obtaining weather

information. The service also offers graphical

information to the user with a reasonable delay

(Wifi, 3G, and text/image).

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

224

Figure 1: The Restaurant Finder.

4 ADAPTABLE SOS

DEVELOPMENT PROCESS

The proposed method described in Figure 2 is based

on MDA (Model driven architecture). It is composed

of three abstraction layers: the CIM (Computation

Independent model) which describes the system’s

requirements, the PIM (Platform independent

Model) which specifies the system independently of

any platform and the PSM (platform specific model)

which contains the service models related to a

specific platform.

Figure 2: Development Process of adaptable Service

Oriented System.

The first phase “Global analysis" is interested in

the feasibility study.

Furthermore, the method is composed of two

sub-processes:

An Evolution Process composed of the following

activities: analysis and design service identify

business requirement and implementation service.

An Adaptability Process which the main

activities is: analysis and design Adaptation

concerns the adaptation where system processes

should adapt to certain conditions and

implementation Adaptation.

4.1 Preparation

This phase is the preliminary study of the

complicated organization that identifies two points:

(1) business motivation model (2), Legacy system

analysis.

4.1.1 Business Motivation Model

We define business requirements for business

processes as the overall set ofrequirements that

relate to business processes as given by the Business

Motivation Model (BMM) of OMG, such as vision,

mission, goal, strategy, objective andtactic. More

specifically, a vision describes the future state of the

application, withoutregard to how it is to be

achieved, and mission indicates the ongoing activity

thatmakes the vision a reality. A goal indicates what

must be satisfied on a continuingbasis to effectively

attain the vision, and a strategy is a long-term

activity designed toachieve a goal. An objective is a

specific and measurable statement of intent

whoseachievement supports a goal, and a tactic is a

short-term action designed to achieve anobjective.

Figure 3: Business Model Motivation of Restaurant

provider.

4.1.2 Legacy System Analysis

In this step, the decomposition of existing systems in

the form of application modules is used to provide

an implementation for business services that were

previously identified. Then, we apply a bottom-up

approach, i.e. starting from the existing system to the

business services and business processes.

4.2 Services Analysis and Design

Business service identification is critical. Identifying

appropriate services with the right level of

granularity can have a major influence on the whole

system. It is agreed that all business services should

be identified to meet a business goal. Goals can be

formulated at different levels of abstraction; ranging

Adaptation Services-oriented Systems LifeCycle

225

from ahigh level and strategic to low level and

operational.

4.2.1 Business Process Design with Goal

Models

A goal model is used to capture why a business

process is needed – its purpose or goal – and the

different ways from which a goal can be attained.

The goal model has been designed based on the

design principle of Object-oriented Design, namely

Decomposition and Abstraction. Decomposition

principle is used to decompose a large problem into

subproblems. Each sub problem is at the same level

of detail, can be solved independently and can be

combined to solve the original problem. Based on

the above definition the goal model is designed to

specify a high-level goal which is decomposed into

subgoals and a hierarchical ordering of the subgoals

is done. Goal tree structure is used to represent the

model. In this, the high-level goal (problem) is

decomposed into one or more subgoals

(subproblems) and each subgoal is decomposed

further into one or lower level subgoals. This goal

becomes the root of the goal model. It is refined

using AND/OR decompositions until the resultant

subgoals can be delegated to either human actors or

software services.

Figure 4 shows the goal of Restaurant Provider

by tool OpenOME is an Eclipse-based tool designed

to support goal-oriented, agent-oriented and aspect-

orientedmodeling and analysis.

Figure 4: A goal model for the “Tourist System

Management” business process.

The general goal is to provide Restaurants that

AND-refined into the following sub-goals: Find

Restaurant withhigh quality service and which

provide both textual and graphical mode.

4.2.2 Enriching Goal Models for BP

Modeling

Since we are interested in the automated execution

of business processes, we needto capture more

information about BPs than the basic goal models

allow. A few annotationsare introduced for this

purpose. Note that the annotations presented here

arenot required to be formal. We use the following

control flow annotations when employinggoal

models to represent business processes:

• Parallel (“Para”) and sequence (“Seq”) annotations

can be used with ANDdecomposedgoals to specify

whether or not their subgoals are to be achievedin a

temporal order. For example, billing customers and

shipping goods are doneconcurrently in the process.

• Sel (“if(condition)”) indicate the necessary

conditions for achievingsubgoals. For example, in

Fig. 2 the goal Order Out Of Stock Product

isachieved only if the item is not already in stock.

•Loops (“while(condition)” or “for(setOfItems)”).

For instance, the goal Add OrderItem must be

achieved for all items in the order.

Table 1: Annotation for Business Processes.

Annotation Meaning

Seq Sequential execution of activities

Loop Repeated execution of activities in a

loop

Sel Conditional selection of activities

Para Parallel execution of activities with

complete synchronization

4.2.3 Modeling of Input/Output

Modeling of input/output parameters of goals is also

important for BP modeling. Identifying inputs and

outputs during the analysis of a business domain

help in determining resource requirements for

achieving goals as well as for the sequencing of the

goals. The types of inputs and outputs can also be

specified. While optional, the input/output types can

be used to generate detailed specifications for

messages and service interfaces in a BP

implementation.

Name: Collect Requests

Input/Output:

r: ReceiveRequest; rc :RestaurantsCollection

DomainPrecondition:

rc:state = default

DomainPostcondition:

rc:state = req initialized

RequiredPrecondition:

rc:keyword = “” ^ rc:date = null

^rc:distance = “” (r:keyword ≠ “”˅ r:date ≠ null˅ r:distance≠ “”)

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

226

RequiredPostcondition:rc:keyword = r:keyword ^ rc:date

= r:date ^ rc.distance=r:distance^Collect(rc:keyword;rc:date)

User: Tourist

Context: Device, Location, Time, Profile, Resturants

Preference, Weather

Name: Find Graphical Content

Input/Output:

rc :RestaurantsCollection

DomainPrecondition:rc:state = req_initialized

DomainPostcondition:

rc:state = restaurants received

RequiredPrecondition:rc:keyword = “” ^ rc:date = null ^

rc:distance=“” ^ (r:keyword≠ “”˅ r:date ≠ null˅r.distance≠ “”)

RequiredPostcondition:

∈∀ n rc:restaurants: n:keyword

= rc:keyword˅rc:date n:date˅ rc:distance= n:distance ^n:text≠

null ^ n:images ≠ null

User

: Tourist

Context: Device, Location, Time, Profile, Resturants

Preference, Weather

An operation is defined through name, input and

output values and pre- and post-conditions. Required

preconditions (ReqPre) define when the

operationcan be executed.Required post-conditions

(ReqPost) define additional conditions that mustbe

true after execution. Domain pre- (DomPre) and

post-conditions (DomPost) define the effects of the

operation on the domain.The definition of operation

Find Text Content is similar to operation Find

Graphical Content except for the required post

condition that is specified as follows:

ReqPost:

∈∀ n rc:restaurants: n:keyword = rc:keyword ˅

rc:date n:date˅ rc:distance= n:distance ^n:text ≠ null ^ n:images

= null

4.3 Adaptation Analysis and Design

It is interested in capturingspecific adaptation

requirement for SOS. To control service Adaptation,

a designer needs to knowwhy a change was made,

what are the implications, and whether the change is

consistent or not. Eliminating spuriousresults and

inconsistencies; that occur due to uncontrolled

changes, is a necessary condition for services

toevolve gracefully, ensure stability and handle

variety on their behavior.

4.3.1 Typology of Adaptation

The nature of service Adaptations can be

classifieddepending on their causal effects as

follows:

• Minor Adaptations: these are small-scale

incremental changes that are localized to a service or

arerestricted to the clients of that service.

• Major Adaptation: these are large-scale

transformational changes cascading beyond the

clients of aservice, possibly to entire value chains.

Typical Minor Adaptation focuses on structural level

changes (service types, messages,

interfaces,andoperations) and business protocol

changes (the conversations in which the service

participates). TypicalMajor adaptation

includespolicy-induced (pertaining to business

agreements between service providers

andconsumers.

Figure 5: Minor and Major Adaptation.

4.3.2 Dealing with Adaptations

Service Adaptation requires an adaptation-oriented

service lifecycle methodology to provide a sound

foundation for spreading changes in an organized

fashion that impacted services in a servicechain are

appropriately configured, aligned and controlled as

thechanges occur.

The purpose of the adaptation-oriented service life

cycle is to ensure that standardized methods

andprocedures are used for efficient and prompt

handling of all servicechanges in order to minimize

theimpact of change-related incidents upon service

operation and quality. This means that in addition

tofunctional (structural and behavioral) changes,

adaptation-oriented service life cycle must deal with

policy-induced operational behavior and non-

functional changes. Figure 6 illustrates an adaptation-

oriented service life cycle that comprises a set of

inter-related phases, activities, and tasks that define

the change process from the start through to

completion. Each phaseproduces a deliveredmajor

that contributes towards achieving change objectives.

Logical breaks arealso provided in the change process

and are associated with key decision points. The

phases of the lifecycle are discussed in the next part.

Figure 6: adaptation-oriented service life cycle.

Adaptation Services-oriented Systems LifeCycle

227

The initial phase Figure 6 “Define Adaptation

Requirement” focuses on identifying the need for

adaptation and scoping its extent. One of the major

elements of this phase is understanding the causes of

the need for adaptation and their potential

implications.

The secondin Figure 6 (“Analyze impact of

Adaptation”) focuses on the actual analysis, re-

designor improvement of existing services. The

ultimate objective of service adaptation analysis is to

provide an in-depth understanding of function,

scope, reuse, and granularity of services that are

identified for adaptation. The problem lies in

determining the difference between existing and

future service function.To analyze and assess the

impact of changes, organizations rely on the

existence of an “as-is” and a “tobe”service model

rather than applying the changes directly to

operational services. Analysts rely on an

“as-is”

service model tounderstandthe portfolio of available

services. This model is used as thebasis

forconducting a thorough re-engineering analysis of

the current portfolio of available services that need

toevolve. The “to-be” service model is used as

thebasis for describing the target service

functionandperformance levels after applying the

requiredadaptation.To determine the differences

between these two models, a gap analysis model is

used to help prioritize, improve and measure the

impact of service adaptation.

During the third and final phase “Identify

adaptation strategy and trigger” in Figure 6, In

order to select the adaptation strategy which should

be applied, it is necessary to consider that adaptation

maybe associated with a set of conditions and a

trigger that are important for designing and

performing adaptation. The trigger states when the

adaptation Service must be activated. Each

adaptation Service is operated through adaptation

actions as explained in Table 2.

Table 2: Description of the two adaptation action.

Adaptation

Action

Description

Substitution The Possibility of configuration with a

dynamic substitution of the service with

another one

Performance The possibility of going back in the

process for performing an alternative

path or redoing the same set of tasks

4.4 Service Implementation

It is based on the following step: Generating

Business Processes

4.4.1 Generating Executive Business

Processes

A method has been devised for using goal models to

assist with the development and configuration of

high- adaptability (flexible) BPEL processes. This

makes it possible to generate BPEL processes that are

easily readable by humans and are structured after the

respective goal models. The BPEL code generation is

semi-automatic. The generated code is not

immediately executive so it needs to be completed.

Nevertheless, provides valuable help in producing an

executable BP based on the source goal model, the

code is to be further developed by integration

developers, who will also be selecting/designing Web

services to be used by the process.

Figure 7: Example of WS-BPEL 2.0 code generation.

We start BPEL generation from the root goal and

recursively through the goal tree until we reach leaf

goals. Some of the goal models are presented to

BPEL mappings through the example in Fig. 5,

which shows a generic annotated goal model

fragment. The root goal G has a sequential AND

refinement, so it corresponds to the sequence

operator in BPEL. G1 has a similar AND

refinement, so it maps to the flow construct. G2 has

a data-driven OR refinement, so it generates the if-

elseif(BPEL 2.0) or the switch (BPEL 1.1) operator.

Note that the conditions c1 and c2, which

areinformal descriptions in the goal model, will be

replaced with the appropriate conditions by a BPEL

developer. While we abstract from some of the low-

level BPEL details such as correlations, with the

information captured in the annotated goal models,

we also generate the following aspects of

BPEL/WSDL specifications.

• We do an initial setup by defining the appropriate

interface (portType), etc. for the process. A special

portType for invoking the process and providing it

with the (initial) configuration is also defined.

• A conditional/loop annotation for a goal G is

mapped to the appropriate BPEL construct (e.g., if-

elseif or switch, while, etc.) with the activity to be

executed being the result of mapping the goal model

subtree rooted at G into BPEL. The formal

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

228

conditions currently have to be specified manually.

• Leaf-level goals map into Web service invocations.

The information in the goal model helps in defining

the interface for the Web services invoked by the

BP. We define appropriate WSDL messages based

on input/output parameters of these goals. If data

types are omitted from the goal model, they have to

be supplied by a developer.

• Softgoals are used as the evaluation criteria in the

configuration process and thus do not map into the

resulting BPEL specification.

4.5 Adaptation Implementation

This activity involves in the implementation of the

adaptation Mechanisms that were described in the

phase analyze and design adaptation. Each

conventional goal, which represents a functional

requirement (i.e., it is operationalized),is mapped onto

the corresponding sequence activity in the BPEL

process. If the goal represents a non-functional

requirement, but its nearest ancestor goal is

operationalized, it is associated with the same sequence

of its parent goal. This activity must represent an

interaction of the process with its partner services (e.g.,

invoke, pick, and receive).Each adaptation goal is

associated with a set of actions that must be performed

at theprocess level.A triggering rule activates the

evaluation of the trigger associated with the goal. A

condition rule evaluates the conditions linked to the

goal. If the two previous rules provide positive

feedback, an activation rule is in charge of the actual

execution of the adaptation actions. Performed when an

adaptation goal can potentially fire (i.e., the

corresponding Activation fact is available in the

working memory) and is selected by the rule engine to

be performed, among the other adaptation goals that

can be performed as well. It executes the actions

associated with that adaptation goal. For example, the

triggering rule associated with ABG1 is the following:

when

Goal(id=="FGR", satisfaction < 1)

then

workmemory.insert(new

Trigger("TriggerABG1));

5 ADAPTATION ASPECTS

WEAVER

The adaptation Implementation follows a three-step

process (see Figure 10):

1. Context detection consists of checking the

runtime context information, in order to detect

possible context changes. These tasks are performed

by the Context Manager Service which is developed

as a Web service in the BPEL process.

2. Aspect Activation is responsible for the plug-in

and the removal of pre-defined Aspects into the

BPEL process using the Aspect Activator

Module.The Aspect Activator Module is conceived

as an extension to the BPEL engine when running a

process instance; the Aspect Activator receives the

context change information from the Context

Manager Service.

3. Updating original BPEL Process by activating the

right Aspect which is executed in the BPEL process.

Figure 8: The adaptation process.

5.1 Adaptation Tools

We propose an evolved adaptationtool, based on the

context manager and aspect, this tool allows

selectingwhich services to invoke, and adapt them.

These toolsare divided into three distinct layers,

namely (see Figure 9): Application layer, Adaptation

layer, and a Resource layer. These different layers

are described as follows in the following.

Figure 9: Technical architecture of adaptation.

Adaptation Services-oriented Systems LifeCycle

229

Application Layer: It is the top layer of the

technical architecture, including application platform

which we implement our approach to adaptation.

The central element of this layer application server.

Typically, an application server is a server that Are

installed applications used by customers.

Adaptation Layer: This is the second layer of this

architecture. Placed between the application layer

and resource, it contains components which will

ensure the processing context information and any

other operations required to carry out the adaptation

of invoking services. Essentially, this layer contains

two modules:

The context manager is charged to collect the

information in context and to detect the possible

changes of this information. The context manager

will be called upon by process BPEL like any other

web service.

The second module is the activation of aspect.

Just like the context manager, the activation of

aspect is implemented under the form of a Web

service to interact better with the other elements of

the architecture. This module is always placed after

the context Manager in the process BPEL.

Figure 10: Aspect ExtraFes.

Resource Layer: It represents the third layer of this

technical architecture. The resource layer includes

all the resources needed for the other two layers. It

interacts essentially with the matching layer at the

two matching modules: the context manager and the

aspect activation module. The resource layer

includes the following:

- Repository Process: it lists all processes deployed

to the BPEL engine.

-Repository Service: this case represents the

functional service implemented as Web services.

-Repository Aspect: contains all aspects represented

as an XML tree. Every aspect is a node in the tree

characterized by an identifier and condition that

represents a value of a context parameter.

-Repository Context: is supplied and updated by the

context manager, the repository stores the context

parameters related to the client and to the

opportunity of cooperation.

6 CONCLUSIONS

In the previous sections, an approach is proposed to

develop service-oriented systems that can be adapted

to different contexts that deal with the effects of both

major and minor. An adaptable-oriented service life

cycle methodology is used to address and describe

its phases. In particular, it discussed when a change

in a service is triggered, how to analyze its impact

and what are the possible implications of the

implementation of the change for the service

provider and consumers. A formal model for minor

and majoradaptation,on the basis of the one, is the

main goal of our future work.

REFERENCES

M.lethrech, I.Elmagrouni, A.Kenzi, M.Nassar and

A.Kriouile“DSL and SOA, Exploratory Study”

JDTIC, 2012.

H. Hafiddi, H. Baidouri, M. Nassar and A. Kriouile“A

Model Driven Approach for Context-Aware Services

Development”, in the 2nd International Conference on

Multimedia Computing and Systems

(ICMCSmodel'11), Ouarzazate, Morocco, April 2011.

S.Lane,I.Richardson, A Process reference model

developing adaptable service-based applications:

information and software Technology (2011).

M. Shahrbanoo, M. Ali, and M. Mehran, “An Approach

for Agile SOA Development Using Agile Principals,”

arXiv preprint arXiv:1204.0368, 2012.

S.consortium,S-Cube knowledge model, 2011,

http://www.s-cube-network.eu/km>.URL<http:/ /http:/

/www.s-cube-network.eu/km>

K. Boukadi, L. Vincent, P. Burlat, Modeling adaptable

business service for enterprise collaboration, Springer,

Thessaloniki, Greece, 2009, pp. 51–60.

A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S.

Ganapathy, K.Holley, SOMA: a method for

developing service-oriented solutions, IBM Systems

Journal, 47 (2008) 377–396.

M.P. Papazoglou,W.V.D. Heuvel, Service-oriented design

and development methodology, International Journal

of Web Engineering and Technology, 2 (2006) 412–

442.

A. Kenzi, B. El Asri, M. Nassar, A. Kriouile, A model

driven framework for multiview service oriented

system development, IEEE Computer Society, 2009,

pp. 404–411.

S.K. Johnson, A.W. Brown, A model-driven development

approach to creating service-oriented solutions,

Springer, 2006, pp. 624–636.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

230

C. Canal, J.M. Murillo Software adaptation 12 (1) (2006).

I. Christou, S. Ponis, E. Palaiologou, Experiences of Using

the Agile Unified Process in the Banking Sector,

Software, IEEE PP (2009) 1–1.

A. Kenzi, B. El Asri, M. Nassar, A. Kriouile, A mdel

driven framework for multiview service oriented

system development, in: IEEE Computer Society,

2009.

C.Pahl, Semantic model-driven architecting of service-

based software systems, Information and Software

Technology, 49(2007) 838-850.

S. Mittal, Devs unified process for integrated development

and testing of soa, University of Arizona 2007.

C. SooHo, A systematic analysis and design approach to.

develop adaptable services in service oriented

computing, in: Congress on Services (Services 2007),

pp. 375–378.

Her, J., La, H., Kim, S.: A Formal Approach to Devising

a Practical Method for ModelingReusable Services. In:

Proc. of 2008 IEEE Int’l. Conf. on e-Business

Engineering.

(ICEBE 2008), pp. 221–228 (2008).

S. Consortium, State of the art report on software

engineering design knowledge and survey of HCI and

contextual knowledge, Tech. Rep. PO-JRA- 1.1.1,

July 2008.

Erl, T.: Service-Oriented Architecture: Concepts. Prentice-

Hall, Englewood Cliffs (2005).

Cappiello C, Pernici B (2009) Design of repairable

processes. In: Cardoso J, van der Aalst W (eds)

Handbook of Research on Business Process,

Information Science Publishing.

Bucchiarone A, Cappiello C, Di Nitto E, Kazhamiakin R,

Mazza V, Pistore M (2009) Design for Adaptation of

Service-Based Applications: Main Issues and

Requirements. In: Proc. of Fifth International

Workshop on Engineering Service-Oriented

Applications: Supporting Software Service

Development Lifecycles (WESOA).

Adaptation Services-oriented Systems LifeCycle

231