MODELLING WEB SERVICES INTEROPERABILITY
S. Haddad
∗
and T. Melliti
∗
and P. Moreaux
∗ +
and S. Rampacek
+
(∗)LAMSADE (+)LERI-RESYCOM
Université Paris Dauphine, France Université de Reims Champagne-Ardenne, France
Keywords:
Web service, Algebra of timed processes, Timed Labelled Transition systems, Timed automata, Synthesis
algorithm
Abstract:
With the development of the semantic Web, the specification of Web services has evolved from a “remote
procedure call” style to a behavioral description including standard constructors of programming languages.
Such a transformation introduces new problems since traditional clients will not be able to interact with these
sophisticated services. In this work, we develop a generic agent capable to fully control the interaction process
with a Web service given its XLANG behavioral description (XLANG being one of these languages). At first,
we give an operational semantic to XLANG in terms of timed transition systems. Then we define a relation
between two communicating systems which formalizes the concept of a correct interaction and we propose
an algorithm which either detects ambiguity of the Web service or generates a timed deterministic automaton
which controls the agent behavior during the interaction with the service. Starting from these theoretical
developments we have built a platform which ensures to a user the correct handling of any complex Web
service dynamically discovered through the Web.
1 INTRODUCTION
Web services are “self contained, self-describing
modular applications that can be published, located,
and invoked across the Web" (Tidwell, 2000). They
are based on a set of independent open platform stan-
dards to reach a high level of acceptance. Web ser-
vices framework is divided into three areas - com-
munication protocol, service description, and ser-
vice discovery - and specifications are being devel-
oped for each one: the "Simple Object Access Pro-
tocol" (SOAP)(SOAP, 2000), which enables commu-
nication among Web Services, the "Universal De-
scription, Discovery and Integration" (UDDI)(UDDI,
2002), which is a registry of Web Services descrip-
tions and the "Web Services Description Language"
(WSDL)(WSDL, 2001), which provides a formal,
computer-readable description of Web services. The
latter describes such software components by an in-
terface listing the collection of operations that are
network accessible through standard XML messaging
(CaudWell and al, 2001). This description contains all
information that an application needs to invoke such
as the message structure, the response structure and
some binding information like the transport protocol,
the port address, etc.
However simple operation invocation is not suffi-
cient for some kind of composite services. They re-
quire in addition a long-running interaction derived
by an explicit process model. This kind of services
may often be encountered in two cases. At first when
a web service is developed as an agent, it is composed
by a set of accessible operations and a process model
which schedules the invocation to a correct use of the
service. Secondly, facing to the capability limits of
Web services, composite services may be obtained by
aggregating existing Web services in order to create
more sophisticated services (and this in a recursive
way).
In order to deal with the behavioural aspects of
complex services, some industrial and academic spec-
ifications languages have been introduced such as
WSFL (Bechhofer and al, 2001), XLANG (Thatte,
2001), WSCL (WSCL, 2002) and more recently
BPEL4WS and DAML-S (Ankolekar and al, 2001).
Each of them is directly based on top of WSDL. They
propose different schemas to glue such services op-
erations according to a process model(Staab et al.,
2003). Such specification languages were adopted
287
Haddad S., Melliti T., Moreaux P. and Rampacek S. (2004).
MODELLING WEB SERVICES INTEROPERABILITY.
In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 287-295
DOI: 10.5220/0002648802870295
Copyright
c
 SciTePress

by tools such as eFlow, SCET
1
for supporting the
specification of the composition. A composition tool
is mostly defined by three components: a composi-
tion module which offers an intuitive interface to plan
Web services (data and control flows), an execution
entity which controls the services invocation accord-
ing to the specification model and finally an efficiency
evaluator(Casati et al., 2000)(Chandrasekaran et al.,
2003).
While composite services are recursively consid-
ered as Web services, they introduce new problems
since traditional clients will not be able to assure
interoperability and sophisticated interaction proto-
cols. Facing with the increasing complexity of the
behaviour of such services, the need of a tool for user
assistance in interaction processes becomes a neces-
sity.
In this work, we develop a platform capable to fully
control the interaction process with a Web service
given its process model specification. This work is es-
sentially based on a previous paper which focuses on
algorithmic aspect(Melliti and Haddad, 2003). Build-
ing such platform raises the following two issues: the
first one concerns semantics and algorithmic aspects
whereas the second one is related to technological as-
pects.
Since our goal is to produce a client behaviour
which correctly interacts with the service, we have
to formally define such an interaction. But this re-
quires beforehand to specify a formalism of represent-
ing the service and the client behaviour; composite
Web service behaviour may be represented in a vari-
ety of ways. While digraphs have been used widely to
model business processes (Casati et al., 2000), other
models like Petri nets (W. Aalst and Houben, 1994),
activity/state charts are also being employed. In our
system, we represent the behaviour of a Web service
process by a timed transitions system. The timed
transitions system models a communicating system
where the actions are mainly message exchanges and
time passing. In order to design a client behaviour
synthesis algorithm, we propose an interaction rela-
tion between two communicating systems which for-
malizes the concept of a correct interaction. Let us
briefly explain why the two main ones - the language
equivalence and the bisimulation equivalence - do not
match our needs. The language equivalence is un-
able to express the different branching capabilities of
the systems since it does not require an equivalence
relation between the intermediate states of the two
systems. The bisimulation equivalence does not take
into account the different nature of the events: in an
asynchronous communicating system the sending of
a message is an action whereas the reception is a re-
action. Thus the interaction relation that we introduce
1
it uses WSFL for dynamic Web services Composition
can be viewed as a bisimulation relation modified in
order to capture the nature of the events.
In addition to the theoretical difficulties we have
solved, we have also faced technical difficulties dur-
ing the development and execution of such compos-
ite services. Indeed the existing technologies for
Web services have two drastic restrictions on inter-
action models. The first one refers to the synchronous
and asynchronous nature of the interaction and the
second one concerns the difference between targeted
interaction like RPC and message oriented interac-
tion(B. Benatallah and Rabhi, 2001)(Curbera et al.,
2001). Our platform supports all interaction patterns
such as centralized and decentralized execution, mes-
sage oriented and RPC model, synchronous and asyn-
chronous interaction. However in the asynchronous
interaction mode, the platform only supports Web ser-
vices using a Java XML message provider. Let us note
that a technical solution bridging the JAXM which
other asynchronous interaction providers is possible
but it is out of the scope of the present work.
The balance of the paper is the following one. At
first, we define a formal semantic for a Web service
description language as a timed transitions system.
Then we propose a relation between two communicat-
ing transition systems which formalizes the concept
of a correct interaction between two processes. Based
on this relation, we present a client behaviour syn-
thesis algorithm which either produces a timed transi-
tions system for scheduling a correct interaction with
the service or detects the ambiguity of the service
specification. Afterwards, we focus on the platform
specification and implementation. More precisely, we
describe the different steps of the process which binds
our client with a composite Web service. We also de-
tail the components of our platform. Then we present
an illustrative example. Finally we discuss our ap-
proach and we give future improvements of this work.
2 A FORMAL SEMANTIC FOR
XLANG
XLANG is an XML block-structured specification
which offers a set of flow control primitives in order
to define the process model of the Web service. The
flow control primitives organize the operation execu-
tion exactly like the different primitives that we meet
in programming languages. An XLANG description
is always built on one or more WSDL description
which supplies a set of operations. It uses their oper-
ations as the basic elements in order to construct the
processes. An XLANG process is built by applying
control primitives on operations and XLANG subpro-
cesses. Every flow control primitive represents a spe-
cific execution order model to the XLANG processes
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
288

and the WSDL operations according to a specific se-
mantic. In addition to flow control primitive XLANG
offers a set of primitives to structure the processes or-
ganization by defining an execution context for a set
of processes or transactions. We have chosen to deal
with the main constructors of this language. The for-
gotten ones either has an unclear semantic or are of
minor interest. For instance we handle the delayFor
constructor and skip the delayUntil since it is unusual
to specify a fixed date in a service. Rather than fol-
lowing the XML syntax of XLANG, we have chosen
to delete the syntactic sugar in order to manage com-
pact expressions. We now present the models that we
use for the formalization of the XLANG semantics.
2.1 A quick overview of some formal
models
Algebra of timed processes XLANG provides a set
of operators describing in a modular way the observ-
able behaviour of a Web service. In fact, this approach
is close to the process algebra paradigm illustrated for
instance by CCS (Milner, 1989), CSP (C.A.R.Hoare,
1985) and ACP (Bergstra and Klop, 1984). The main
objective of the process algebra approach is to cope
with the complexity of the conception of parallel sys-
tems. In order to achieve this goal, the theoretical
developments related to a process algebra generally
consists in four steps(Lee et al., 1994). At first one
defines a set of operators and syntactic rules for con-
structing processes (e.g. what we have done in the
previous subsection). Then one associates to each op-
erator a set of semantic rules which assign to a pro-
cess a behavioural interpretation. In order to compare
different processes, one introduces some equivalence
relations and congruences which express that two pro-
cesses (or components) have a similar behaviour w.r.t.
to different criteria. At last one develops algorithms
which decide the equivalence of two processes, work-
ing at the syntactical level (e.g. via a set of algebraic
laws) or at the semantical level (e.g. with techniques
like model-checking).
Since time is an important issue in such systems,
the process algebra model has been enlarged by in-
troducing discrete time passing. The discrete time
models are usually defined by a special transition rep-
resenting one unit time passing(Nicollin and Sifakis,
1991). Thus it appears that the syntactic features of
XLANG make it a good candidate to be an algebra of
timed processes. Beforehand, we give the elements
necessary to this semantic.
Labelled Transition System A labelled transition
system is an oriented graph where the nodes represent
the possible states of the system (with an initial state)
and the arcs represent the state transitions. Each arc is
labelled by the action whose occurrence has triggered
this transition. Depending on the process algebra lan-
guage, some labels have a special meaning. We will
detail our alphabet later.
Definition 1 A labelled transition system LT S is de-
fined by a tuple LT S =(S, L, →,s
0
) where:
• S is a set of states with s
0
∈ S the initial state
• L is a finite set of labels
•→⊆S × L × S is the transition relation
Transition rules A LT S is the representation of the
behaviour of a process. The states of the process are
simply the current process after some part of an ex-
ecution. To each operator op, one associates a set of
transition rules which define the possible behaviour of
a process whose outer constructor is op. Let us sup-
pose that we want to define a rule [op
x
] for a generic
process P = op(P
1
,P
2
,...). At first, we have a
boolean expression over some potential transitions of
selected components of P : Bexp({P
o(i)
α
i
−→ P

o(i)
}).
This condition is enforced by a second condition on
the occurring labels denoted guard({α
i
}). If the two
conditions are fulfilled then a state transition for P is
possible where the label Lexp({α
i
}) is an expression
depending on the labels of sub processes transition
and the new state is an expression Nexp(P, {P

o(i)
})
depending on the original process and the new sub
processes. Below, a generic rule is presented with the
usual style.
[op
x
]:
Bexp({P
o(i)
α
i
−→ P

o(i)
})
P
Lexp({α
i
})
−→ Nexp(P, {P

o(i)
})
where guard({α
i
})
2.2 Semantic rules for XLANG
In the sequel, we will complete the XLANG algebra
with an operational semantic as the first step for the
development of our platform. Here we describe the
events of a LTS associated to an XLANG specifica-
tion:
• The set of types of messages will be denoted M .
There are two events associated to a message m:
the emission denoted by !m and the reception de-
noted by ?m. We also denote !M = {!m |m ∈ M}
and ?M = {?m |m ∈ M} and the joker character
∗ may be substituted by ! or ?.
• Since the service may evolve in an unobservable
way (e.g. the evaluation of a condition) we intro-
duce τ, the internal action.
• Since XLANG takes into account the time, χ de-
notes one unit time passing. We have chosen to rep-
resent time passing by units because the time con-
straints of a Web service are generally "soft" and
thus the discretization of time is a valid abstraction.
MODELLING WEB SERVICES INTEROPERABILITY
289

• The exception event set of XLANG is denoted by
E.
• In order to control that the client correctly detects
the end of the service, we introduce
√
the termina-
tion event. This action will also simplify the defi-
nition of the operational semantic.
The basic processes The process ?o[m] (which cor-
responds to the input operation of WSDL) consists in
receiving a message of type m. The process !o[m]
(which corresponds to the notification operation of
WSDL) consists in sending a message of type m.We
consider only these two types of WSDL operations.
The two other types can be built with the sequence
constructor (see below). The raise process r[e] sim-
ply raises an exception e which must be handled in
some way (see below the context process). Since we
consider that due to internal or external conditions,
any basic action of a process can be delayed, the be-
haviour of the basic processes is specified by the fol-
lowing rules:
∗o[m]
χ
→∗o[m] and ∗o[m]
∗m
→ empty where ∗∈{!, ?}
and r[e]
e
→ empty
The sequence process and the empty process The
process P ; Q executes the process P followed by the
process Q. Since the operator “;” is associative, we
safely restrict the number of operands to two pro-
cesses. The sequence process acts at its first subpro-
cess while this process does not indicate its termina-
tion. In the latter case, the sequence process becomes
the second process in a silent way.
P
a
→ P

∧¬P
√
→ P

P ; Q
a
→ P

; Q
where a =
√
and
P
√
→ P

P ; Q
τ
→ Q
The empty process empty does nothing; it is sim-
ilar to the skip instruction of some languages. It can
also be interpreted as the neutral element for the oper-
ator “;”. It is different from the null process 0. After
some units of time it indicates its termination and then
becomes 0.
empty
χ
→ empty and empty
√
→ 0
The switch, the while and the all process The pro-
cess switch({c
i
,P
i
}
i∈I
}) chooses to behave as one
process among the set {P
i
}. Each branch of its ex-
ecution is guarded by an internal condition denoted
by a qualified name (c
i
). The conditions are evalu-
ated w.r.t. the order of their appearance in the de-
scription. However since the client has no mean to
predict the choice of the service, this order is irrel-
evant. The main consequence is that from the point
of view of the client, this choice is non deterministic.
The switch process becomes one of its sub-processes
in a silent way. Let us note that we have implicitly
supposed that at least one condition is fulfilled. In the
other case, it is enough to add the process empty as
one of the sub-processes.
∀i ∈ Iswitch({c
i
,P
i
}
i∈I
)
τ
→ P
i
The process while(c, P ) iterates an inner process
while an internal condition c is satisfied. Like the
switch process, the while process evaluates in a
silent way its condition. Thus we have two rules de-
pending on this internal evaluation.
while(c, P )
τ
→ P ; while(c, P ) and while(c, P )
τ
→ empty
The process all({P
i
}
i∈I
}) simultaneously acti-
vates a set of processes {P
i
}. XLANG does not
include synchronization primitives since it consid-
ers synchronization as an internal action unobserv-
able by the client. This parallel execution is similar
to a “fork join” in the sense that the combined pro-
cess finishes its interaction when all the sub-processes
have achieved their execution. The subprocesses of a
all process act independently except for two actions.
They simultaneously let pass a unit of time and they
simultaneously indicate their termination. In the latter
case, the all process becomes the null process.
∃j ∈ IP
j
a
→ P

all({P
i
}
i∈I
)
a
→ all({P
i
}
i∈I\{j}
∪ P

)
where a/∈{χ,
√
}
∀i ∈ IP
i
χ
→ P

i
all({P
i
}
i∈I
)
χ
→ all({P

i
}
i∈I
)
and
∀i ∈ IP
i
√
→ P

i
all({P
i
}
i∈I
)
√
→ 0
The pick process and the context process The
pick process pick[{m
i
,P
i
}
i∈I
, {d, Q}, {e
j
,R
j
}
j∈J
]
manages a condition race between sub-processes
based on timing or triggers. It contains one or more
event handler sub-blocks. Each event handler asso-
ciates a specific service behaviour to an occurrence of
the corresponding event. The possible kinds of event
are the reception of an expected message (m
i
), the
triggering of a time-out whose duration is expressed
w.r.t. to some time unit by an integer d (delay actions)
or the raising of some exception e
j
. When some event
happens the service behaves as the associated process
(P
i
, Q or R
j
). The “time” event introduces a watch-
dog for reception of messages. There is at most one
such event in the construction. The specification of
catching processes is authorized only if the pick pro-
cess is the exception part of a context process.
The context process [P, E] has different roles but
here we only describe the handling of exceptions.
Each context contains an (optional) exception pro-
cess E which is a pick process. The exception pro-
cess has catching sub-processes which intercept the
raised exceptions during the current context execu-
tion or during a nested one if the raised event has
not been previously catched. The “time” action of
the exception block is a watchdog for the context
execution delay. Similarly, cancelling or aborting
messages can be handled by this construction. Due
to space considerations, we only give a semantic to
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
290

the context process and then we will informally ex-
plain the semantic of a pick process when it is not
an exception process. In the following rules, E the
exception process is an abbreviation for the process
pick({m
i
,P
i
}
i∈I
, {d, Q}, {e
j
,R
j
}
j∈J
).
This rule expresses that the exception block may be
triggered by the reception of the expected messages.
[P, E]
?m
i
→ P
i
The next rules specify that the time elapses under
the control of the watchdog.
P
χ
→ P

∧¬P
√
→ P

[P, E]
χ
→ [P

,pick({m
i
,P
i
}
i∈I
, {d − 1,Q}, {e
j
,R
j
}
j∈J
)]
where d>1
P
χ
→ P

∧¬P
√
→ P

[P, E]
χ
→ Q
where d =1
Let us note that we can adapt the three previous
rules in order to determine the behaviour of a pick
process which is not an exception process. The adap-
tation consists in deleting the conditions related to P.
The following two rules handle the case of a raised
exception depending on whether the context process
has a sub-process to handle this exception. If it is not
the case the exception is “transmitted” to the includ-
ing context block.
P
e
j
→ P

[P, E]
τ
→ R
j
and
P
e
→ P

[P, E]
e
→ empty
where e ∈ E\{e
j
}
j∈J
The last rules describe the actions of P inside the
context.
P
√
→ P

[P, E]
τ
→ empty
and
P
a
→ P

[P, E]
a
→ [P

,E]
3 GENERATION OF AN
INTERACTING CLIENT
Using the previous rules, starting from a XLANG
specification we develop the LTS related to its be-
haviour. Although we will not prove it here, this LTS
has a finite number of states.
We want to specify the behaviour of an agent able
to correctly interact with the service. Obviously we
choose the formalism of the labelled transition sys-
tems for the representation of this behaviour. We re-
mark that this LTS must be deterministic in order to
be implementable.
Now we proceed in two steps. At first, we need to
formally define what is a correct interaction between
two LTS. Once this relation is defined, we develop an
algorithm producing the LTS of the client behaviour
if such a behaviour exists or detecting the ambiguity
of the Web service.
3.1 An interaction relation
As usual in the LTS formalism, we define an observ-
able transition relation between states given by s
a
⇒ s

iff s
τ
∗
aτ
∗
→ s

and s

⇒ s

iff s
τ
∗
→ s

. Moreover we
suppose that the exception events are not observable
in the LTS of the service. If it is the case, it means
that the service does not catch an exception and then
must be modified.
We now derive the interaction relation from general
considerations. Let us focus to some instant of the ex-
ecution. If one LTS is able to send a message (action
!m), the other one must be able to receive this mes-
sage (action ?m). If one LTS is able to let the time
pass (action χ), the other one must also be able to let
the time pass (action χ). At last, if one LTS is termi-
nating (action
√
), the other one must also be able to
terminate (action
√
).
The subtle point is about the reception of a mes-
sage. Suppose that one LTS expects the reception of
?m, does it mean that the other one is able to send this
message? The answer is not necessary since the latter
LTS may evolve in an indistinguishable way from one
state to two states, one where it is able to send m and
the other one where it is not. However we require that
in the other state, it is able to send a message in order
to avoid an infinite waiting of the first LTS.
We introduce the following notation ?m
c
=!m,
!m
c
=?m and ∀a/∈{!m}
m∈M
∪{?m}
m∈M
a
c
= a.
Definition 2 Let LT S
1
=(S
1
,L
1
, →
1
,s
01
) and
LT S
2
=(S
2
,L
2
, →
2
,s
02
) be two labelled transition
systems. Then S
1
and S
2
correctly interact iff ∃∼
⊆ S
1
× S
2
such that:
• s
01
∼ s
02
•∀s
1
,s
2
such that s
1
∼ s
2
– Let a/∈{?m}
m∈M
,if∃s
1
a
=⇒
1
s

1
then
∃s
2
a
c
=⇒
2
s

2
with s

1
∼ s

2
and if ∃s
2
a
=⇒
2
s

2
then ∃s
1
a
c
=⇒
1
s

1
with s

1
∼ s

2
– Let m ∈ M,ifs
1
?m
=⇒
1
s

1
then
∗∃s
−
2
w
=⇒
2
s
2
, ∃s
−
2
w
=⇒
2
s
+
2
, ∃s
+
2
!m
=⇒
2
s

2
with
s
1
∼ s
+
2
and s

1
∼ s

2
where w is a word
∗∃s
2
!m

=⇒
2
s

2
– Let m ∈ M,ifs
2
?m
=⇒
2
s

2
then
∗∃s
−
1
w
=⇒
1
s
1
, ∃s
−
1
w
=⇒
1
s
+
1
, ∃s
+
1
!m
=⇒
1
s

1
with
s
+
1
∼ s
2
and s

1
∼ s

2
where w is a word
∗∃s
1
!m

=⇒
1
s

1
3.2 The synthesis algorithm
The algorithm builds the deterministic LTS (LT S
1
)
following a kind of determinization of the LTS
MODELLING WEB SERVICES INTEROPERABILITY
291

(LT S
2
) of the service. Each state of the potential
client is associated to a subset of states of the service.
There is a stack of couples (s
1
,S

2
) to be processed
where s
1
is a new state of the client and where S

2
is a
subset of states of the service which are related to s
1
via the interaction relation. Let us describe one step
of the algorithm.
• At first, one completes S

2
with

=⇒
2
transitions.
• If a state of the client s

1
is already associated to S

2
then one redirects all the input edges of s
1
to s

1
and
one deletes s
1
.
• Otherwise for each s
2
a
=⇒
2
s

2
with a and s
2
∈ S

2
,
one builds a new vertex s

1
and a new edge s
1
a
c
=⇒
1
s

1
and one stacks (s

1
,S
∗
2
) where S
∗
2
= {s

2
|∃s
2
∈
S

2
, ∃s
2
a
=⇒
2
s

2
}
• Let a/∈{?m}
m∈M
such that s
1
a
=⇒
1
s

1
, if there
is a s
2
∈ S

2
with s
2
a
c
=⇒
2
s

2
then stop and return
“service ambiguous”.
• Let s
1
?m
=⇒
1
s

1
, if there is a s
2
∈ S

2
with s
2
!m

=⇒
2
s

2
then stop and return “service ambiguous”.
The algorithm starts with the couple of initial states
(s
01
,s
02
) in the stack and stops either when the stack
is empty (i.e. the client has been built) or when it has
detected the ambiguity of the service. Again due to
space considerations, we do not include the correct-
ness proof of the algorithm.
4 PLATFORM ARCHITECTURE
AND IMPLEMENTATION
Here we describe the architecture of our platform for a
dynamic management of clients interacting with Web
services. The figure 1 presents the main modules
of our system: the service’s behaviour generator, the
client’s behaviour generator, the interaction controller
and the communication module.
4.1 The service’s and the client’s
behaviour generators
The construction starts from the description of the
service available through its WSDL file. It is made
of three steps: the transformation of the WSDL (and
XLANG) file describing the service into a DOM tree,
the extraction of relevant information from this DOM
tree and the computation of the LTS corresponding to
the observable behaviour. Let us note that as speci-
fied in the previous sections, we do not care of data
nor communication support and all activities except
message exchange and time passing are modelled as
internal (silent) actions.
Service TIOTS
generator
Registry of
services Web
Xlang,WSFL, BPEL4WS etc.
Service TIOTS
Communication modules
Interaction controller
Data
Communication modules
publish
Locate the elementary services
composition
Composite
Service
execution
controller
Web
Services
Client TIOTS synthesis
module
Client TIOTS
messages
Service TIOTS
generator
Registry of
services Web
Xlang,WSFL, BPEL4WS etc.
Service TIOTS
Communication modules
Interaction controller
Data
Communication modules
publish
Locate the elementary services
composition
Composite
Service
execution
controller
Web
Services
Client TIOTS synthesis
module
Client TIOTS
messages
Figure 1: The platform architecture
We first transform the text file of the service de-
scription into a DOM tree using an XML parser. Then
we do a first analysis of the DOM tree in order to ex-
tract information on the links between WSDL oper-
ations and XLANG actions and on input and output
messages. After this analysis, we generate the LTS
guided by a recursive traversal of the DOM tree since
the structure of this tree is close to the modular con-
struction of an XLANG specification. However the
two way message operations in the description lan-
guage must be considered as a sequence of one way
messages.
The generator of the client applies the algorithm
described in the subsection 3.2 with the LTS of the
service as input. Once the LTS of the client is built, it
applies a kind of factorization of states. Indeed since
the handling of time passing leads to numerous states
different only w.r.t. by the timing constraints, the fac-
torization tries to incorporate explicit timers inside the
LTS in order to aggregate states. The result is in fact
a timed automaton. Due to space considerations, we
do not detail the factorization algorithm. We illustrate
on the following toy example the generation process:
S =
def
[P, E]
P =
def
?op
1
; r[e
1
]
E =
def
pick({e
1
, !op
2
}, {2, !timeout})
Figures 2 and 3 respectively present the service and
client LTS generated by our platform.
4.2 Interaction controller
This component takes as input the client automaton
and a set of binding information from the XLANG
description of the service (i.e. WSDL files on which
is based the composite service). For each interaction
session (initialized by the user), the interaction con-
troller schedulers the user actions during the interac-
tion. It generates a client application instance for each
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
292

start_context
1
chi
aft_!op1
?op1
bef_!timeout
chi
aft_!op1(1)
?op1
raise_E:e1
tauchi
aft_!timeout
!timeout tau
chi
bef_!op2
tau catch E:e1
chi
aft_!op2
!op2
chi
end
tau
tau
chi
Figure 2: An example of a service LTS
start_context
1
chi
aft_?op
!op
!op
bef_!timeout
chi
ch
i
aft_?op2
?op2
chi
end_timeout
?timeout
end
ticktick
Figure 3: The corresponding client LTS
service instantiation. The application instance is com-
posed by:
• a copy of the client behaviour automaton,
• a set of contextual variables,
• a J AVA RM I
2
client for each WSDL service.
According to the service binding information the
interaction controller links each client application to
a communication modules. The link consists in as-
sociating each sending action to the appropriate com-
munication service and routing the message listener
to the correct receiving action in the automaton in-
stance. The components of the communication mod-
ule vary according to the service execution and inter-
action models. For synchronous services, centralized
or decentralized, the controller generates a proxy for
every WSDL service involved in the XLANG descrip-
tion. In the case of an asynchronous service the con-
troller launches the client application instance over a
messaging provider in order to assure a peer to peer
interaction between the client and the service. At
the present time, the Web service technologies sup-
port more synchronous interaction than asynchronous
ones. Actually, in our platform we support only asyn-
chronous Web services implemented using JAVA API
for XML Messaging as the messaging provider. Note
that a possibility to bridge the JAXM to other com-
munication platforms exist but is very complex.
4.3 Communication module
The interaction controller requests the communica-
tion module services in order to send and receive mes-
sages. Depending on the interaction implementation
type (synchronous or asynchronous and centralized
or decentralized) the interaction controller uses the
binding information included in the services descrip-
tion file to instantiate the communication tools. The
communication model is instantiated at runtime. We
have developed two APIs which either generate client
proxies for WSDL RPC services or instantiate a JAVA
XML messaging provider (JAXM) for message ori-
ented services.
The JAXM (WST, 2003) enables to write business
applications that support messaging standards based
on the SOAP1.1 and SOAP with Attachments spec-
ifications. It may additionally support one or more
SOAP message Profiles, we use for our platform the
SOAP Rooting Protocol profile. The JAXM offers a
message provider which is a Web application enables
sending and receiving synchronous or asynchronous
SOAP messages. Both the client and the services
must support message provider in order to realize an
asynchronous communication.
2
Remote Method Invocation
MODELLING WEB SERVICES INTEROPERABILITY
293

Figure 4: Interaction models supported by the platform
To create an application client that interact within
an asynchronous composite Web services the interac-
tion Controller launches the client automaton and its
context variable (the application instance thread) in
a JAXMServlet and implements the oneWaylistener
which root the message to application instance based
on the reference correlation. The thread application
must obtain the service message provider endpoint
and its provider message in order to send and receive
SOAP messages. In the figure 4 we present the differ-
ent communication models supported by the tool.
5 SCENARIO
In order to test our platform, we have developed a
composite Web service. The service offers a quiz
game. We orchestrated the operations of an existent
Web service and we introduced some kind of time re-
strictions. The Web service offers three operations:
• "getRandomQuestion" returns a multiple choice
question.
• "getRandomQuestionBydifficulty" offers to the
user the possibility to choose the difficulty of the
question.
• "checkQuestionResponse" takes as parameter the
user response with the question reference and re-
turns true or false.
Each user begins the game by sending his identi-
fier. In a limited amount of time, the user answers
to a maximum number of questions. In every cycle,
the user chooses between selecting a random ques-
tion or specifying the difficulty level. The time out
triggers a new question cycle. The service computes
a user score based on the difficulty level and the user
response. At the end of the game, the user receives
his score and his rank in the hole classification. The
User response
Service genrated question
Game timeOut indication
Question timeOut indication
Time
Service response
End of the interaction
Figure 5: A sample of the service execution sequence
composite service is developed as message oriented
service while the existing service is an RPC message.
We used the JAXM and SOAPRP profile to support
asynchronous interaction. In the figure 5 we present
the sequence of windows generated by the interaction
controller for user assistance. Both the formal seman-
tics and corresponding algorithms are transparent to
the user.
6 CONCLUSION
In this work we have coped with the problem of han-
dling a complex Web service given its XLANG be-
havioural description. We have given an operational
semantic to XLANG in terms of timed transition sys-
tem and formalized the concept of a correct interac-
tion between two communicating systems. Our key
algorithm either detects ambiguity of the Web service
or generates a timed deterministic automaton which
controls the agent behaviour during the interaction
with the service. Starting from these theoretical de-
velopments we have built a platform which ensures to
a user the correct handling of any complex Web ser-
vice dynamically discovered through the Web.
We are now pursuing this work into two comple-
mentary directions. On the one hand, an implicit hy-
pothesis of our synthesis algorithm is that the medium
is a perfect one. We are looking for an algorithm
which takes into account an expected behaviour of
the medium. On the other hand, given some task re-
quested by the user, we want to generate a client si-
multaneously interacting with different services in or-
der to improve the quality of the results. These par-
allel interactions could be considered as a dynamical
composition of services.
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
294

REFERENCES
Ankolekar, A. and al (2001). Daml-s : Semantic markup for
web services. In Proceedings of the International Se-
mantic Web Working Symposium (SWWS), Standford,
USA.
B. Benatallah, M. Dumas, M. F. and Rabhi, F. (2001). To-
wards patterns of web services composition. Tech-
nical report, Technical Report UNSW-CSE-TR-0111,
The University of New South Wales Sydney, Aus-
tralia. http://citeseer.nj.nec.com/correct/472153.
Bechhofer, S. and al (2001). Web services
flow language (wsfl 1.0). Technical re-
port, IBM Corporation. http://www-
4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.
Bergstra, J. and Klop, J. (1984). Process algebra for syn-
chronous communication. Information and Control,
60(1-3), pages 109–137.
C.A.R.Hoare (1985). Communicating sequential processes.
Prentice Hall.
Casati, F., Ilnicki, S., Jin, L., Krishnamoorthy, V., and Shan,
M. (2000). Adaptive and dynamic service compo-
sition in eflow. In Proceedings of the International
Conference on Advanced Information Systems Engi-
neering, pages 13–31, Stockholm, Sweden.
CaudWell, P. and al (2001). Service Web XML Profession-
nel. wrax, Paris.
Chandrasekaran, S., Miller, J. A., Silver, G. S., Arpinar,
B., and Sheth, A. P. (2003). Composition, perfor-
mance analysis and simulation of web services. Elec-
tronic Markets: The International Journal of Elec-
tronic Commerce and Business Media (EM)Web Ser-
vices EM Vol.13,No. 2.
Curbera, F., Nagy, W. A., and Weerawarana, S. (2001). Web
services : Why and how? OOPSLA 2001 Workshop
on Object-Oriented Web Services.
Lee, I., Bremond-Gregoire, P., and Gerber, R. (1994).
A process algebraic approach to the specification
and analysis of resource-bound real-time systems.
Proceedings of the IEEE, pages 158–171. cite-
seer.nj.nec.com/lee94process.html.
Melliti, T. and Haddad, S. (2003). Synthesis of agents for
web services interaction. International Conference
Electronic Commerce, workshop.
Milner, R. (1989). Communication and Concurrency. Pren-
tice Hall.
Nicollin, X. and Sifakis, J. (1991). The algebra of timed
process, atp: Theory and application. Technical re-
port, Technical Report RT-C26, Institut National Poly-
technique De Grenoble.
SOAP (2000). Simple object access protocol (soap)
1.1. Technical report, World Wide Web Consortium.
http://www.w3.org/TR/SOAP/.
Staab, S., van der Aalst, W., Benjamins, V. R.,
Sheth, A., Miller, J. A., Bussler, C., Maed-
che, A., Fensel, D., and Gannon, D. (2003).
Web services: Been there, done that? IEEE
Intelligent Systems: volume 18, pages 72–85.
http://www.tm.tue.nl/it/research/patterns/ieeewebflow.pdf.
Thatte, S. (2001). Xlang: Web services for busi-
ness process design. World Wide Web page.
http://www.gotdotnet.com/team/xml/wsspecs/xlang-
c/default.htm.
Tidwell, D. (2000). Web services - the web’s next revolu-
tion. IBM developerWorks.
UDDI (2002). Universal description, discovery and in-
tegration. Technical report, OASIS UDDI Spec-
ification Technical Committee. http://www.oasis-
open.org/cover/uddi.html.
W. Aalst, V. H. and Houben, G. (1994). Modelling work-
flow management systems with high-level Petri nets.
In Proceedings of the second Workshop on Computer
Supported Cooperative Work, Petri nets and related
formalisms, pages 31–50.
WSCL (2002). Web services conversation language (wscl)
1.0. Technical report, World Wide Web Consortium.
http://www.w3.org/TR/wscl10/.
WSDL (2001). Web services description language (wsdl)
1.1. Technical report, World Wide Web Consortium.
http://www.w3.org/TR/wsdl.
WST (2003). The java web services tutorial.
Technical report, Sun Microsystems, Inc.
http://www.alphaworks.ibm.com/tech/ettk/.
MODELLING WEB SERVICES INTEROPERABILITY
295