MODELING ARCHITECTURAL LEVEL REPAIR IN WEB

SERVICES

Francisco Moo-Mena

1,2

and Khalil Drira

Laboratoire d’Analyse et d’Architecture des Syst

emes, 7 Av. du Colonel Roche, 31077 Toulouse, Cedex 04, France

Facultad de Matem

aticas, Universidad Aut

onoma de Yucat

an, Apartado Postal 172 Cordemex, 97110 M

erida, M

exico

Keywords:

Architecture model, Architecture reconﬁguration, Web services, repair actions, UML.

Abstract:

Failures during Web service execution may depend on a wide variety of causes, such as network faults, server

crashes, or application-related errors, such as unavailability of a requested Web service, errors in the orches-

tration or choreography of applications, missing data or parameters in an execution ﬂow, or low Quality of

Service (QoS). Providing efﬁcient solutions requires handling adaptability not only at the behavioral level, but

also at the architectural level. Most of existing standard solutions focus on the behavioral level using reconﬁg-

uration mechanisms. In this paper, we propose a model-based approach providing adaptability actions at the

architectural level. Typical architectural reconﬁguration actions, such as duplication of services or substitution

of a non conforming service are introduced. An example is illustrated and discussed with respect to a running

example involving coordinated Web services.

This work has been funded by the IST WS-DIAMOND European project.

1 INTRODUCTION

In the WS-DIAMOND (Web service DIAgnosabil-

ity, MONitoring, and Diagnosis) project (IST, 2006),

methodologies and solutions are investigated to de-

sign and deploy self-healing Web Services. Namely,

Web services able to detect and repair anomalous

situations in the execution of distributed Web based

applications. WS-DIAMOND studies and develops

methodologies and solutions for the creation of self-

healing Web Services, able to detect anomalous situa-

tions, which may manifest as the inability to provide a

service or to fulﬁll Quality of Service (QoS) require-

ments, and to recover from these situations. To re-

cover from these situations, various actions can be un-

dertaken, depending on where the fault has occurred.

In many cases, such actions lead to rearrangement or

reconﬁguration of the architecture.

According to (Dashofy et al., 2002), the ability to

dynamically repair a system at runtime based on its

architecture requires several capabilities: (i) the abil-

ity to describe the current architecture of the system,

(ii) the ability to express all changes to the architec-

ture that will serve as a repair plan, (iii) the ability to

analyze the result of the repair to gain conﬁdence that

the change is valid, and (iv) the ability to execute the

repair plan on a running system without restarting the

system.

Following a model-based development approach,

application scenarios are expressed at a conceptual

level, for example, by adapting UML diagrams. This

representation allows to reason about requirements

at a high level of abstraction, without considering

implementation-speciﬁc details. A conceptual model

of the architecture would allow an understanding of

the basic mechanisms, and their suitability for a cer-

tain task, at a non-technical level (Baresi et al., 2003).

The goal of this paper is to present actions for re-

conﬁguration of QoS mismatches, and to propose a

model-based strategy to management and reconﬁgu-

ration of non conforming Web services applications.

The approach here proposed is based on reconﬁgura-

tion actions deﬁned for different types of mismatches.

The QoS mismatches we deal with are at the architec-

tural level, so they involve reconﬁgurations actions,

such as addition and removal of services and connec-

240

Moo-Mena F. and Dr ira K. (2007).

MODELING ARCHITECTURAL LEVEL REPAIR IN WEB SERVICES.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 240-245

DOI: 10.5220/0001280002400245

 SciTePress

tions. In particular, we focus on mechanisms based

on adaptivity achieved through service duplication or

substitution. This model-based approach involves an

explicit partitioning between functional architectural

issues. In this sense, our ﬁrst task involves represen-

tation of functional (applicative) aspects of architec-

tures by describing a structural speciﬁcation (across

UML extensions) encompassing the functional de-

composition of a Web service application. And sec-

ondly, reconﬁguration management is considered by

applying a set of transformation rules (as deﬁned by

graph rewriting theory) in order to deﬁne reconﬁgu-

ration actions at the architectural level. In order to

facilitate the understanding of our proposal we apply

our idea to the context of a Cooperative Review appli-

cation.

The rest of the paper is organized as follows: sec-

tion 2 introduces our proposal. Section 3 depicts an

applicative sample of our approach. Section 4 de-

scribes research related to our work. And Section 5

presents conclusions and perspective of this work.

2 OUR APPROACH

2.1 Architectural Description

A ﬁrst step consists in modeling of architectures rep-

resenting a Web service application. For this, some

model types are deﬁned as follows:

• The Cooperative role represents a logical deploy-

ment unit associated to sites wherein participating

actors are connected. It may be that a Cooperative

role is identiﬁed in practice with a particular run-

time entity (i.e. Web service application server,

orchestration engine, etc.) but no correlation ex-

ists between Cooperative role and runtime entity

in general, so a Cooperative role can either cor-

respond to several runtime entities or a runtime

unit can match the services associated with sev-

eral Cooperative roles. The concept of Coopera-

tive role fulﬁlls inherent needs in any Web service

application by distinguishing logical distribution

of sites hosting Web services. Speciﬁc Coopera-

tive role examples would be: “Author Site”, “Sup-

plier Site”, “TrackChair Site”, etc.

• The Service category represents a global and

common functionality offered by a set of Web ser-

vices distinguished by their class. Web services

belonging to the same Service category can be de-

ployed on one or more Cooperative roles. We

distinguish, for example, Service categories such

as “Travel Agency Management”, “Food Shop-

ping Management”, “Cooperative Review Man-

agement”, etc.

• The Service class refers to the functional behav-

ior offered by a particular type of Web service as a

basic logical unit associated to a Service category.

In a deployment scenario, a Service class repre-

sents a speciﬁc part of the business logic offered

by a Service category deployed into a Coopera-

tive role. For the sake of simplicity we consider

a unique Service class, of the same category, be-

ing deployed into the set of Cooperative roles. We

distinguish, for example, Service classes such as

“Booking Manager”, “Costumer Manager”, “Re-

viewing Manager”, etc.

A graphical notation is deﬁned in order to repre-

sent static architectural speciﬁcation of a Web service

application. This notation is based on issues deﬁned

by the UML deployment diagram (OMG, 2005) and

extends it as shown in ﬁgure 1. This metamodel de-

ﬁne each of the architectural types as extensions of the

Node metaclass. A relation of aggregation exists be-

tween the Cooperative role and the Service category

since the latter may be deployed on different Coop-

erative roles. As well, a relation of composition is

enabled between the Service category and the Service

class meaning the latter may only be deployed on a

unique Service category. Services (or Web services)

are deﬁned (besides of the architectural types) by ex-

tending the Component metaclass.

Figure 1: Metamodel extending UML deployment view.

According to the proposed metamodel, the notions

of Cooperative Role, Service Category and Service

class are all represented by a Node symbol. A tag al-

lows to distinguish each element by its name. Depen-

dencies between these architectural elements are im-

plicitly represented by embedding each element into

its counterpart. As well, we use Communication paths

in order to represent interconnection at the Service

class level. Services and speciﬁc interactions between

MODELING ARCHITECTURAL LEVEL REPAIR IN WEB SERVICES

241

them are based on component metaclass as deﬁned by

UML 2 (OMG, 2005). Each service is represented by

a component design, in addition to some tags remem-

bering dependencies with regard to the architectural

elements (Cooperative role, Service category and Ser-

vice class).

2.2 Basic Rule Deﬁnition

This step consists in the deﬁnition of dynamic archi-

tectures in order to represent reconﬁguration actions.

To make it possible we deﬁne some basic rules based

on graph transformation. Deﬁnition of rules is merely

based on the basic model types. Namely, each rule

must involve either a Cooperative role, Service cate-

gory, Service class or a mixture of them into its spec-

iﬁcation. This strategy aims to provide some impor-

tant advantages such as: (i) deﬁnition of simpler and

generic rules, (ii) deﬁnition of more powerful rules,

as a single model type (Cooperative role, Service cat-

egory or Service class) generally involves multiple in-

stances of Web services.

In order to build basic rules we deﬁne a sim-

ple graph, where vertices represent Web services and

edges represent connections between Web services.

Each vertex of the graph is deﬁned by:

W S

(i,j,k,l)

where :

i represents a Cooperative role,

j represents a Service category,

k represents a Service class, and

l represents the identiﬁer of the WS.

In what follow we depict three basic rules which

involve some typical actions required to build recon-

ﬁguration actions. In these rules, variables X,Y and

Z match graph vertices, where each vertex represents

one or more instances of Web services. These basic

rules are deﬁned as follows:

• Rule R1 deals with addition of Web services. In

practice that means activation or deployment of

Web services instances.

• Rule R2 deals with addition of connections. A re-

striction is imposed as the connections between a

pair of elements must remain unique, so this rule

is only applicable if declared edges have no been

created previously, and

• Rule R3 deals with removal of elements and asso-

ciated connections. In practice removal could be

interpreted as deactivation of implied elements. It

must be noted due to parameters are associated to

model types each variable would instantiate sev-

eral elements (Web services instances and connec-

tions).

Based on this principles, for instance, a ba-

sic rule describing something like: “add Web ser-

vices with Service category = AuthorManagement”,

would be carried out by applying the Rule R1 with

X = W S

(i=∗,j=AuthorM anagement,k=∗,l=∗)

, where

“*” matches any value in all cases. That involves all

elements relied on this Service category, namely, the

Service classes and services.

2.3 Reconﬁguration Actions

In order to model reconﬁguration actions for a non

conforming Web service application, we use the ba-

sic rules aforementioned and deﬁne policies for their

right application. Namely, we establish an ordered

sequence of basic rules to enable architectural recon-

ﬁguration actions such as duplication or substitution

of Web services.

• Duplication(or replication) involves addition of

services representing similar functionalities. This

aiming at improving load balancing between ser-

vices in order to better adapt, for instance, to QoS

requirements.

• Substitution encompasses redirection between

two services. Applying this action means the ﬁrst

one is deactivated and relieved by the second one.

Hence, the Duplication and Substitution reconﬁg-

uration actions are deﬁned as follows:

Duplication = R

Substitution = R

That means reconﬁguration action of Duplication

implies the application sequence of Rule R1 and Rule

R2. And reconﬁguration action of Substitution im-

plies the application sequence of Rule R1, Rule R2

and Rule R3.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

242

3 ILLUSTRATION

This example illustrates the functioning of a common

collaborative activity addressing the problem of “re-

view process”. This problem has several instantia-

tions in different activity areas. In industrial activ-

ities such as engineering of complex and embedded

systems, the “design review” activity is known to be

as one of the most complex activities in aerospace

industry. The “cooperative review” application sce-

nario we study in the context of the WS-DIAMOND

project aims to support such activities. Most of the

deﬁned services, parameters, actors and processes

are generic and may be applied to different domain-

speciﬁc review processes. In order to facilitate the un-

derstanding and the collaboration within our project,

we choose to instantiate the review process by the

well-known scenario of the review process in scien-

tiﬁc publishing activities. Namely, we consider the

speciﬁc case of the scientiﬁc conferences looking for

describing the automatic functioning of their different

steps within a service-oriented approach.

Several actors collaborate in order to accomplish

the various management tasks of the cooperative re-

viewing process. The different types of actors are

presented as follows: (i) the Conference Chair repre-

sents the principal actor in charge of organization of

the conference. (ii) The Track Chair has in charge to

manage a particular conference’s session, (iii) the Au-

thor represents each potential contributor to the dif-

ferent topics of the conference, (iv) the Reviewer is

an expert in one or more of the domains deﬁned by

the different topics of the conference.

3.1 Architecture Description

For this example an architectural description is de-

picted in ﬁgure 2. This description involves:

• 4 Cooperative Roles: (i) AuthorSite considers par-

ticipant site for authors, (ii) ConfChairSite con-

siders participant site for conference Chairs, (iii)

TrackChairSite considers participant site for track

Chairs, (iv) ReviewerSite considers participant

site for reviewers.

• 3 Services Categories: (i) AuthorMgmt deals with

general functionality management regarding au-

thors, (ii) ConfMgmt deals with general func-

tionality management regarding conferences, (iii)

ReviewerMgmt deals with general functionality

management regarding reviewers.

• 7 Services Classes: (i) AuthorMgr deﬁnes spe-

ciﬁc functionality concerning authors, (ii) Con-

fInfoProv deﬁnes speciﬁc functionality concern-

ing information providing of conferences, (iii) Ap-

provalMgr deﬁnes speciﬁc functionality concern-

ing approval process of publications, (iv) Publish-

ingMgr deﬁnes speciﬁc functionality concerning

publishing management of proceedings, (v) Sub-

misMgr deﬁnes speciﬁc functionality concerning

submission management of papers, (vi) Review-

ingMgr deﬁnes speciﬁc functionality concerning

reviewing management of papers, (vii) Reviewer-

Mgr deﬁnes speciﬁc functionality concerning re-

viewers.

Figure 2: Architecture of the Cooperative Review applica-

tion.

Several interactions, structured into activities, be-

tween Web services would be enabled on this appli-

cation. Some typical examples of these activities are:

(i) Conference Search Activity, (ii) Reviewers Search

Activity, (iii) Report Transmission, (iv) Author Noti-

ﬁcation, etc.

3.2 Application of Reconﬁg. Actions

In order to better illustrate effects due to application

of reconﬁguration action we use a Left-Right style

(namely, each reconﬁguration action is composed by

a left side and a right side). In the left side, we de-

scribe architectural elements (services and connec-

tions) as necessary to apply the rules. In the right

side, we describe architectural elements, as wished af-

ter application of the rules. In practice, architectural

changes yielded by passing from a state to another are

carried out by a set of atomic actions (like activation,

binding or deactivation of Web services and connec-

tions).

A ﬁrst example illustrating reconﬁguration actions

for the Cooperative Review application considers du-

plication of Web services. In fact, many reasons

would be behind decision for applying this action,

for instance, QoS mismatches as overhead, load bal-

ancing, low throughput, etc. As depicted in ﬁgure 3

it is possible that in any time many AuthorMgrServ

services try to address a same instance of ConfInfo-

ProvServ service, so it is pertinent to improve perfor-

mance by deploying new instances of the latter ser-

MODELING ARCHITECTURAL LEVEL REPAIR IN WEB SERVICES

243

vice. Hence, the duplication action is applied as de-

scribed in section 2.3 (R

For all Web services instances deﬁned by vari-

ables X, Y, and Z; apply rules R1 and R2 with the

following parameters.

Rule X() Y() Z()

i=ConfChairSite i’=ConfChairSite

R1 j=ConfMgmt j’=ConfMgmt

k=ConfInfoProv k’=ConfInfoProv

l=* l’=new

i=ConfChairSite i’=ConfChairSite i”=*

R2 j=ConfMgmt j’=ConfMgmt j”=*

k=ConfInfoProv k’=ConfInfoProv k”=*

l’!=new l’=new l”=*

Figure 3: Applying duplication action.

A second example depicting reconﬁguration ac-

tions for the Cooperative Review system deals with

application of the substitution action. Recurrent QoS

mismatches as Web services delivering a wrong ser-

vice, low throughput, or yet denial of service, would

carry the reconﬁguration module to apply this kind of

reconﬁguration action. As depicted in ﬁgure 4 it is

possible that the group of Web services related to the

same Service category get in any time a non conform-

ing state, so a pertinent and efﬁcient way of repair-

ing this matters is by substituting all the Web services

concerned with this Service category (ConfMgmt). It

must be clear interactions between services involved

at the moment of applying the reconﬁguration action,

must be taken into account in order to restore them

with the new instances of involved services. In this

example, this is the case between the AuthorMgrServ

service and the ConfInfoProvServ service, when ap-

plying the action of substitution as deﬁned in section

2.3 (R

). Many other scenarios would be illus-

trated by assigning different values of variables con-

cerning each architectural type.

For all Web services instances deﬁned by vari-

ables X, Y, and Z; apply rules R1,R2, and R3 with

the following parameters.

Rule X() Y() Z()

R1 j=ConfMgmt j’=ConfMgmt

l’=new

j=ConfMgmt j’=ConfMgmt i”=*

R2 j”=*

k”=*

l’!=new l’=new l”=*

R3 j=ConfMgmt

l’!=new

Figure 4: Applying substitution action.

4 RELATED WORK

Many research efforts contribute to the topic consid-

ered by this work. Regarding Architecture Descrip-

tion Language (ADL) as a support for achieving self-

adaptive or self-conﬁguration software, (Georgiadis

et al., 2002) proposed the use of architectural con-

straints as the basis for self-organising architectures in

distributed systems. In this proposal structural speci-

ﬁcation of architectures is carry out through the Dar-

win ADL (J. Magee, N. Dulay, S. Eisenbach and J.

Kramer, 1995). (Garlan and Schmerl, 2002) depict

an approach for self-adaptation of architectures based

on the ACME ADL (Garlan et al., 2000). The CHAM

ADL (Inverardi and Wolf, 1995) offers an approach in

terms of molecules and reactions, where components

are represented as atoms connected into molecules.

Reconﬁgurations are speciﬁed as reactions. Provided

with an appropriate set of reaction rules, it is possible

to determine whether a certain reconﬁguration is valid

or not.

(Le Metayer, 1998) adopted graph grammar for

modeling of software architectures and associated re-

conﬁguration. With this formalism, he expresses ar-

chitectural styles and reasons about conformance of

change or evolution with respect to structural con-

straints.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

244

Regarding frameworks for supporting self-healing

systems, (Wile and Egyed, 2004) propose a frame-

work for self-healing systems through monitoring, in-

terpretation, analyzing and reconﬁguration of running

systems. (Gurguis and Zeid, 2005) propose a solution

based on an architecture encompassing a Monitor, an

Analyzer, a Planner and an Executive.(Shin, 2005)

proposes a strategy for self-healing components in

distributed systems based on an architecture with two

layers. The services layer provides functional ser-

vices to the other components, whilst the self-healing

layer implements mechanisms for monitoring and re-

pairing.

In the particular case of reconﬁguration in Web

services, (Baresi et al., 2003) propose a model for

a SOA style. Architectures are speciﬁed by adapt-

ing UML diagrams and reconﬁguration is achieved

through reconﬁguration rules. An important differ-

ence with our work is that their model, for represent-

ing architectures, is more based on behavioral ele-

ments of service-oriented architectures.

The goals in the WS-DIAMOND go beyond these

approaches, namely a dynamic reconﬁguration of

Web service architectures whenever some QoS mis-

matches occur, considering both functional and non

functional features of Web services.

5 CONCLUSION

The architectural aspects aforementioned may be

translated and implemented by using the architec-

tural tools being developed at LAAS-CNRS. In con-

crete, the architectural description, as well as, the ba-

sic rules are described by XML ﬁles deﬁned across

XML Schemas. Initial speciﬁcation and reconﬁgura-

tion actions could be mapped into graphs and graph

transformation actions, respectively. The main idea is

to use a graph transformation engine in order to man-

age dynamic changes in the Web services application

whenever a reconﬁguration action is triggered.

The approach herein described enables modeling

of dynamic reconﬁguration of Web services at the

architectural level. Following the goals of the WS-

DIAMOND project we consider its integration to the

monitoring, diagnosis and repair mechanisms being

developed, in order to satisfy requirements of a global

self-healing solution (Koopman, 2003). An extended

version of the Cooperative Review example might in-

troduce other interacting scenarios by handling addi-

tional architectural elements.

REFERENCES

Baresi, L., Heckel, R., Th

one, S., and Varr

o, D. (2003).

Modeling and validation of service-oriented architec-

tures: application vs. style. In ESEC / SIGSOFT FSE,

pages 68–77.

Dashofy, E. M., van der Hoek, A., and Taylor, R. N. (2002).

Towards architecture-based self-healing systems. In

WOSS, pages 21–26.

Garlan, D., Monroe, R., and Wile, D. (2000). Acme: Ar-

chitectural description of component-based systems.

In Foundations of Component-Based Systems. Leav-

ens, G.T., and Sitaraman, M.(eds), pages 47–68. Cam-

bridge University Press.

Garlan, D. and Schmerl, B. (2002). Model-based adaptation

for self-healing systems. In WOSS ’02: Proceedings

of the ﬁrst workshop on Self-healing systems, pages

27–32, New York, NY, USA. ACM Press.

Georgiadis, I., Magee, J., and Kramer, J. (2002). Self-

organising software architectures for distributed sys-

tems. In WOSS ’02: Proceedings of the ﬁrst workshop

on Self-healing systems, pages 33–38, New York, NY,

USA. ACM Press.

Gurguis, S. A. and Zeid, A. (2005). Towards autonomic web

services: achieving self-healing using web services. In

DEAS ’05: Proceedings of the 2005 workshop on De-

sign and evolution of autonomic application software,

pages 1–5, NY, USA. ACM Press.

Inverardi, P. and Wolf, A. (1995). Formal speciﬁcation and

analysis of software architectures using the chemical

abstract machine. In IEEE Transactions on Software

Engineering, 21(4):373–386.

IST (2006). The web services diagnosability, monitoring

and diagnostic project. http://wsdiamond.di.unito.it.

J. Magee, N. Dulay, S. Eisenbach and J. Kramer (1995).

Specifying distributed software architectures. In Pro-

ceeding of the 5th European Software Engineering

Conference, ESEC ’95.

Koopman, P. (2003). Elements of the self-healing system

problem space. In Proceeding of the Workshop on

Software Architectures for Dependable Systems.

Le Metayer, D. (1998). Describing software architecture

styles using graph grammars. In IEEE Transactions

on Software Engineering, 24(7):521–533.

OMG (2005). Uniﬁed modeling language speciﬁ-

cation. Technical Report Infrastructure Version

2.0.formal/05-07-04, Object Management Group.

Shin, M. E. (2005). Self-healing components in robust soft-

ware architecture for concurrent and distributed sys-

tems. Sci. Comput. Program., 57(1):27–44.

Wile, D. S. and Egyed, A. (2004). An externalized infras-

tructure for self-healing systems. In Proceedings of

the Fourth Working IEEE/IFIP Conference on Soft-

ware Architecture. IEEE Computer Society.

MODELING ARCHITECTURAL LEVEL REPAIR IN WEB SERVICES

245