=Paper=
{{Paper
|id=Vol-494/paper-3
|storemode=property
|title=Web Services Synchronization in Composition Scenarios
|pdfUrl=https://ceur-ws.org/Vol-494/mallowawesomepaper3.pdf
|volume=Vol-494
|dblpUrl=https://dblp.org/rec/conf/mallow/YahyaouiMBB09
}}
==Web Services Synchronization in Composition Scenarios==
https://ceur-ws.org/Vol-494/mallowawesomepaper3.pdf
Web Services Synchronization in Composition Scenarios
Hamdi Yahyaoui1 , Zakaria Maamar2 , Jamal Bentahar3 , and Khouloud Boukadi4
1
KFUPM, Dhahran, KSA —- 2 Zayed University, Dubai, U.A.E —– 3 Concordia University, Montreal, Canada—–
4
École des Mines, Saint-Etienne, France
Abstract position design and development are bound to a specifica-
tion that describes, at design time, multiple elements such
This paper discusses Web services synchronization at the as execution order of component Web services, data de-
composition level. Synchronization aims at assisting in- pendencies between component Web services, and correc-
dependent parties coordinate their actions and thus, avoid tive strategies in case component Web services raise excep-
conflicts. Our previous work on synchronization primar- tions. At run time, the composition specification is trig-
ily focused on the component level and shed the light on gered, which means identifying and invoking component
two types of behaviors related to specifying Web services. Web services, overseeing their execution, coordinating their
The control behavior defines the business logic that under- actions, and initiating corrective strategies if needed. Dif-
pins the functioning of a Web service, and the operational ferent specifications related to Web services composition
behavior regulates the execution progress of this control be- currently exist such as BPEL (de facto standard) and WSCI.
havior by stating the actions to carry out and the constraints In term of execution, Web services composition can be
to put on this progress. Control and operational behav- structured along two types of orchestration [1]: centralized
iors continue to be used to specify composite Web services or peer-to-peer (P2P) (i.e., decentralized). On the one hand,
with respect to the orchestration schemas that these com- centralized orchestration like its name hints relies on a cen-
posite Web services have to comply with whether central- tralized module (e.g., BPWS4J) that coordinates and tracks
ized or peer-to-peer. As a result, various types of messages all the execution activities related to component Web ser-
to achieve synchronization are developed per type of orches- vices in terms of when to invoke them, what to expect out
tration schema. Experiments showing the use of these mes- of their invocation, what data they exchange, how to pass
sages are reported in this paper as well. on these data, just to cite a few. On the other hand, P2P or-
Keywords. Composition, Synchronization, Web service. chestration excludes the centralized module and promotes
direct interactions between component Web services. This
1 Introduction makes Web services aware of some of their direct acquain-
tances during composition, which means the necessity of
In [8] and [9], we investigated the synchronization issue empowering these Web services with appropriate knowl-
of (“isolated”) Web services independently of the composi- edge and mechanisms in order to support direct interactions.
tion scenarios in which these Web services could take part. eFlow [2] is an example of Web services-based systems that
This investigation shed the light on two types of behaviors adopts a centralized orchestration, whereas PCAP [10] is an
namely control and operational that were both used to spec- example of Web services-based systems that adopts a P2P
ify and exhibit the functioning of Web services. The control orchestration.
behavior illustrates the business logic of the functionality, This paper extends the synchronization initiative we re-
e.g., CarRental, of a Web service, while the operational port in [9] by leveraging this time our research findings
behavior frames the progress of executing the business logic and thoughts from the component to the composition lev-
of this Web service at run time. els. In [5], we applied the separation between control and
As the literature review points out [3], it is known that operational behaviors to model check orchestration-based
the “beauty” of Web services resides in their capacity to composite Web services. The control behavior is used to
be composed into high-level business processes known as extract the desired properties to be checked in the model of
composite Web services. Composition is suitable for users’ composite Web services captured by the operational behav-
requests that cannot be satisfied by any single, available ior. In this paper, our primary objective is to address the fol-
Web service, whereas a composite Web service obtained lowing issues per type of orchestration: what synchroniza-
by combining available Web services might be used. Com- tion mechanisms are required to set up, what messages im-
plement these mechanisms, how these messages are tracked its invitation of participation; there is no guarantee that the
during synchronization, how synchronization and execution component Web service is still part of a composition sce-
are interleaved, and how the correctness of these messages nario at time of invocation;
is proved. In this extended work, Web services are no longer “Trigger” action makes the composite Web service initi-
treated as isolated components but as integral components ate the execution of the component Web service;
of composition scenarios. Analyzing the synchronization “Audit” action makes the composite Web service monitor
of Web services at the composition level offers some di- the performance of the component Web service for assess-
rect benefits. First of all, it would be possible to dissociate ment purposes; service level agreements motivate the audit
the behaviors of Web services at the composite level from exercise;
the behaviors of these Web services at the component level. And, “retract&invite” action makes the composite Web
Second, it would be possible to track the interactions that service withdraw the component Web service from its com-
occur between the Web services from the component to the position due to poor performance for example. This yields
composite levels and vice-versa. Finally, it would be possi- into searching for another replacement Web service that will
ble to work out the necessary synchronization mechanisms be added to this composition.
per type of composition orchestration whether centralized In horizontal interactions, a P2P orchestration of Web
or P2P. services is implemented. Here, a component Web service
Section 2 discusses the commonalities and differences has the authority to carry out the following actions over a
between the component and composite levels and provides peer:
a running scenario. Section 3 reports on the synchroniza- “Invite” action makes the component Web service re-
tion work that was done at the component level. Section 4 quest the participation of the peer in the current composition
discusses synchronization at the composite level with focus scenario;
on the P2P schema. Prior to concluding in Section 6, some “Ping” action makes the component Web service check
experimental details are given in Section 5. the liveness of the peer that accepted its invitation of partic-
ipation; there is no guarantee that the peer is still part of a
2 Background composition scenario at time of invocation;
And, “trigger” action makes the component Web service
initiate the execution of the peer.
2.1 Component vs. composition levels
Compared to the vertical interactions in the centralized
orchestration, “audit” and “retract” actions are excluded
In a composition scenario, we classify interactions that from the horizontal interactions in the P2P orchestration.
involve composite and component Web services into ver- Essentially, this is due to the challenges that are posed when
tical (from composite Web service to component Web ser- tracking the performance of Web services and replacing
vice) and horizontal (from component Web service to an- them if needed. Not all providers would like to have their
other component Web service). By establishing an interac- Web services audited by the Web services of other providers
tion session, the initiator of a message aims at making the for reasons that could be related to security, privacy, com-
recipient of this message behave and take actions according petitiveness, etc. In a centralized orchestration, providers
to the content of this message. In the following, we identify do not mutually interact with each other and might not even
the acceptable actions that a message initiator can execute know that they are parts of the same composition scenario.
over a potential recipient during vertical and horizontal in- The absence of “audit” and “retract” actions in a P2P or-
teractions. The objective of identifying these actions is to chestration sheds the light on the necessity of developing
facilitate the definition of the relevant synchronization mes- appropriate mechanisms that should take into account con-
sages that would be suitable per type of interaction. cerns like privacy and competitiveness. However, these
In vertical interactions, a centralized orchestration of mechanisms do not fall into the scope of this paper.
Web services composition is implemented. Here, a com-
posite Web service through the centralized module has the
2.2 Running scenario
authority to carry out the following actions over a compo-
nent Web service:
“Invite” action makes the composite Web service request Our running scenario concerns a university student who
the participation of the component Web service in its com- is in the process of organizing a cookout party to celebrate
position scenario1 ; his recent graduation. We identify hereafter the Web ser-
“Ping” action makes the composite Web service check vices along with their activities that will implement this
the liveness of the component Web service that accepted party’s logistics.
CateringWS: searches for and contacts catering compa-
1 Component Web services invitation is discussed in [6]. nies according to some criteria like allocated budget, num-
2
ber of expected guests, type of cuisine, etc. on, we qualify transitions in the behavior of a Web service
GuestWS: sends invitees invitations, keeps track of as intra-behavior. ¤
confirmed invitations, reminds late invitees for confirma- The control and operational behaviors of a Web ser-
tion, etc. vice are defined as instances of the behavior of this
PlaceBookingWS: looks for a place to host the cookout Web service (Definition 1). These two behaviors are
party, books the place, completes the necessary paperwork denoted by Bco = hSco , Lco , Tco , s0co , Fco i and Bop =
like payment, etc. hSop , Lop , Top , s0op , Fop i, respectively.
WeatherWS: checks weather forecast for the day of the
cookout party. In case of bad weather, the party takes place Example 1: Fig. 2 (a) is a state chart of the
at the student’s place. control behavior of WeatherWS. Several states like
In our initial synchronization project [9], state charts city-located (initial state), report-delivered
were selected to specify component Web services indepen- (final state), and search-canceled, and several
dently of any composition scenario (Fig. 2 (a)). For the transitions like (city-located, unavailable,
sake of compliance, we continue doing so when modeling search-canceled) are included in this state chart.
the specification of composition scenarios. However states In this transition example, city-located and
correspond this time to Web services taking part in these search-canceled are the source and target states,
scenarios (Fig. 1). respectively, and unavailable is the transition’s label.
Nice Confirmation Guest
WeatherWS weather
PlaceBookingWS booking
GuestWS confirmation
CateringWS
Bad weather Example 2: Fig. 2 (b) is another state chart that
illustrates this time the operational behavior of Weath-
Figure 1. Specification of the cookout party erWS. Similar to the control behavior, several states like
not-activated and suspended, and transitions like
3 Specification of Web services (compensated, rolling-back, not-activated)
and (activated, failure, aborted) are identified
3.1 Control and operational behaviors in this state chart.
The control behavior shows the business logic that un- In Fig. 2, the control and operational behaviors of a
derpins the functioning of a Web service with respect to Web service include different finite sequences that connect
its functionality. A business logic is domain-application states and transitions together. We refer to these sequences
dependent (e.g., healthcare) and changes from one case as paths and define them as follows:
study to another according to various requirements such as
user (e.g., minimum age to submit an application), security Definition 2 (Path in Web Service Behavior). A path pi→j
(e.g., type of encryption algorithm), etc. in the behavior B of a Web service is a finite sequence
The operational behavior guides the execution progress of states and transitions starting from state si and ending
of the business logic of a Web service. To this end, li
at state sj and is denoted as follows: pi→j = si −→
this behavior relies on a specific number of states, which li+1 lj−1
are activated, not-activated, done, aborted, si+1 −→ si+2 . . . sj−1 −→ sj such that ∀k ∈ {i, j − 1} :
suspended, and compensated. These states are re- (sk , lk , sk+1 ) ∈ T (exponents in state names are here given
ported in the field of transactional Web services [11] and for notational purposes only). ¤
common to a certain extent to all Web services (and to any
software application) regardless of their functionalities, ori- Example 3: Let l1 (resp. l2 ) = start (resp.
gins, and locations. l1
commitment) in Fig. 2 (b). not-activated −→
As mentioned in Section 1, the control and operational l2
behaviors of a Web service are modeled using state charts. activated −→ done is a path in the operational be-
This exercise of modeling is hereafter interleaved with some havior of WeatherWS.
formal definitions and illustrative examples.
Definition 1 (Web Service Behavior). The behavior of a 3.2 Both behaviors in interaction
Web service is a 5-tuple B = hS, L, T , s0 , Fi where: S
is a finite set of state names; s0 ∈ S is the initial state; We pointed out that the operational behavior guides
F ⊆ S is a set of final states; L is a set of labels; and the performance of the control behavior of a Web ser-
T ⊆ S × L × S is the transition relation. Each transition vice. This guidance requires bringing both behaviors to-
t = (ssrc , l, stgt ) consists of a source state ssrc ∈ S, a tar- gether. For instance, done state that a Web service takes
get state stgt ∈ S, and a transition label l ∈ L. From now on in the operational behavior will in return make this
3
Compensation after failed retrials
Compensation
Compensated
Rolling back after commitment
Weather Submission Report
le collected delivered Not Start Commitment
ab Activated Done
ail activated
Av
Fa
Access Connection
Exception
Access Completion ilu
Retrial
City located re
Un
failed closed
av
ail
ab
le Search
canceled Abortion after
Suspended failed retrials
Aborted
Refinement
(a) Control behavior (b) Operational behavior
Figure 2. WeatherWS’s control and operational behaviors
Operational
behavior
Not
Component level
Start Commitment
Activated Done
activated
Available
behavior
Weather Report Connection
Control
Submission
City located
collected delivered closed
Legend Conversation session
Figure 3. Example of operational and control behaviors mapping in WeatherWS
Web service take on other appropriate counterpart states between control and operational behaviors require a
like weather-collected and report-delivered specification operation that indicates which state in the
in the control behavior. operational behavior is associated with which set of
The process of connecting operational and control possible paths in the control behavior along with the “new”
behaviors together results in establishing conversation transitions that will implement these interactions. The next
sessions between the respective states of these two be- state to take on in the operational behavior is determined
haviors (Fig. 3). To complete this connection process, a by the executed path in the control behavior and whether
mapping function is defined as follows: this execution was a success or failure. In other words, the
specification operation lets the control behavior indicate to
Definition 3 (Mapping Function). Let Pco be the set of the operational behavior what needs to be done next. We
all paths in the control behavior of a Web service starting define the specification operation as follows:
from any state in this behavior. Connecting the operational
behavior to the control behavior and vice-versa occurs us- Definition 4 (Specification Operation). Let LS be the set of
ing the following mapping function: M ap : Sop → 2Pco , labels associated with the “new” transitions between oper-
where 2Pco is the power set of Pco . ¤ ational and control behaviors. The specification operation
What the he mapping function M ap does is to associate uses the following two functions:
each state in the operational behavior with a set (possibly Spec : Sop → 2LS ×Pco ×LS and N ext : Sop × Pco →
empty) of possible paths in the control behavior. Lop × Sop . ¤
The specification function Spec associates each state sop
in the operational behavior with a (possibly empty) set of
Example 4: Fig. 3 is an example of the use of the triples. A triple contains (i) the label of the transition
mapping function in WeatherWS where activated state from sop to the first state in the control behavior of a mapped
in the operational behavior is associated with multi- path, (ii) the mapped path itself pi→j , and (iii) the label
ple paths in the control behavior. One of these paths of the transition from the last state in the control behavior
l1 l2
is: city-located −→ weather-collected −→ of the mapped path back to sop in the operational behav-
report-delivered where l1 = available and l2 = ior. We qualify the “new” transitions that connect states in
submission. A second path for activated state is independent state charts as inter-behavior (note that intra-
given in Fig. 4 (b) as well. behavior transition was used in Definition 1). The partial
On top of the mapping function Map, interactions function N ext associates both a given state in the opera-
4
tional behavior and the mapped path in the control behavior SIT (op) is the inter-behavior transition relation starting from
with both the next state to take on in the operational behav- the control behavior and ending at the operational behav-
ior and the associated transition label. ior; SIT (op) ⊆ Sop is a finite set of state names in the
operational behavior that take part in inter-behavior tran-
Example 5: Fig. 4 shows the synchronization of Weath- sitions; SIT (co) ⊆ Sco is a finite set of state names in the
erWS’s operational and control behaviors where two types control behavior that take part in inter-behavior transitions;
of transitions exist: intra-behavior from Tco ∪ Top (plain and Lop→co is a set of inter-transitions’ labels from the op-
lines) and inter-behavior (dashed lines, Labels1,2,3 ). erational to the control behaviors, and Lco→op is a set of
Fig. 4 contains Spec(activated)={(label1 , inter-transitions’ labels from the control to the operational
path1 , label2 ),(label1 , path2 , label3 )}, behaviors (Lco→op ∪ Lop→co = LS (Definition 4)). ¤
N ext(activated,path1 )=(commitment,done), Before we define Web service conversation session,
l1 we introduce another function known as Lab. This
where path1 = city-located −→ function returns the label of an inter-behavior transition:
2
l
weather-collected −→ report-delivered Lab : IT → LS .
and N ext(activated,path2 )=(failure,aborted)
l3 Definition 6 (Web Service Conversation Session).
where path2 = city-located −→ access-failed
l4 A conversation session between the operational
−→ connection-closed.
and control behaviors of a Web service is a 4-
In Fig. 4, the initiation of WeatherWS is shown in the
tuple hsop , itop→co , pco , itco→op i such that: sop ∈
operational behavior with activated state. WeatherWS
Sop , itop→co ∈ IT op→co , itco→op ∈ IT co→op , pco ∈
takes on this state following receipt of a user’s request. Be-
Pco ; and (Lab(itop→co ), pco , Lab(itco→op )) ∈
cause of (activated, label1 , city-located) inter-
Spec(sop ). ¤
behavior transitions, the execution of WeatherWS begins by
using a dedicated database to search for the requested city.
This makes WeatherWS take on city-located state in 4 Synchronization woven into composition
the control behavior. Afterwards, two cases are identified.
Case a. Everything goes fine and a 5-day weather- Synchronization is a mechanism by which independent
forecast report is delivered back to the user. Because entities coordinate their next actions by agreeing on how,
of (report-delivered, label2 , activated) inter- where, and when to carry out these actions. In the rest of
behavior transition, this makes WeatherWS complete its op- this paper, entities correspond to Web services that could be
eration with success by transiting from activated to either component or composite. We look into synchroniza-
done states in the operational behavior, i.e., (activated, tion from two perspectives: Intra, which means how the op-
commitment, done) intra-behavior transition. erational and control behaviors in a component/composite
Case b. The access to the database fails (not like in Web service are coordinated (Section 4.1), and Inter, which
case a) as the control behavior of WeatherWS indicates means how the operational and control behaviors in separate
with access-failed and connection-closed component Web services are coordinated within the context
states. Because of (connection-closed, label3 , of the same composite Web service (Section 4.2). Because
activated) inter-behavior transition, this makes Weath- composition could have either a centralized or a P2P or-
erWS terminate its operation with failure by transiting from chestration schema, inter Web-services synchronization is
activated to aborted states in the operational be- examined from these two types.
havior, i.e., (activated, failure, aborted) intra-
behavior transition. 4.1 Intra Web-services synchronization
To wrap-up this section, the formal definitions of inter-
behavior and conversation session are provided. Needless Case of component Web services. The synchronization
to propose a formal definition for intra-behavior transition, of component Web services was the main object of our re-
which is a regular transition in a state chart (Definition 1). search project in [9], so further details are provided in this
reference. Table 1 contains some synchronization messages
Definition 5 (Inter-Behavior Transition). The set of all we developed in order to allow the operational and control
inter-behavior transitions that connect the operational and behaviors interact with each other.
control behaviors of a Web service is denoted by IT Case of composite Web services. The synchronization
where IT = IT op→co ∪ IT co→op such that: IT op→co ⊆ of composite Web services is differently handled from
SIT (op) × Lop→co × SIT (co) is the inter-behavior transition the synchronization of component Web services. This is
relation starting from the operational behavior and ending due to the characteristics of composite Web services that
at the control behavior; IT co→op ⊆ SIT (co) × Lco→op × need now to be highlighted through their operational and
5
Users WeatherWS WeatherWS Users
Operational behavior Control behavior Operational behavior Control behavior
label 1 label 1
Activated City located DB Activated City located DB
commitment
failure
Weather
la
la
Access failed
be
be
collected
l2
l3
Report Connection
Done Aborted
delivered closed
(a) Success case (b) Failure case
Legend
Inter-behavior transition Intra-behavior transition
Figure 4. Synchronization of WeatherWS’s control and operational behaviors
Table 1. Messages during intra (component) Web-service synchronization
# Message name Description
1. sync Originates from an operational state and targets a control state. The purpose is to trigger the execution of the control states (including the targeted control
state) in a conversation session. sync is a blocking message, which makes the operational state wait for a notification back from the last control state to
execute in this conversation session.
2. success Originates from a control state and targets the operational state that submitted sync. The purpose is to inform this operational state of the successful
execution of the control states in a conversation session and to return the execution thread back to this operational state as well. success is coupled with
sync.
control behaviors. These characteristics are as follows. (WeatherWS, NiceWeather, PlaceBookingWS)
Firstly, the control behavior represents the business logic are included. In this transition example, WeatherWS
of a composition scenario and no longer the business logic and PlaceBookingWS are the source and target states,
of a certain component Web service. Secondly, the current respectively, and NiceWeather is the transition’s label.
definition of the operational behavior (Definition 1) does
not tell much about the execution outcome of a composition Definition 8 (Composite Web Service Operational Be-
scenario and if this execution either succeeded or failed. havior). The operational behavior of a composite Web
This current definition through states like activated and service is defined as an instance of the behavior of a
cws
suspended is geared towards the needs of the component Web service (Definition 1) and is denoted by Bop =
0
level, only (Fig. 2 (b)). hSop , Lop , Top , sop , Fop i. ¤
The purpose of the operational behavior of a composite
Definition 7 (Composite Web Service Control Behavior). Web service is (i) to initiate the execution of its specifica-
The control behavior of a composite Web service is a 5- tion, which is in fact the control behavior of this composite
tuple Bcocws
= hWS co , Lco , Tco , WS 0co , Fco i where WS co is Web service and (ii) to report on the success or failure of
a finite set of states that correspond to Web services’ names; the execution of this specification. As a result, the opera-
WS 0co ⊂ WS co is the set of initial states that correspond to tional behavior of a composite Web service is a subset of
initial Web services; Fco ⊆ WS co is the set of final states the operational behavior of a component Web service.
that correspond to final Web services; Lco is a set of la-
bels; and Tco ⊆ WS co × Lco × WS co is the transition
Example 7: Fig. 5 is another state chart that illustrates
relation. Each transition t = (wssrc , l, wstgt ) consists of a
this time the operational behavior of the CookoutParty
source Web service wssrc ∈ WS co , a target Web service
composite Web service. In this state chart, the number
wstgt ∈ WS co , and a transition label l ∈ Lco . ¤
of states is limited to four, namely not-activated,
activated, done, and aborted, and the num-
Example 6: Fig. 1 is a state chart of the control ber of transitions is limited to three, namely start,
behavior of the CookoutParty composite Web service. commitment, and failure.
Several states like WeatherWS (initial state) and Compared to the six states in the operational behavior of
CateringWS (final state) and several transitions like a component Web service (Fig. 2 (b)), the four states in the
6
Com
mitm
ent Done In this paper, we look at inter Web-services synchroniza-
Not Start
Activated
activated Fail
ure
tion from two perspectives: centralized and P2P (focus of
Aborted
this paper). This synchronization aims at initiating the de-
velopment of composition scenarios and overseeing the exe-
Figure 5. Operational behavior of a compos- cution progress of this development at run-time. As a result,
ite Web service this raises the necessity of enhancing Web services with ad-
ditional mechanisms based on the needs and requirements
of these composition scenarios. For instance, a Web ser-
operational behavior of a composite Web service (Fig. 5) vice has now to decide if it would or not take part in a
puts some restrictions on the authorized synchronization composition scenario subject to carrying out some sort of
messages (like those suggested in Table 1) that can be con- self-assessment [6]. That was not the case in the intra Web-
sidered between this operational behavior and its counter- services synchronization (Section 4.1) where the focus was
part control behavior. These restrictions are hereafter listed: on how to specify the execution of “isolated” Web services.
We identify the additional mechanisms that should em-
1. There is one conversation session between the opera- body Web services along four cases, which we denote by
tional and control behaviors. This session includes the invitation, execution, verification, and replacement. These
activated state in the operational behavior and all four cases abstract the different types of actions that com-
the states (i.e., WS co ) in the control behavior. ponent and composite Web services carry out during verti-
cal and horizontal interactions. For example, a Web service
2. Interaction message of type sync to come out of the
should submit its performance details to a composite Web
activated state in the operational behavior has one
service as part of the verification exercise that this com-
recipient, which is the initial state(s) (i.e., Web service)
posite Web service carries out. In addition, a Web service
in the control behavior (i.e., WS 0co ).
should not leave its ongoing operations pending in case a
3. Any state (i.e., component Web service) in the con- composite Web service decides to substitute it as part of the
trol behavior can only submit an interaction message replacement exercise. These additional mechanisms need
of type fail back to the activated state in the oper- to be woven into the business logic that underpins the func-
ational behavior. This restriction is waived for the final tionality of a Web service. In [7], we elaborate on how this
state(s) in the control behavior (i.e., Fco ) that can sub- weaving should place in compliance with some design prin-
mit on top of fail message another message of type suc- ciples like separation of concern and aspect-oriented pro-
cess back to the activated state in the operational gramming. To keep the paper self-contained on synchro-
behavior. nization, enriching Web services with additional mecha-
nisms is excluded.
4. Interaction message of type syncreq is not allowed Case of P2P orchestration. The synchronization of in-
from the control to the operational behaviors. ter Web-services in a P2P orchestration reinforces the exis-
tence of the component level, only. Each component Web
4.2 Inter Web-services synchronization service that takes part in a composition scenario is associ-
ated with an operational and a control behaviors (Fig. 6).
Centralized orchestration is well “embraced” in Web ser- The previously proposed definitions for these two behav-
vices composition projects. But, a few projects look into iors continue to be used (Definition 1). However, new def-
the changes that need to be made in Web services stan- initions are deemed appropriate for first, the inter-behavior
dards/specifications like BPEL to smooth the design and de- transitions between component Web services and second,
velopment of P2P orchestration. Gowri Nanda et al. note the conversation sessions that result out of setting-up these
that because performance and throughput are major con- inter-behavior transitions. These new definitions have to
cerns in enterprise applications, removing the inefficien- be inline with the authorized actions to carry out in a P2P
cies that a centralized control introduces, is required [4]. A orchestration. These actions are “invite”, “trigger”, and
BPEL program could be partitioned into independent sub- “ping”.
programs that interact with each other without any cen- In Fig. 6, the double-arrowed lines (plain and dashed)
tralized control. Gowri Nanda et al. propose a technique illustrate where the synchronization of inter Web-services
to partition a composite Web service written as a single should take place in a P2P orchestration. Numbers asso-
BPEL program into an equivalent set of decentralized pro- ciated with these lines represent message chronology. In
cesses. This technique minimizes communication costs and the P2P orchestration we hereafter adopt, sequential execu-
maximizes the throughput of multiple instances of the input tion of the component Web services is assumed even though
program. concurrent execution could be handled without any substan-
7
Component Web servicei Component Web servicej
Operational 1 Control Operational 4 Control
behavior 2 behavior behavior 5 behavior
3 8 6
7
Legend
Inter-behavior transition within component Web service
Inter-behavior transition between component Web services
i): Chronology of synchornization messages
Figure 6. Synchronization of behaviors at the composition level – P2P orchestration
tial changes in the new or existing definitions. Plain lines in
Fig. 6 represent inter-behavior transitions within the same ½
N otif y(W Si+1 ) i = 1, · · · , n − 1
component Web service (Section 4.1). What is now needed, Status(W Si ) =
success | f ailure i = n
which is the focus of this part of the paper, is to define
the inter-behavior transitions between component Web ser- It is worth to mention that success and failure are conver-
vices. These inter-behavior transitions are represented with sational messages between component Web services. These
dashed lines (3, 6, 7, 8) in Fig. 6. messages are specified in Table 2.
In a P2P orchestration, the absence of a centralized coor- Fig. 7 illustrates the different conversation sessions that
dination that would “spread the word” to other component need to be set-up in a P2P orchestration. The focus is
Web services about the execution outcomes of their peers on conversation session #2; conversation session #1 is al-
requires some changes in the way these component Web ser- ready discussed in Section 4.1. The identification of the
vices should behave. For instance, component Web services inter-behavior transitions that should be included in con-
cannot announce their immediate successful execution un- versation scenario #2 takes advantage of the set of accept-
til they receive positive feedbacks from their peers in a re- able actions (e.g., “invite” and “ping”) that can be car-
verse order. In case of negative feedbacks, these component ried out between component Web services. These ac-
Web services have to cancel or compensate their execution tions are now woven into the synchronization messages
outcomes and notify their predecessors about the cancela- to occur between the respective operational behaviors of
tion or compensation actions they have taken, as well. An- the component Web services. The following comments
nouncement delay and backward notification have to be re- are made on the new operational behavior of a compo-
flected on the operational levels of the different component nent Web service: (i) partial done and final done
Web services. Like in a centralized orchestration we split states are added and connected, (ii) partial done and
done state into two states (Fig. 7): partial done and aborted states are connected, and (iii) partial done
final done. and compensated states are connected as well.
Table 2 summarizes some messages that can be ex-
changed in a P2P orchestration during inter Web-services
• Partial done in a component Web service allows
to pass on the execution thread to the next peer(s) synchronization. This table is built upon the messages of
(Fig. 6, dashed lines 3 and 6). Table 1. The description of each message type shows (i) the
direction of the bidirectional flow between the operational
behaviors of the component Web services, and (ii) the case
• Final done in a component Web service permits to that corresponds to the actions to perform during horizon-
confirm its successful execution (final completion) fol- tal interactions. Interesting to discuss messages #9 and #10,
lowing receipt of a positive notification from a succes- i.e., confirm and cancel, respectively in Table 2. Both mes-
sor peer (Fig. 6, dashed lines 7 and 8). sages are used by component Web services to notify other
component Web services that they could either confirm or
Definition 9 (Completion Status of Component Web Service cancel their execution.
in Peer-to-Peer Orchestration). Let assume a composition Definition 10 (Inter-Behavior Transition in Peer-to-Peer
scenario of n component Web services. The completion Orchestration). The set of all inter-behavior transitions
status of a component Web service WSi in term of either that connect the operational behaviors of component Web
success or failure is dependent on the notification message services together in a P2P-orchestration mode (conver-
that WSi receives from its direct successor component Web sation session #2 in Fig. 7) is denoted by IT (wsi ,wsj )
service WSi+1 . where IT (wsi ,wsj ) = IT (ws i ,wsj )
op→op ∪ IT (ws j ,wsi )
op→op such that:
8
Aborted
Operational
Failure
behavior
Not Start Cancellation
Component level
Activated Comm ent Final done
(WeatherWS)
activated itment mitm
Partial Com
done Compe
nsatio
n ... Compensated
behavior
Control
Report
City located
delivered
1
Operational
Not Start Commitment Partial
behavior
Activated
Component level
activated done
(CateringWS)
2
behavior
Control
Catering
Menu items
delivered
1
Legend Conversation session
Figure 7. Operational and control behaviors mapping in CookoutParty - P2P orchestration
(ws ,ws )
IT (ws i ,wsj )
op→op
i
⊆ SIT (op) × Lop→op j
× SIT (op) is the inter- quences). It implements functions to support conversations
behavior transition relation starting from the operational be- between operational and control behaviors. Specifically, it
havior of a component Web service (W Si ) and ending at provides methods for managing conversation instances and
the operational behavior of another component Web ser- triggering transitions. When dealing with a peer to peer
vice (W Sj ). Same definition applies to IT (ws j ,wsi )
op→op ⊆ synchronization, the ConversationModeler manages
(ws ,ws )
j i first, the inter-behavior transitions between component
SIT (op) × Lop→op × SIT (op) ; SIT (op) ⊆ Sop is a finite
set of state names in the operational behavior of a com- Web services and second, the conversation sessions that
ponent Web service that take part in inter-behavior tran- result out of setting-up these inter-behavior transitions.
(wsi ,wsj ) Finally, the SimulationController tracks and
sitions; and Lop→op is a set of inter-transitions’ labels
analyzes (if necessary) the execution of a composite or
from the operational behavior of a component Web ser-
a component Web service according to its conversation
vice (W Si ) to the operational behavior of another compo-
(wsj ,wsi ) definition (e.g., whether the messages are received and sent
nent Web service (W Sj ), and Lop→op is the opposite in an appropriate order).
(wsi ,wsj ) (wsj ,wsi )
(Lop→op ∪ Lop→op = LS ). ¤ Fig. 8 shows the execution of a component Web ser-
vice in the case of a peer to peer orchestration. Upon
5 Implementation the reception of a user’s request, the operational level of
the first component Web service (WeatherWS in this case)
moves from not-activated state to activated state (red color
To test the viability of the proposed approach, a proto-
is used to show the execution path). This latter state, sub-
type system was implemented in Java and integrated under
mits a Sync message to Citylocated state in the con-
Eclipse 3.3 by extending the Web service development
trol behavior to trigger its execution. In a success case,
platform we developed previously [9]. The prototype
Reportdelivered state returns a Success message
consists of four modules:
back to the activated state in the operational behavior. Based
ControlBehaviorModeler,
on this information, the operational behavior moves from
OperationalBehaviorModeler,
activated state to partial done state. This latter state sends a
ConversationModeler and
trigger message to invoke the next component Web service
SimulationController.
(CateringWS).
The ControlBehaviorModeler and the
OperationalBehaviorModeler assist engi-
neers specify the control and operational behaviors of 6 Conclusion
a component or a composite Web service, respectively.
In particular, we developed a visual interface for edit- We presented in this paper a framework for establishing
ing Web services’ behaviors using state charts. The synchronization between Web services engaged in compo-
ConversationModeler takes the behavior specifica- sition scenarios. Synchronization assists independent par-
tions of a Web service as an input to produce conversation ties coordinate their actions and thus, avoid conflicts. This
specifications (i.e., inter-transitions and message se- framework extends the research work we carried out on iso-
9
Table 2. Messages during inter Web-services synchronization - P2P orchestration
# Message Description
name From To In reply to Case
1. invite Component WSi (Bop ) Component WSj (Bop ) null Invitation
2. trigger Component WSi (Bop ) Component WSj (Bop ) null Execution
3. ping Component WSi (Bop ) Component WSj (Bop ) null Verification
4. ... ... ... ... ...
ws
9. confirm Component WSi (Bop ) 1[Component WSj (Bop )](i-1) success Execution
ws
10. cancel Component WSi (Bop ) 1[Component WSj (Bop )](i-1) failure Execution
Figure 8. An execution of a component Web service in a P2P orchestration
lated Web services (not engaged in any composition) and [2] F. Casati and M. C. Shan. Dynamic and Adaptive Composi-
leverages two types of behaviors related to specifying such tion of E-Services. Information Systems, 26(3), 2001.
Web services. The control behavior defines the business [3] F. Daniel and B. Pernici. Insights into Web Service Or-
logic that underpins the functioning of a Web service, and chestration and Choreography. International Journal of E-
the operational behavior regulates the execution progress of Business Research, The Idea Group Inc., 1(2), 2005.
this control behavior by stating the actions to carry out and
the constraints to put on this progress. Synchronizing Web [4] M. Gowri Nanda, S. Chandra, and V. Sarkar. Decentral-
izing Execution of Composite Web Services. In Proceed-
services through their respective behaviors has revealed that
ings of 19th Annual ACM Conference on Object-Oriented
the orchestration schemas, whether centralized or P2P, af- Programming, Systems, Languages, and Applications (OOP-
fect the mechanisms to develop in response to the needs SLA’2004), Vancouver, British Columbia, Canada, 2004.
and requirements of the composition scenario that is under
consideration. The use of some of these mechanisms per or- [5] M. Kovas, J. Bentahar, Z. Maamar, and H. Yahyaoui. For-
chestration schema was demonstrated through a prototype. mal Verification of Conversations in Composite Web Ser-
vices using NuSMV. In Proceedings of the 8th Interna-
In term of future work, we plan to study the value-add of
tional Conference on Software Methodologies, Tools and
model checking to the early-detection of design inconsis- Techniques (SoMeT09), IOS Press, Prague, Czech Republic,
tencies and errors. 2009.
[6] Z. Maamar, S. Kouadri Mostéfaoui, and H. Yahyaoui. To-
wards an Agent-based and Context-oriented Approach for
References Web Services Composition. IEEE Transactions on Knowl-
edge and Data Engineering, 17(5), May 2005.
[1] Benatallah. B., Q. Z. Sheng, Ngu A. H. H., and M. Dumas. [7] Z. Maamar, M. Sheng, D. Benslimane, and H. Yahyaoui.
Declarative Composition and Peer-to-Peer Provisioning of Web Services Interactions: Analysis, Modeling, and Man-
Dynamic Web Services. In Proceedings of the 18th Interna- agement. International Journal on Software Engineering
tional Conference on Data Engineering (ICDE’2002), San and Knowledge Engineering, World Scientific Publishing
Jose, CA, US, 2002. Co., 18(2), March 2008.
10
[8] Z. Maamar, M. Sheng, H. Yahyaoui, J. Bentahar, and
K. Boukadi. A New Approach to Model Web Services’ Be-
haviors based on Synchronization. In Proceedings of the
23rd IEEE International Conference on Advanced Informa-
tion Networking and Applications, Symposium on Frontiers
of Information Systems and Network Applications, Bradford,
UK, 2009.
[9] Z. Maamar, M. Sheng, H. Yahyaoui, J. Bentahar, and
K. Boukadi. Conversation-Oriented Engineering of Web Ser-
vices. Technical report, College of Information Technology,
Zayed University, September 2007.
[10] Q. Z. Sheng, B. Benatallah, Z. Maamar, M. Dumas, and
A. H. H. Ngu. Enabling Personalized Composition and
Adaptive Provisioning of Web Services. In Proceedings of
the 16th International Conference on Advanced Information
Systems (CAiSE’2004), Riga, Latvia, 2004.
[11] W. Yang and S. Tang. A Solution for Web Services Transac-
tion. In Proceedings of The 2006 International Conference
on Hybrid Information Technology (ICHIT’2006), Cheju Is-
land, Korea, 2006.
11