Towards a Coordination Model for Web Services

Zakaria Maamar

, Nanjangud C. Narendra

and Philippe Thiran

Zayed University, U.A.E

IBM India Research Lab, India

University of Namur, Belgium

Abstract. The increasing popularity of Web services for application integration

has strengthened the need for automated Web services composition. For this au-

tomation to succeed, the joint execution of Web services requires to be coor-

dinated. Coordination’s main use is to solve conﬂicts between Web services.

Conﬂicts could be on sharable resources, order dependencies, or communica-

tion delays. The proposed coordination model tackles these conﬂicts with three

inter-connected blocks deﬁned as conﬂict, exception, and management. Conﬂicts

among Web services raise exceptions that are handled using appropriate mecha-

nisms as part of the coordination model.

1 Introduction

Over the last few years, the development pace of Web services has been impressive [4].

Several standards have been developed and several projects have been initiated. Some

standards concern Web services deﬁnition, discovery, and security, and some projects

concern Web services composition, personalization, and provisioning. In general, com-

position of Web services primarily addresses the situation of user requests that cannot

be satisﬁed by any single Web service, whereas a composite Web service obtained by

combining available Web services may be used.

Another research venue that is worth pursuing is the coordination of Web services

so ﬁrst, their collective actions are performed in a coherent way and second, their excep-

tions are handled in a proper way. Although the WS-Coordination speciﬁcation exists,

it does not emphasize the conﬂicts that could arise between Web services. Web services

do not always expose a cooperative attitude when they participate in compositions. For

instance, they can compete on sharable resources, which may affect their performance

scheduling. Second they can announce misleading information (e.g., QoS) to enhance

their participation opportunities in composite Web services. In addition, they can be

kept on-hold for long time periods due to data or order dependencies with peers. Our

objective is to investigate the way Web services coordination happens over the follow-

ing three steps: discovery, engagement, and performance. The three steps denote here

what we call Web services composition.

It is known that coordination’s main use is to solve conﬂicts between separate com-

ponents, for example Web services. Depending on the type of conﬂict, a centralized or

distributed (e.g., peer-to-peer) form of coordination can be adopted. In this paper we

study both forms of coordination along the discovery, engagement, and performance

steps and discuss which form suits which step. Each form of coordination has its pros

Maamar Z., C. Narendra N. and Thiran P. (2006).

Towards a Coordination Model for Web Services.

In Proceedings of the 1st International Workshop on Technologies for Collaborative Business Process Management, pages 24-32

 SciTePress

and cons. In term of pro, centralized coordination makes the identity of the components

only available to the entity in charge of coordination. This is crucial when components

want to remain anonymous. For decentralized coordination, the different components

know each other so they can reach mutual agreements without going through third par-

ties. In term of con, centralized coordination heavily relies on the normal operation of

the entity in charge of coordination, which could turn out to be a bottleneck for this

operation. For decentralized coordination, there is no overall picture of the way coordi-

nation progresses among the different components. The rest of this paper is organized

as follows. We overview some concepts and present a running scenario in Section 2.

Sections 3 and 4 present the proposed coordination model for handling exceptions of

Web services. The paper concludes in Section 5.

2 Background

2.1 Deﬁnitions

The decomposition of Web services composition into three steps namely discovery, en-

gagement, and performance is inline with Burstein et al.’s steps [2]. These steps are

to a certain extent run in parallel and thus, require to be monitored for reasons of per-

formance and concurrence. Another conﬂict could arise while the current conﬂict is

being ﬁxed, unless the execution of all component Web services - including those Web

services that are not affected by the current conﬂict - is suspended.

The discovery step is about identifying the Web services that satisfy users’ needs

based on user-speciﬁed selection criteria [1]. This discovery can be implemented by the

use of an UDDI registry on which Web services descriptions are posted so potential

users consult these descriptions.

The engagement step is about connecting the component Web services that were

identiﬁed in the discovery step. The connection, usually known as orchestration, com-

plies with a speciﬁcation that underlines a business logic (e.g., travel planning). Inter-

esting to stress that Web services interaction highlights messages to exchange, data to

supply, acknowledgments to return, dependencies to manage, etc.

The performance step is about running the component Web services on top of re-

sources. Scheduling the execution requests of Web services is prioritized when enough

resources are not available to satisfy these requests all at once. A Web service requires

resources for different operations like self-assessment prior to participating in compo-

sitions, satisfying user needs upon request, and data exchange with other Web services.

2.2 Coordination Form

Coordination can take two different forms: centralized or distributed. The ﬁrst form

of coordination calls for a central component that is in charge of providing a uniﬁed

model of the coordination, overseeing the operation of other components, interfering

in case of conﬂicts, and restarting execution after exception handling. The second form

of coordination calls for a mutual awareness of the components and their respective

operations. This alleviates the burden of designing a single coordination component

that will be bound to monitor other components. The components engage in conﬂict

resolution, and cooperate with each other to determine appropriate exception handling

procedures. In section 3.2, we discuss the interleaving of coordination and interaction.

Some pros and cons of each form of coordination have been discussed in Section 1.

In addition to both forms of coordination, coordination could be either implicit or

explicit. On the one hand implicit coordination assumes that participants are aware of

some existing pre-deﬁned rules, which they need to abide by. If the contrary happens

participants are subject to penalties that depend on the application domain. Trafﬁc reg-

ulation is a good example of implicit coordination, where ﬁnes sanction the drivers who

do not conform to the regulation’s policies. On the other hand explicit coordination re-

quires negotiation, voting, or intervention of an authority. This coordination calls for a

clear speciﬁcation of various elements including tasks that are executed, conﬂicts that

can arise, and exceptions that can happen.

2.3 Running Example

Our running scenario is about Amin who is visiting Melissa back in her home city, Oslo.

Amin and Melissa agree to meet in a coffee shop, not far from Melissa’s ofﬁce since she

ﬁnishes work late on that day. Amin has two options to reach the meeting place: by taxi

or by bus. Figure 1 illustrates the speciﬁcation of Amin scenario using a combination

of state chart diagrams and service chart diagrams [5].

SCD-BS

(Bus Schedule)

SCD-LO

(LOcation)

SCD-TP

(TriP)

SCD-WE

(WEather)

SCD-TA

(TAxi)

SCD-TC

(TraffiC)

yes

no

[confirmed (bad weather)]

(SCD: Service Chart Diagram)

Fig.1. Speciﬁcation of Amin scenario.

In case Weather WS forecasts bad weather, a taxi booking is made on behalf of

Amin using Taxi WS. Otherwise, i.e., pleasant day, Amin uses public transportation.

The location of both Amin’s hotel and coffee shop are submitted to Bus Schedule WS,

which returns for example the bus numbers Amin has to take. Potential trafﬁc jams

force Bus Schedule WS to regularly interact with Trafﬁc WS that monitors the status

of the trafﬁc network. This status is fed into Bus Schedule WS so adjustments to bus

numbers and correspondences between buses can occur.

Amin scenario yields insight into the multiple challenges that Web services coordi-

nation faces. Some of these challenges include: what are the reasons that trigger con-

ﬂicts between Web services, how to model and track Web services coordination, how

to adjust control and data ﬂow among the involved Web services during coordination,

which form of coordination, whether centralized or distributed, to adopt according to

the progress of Web services composition, how to ensure that Web services comply with

an implicit or explicit coordination, and what types of penalties could be developed for

the non-complying Web services?

3 Proposed Coordination Model

3.1 Foundations and Operation

For Papazoglou and Georgakopoulos, coordination is ”to control the execution of the

component services, and manage dataﬂow among them and to the output of the compo-

nent service” [7]. While there is no disagreement on this deﬁnition, the way exceptions

hinder a composition progress and affect its execution control and dataﬂow manage-

ment is not strengthened. Figure 2 presents our proposed coordination model for han-

dling Web services exceptions. The model is made up of 3 blocks: conﬂict, exception,

and management. These blocks form a cycle that starts with conﬂict and continues next

with exception then management, before it returns back to conﬂict. The coordination

model runs along the discovery, engagement, and performance steps of Web services

composition. Each step could host the execution of the complete cycle of the three

blocks, which calls for a close follow-up of the awareness, handling, and monitoring

transitions between these blocks (Figure 2).

Conflict Exception Management

Awareness

Monitoring

Handling

Fig.2. Proposed coordination model to handle Web services exceptions.

Conﬂict block is concerned with the problems that preclude the normal operation of

Web services as per the composition speciﬁcation (Figure 1). These problems vary ac-

cording to the step that features a composition progress. Indeed conﬂicts during discov-

ery are different from those during engagement or performance. Examples of conﬂicts

per type of step are given later. In the conﬂict block, we identify the following actions:

(1) conﬂict detection for knowing that a conﬂict is happening is deemed appropriate

so actions can be taken; (2) conﬂict classiﬁcation that identiﬁes the type of conﬂict

whether related to resource, communication failure, etc; (3) conﬂict impact assessment

that evaluates how much a conﬂict impacts the normal progress of composition. This

impact is in terms of time duration, execution cost, etc; (4) conﬂict correction that aims

at suspending a composition progress, giving room for corrective actions to be executed.

This will manifest itself in the exception block.

Exception block follows the conﬂict block and aims at gearing the computational

efforts to put in towards the detected type of conﬂict. Each conﬂict has to be separately

treated from the speciﬁcation of composition, which shows the importance of concern

separation between exception handling and composition speciﬁcation execution. In the

exception block, we identify the following actions: (1) exception establishment that

conﬁrms the presence of a conﬂict by labelling the speciﬁcation as abnormal. This is de-

rived from the conﬂict correction action in the conﬂict block; (2) exception information

propagation that deﬁnes the exception in terms of current active step in speciﬁcation,

participating Web services, pending messages, etc. In addition, the information regard-

ing the exception is propagated to all the participating Web services. This propagation

is detailed in Section 3.3.

Management block follows the exception block and aims at ﬁxing the conﬂict that

is associated with an exception, i.e., running exception handling. Management adopts a

centralized or distributed form of coordination according to the exception type and the

active step of composition. In the management block, we identify the following actions:

(1) management initiation that begins the coordination work by selecting the appropri-

ate conﬂict solving strategy according to details obtained out of the exception block.(2)

management tracking that aims at overseeing the performance of the selected solving

strategy in terms of executed actions, ﬁxed conﬂicts, exchanges messages, etc; manage-

ment outcome validation that permits to ﬁnalize the solving strategy by conﬁrming its

success or failure and to give back the control to the conﬂict block.

We stated earlier that the proposed coordination model (Figure 2) runs along the

discovery, engagement, and performance steps that make up Web services composi-

tion. During Web services discovery, three requirements of type language, function,

and architecture need to be satisﬁed [2]. If this does not happen, conﬂicts will arise.

Language requirements concern expressing the capabilities of Web services and goals

of requestors. A potential conﬂict could be lack of understanding of these capabili-

ties or goals. Functional requirements concern the actions that providers, requestors,

and matchmakers will perform. A potential conﬂict could be the non-performance of

the expected actions or the non-compliance with the actions each entity is supposed

to perform. Finally, architectural requirements deﬁne the advertisements and discovery

protocols to be used by Web services providers and requestors, respectively. A potential

conﬂict could be the use of an unknown advertisement or discovery protocol.

During Web services engagement, interactions between Web services providers and

requestors take place and result in agreements [2]. Similar to Web services discov-

ery’s requirements, the engagement step is featured with functional and architectural

requirements. If these requirements are not satisﬁed, conﬂicts will arise. Functional

requirements concern Web services request formulation, contract preliminaries, con-

tract negotiation, and negotiation. A potential conﬂict could be differing expectations

between service requestor and provider regarding terms of the contract. Architectural

requirements concern negotiation protocols, negotiation services, and auditing services.

A conﬂict could be the non-compliance with the commitments made in a contract.

During Web services performance, a.k.a enactment and management in [2], require-

ments are of types function and architecture. If these requirements are not satisﬁed,

conﬂicts will arise. Functional requirements concern multiple aspects like choreogra-

phy interpretation and execution, service-failure handling and compensation, and non-

repudiation. A potential conﬂict could be differing compensation strategies among par-

ticipating Web services. Architectural requirements concern also multiple aspects like

process-scheduling and composition services and policy-monitoring services. A poten-

tial conﬂict could be non-compliance with agreed upon QoS requirements.

3.2 Interleaving Interaction and Coordination

In a Web services composition scenario, the ﬂow of interaction happens in a vertical

(between a composite Web service and its component Web services) and horizontal

(between component Web services of the same composite Web service) way. Through

an interaction, the initiator aims at conveying some information to the recipient, so this

latter can for instance take actions and adapt its behavior, consequently. In the following

we discuss the way interaction and coordination are interleaved per way of interaction.

This discussion uses Figure 3 and Figure 4. In both ﬁgures, plain lines correspond to

interactions and dotted lines correspond to conﬂict detection and resolution operations.

In vertical interactions, a composite Web service has the authority to execute the

following actions over a component Web service (Figure 3): invite in order to join com-

position, trigger in order to initiate execution, audit in order to track performance, and

retract in order to replace component (e.g., due to poor performance or temporary un-

availability). It is shown in Figure 3 that trigger action implements a centralized orches-

tration of Web services, which is used in systems like CMI [8]. A centralized orchestra-

tion assumes that the connection between the central scheduler of the composite Web

service and the component Web services is continually available. It is also shown in this

ﬁgure that retract action is followed by invite action, so a suitable replacement of the

retracted component Web service from the composition is identiﬁed and appended into

this composition.

Initiator

"Composite service"

Recipient

"Web service"

Actions

Invite

Trigger

Audit

Retract

Conflict detection

& resolution

Conflict

detection

Feedback

Fig.3. Interleaving interaction and coordination during vertical interactions.

Coordination in vertical interactions occurs at the composite Web service level.

Conﬂict detection that triggers coordination is carried out in two different places. The

ﬁrst place highlights a component Web service that faces difﬁculties in completing its

operations. A Web service could be put on hold for a long period of time due to oc-

cupied resources. As a result, the Web service notiﬁes the composite Web service so

appropriate resolution actions can be taken. The notiﬁcation is represented with feed-

back in Figure 3. The second place of coordination highlights a composite Web service,

which based on the feedbacks it receives from its component Web services, can expect

the occurrence of conﬂicts, such as possible bus scheduling conﬂicts (caused by trafﬁc

jams) in Amin scenario. Thus, the composite Web service decides to take actions prior

to conﬂict occurrence. This is called preventive strategy to conﬂict occurrence.

In horizontal interactions, a Web service has the authority to carry out the following

actions over another peer engaged in the same composition (Figure 4): trigger in order to

initiate execution and monitor in order to check peer’s liveness. It is shown in Figure 4

that trigger action implements a peer-to-peer orchestration of Web services, which is

used in systems like PCAP [9]. It is also shown in this ﬁgure that monitor action is

followed by trigger action to ensure that a Web service has effectively been triggered.

There is no guarantee that a particular Web service is still available at time of request.

Coordination in horizontal interactions occurs at the component Web services level.

Conﬂict detection that triggers coordination is also carried out at the same level. When

a component Web service identiﬁes a conﬂict, it interacts with the component Web

services that are part of this conﬂict. In Amin scenario, bus WS may interact with Trafﬁc

Initiator

"Web service 

1

"

Recipient

"Web service 

2

"

Actions

Trigger

Monitor

Conflict

detection

Conflict

detection

Conflict resolution

Fig.4. Interleaving interaction and coordination during horizontal interactions.

WS and Location WS regarding potential trafﬁc jams. The number of these components

varies from one to many, which can increase the complexity of resolving conﬂicts.

It should be noted that triggering action here does not mean that the Web service

can only perform one operation; it is assumed that the trigger action would specify

the operation needed to be performed. In addition to the aforementioned conﬂict types,

semantic conﬂicts could be considered [3]. However they are not discussed in this paper.

3.3 Adaptation and Propagation During Exception Handling

As per Narendra et al.’s classiﬁcation of the tasks in a workﬂow, a task can fall into one

of the following categories [6]: pivot, retriable, or compensatable. We bind to the same

classiﬁcation to our coordination model and consider that a Web service could be:

- Pivot: once the Web service fails, it is neither retried nor compensated. This Web

service can only be aborted, not even rolled back. Committing a pivot Web ser-

vice for execution means that the execution of the entire composition speciﬁcation

needs to be completed. A pivot-Web-service failure means failure of the compo-

sition speciﬁcation, which will need to be aborted and restarted from scratch. In

Amin scenario, Trip WS committing to assist Amin in preparing his trip to the

coffee shop, is an example of pivot Web service.

- Retriable: the Web service can be retried upon failure, but cannot be compensated.

This Web service can also not be rolled back if the retry also fails, and thus, can

only be aborted. In Amin scenario, Taxi WS that books a taxi for Amin reports

failure after retrying a number of times.

- Compensatable: the Web service is retriable and thus, can be rolled back via its cor-

responding compensating Web service. In Amin scenario, if the meeting location is

changed this will result in forcing Location WS to do some compensation.

Web services in conﬂict are either rolled back or aborted in the reverse order in

which they executed. Two possibilities illustrate the way the reverse order occurs:

1. Web service is retriable. If the retry succeeds, then the traversal stops and the ex-

ecution of the composition speciﬁcation resumes. Otherwise, the Web service is

aborted and the control moves backward to the previously executed Web service.

2. Web service is compensatable. If the retry succeeds, then the traversal stops and

the composition speciﬁcation resumes. Otherwise, the compensating Web service

for the Web service is invoked, and the control moves backward to the previously

executed Web service.

4 Illustration via the Running Scenario

Referring to the running scenario in Figure 1, we suggest hereafter three possible con-

ﬂicts. We assume that Trip WS is of type pivot, Location WS is of type compensatable,

and the rest of Web services are of type retriable.

First, taxi scheduling conﬂict that impedes Amin’s ability to take a taxi due to bad

weather. Here Taxi WS can retry the execution so an alternate taxi is provided to Amin.

In case the retrial fails, Taxi WS will need to simply abort and report failure, forcing

Amin to check Bus schedules despite the bad weather.

Second, bus scheduling conﬂict resulting from trafﬁc jams on the way to the coffee

shop. The occurrence of this conﬂict is due to trafﬁc jams, which forces Bus sched-

ule WS to provide an alternate schedule via a retry. In case this also results in conﬂict,

Bus schedule WS is aborted. Afterwards, Location WS needs to be rolled back via its

compensating Web service, and again re-executed to assign a new location for Amin

& Melissa to meet.

Third, Bus scheduling conﬂict because of erroneous location. In case Location WS

itself returns an erroneous location, Bus schedule WS needs to be aborted, and Lo-

cation WS needs to be rolled back using its compensating Web service. Afterwards,

Location WS needs to re-execute so it can provide the correct meeting location. This

adaptation process can either be coordinated by Trip WS (vertical interactions) or can be

self-coordinated by the conﬂicting Web services themselves (horizontal interactions).

5 Conclusion

In this paper we presented a coordination model for Web services with emphasis on

handling exceptions during execution. The model encompasses three blocks: conﬂict,

exception, and management. They are concerned with, respectively, conﬂict detection

and classiﬁcation; exception derivation and information propagation; and tracking of

exception handling. We also discussed the way the coordination model can be imple-

mented in either a centralized or distributed manner.

References

1. V. Agarwal, G. Chaﬂe, K. Dasgupta, N. Karnik, A. Kumar, S. Mittal, and B. Srivastava. Syn-

thy: A System for End To End Composition of Web Services. Journal of Web Semantics, 3(4),

2005.

2. M. Burstein, C. Bussler, M. Zaremba, T. Finin, M. N. Huhns, M. Paolucci, A. P. Sheth, and

S. Williams. A Semantic Web Services Architecture. IEEE Internet Computing, 9(5), Septem-

ber/October 2005.

3. J. Cardoso and A. Sheth. Semantic Web Processes: Semantics Enabled Annotation, Discovery,

Composition and Orchestration of Web Scale Processes. In Proceedings of The 4th Interna-

tional Conference on Web Information Systems (WISE’2003), Roma, Italy, 2003.

4. S. Dustdar and W. Schreiner. A Survey on Web Services Composition. International Journal

on Web and Grid Services, 1(1), 2005.

5. Z. Maamar, B. Benatallah, and W. Mansoor. Service Chart Diagrams - Description & Appli-

cation. In Proceedings of The Alternate Tracks of The Twelfth International World Wide Web

Conference (WWW’2003), Budapest, Hungary, 2003.

6. N. C. Narendra and S. Gundugola. Automated Context-Aware Adaptation of Web Service

Executions. In Proceedings of The 4th IEEE Conference on Computer Systems and Applica-

tions (AICCSA’2006), Sharjah, U.A.E, 2006.

7. M. Papazoglou and D. Georgakopoulos. Introduction to the Special Issue on Service-Oriented

Computing. Communications of the ACM, 46(10), October 2003.

8. H. Schuster, D. Georgakopoulos, A. Cichocki, and D. Baker. Modeling and Composing

Service-based and Reference Process-based Multi-Enterprise Processes. In Proceedings of

The 12th International Conference on Advanced Information Systems (CAiSE’2000), Stock-

holm, Sweden, 2000.

9. 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 Inter-

national Conference on Advanced Information Systems (CAiSE’2004), Riga, Latvia, 2004.