DIAPASON: A FORMAL APPROACH FOR SUPPORTING AGILE

AND EVOLVABLE INFORMATION SYSTEM SERVICE-BASED

ARCHITECTURES

Herv

e Verjus and Fr

eric Pourraz

University of Savoie - Polytech’Savoie

LISTIC-LS - Language and Software Evolution Group

BP 80439, 74344 Annecy-le-Vieux Cedex, France

Keywords:

Information system architecture, SOA, Services orchestration, BPM, Dynamic evolution, π-calculus.

Abstract:

This paper presents a novel approach called Diapason, for expressing, verifying and deploying evolvable

information system service-based architectures. Diapason promotes a π-calculus-based layered language and

a corresponding virtual machine for expressing and executing dynamic and evolvable services orchestration

that support agile business processes. Information system service-based architecture may dynamically evolve,

whatever the changes may occur during the services orchestration lifecycle.

1 INTRODUCTION

Service-Oriented Architectures (SOA) is a recent

paradigm for building large scale information sys-

tem service-oriented architectures (IS-SOA) from dis-

tributed services. One of the main interest of SOA

is basically the underlying ability of such architec-

ture to inherently being evolvable; because the un-

derlying idea of SOA is that the services are loosely

coupled and the SOA could be adapted to its envi-

ronment. Services are supposed to be autonomous,

self-contained, and we do not control nor we have

authority over them. When considering information

system perspective, the openess, ﬂexibility, agility of

such information system service-oriented architecture

is very challenging for addressing new functionalities,

time to market, etc. SOAs introduce new engineering

issues (Fitzerald and Olsson, 2006; Papazoglou et al.,

2006) and SOA evolution is becoming very challeng-

ing (Papazoglou et al., 2006). Thus, important engi-

neering questions are addressed to service-based in-

formation system architects: what about the quality

of IS-SOA ? How can we ensure that IS-SOA ﬁt ex-

pectations ? How are IS-SOAs able to be dynamically

adapted ? How can we ensure that the executed IS-

SOA is consistent with the design ?

We present in this paper our formal language called

π-Diapason that lets the user/architect to formally ex-

press and control dynamic evolvable web services or-

chestrations. From service-oriented information sys-

tem engineering perspective, service orchestration is

a key issue as it supports (at least partially) business

processes.

The section 2 of this paper will present works and

challenges related to SOA engineering. Section 3 will

present our formal language, called π-Diapason, for

designing evolvable IS-SOAs and section 4 will then

conclude.

2 RELATED WORK AND

CHALLENGES

Services orchestration addresses business process

through services invocations scheduling and organi-

sation. Services orchestration aims at deﬁning ex-

ecutable processes by providing orchestration lan-

guages (among the most well known BPEL, XLANG,

WSFL, etc. (Peltz, 2003)) that are executable lan-

guages (by the way of workﬂow engines). BPEL

allows to deﬁne abstract business processes and ex-

ecutable processes. But such languages lack in ser-

vices orchestration reasoning, reuse, dynamic evolu-

tion (Papazoglou et al., 2006; Ravn et al., 2006): i.e.

business processes expressed using these languages

cannot be formally checked, nor they can evolve dy-

namically.

Verjus H. and Pourraz F. (2008).

DIAPASON: A FORMAL APPROACH FOR SUPPORTING AGILE AND EVOLVABLE INFORMATION SYSTEM SERVICE-BASED ARCHITECTURES.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 76-81

DOI: 10.5220/0001677000760081

 SciTePress

During the part three years, some works (Sala

un et al.,

2004; Fu et al., 2004; Foster et al., 2006; Solanki

et al., 2006; Chirichiello and Sala

un, 2005) have been

devoted to employ formal approaches for services

orchestration deﬁnition and analysis. These works

mainly consider BPEL as the core language for ex-

pressing service orchestration. Thus, authors propose

mappings approaches between formal languages and

BPEL. As these languages are not expressive equiv-

alent, mappings/transformation produce gap and dis-

crepencies and analysis cannot be exhaustive enough.

Our approch we will introduce hereafter, deals si-

multaneously with two important considerations that

other approches do not: (i) we propose a new formal

and executable language (named π-Diapason) for or-

chestrating services avoiding mappings and transfor-

mations from or to BPEL; (ii) π-Diapason is based

on the π-calculus that is the most expressive process

algebra (complete in sense of the Turing machine).

As consequence, π-Diapason is more powerful than

BPEL, π-Diapason is executable, π-Diapason sup-

ports evolvable services orchestration formalization

that can be analyzed and executed.

3 EVOLVABLE IS-SOAS

FORMALIZATION

3.1 π-Diapason Formal Foundations

Diapason (Pourraz and Verjus, 2007) is a π-calculus

based approach allowing formal services based sys-

tems modeling, deployment and execution. The aim

of using a process algebra (which formally models in-

teractions between processes (Sala

un et al., 2004)) as

a fundament is to provide a mathematical model in

order to guarantee the software conformance with the

end-user’s requirements. In other words, thanks to a

mathematical description, a services based system de-

scription can be proven. Different process algebras

have been provided, for example CSP (Hoare, 1985),

CCS (Milner, 1989), π-calculus (Milner, 1999), etc.

In our case, we have adopted the π-calculus due to

its main feature: the process mobility. This concept

allows us to dynamically evolve application’s topol-

ogy by the way of processes exchanges. In the case of

services orchestration, processes (i.e. orchestrations)

is formally deﬁned in π-calculus terms of behaviours

and channels. A channel aims at connecting two be-

haviours and lets them interacting together. The ﬁrst

order π-calculus has a restricted policy according to

the type of informations which can be transited over a

channel. Only simple data or channel can be transmit-

ted but in never way a behaviour. Transiting a channel

reference over another channel provides a way, for a

process A, which has got a channel with a process B

and another channel with a process C, to send, for ex-

ample to B, its channel with C. Finally, the processes

B and C which are not able to communicate as far

for now, can now communicate with a common chan-

nel. This his the ﬁrst kind of mobility. In our case, π-

Diapason is based on the high order π-calculus which

is more powerful. In addition to the ﬁrst kind of mo-

bility, hight order π-calculus let channels to exchange

channels as well as behaviours. This brings a more

powerful mobility. In this way, a behaviour can send

(via a channel) a behaviour to another behaviour. The

transmitted behaviour could be executed by the be-

haviour’s receiver. Thus, this latter may be dynami-

cally inherently modiﬁed by the behaviour it just has

received.

π-Diapason aims at proposing well deﬁned formal ab-

stractions for expressing services orchestration that

can be then executed (because π-Diapason is an ex-

ecutable formal language); π-Diapason:

• allows the IS-SOA architect to design and specify

IS-SOAs (focusing on services orchestration);

• provides Domain Speciﬁc Layer (see below) in or-

der to simplify IS-SOA design;

• is formally deﬁned, based on π-calculus;

• supports dynamic IS-SOA evolution (focusing on

services orchestration dynamic evolution);

• it is executable: it is powerful and expressive

enough that a virtual machine can interprete it.

Thus, there is no gap between the design (abstract

level) and the corresponding implementation (con-

crete level) as it is the same language that covers both

levels. There is no mapping rules, and no need for

consistency management. The IS-SOA speciﬁed will

be the one that will be interpreted. IS-SOA’s execu-

tion is precisely carried out by the π-Diapason virtual

machine; this latter can be used for IS-SOA simula-

tion and validation purpose and is the runtime engine

that interpretes services orchestration expressed in π-

Diapason.

3.2 π-calculus Basis

Thanks to the π-calculus (Milner, 1989), some opera-

tors are required (we deﬁned naming conventions: up-

per case letters stand for processes while lower case

letters stand for variables):

• µ.P: the preﬁx of a process by an action where µ

can be :

DIAPASON: A FORMAL APPROACH FOR SUPPORTING AGILE AND EVOLVABLE INFORMATION SYSTEM

SERVICE-BASED ARCHITECTURES

– x(y): a positive preﬁx, which means the receiv-

ing event of the variable y on the channel x,

– ¯xy: a negative preﬁx, which means the sending

event of the variable y on the channel x,

– τ: a silent preﬁx, which means an unobservable

action,

• P|Q: the parallelisation of two processes,

• P + Q: the indeterministic choice between two

processes,

• [x = y]P: the matching expression,

• A(x1, ..., xn)

de f

= P: the process deﬁnition which

allows to express the recursion.

Starting for the 0 process (i.e. the inactive process),

the deﬁnition of a P process can be expressed as

follows:

de f

= 0 — x(y).P — ¯xy.P — τ.P — P1—P2 — P1+P2

— [x = y]P — A (x1, ..., xn)

π-Diapason has been designed as a layered lan-

guage which provides three abstraction levels. The

π-Diapason formal deﬁnition and implementation are

given in (Pourraz and Verjus, 2007).

Figure 1: π-Diapason as a layered language.

3.3 The First Layer

The π-Diapason ﬁrst layer is the expression of the

high order, typed, asynchronous and polyadic π-

calculus (Milner, 1999):

• polyadic for simultaneously sending several val-

ues on a same channel (i.e. in order to invoke a

service with some parameters),

• asynchonous; thus a process that sends a value on

a channel is not blocked event if the receiver is not

ready to proceed the receiving action,

• typed for allowing typed value declaration. Thus,

type checking is then possible,

• high order for allowing to pass connections and

processes on channels that stands for mobility

(we will employ π-calculus mobility as concep-

tual means for evolvable services orchestration).

The π-Diapason virtual machine supports this

ﬁrst layer. The π-Diapason ﬁrst layer non-symbolic

syntax is a XSB (Sagonas et al., 2006) Prolog-based

syntax. Given the naming conventions: a process’s

name begins with a lower case letter while variable’s

name begins either with an underscore character “ ”,

either with a upper case letter, this ﬁrst layer syntax

deﬁnition is as follows:

0 ≡ terminate

P ≡ apply(p)

P.Q ≡ sequence(apply(p), apply(q))

x(y) ≡ receive(X, Y)

¯xy ≡ send(X, Y)

τ ≡ unobservable

P — Q ≡ parallel split([apply(p), apply(q)])

P + Q ≡ deferedChoice([apply(p), apply(q)])

[x = y] P ≡ if then(C, apply(p))

or if then else(C, apply(p), apply(q))

Process Deﬁnition and Application. A process can

be deﬁned and applied in two different ways.

• the ﬁrst one consists in creating an anonymous

process that is applied only once (and cannot be

reused). Such process is called as behaviour and

is declared and applied as follows:

ap p ly ( b eh av io ur (... ) ).

• the second way consists in ﬁrst deﬁning a named

process that can be possibly applied several times

in a given services orchestration. Such process is

called as process and its deﬁnition and application

are as follows:

pr oce ss ( pro ce ss _n a m e ( _ pa r am ete r1 , _ pa r am e te r2 , . ..) ,

be ha vi o ur (.. .) )

...

ap p ly ( p r o c e ss _n am e ( _v a lue 1 , _valu e2 , .. .) )

Inter-process Communication Channels can be

deﬁned as connections. A connection is named. We

may send a value on a connection connection name.

sen d ( co nn ec ti on ( ’ c o nn ec t io n_ nam e ’) , _va l ue )

Values and Variables. Values are literals (integers,

ﬂoats, booleans, strings). Variables are named (with a

ﬁrst character that is either the underscore character,

either a upper case letter). A variable’s value can be

either a literal, either a connection or a process.

ICEIS 2008 - International Conference on Enterprise Information Systems

Collections. A collection is either a list, either an

array. A list is sorted collection that contains values

that may of different types while an array only con-

tains same type values.

lis t ([ _ valu e1 , _va lue2 , ...] )

ar r ay ( [ _va lue1 , _ v alu e 2 , .. .])

We introduced an iterate operator for iterating

over a collection. Iteration consists in executing a be-

haviour at each collection’s element.

it era te ( _ co lle cti on , _ ite rat or , _ be ha vi o ur )

New Types Deﬁnition can be added in the lan-

guage. We do not detail this feature in this paper.

3.4 The Second Layer

The π-Diapason second layer is deﬁned on top of the

ﬁrst layer, using the ﬁrst layer language. This second

abstraction level is the expression of the previously

mentioned workﬂow patterns: it is itself a formal pro-

cess pattern deﬁnition language. The twenty ﬁrst pat-

terns proposed in (van der Aalst et al., 2003) are cur-

rently described in this layer and we will deﬁne some

others soon. This second layer:

• lets us to describe any complex process in an eas-

iest way and at a higher level of abstraction, than

only using the ﬁrst layer (π-calculus deﬁnition

layer that is less intuitive);

• allows the user to deﬁne recurrent structures that

will serve as language extensions and will be

reused in other process pattern deﬁnitions. We

have currently express some patterns in order to

provide a ﬁrst library but, as we mentioned, any

other structure can be described using this layer;

• contains the formal deﬁnition of the services or-

chestration paterns. Thus, future veriﬁcation tasks

could be performed;

• is generic enough to be domain independant and

can be served as basis for domain-speciﬁc lan-

guages deﬁned upon it.

Let us take the example of the synchronization

pattern, called synchronize. This pattern allows to

merge different parallelized processes. Expressed us-

ing the ﬁrst layer, its description is the following:

pa tte rn ( syn ch ro n i z e ( c on ne ct io ns ( _ c o n n ec ti on s ) ) ,

it era te ( _co nne ct i on s ,

it er a to r ( _ co nn e c t io n ) ,

be ha vi o ur (r ec e iv e ( _c on n ec t io n , _ v al ue s ))) ) .

The synchronize pattern takes a list of connections

(i.e channels in π-calculus) as parameters. The length

of the list corresponds to the number of paralleled pro-

cesses. Once applied, this pattern will use the iterate

behaviour provided by the ﬁrst layer. The iterate be-

haviour takes three parameters: a list (on which one

will iterate), the iteration variable and a behaviour

which will be applied for each iteration. Thanks to

the synchronize pattern, the iterate pattern is used as

follows: the list passed as parameter is a list of con-

nections; thus, the iteration variable is a connection

(of the list); the behaviour is deﬁned as a receiving

action attempt on the current connection (the iteration

variable value). When the iterate pattern is terminated

(i.e. all of the connections involved have received any

value), the orchestration process goes on to the next

steps. Thus, this layer contributes signiﬁcantly to the

services orchestration by using formal orchestration

patterns. π-Diapason second layer constitutes a novel

and extensible services orchestration formal language

and is a serious alternative to well known but less ex-

pressive and less extensible orchestration languages

(BPEL, WSFL, etc.).

3.5 The Third Layer

This layer is a domain speciﬁc layer. In our case it

provides to the end user, language for formalizing

web services orchestration (it consists in a Domain

Speciﬁc Language). This third abstraction level is de-

ﬁned by using the two previous layers; thus, an in-

formation system Web service oriented architecture

expressed in this third level language is directly ex-

pressed as a π-calculus process. This layer lets us to

describe:

• the behaviour of a services orchestration,

• the orchestration’s inputs and outputs,

• the complex types manipulated and required in

such services orchestration,

• operations of all of the services involved in the

orchestration.

In order to deﬁne web services orchestrations, we

have to express web services operations involved in

the orchestration. We do not care how services are im-

plemented but we just need operations provided. We

obtain operations’ speciﬁcations by analyzing WSDL

ﬁles that contain all required information, among

them:

• the operation’s name;

• the operation’s parent web service;

• the operation’s invocation URL;

• the operation’s parameters;

• the operation’s return value (optional).

DIAPASON: A FORMAL APPROACH FOR SUPPORTING AGILE AND EVOLVABLE INFORMATION SYSTEM

SERVICE-BASED ARCHITECTURES

Operation concept is deﬁned in terms of types of

the π-Diapason second layer.

typ e ( op e rat ion , l ist ([ ope rat io n_n am e , se r vic e , url ,

req ues t s , r e sp on se ] ) ) .

...

typ e ( op er a ti on _ na me , str i ng ) .

typ e ( ser v ice , s tr ing ) .

typ e ( u rl , s t ri n g ) .

...

We do not explain deeper such operation complete

deﬁnition (request and response are not detailed in

this paper).

Thanks to the communication protocol (SOAP)

employed in Web Service Oriented Architectures,

complex types have to be formalized. Each complex

type formalization includes the complex type name,

its namespace and its constituents (other types). This

formalization is not presented here.

Invoking Operation is formalized as a π-calculus

process called invoke. Such invocation process takes

some parameters: the operation name, a collec-

tion containing the operation arguments and a return

value. In term of π-Diapason ﬁrst layer concepts, such

deﬁnition consists in sending a message on a connec-

tion named request and then, waiting for a message

on a connection named response. The deﬁnition of

the invocation process is given as follow:

pr oce ss ( in vo ke ( o pe ra ti o n ( _ op er at i on ), r eq ue st s_ va lu es (

_r eq ue s ts ), r es po ns e_ va lu e ( _ r es po ns e ) ) ,

se qu e nc e ( se nd ( c on ne c ti on ( ’ re ques t ’) , o pe ra ti on _v al ue (

lis t ([ ope r at io n ( _ op e ra ti on ) , r e q u e s t s _ v a l u e s (

_r eq ue s ts )]) ) ) ,

re cei ve ( con ne c ti on (’ res pon s e ’) , r es po ns e_ va lu e (

_r es po n se ))) ) .

Web Services Orchestration is then deﬁned as a

π-Diapason second layer process. Such process takes

four parameters: the name of the orchestration (re-

member that a named process can be reused as neces-

sary), the orchestration parameters (i.e. a collection),

a return value and a behaviour that orchestrates some

invocation processes. The orchestration process be-

haviour consists in applying the behaviour passed as

parameter. Such deﬁnition implies new types deﬁni-

tion (i.e. parameters, return, etc.) that are not intro-

duced in the paper.

typ e ( or ch es tr a ti on _n a me , s tr ing ) .

pr oce ss ( orc he st ra ti on ( orc he st ra ti on _n a m e ( _ nam e ) ,

pa ra me t e r s ( _ pa ra me te rs ) , r etu rn ( _ re tur n ) ,

be ha vi o ur (_ be ha vi ou r )) ,

ap p ly ( b eh av io ur ( _ be ha vi ou r )) ).

3.6 IS-SOA Dynamic Evolution

Thanks to the π-calculus mobility, we may modify the

services orchestration dynamically, at runtime, with-

out to stop this runtimed orchestration. Inherently,

due to the layered languages we propose, a services

orchestration expressed using the third layer language

is semantically and formally deﬁned as a π-calculus

process (in term of the ﬁrst layer language). Evolving

a services orchestration is quite as the same as evolv-

ing a π-calculus process (Pourraz and Verjus, 2007).

Figure 2: The services orchestration evolution p rocess.

We are now explaining how a services orchestra-

tion formally deﬁned using π-Diapason third layer

is able to evolve dynamically (at runtime). The or-

chestration behaviour (see the orchestration in the left

part of the Figure 2) consists in scheduling the Web

services operations invocations by the way of pro-

cess patterns (sequence, parallel, conditional expres-

sions) deﬁned in the second layer of the π-Diapason

language. In order to perform the external evolu-

tion, an “evolution point” has been deﬁned. A con-

nection called “EVOLVE”, deﬁned in the services

orchestration π-Diapason code, is a connection for

ﬁring and receiving services orchestration changes.

This connection allows us to dynamically pass a be-

haviour to the orchestration (i.e. conform to pro-

cess mobility (Milner, 1999)). Once received (the

evolved behaviour variable is becoming not null),

this changed or new behaviour (see the orchestration

in the right part of the Figure 2) can be applied within

the orchestration (the receiver). Such behaviour ap-

plication modiﬁes dynamically the orchestration ac-

cording to the behaviour’s π-Diapason deﬁnition that

integrates changes. Otherwise, when no behaviour

is received, the orchestration process goes on as it

was planned, without modiﬁcation. The following

piece of code is a services orchestration example that

may receive a new behaviour through the “EVOLVE”

connection and then apply dynamically this new be-

haviour.

...

be ha vi o ur (

pa ra ll el _s pl it ([

// An ex te r na l evo lu ti on may b e r eq ue s te d

re cei ve ( con ne c ti on (’ EVOL V E ’) , v a lu e s ([

_e vo lv ed _ b e h a v i o u r ]) )

// s ome i n vo ca ti on s of se con d laye r pat te rns

...

se qu e nc e ( i f_ th en _e l s e ( _e vo lv ed _b eh av io ur != NUL L ,

// Evo lu ti o n Re qui re d

ICEIS 2008 - International Conference on Enterprise Information Systems

ap p ly ( _ev ol ve d_ be ha vi ou r )

// NO Ev ol u ti on R e qu ir ed

if _t he n_ el se ( // a t est ,

// t h e orc he st ra ti on go e s on wi th o ut

mo di fi ca ti on

...

te rm in a te )) ]) ]) ) ,

...

The π-Diapason expression of the behaviour that

is containing modiﬁcations (for example new orches-

tration process, adding, removing services and/or op-

erations) is dynamically received and applied (see the

bottom part of the ﬁgure 2). It is up to the user to

express and on the ﬂy provide to the π-Diapason vir-

tual machine, the deﬁnition of such behaviour. This

evolution mechanism at π-Diapason code level deals

with unpredicatble situations that may occur at run-

time, without having to suspend or to stop the execu-

tion.

4 CONCLUSIONS

π-Diapason is a formal and layered language for ex-

pressing processes at the second layer level by the

way of patterns (strongly related to business pro-

cesses/workﬂows); the third layer offers a high level

language that allows the user to formalize evolvable

information system service-based architectures (i.e.

service orchestration) without being in touch with π-

calculus. Such approach aims at providing means for

supporting agile business processes and ﬂexible and

open information systems service-based architectures

through service orchestration: services orchestration

may be internally modiﬁed by receiving a new be-

haviour and the current execution may be deeply and

consistently modiﬁed. Our approach is non-intrusive

as the service orchestration is encapsulated in the de-

ployed web service that is the services choreographer

without to modify any other part of the information

system architecture.

ACKNOWLEDGEMENTS

This work is partially funded by the french ANR JC05

42872 COOK Project.

REFERENCES

Chirichiello, A. and Sala

un, G. (2005). Encoding abstract

descriptions into executable web services: Towards a

formal development negotiation among web services

using lotos/cadp. In IEEE/WIC/ACM International

Conference on Web Intelligence (WI 2005).

Fitzerald, B. and Olsson, C., editors (2006). The Soft-

ware and Services Challenge. EY 7th Framework Pro-

gramme, Contribution to the preparation of the Tech-

nology Pillar on ”Software, Grids, Security and De-

pendability”.

Foster, H., Uchitel, S., Magee, J., and Kramer, J. (2006).

Ltsa-ws: A tool for model-based veriﬁcation of web

service compositions and choreography. In IEEE

International Conference on Software Engineering

(ICSE 2006).

Fu, X., Bultan, T., and Su, J. (2004). Analysis of interacting

bpel web services. In Press, A., editor, Proceedings

of the 13th International World Wide Web Conference

(WWW’04), USA.

Hoare, C. (1985). Communicating Sequential Processes.

Prentice Hall International Series in Computer Sci-

ence.

Milner, R. (1989). Communication and Concurrency.

Prentice-Hall.

Milner, R. (1999). Communicating and Mobile Systems:

The π-calculus. Cambridge University Press.

Papazoglou, M. P., Traverso, P., Dustdar, S., Leymann,

F., and Kr

amer, B. J. (2006). Service-oriented

computing: A research roadmap. In Cubera,

F., Kr

amer, B. J., and Papazoglou, M. P., edi-

tors, Service Oriented Computing (SOC), number

05462 in Dagstuhl Seminar Proceedings. Interna-

tionales Begegnungs- und Forschungszentrum fuer

Informatik (IBFI), Schloss Dagstuhl, Germany.

http://drops.dagstuhl.de/opus/volltexte/2006/524

[date of citation: 2006-01-01].

Peltz, C. (2003). Web services orchestration: A review of

emerging technologies, tools, and standards. Techni-

cal report, HP.

Pourraz, F. and Verjus, H. (2007). π-diapason: A π-

calculus based formal language for expressing evolv-

able web services orchestrations. Research Report

LISTIC 07/06, University of Savoie - LISTIC.

Ravn, A. P., Owe, O., Giambiagi, P., and Schneider, G.

(2006). Language-based support for service oriented

architectures: Future directions. In Proceedings of 1st

International Conference on Software and Data Tech-

nologies (ICSOFT 2006), page 6, Set

ubal, Portugal.

Sagonas, K., Swift, T., Warren, D. S., Freire, J., Rao, P.,

Cui, B., Johnson, E., de Castro, L., Marques, R. F.,

Dawson, S., and Kifer, M. (2006). The xsb system

version 3.0 volume 1: Programmer’s manual. Techni-

cal report, XSB consortium.

Sala

un, G., Ferrara, A., and Chirichiello, A. (2004). Ne-

gotiation among web services using lotos/cadp. In

Springer, editor, Proceedings of the European Con-

ference On Web Services (ECOWS’04), volume 3250,

pages 198–212, Erfurt, Germany.

Solanki, M., Cau, A., and Zedan, H. (2006). Asdl: A

wide spectrum language for designing web services.

In 15th International World Wide Web Conference

(WWW2006).

van der Aalst, W. H. M., ter Hofstede, A. H. M., Kie-

puszewski, B., and Barros, A. P. (2003). Workﬂow

patterns. Distributed and Parallel Databases, 14(3) .

DIAPASON: A FORMAL APPROACH FOR SUPPORTING AGILE AND EVOLVABLE INFORMATION SYSTEM

SERVICE-BASED ARCHITECTURES