Integrating Formal Approaches and Simulation to

Improve Reliability and Correctness of Web Services

George Eleftherakis

and Ognen Paunovski

City College, 13, Tsimiski str., 54624 Thessaloniki, Greece

South East European Research Centre, 17, Mitropoleos str., 54624 Thessaloniki, Greece

Abstract. The emerging web service paradigm offers an innovative and prac-

tical platform for business to business collaboration and enterprise information

systems integration. A methodology for modelling web service systems based on

an incremental and iterative approach integrating formal techniques and simula-

tion is presented. This disciplined approach focuses on improving the reliability

and correctness of the system under development. Using X-machines as the core

design technique it offers intuitive mapping of BPEL speciﬁcation. At the same

time it enforces continuous veriﬁcation and testing of components throughout the

process. Blending this formal approach with simulation it allows the informal

veriﬁcation of complex service compositions in cases where formal veriﬁcation

is impossible or impractical. The applicability of the methodology is practically

demonstrated through a typical web service case study.

1 Introduction

The future interoperation between network applications will be based heavily on the

concept of Web Services. Web Services (WS) as self-contained software components

aim to provide seamless machine to machine interoperation in network applications.

This new paradigm is of paramount importance for business to business collaboration

and enterprise information systems integration. This is primarily due to the broad range

of applicability and ﬂexibility of the architecture as well as the opportunity to facilitate

introduction of novel functionalities which can be achieved through service collabora-

tion. This collaboration between the services creates a framework for combination of

existing services in order to achieve a desired business process. Thus the elementary

services may form more complex composite services.

However as the complexity of web services increases, there is a need to ensure that

they behave correctly. Therefore the elementary services need to satisfy several crite-

ria. First of all they need to meet the requirements and satisfy any necessary properties

which are part of its design objectives. Additionally the implementation of the service

should follow the design and be tested in order to prove its correctness. In this context

it is argued that the use of formal methods can achieve (to some extend) this goal in all

phases of system development, modelling, veriﬁcation and testing [10]. However ap-

plying formal veriﬁcation to composite web services is not possible in some cases due

Eleftherakis G. and Paunovski O. (2008).

Integrating Formal Approaches and Simulation to Improve Reliability and Correctness ofWeb Services.

In Proceedings of the 6th International Workshop on Modelling, Simulation, Veriﬁcation and Validation of Enterprise Information Systems, pages

180-189

DOI: 10.5220/0001740701800189

 SciTePress

to the complexity of the composition. Furthermore in some cases while formal veriﬁ-

cation may be possible it requires too much time and effort which makes it completely

impractical.

This is in fact why an informal language is commonly used to specify composi-

tions of web services. The Business Process Execution Language for Web Services

(BPEL4WS or BPEL) [1] in recent years has become an industrial standard for speci-

fying web service compositions. Nevertheless while BPEL is intuitive and easy to use

it lacks the capability to ensure “correctness” of the design. A possible solution to this

problem could be achieved by mapping a BPEL process speciﬁcation to a language

with formally deﬁned semantics (e.g. Petri net, state machines, process algebras etc.).

This approach has several advantages. By mapping a BPEL speciﬁcation to a formal

language, a formal semantics of the BPEL could be provided [12]. Also, all static and

dynamic analysis techniques and tools developed for the formal method can be ex-

ploited in the context of BPEL processes improving the conﬁdence of the correctness

of the ﬁnal product.

In this paper we use a formal method, namely X-machines and its extension Com-

municating X-machines, to capture a BPEL process speciﬁcations. The chosen formal

method closely suits the needs of component-based development (like in the case of

web services) while being practical at the same time. Furthermore we present a disci-

plined methodology offering iteratively incremental development of complex service

compositions. The proposed methodology utilises formal modelling and veriﬁcation to

avoid any ﬂaws in the early stages of the development of services together with a for-

mal testing strategy to discover any undiscovered ﬂaws in later stages. These formal

techniques are coupled with informal veriﬁcation steps provided through simulation

(animation). The simulation is needed in order to informally verify complex models

with dynamic communication which cannot be formally veriﬁed. However at the same

time the animation of the model is a step which provides immediate feedback to the de-

velopment team and facilitates effective communication of the formal experts and the

people (users and/or developers) with no formal background. All these features make

the proposed methodology practical. This way it makes the best use of the development

effort to achieve highest conﬁdence in the quality of the developed services.

In the following section several formal approaches used in web service development

are discussed with the focus on the one used in this paper. The major idea and a brief

description of the activities in the proposed methodology is elaborated in section 3. We

demonstrate the approach taken to implementing each activity in the methodology with

the same example throughout. Finally, a discussion on the methodology and further

work to be carried out is presented.

2 Web Services and Formal Methods

There are several techniques and tools that are able to transform a process speciﬁed in

BPEL into a formal model for the purpose of veriﬁcation. In this step the formal model

is usually transformed into a version of ﬁnite state machines (FSM) and automata [7],

a version of Petri nets, process algebras [14] or other formal methods. The second step

181

is to represent the formal model (e.g. FSM) to an appropriate language for a model

checker or any other tool offering veriﬁcation for the model [11].

In this process the emphasis is on the veriﬁcation of web service speciﬁcation, how-

ever there is very little ongoing research on the testing of web services [3]. There are

even fewer attempts to combine testing techniques with veriﬁcation techniques, like the

work described in [6], where the focus is on testing of composite web services. How-

ever there is a lack of methodologies integrating these formal techniques into a practical

process.

The proposed methodology is addressing the issues discussed above through a dis-

ciplined process which utilises a formal approach (X-machines) and integrates many

formal techniques with informal activities (simulation). In essence X-machines is a for-

mal method that enhances the class of FSM by introducing memory and functions. An

X-machine is deﬁned by an input stream, an output stream, a set of values that describe

its memory structure, a set of states, a state transition set and a set of functions. Labels

in the transitions are functions which are triggered through an input symbol and a mem-

ory instance to produce an output symbol and a new memory instance. A deterministic

X-machine [5] is an 8-tuple X = (Σ, Γ, Q, M, Φ, F, q

, m

) where:

– Σ and Γ are the input and output alphabets respectively.

– Q is the ﬁnite set of states.

– M is the (possibly) inﬁnite set called memory.

– Φ, the type of the machine X, is a set of partial functions ϕ that map an input and

a memory state to an output and a possibly different memory state, ϕ : Σ × M →

Γ × M .

– F is the next state partial function, F : Q × Φ → Q, which given a state and a

function from the type Φ determines the next state. F is often described as a state

transition diagram.

– q

and m

are the initial state and initial memory respectively.

X-machines can be applied in similar cases as Statecharts and other similar nota-

tions, such as SDL for example. However, X-machines have several signiﬁcant advan-

tages. First, they provide a mathematical modelling formalism for the system, which in

turn allows X-machine speciﬁcation to be model checked [2]. Thus, facilitating the ver-

iﬁcation of desired model properties. Moreover, X-machines offer a strategy to test the

implementation against the model which guarantees to determine correctness if certain

assumptions in the implementation hold [5].

In addition, communicating X-machines provide a notation allowing to deﬁne in-

teraction and communication between individual X-machine models [8]. Functions can

send messages to input streams of other X-machine components which are consumed

by local functions. A Communicating X-machine System Z as deﬁned in [8] is a 2-tuple

Z = ((C

)

i=1,...,n

, CR) where:

– C

is the i-th Communicating X-machine component, and

– CR is a relation deﬁning the communication among the components, CR ⊆ C ×

C and C = {C

, . . . , C

}. A tuple (C

, C

) ∈ CR denotes that the X-machine

component C

can output a message to a corresponding input stream of X-machine

component C

for any i, k ∈ {1, . . . , n}, i 6= k.

182

A communicating X-machine model consists of several X-machine models that are

able to interact by exchanging messages. The structure CR deﬁnes a directed graph

which statically determines the direction of messages between components. An X-

machine component is deﬁned as an X-machine in which the functions do not only

read and write from/to their input and output streams respectively but also read and

write from/to streams that are used to communicate with other X-machine components.

More analytically, functions are of the form: ϕ

((σ)

, m) = ((γ)

, m

′

) where (σ)

means that input is provided by machine C

whereas (γ)

denotes an outgoing mes-

sage to machine C

. If i = j and/or i = k, that means that machine C

reads from its

standard input stream and/or writes to its standard output stream.

In practice, it is found that the development of a communicating system model can

be based on a number of well-deﬁned distinct steps that are described in detail in the

following sections. To each of the steps a set of appropriate tools, such as an interchange

description language, parser, animator, test set generator etc., is employed in order to

make the methodology applicable in real cases [9].

3 Methodology

Communicating X-machines is viewed as a modelling method, where a complex sys-

tem can be decomposed in small components (elementary services) modelled as simple

X-machine models, thus model interacting component-based systems. The communi-

cation of all these components is speciﬁed separately in order to form the complete

system as a communicating X-machine model which corresponds to a composite web

service. This implies a modular bottom-up approach and supports an iterative gradual

development. It also facilitates the reusability of existing X-machine models, making

the management of the whole project more ﬂexible and efﬁcient. Thus achieving the

completion of the entire model with lower cost and less development time.

The communicating X-machine method supports a disciplined modular develop-

ment, allowing the developers to decompose the system under development into com-

municating components. We suggest that the development of a system model can be

mapped into the following well-deﬁned distinct actions that are graphically illustrated

in ﬁgure 1:

1 Analyze the existing business process in order to determine the web service com-

position:

• description of the tasks performed by individual web services,

• description of the communication (interaction) between the web services,

• description of the expected behaviour of the composed web service.

2 Develop a set of test scenarios (simulation conditions) which will validate the be-

haviour of the service composition. At the same time the set of properties that each

of the services should satisfy need to be derived.

3 Develop X-machine models for each independent service in the composition.

4 Code the X-machine model into a language (XMDL) that facilitates the subsequent

steps.

183

Business Process

Services

Description

Communication

Description

Expected

Behaviour

Services X-machine

Models (visual)

Modelling

Verification

Verified Models

Communicating

X-machine Model

Modelling

Analysis

Simulation

Scenarios

Analysis

Animation

(simulation)

Outcomes

Analysis

Result

Services X-machine

Models (XMDL)

Coding

Simulation Model

Implementation

Model Properties

Analysis

Test Suite

Informal

Verification

< >

EMPTY

NON_EMPTY

FULL

add_part

become_empty

remove_part

add_part

become_full

M=( set_of (ITEM_TYPE, ID), capacity )

remove_part

nore

add

Buffer

EMPTY

NON_EMPTY

FULL

add_part

become_empty

remove_part

add_part

become_full

M=( set_of (ITEM_TYPE, ID), capacity )

remove_part

nore

add

Buffer

part

Input buffer

Processing Machine

Output buffer

part

Input Controller (queue) Output Controller

CONTROLLING

take_out_first

update_memory

ctrl_in

buf_in

mach

mach buf_in

part

in_buffer,not_empty

give_me_one

BLOCKED

READY

PROCESS_COMPLETED

PROCESSING

unblock

request

start

reset

block

end_process

mach

ctrl_in

actrl_in

buf_in ctrl_o ut

ctrl_out

buf_out

ctrl_out

buf_out

ctrl_out

EMPTY

NON_EMPTY

FULL

add_part

become_empty

remove_part

add_part

become_full

buf_in

remove_part

nore

add

ctrl_in

mach

ctrl_in

mach

EMPTY

NON_EMPTY

FULL

add_part

become_empty

remove_part

add_part

become_full

buf_out

remove_part

nore

add

ctrl_out

mach

ctrl_out

mach

operation_push,

operation_pop

CHECKING

forth_coming_will_block

increase

ctrl_out

buf_out

mach

decrease

buf_out

mach

forth_coming_will_not_block

full,

not_full

on_process

-Activity, operation at a particular step

-Transition flow forward

-Transition flow backward (feedback)

-Artifact (single or multiple instances)

Fig.1. The proposed development methodology.

• Simulate the X-machine model to rapidly verify (informally) the expected be-

haviour and communicate the model to the users to detect errors in the design

in the early stages of the development.

5 Use the formal veriﬁcation technique (model checking) for X-machine type models

in order to increase the conﬁdence that the proposed model has the desired charac-

teristics.

6 Develop communicating X-machine model which describes the way in which indi-

vidual services communicate and interact.

7 Implement the communicating X-machine model in a form which could be ani-

mated, used in a simulation study.

8 Execute the test scenarios (deﬁned in step 2) through execution of simulation study

of the implemented model.

9 Analyze the results of the simulation on order to determine whether the service

composition behaved as intended.

The process described above can be used to reﬁne the resulting model following

an iterative process. Towards this end a set of appropriate tools has been developed

and have been integrated under a suite (called X-System), to support modelling with

X-machines [9]. X-System can be employed to facilitate the activities of the above

methodology making it applicable in real cases. Coding of X-machine model is car-

ried out using the X-machine Description Language (XMDL) notation which acts as

184

an interchange language for describing X-machine models and its corresponding tools

(syntax and type checker,visual editor, compiler,animator) [9]. Through the animation,

it is possible for the developers to informally verify that the model corresponds to the

actual system under development. The animation can also be used to demonstrate the

model to the end-users allowing them to identify any misconceptions regarding the user

requirements. After that formal veriﬁcation of X-machine models is achieved with the

use of an automated tool, a model checker. Model checking of X-machine models is

supported by X mCTL . This technique enables the designer to verify the developed

model against temporal logic X mCTL formulas which express the properties that the

system should have. Following the implementation of the service, the test-cases are au-

tomatically derived using the X-machine test case generator. This allows the use of the

formal testing strategy to test the implementation and prove its correctness with respect

to the X-machine model. Once the individual models are veriﬁed, the communication

and interaction of the components can be established. This is done in XMDL-c notation

and its corresponding tools. Using this framework the simulation scenarios are executed

to derive informal validation of the expected behaviour.

In the section that follows a web services example is used as a vehicle of study

illustrating the proposed methodology and its applicability to composite web services,

explaining in practice how each activity is carried out.

4 Case Study

In order to demonstrate the modelling of web services using X-machines, we have ap-

plied our methodology on the Virtual Travel Agency (VTA) case study [7]. In the VTA

problem domain the goal of the VTA service is to provide a ﬂight and hotel booking for

a user. Once the VTA receives a reservation request from a user, it contacts the ﬂight ser-

vice in order to get an offer for the available ﬂights in the speciﬁed period and location.

After that it contacts the hotel service for the available hotel offers. When it receives the

offers the VTA contacts the user with the available offers awaiting its response. If the

user accepts the offer the VTA informs the ﬂight and hotel services in order to obtain

the tickets and provides them to the user. Otherwise (if user rejects the offer) the VTA

rejects the hotel and ﬂight service offers. In the case when no offer is available, either

for the ﬂight or hotel, the VTA informs the user that there is no offer available for the

requested time and location.

First of all the analysis of the description of the case study produces the three ex-

pected documents. A description of the identiﬁed services (i.e. ﬂight, hotel and vta)

and their expected behaviour, a description of the way these services communicate and

ﬁnally the description of the expected system behaviour. Using these documents we

construct the needed simulation scenarios and we specify each model’s properties as

temporal logic formulas. Then we start modelling each service, using the ﬁrst docu-

ment, as X-machine models.

In ﬁgure 2 the state transition diagram of the X-machine model of the ﬂight service

is depicted together with the BPEL description of the service. This ﬁgure clearly depicts

the intuitive modelling of the service as an X-machine model and demonstrates the

expressional power of the X-machine to model web services. The extra beneﬁt using

185

No Yes

NA FAILURE

SUCCESS

NA FAILURE

[

RECEIVE]

Flight Request

[

SWITCH]

isAvailable

[INVOKE]

Flight NA

Flight Service X-Machine modelFlight Service BPEL model

[INVOKE]

Flight Offer

[

PICK]

[ON MESSAGE]

Flight Ack

[ON MESSAGE]

Flight nAck

[INVOKE]

Flight Ticket

WAITING

FLIGHT_NA

FLIGHT_AVAILABLE

WAIT

FAILURE

SUCCESS

FLIGHT_ACCEPTED

flight_offer_available

reset

invoking_flight_offer

invoking_flight_na

invoking_flight_ticket

receiving _flight_ack

receiving_flight_nack

PROCESSING

receiving_flight_request

flight_offer_na

Fig.2. Flight service in BPEL and as an X-machine model.

X-machines compared with other formal methods is that apart from the intuitive way

to model the control (dynamic behaviour of the service) you can model the data (static

part of the service). Using mathematical notation, the deﬁnition of the ﬂight service is

as follows:

– The set of inputs is Σ = BPEL_element × variable where BPEL_element =

{ invoke, receive, on_message, switch, reset } and variable =

variable_name × value, where variable_name is a basic type (could be any

string) and value is either a natural number, or a boolean, or an abstract represen-

tation of date and time as time slots (time_slots). The set of outputs is

Γ ={flight_requested, flight_available, ...}.

– The set of states is Q ={ waiting, processing, flight_available,

flight_na, failure, wait, flight_accepted, success}.

– The memory holds a set of all the available ﬂights and the ﬂight that was requested.

M = (flight_numbers × time_slots, (flight_numbers,time_slots)),

with flight_numbers representing all possible ﬂight numbers.

– The type of the machine Φ is a set of the transition labels in ﬁgure 2.

Finally, the functions ϕ ∈ Φ of the X-machine need to be deﬁned. The next ac-

tivity is to code the model to XMDL. In order to demonstrate XMDL the function

flight_offer_available is deﬁned in XMDL as:

#fun flight_offer_available(((?bpel,(?F,?T))),(?av_flights,?fl))=

if ?bpel = switch and (?F,?T) belongs ?av_flights

then ( (flight_available), (?av_flights),(?F,?T)).

Using XMDL as the modelling language, X-System allows the animation of X-

Machine models. This is an important activity that makes the methodology practical

since it enhances the communication overall (developer to developer and developer to

client) and provides early and cost effective feedback from the actual users although

they have no experience in formal models.

186

vta

ight

hotel

user

WAITING

PROCESSING

OFFER_RECEIVED

WAIT

SUCCESS

OFFER_REJECTED

TICKET_RECEIVED

FAILURE

OFFER_ACCEPTED

OFFER_NOT_AVAILABLE

NA_FAILURE

receiving_offer_request

user

vta

invoking_flight_request

invoking_hotel_request

invoking_offer

reset

receiving_flight_offer

receiving_flight_na

invoking_na

receiving_hotel_na

invoking_flight_nack

invoking_hotel_ack

invoking_flight_nack

invoking_ticket

receiving_offer_nack

receiving_offer_ack

invoking_flight_ack

invoking_hotel_nack

receiving_flight_ticket

receiving_hotel_offer

receiving_hotel_ticket

WAITING

FLIGHT_NA

FLIGHT_AVAILABLE

WAIT

FAILURE

SUCCESS

FLIGHT_ACCEPTED

flight_offer_available

reset

invoking_flight_offer

invoking_flight_na

invoking_flight_ticket

receiving_flight_ack

receiving_flight_nack

vta

WAITING

HOTEL_NA

HOTEL_AVAILABLE

WAIT

FAILURE

SUCCESS

HOTEL_ACCEPTED

hotel_offer_available

reset

invoking_hotel_offer

invoking_hotel_na

invoking_hotel_ticket

receiving_hotel_ack

receiving_hotel_nack

PROCESSING

receiving_hotel_request

hotel_offer_na

INACTIVE

WAIT

OFFER_RECEIVED

OFFER_ACCEPTED

NA_FAILURE

SUCCESS

requesting_offer

receiving_na

receiving_offer

reset

invoking_offer_ack

receiving_ticket

invoking_offer_nack

PROCESSING

receiving_flight_request

flight_offer_na

user

flight

hotel

flight

hotel

flight

hotel

user

hotel

user

hotel

flight

user

vta

flight

vta

Fig.3. The overall system as a communicating X-machine model.

However there are properties of the system that the designer would like to prove and

not demonstrate their existence in the X-machine model. The formal veriﬁcation tech-

nique for X-machine models enables the designer in the following activity to formally

verify the developed model against temporal logic formulas that express the properties

that the system should have.

The next step is to specify the communication between the X-machine models of the

services and this way create the communicating X-machine model of the system under

development. One more beneﬁt is that it is possible to model the environment (i.e. the

user) as an X-machine achieving to model the complete system. Graphically on the state

187

transition diagram we denote the acceptance of input by a stream other than the standard

by a solid circle along with the name C

of the communicating X-machine component

that sends it. Similarly, a solid diamond with the name C

denotes that output is sent

to the C

communicating X-machine component. The complete model is depicted in

ﬁgure 3 providing a ﬂexible and modular design of the complete system where clearly

the services of the system are represented together with the needed communication to

create the expected system behaviour.

XMDL has been extended (XMDL-c) in order to code communicating components.

XMDL-c provides syntax that facilitates the deﬁnition of the communicating functions.

CommX-System is a tool created to support modelling and simulation of Communi-

cating X-machines [8]. CommX-System takes as input all the XMDL ﬁles describing

the services together with the XMDL-c ﬁle that describes the communication between

them, and outputs an executable ﬁle corresponding to the overall system, offering a

simulation model of it. The following activity is to execute the simulation scenarios

and compare the outcome with the expected behaviour of the system. The results of

this analysis will provide feedback to the developers indicating the “correctness” of the

model. Taking this into account further iterations maybe needed to improve the model.

5 Conclusions and Further Work

We have presented a methodology for developing enterprise systems following a web

service architecture using X-machines formal method. X-machines attracted many re-

searchers interest over the last ﬁfteen years [4] mainly because of the intuitiveness in

modelling reactive systems and the additional features they provide in terms of testing

and veriﬁcation. The methodology and its accompanying tools impose an incremental

bottom-up practical development.

The proposed methodology following a holistic approach, integrates formal tech-

niques focusing on the improvement of reliability and correctness of composite web

services. It offers a disciplined approach exhibiting the following key features: (a) It is

component based and architecture centric. (b) It uses a formal method (X-machines) as

the core design tool that offers a diagrammatic notation and tool support. This formal

model offers an intuitive mapping of BPEL notation to a formal one. (c) It enforces

continuous veriﬁcation and testing of components throughout the process to achieve

highest conﬁdence in the quality of the developed components. (d) It employs simula-

tion allowing the informal veriﬁcation of complex service compositions in cases where

formal veriﬁcation is impossible or impractical. (e) Design is incremental and iterative

via a prescribed sequence of design activities within a cyclic process.

The use of the proposed methodology on the case study demonstrated promising re-

sults. However, there are several issues that could be potentially improved. Future work

will be concentrated on the automatic translation of BPEL speciﬁcations to X-machine

models. In addition the model checking technique could be further extended in order to

facilitate the formal veriﬁcation of communicating X-machine models. Research is also

conducted towards the establishment of a successful testing strategy for the communi-

cating X-machine models, that is expected also to offer the ability to formally extract

simulation scenarios in order to follow a disciplined approach in the informal veriﬁca-

188

tion through simulation. Finally, on going research is addressing the issue of detecting

unexpected emergent behaviours in automatic web services compositions [13].

References

1. A. Arkin, S. Askary, B. Bloch, F. Curbera, Y. Goland, N. Kartha, C.K. Liu, V. Mehta,

S. Thatte, P. Yendluri, A. Yiu, and A. Alves. Web services business process execution lan-

guage, version 2.0, December 2005.

2. G. Eleftherakis. Formal Veriﬁcation of X-machine Models : Towards Formal Development

of Computer-Based Systems. PhD thesis, University of Shefﬁeld, UK, 2003.

3. Lars Frantzen, Jan Tretmans, and Ren´e de Vries. Towards model-based testing of web ser-

vices. In Antonia Bertolino and Andrea Polini, editors, in Proceedings of International

Workshop on Web Services Modeling and Testing (WS-MaTe2006), pages 67–82, Palermo,

Sicily, Italy, June 9th 2006.

4. M. Holcombe. What are X-machines? Formal Aspects of Computing, 12(6):418–422, 2000.

5. M. Holcombe and F. Ipate. Correct Systems: Building a Business Process Solution. Springer

Verlag, London, 1998.

6. Hai Huang, Wei-Tek Tsai, Raymond Paul, and Yinong Chen. Automated model checking

and testing for composite web services. In Proceedings of 8th IEEE International Symposium

on Object-Oriented Real-Time Distributed Computing (ISORC 2005), page 300307, Seattle,

WA, USA, May 2005.

7. R. Kazhamiakin and M. Pistore. Parametric communication model for the veriﬁcation of

BPEL4WS compositions. In M. Bravetti, L. Kloul, and G. Zavattaro, editors, Proceedings

of the 2nd International Workshop on Web Services and Formal Methods, volume 3670 of

Lecture Notes in Computer Science, pages 318–332, Versailles, France, September 2005.

8. P. Kefalas, G. Eleftherakis, and E. Kehris. Communicating X-machines: a practical approach

for formal and modular speciﬁcation of large systems. Information and Software Technology,

45(5):269–280, April 2003.

9. P. Kefalas, G. Eleftherakis, and A. Sotiriadou. Developing Tools for Formal Methods. In 9th

Panhellenic Conference on Informatics, pages 625–639, Thessaloniki, November 2003.

10. B. Meyer. The Grand Challenge of Trusted Components. In 25th International Conference

on Software Engineering, pages 660–667, Portland, Oregon, May 2003.

11. S. Nakajima. Lightweight formal analysis of web service ﬂows. Progress in Informatics,

1(2):57–76, November 2005.

12. C. Ouyang, W.M.P. van der Aalst, S. Breutel, M. Dumas, A.H.M. ter Hofstede, and H.M.W.

Verbeek. Formal semantics and analysis of control ﬂow in ws-bpel. Technical Report Report

BPM-05-15, BPM Center, 2005.

13. O. Paunovski, G. Eleftherakis, and A.J. Cowling. Framework for Exploring Emergence

within Complex Systems. In Proc. 2nd Annual SEERC Doctoral Conference, July 2007.

14. G. Sala¨un, L. Bordeaux, and M. Schaerf. Describing and reasoning on web services using

process algebra. In Proceedings of the IEEE International Conference on Web Services,

pages 43–51, San Diego, CA, USA, June 2004. IEEE.

189