AN EVENT-BASED MODEL FOR WEB SERVICES COORDINATION

Mohsen Rouached

LORIA-INRIA

BP 239, F-54506 Vandoeuvre-les-Nancy Cedex, France

Claude Godart

LORIA-INRIA

BP 239, F-54506 Vandoeuvre-les-Nancy Cedex, France

Keywords:

Web services, Web service composition, composite Event, Event Calculus.

Abstract:

The promise of Web services is centered around standard and interoperable means for integrating loosely

coupled Web based components that expose well-deﬁned interfaces, while abstracting the implementation and

platform speciﬁc details. The current and more mature core Web services standards SOAP, WSDL and UDDI

provide a solid foundation to accomplish this. However, these speciﬁcations primarily enable development of

simple Web services whereas the ultimate goal of Web services is to facilitate and automate business process

collaborations both inside and outside enterprize boundaries. Useful business applications of Web services in

B2B, B2C, and enterprize application integration environments will require the ability to compose complex

and distributed Web services and the ability to formally describe the relationships between the constituent

low-level services.

This paper advocates an event-based approach for Web services coordination. We focused on reasoning about

events to capture the semantics of complex Web service combinations. Then we present a formal language to

specifying composite events for managing complex interactions amongst services, and detecting inconsisten-

cies that may arise at run-time.

1 INTRODUCTION

Web services have been gathering an increasing

amount of attention lately. They have emerged as a

distributed computing paradigm for applications, or

business processes, that interact over the open Inter-

net through the use of standard protocols. Current

Web services standards such as SOAP, and WSDL

provide rudimentary mechanisms for deﬁning interac-

tions amongst services that may be located in different

organizations. While WSDL provides the deﬁnitions

for the entry-points of a service, in many cases, in-

teractions between services have more structure than

can be described by just the deﬁnition of entry points.

Indeed, to form real B2B or B2C interactions, a set

of services need to work together and be executed

in speciﬁed order. Such execution is termed service

composition or choreography. Several standards have

been proposed and are being introduced into prac-

tice, especially BPML, BPEL4WS, and WSCI. How-

ever, these approaches are conceptually no more than

simple extensions of traditional workﬂow technolo-

gies wherein Web services, which have to cope with

a highly dynamic environment, are used to represent

tasks instead of ad hoc legacy processes. Indeed,

distributed enterprize environments assume that Web

services are not limited to peer-to-peer interactions

between business partners, but that it should be pos-

sible to coordinate interactions of a group of busi-

ness partners. However, the above approaches are

largely limited to rather simple request/response ser-

vices and the Web choreography standards rely on

the XML based RPC which is essentially a one-to-

one mechanism, and is not suitable for coordinating

Web services in complex environments. Addition-

ally, Web service speciﬁcations mostly concentrate on

lower levels and do not offer high-level abstractions

to accommodate variations in service invocations and

run-time interactions.

On the other hand, the event-based architectural

style has become prevalent for large-scale distributed

applications due to the inherent loose coupling of

the participants. It facilitates the clear separation of

communication from computation and carries the po-

tential for easy integration of autonomous, heteroge-

neous components into complex systems that are easy

to evolve and scale (Pietzuch et al., 2003). However,

the event-driven technology is not well exploited in

Rouached M. and Godart C. (2006).

AN EVENT-BASED MODEL FOR WEB SERVICES COORDINATION.

In Proceedings of WEBIST 2006 - Second International Conference on Web Information Systems and Technologies - Internet Technology / Web

Interface and Applications, pages 81-88

DOI: 10.5220/0001244700810088

 SciTePress

the context of Web services. Indeed, many existing

initiatives such as WS-Eventing and WS-Notiﬁcation

restrict subscriptions to single events only and thus

luck the ability to express interest in the occurrence of

patterns of events. However, especially in large-scale

Web applications, event sinks may be overwhelmed

by the vast number of primitive, low-level events,

and would beneﬁt from a higher-level view. Such a

higher-level view is given by composite events that

are published when an event pattern occurs. There-

fore, Web services need to support composite event

detection, in order to quickly and efﬁciently notify

their clients of new, relevant information in the net-

work. This can improve efﬁciency and robustness

in the case of widely distributed Web services where

bandwidth is limited and services are loosely cou-

pled. Nevertheless, without composite event detec-

tion, many messages would still be sent unnecessarily,

because speciﬁc event combinations or patterns could

not be expressed by recipients.

In this paper, we address the problem of coordi-

nating large-scale Web services by adopting a purely

event-based approach. We propose a distributed ar-

chitecture and a general framework to handle the

event composition in Web services. This frame-

work includes a formal language with well formal se-

mantics to specifying and reasoning about composite

events, which facilitates the detection of several in-

consistencies that may arise at run-time. The remain-

der of the paper is structured as follows. Section 2

describes a car rental scenario used as a running ex-

ample. In section 3 we present our event-based ar-

chitecture. We start by deﬁning events in Web ser-

vices context. Then, we present the proposed model.

Section 4 studies the event composition in distributed

Web service environments. It details a formal lan-

guage for specifying composite events and precises

how this formalism can verify and detect some exam-

ples of inconsistencies that may arise in the running

scenario. In section 5, the related work is discussed.

Finally, section 6 concludes the paper and discusses

some future directions.

2 RUNNING EXAMPLE

Throughout this article, we will illustrate our ideas

with an interesting running example. We consider a

car rental scenario that involves four complementary

services. A car broker service (CBS) which acts as a

broker offering its customers the ability to rent cars

provided by different car rental companies directly

from car parks at different locations. CBS is imple-

mented as a service composition process, which in-

teracts with car information services (CIS), and cus-

tomer management service (CMS). CIS services are

provided by different car rental companies and main-

tain databases of cars, check their availability and al-

locate cars to customers as requested by CBS.

CMS maintains the database of the customers and

authenticates customers as requested by CBS. Each

car park also provides a car sensor service (CSS) that

senses cars as they are driven in or out of car parks and

inform CBS accordingly. The end users can access

CBS through a user interaction service (UIS).

Typically, CBS receives car rental requests from

UIS services, authorizes customers contacting CMS

and checks for the availability of cars by contact-

ing CIS services, and gets car movement information

from CSS services.

However, due to the autonomous nature of services

and the run-time requirements monitoring, many

complications may arise. For example, CBS can ac-

cept a car rental request and allocate a speciﬁc car to

it if, due to the malfunctioning of a CSS service, the

departure of the relevant car from a car park has not

been reported and, asa consequence, the car is consid-

ered to be available by the UIS service. Through this

example, we aim to precise how Web services inter-

actions can be speciﬁed and formalized using events,

and how this speciﬁcation could facilitate their moni-

toring at run-time.

3 EVENT BASED WEB SERVICE

COORDINATION

The services will interact by responding to commu-

nal events. We are not interested in the intra-service

interaction between the different business objects that

make out a single service, but we focused on provid-

ing a formal framework for coordinating distributed

and autonomous Web services . Then, if a such

framework could be applied to inter-services interac-

tion, the local business objects of each service can be

considered as small atomic services themselves and

therefore it can be applied to intra-service interaction

recursively. Accordingly, this approach can be eas-

ily generalized into an n-level system since the num-

ber of parties that participate in an event can be eas-

ily increased by just adding another service that sub-

scribes to the event, without having to redesign the

entire chain of one-to-one message exchanges. Let us

now introduce the notion of events and describe the

role that can play in Web services interactions.

3.1 Events in Web Services

Events can be simply perceived as occurrences that

happen over time, and can be independent or not from

each other. They are represented by structured mes-

sages which are exchanged between the event genera-

WEBIST 2006 - INTERNET TECHNOLOGY

tor and any number of event receivers, and carry con-

textual information in which the event is described,

plus the circumstances in which it occurred (event

context). Such contextual information may be an ex-

plicit part of the event representation, or can be im-

plicitly deduced from said circumstances. The sig-

niﬁcance of business events is ensured by assigning

types to these events. The type of an event is mod-

eled by its body, which incorporates a data structure

representing the context in which the event was gen-

erated. In our framework, three event types could be

distinguished:

• The invocation of an operation by a partner service.

These events are represented by terms of the form

Q.ServiceName.OperationName(parameters).

For example, the event

Q.CBS.ReleaseKey(car,customer,Park) precises

that CBS invokes an operation in UIS that signiﬁes

the release of a car key to a customer.

• The reply following the execution of an op-

eration that was invoked by a partner service.

These events are represented by terms of the form

R.ServiceName.OperationName(parameters).For

example, the event R.CSS.Depart(car,park) is a

reply event that signiﬁes the exit of the car from

the car park. If the previous event did not occur,

the event Q.CBS.Available(car,park) must be gen-

erated to CIS in order to check the availability of

the requested car.

• The assignment of a value to a variable. These

events are represented by terms of the form

AS.AssignmentName(assignmentId). For exam-

ple, if the URL of a service (for example CSS

or CIS) has to be changed, an assignment event

AS.AssignementURL(NewURL) is generated.

In next section, we show how to use these events to

manage and monitor interactions between Web ser-

vices.

3.2 Web Services Interactions

Web services interactions are based on the simultane-

ous participation in shared events. Event notiﬁcations

are not propagated one-to-one but are broadcast in

parallel to all services that have an interest in relevant

event. Then, the updates that result from a given busi-

ness event are to be coordinated throughout the en-

tirety of all interested services that participate in that

event. This broadcasting paradigm is fully compati-

ble with current Web service standards such as SOAP,

WSDL and UDDI.

Since each Web service operates as an autonomous

and separate entity and is not subject to a form of

centralized monitoring, we associate to each service

a local event history, and to each group of services

an event space. The event history represents events

that occurred or they are assumed to be occur whereas

the event space represents a group of collaborating

services which interact by exchanging events from

their local event histories, and changes over time as

services join or leave the collaboration. Each event

space is represented by a monitor, which operates as

an UDDI-like registry for advertising and discovering

events that may be published or subscribed to by the

participating services. As soon as a relevant event is

published, the monitor will dispatch it to subscribed

participants, after which they may consume the event

once it conforms to prescribed policies. Service poli-

cies such as security policies and access controls are

beyond the scope of this paper, but are planned as very

important topics for future research.

The monitor may be allocated to one of the par-

ticipants according to some criteria. For example, in

the rent car scenario, we can specify an event space

formed by the CBS, CIS, CSS and UIS. The monitor

is delegated to the CBS since it is responsible for the

instantiation of the interaction and therefore it has a

directed relationship with customers. In some other

cases, in order to stress the independent and trusted

nature of the monitor, it can be implemented on an in-

dividual trusted party chosen by all service partners.

In complex environment where numerous business

partners interact in shared business processes, the re-

sponse to a given request usually needs to handle sev-

eral event spaces at the same time and therefore needs

a mean to ensure interactions between them at run-

time. In our approach, this is illustrated by allowing

communication between monitors of all the involved

event spaces. Indeed, in an event space, if an event oc-

curs in a given Web service, this event is routed to the

local monitor which broadcast it to all subscribed ser-

vices. If the monitor detects that a subscribed service

is situated in an external event space, it propagates the

event to its representing monitor that will carry out

the same treatment. The event routing is carried out

according to the URL of services and monitors, that

are introduced as parameters of the generated event.

These URL are then stored as attribute values to each

event space’s monitor and can be changed dynami-

cally by triggering an event of assignment type. Fig-

ure 1 shows how communications between three dif-

ferent event spaces can be established.

After introducing the notion of events and present-

ing their role in coordinating and composing Web ser-

vices, we focus in next section on providing a formal

speciﬁcation to composite events, and then using this

speciﬁcation to handle some inconsistencies that may

arise in the car rental scenario described in section 2.

AN EVENT-BASED MODEL FOR WEB SERVICES COORDINATION

S13

S14

S11 S12

S23

S22S21

S24

S31

S32

Event Space : ES3

Monitor(ES1) Monitor(ES2)

Monitor(ES3)

Event Space : ES1 Event Space : ES2

Figure 1: Web services Coordination.

4 EVENT COMPOSITION

In Web services, the current event based approaches

such as (Lemahieu et al., 2003a; Lemahieu et al.,

2003b) only provide parameterized primitive events

and leave the task of composing events to the appli-

cation programmer. That means that they ﬁlter event

notiﬁcations trying to deliver events of interest to con-

sumers without considering any correlation with other

event occurrences. Instead, we are interested in spec-

ifying and handling event composition. We start by

proposing a core composite event language, then we

use this formalism to check some examples of devia-

tions derived from the car rental scenario.

4.1 Composite Event Language

In order to provide a computational model for

events, we use the event calculus (Kowalski and

Sergot, 1986) which is a calculus that allows for

specifying some state at particular time-points for

time-varying properties (called ﬂuents). The oc-

currence of an event is represented by the predi-

cate Happens(e, t, (t1,t2)) which signiﬁes that an

event e occurs at some time t within the time range

(t1,t2). The boundaries of (t1,t2) can be speci-

ﬁed by using either time constants, or arithmetic ex-

pressions over the time variables of other Happens

predicates of the same formula. An event may initiate

or terminate a ﬂuent. A ﬂuent is speciﬁed as a condi-

tion over the value of a speciﬁc variable of the compo-

sition process of a system. The ﬂuent equalT o(x, y),

for example, signiﬁes that the value of the variable

x is equal to y. The effects of events on ﬂuents are

represented by the predicates Initiates(e, f, t) and

Terminates(e, f, t). Initiates(e, f, t) signiﬁes that

a ﬂuent f starts to hold after the event e at time t.

Terminates(e, f, t) signiﬁes that a ﬂuent f ceases

to hold after the event e occurs at time t. An EC for-

mula may also use the predicate HoldsAt(f,t) which

signiﬁes that the ﬂuent f holds at time t. Using these

predicates, some literals included in the event log of

the car rental scenario are shown in ﬁgure 2. Variables

, v

, and c

represent respectively the park number,

the car number, and the customer identiﬁer. Given this

L2 :Happens(Q.U IC.RelKey(v1,c1,l1), 5, (5, 5))

L3 :Happens(Q.CIS.Available(v1,l1), 9, (9, 9))

L4 :Happens(R.U IS.RetKey(v1,l1), 15, (15, 15))

L5 :Happens(RC.CSS.Enter(v2,l2), 18, (18, 18))

L6 :Happens(R.U IS.RetKey(v2,l2), 23, (23, 23))

L7 :Happens(Q.CIS.Available(v2,l2), 26, (26, 26))

L8 :Happens(

Q.CSS.Enter(v1,l1), 27, (27, 27))

L9 :Happens(Q.U IS.RelKey(v2,c2,l2), 28, (28, 28))

L10 :Happens(Q.CIS.Available(v2,l2), 34, (34, 34)

L11 :Happens(R.U IS.CarRequest(c1,l2), 49, (49, 49))

L12 :Happens(Q.CIS.F indAvailable(l2,v), 50, (50, 50))

L13 :Happens(Q.CIS.F indAvailable(l2,v), 51, (51, 51))

L14 :Happens(R.U IS.CarHire(c

1,l2,v2), 52, (52, 52))

L15 :Initiates(Q.CIS.F indAvailable(l2,v),equalTo(v, v2, 51))

L1 :Happens(R.CSS.enter(v1,l1), 1, (1, 1))

L16 :Happens(R.U IS.RetKey(v2,l2), 54, (54, 54))

Figure 2: The CRS Event Log.

speciﬁcation, both behavioral properties and assump-

tions of each event space associated to a Web service

composition can be formally expressed, which per-

mits to monitor different types of deviations and in-

consistencies. A monitoring scheme and a detailed

algorithm were discussed in (Spanoudakis and Mah-

bub, 2004). However, in that work, only simple busi-

ness events were considered and the event composi-

tion was not taken into account.

4.1.1 Temporal Orders

Based on the event calculus, it is easy to treat event

interrelationships, as different Happens can refer to

the same timepoint. Given this property, we can de-

duce that two events (with their corresponding time-

points) can be totally ordered based on the ordering of

their timepoints and the event calculus standard order

relation for time. Indeed, let e1 and e2 be any two

primitive events then the temporal order of these two

events is deﬁned as follows:

• Happens(e1,t1) is said to be happen before

Happens(e2,t2) if t1 <t2.

• Happens(e1,t1) is said to be concurrent with

Happens(e2,t2) if t1=t2.

• Happens(e1,t1) is said to be happen after

Happens(e2,t2) if t1 >t2.

WEBIST 2006 - INTERNET TECHNOLOGY

4.1.2 Disjunction

The meaning of the disjunction is that as soon as

either event occurs, the disjunctive event occurs.

The disjunction of two events e1 and e2 is denoted

disj(e1,e2). Formally:

disj(e1,e2)(t)=Initiates(e

, raised, t) ←−

Happens(e

,t) ∨ Initiates(e

, raised, t) ←−

Happens(e

,t)

4.1.3 Conjunction

The meaning of the conjunction is that two events

must both occur before the conjunctive event e3

occurs, but that the order of occurrence, and any

overlap of occurrence, is immaterial. The conjunction

of two events e1 and e2 is denoted conj(e1,e2).

Formally:

conj(e1,e2)(t)=Initiates(e

, raised, t) ←−

Happens(e

) ∧ Happens(e

) ∧ (t ≥ sup{t

})

4.1.4 Sequence

Sequence is said to be strict, i.e. one event must

have occurred before the next event in the sequence.

Sequence of two events e1 and e2 is denoted

seq(e1,e2), and is deﬁned as follows:

seq(e1,e2)(t)=Happens(e

) ←−

Happens(e

) ∧ (t

)

It is possible that after the occurrence of e1, e2 does

not occur at all. To avoid this situation, we must ap-

propriately use deﬁnite events, such as absolute tem-

poral event or the end of each operation’s invocation.

4.1.5 Negation

The meaning of a negation is that an event e1 does

not occur in a closed interval formed by two events

e2 and e3. It is denoted by neg(e1,e2,e3). Formally:

neg(e1,e2,e3)(t)=∀t

∈ [t

], Happens(e

) ∧

Happens(e

) ∧¬Happens(e

)

4.1.6 Temporal Iteration

A periodic event is a temporal event that occurs peri-

odically. It is denoted by P (e1,d,e2) where e1 and

e2 are two arbitrary events and d is a time slot. Event

e1 occurs for every d in the interval [e1,e2]. For-

mally:

P (e1,d,e2)(t)=(∃t

)(∀t

∈ [t

,t],t = t

+ i ∗

dfori∈ N)(Happens(e1,t

) ∧¬Happens(e2,t

))

If we have the constraint that e1 occurs only once e2

occurs, the previous deﬁnition becomes:

P (e1,d,e2)(t)=(∃t

)(t>t

)(Happens(e1,t

) ∧

Happens(e2,t))

Additionally, we have the possibility to combine

different operators in the same time. For example,

disj(e1,seq(e2,e3)) represents a composite event

which occurs as a result of the disjunction of e1 and

the sequence of e2 and e3. After specifying compos-

ite events and deﬁning semantics of composition op-

erators, it is necessary to study their relationships in

order to ensure the synchronization of the exchanges

and enable the communication among services either

in the same event space or in different event spaces.

4.2 Event-driven Causality

From an abstract point of view, a Web service compo-

sition can be described by the types and relative order

of events occuring in each atomic service. Let E

de-

note the set of events occurring in service S

, and let

E = ∪

i=1,...,N

denote the set of all events (either

primitive or composite) in the N compound services.

These event sets are evolving dynamically during ex-

changes between services. Events in E

are totally

ordered by the sequence of their occurrence. Thus, it

is convenient to index the events of a service S

in the

order in which they occur: E

= {e

, ...}.

We will refer to this occurrence to specify an enumer-

ation of E

Deﬁnition 1 Given the enumeration of E

, the

causality relation ≺ onto E × E is the smallest tran-

sitive relation satisfying:

(1) If e

∈ E

occur in the same service S

and

j<k, then e

≺ e

(2) If s ∈ E

is a sent event and r ∈ E

is the corre-

sponding received event, then s ≺ r.

If for two events e1 and e2, neither e1 ≺ e2, nor

e2 ≺ e1 holds, then neither of them causally affects

the other. There is no way to decide which of the

events e1 and e2 took place ﬁrst, i.e, we do not know

their absolute order. This motivates the following def-

inition of concurrency:

Deﬁnition 2 The concurrency relation  onto E × E

is deﬁned as

e1  e2 ≡¬((e1 ≺ e2) ∨ (e2 ≺ e1))

If e1  e2, e1 and e2 are said to be concurrent.

To illustrate the concept of causality between events,

we suggest the example illustrated in ﬁgure 3. In

this example, a service composition involves three

atomic services: S

, S

and S

. {a1,a2,a3,a4,a5},

{b1,b2,b3,b4} and {c1,c2,c3,c4} are sets of op-

erations invoked respectively by S

, S

and S

{m1,m2,m3,m4,m5} is the set of messages

(queries) exchanged between services during the re-

sponse to a customer request.

In this example, we have the following relations:

a1 ≺ c1, a3 ≺ b2, c2 ≺ a4, b3 ≺ a5, b4 ≺ c4.

Certain events couples are independant or concurrent:

a2  b1, b1  c3, a2  c3. The concurrency relation

 is not transitive. For example, in Figure 3 a3  c1

AN EVENT-BASED MODEL FOR WEB SERVICES COORDINATION

a3 a4 a5

c1 c2 c3 c4

b1 b3 b4

m2 m4

a1 a2

Figure 3: Event-driven Causality.

and c1  b2 hold, but obviously a3 ≺ b2. In general,

an unspeciﬁed pair of events always satisﬁes one and

only one of the following relations:

∀e1,e2:e1 ≺ e2



e2 ≺ e1



e1  e2

The symbol



is the ”exclusive or” operator.

In principle, we can determine causal relationships

by assigning to each event e the set of events causally

related with it, we denote this set C(e). C(e) is de-

ﬁned as follows:

Deﬁnition 3 Let E = ∪

i=1,...,N

denote the set of

exchanged events, and let e ∈ E denote an event oc-

curring during an operation invocation. C(e) is de-

ﬁned as

C(e)={e1 ∈ E | e1 ≺ e}∪{e}

The projection of C(e) on E

, denoted C

(e)=

C(e)∩E

. For example, event c4 in Figure 3 is reach-

able by c3,c2,c1,a1,b4,b3,b2,b1,a3 and a2; hence,

C(c4) = {c3,c2,c1,a1,b4,b3,b2,b1,a3,a2}. After

deﬁning C(e), we can characterize the causality re-

lationship between two different events e1 and e2 as

follows:

1. e1 ≺ e2 iff e1 ∈ C(e2).

2. e1  e2 iff e1 /∈ C(e2) ∧ e

2 /∈ C(e1).

In order to facilitate the handling of C(e),we

have represented it by a vector time ( C(e)=

∪

i=1,...,N

(e)). If E

= {e

, ..., e

then e

∈ C

(e) implies that {e

, ...e

kj−1

}⊂

(e). Therefore, for each k the set C

(e) is suf-

ﬁciently characterized by the largest index among

its members, i.e, its cardinality. Thus, C(e) can

be uniquely represented by an N-dimensional vector

V (e) of cardinal numbers, where V

(e)=| C

(e) |

holds for the k-th component (k =1, ..., N ) of vector

V (e). However, in some service composition scenar-

ios, the number of atomic services is not ﬁxed. To

handle this case, we suggest to represent V (e) by the

set of all those pairs (k, | C

(e) |) for which the sec-

ond component is different from 0. As an example,

the set of causality relationships of event c4 in 3 can

be represented by V (c4) = [3, 4, 4] because the cardi-

nality of C

(c4),C

(c4) and C

(c4) is 3,4, and 4 re-

spectively. For notational convenience, let the supre-

mum sup{v1,v2, ..., vm} of a set {v 1,v2, ..., vm} of

n-dimensional vectors denote the vector v deﬁned as

v[i]=max{v1[i], ..., vm[i]} for i =1, ..., n. This

leads to the following deﬁnition:

Deﬁnition 4 Let e1 and e2 denote two events, let

C(e1), C(e2) the sets of causality relationships of

these events, and let V (e1), V (e2) denote the cor-

responding vector representations, respectively. The

vector representation of the union C(e1) ∪ C(e2) is

V (C(e1) ∪ C(e2)) = sup{

V (e1),V(e2)}

Let V (e) denote the vector time V

which results from

the occurrence of event e in service S

. We consider

V (e) the vector timestamp of event e. Since a sim-

ple one-to-one correspondence between vector times-

tamp V (e) and C(e) exists for all e ∈ E, we can de-

termine causal relationships solely by analysing the

vector timestamps of the events in question.

Deﬁnition 5 For two events e1 and e2, we have

1. e1 ≺ e2 iff V (e1) <V(e2).

2. e1  e2 iff V (e1)  V (e2).

For two vectors v1 and v2 of dimension m, we have:

1. v1 ≤ v2 iff v1[k] ≤ v 2[k] for k =1, ..., m.

2. v1 <v2 iff v

1 ≤ v2 and v1 = v2.

3. v1  v2 iff ¬(v1 <v2) ∧¬(v2 <v1).

Furthermore, we can restrict the comparison to just

two vector components in order to determine the pre-

cise causal relationship between two events if their

origins services S

and S

are known. For two events

e1 ∈ E

and e2 ∈ E

,e1 = e2,wehave

1. e1 ≺ e2 iff V

(e1) ≤ V

(e2).

2. e1  e2 iff V

(e1) >V

(e2) ∧ V

(e2) >V

(e1).

The meaning of this characterization is that if the

“knowledge” of event e2 in service S

about the

events in service S

(i.e,V

(e2)) is at least as accu-

rate as the corresponding “knowledge” V

(e1) of e1

in S

, then there must exist a chain of events which

propagated this knowledge from e1 at S

to e2 at S

hence e1 ≺ e2 must hold. If, on the other hand, event

e2 is not aware of as many events in S

as is event e1,

and e1 is not aware of as many events in S

as is e2,

then both events have no knowledge about each other,

and thus they are concurrent.

4.3 Event Based Veriﬁcation

Some monitoring requirements of the car rental sce-

nario, introduced in section 2, are speciﬁed as fol-

lows:

WEBIST 2006 - INTERNET TECHNOLOGY

(A1) Happens(R.UIS.RelKey(v, c, l),t1, (t1,t1)) ∧

¬(∃t2)Happens( R.CS S.Depart(v, l),t2, (t1,t1+6∗

tu)=⇒ (∃t3)Happens(R.CIS.Available(v, l),t3,

(t1+6∗ tu, t1+6∗ tu))

(A2) Happens(R.UIS.CarRequest(c, l),t1, (t1,t1)) ∧

Happens(R.CIS.F indAvailable(l, v3),t2, (t1,t1+

tu)) ∧ Initiates(R.CIS.F indAvailable(l, v),equalTo

(v,v3),t2)=⇒ (∃t3)Happens(Q.U IS.CarHire(c, l, v)

,t3, (t2,t2+tu))

(A3) Happens(R.CIS.F indAvailable(l, v),t1, (t1,t1))

∧ HoldsAt(equalT o(availability(v3), not avail),t1

− tu)=⇒¬Initiates(R.CIS.F indAvailable(l, v),

equalT o(v, v3))

(A4) Happens(Q.U IS.RelKey(v3,c,l),t1, (t1,t1)) ∧

Happens(Q.U IS.RetKey(v3,l),t2, (t2,t2) ∧

(t1 ≤ t3) ∧ (t3 ≤ t2) =⇒

HoldsAt(equalT o(availability(v3), not avail) ,t3)

These requirements are considered as events and

are expressed in terms of the EC predicates to facil-

itate the detection of inconsistencies that may arise.

For example, the formula A1 speciﬁes that when CBS

invokes an operation in UIS (R.UIS.RelKey(v, c, l)

)that signiﬁes the release of a car key to a customer, it

waits for an event signifying the exit of the car from

the car park for 6 time units (this message is to be

sent by CSS). If the latter event does not occur, CBS

invokes the operation Available(v, l) in CIS to mark

the relevant car as available.

We precise that in the above formulas, tu refers

to the minimum time between the occurrence of two

events. tu can be set by the service provider.

Given this speciﬁcation and the event log of ﬁgure

2, the assumption A3 is found to be inconsistent with

the expected behavior of CBS at t=54. A3 is an as-

sumption about the behavior of the CIS service stating

that when CIS executes the operation F indAvailable

it should not report a car as available unless this is

indeed the case. The inconsistency arises because

the literals L13 and L14 in Figure 2 and the literal

HoldsAt(equalT o(availability(v2), not avail), 50),

which is derived from the literals L9 and L16 and

the assumption A4 entail the negation of A3. In this

example, the inconsistency is caused by the failure of

the CSS service to send an R.C S S.Depart(v2,l2)

event to CBS following the event

Happens(Q.UIS.RelKey(v2,c2,l2), 28, (28, 28)).

Thus, according to A1, CBS invoked the operation

Available to mark the vehicle v2 as available (see

the literal L10 in ﬁgure 2). Subsequently, when

the operation Q.CIS.F indAvailable(l2,v) was

invoked in CIS (see literal L12), CIS reported v2

as an available vehicle. Note, however, that this

inconsistency could only be spotted after the event

signiﬁed by the literal L16 and by virtue of A4

(according to A4, a car whose key is released should

not be considered as available until the return of its

key).

One other case is that at t=54, the event L15 which

was generated due to A2 can be detected as unjus-

tiﬁed behavior. This is because this event can only

have been generated by A2. Note that, although in

this case CBS has functioned according to A2, one of

the conditions of this property is violated by the literal

Initiates(R.CIS.F indAvailable(l2

,v),equalTo(v

,v2), 51). This literal can be deduced

from A3, the literal L13, and the literal

HoldsAt(equalT o(availability(v2), not avail), 50).

The latter literal is deduced from L9 and L16 and

assumption A4.

5 RELATED WORK

Specifying and managing Web services interactions

can be challenging due to the autonomous and het-

erogenous nature of services providers . Below we

discuss some leading approaches that are most related

to our work.

Recent emerging workﬂow projects such as eFlow

(Casati et al., 2000), and CrossFlow (Hoffner et al.,

2001) focus on loosely coupled processes. However,

they lack a formal model for specifying and verifying

Web services. They also do not address the semantics

of composite events in Web services interactions.

Web service integration requires more complex

functionality than SOAP, WSDL, and UDDI can pro-

vide. The functionality includes transactions, work-

ﬂow, negotiation, management, and security. There

are several efforts that aim at providing such func-

tionality, for example, the recently released Busi-

ness Process Execution Language for Web Services

(BPEL4WS), which represents the merging of IBM’s

Web Services Flow Language (WSFL) and Mi-

crosof’s XLANG, is positioned to become the basis

of a standard for Web service composition. These lan-

guages are based on both SOAP, WSDL, and UDDI

basic stack, are complex procedural languages, and

very hard to implement and deploy. There are also

some proposals such as DAML-S, which is a part of

DARPA Agent Markup Language project that aims

at realizing the Semantic Web concept. However,

DAML-S is a complex procedural language for Web

service composition.

A part from this, lots of proposals originally aim at:

i) specifying web services at an abstract level using

formal description techniques and reasoning on them,

ii) using jointly abstract descriptions and executable

languages (BPEL), iii) developing web services from

abstract speciﬁcations. However, due to lack of space,

we just point the reader to the related work section of

paper (Ferrara, 2004).

On the other hand, to monitor the existence of spe-

ciﬁc patterns of events that indicate the violation of re-

quirements, the existing techniques use either special

purpose monitoring architectures such AMOS (Co-

hen et al., 1997) and FLEA (Feather et al., 1998)

that maintain event logs and offer proprietary event

AN EVENT-BASED MODEL FOR WEB SERVICES COORDINATION

pattern speciﬁcation languages, or store events in re-

lational databases and deploy standard SQL query-

ing for detecting requirement violations (Robinson,

2003). Typically, existing approaches assume that the

events to be monitored are generated by special state-

ments, which must be inserted in the code of a system

for this purpose . These statements may be inserted

in the source or compiled code of a system. The main

drawback of instrumentation is that it has to be done

manually. To alleviate this problem, Dingwall-Smith

and Finkelstein (Smith and Finkelstin, 2002) have de-

veloped an aspect oriented approach, in which sys-

tem providers specify instrumentation code in sepa-

rate classes, and deﬁne composition rules that deter-

mine how this code is to be merged with application

code.

A different approach has been developed by Robin-

son (Robinson, 2003). In this approach, requirements

are expressed in KAOS and analyzed to identify ob-

stacles for them. If an obstacle is observable (i.e., it

corresponds to a pattern of events that can be observed

at run-time), it is assigned to an agent for monitoring.

At run-time, an event adaptor translates web service

requests and replies expressed as SOAP messages into

events and a broadcaster forwards these events to the

obstacle monitoring agents which are registered as

event listeners to the broadcaster.

A common pattern of the related works discussed

above is that all of them suppose that all interact-

ing partners “know” one another in advance: together

they form an extended enterprize. However, our work

concerns situations where partners have to dynami-

cally ﬁnd one another, after which they participate in

short lived, ad hoc partnerships.

6 CONCLUSION

In this paper, we have presented a distributed event-

based architecture, that is grounded on a formal meta-

model stating its structural and dynamic characteris-

tics, and proving its reliability and efﬁciency for co-

ordinating Web services. The formal semantics of

the event composition operators is expressed in terms

of event calculus predicates. We have made use of

event calculus, especially because it is one of the best

known formalism for reasoning about events. The use

of this formal model allows the veriﬁcation of prop-

erties and the detection of inconsistencies both within

and between services. Current work aims at reﬁning

and extending the approach in various directions. In-

deed, we are working on the implementation of a tool

to operationalize the architecture that we have devel-

oped, and we intend to establish a strong link with

other process algebra, such as CSS (Milner 1989) and

ACP (Bergstra & Klop 1985) in order to import pro-

cess algebra speciﬁc veriﬁcation techniques such as

axiomatizations of behavioral equivalences.

REFERENCES

Casati, F., Ilnicki, S., Jin, L.-J., and Shan, M.-C. (2000).

An open, ﬂexible, and conﬁgurable system for ser-

vice composition. In WECWIS ’00: Proceedings of

the Second International Workshop on Advance Issues

of E-Commerce and Web-Based Information Systems

(WECWIS 2000), page 125, Washington, DC, USA.

IEEE Computer Society.

Cohen, D., Feather, M. S., Narayanaswamy, K., and Fickas,

S. S. (1997). Automatic monitoring of software re-

quirements. In ICSE ’97: Proceedings of the 19th

international conference on Software engineering,

pages 602–603, New York, NY, USA. ACM Press.

Feather, M. S., Fickas, S., Lamsweerde, A. V., and Ponsard,

C. (1998). Reconciling system requirements and run-

time behavior. In IWSSD ’98: Proceedings of the 9th

international workshop on Software speciﬁcation and

design, page 50, Washington, DC, USA. IEEE Com-

puter Society.

Ferrara, A. (2004). Web services: a process algebra ap-

proach. In ICSOC ’04: Proceedings of the 2nd inter-

national conference on Service oriented computing,

pages 242–251, New York, NY, USA. ACM Press.

Hoffner, Y., Ludwig, H., Grefen, P., and Aberer, K. (2001).

Crossﬂow: integrating workﬂow management and

electronic commerce. SIGecom Exch., 2(1):1–10.

Kowalski, R. and Sergot, M. J. (1986). A logic-based calcu-

lus of events. New generation Computing 4(1), pages

67–95.

Lemahieu, W., Snoeck, M., Michiels, C., and Goethals,

F. G. (2003a). An event based approach to web service

design and interaction. In APWeb, pages 333–340.

Lemahieu, W., Snoeck, M., Michiels, C., Goethals, F. G.,

Dedene, G., and Vandenbulcke, J. (2003b). Event

based web service description and coordination. In

WES, pages 120–133.

Pietzuch, P. R., Shand, B., and Bacon, J. (2003). A frame-

work for event composition in distributed systems. In

Middleware, pages 62–82.

Robinson, W. N. (2003). Monitoring web service require-

ments. In RE ’03: Proceedings of the 11th IEEE In-

ternational Conference on Requirements Engineering,

page 65, Washington, DC, USA. IEEE Computer So-

ciety.

Smith, A. D. and Finkelstin, A. (2002). From requirements

to monitors by way of aspects. In Proceedings of the

1th International Conference on Aspect Oriented Soft-

ware Development.

Spanoudakis, G. and Mahbub, K. (2004). Requirements

monitoring for service-based systems: Towards a

framework based on event calculus. In ASE ’04: Pro-

ceedings of the Automated Software Engineering, 19th

International Conference on (ASE’04), pages 379–

384, Washington, DC, USA. IEEE Computer Society.

WEBIST 2006 - INTERNET TECHNOLOGY