composite web services provisioning in dynamic environments

Composite Web Services Provisioning

in Dynamic Environments

A dissertation submitted in fulfillment

of the requirements for the degree of

Doctor of Philosophy

in

Computer Science and Engineering

Quanzheng Sheng

Supervisor: A/Prof. Boualem Benatallah

March 07th, 2006

c© Copyright by

Quanzheng Sheng

2006

ORIGINALITY STATEMENT

“I hereby declare that this submission is my own work and to the best of my knowledge

it contains no materials previously published or written byanother person, or substan-

tial proportions of material which have been accepted for the award of any other degree

or diploma at UNSW or any other educational institution, except where due acknowl-

edgement is made in the thesis. Any contribution made to the research by others, with

whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis.

I also declare that the intellectual content of this thesis is the product of my own work,

except to the extent that assistance from others in the project’s design and conception

or in style, presentation and linguistic expression is acknowledged.”

Quanzheng Sheng

March 07th, 2006

To my mother and father,

my wife and my little princess,

my brothers,

who made all of this possible,

for their endless encouragement and patience.

ACKNOWLEDGMENTS

It has been a great pleasure working with the faculty, staff,students at the University of

New South Wales (UNSW), during my tenure as a doctoral student, and I would like

to thank them all for such a great graduate school experience. My foremost thank goes

to my thesis supervisor Dr. Boualem Benatallah, a talented teacher and passionate

scientist. Boualem instilled a thirst for excellence in me, taught me how to do high-

quality research, and helped me think independently and creatively. He not only guided

my research, but also served as a mentor and role model as I embarked on my academic

career. I will forever cherish his full support during my study. I also would like to thank

Prof. Anne Hee Hiong Ngu, who first introduced me to UNSW as a visiting research

fellow and opened the door for my academic journey.

I thank my co-authors: Boualem Benatallah, Marlon Dumas, Marie Fauvet, Za-

karia Maamar, Eileen Oi-Yan Mak, Bill McIver, Mehregan Mahdavi, Anne H.H. Ngu,

Phuong Nguyen, Lionel Port, Fethi Rabhi, and Rayan Stephan, for their productive

and enjoyable collaborations. I would like also to thank anonymous reviewers for their

valuable comments on earlier drafts of my papers.

I owe a huge debt of gratitude to my mother, my brother (Xingzheng), my wife,

and my little princess for their constant support and encouragement. They have been

always being there whenever I needed them. I express my most heartfelt thanks to

my father and my eldest brother (Guanzheng), although they will never have a chance

to read or hear my gratitude. They always supported and encouraged me to pursue a

Ph.D. even when I was little.

Finally, I express my sincere appreciation to UNSW, who provided the University

Postgraduate Award (UPA) scholarship and the Supplementary Engineering Award

(SEA) scholarship, to financially support my work in this dissertation.

iv

ABSTRACT OF THEDISSERTATION

Composite Web Services Provisioning in DynamicEnvironments

by

Quanzheng Sheng

Doctor of Philosophy in Computer Science and Engineering

The University of New South Wales, 2006

Web services composition is emerging as a promising technology for the effective

automation of application-to-application collaborations. The application integration

problems have been subject of much research in the past years. However, with growth

in importance of business process automation and highly dynamic nature of the Inter-

net, this research has taken on a new significance and importance. Adequate solutions

to this problem will be very important to make enterprise systems more flexible, robust

and usable in the future.

In this dissertation, we present a novel approach for the declarative definition and

scalable orchestration of composite Web services in large,autonomous, heterogeneous,

and dynamic environments. We first propose a composition model for composing Web

services in a personalized and adaptive manner. We model composite Web services

based on statecharts. To cater for large amounts of dynamic Web services, we use

the concept ofservice communitythat groups services together and is responsible for

the runtime selection of services against user’s preferences. We use the concept of

process schemathat specific users can adjust with their personal preferences. A set

of exception handling policiescan be specified to proactively react to runtime excep-

tions. We then propose a tuple space based service orchestration model for distributed,

v

vi

self-managed composite services execution. We introduce the concept ofexecution

controller that is associated with a service and is responsible for monitoring and con-

trolling service executions. The knowledge required by a controller is statically ex-

tracted from the specification of personalized composite services. We also present

techniques for robust Web services provisioning. The techniques presented in this dis-

sertation are implemented inSelf-Serv, a prototype that provides a set of tools for Web

service composition and execution. Finally, we conduct an extensive usability and per-

formance study of the proposed techniques. The experimental results reveal that our

system i) provides an efficient support for specifying, deploying, and accessing com-

posite services; ii) is more scalable and outperforms the centralized approach when

the exchanged messages become bigger; and iii) is more robust and adaptive in highly

dynamic environments.

TABLE OF CONTENTS

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Web Services Composition . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Digital Class Assistant: An Example . . . . . . . . . . . . . . . . . . 4

1.3 Research Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Contributions Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.1 Personalized and Adaptive Composition of Web Services. . . 9

1.4.2 Tuple Space Driven Service Orchestration . . . . . . . . . .. 10

1.4.3 Robust Web Services Provisioning . . . . . . . . . . . . . . . 11

1.4.4 Implementation and Performance Study . . . . . . . . . . . . 12

1.5 Dissertation Organization . . . . . . . . . . . . . . . . . . . . . . . .12

2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 Composite Web Services Provisioning: Preliminaries . . .. . . . . . 15

2.1.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.2 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Requirements for Composite Web Services Provisioning . . .. . . . 25

2.2.1 Service Composition Modeling . . . . . . . . . . . . . . . . 25

2.2.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.3 Adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.4 Personalization . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Research Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

CONTENTS viii

2.3.1 Overview of Research Prototypes . . . . . . . . . . . . . . . 29

2.3.2 Research Prototype Comparison . . . . . . . . . . . . . . . . 35

2.4 Standardization Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3 A Personalized and Adaptive Composition Model for Web Services . . . 45

3.1 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2 Process Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.2.1 Overview of Statecharts . . . . . . . . . . . . . . . . . . . . 49

3.2.2 Data Dependencies . . . . . . . . . . . . . . . . . . . . . . . 52

3.3 Service Communities . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3.1 Service Registration . . . . . . . . . . . . . . . . . . . . . . 57

3.3.2 Multi-Attribute Service Selection Policies . . . . . . .. . . . 59

3.4 User Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.4.1 Context Constraints . . . . . . . . . . . . . . . . . . . . . . . 63

3.4.2 Data Supply and Delivery Preferences . . . . . . . . . . . . . 67

3.4.3 Service Selection Preferences . . . . . . . . . . . . . . . . . 68

3.5 Multi-Level Exception Handling Policies . . . . . . . . . . . .. . . 69

3.5.1 Exception Types . . . . . . . . . . . . . . . . . . . . . . . . 70

3.5.2 Exception Handling Policies . . . . . . . . . . . . . . . . . . 72

3.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.6.1 Web Service Standards . . . . . . . . . . . . . . . . . . . . . 75

3.6.2 Component-Based Middlewares . . . . . . . . . . . . . . . . 76

CONTENTS ix

3.6.3 Web Service Composition Approaches . . . . . . . . . . . . 77

3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4 Tuple Space-Driven Service Orchestration . . . . . . . . . . . . . . . . 81

4.1 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.2 An Orchestration Example . . . . . . . . . . . . . . . . . . . . . . . 86

4.3 Tuple Spaces and Control Tuples . . . . . . . . . . . . . . . . . . . . 89

4.3.1 Tuple Spaces: An Overview . . . . . . . . . . . . . . . . . . 89

4.3.2 Control Tuples . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.4 Service Orchestration Tuples . . . . . . . . . . . . . . . . . . . . . .93

4.4.1 Service Invocation Tuples . . . . . . . . . . . . . . . . . . . 93

4.4.2 Exception Handling Tuples . . . . . . . . . . . . . . . . . . . 97

4.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.5 Control Tuples Generation . . . . . . . . . . . . . . . . . . . . . . . 100

4.5.1 Pre-Invocation Tuples Generation . . . . . . . . . . . . . . . 100

4.5.2 Post-Invocation Tuples Generation . . . . . . . . . . . . . . .102

4.5.3 Exception Handling Tuples Generation . . . . . . . . . . . . 104

4.6 Control Tuples Enforcement . . . . . . . . . . . . . . . . . . . . . . 105

4.7 Analysis of Centralized and Distributed Orchestration .. . . . . . . . 108

4.7.1 Scalability and Performance . . . . . . . . . . . . . . . . . . 109

4.7.2 Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 110

4.8 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

CONTENTS x

5 Robust Web Services Provisioning. . . . . . . . . . . . . . . . . . . . . 117

5.1 The Proposed Model for Robust Service Provisioning . . . . .. . . . 118

5.1.1 Mobile Web Services . . . . . . . . . . . . . . . . . . . . . . 118

5.1.2 Robust Services Provisioning . . . . . . . . . . . . . . . . . 120

5.2 Resources Matchmaking . . . . . . . . . . . . . . . . . . . . . . . . 123

5.2.1 Advertising Services and Resources . . . . . . . . . . . . . . 123

5.2.2 Matchmaking Process . . . . . . . . . . . . . . . . . . . . . 129

5.2.3 Resources Selection . . . . . . . . . . . . . . . . . . . . . . 132

5.3 Composite Service Execution Planning . . . . . . . . . . . . . . . .. 135

5.3.1 Execution Plan: An Overview . . . . . . . . . . . . . . . . . 136

5.3.2 A Multi-Phase Execution Planning . . . . . . . . . . . . . . . 136

5.3.3 Interleaving Service Execution and Planning . . . . . . .. . 140

5.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

5.4.1 Web Service Provisioning Approaches . . . . . . . . . . . . . 144

5.4.2 Matchmaking Approaches and Load Balancing Architectures 146

5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6 Implementation and Performance Study . . . . . . . . . . . . . . . . . 149

6.1 Self-Serv Prototype: An Overview . . . . . . . . . . . . . . . . . . .150

6.2 Service Composition Environment . . . . . . . . . . . . . . . . . . . 153

6.2.1 Service/Resource Discovery Engine . . . . . . . . . . . . . . 153

6.2.2 Service Builder and Service Planner . . . . . . . . . . . . . . 156

6.2.3 Service Deployer . . . . . . . . . . . . . . . . . . . . . . . . 157

CONTENTS xi

6.3 Service Execution Environment . . . . . . . . . . . . . . . . . . . . 158

6.3.1 Execution Controller . . . . . . . . . . . . . . . . . . . . . . 158

6.3.2 Event Manager and Context Manager . . . . . . . . . . . . . 159

6.3.3 Service Migrator . . . . . . . . . . . . . . . . . . . . . . . . 160

6.4 Demo Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

6.5 Usability and Performance Study . . . . . . . . . . . . . . . . . . . .166

6.5.1 Usability Evaluation . . . . . . . . . . . . . . . . . . . . . . 167

6.5.2 Performance Evaluation . . . . . . . . . . . . . . . . . . . . 170

6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

7.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

A Curriculum Vitae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

L IST OF FIGURES

1.1 An example of service composition . . . . . . . . . . . . . . . . . . 3

1.2 Composing class attendance services . . . . . . . . . . . . . . . . .. 6

2.1 Web service interaction model . . . . . . . . . . . . . . . . . . . . . 17

2.2 Workflow system characteristics . . . . . . . . . . . . . . . . . . . .23

2.3 A high level overview of the interaction of two companiesconducting

a business process using ebXML . . . . . . . . . . . . . . . . . . . . 39

2.4 Top level of service ontology . . . . . . . . . . . . . . . . . . . . . . 41

3.1 UML class diagram for personalized service compositionmodel . . . 47

3.2 The process schema of the digital class assistant . . . . . .. . . . . . 51

3.3 The UML class diagram of the community model . . . . . . . . . . .55

3.4 The detailed community model . . . . . . . . . . . . . . . . . . . . . 56

3.5 Signatures of the operations of communityCBS-UNSW and service

CBS-K17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.6 A fraction of the mapping script . . . . . . . . . . . . . . . . . . . . 58

3.7 Syntax of extended Ponder obligation policies . . . . . . . .. . . . . 73

4.1 Tuple space based service orchestration . . . . . . . . . . . . .. . . 84

4.2 Interactions between the controllers and the componentservices dur-

ing an execution of digital class assistant . . . . . . . . . . . . . .. . 87

4.3 Tuple space operations . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.4 Algorithm for generation of pre-invocation tuples (PreInv) . . . . . . 101

xii

LIST OF FIGURES xiii

4.5 Cartesian production of ECA rule sets . . . . . . . . . . . . . . . . . 102

4.6 Algorithm for generation of post-invocation tuples (PostInv) . . . . . 103

4.7 Interactions of control tuple enforcement . . . . . . . . . . .. . . . . 107

4.8 Control-flow and data-flow notifications of (a) centralized and (b) dis-

tributed orchestration approach . . . . . . . . . . . . . . . . . . . . . 109

4.9 Worst-case scenario for the distributed orchestrationapproach. . . . . 112

5.1 Interactions of service migration . . . . . . . . . . . . . . . . . .. . 122

5.2 Very large data flow between two Web services . . . . . . . . . . .. 128

5.3 Interactions in the matchmaking process . . . . . . . . . . . . .. . . 130

5.4 A matchmaking example . . . . . . . . . . . . . . . . . . . . . . . . 131

5.5 (a) Matched resources of the digital class assistant service; (b) domains

of the matched resources . . . . . . . . . . . . . . . . . . . . . . . . 138

5.6 Interleaving service planning and execution . . . . . . . . .. . . . . 142

6.1 Architecture of Self-Serv system . . . . . . . . . . . . . . . . . . .. 151

6.2 Defining services in Self-Serv . . . . . . . . . . . . . . . . . . . . . 162

6.3 Configuration of process schemas on PDAs . . . . . . . . . . . . . . 163

6.4 Deploying control tuples . . . . . . . . . . . . . . . . . . . . . . . . 164

6.5 Execution of the composite service . . . . . . . . . . . . . . . . . .. 165

6.6 The responses to the willingness of using Self-Serv . . . .. . . . . . 167

6.7 The time used for specifying the digital class assistantservice . . . . . 168

6.8 Workload allocation in the execution of the class assistant service in:

(a) case 1, and (b) case 2 . . . . . . . . . . . . . . . . . . . . . . . . 174

LIST OF FIGURES xiv

6.9 The response time of the composite serviceCAS . . . . . . . . . . . . 176

6.10 System performance with and withoutTimeout policy . . . . . . . 178

L IST OF TABLES

1.1 Digital class attendance services . . . . . . . . . . . . . . . . . .. . 5

2.1 Comparison: prototypes vs. service composition requirements . . . . 35

3.1 Data dependencies of the class assistant process schema. . . . . . . . 54

3.2 Service selection attributes . . . . . . . . . . . . . . . . . . . . . .. 60

3.3 Temporal and spatial constraints of class assistant schema . . . . . . . 66

3.4 Selected exception events . . . . . . . . . . . . . . . . . . . . . . . . 71

3.5 Example exception handling policies . . . . . . . . . . . . . . . .. . 74

4.1 Operation primitives of tuple spaces . . . . . . . . . . . . . . . .. . 90

4.2 Selected events supported in our system . . . . . . . . . . . . . .. . 93

4.3 Selected actions supported in our system . . . . . . . . . . . . .. . . 94

5.1 Data model describing a workstation . . . . . . . . . . . . . . . . .. 125

5.2 Pricing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.3 Data model describing a service . . . . . . . . . . . . . . . . . . . . 127

5.4 Pseudocode for resource matchmaking . . . . . . . . . . . . . . . .. 133

5.5 Algorithm for composite service resource selection . . .. . . . . . . 141

6.1 Enabling technologies in Self-Serv . . . . . . . . . . . . . . . . .. . 152

6.2 Example of RDF schema . . . . . . . . . . . . . . . . . . . . . . . . 154

6.3 Example of RDF description . . . . . . . . . . . . . . . . . . . . . . 155

6.4 serviceType tModel . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

xv

LIST OF TABLES xvi

6.5 Evaluation results of the system design . . . . . . . . . . . . . .. . . 169

6.6 The deployment cost of composite services. . . . . . . . . . . .. . . 171

6.7 The number of exchanged messages in the execution of the class as-

sistant service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Chapter 1

Introduction

During the past decade, the Web is more and more being used as aplatform for exe-

cuting complex distributed systems and performing application integration, rather than

a simple Web interface for content publishing [6, 33, 24, 39]. The driving force be-

hind this evolution is the concept ofWeb services. A Web service is essentially a

semantically well defined abstraction of a set of computational and/or physical activi-

ties involving a number of resources, intended to fulfill a customer need or a business

requirement. A Web service allows applications and/or other services to program-

matically interact with, for example, information sources, application programs, and

business processes. Web services can be described, advertized, and discovered us-

ing (XML-based) standard languages, and interacted through standard Internet pro-

tocols1. An example of a Web service is a flight booking system accessible through

SOAP [155].

With the technologies of Web services, enterprises nowadays are able to expose

their internal business processes as services and make themaccessible via the Inter-

net. For example, Google2 recently provides a Web service calledGoogle Web APIs

service [79], with which software developers can query billions of Web pages directly

from their own computer programs. As a sign of their ubiquity, Web services are even

1A detailed discussion of Web services can be found in Section2.1.1.2http://www.google.com.

http://www.google.com

Chapter 1. Introduction 2

accessible from mobile devices [46]. Indeed, the proliferation of such devices (e.g.,

laptops, PDAs, 3G mobile phones) and the deployment of more sophisticated wireless

communication infrastructures (e.g., GPRS [74] and UMTS [171]), are empowering

the Web with the ability to deliver data and services to mobile users.

Web services offer tremendous opportunities for automating information manage-

ment in a variety of application domains including office tasks, travel, intelligent in-

formation gathering, and analysis. However, enjoying suchbenefits using current Web

technologies is a time-consuming and cumbersome process because users often need

access to a large number of heterogeneous and distributed data sources in order to

perform desired tasks. For example, travelers may need to access several Web portals

separately, manually filter and organize the search resultsto get the information they

need. This ad-hoc process of searching and combining required services has largely

hampered a faster pace in allowing users to automate their tasks.

This chapter is organized as follows. In Section 1.1, we briefly discuss Web ser-

vices composition. In Section 1.2, we depict a case study, which will be used as an

example throughout this dissertation. In Section 1.3, we outline the research issues

tackled in this dissertation. In Section 1.4, we summarize our contributions, and in

Section 1.5, we describe the structure of this dissertation.

1.1 Web Services Composition

Web services can be composed with each other in the context ofinter-organisational

business processes, leading tocomposite (Web) services[17, 40, 117, 121]. Compos-

ite services allow organisations to form alliances, to outsource functionalities, and to

provide one-stop shops for their customers. For example, Figure 1.1 illustrates a travel

planning system, which is a composite service that integrates flight booking, accom-


Travel planning service

Hotel booking provider

Traveller

Travel insurance company

Flight booking provider

Car rental company

travel insurance service

flight booking service

hotel booking service

car rental service

Web services

Figure 1.1: An example of service composition

modation booking, travel insurance, and car rental Web services.

In the recent years, Web services composition is emerging asa promising tech-

nology for the effective automation of application-to-application collaborations and

attracts a significant industry and research interest [7, 15, 50, 39, 117]. This is mainly

motivated by three factors. Firstly, the adoption of XML-based messaging over well-

established and ubiquitous protocols (e.g., HTTP) enablescommunication among dis-

parate systems. Secondly, the use of a document-based messaging model in Web ser-

vices caters for loosely coupled relationships among organization’s applications. This

is in contrast with other technologies (e.g., component-based softwares [62, 54]) that

generally use object-based communication where the coupling between applications

is tight. Finally, tomorrow’s Web is expected to be highly populated by Web services.

Almost every asset would be turned into a Web service to drivenew revenue streams

and create new efficiencies [6, 139].


From a business perspective, service composition providesa number of bene-

fits [89]:

• Service composition allows enterprises to minimize the amount of coding work

for building new business functionalities, ensuring the quick delivery of new

business services to synchronize with frequent business shifts.

• Service composition dramatically reduces the cost and risks for building new

business applications in the sense that existing business logics are represented as

Web services and can be reused.

• Service composition reduces the complexity—requiring less skills and efforts—

in building new business applications.

The service composition problems have been subject of much research in the past

years. However, with growth in importance of business process automation and highly

dynamic nature of the Internet, this research has taken on a new significance and impor-

tance. Adequate solutions to this problem will be very important for making enterprise

systems more flexible, robust and usable in the future.

1.2 Digital Class Assistant: An Example

While the outcomes of our research are generic enough to be applicable to a wide

range of applications, we use thedigital class assistantas a running example. One of

the major concerns of the digital class assistant is to enhance participation of students

in the classrooms using information and communication technologies [152, 144, 81].

The motivation is based on a number of observations of traditional class attendance

behavior. Firstly, class participation is likely to decrease when the size of classes grows

because some students are reluctant to ask questions in front of large groups. Secondly,


Service Name Service DescriptionAttendance Reminder Sending a reminding message at a given amount time (e.g., 15 min-

utes) before the lecture begins.Attendance Guide Suggesting an optimal route to the lecture room based on student’s

current location.Lecture Notes Outliner Taking the lecture notes and producing a sketch of the lecture.Question Browser Displaying questions asked by students. The questions are stored in

a database.Question Voter Voting a particular question.Question Poster Posting a new question.Consultation Booker Booking a consultation with the lecturer.Lecture Feedback ProviderProviding feedbacks to the lecturer about the lecture.

Table 1.1: Digital class attendance services

students may be late for or miss lectures if they are not familiar with the campus or

forget the attendance. Thirdly, students often need to visit different physical sites

for the accomplishment of relevant class attendance activities. For example, students

need to go to labs for printing lecture notes, and classroomsfor attending lectures. To

provide their feedbacks of a lecture, students have to either approach the lecturer and

communicate with her, or go to the school office and manually fill out a paper form.

The difficulty and cumbersome in managing class activities prevent students from

achieving satisfying learning efficiency and also hamper the interactions between stu-

dents and lecturers. For example, students may give up providing their feedbacks if

they do not want to speak to lecturers and are fed up with filling out feedback forms.

To overcome above limitations, we organize class related activities asWeb services,

shown in Table 1.1. Students can invoke these Web services toaccomplish relevant ac-

tivities. Furthermore, these services can be composed together to form adigital class

assistantservice that provides a “completed” class attendance experience for students.

Planning such a service for more efficient class attendance generally needs to meet

severalsub-requests, where each sub-request would be performed by executing oneor

more class attendance Web services (see Figure 1.2). The following depicts typical


Remind and prepare the class attendance

Manage question asking activities

Book consultation and provide feedback

Sub-request SR1 Sub-request SR2 Sub-request SR3

Class Attendance Services

Composing Services for SR1



Figure 1.2: Composing class attendance services

scenarios of the different parts of such a digital class assistant service.

SR1: Remind and Prepare the Class Attendance. Assume that a college student Andrew,

who was relaxing on the lawn outside the library after an exhausting Calculus exam, is sud-

denly awoken by his PDA, which reminds him that the Java lecture is in 15 minutes. Andrew

is grateful that he had set this reminder, otherwise he would have missed the lecture! With the

guidance of his PDA, Andrew arrives at the lecture hall just in time. On his road to the lecture,

Andrew also listens to his PDA and gets aware of the main topics that are goingto be taught

in the lecture.

SR2: Manage Question Asking Activities. Ten minutes later, Andrew is confused about

the concept ofArrays-of-Arrays and struggles with how an array can be inside another

array. Because no other classmate seems to be lost, Andrew does not want to raise his hand.

Instead, he decides to ask his question using theclass assistantservice via his PDA. Soon

after posting the question, many students vote for it and the question receives the highest score

among all questions. During the break, the lecturer checks his laptop, where an application

displays the posted questions from students, and notices that students are concerned about

Arrays-of-Arrays. Noticing that many students did not grasp the concept, the lecturer


decides to re-explain it after the break. Andrew now understands the concept and enjoys the

rest of the lecture.

SR3: Book Consultation and Provide Feedback. After the lecture, Andrew’s PDA re-

minds him about the consultation booking and lecture feedback. Since Andrew has understood

the whole lecture, he does not need a consultation. He invokes theLecture Feedback

Provider service, fills out the feedback form from his PDA, and commends the lecturer for

his clear explanation and suitable pace of the lecture.

The scenario used in this thesis is actually inspired by two recent ubiquitous com-

puting applications: UIUC’s Gaia [144] and, to a greater extent, UCSD’s Active-

Class [81]. The digital class attendance services provide a number of distinct features

like: i) students are encouraged to ask questions anonymously without exposing them-

selves to the class, thereby avoiding the problems associated with the traditional prac-

tice of raise-hand-upasking in which those students who are diffident are unlikelyto

ask any questions; ii) students can vote for the questions asked by others, which helps

lecturers to identify the most concerned questions; and iii) students provide comments

on the lectures so that lecturers are able to improve them.

It should be noted that introducing digital class attendance services does not ex-

clude the experiences in traditional classrooms, which on the contrary, provides more

choices for students. For example, students can ask questions either by using their

portable computing devices (e.g., PDAs) or by raising theirhands and verbalizing the

questions directly to the lecturers.

1.3 Research Issues

As noticed in the aforementioned example, composing Web services raises the follow-

ing key issues:


• Rapid and personalized service composition:The why part of Web services

composition is widely understood [132]. However, the technology (i.e, thehow

part) to compose Web services in appropriate time-frames has not kept pace with

the growth and volatility of available opportunities. Indeed, the development of

integrated Web services is still largely ad-hoc, time-consuming and requiring a

considerable effort of low-level programming. This approach is hardly applica-

ble because of the volatility and size of the Web. More agile approaches (e.g.

model-driven) to service composition are therefore required. In addition, users

may need to specify contextual preferences and constraintsregarding the enact-

ment of service compositions (e.g., where and when they wishto interact with

the services). For example, Andrew may prefer that the attendance reminder

service sends him the reminding message 15 minutes before the lecture begins.

• Adaptation to large and dynamic environments: The set of services to be

composed may be large and continuously changing [18]. Consequently, ap-

proaches where the development of a composite service requires the understand-

ing of each of the underlying services are inappropriate. Instead, a divide-and-

conquer approach should be adopted, whereby services addressing similar cus-

tomer needs (i.e.,substitutable services) are grouped together, and these groups

take over some of the responsibilities of service composition.

• Distributed orchestration: The orchestration of composite services in existing

techniques is usually centralized, whereas the participating services are natu-

rally distributed and autonomous. A centralized orchestration model has several

drawbacks with respect to scalability and availability [45]. Given the highly

dynamic and distributed nature of Web services, we believe that novel tech-

niques involving peer-to-peer orchestration of services will become increasingly

attractive. In a peer-to-peer execution model, distributed service components of


similar capacity collaborate directly with each other without the need to estab-

lish a hierarchical relationship between them. Peer-to-peer computing is gaining

a considerable momentum, as it naturally exploits the distributed nature of the

Internet [184].

• Adaptive and reliable services provisioning.There are multiple situations that

could hinder a smooth execution of Web services. Indeed, obstacles range from

the dynamic nature of the Web services such as variations of Quality of Service

(QoS) to the changes of user requirements. We advocate that services should be

self-managedto support their adaptive execution over the Internet. To facilitate

the flexible execution of services, it is necessary to provide the capabilities for

detecting the exceptions at run-time so that appropriate actions can be promptly

taken.

1.4 Contributions Overview

We propose a generic approach for the provisioning of composite Web services in

dynamic and distributed environments. We also provide an implementation of our

approach in theSelf-Serv(compoSing wEb accessibLe inFormation & buSiness sER-

Vices) prototype [151]. In particular, the main research contribution in this thesis

focuses on the following:

1.4.1 Personalized and Adaptive Composition of Web Services

We propose a service composition model where Web services can be composed in

a personalized and adaptive manner [152, 19, 17, 153]. We model composite Web

services based on statecharts [85]: a widely used formalismin the area of reactive

systems, which is emerging as a standard for process modeling as it has been inte-


grated into the Unified Modeling Language (UML) [167]. Statecharts possess a formal

semantics and support the expression of control-flow dependencies found in existing

process description languages such as sequence, branching, merging, concurrency, etc.

To cater for the large amount and dynamic nature of Web services, we exploit a

divide-and-conquer approach that groups services intocommunities[19]. Service com-

munities are essentially containers of substitutable services. They provide descriptions

of desired services (e.g., providing flight booking interfaces) without referring to any

actual provider. Actual providers can register with any community of interest to offer

the desired service. At run-time, the community is responsible for selecting the service

offer that best fits a particular user profile in a specific situation.

To speed up and ease the development of composite services, we use the concept of

process schema, which is a reusable and extensible business process skeleton devised

to reach a particular goal. Users can then adjust this process schema with their personal

contextual preferences and constraints, rather than building a new service from scratch.

To handle the exceptions (e.g., service failures, network errors) happened in the

service provisioning, we develop apolicy-based approachwhere a set of exception

handling policies can be specified to proactively react to runtime exceptions. Poli-

cies are expressed and controlled at a high level of abstraction, separating from the

composite service’s functionality. In this way, service designers can dynamically add,

remove, and modify policies, to reconfigure the composite services without changing

composite service functionalities (e.g., control flow embedded in statecharts).

1.4.2 Tuple Space Driven Service Orchestration

We propose a distributed, tuple space based composite service execution model to

achieve flexible and scalable execution of composite services in dynamic environ-

ments [152, 153]. In our model, the execution of participating services of compos-


ite services isself-managed: they are capable of coordinating their actions in an au-

tonomous way, without having to continuously synchronize with a central entity. The

self-orchestration is achieved by means ofexecution controllers. A controller is asso-

ciated with a service and is responsible for monitoring and controlling service execu-

tions. The knowledge required by a controller is staticallyextracted from the specifi-

cation of composite services.

To deal with the dynamic issues (e.g., disconnection) of theservice provisioning

environments, we propose atuple spaces[4] based orchestration model where the

knowledge of the service orchestration is represented in the form of control tuples

that are placed in and retrieved from the tuple spaces associated with the services.

The control tuples are represented as event-condition-action (ECA) rules where the

orchestration of composite services is based on an event triggering mechanism. The

communications of the service orchestration are asynchronous and de-coupled in both

time and place.

1.4.3 Robust Web Services Provisioning

We propose novel techniques for robust Web services provisioning [113, 114, 112].

We extend the system model and introduce a new component calledservice migrator.

A service migrator, which is associated with a mobile Web service, can instantiate

an instance of the service at appropriate idle computing resources during runtime on

demand and therefore, reduces the risk of the service being unavailable. Furthermore,

due to load balancing, a faster processing of service requests can be achieved.

To facilitate dynamic resources selection, we introduce a flexible, semi-structured

data model for the description of services and resources, aswell as amatchmaking

algorithm for selecting computing resources against the requirements of Web services.

To achieve optimized overall performance of a composite service, we propose a multi-


phase execution planning approach where resources are selected for the components

of the composite service based on a number of criteria such ascommunication cost.

1.4.4 Implementation and Performance Study

We provide an implementation of proposed techniques insidethe Self-Serv proto-

type [151, 154, 19]. We adopt a number of state-of-the-art technologies for the imple-

mentation of the prototype, including emerging Web servicestandards like WSDL [49],

SOAP [155], and UDDI [10]. We develop a comprehensive platform for Web services

creation, composition, and invocation in distributed and dynamic environments.

To validate the feasibility and benefits of our approach, we develop several compos-

ite services using the prototype system and conduct an extensive performance study.

First, we investigate the potential usage of the proposed service composition platform

via a usability study. Second, we study the performance of our approach from various

aspects including scalability, execution cost, and adaptation effectiveness.

1.5 Dissertation Organization

The remainder of this dissertation is organized as follows.In Chapter 2, we introduce

some basic concepts related to Web services composition andpresent the state of the

art in research and standardization efforts. Especially, we overview the representative

research approaches and standardization efforts, and compare them with respect to a

set of service composition requirements.

In Chapter 3, we present the details of the proposed service composition model. In

particular, we introduce the concept of process schema and service community. We

describe the mechanisms for configuring process schemas using user preferences and

introduce a policy-based, multi-level exception handlingmodel for composite Web


services.

In Chapter 4, we give a detailed description of our proposed composite service exe-

cution model. We first illustrate the basic ideas of the execution model using the digital

class assistant example. We then provide details of the service orchestration tuples (i.e.,

pre-invocation tuples, post-invocation tuples, and exception handling tuples) that are

used in our execution model and show how they are used to achieve self-orchestration.

We describe the algorithms for the generation of control tuples from composite service

definitions and discuss the control tuples enforcement. We also analyze the centralized

and distributed orchestration approaches from different aspects.

In Chapter 5, we describe the techniques—proposed on top of the models we in-

troduced in Chapter 3 and 4—for robust Web services provisioning. In particular,

we introduce the functionalities of service migrators and their interactions with other

components such as service controllers, matchmaker, and computing resources. We

present a data model for describing services and resources,and an algorithm for re-

sources matchmaking. We also propose a multi-phase execution planning algorithm

for composite services.

In Chapter 6, we describe the implementation of our approach for service compo-

sition in the Self-Serv prototype. We also report the results of a usability study and a

set of performance studies of our service composition approach. Finally, in Chapter 7,

we provide concluding remarks of this dissertation and discuss directions for future

research.

Chapter 2

Background

No research work ever stands on its own. Especially as Brian K.Reid [71] stated:

“ In computer science, we stand on each other’s feet”. In this chapter, we give an

introduction to the research fields of Web service composition. We overview some

major techniques, research prototypes, and standards for Web services composition, to

help readers gain a better understanding of the work described in this dissertation.

This chapter is organized as follows. In Section 2.1, we firstintroduce some ba-

sic concepts and terminologies related to Web service composition. In Section 2.2,

we identify a set of requirements in terms of Web services composition. Then in

Section 2.3 and Section 2.4, we overview representative research prototypes and stan-

dardization efforts of Web service composition, and compare them with respect to our

proposed requirements. Finally, we summarize this chapterin Section 2.5.

2.1 Composite Web Services Provisioning: Preliminaries

2.1.1 Web Services

The termWeb serviceis used very often nowadays, although not always with the same

meaning. Existing definitions of Web services range from thevery generic and all-

inclusive to the very specific and restrictive. A Web serviceis often seen as an applica-

Chapter 2. Background 16

tion accessible to other applications over the Web [68]. This is a very open definition,

under which almost everything that has a URL is a Web service. It could, for instance,

include a CGI script, or could be a program accessible over theWeb with a stable API.

A more formal definition provided by IBM is that Web Services are “a new breed

of web application, and they are self-contained, self-describing, modular applications

that can be published, located and invoked across the Web” [168]. This definition

is more detailed, placing emphasis on the need to be open, which essentially means

that a Web service has to be published and can be located and invoked over the Web.

However, standards requirement of the Web services is not clearly mentioned in the

definition.

The W3C (World Wide Web Consortium) defines a Web service as “a software

system identified by a URI, whose public interfaces and bindings are defined and de-

scribed using XML. Its definition can be discovered by other software systems. These

systems may then interact with the Web service in a manner prescribed by its defi-

nition, using XML based messages conveyed by Internet protocols” [11]. The W3C

definition stresses that Web services should be able to bedefined, described, anddis-

coveredand clearly mentions the requirements ofInternet-oriented, standards-based

interfaces. In other words, Web services are components that can be integrated into

more complex distributed applications. This interpretation is very much in line with

the perspective we take in this dissertation. It should be noted that W3C also empha-

sises that XML is part of the solution. Indeed, XML is so important for Web services

that sometimes we call Web services asXML Web services. It is also worth mentioning

that it isnot required to manipulate Web services using Web browsers.

Web Service Technologies. Figure 2.1 shows the interactions of the Web service

model. From the figure we can see that there are three roles involved in Web service


Service Requester

Service Provider

Service Registry

SOAP request

SOAP response WSDL

Find

SOAP request WSDL

SOAP response

Publish

SOAP request SOAP response

Invoke/bind

Service Description

Service Interface

Service

Service Description UDDI

Figure 2.1: Web service interaction model

applications:service provider, service registry, andservice requester. The interactions

between three roles arepublish, find and invoke/bind. Web services are implemented

and published by service providers. They are discovered andinvoked by service re-

questers. Information about a Web service (i.e., service descriptions) is kept within a

service registry.

Web services depend on three important standardization initiatives, namely the

Web Services Description Language (WSDL) [49], the Universal Description, Discov-

ery, and Integration (UDDI) [10], and the Simple Object Access Protocol (SOAP) [160].

From Figure 2.1 we can see that service registration, discovery and invocation are

implemented by SOAP calls. First, service provider sends a UDDI SOAP request,

together with the service descriptions (i.e., WSDL) of the Web services, to UDDI reg-

istry operators (e.g., Microsoft UDDI test operator). The acknowledgment of success-


ful registration also returns a SOAP message. After a service is registered in the UDDI

registry, service requester can discover this service fromthe registry. Requester sends

the UDDI SOAP request (e.g., business name, service type etc.) to the UDDI registry.

The registry locates the service and returns its description (WSDL). Then requester in-

vokes the service using the binding details in the service description to locate, contact

and invoke the service.

To help researchers from other areas achieve a better understanding of the work

presented in this dissertation, we give a brief introduction to WSDL, SOAP, and UDDI.

Our experience in using these three components in a service composition prototype is

reported in [154].

• Web Services Description Language(WSDL) [49]: Proposed by IBM and Mi-

crosoft, WSDL is a general purpose XML language for describing the interface,

protocol bindings and the deployment details of Web services. A WSDL doc-

ument describes how to invoke a service. It provides information on the data

being exchanged, the sequence of messages for an operation,the location of the

service and the description of bindings (e.g., SOAP or HTTP).

WSDL descriptions are composed ofinterfaceand implementationdefinitions.

The service interface is an abstract, containing WSDL elements that comprise

thereusableportion of the service description. For example,WSDL:portType

element defines the operations of the Web service, and the input and output pa-

rameters of an operation of the service are defined in theWSDL:message ele-

ment. The service implementation definition describes how aparticular service

interface is implemented by a given service provider.

• Simple Object Access Protocol(SOAP) [160]: SOAP is a lightweight messag-

ing framework for exchanging XML formatted data between Webservices. It


is composed of three parts: i) anenvelopethat defines a framework for describ-

ing what is in a message and how to process it, ii) a set ofencoding rulesfor

expressing instances of application-defined data types, and iii) a conventionfor

representing remote procedure calls and responses. SOAP can be used with a

variety of network protocols such as HTTP, SMTP, and FTP.

• Universal Description, Discovery, and Integration(UDDI) [10]: UDDI is an

industry effort started in September 2000 by Ariba, IBM, Microsoft and other

33 companies. UDDI is a platform-independent, open framework for describing,

discovering, and integrating Web services over the Internet. The core component

of UDDI is an XML repository where Web services are advertised and located.

UDDI provides two basic specifications that define a service registry’s structure

and operation [56]:

– a definition of the information to provide about service and how to encode

it; and

– a query and update API for the registry that describes how service infor-

mation can be accessed and updated.

UDDI encodes three types of information about Web services:i) white pages

information includes name and contact details; ii)yellow pagesinformation pro-

vides a categorization based on business and service types;and iii) green pages

information includes technical data about the services. UDDI registry access is

accomplished using a standard SOAP API for both querying andupdating.

Atomic and Composite Web Services. We distinguish betweenatomicandcom-

positeWeb services. An atomic service (also calledelementary service[151]) is an

access point to an application that does not rely on another Web service to fulfill user


requests. For example,Consultation Booker is an atomic service that helps

students book consultations. Each atomic service providesa programmatic interface

based on SOAP and WSDL [49]. For those legacy applications such as those written

in CORBA, appropriate adapters can be developed so that they can be invoked as Web

services.

A composite service [17, 40, 117] is an umbrella structure that brings together

other composite and atomic services that collaborate to implement a set of operations.

The services brought together by a composite service are referred to as itscomponent

services. An example of a composite service would be a travel preparation service,

integrating services for booking flights, booking hotels, searching for attractions, etc.

Whether atomic or composite, a Web service is specified by anidentifier (e.g.,

URL), a set ofattributes, and a set ofoperations. The attributes of a service provide

information which is useful for the service’s potential consumers (e.g., public key

certificates).

Business Processes.A business process is a set of activities (also called tasks)that

are performed collaboratively to achieve a business objective or goal [179]. The ac-

tivities are related with data/control flows (see Figure 2.2). An activity is typically the

smallest unit of work, performed by executing a program, enacting a human/machine

action, or invoking another business process (we call such process assub-process). For

example, we can have aclass assistant process for the scenario illustrated in

Section 1.2, which helps student manage their class attendance and includes several

activities such as reminding the lecture attendance, asking questions, booking consul-

tations, and providing feedbacks.

Business processes are normally owned by particular organizations. However, the

activities involved in a process can be conducted in different organizations. For in-


stance, while the activities like reminding attendance andasking questions are con-

ducted by the services provided by the university (e.g.,Attendance Reminder

service), the activity of detecting a student’s current location is conducted by a mobile

network operator (e.g.,Vodafone).

Web Service Orchestration. The standard set of Web service technologies (XML,

SOAP, WSDL) provides the means to describe, locate, and invoke a Web service as

an entity in its own right. Although a Web service may expose many operations, each

WSDL file describes fairly atomic, low-level functions. What the basic technologies

do not give us is therich behavioral detail that describes the role the service playsas

part of a larger, more complex collaboration (i.e., business processes).

The description of the sequence of activities that make up a business process is

called an orchestration. Orchestration can therefore be considered as a construct be-

tween an automated process and the individual services which enact the steps in the

process. In other words, the orchestration describes a business process from each inter-

action between two services to complete cases that links together these individual ser-

vice interactions. Orchestration includes the managementof the transactions between

the individual services, including any necessary error handling, as well as describing

the overall process.

It should be noted that service orchestration and servicechoreographyare not the

same [138]. Orchestration refers to an executable businessprocess that can interact

with both internal and external Web services. Orchestration always represents control

from one party’s perspective. This differs from choreography, which is more collab-

orative and allows each involved party to describe its part in the interaction. Chore-

ography tracks the message sequences among multiple parties and sources including

customers, suppliers, and partners. Choreography is typically associated with the pub-


lic message exchanges that occur between multiple Web services rather than a specific

business process that a single party executes.

2.1.2 Workflows

Workflow is a technology that managesbusiness processesautomation [109, 75]. The

Workflow Management Coalition (WfMC) [179] defines a workflow as “the comput-

erized facilitation or automation of a business process, inwhole or part, where doc-

uments, information or tasks are passed between participants according to a defined

set of rules to achieve, or contribute to, an overall business goal”. In this section, we

first introduce the concept of workflow management systems. We then overview the

characteristics of distributed workflow systems.

Workflow Management Systems. Workflow management is a technology that sup-

ports the reengineering of business processes, including the definition, enactment, and

administration of business processes (see Figure 2.2). In [178], the WfMC defines

workflow management system (WFMS) as “a system that defines, creates and man-

ages the execution of workflows through the use of software, running on one or more

workflow engines, which is able to interpret the process definition, interact with work-

flow participants and, where required, invoke the use of IT tools and applications”.

From the definition, we can see that the workflow management mainly involves

the modeling and enactment of workflow specifications. Accordingly, a WFMS con-

sists of two main components: abuildtimecomponent and aruntimecomponent (see

Figure 2.2). The buildtime component provides tools for designers to model, specify,

and analyze business processes. The tools for modeling business processes include

scripting languages (e.g., XPDL [180]) and graph-based process modeling techniques

(e.g., Statecharts [84, 85] and Petri Nets [125]). Meanwhile, the runtime component


Business Process Analysis, Modeling and Definition Tools

Process Definition

Business Processes

Activity

Data/control flow

Workflow Enactment

Service

Process changes

Applications Users

Process define and definition

Process Instantiation and control

Interaction with Users and Applications

Build Time

Run Time

Figure 2.2: Workflow system characteristics

supports the creation, control, and enactment of processes. The core part is a soft-

ware (i.e., workflow enactment service) that is responsiblefor interpreting the process

specification, instantiating the processes, controlling the sequence of activities, and

interacting with users and applications. Some good surveysabout workflows can be

found in [75, 1].

Distributed Workflow Systems. A wide range of products and research projects

provide support for workflow management such as FlowMark, Lotus Notes and Staff-

ware [75]. However, most of these products have been primarily developed for use


within one working environment and are not geared towards department-spanning or

even enterprise-wide workflows. Typically, all the data of the workflow is kept on a

single central server. The most critical deficiencies of such centralized workflows are

the lack of scalability and fault tolerance [122].

Distributed workflow systems—on the other hand—focuses on partitioning the

overall workflow specification into several sub-workflows, and each contains all the

activities that are scheduled to be executed by a given entity within an organization. In

this way, a workflow system can be executed in distributed andheterogeneous environ-

ments [127, 78]. For example, in [127], authors propose an algorithm for transforming

a centralized statechart into a provably equivalent partitioned one that is suitable for

distributed execution.

Although providing some basic mechanisms for describing composite Web ser-

vices, traditional workflow systems do not cater for the dynamic and distributed nature

of service composition [16, 117, 185]. Firstly, distributed workflow systems assume

a tight coupling model among the distributed sub-workflows, which is expensive for

process changes because the new processes must be modeled and deployed across all

the participants. Secondly, most of the existing workflow specification languages—

including the one defined by the WfMC—lack formal semantics, making it difficult

to compare their capabilities and expressiveness in order to make an objective choice

between them. Finally, business workflows are geared for dealing with human users

whereas composite Web services are dealing interactions among autonomous services.

Human users are implicitly represented through the Web services they use.


2.2 Requirements for Composite Web Services Provisioning

Service composition is emerging as a promising paradigm forrapid application de-

velopment, services reuse, and complex service consummation. However, there is no

standard for Web service composition yet and also lacks of definitions of requirements

that service composition approaches must satisfy [121, 20]. In this section, we propose

a set of requirements for Web services composition, which will be used to compare the

existing service composition approaches (see Section 2.3 and Section 2.4).

Overall, the paramount importance for the success of service composition is that

the approach should be able to provide stable and dependablecomposite services. The

issues need to be considered may include:service composition modeling, scalability,

personalization, andadaptability, which we will elaborate in the sequel.

2.2.1 Service Composition Modeling

Composite services typically involve complex business processes, which may include

multiple tasks as well as interactions among these tasks (e.g., control and data flow,

transaction dependencies). Obviously, ad-hoc development of composite services is

time-consuming, inflexible, cumbersome, and error prone, and is therefore hardly ap-

plicable because of the volatility and size of the Web. Current efforts in Web services

composition can be generally grouped into three categories: manual, automatic, and

semi-automaticcomposition. By manual composition, we mean that the composite

service is designed by a human designer (i.e., service provider) and the whole service

composition takes place during the design time. The issues—like what component

services to be used and how these components to be linked—areknown a priori. This

approach works fine as long as the the service environment—business partners and

component services—does not or rarely change.


In contrast,automaticservice composition is sort of “service semantic integration

system”. Automatic service composition approaches typically exploit the Semantic

Web [22] and artificial intelligence (AI) planning techniques. By giving a set of com-

ponent services and a specified requirement (e.g., user’s request), a composite service

specification can be generated automatically [21]. However, realizing a fully auto-

matic service composition is still very difficult and presents several open issues [20].

The basic weakness of most of research efforts proposed so far is that Web services do

not share a full understanding of their semantics, which largely affects the automatic

selection of services. Currently, the first results on automatic composition of Web ser-

vices are those presented in [32, 117, 116, 169] and a comprehensive overview can be

found in [21].

There exist some research efforts that leverage manual and automatic composi-

tions. Instead of coupling component services tightly in the service model, such ap-

proaches feature a high-level abstraction of the process models at the design time,

while the concrete composite services are either generatedautomatically using tools

or decided dynamically at run time. For example, in [157, 12], authors propose some

model-driven approaches for Web services composition. A completed executable ser-

vice specification (e.g., BPEL [7]) can be generated from the composite service spec-

ification (e.g., UML activity model, protocol specifications and interface). In [152],

composite services are specified asprocess schemaand the component services are

selected—at run time—based on the non-functional properties (e.g., QoS parameters)

constraints specified by users. In fact, the idea of semi-automatic service composition

is quite interesting and reasonable at the current stage where fully automating service

composition processes is still the object of ongoing research efforts [156].


2.2.2 Scalability

Composing two Web services is not thesameas composing 50 or 100 services. In

practice, complex composite services (e.g., enterprise applications) may involve many

Web services, possibly several hundred services [121]. Therefore, one critical issue is

that how the proposed composition approachesscalewith the number of component

services. The scalability can be evaluated from two aspects: i) the ease-of-use of the

composite service specification model, and ii) the execution of composite services. For

example, statechart [84] is a scalable process modeling language because it provides

compound statesthat nest one or several statecharts inside a (larger) statechart. A

large composite service can be therefore always modularized into several parts that are

modeled as compound states in a smaller statechart1.

The execution of composite services depends on the composite service orchestra-

tion (i.e., the execution engine that coordinates the execution of composite services).

There are generally two different kinds of approaches:centralizedanddistributed[17].

In the centralized mode, a single execution engine is responsible for the invocation of

composite services, including the enforcement of control flows and message exchanges

among component services. On the other hand, in the distributed mode, the component

services participating in a composite service interact with each other to ensure that the

control and data flow dependencies expressed in the specification of composite service

are respected.

2.2.3 Adaptability

As we mentioned before, Web service environments are highlydynamic where new

Web services may come on-line at any time, existing servicescould be removed or be-

1The detailed discussion of statecharts can be found in Section 3.2.1.


come temporarily unavailable, and the content and the capabilities (e.g, QoS attributes)

of services could be changed. In addition, business environments are also highly dy-

namic (e.g., changes of customer requirements). Therefore, the service composition

approaches should provide composite services that can be able to dynamically adjust

their operations to respond promptly to not only exceptions(e.g., selected component

services are not available), but also opportunities (e.g.,replacing selected component

services with new services offering better QoS).

Adaptability enables the provisioning of reliable composite Web service [55, 94,

173, 100]. Failures for the invocation of composite services could be vital and are

not acceptable for many important Web applications—for example, mission-critical

applications of companies—and therefore, should be avoided as much as possible.

2.2.4 Personalization

Besides the requirement of adaptability,personalizationis another important require-

ments for providing composite services in highly dynamic and distributed environ-

ments. The pervasiveness of the Internet offers the technical possibilities to interact

with services anytime and anywhere. For example, business travelers now expect to

be able to access their corporate servers, enterprise portals, e-mail, and other collabo-

ration services while on the move. Students may book a consultation with professors

using their PDAs at anywhere without approaching a desktop computer in labs. Since

the requirements and preferences of users—either human beings or enterprises—are

varied, it is essential that service composition approaches enable auser-centricand

personalizedservice provisioning [53, 143]. Users should be able to express contex-

tual preferences and constraints regarding the specification and enactment of service

compositions (e.g., where and when they wish to interact with the services, how to

select component services).


The personalization can be tailored to a user group or to an individual. From the

business point of view, personalization is the prime directive for businesses to i) give

customers a high-quality service that they really need, ii)make the interactions efficient

and satisfied, and iii) finally build customer loyalty.

2.3 Research Prototypes

The past half decade has witnessed prosperous research and development activities

on Web services composition. In this section, we overview and compare research

prototypes that support Web service composition. Since there are huge number of

service composition prototypes in the literature, it is impossible for this dissertation to

present an exhaustive overview. Instead, we focus on several representative prototypes.

2.3.1 Overview of Research Prototypes

eFlow. eFlow [40] is a platform for specifying, enacting, and monitoring composite

services. Composite services are specified as business processes that combine basic

and composite services and are enacted by a service process engine. A composite ser-

vice is modeled by a graph that defines the execution sequenceamong nodes in the

process. The graph may includeservice, decision, andeventnodes. Service nodes

represent the invocation of a basic and composite service. Decision nodes specify the

alternatives and rules controlling the execution flow, while event nodes enable service

processes to send and receive several types of events. eFlowprovides a number of fea-

tures that support adaptive service provisioning in dynamic environments, including

dynamic service selection, dynamic conversation selection, andgeneric nodes. eFlow

service nodes include the specification of a service selection rule that is represented

in a query language. When a service node is started, the service selection rule is first


executed to dynamically select an appropriate service. Dynamic conversation selec-

tion allows eFlow to select a corresponding conversation for the selected service at

run-time, which makes the dynamic service selection practical, especially when ser-

vice interfaces are unknown at the design time. Generic service nodes are introduced

to support personalized service composition. Generic nodes are not statically bound

or limited to a specified set of services. Instead, they include a configuration param-

eter that can be set with a list of actual service nodes eitherat runtime or at process

instantiation time.

WISE (Workflow based Internet SErvices). WISE [106, 105] project aims at pro-

viding a software platform for process based business-to-business electronic com-

merce. WISE has both a development environment and a runtime component associate

with it. WISE is organized into three service layers:database services, process ser-

vices, andinterface services. The database service layer acts as the storage manager

of all kinds of system data such as templates (for the structure of processes), instances

(for processes being executed), history (for processes executed), and configuration (for

system related information like access permission, registered users). The process ser-

vice layer contains all the components required for coordinating and monitoring the

execution of processes. Two important components aredispatcherandnavigator. The

dispatcher deals with physical distribution and acts as resource allocator for process

execution, while the navigator acts as the overall scheduler (e.g., deciding what to ex-

ecute next, what needs to be delayed). The interface servicelayer contains interfaces

with which users interact the system. Users specify processes via a process definition

tool named StructWare that is based on Petri-nets [125].

CrossFlow. The CrossFlow project [80] aims at providing high-level support for

workflows in dynamically formed virtual enterprises. The main contribution of the


project is in using the concept ofcontractsas a basic tool for cooperation. Businesses

specify their interactions through contracts. Partially defined contracts can be used by

service providers to advertize their services, and consumers can search for relevant ser-

vices. The CrossFlow architecture supports bothcontract matchmakingandcontract

(service) enactment. When a service provider wants to advertise a service, it usesits

contract manager to send a contract template to a trader. Whena service consumer

wants to outsource the enactment of a service, it uses a contract template to search for

service providers via a trader. When a match between consumers requirements and

providers offer is found, an electronic contract can be madeby filling in the template.

Based on specifications in the contract, a dynamic contract and service enactment ar-

chitecture is set up. The symmetrical architecture contains proxy gateways that control

all communication and support services for advanced cooperation functionality. The

dynamically created modules can be deleted after the contract is completed.

FUSION. FUSION [172] is a comprehensive software system that provides the un-

derlying framework for service portals where by giving a user service specification,

a correct and optimized service execution plan can be automatically generated and

executed, and the results are verified. The system contains six parts: User Specifica-

tion, Web Services Dynamic Plan Generator, Plan Execution, Verification, Recovery,

andUser Response Generation. The user specification part is a graphical form-based

interface that allows users to specify their abstract requirements and convert the spec-

ifications into more structured form for the plan generator.The Web services dynamic

plan generator takes input the user specifications and generates correct and optimized

execution plan. The plan is an expression represented in a language calledWeb Ser-

vices Execution Specification Language(WSESL). The plan execution part mapps the

execution plan into executable code and actually invokes the method instances de-

scribed in the plan. The execution part interacts with i) verification part to make sure


that the service result meets the users satisfied criteria, and ii) recovery part to initi-

ate an appropriate recovery process in case of the failure ofthe verification. Finally,

the user response generation part is responsible for preparing and delivering the final

response to the user.

ServiceGlobe. The ServiceGlobe system [99, 100, 98] is a lightweight, distributed,

and extensible service platform that aims at providing new techniques for Web service

execution and deployment in dynamic environments. To support the development, ex-

ecution, and deployment of flexible and reliable services, ServiceGlobe proposes two

approaches:dynamic service selectionand thedispatcher service. Dynamic service

selection offers Web services the possibility of selectingand invoking services at run-

time based on a technical specification of the desired service. The dispatcher service

addresses load balancing and high availability of Web services. The dispatcher is a

software-based layer-7 switch with the known advantages: it forwards requests to dif-

ferent service instances and therefore reduces the risk of aservice being unavailable

and speeds up request processing because of load balancing respectively load sharing.

In addition, the dispatcher service implements a feature called automatic service repli-

cation. Using this feature new (individually configured) servicescan be installed on

idle hosts on behalf of the dispatcher to use available computational power as good as

possible. ServiceGlobe also implements acontext frameworkthat facilitates the devel-

opment and deployment of context-aware adaptable Web services. In ServiceGlobe,

context is transmitted as a SOAP header block (i.e.,context block) within the SOAP

messages that Web services receive and send. Context processing is done by Web

services, context plugins, or context services.

Mentor. The Mentor project [127, 76] provides support for distributed execution of

workflow systems. Given a workflow specified as a state and an activity chart, Mentor


partitions it into several sub-workflows, each encompassing all the activities that are

to be executed by a given entity within an organisation (thereby assuming that this

information is statically known). Each of these sub-workflows is itself specified as a

statechart. Mentor contains some optimization techniquesthat reduce the number and

the size of the messages exchanged by the sub-workflows, leading to aweak synchro-

nisationmodel. Also in the context of the Mentor project, [76] further considers the

issue of configuring a distributed workflow system in order tomeet performance and

availability constraints while minimising the system costs.

PerCollab. The PerCollab system [42] integrates workflow and collaboration tech-

nologies allowing people to participate in business processes anytime and anywhere

using a traditional collaboration mechanism such as email and short messages (SMS).

PerCollab uses an extended BPEL language to formally define business processes with

human partners and exploits dynamic usercontext(e.g., devices currently used, user lo-

cation) to solve the personal mobility problem. The system proactively engages users

in business processes by pushing interaction to appropriate devices of users. This

functionality is realized by a component calledinteraction controller, which serves as

a proxy for all interacting human entities. The interactioncontroller selects the most

appropriate collaboration modality to reach a user, based on user context information

such as location, activity, and preferences.

SWORD. SWORD [140] provides a set of tools that allows developers to quickly

compose existing Web services to realize new composite Web services. It is interesting

to note that SWORD does not exploit emerging service standards like WSDL and

OWL-S [166], instead, it uses the Entity-Relationship (ER) model [170] to specify

Web services. In SWORD, each service is modeled by its inputs and outputs, which are

specified in a “world model” that consists of entities (e.g.,movies) and relationships


among entities (e.g., a theater shows a movie). To create a composite service, a service

developer only needs to specify the initial and final states of the composite service.

A rule-based expert system is then used to automatically determine whether a desired

composite service can be realized using existing services.If true, SWORD generates

a composition plan for the composite service.

WebDG. The WebDG (Web Digital Government) project [117, 118] provides the

accesses to e-government (composite) Web services via a rich, uniform, and flexible

interface. WebDG enablesautomaticservices composition by dealing with three ma-

jor challenges. Firstly, WebDG presents an ontology-basedframework for organizing

and describing semantic Web services. The concept of community is introduced to

cluster Web services based on their domain of interests. Each community is defined as

an instance of an ontology called community ontology. Then WebDG proposes a com-

posability model to check whether semantic Web services canbe combined together,

hence avoiding unexpected failures at run time. The model defines formal safeguards

for meaningful composition through the use of composability rules. The notions of

composability degree andτ -composability are introduced to cater for partial and to-

tal composability. Finally, based on the composability model, WebDG provides a set

of algorithms that automatically generate detailed descriptions of composite services

from high level specifications of composition requests. Thecomposite services are

specified using a language calledComposition Specification Language(CSL), which

is provided by WebDB. A Quality of Composition (QoC) model is also introduced to

assess the quality of the generated composite services, that can be used to select an

optimal composite service in case there exist multiple composition plans.


Prototype Composition Modeling Personalization Adaptability ScalabilityeFlow graph-based flow structure; dy-

namic service selection at run-time; semi-automatic

customize servicenode creation basedon process schemas

support exceptionhandling, dynamicmodification ofservice processes

centralized executionengine

WISE graph-based StructWare; man-ual

not addressed exception handling in-corporated in the pro-cess language; execu-tion guarantee

distributed executionvia program executionclient (PEC) associat-ing with each servicenode

CrossFlow XML based contract language;manual

not addressed support flexible con-tract changes

distributed execution;participants must in-stall contract runtimeenvironment

FUSION execution plans expressed inWSESL; automatic

not addressed recovery process canroll back to the prob-lematic points

centralized plan exe-cution engine

ServiceGlobe not formally addressed support contextawareness; contexttransmitted withinSOAP messages

dynamic service se-lection; service repli-cation for load balanc-ing

not addressed

Mentor graph-based state and activitychart; manual

not addressed not addressed distributed; work-flows are partitionedinto several sub-workflows

PerCollab an extended BPEL language;manual

support user contextawareness

not addressed centralized; BPEL ex-ecution engine

SWORD rule-based service executionplan; automatic

not addressed not addressed centralized

WebDG semantic description of webservices and composabilityrules; automatic

not addressed not addressed the execution of com-posite services is notformally addressed

Table 2.1: Comparison: prototypes vs. service composition requirements

2.3.2 Research Prototype Comparison

In this section, the aforementioned research prototypes are compared using the require-

ments of Web services composition presented in Section 2.2.Table 2.1 summarizes the

results. For example, eFlow uses a graph-based flow structure to model composite ser-

vices. Since Web services can be selected dynamically for service nodes in process

schemas at rum time, the service composition of eFlow is semi-automatic. eFlow sup-

ports personalization in the sense that users can customizebusiness processes. eFlow

is adaptive because it supports exception handling and dynamic service process mod-

ification. Finally, eFlow is not scalable because it exploits a centralized execution

engine.


From the table we can see that most of the prototypes (e.g., WISE, CrossFlow, and

PerCollab) offer modeling approaches where Web services arecomposed manually.

However, there are some recent research efforts (e.g., WebDG, SWORD, and eFlow)

that provide automatic or semi-automatic service composition modeling approaches.

It is worth mentioning that most approaches neglect the personalization issues of com-

posite services. Only eFlow, ServiceGlobe, and PerCollab support very limited feature

for personalized service provisioning. From the table we also can see that one of the

current trends is to provideadaptiveandscalableservice composition solutions that

offer better quality of composite Web services.

2.4 Standardization Efforts

Efforts are also underway to define standards for composing Web services. In this

section, we overview and compare these standardization efforts. Similarly, we are

not going to give an exhaustive survey, but focus on several representative efforts.

For example, because the Business Process Execution Language for Web Services

(BPEL4WS, or BPEL for short) [7] combines efforts of both the WebServices Flow

Language (WSFL) [108] and XLANG [165], we will only review BPEL.

BPEL. BPEL [7] is an XML language for Web services composition. Developed

by BEA, IBM, Microsoft, SAP, and Siebel, BPEL is currently standardized by OA-

SIS2. In BPEL, the composition result is called aprocess, participating services are

calledpartners, and message exchange or intermediate result transformation is called

anactivity.

BPEL introduces several types of primitive activities to: i)allow for interaction

2The Organization for the Advancement of Structured Information Standards, http://www.oasis-open.org.

http://www.oasis-open.org




with the applications being composed (invoke, reply, andreceive), ii) wait for

some time (wait), iii) copy data from one place to another (assign), iv) indicate er-

ror conditions (throw), v) terminate the entire composition instance (terminate),

or vi) do nothing (empty). These primitive activities can be combined into more

complex ones usingstructuredactivities provided by BPEL. These include the ability

to:

• define an ordered sequence of steps (sequence),

• have branching using the now common “case-statement” approach (switch),

• define a loop (while),

• execute one of several alternative paths (pick), and finally

• indicate that a collection of steps should be executed in parallel (flow). Within

activities executing in parallel, one can indicate execution order constraints by

using links.

BPEL offers the ability to scope activities and specifyfault handlersandcompen-

sation handlersfor scopes. A fault handler gets executed when an exception arises, for

example through the execution of thethrow activity, while compensation handlers

are triggered due to faults or through compensate activities that force compensation of

a scope. To this end, BPEL provides a limited functionality onservices composition

adaptability. However, BPEL, like other standardadizationefforts, does not address

the issue of personalization.

An interesting feature of BPEL4WS is its support for two distinct styles of process

modeling: the graph–oriented style, involving definition of a composition using graph

primitives (nodes and edges), and the “algebraic” style derived from process calculi,

in which complex control constructs (such as the compound activities above) result in


implicit control flow. Each of these alone provides sufficient expressibility. Supporting

both styles gives the designer maximum flexibility to develop a model in the most

intuitive way.

ebXML (Electronic Business Using XML). ebXML [64]—started in 1999 as an

initiative of OASIS and United Nations/ECE agency CEFACT—aimsat defining a set

of specifications for enabling B2B interactions among companies of any size. ebXML

consists of the following major components:

• Messaging Serviceprovides a standard way to exchange business messages be-

tween organizations. One important feature of the messaging service is that it

does not rely on any particular file transport mechanism (such as SMTP, HTTP,

or FTP) or network for actually exchanging the data.

• Registryis a database of items that support doing business electronically. It

stores important information about businesses such as XML schemas of business

documents, definitions of library components for business process modeling,

and trading partner agreements. An original goal of the ebXML registry was

to support a fully distributed, networked set of interacting registries that is an

interesting feature for improving scalability. However, to date, only a single

registry is specified.

• Trading Partner Information.The Collaboration Protocol Profile (CPP) provides

the definition of an XML document that specifies the details ofhow an organi-

zation is able to conduct business electronically. The Collaboration Protocol

Agreement (CPA) specifies the details of how two organizations have agreed to

conduct business electronically. It is formed by combiningthe CPPs of the two

organizations.


Business Profiles

ebXML Registry

Business Scenarios XML Company A

Company B

ebXML compliant system

1 Request business details

2 Build local system

implementation

3 Register implementation details

Register Company A profile

4 Query Company A profile Download scenarios and profiles 5

Agree on business arrangement

6 Do business transactions

Figure 2.3: A high level overview of the interaction of two companies conducting abusiness process using ebXML

• Business Process Specification Schema (BPSS)provides the definition of an

XML document modeling business processes (i.e., compositeservices). It iden-

tifies such things as the overall business process, the roles, transactions, identifi-

cation of the business documents used (the DTDs or schemas),document flow,

legal aspects, security aspects, business level acknowledgments, and status.

Figure 2.3 depicts a sequence of steps, showing how to establish and conduct busi-

ness collaborations between two companies using ebXML architecture. In this ex-

ample, Company A is a service provider while Company B is a service requester.

Company A has become aware of an ebXML Registry that is accessible on the Inter-

net (step 1), and after reviewing the contents of the ebXML Registry, decides to build


and deploy its own ebXML compliant application (step 2). Custom software devel-

opment is not a necessary prerequisite for ebXML participation. ebXML compliant

applications and components may also be commercially available as shrink-wrapped

solutions. Company A then submits its own business profile information (including im-

plementation details and reference links) to the ebXML Registry (step 3). The business

profile submitted to the ebXML Registry describes the company’s ebXML capabilities

and constraints, as well as its supported business scenarios. These business scenarios

are XML versions of the business processes and associated information bundles (e.g.

a sales tax calculation) in which the company is able to engage. After receiving verifi-

cation that the format and usage of a business scenario is correct, an acknowledgment

is sent to Company A (step 3).

Company B discovers the business scenarios supported by Company A in the

ebXML Registry (step 4). Company B sends a request to Company A stating that they

would like to engage in a business scenario using ebXML, and acquires an ebXML

compliant shrink-wrapped application (step 5). Before engaging in the scenario Com-

pany B submits a proposed business arrangement directly to Company A’s ebXML

compliant software interface, which outlines the mutuallyagreed upon business sce-

narios and specific agreements. The business arrangement also contains information

pertaining to the messaging requirements for transactionsto take place, contingency

plans, and security-related requirements (step 5). CompanyA accepts the business

agreement and Company A and B are now ready to engage in eBusiness using ebXML

(step 6).

It should be noted that ebXML specifications are not limited to the above sce-

nario. More complicated service composition scenarios, such as three or more service

providers conducting businesses using shared business processes, are also supported.


Service Resources

ServiceModel

ServiceProfile ServiceGrounding

provide

present

described by

support

What the service does

How the service works

How to access the service

Figure 2.4: Top level of service ontology

OWL-S. OWL-S [166], previously DAML-S (DARPA Agent Markup Language for

Web Services), provides the ability for describing and reasoning over services seman-

tically. As shown in Figure 2.4, OWL-S consists of three upperontologies:service

profile, process model, andgrounding. The service profile is used to describe services

for the purposes of discovery. Service descriptions and queries are constructed from

a description of functional properties (e.g., inputs, outputs, and preconditions) and

non-functional properties (e.g., QoS parameters). In addition, the service profile class

can be subclassed and specialized for the support of creating profile taxonomiesthat

subsequently describe different classes of services.

OWL-S process models describe the composition and executionof Web services.

The process model is used both for reasoning about possible compositions (e.g., val-

idation) and controlling the enactment and invocation of a service. OWL-S defines

three process classes:composite, simple, andatomic. Atomic processes are directly

invocable and have no subprocesses. Simple processes are not invocable and provide

a means of describing service or process abstractions. A simple process does not have

any specific binding to a physical service and thus has to be realized either by an atomic


process, or expanded into a composite process. Composite processes are hierarchi-

cally defined workflows, consisting of atomic, simple and other composite processes.

Composite processes can be constructed using a number of control constructs such as

sequence, unordered, choice, if-then-else, iterate, repeat-until, repeat-while, split, and

split+join.

Finally, the grounding of a service specifies the details of how to access the service.

The process model is mapped to a WSDL description of the service, through a thin

grounding. Each atomic process is mapped to a WSDL operation,and the OWL-S

properties used to represent inputs and outputs are grounded in terms of XML data

types. Additional properties pertaining to the binding of the service are also provided

(e.g., the IP address of the machine hosting the service, theports used to expose the

service).

WSMF. The Web Service Modeling Framework (WSMF) [67] is an Europeanini-

tiative to provide a fully fledged modeling framework for describing various aspects

related to Web services. Its main goal is to fully enable e-Commerce by applying

Semantic Web technology to Web services. WSMF is centered on two complemen-

tary principles: i) a strong de-coupling of the various components that realize an e-

Commerce application, and ii) a strong mediation service enabling Web services to

communicate in a scalable manner. WSMF consists of four main elements:ontolo-

giesthat provide the terminology used by other elements;capabilities repositoriesthat

define the problems that should be solved by Web services;Web services descriptions

that define various aspects of a Web service; andmediatorsthat bypass interoperability

problems.

There are two main projects in WSMF: the Semantic Web enabled Web Services

(SWWS) [163] and the Web Service Modeling Ontology (WSMO) [182]. SWWS


will provide a description framework, a discovery framework, and a mediation frame-

work for Web services, according to a conceptual architecture. WSMO will refine

WSMF and develop a formal service ontology and language for Semantic Web ser-

vices. WSMO service ontology includes definitions for goals,mediators, and Web

services. The main characterizing feature of WSMO is that thegoal, Web service and

ontology components are linked by four types of mediators: i) OO mediators link on-

tologies to ontologies, ii) WW mediators link Web services toWeb services, iii) WG

mediators link Web services to goals, and iv) GG mediators link goals to goals. Al-

though WSMF provides a comprehensive conceptual architecture and is a promising

competitor of OWL-S, it is rather young and is still currentlyunder the development.

2.5 Summary

In this chapter, we have introduced some basic concepts related to Web services com-

position and presented the state of the art in research and standardization efforts. In

particular, we have overviewed the representative research approaches and standard-

ization efforts, and compared them with respect to a set of composition requirements.

Our findings indicate that, although tremendous efforts andresults have been made

and obtained in this area, Web services composition technology is not mature yet and

requires significant efforts in some open research challenges. In the next chapters, we

will discuss and present our solutions towards Web servicescomposition.

Chapter 3

A Personalized and Adaptive

Composition Model for Web Services

The efficiency and flexibility are two important requirements for Web services com-

position. On the one hand, the current development of integrated Web services is still

largely ad-hoc, time-consuming and requires a considerable effort of low-level pro-

gramming. This approach is hardly applicable because of thevolatility and size of the

Web. On the other hand, environments that users interact with aredynamicby nature,

e.g., changing environmental factors, changes in services, and evolving user require-

ments. The specification of new composite services reflecting user requirements and

situations could be hence frustrating and tedious. This calls for more agile approaches

that Web services can be easily composed and the resulted composite services can be

configurableto accommodate the needs of every individual user, and can beable to

transparently adapt to changes in the environment with minimal or no user interven-

tion.

In this chapter, we describe our proposed composition modelfor composing Web

services in a personalized and adaptive manner [152, 153, 19, 17]. To cater for the large

amount and dynamic nature of Web services, we use the conceptof service community

that groups services together and is responsible for the runtime selection of services

against user’s preferences. To speed up and ease the development of composite ser-

Chapter 3. Personalized and Adaptive Composition Model 46

vices, we use the concept ofprocess schema. A process schema of a composite service

is modeled using statecharts [85] and represents a reusableand extensible business

process skeleton devised to reach a particular goal. Users can then adjust this process

schema with their personal preferences and contextual information, thereby defining

personalized composite services. In addition, a set ofexception handling policiescan

be specified to proactively react to runtime exceptions.

This chapter is organized as follows. In Section 3.1, we givean overview of the

proposed model for Web services composition. In Section 3.2and Section 3.3, we

introduce the concept of process schema and service community, respectively. In Sec-

tion 3.4, we describe the mechanisms for configuring processschemas using user pref-

erences. In Section 3.5, we introduce a policy-based, multi-level exception handling

model for composite Web services. Finally, we discuss some related work in Sec-

tion 3.6 and conclude this chapter in Section 3.7.

3.1 Design Overview

Figure 3.1 shows our personalized and adaptive service composition model, described

in the Unified Modeling Language (UML) [167]. Aprocess schemais a reusable

and extensible business process skeleton devised to reach aparticular goal (e.g., travel

planning). Each process schema has one or more tasks and eachtask belongs to exactly

one process schema. The relation is denoted by a composite aggregation (i.e., the

association end with a filled diamond). Each task is associated with a service operation

where the service can be either an atomic service, a composite service, or a service

community. Process schemas are modeled using statecharts [85, 151] and the detailed

design of the process schema will be introduced in Section 3.2.

A process schema can beconfiguredto form what we callpersonalized composite


Legend

class

associations association class

compositions

generalizations

Figure 3.1: UML class diagram for personalized service composition model

service, by assigning a number ofuser preferencesto the process schema’s tasks and

the schema itself. The relation is denoted as an associationclass (dashed line). There

are three kinds of user preferences, namelycontext constraint, data supply and deliv-

ery preference, andservice selection preference. Individual users can adjust process

schemas to meet their particular requirements by specifying user preferences1. For

example, a college student may specify that she would like toinvoke the consultation

booking service only after the classes. We will describe theuser preference model in

Section 3.4.

An exception handling policy is a rule that prescribes the knowledge on the appro-

1It should be noted that users specify preferences on particular tasks of a composite service withoutchanging its schema.


priate response to a particular execution exception. Policies are assigned to the process

schema and its tasks by the relationpolicyAssignment, indicating which task (process

schema) has what kinds of exception handling policies. A task (process schema) can

have multiple exception handling policies. We will discussour design of exception

handling policies in Section 3.5. It should be noted that thenotations used in Fig-

ure 3.1 are directly adopted from the UML language. Readers are referred to [167] for

the explanation of UML notations.

3.2 Process Schema

A process schemais an umbrella structure that aggregates other atomic or compos-

ite services that collaborate to implement a set of operations. The services brought

together by a process schema are referred to as itscomponent services. We model pro-

cess schemas using statecharts [85, 151]. The choice of statecharts as the language for

capturing the flow of operation invocations in our work is motivated by several reasons.

First, statecharts possess a formal semantics, which is essential for analysing process

schema specifications. Next, statecharts are a well-known and well-supported behavior

modeling notation, and they are part of the Unified Modeling Language (UML) [167].

Furthermore, statecharts offer most of the control-flow constructs found in existing

process description languages: sequence, branching, concurrent threads, and cycles.

In particular, the work in [63] shows that statercharts are suitable for expressing typ-

ical control-flow dependencies. It is specifically shown that statecharts can capture a

relatively high number of the workflow patterns identified in[1].

However, like any other process modeling languages (e.g., languages based on

Petri nets, process algebra, or transaction logic), statecharts have their relative ad-

vantages and drawbacks. In particular, statecharts do not provide direct support for

modeling the so-calledmultiple instances patterns[1], that is, situations where mul-


tiple copies of the same activity are executed simultaneously and these copies need

to synchronize upon completion. Nonetheless, this characteristic is shared by several

other proposals in this area, like the Business Process Execution Language for Web

Services (BPEL) [7], which is currently emerging as an implementation-level standard

in the area of Web service composition. It is worth noting that the process schemas

developed in the context of statecharts can be mapped onto other process definition

languages such as BPEL [7]. For example, in [12], authors propose a model-driven

approach to automatically transform composite services expressed in statecharts to

BPEL processes.

3.2.1 Overview of Statecharts

A statechart is made up of states and transitions. Transitions are labeled byECA(Event

Condition Action) rules. The occurrence of an event fires a transition if:

• the machine is in the source state of the transition,

• the type of the event occurrence matches the event description attached to the

transition, and

• the condition of the transition holds.

When a transition fires, its action part is executed and its target state is entered. The

event, condition, and action parts of a transition are all optional. A transition without

an event is said to betriggerless.

States can beinitial , end, basic, or compound. A basic state corresponds to an

invocation of a service operation, whether an atomic service, a community, or a com-

posite service. Accordingly, each basic state is labelled with an invocation to a service

operation. When the state is entered, this invocation is performed. The state is nor-

mally exited through one of its triggerless transitions when the execution induced by


this invocation is completed. If the state has outgoing transitions labeled with events,

an occurrence of any of these events causes the state to be exited and the ongoing

execution to be canceled.

Compound states provide a mechanism for nesting one or several statecharts inside

a (larger) statechart. There are two types of compound states: OR and AND states.

An OR-state contains an arbitrary statechart nested inside it, which is executed when

the compound state is entered. An AND-state on the other handcontains several state-

charts (separated by dashed lines) which are all executed concurrently when the com-

pound state is entered. Each of the statecharts contained inan AND-state is usually

called anAND componentor anorthogonal component. In this work we choose the

term concurrent regioninstead, to avoid confusion with the termcomponent service

introduced earlier.

The origin of the terms OR-state and AND-state can be explained as follows. The

states of the statechart contained in an OR-state (i.e., the substates of the OR-state)

are related by anexclusive orrelationship, in the sense that being in an OR-state is

equivalent to being inexactly oneof its substates. Meanwhile, being in an AND-state

is equivalent to being inall the concurrent regions contained in the AND-state.

From an operational perspective, when a compound state is entered, the initial

state(s) of the statechart(s) nested in it become(s) active. The execution of a com-

pound state is considered to be completed when it has reached(all) its final state(s).

Initial states are denoted by filled circles whereas final states are denoted by two con-

centric circles. It should be noted that we do not consider the specification of richer

abstractions such as service conversations in the work of this dissertation. For details

about service conversation support in our approach, we refer the reader to [14].

Example 3.2.1 (Class Assistant Process Schema). Figure 3.2 is the statechart of a

simplified process schema that helps students manage their class activities along the


Attendance

Reminder (AR)

tr0

Question Browser (QB)

Question Voter (QV)

Question Poster (QP)

Consultation Booker (CB)

Lecture Feedback Provider (LF)

tr4: [not classOver(lectureTime)]

tr3: [classOver(lectureTime) and (not answered)]

tr5: [classOver (lectureTime) and answered]

Question Asking trq1 : [listed]

trq2 : [not listed]

tr2

tr6

tr7

trq0

trq4

trq3

Lecturenotes Outliner (LO)

Attendance Guide (AG)

tr1

trg0 trg1

tro0 tro1

Class Assistant

Figure 3.2: The process schema of the digital class assistant


lines of the motivating scenario described in Section 1.2. In this schema, an attendance

reminder notifies students about the lecture’s time and place. The task is followed by an

AND state, in which an attendance guide is performed in parallel with the outlining of

the lecture notes. The former provides a detailed guidance on how to get to the lecture

room from a student’s current location, while the latter searches the lecture note slides

and provides the student an outline of the coming lecture. During the lecture, when a

student wants to ask a question, she first browses the questionsasked by other students

using her PDA. Then she decides either to vote for a posted question (if her question

was already asked by someone else) or to post her question (if no one has asked a

similar question). The student may ask several questions during the lecture. After the

class, a consultation booking is performed if not all the questions asked by the student

are answered. In both cases, feedback about the lecture is provided by the student.

3.2.2 Data Dependencies

In a process schema, each taskt has a set of input and output parameters. We denote

its input and output asΘι = {i1, i2, . . . , im} andΘo = {o1, o2, . . . , ok}, respectively.

The value of a task’s input parameter may be:

• requested from the user during the execution of the task,

• obtained from the user profile where the corresponding data is stored, or

• obtained as an output of another task.

For the first case, the following expression is used:ij:=USER. For other cases, they

are expressed as queries:ij:=Qj. Queries vary from simple to complex, depending on

the application domain and user needs. Queries can be expressed using languages like

XPath [52].


In our approach, values that users supply as input parameters are differently han-

dled from the values obtained from their profiles. Extracting values automatically from

user profiles not only enables the less user interactions during the process execution,

but also is critical for users who are always on the move (e.g., business persons). In-

deed, due to the reasons like resource scarcity of mobile devices, values that can be

obtained from user profiles should not be requested from users. Users only supply

the values for data items that are labeledcompulsory. However, in a process schema

specification, the schema designer only indicates which input parameters users have to

supply a value. It is the responsibility of a user to specify—during the configuration

phase (see Section 3.4)—if the value will be provided manually or extracted from her

profile.

Similarly, the value of a task’s output parameter may be: i) sent to other tasks as

input parameters, and/or ii) sent to a user in case she wants to know the execution

result of the task. Symbol denotes the delivery of output parameters. For instance,

oj {USER}means that the value ofoj should be sent to the user. Note that the value

of an output parameter can be submitted to multiple places (e.g., to a task and the user

as well).

Example 3.2.2 (Data Dependencies). Table 3.1 describes the input and output pa-

rameters of the class assistant process schema, together with their data dependencies.

To describe data dependencies, the following additional notations are used: i)USER

denotes an end user (e.g., a student), ii)document(RCV(QB))/subjectID is an

XPath query whereRCV(QB) stands for the XML document that includes the outputs

of other tasks received byQB. A similar explanation applies to other XPath queries

given in the table. In the example, it can be seen that in orderto give lecture feed-

back (taskLF), a student must input her comments (e.g.,comments). Meanwhile,

the value of input parametersubjectID of taskQB can be derived from the value of


Task Input Parameter & dependency Output Parameter & dependencyAR string subjectID:=USER, string lectureTime {USER},

string studentID:=USER string lecturePlace {AG, USER},string subjectID {LO, QB, QV, QP,CB, LF},string studentID {CB},string professor {CB}

AG string lectureP=document(RCV(AG))/lecturePlace,XMLDoc guideDetailsstring studentID=document(RCV(AG))/studentID

LO string subjectID=document(RCV(LO))/subjectID XMLDoc lectureOutlineQB string subjectID=document(RCV(QB))/subjectIDQV string subjectID=document(RCV(QV))/subjectID, XMLDoc voteDetails {USER}

string questionID:=USERQP string subjectID=document(RCV(QP))/subjectID, XMLDoc postDetails {USER}

string question:=USERCB Date preferredDate:=USER, XMLDoc

string subjectID=document(RCV(CB))/subjectID, consultBookingDetails {USER}string professor=document(RCV(CB))/professor,string studentID=document(RCV(CB))/studentID

LF string subjectID=document(RCV(LF))/subjectID, XMLDoc commentDetails {USER}string comments:=USER

Table 3.1: Data dependencies of the class assistant processschema

output parametersubjectID of AR, which in fact, is also used to provide the values

of the same input parameter of other tasks (i.e.,AG, QV, QP, CB, andLF).

It is worth mentioning that there are five conditions in the statechart transitions.

Conditions are modeled as boolean variables whose values areprovided by a user

at runtime, or calls to boolean functions that take as parameters queries involving

input and output parameters of process schema tasks. For example, the condition

classOver(lectureTime) is a function call whose parameter is directly ob-

tained from one of the outputs of taskAR. Meanwhile,listed andanswered are

two boolean variables.


Figure 3.3: The UML class diagram of the community model

3.3 Service Communities

Handling large amount of and dynamic Web services is one of main concerns of our

service composition model. Central to our model is the concept of service community.

A service community is a collection of Web services with a common functionality

(e.g., consultation booking) but different non-functional properties such as different

providers and different QoS parameters (e.g., location). All Web services that belong to

a given community share the same area of interest. For example, suppose that a number

of consultation booking services are running in the main buildings of the university

campus. We can form a pan-campus consultation booking service community (e.g.,

CBS-UNSW).

Figure 3.3 shows a UML class diagram representing the concept of the community

model. A service community aggregates multiple Web services, which can be atomic

Web services or composite services. It should be noted that aservice community itself

is a Web service.

Figure 3.4 illustrates the basic process of creating a community and registering


WS2 WS3 WS4

Service Registry

Service community CM1

Service community CM2

Web Services

Service Providers

Community Provider

Community Provider

1. defining community

1. defining community

2. advertising community

2. advertising community

4. registering with community

3. selecting community

published in

member of

published in

member of

member of published in

WS1 WS5

Figure 3.4: The detailed community model

Web services with it. Communities are specified by community providers (step 1),

who then register the communities with service registry (step 2). In our model, a

community is a service that is created, advertised, discovered, and invoked in the same

way that regular Web services are. Communities are publishedin a service registry

(e.g., UDDI) so that they can be discovered by service providers.

Service providers search the service registry to find the appropriate communities

(step 3) and register their services (atomic or composite) with the communities (step

4). After registering with a community, a Web service becomes a member of the

community. It should be noted that a service community can bea member of another

community.

Service communities provide descriptions of a desired functionality (e.g., consul-

tation bookingCBS-UNSW) without referring to any actual service (e.g.,CBS-K17).

When a community receives a request to execute an operation, the request is delegated


to one of its current members based on selection strategies.It should be noted that

tModel is a data construct supported by UDDI, which can be also used for service

classification. However, tModel has some intrinsic limitations such as limited search-

ing capabilities. In the following sections, we introduce the service registration and

selection.

3.3.1 Service Registration

The registration of a service with a community requires the specification ofmappings

between the operations of the service and those of the community. The mappings

involve both the operations and their input/output parameters.

Suppose that we have a communityCBS-UNSW that contains all the consulta-

tion booking Web services provided in the university (e.g.,UNSW), and a Web ser-

vice CBS-K17 provided by the School of Computer Science and Engineering. Fig-

ure 3.5 describes the signatures ofCBS-UNSW and CBS-K17. The keywordin

(resp.,out) indicates an input (resp., output) parameter. For instance, in Date

preferredDate indicates thatpreferredDate is an input parameter of type

Date, of the operation of service communityCBS-UNSW.

CBS-UNSW consultBooking(in Date preferredDate, in string studentID,in string professor, in string subjectID, out XMLDoc con-sultBookingDetails)

CBS-K17 bookConsultation(in Date bookingDate, in string studentID,in string professorName, in string subjectID, out XMLDocbookingDetails)

Figure 3.5: Signatures of the operations of communityCBS-UNSW and serviceCBS-K17

Figure 3.6 gives an example of the mapping script of the community CBS-UNSW


source serviceCSE consultation booking service CBS-K17target community consultation bookings CBS-UNSW

operation mappingsoperation CBS-UNSW.consultBooking() is CBS-K17.bookConsultation();

parameter mappingsparameter CBS-UNSW.preferredDate is CBS-K17.bookingDate;parameter CBS-UNSW.studentID is CBS-K17.studentID;. . .parameter CBS-UNSW.consultBookingDetails is CBS-K17.bookingDetails

Figure 3.6: A fraction of the mapping script

and the serviceCBS-K17. From the example we can see that, the operationconsult-

Booking of the communityCBS-UNSW is mapped to the operationbookConsult-

ation of the serviceCBS-K17. Similarly, the parameters of the community oper-

ation are mapped to the ones of the service operation. For example, the parameter

preferredDate of the community operation is mapped to the parameterbooking-

Date of the service operation. It should be noted that a registration may concern only

a subset of the operations of a community. Thus, Web serviceshave the flexibility to

register only for the operations that they can provide. For instance, suppose that the

communityCBS-UNSW provides two operations:consultBooking for booking a

consultation andscheduleSearching for searching and displaying the professor

schedules. If a Web service provides only one of these operations, then it will register

only for the operation that it provides.

A Web service can register with one or several communities. Acommunity can

be registered with another community. For example, the Web servicesCBS-K17 and

CBS-Quad are registered with the communityCBS-UNSW which is itself registered

with the communityCBS-Australia. This has the advantage that a Web service

can still be available even if one of the communities this service is registered with, is


not available.

3.3.2 Multi-Attribute Service Selection Policies

A community is associated with a scoring service that interprets aselection policy. A

selection policy specifies preferences over services of a community. It consists of a

multi-attribute utility function[161] which has the form :

U(s) =∑

i∈SA

wi · Scorei(s) (3.1)

where:

• Scorei(s) is an attribute scoring function, which, given a value of an attribute

i of the services, returns a score (a positive integer value).SA is the set of

selection attributes.

• wi is the weight assigned to the attributei, and

• wi ∈ [0, 1] and∑

i∈SA wi = 1.

The scoring service computes the weighted sum of service attribute scores using

the weight property of each selection attribute. It then selects the service which pro-

duces the higher overall score according to the multi-attribute utility function. Selec-

tion attributes belong to one of three categories:advertised, provider-supplied, and

community-supplied.

• Advertised attributes are the attributes that a service provider makes available

at registration time (i.e., when the service becomes memberof the community).

For example, a service provider may advertise the expected duration of an oper-

ation invocation.


Selection Attribute Attribute Function Function DescriptionExecution Price Fprice(s, op) = P(s, op), where

P(s, op) is the price charged bys.The amount of money that a ser-vice requester has to pay for exe-cuting operationop of services.

Execution Duration Fed(s, op) = (2T (s, op) + T ′(s, op))/3,where T (s, op), T ′(s, op) are the twomost recently recorded values of execu-tion time ofs for the operationop.

The expected delay in secondsbetween when a request tos forexecuting operationop is sentand when results are received.

Reputation Frep(s) = (∑n

i=1Ri(s))/n, whereR(s) is an end user’s ranking on services’s reputation,n is the number of thetimes thats has been graded.

A measure of its trustworthinesswhich depends on end users ex-periences of using the services.

Reliability Frel(s) = Nc(s)/K, whereNc(s) isthe number of successful invocations ofs in the last K requests. HereKis a constant—set by the communityprovider—specifying how far in the his-tory should the estimated reliability of theservice be based on.

The probability that a request tos is correctly processed within amaximum expected time frame.

Availability Fav(s) = Ta(s)/ξ, whereTa(s) is thetotal time interval (in second) in whichsis available during the lastξ second.ξ is apredefined constant set by the communityprovider. Value ofξ may vary dependingon a particular application.

The probability that a request tos is accessible.

Table 3.2: Service selection attributes

• Provider-supplied attributes are available from service providers only upon re-

quest. For instance, the price of a product can be defined as being a provider-

supplied attribute, and finally,

• Community-supplied attributes are the attributes that can be derived at the com-

munity level from past execution logs. For instance, valuesof service quality

attributes such as reliability and availability can be estimated based upon past

execution logs.

Our system supports a predefined set of generic attributes, and allows developers

to introduce new attributes. Table 3.2 lists the predefined attributes.

A scoring function is provided for each selection attributethat calculates the score


of the attribute for a particular service and scales the score to the interval [0..1]. A

higher score value indicates a better quality. However, we draw attention that some of

the selection attributes arenegative, i.e., the higher the value is, the lower the quality is.

This includes attributes such as execution duration and execution price. While others

arepositive(e.g., reputation and availability), i.e., the higher the value is, the higher

the quality is. Therefore the attribute scores should be scaled differently.

Assume a service communityCM hasn members,CM = {s1, s2, . . . , sn}, and

Vα(CM) = {v1, v2, . . . , vn} is a set of values for the selection attributeα in CM. For

negative selection attributes, scores are scaled according to Equation 3.2. For positive

selection attributes, scores are scaled according to Equation 3.3.

Scoreα(si) =

Vmaxα (CM)−vi

Vmaxα (CM)−Vmin

α (CM)if Vmax

α (CM)− Vminα (CM) 6= 0

1 if Vmaxα (CM)− Vmin

α (CM) = 0(3.2)

Scoreα(si) =

vi−Vminα (CM)

Vmaxα (CM)−Vmin

α (CM)if Vmax

α (CM)− Vminα (CM) 6= 0

1 if Vmaxα (CM)− Vmin

α (CM) = 0(3.3)

WhereVmaxα (CM) is the maximal value of a selection attributeα in the community,

i.e., Vmaxα (CM) = Max(vi), 1 ≤ i ≤ n, andVmin

α (CM) is the minimal value of

a selection attribute in the community, i.e.,Vminα (CM) = Min(vi), 1 ≤ i ≤ n. It

is worth mentioning that the method of estimating the value of a community-supplied

attribute is not unique, neither is the set of selection attributes.

Example 3.3.1 Suppose that the communityCBS-UNSW contains five consultation

booking Web services running in different major campus buildings. Their execution

durations—after the calculation using the functionFed(s, op) (see Table 3.2)—are

Ved(CBS-UNSW) = {4.011, 5.809, 7.665, 3.457, 4.589}. Since execution duration is

a negative selection attribute, we will use Equation 3.2 to calculate attribute scores

for the consultation booking services. The scores of the services in the community is


Scoreed(CBS-UNSW) = {0.868, 0.441, 0, 1, 0.731}.

Selection policies are provided by communities at service definition time. Con-

sumers cancustomisethese policies by providing weights for the selection attributes.

A community may provide several alternative multi-attribute utility functions which

correspond to different selection policies. Consumers choose policies depending on

their preferences. In Section 3.4.3, we will discuss the configuration of selection poli-

cies.

3.4 User Preferences

Personalization is another major concern of our services composition model. A spe-

cific customer can configure a process schema accordingly to reflect her particular

requirements. This is done by specifying a number ofuser preferencesand assign-

ing these preferences to the process schema’s tasks and/or the process schema. We

distinguish three kinds of user preferences:

• Context constraintsspecify that certain contexts must meet certain conditionsto

execute a task. For example,temporalandspatial constraints are two prefer-

ences respectively indicatingwhenandwherethe user would like to have a task

executed,

• Data supply and delivery preferencesare related to supplying values to the input

parameters and delivering values of output parameters of the task, and

• Service selection preferencesspecify how to select a Web service for the execu-

tion of a task.


3.4.1 Context Constraints

Users can specify conditional permissions on the invocation of a task viacontext con-

straints. A context constraint of a task indicates that a specific condition must be

satisfied by certain context in order to invoke the task. In this section, we first intro-

duce the concepts ofcontextandcontext constraint, and then present two important

context constraints used in our personalized service composition model.

Context. There are a number of definitions and uses of the term context in the liter-

ature [93, 137, 142, 30, 146, 176, 60, 88, 70]. However, most of them are either done

by enumeration of examples (e.g., location, user identities) or by simply choosing syn-

onyms for context (e.g., referring context as environment or situation). Such defini-

tions are extremely difficult to apply in practice. In our work, we adopt a more general

definition of context—which is in fact widely used in the literature today—proposed

by Dey and Abowd: “Context is any information that can be used to characterize the

situation of an entity. An entity is a person, place, or object that is considered rel-

evant to the interaction between a user and an application, including the user and

applications themselves” [61].

In a context-aware Web service (CAS) [98, 150] provisioning environment, we

advocate that context contains any information that can be used by a Web service to

adjust its execution and output. Examples of contexts are:

• contexts related to a service requester (mostly it is the client who invokes a

service), including the requester’s identification information (e.g., name, DOB,

address), personal preferences (e.g., Chinese cuisines when eating outside), cur-

rent situation (e.g., location, current computing device being used), and other

information (e.g., friends list, calendar);


• contexts related to a Web service, such as service location,service status (e.g.,

available, busy), and its QoS attributes (e.g., price, reliability); and

• other contexts like time and weather information.

Some context information can besenseddirectly (e.g., locations and temperatures

using physical sensors), while others have to bederivedfrom available context infor-

mation. Contexts are provided bycontext providers. It is interesting to mention that

more and more context providers advertise their services—calledcontext information

services2—over the Web that can be seamlessly integrated into context-aware Web

services. Recently, quite a few research efforts on modelingthe context provisioning

services are proposed [145, 31, 86]. It is also worth mentioning that some contexts are

application specific. Forecasted weather, for instance, could be a context in a vacation

planning service, but not in a currency conversion service.

Context Constraint. A context constraint specifies that a certain context must meet

certain condition in order to perform a particular operation (e.g., task execution). For-

mally, a context constraint is modeled as a predicate (i.e.,a Boolean function) that

consists of an operator and two or more operands. The first operand always represents

a context, while the other operands may be either constant values or contexts. An op-

erator can be either a prefix operator that accepts two or moreinput parameters or a

binary infix operator (e.g., =,≤, �, and∋) that compares two values.

While the concept of context constraint is generic enough to be applicable in spec-

ifying a wide range of context constraints, we focus on two constraints in our per-

sonalized service composition model:temporalandspatialconstraints, which will be

described in the subsequence.

2E.g., US National Weather Service, http://www.nws.noaa.gov.

http://www.nws.noaa.gov


• Temporal Constraint. We denote the temporal constraint of a taskt asΘτ (t).

Formally, a temporal constraint is specified asΥ(P , T ), whereP is a compari-

son operator (e.g., =,≤, andbetween) andT is either an absolute time, a relative

time (e.g., termination time of a task), or a time interval inthe form of[T1, T2].

The Υ(P , T ) constraint of a task means that the task must be triggered if the

conditioncurrent-time P T is evaluated to true. Here,current-time

denotes the system time. For the sake of simplicity, we assume that all temporal

values (time instants, durations, and intervals) are expressed at the same level of

granularity.

• Spatial Constraint. Similarly, we denote the spatial constraint of a taskt asΘζ ,

specified asΓ(L). L is a physical location given by a user. TheΓ(L) constraint

prescribes that the task must be fired when the conditioncurrent-location

= L is evaluated to true, wherecurrent-location denotes the current lo-

cation of the user. A locationL1 is considered the same as another locationL2

(i.e.,L1 = L2) if the distance between two points ofL1 andL2 does not exceed

a certain value (e.g., less than 10 meters). We assume that all spatial values are

expressed at the same level of granularity.

It should be noted that the temporal and spatial constraintscan be empty, meaning

that the corresponding task can be executed at anytime and atanywhere. We also

assume that contexts are provided by context providers. Thecontext provisioning (e.g.,

how a context information is sensed, refined, and disseminated) of context providers is

outside the scope of our work.

Example 3.4.1 (Temporal and Spatial Constraints). Now, assume a student, Andrew,

is interested in using the digital class assistant. First, Andrew has to personalize the

schema by indicating his preferences for each task (Table 3.3). In particular, because


Task Θτ Θζ

AR Υ(between, [5:30pm Monday, 5:40pm Monday])AG Υ(between, [5:30pm Monday, 5:40pm Monday])LO Υ(between, [5:30pm Monday, 5:40pm Monday])QB Υ(between, [6:00pm Monday, 9:00pm Monday]) Γ(Quad01A)QV Υ(between, [6:00pm Monday, 9:00pm Monday]) Γ(Quad01A)QP Υ(between, [6:00pm Monday, 9:00pm Monday]) Γ(Quad01A)CB Υ(≥, 9:10pm Monday)LF Υ(≥, 9:10pm Monday)

Table 3.3: Temporal and spatial constraints of class assistant schema

the lecture will be held from 6pm to 9pm atQuad01A every Monday, Andrew sets

the temporal and spatial constraints of tasksQB, QV, andQP to beΥ(between,

[6:00pm Monday, 9:00pm Monday]) and Γ(Quad01A), respectively. The

constraints indicate that only when Andrew sits in the lecture room (i.e., at the right

place) during the lecture time (i.e., at the right time), these services should be executed.

If Andrew is not, e.g., in the lecture room, it is less meaningful to execute question

asking services. Note that there is no spatial constraint fortasksAR, AG, LO, CB and

LF. Such tasks can be executed regardless of Andrew’s location.

It is important to make sure that the constraints specified byusers areconflict-

free, meaning that the specified context constraints should not be inconsistent with

the specification of the process templates. For example, in our digital class assistant

(Figure 3.2), the taskQB should be executedbeforeQV because there is a transition

leading fromQB to QV. However, Andrew may correspondingly specify thatQB and

QV will be executed at9am and8am, which clearly violates the specification. He

may also specify different spatial constraints for two tasks which are supposed to be

executed at the same time. This is also impossible because a user can not be at two

different places at a time. Comparing to the consistency check of temporal constraints,

it is fairly easy to the consistency check of spatial constraints: only ensuring that the

same spatial constraints are specified to the tasks which aresupposed to be executed


parallely (i.e., tasks in the concurrent regions of an AND state). We rely on [5] for

the consistency check of the user’s specified temporal constraints. In particular, the

temporal interval reasoning algorithm proposed in [5] is used to check the consistency

of the temporal constraints. If any inconsistency is detected, the user is requested

either to review her configuration, or to relax certain temporal or spatial constraints.

The interaction keeps going until the specification of the personal composite service is

declared free of conflicts.

3.4.2 Data Supply and Delivery Preferences

As stated in Section 3.2.2, the values of some input parameters of a task can be obtained

from a user profile. The user proceeds in two steps:

1. examine the input parameters whose values need to be supplied by users and

identify which input parameter values can be derived from her profile, and

2. supply the location (e.g., URI) of the profile and the corresponding attribute

names.

Queries can be generated that automatically extract valuesfrom the user profile for

input parameters at run time.

Similarly, for the output parameters of a task, a user may specify which parameter

values need to be delivered to her. If the user would like to receive the value of an

output parametero, then the data delivery preference of this parameter is expressed

aso {USER}. Data supply and delivery preferences specified by the user actually

change the data dependencies of the corresponding process schema.

Example 3.4.2 Suppose Andrew specifies that the value ofstudentID of taskAR

(Table 3.1) can be obtained from his profile via its attributestudent-id. The new


data dependency ofstudentID is now expressed asstring studentID:=doc-

ument(PROFILE)/student-id, wherePROFILE is the XML document where

Andrew’s profile is stored.

3.4.3 Service Selection Preferences

For a particular task, a user can specify how to select a service for this task. The service

can be a fixed one (i.e., the task always uses this service), orcan be selected from a

specific service community or a public directory (e.g., UDDI) based on certain criteria

(e.g., service reliability).

In Section 3.3, we propose a scoring service that enables a service community

to choose a member to execute an operation at the invocation time by interpreting a

service selection policy. The scoring service is a multi-criteria utility function (Equa-

tion 3.1) where users can express their service selection preferences by specifying

weightsfor the selection criteria.

To identify the desired services, users can customize theweightsfor the selec-

tion criteria. For example, suppose each main building in the university campus

is running a copy ofQuestionBrowse service, and these services have different

attributes (e.g., different reliability, different prices, different locations). All such

QuestionBrowse services are registered with a service communityQBS-UNSW.

Suppose that the communityQBS-UNSW is associated with the taskQB in the class

assistant process schema, that selects the optimal serviceto executeQB using the util-

ity function we defined in (3.1). Two service selection criteria are used:execution

duration andreliability. The score of aQuestionBrowse services is

computed using the following formula:

U(s) = wed · Scoreed(s, op) + wrel · Scorerel(s) (3.4)


Wherewed andwrel are weights for the selection criteriaexecution duration

andreliability, respectively. WhileScoreed(s, op) andScorerel(s) are the cor-

responding scoring functions of the two criteria.

If the execution duration, for example, is the most important factor to a student

(i.e., she wants the fastest services to save communicationcost), she can setwed to 1

andwrel to 0. If the two criteria are same important to the student, she can set both

wed andwrel as 0.5. During the execution, a score is computed for each service using

the above utility function and the service with the maximal value ofU(s) is selected

to executeQB. If there are more than one services which have the same maximal value

of U(s), then a service will be chosen randomly from them.

3.5 Multi-Level Exception Handling Policies

Due to the dynamic nature of Web services and error-prone service provisioning envi-

ronments, variousservice provisioning exceptionscan occur during the enactment of

a personalized composite service. By exceptions, we mean abnormal events caused

by service failures, network errors, and resource or requirements changes. The lack of

exception handling causes problems like poor performance,wasted resources, not-

optimal service provision, and even failure of the process enactment. To support

adaptive execution, services therefore should bepro-active: they should be capable

of adapting themselves in reaction to run-time exceptions [152].

Policies are rules that control choices in a system’s behavior [181]. Over the

past few years, many applications (e.g., system managementtools) have relied upon

policy-based techniques to add flexibility and adaptability to management infrastruc-

tures [25, 23, 123, 181, 87]. In our work, we have developed apolicy-based approach

to exception handling that expresses and controls exception handling strategies at a


high level of abstraction, separating from the composite service’s functionality. In

this way, service designers—even users—can dynamically add, remove, and modify

policies, to reconfigure the composite services without changing composite service

functionalities (e.g., control flow embedded in statecharts).

3.5.1 Exception Types

We distinguish three classes of service provisioning exceptions: component service,

community, anduser.

User Exceptions. Many exceptions can occur at user level. For instance, if a user in-

teracts with services using a mobile device, the mobile device can be disconnected3 un-

expectedly due to discharged battery, alignment of antennas, or lack of coverage area.

Further, a service result might not be able to be displayed onthe mobile device be-

cause of the lack of appropriate facilities (e.g., the picture is too big). Some exceptions

are related to the changes of the personalized composite services launched by users.

For example, a user may wish to reset her preferences on a specific task (e.g., spatial

constraint ofQB, QV, andQP in the class assistant) due to situation changes (e.g., the

lecture room is rescheduled toQuad01C).

Component Service Exceptions. During the execution of a personalized composite

service, different exceptions at the component service level can occur. In particular, the

selected service that executes a task of the personalized composite service may become

unavailable because it is overloaded or its respective server is down. The execution of

a service might take longer than the estimated time and even might be failed.

3It should be noted that disconnection can also happen in fixeddevices.


Exception Description Leveldisconnected(deviced) the deviced has disconnected. userunpresentable(resultr, deviced) the service resultr is evaluated to be

unpresentable in the user’s deviced.user

failed(services, taskt) the services is unable to executetaskt.

component

delay(services, taskt) the invocation of services associ-ated with taskt takes longer than theestimated time.

component

QoSDegraded(services, QoSq) the QoSq of services has deteri-orated, e.g., its execution time be-comes longer.

community

serviceRegistered(services, communityc) services is registered with commu-nity c and becomes a member ofc.

community

serviceDeregistered(services, communityc) services is removed from commu-nity c.

community

Table 3.4: Selected exception events

Community Exceptions. Community level exceptions are due to QoS (e.g., price)4

changes of community members or membership changes of a community. For in-

stance, a member service might increase its execution price; the execution duration of

the service might become longer due to a sudden increase in the number of requests.

In addition, some new Web services with better QoS might jointhe community, while

some registered services might leave (deregister) the community. If such changes hap-

pen after the selection, it obviously implies that the selected services may no longer

considered asoptimal. As a result, redoing the selection could be needed to make sure

that optimal Web services are always selected for the execution of tasks.

An exception eventis generated in response to the occurrence of a service provi-

sioning exception. For example, if the invocation of a services—which was selected

to execute a taskt of a composite service—is failed, the exception eventfailed(s,

t) will be generated. Table 3.4 lists part of exception events supported in our work.

4Detailed description of QoS parameters can be found in e.g.,[187].


3.5.2 Exception Handling Policies

An exception handling policyprescribes the knowledge on the appropriate response to

a particular exception event, providing a means for flexible, robust, and adaptive ser-

vice invocation. Exception handling policies can be specified by a schema designer at

process schema definition time, or by an end user during schema configuration phase.

For example, a process schema designer can specify that if a services1, which is se-

lected to execute taskt of a composite serviceCS, is overloaded, the invocation request

should be forwarded to services2.

We use Ponder language [123, 111, 57], especially itsobligation policies, for the

specification of exception handling policies. Obligation policies are declarativeevent-

action-conditionrules defining the actions that policy subjects (entities having the au-

thority to initiate a management decision) must perform on target entities, when spe-

cific events occur and specific conditions hold upon event occurrence. Several reasons

motivate our choice of Ponder obligation language for specifying exception handling

policies:

• Ponder obligation policies are event-triggered rules. Such event-driven model is

an ideal candidate for composite services because their component services are

typically distributed;

• Ponder obligation policies are declarative rules and service designers and users

can express their exception handling strategies directly without having to change

composite service functionalities;

• Ponder obligation policies are amenable to policy analysisand verification. Un-

like exception handling policies embedded in implementation code (e.g.,catch

clauses in Java codes), it is possible to validate declarative exception handling

policies externally for service exception handling.


INST OBLIG PolicyName:

On event-specification;Subject subject-specification;Target target-specification;Do action-list;

[ When constraint-expression; ][ EffectiveInterval time-expression; ]

Figure 3.7: Syntax of extended Ponder obligation policies

Figure 3.7 shows the syntax of Ponder obligation policies. TheOn clause identifies

the triggering event(s), while theSubject clause identifies the entities having the

authority to initiate a management decision. TheDo clause identifies the exception

handling action to perform on the target entity—identified by Target clause—when

the event occurs. Combinations of various actions can be generated using sequence

and concurrency operators provided by Ponder language. Finally, theWhen clause

defines the conditions that must hold for the policy to be applied. Note that some

elements (e.g.,When) are optional.

We introduce an elementEffectiveIntervalto indicate the time period in which

a policy is enabled.EffectiveInterval is a temporal condition, expressed as

Υ′(P , T ) whereP is a comparison operator andT is a time (similar to temporal con-

straint in Section 3.4.1). TheΥ′(P , T ) means that the policy can be enabled if the

conditioncurrent time P T is evaluated to true (current time is the system

time). If EffectiveInterval is not specified, we assume the policy is always

enabled. By means of theEffectiveInterval, which is not provided in Ponder

language, it is possible to state that certain policies are not always enabled, rather, they

are enabled only during specific temporal intervals.

Based on the exception handling policies, a set ofexception handling tuples(Chap-


Policy Name ServiceFailure ResultDeliveryOn failed(QPService,QP) arrived(r,Andrew-Agent)Subject classAssistant classAssistantTarget QPService Andrew-AgentDo retry(QPService) silentDeliver(r)When executionTimes(QPService)<5 Andrew.status=“at meeting”EffectiveInterval Υ′(between,[01/06/2004,

31/12/2004])Υ′(between,[9am, 5pm])

Policy Name NewMemberOn serviceRegistered(s,QBS-UNSW)Subject classAssistantTarget QBS-UNSWDo redoSelection(QBS-UNSW,QB)When QB.executionStatus!=“running”

∧QB.selection=trueEffectiveInterval

Table 3.5: Example exception handling policies

ter 4) can be generated and distributed to the tuple spaces ofthe corresponding services,

facilitating the exception handling during the enactment of personalized composite ser-

vices.

Example 3.5.1 (Exception Handling Policy). Table 3.5 provides three example poli-

cies, dealing with class assistant exceptions at service, user, and community levels,

respectively:

• TheServiceFailure policy is specified by the schema designer. The pol-

icy states that when the execution of serviceQPService, which is associated

with taskQP, is failed (On clause), class assistant service (Subject clause)

should command the controller, introduced in Chapter 4, ofQPservice(Target

clause) to invoke this service again (Do clause) if the number of the invocations

of the service is less than 5 (When clause). In addition, the policy is enabled from

June the1st, 2004 until the end of the year (EffectiveInterval clause),

which is the semester that Andrew studies this course.


• TheResultDelivery policy is specified by Andrew indicating that during

the working hours, whenever a service result is arrived at Andrew’s user agent,

if Andrew is at a meeting, the result should be delivered to his PDA without

sound alert.

• TheNewMember policy is specified by the schema designer, which indicates

that whenever a new member service is added into the communityQBS-UNSW, if

a service is already selected to executeQB and the invocation of the service is not

started yet, the community should redo the service selection. TheNewMember

policy is always enabled because there is noEffectiveInterval specifi-

cation for this policy.

3.6 Related Work

Over the last few years, the prosperous research on Web services has led to a multitude

of results in composition techniques for Web services. In this section, we examine

some related work on Web service standardization efforts, component-based middle-

ware, and process-based service composition approaches.

3.6.1 Web Service Standards

Several standards have emerged recently to enable Web services composition, includ-

ing BPEL4WS [7], WSCL [13], WSFL [108], and XLANG [165]. XLANG and WSFL

extend WSDL language to provide constructs for combining Webservices to build

multi-party business processes. WSCL can be used to describe conversations that a

service supports (e.g., the supported operations and the order of their invocations).


BPEL4WS combines the features of both WSFL (support of graph oriented processes)

and XLANG (structural constructs for processes) for Web services composition. Fi-

nally, the emerging semantic Web efforts such as OWL-S [166] and WSMF [67] pro-

mote the use of ontologies as a means for reconciling semantic heterogeneity between

Web resources. Both BPEL4WS and WSMF offer the ability for exception handling by

usingfault/compensation handlersandexception handling section, respectively. How-

ever, their exception handling specifications are incorporated tightly with the compos-

ite service specifications that is difficult to maintain and evolve. In contrast, our Web

service composition model provides a policy-based, multi-level exception handling

approach that expresses and controls exception handling strategies at a high level of

abstraction, separating from the composite services functionalities.

Such aforementioned standardization efforts focus on designing rich and machine

understandable representations of service properties, capabilities, and behavior, as well

as reasoning mechanisms to select and aggregate services. The issues addressed in

these efforts are complementary to those addressed in our work. In particular, we focus

on the personalized and adaptive Web services composition in dynamic environments.

3.6.2 Component-Based Middlewares

Component-based middlewares (e.g., CrossWorlds, IBM SanFrancisco) [62, 54] typi-

cally rely on distributed object frameworks such as CORBA, DCOM, EJB, and other

state-of-the-art technologies such as Enterprise Application Integration (e.g., IBM

MQSeries) and Enterprise Resource Planning suites (e.g., SAP R/3), database gate-

ways and transaction monitors. A component-based middleware provides standard

data and application integration facilities (e.g., pre-built application adapters, data

transformations, and messaging services among heterogeneous systems) supporting


uniform access to heterogeneous applications. In this approach, composite services

(e.g., ordering a product) can be assembled from independently developed components

(e.g., checking inventory, delivering goods, and payment). However, the composition

of services is realised through ad-hoc code development. This static and ad-hoc com-

position approach would be hardly scalable because of the large number partners that

may be involved in a composition, the loosely coupled and possible dynamic nature

of Web services. Hard coding the composition flow makes the definition, deployment,

and evolution of services difficult and time-consuming [132, 149].

Component-based middleware are thus appropriate for the integration of small

numbers of tightly coupled services with stable interfaces. Our approach focuses on

the composition and deployment of a potentially large number of loosely coupled and

dynamic services. Component-based middleware efforts are complementary to our

approach. An intra-enterprise application which developed using a component-based

middleware, could be wrapped as an atomic service and then composed with other

services using our approach.

3.6.3 Web Service Composition Approaches

There are several research efforts in Web service composition. CMI [149] and eFl-

ow [40] are platforms for specifying, enacting, and monitoring composite services.

Both eFlow and CMI support dynamic service provider selection, although the concept

of community provided in our approach is not explicitly supported. CrossFlow [80]

and WISE [105] are inter-organisational workflow managementplatforms that focus

on inter-connecting business processes for e-commerce. They consider important re-

quirements of B2B applications such as dependability and external manageability.

They differ from our work in that they do not consider the issue of multi-attribute


provider selection in a dynamic environment (where providers join and leave commu-

nities continuously). FUSION [172] is a framework for building and managing service

portals. It provides a description model for Web service methods as well as a Web Ser-

vices Execution Specification Language (WSESL). An optimal execution plan can be

automatically generated from the abstract requirements specified in this language. In

this sense, our work and FUSION both aim at facilitating the rapid composition of

Web services. The issue of deriving an optimal execution plan is not considered in

our work, but instead our work supports dynamic service selection through the notion

of service community and the reused process schemas. All theabove research pro-

totypes, unfortunately, did not consider the issue of personalized service provisioning

(e.g., where and when a service should be invoked).

ADEPT [97] is a multi-agent platform designed to support inter-organisational

business process definition and enactment. In ADEPT, a workflow can be recursively

decomposed into smaller sub-workflows, leading to a tree-like structure similar to the

one induced by the relationship between composite servicesand their components in

our work. Each sub-workflow in ADEPT, is assigned to an autonomous agent. When

the agent responsible for a workflow, needs to invoke a sub-workflow, it has to negoti-

ate with the agent(s) that provide it. This contrasts with our work where the selection

of the component service within a community is done through the evaluation of a se-

lection policy. In this sense, ADEPT and our work complementeach other.

Finally, Hwang and Chen have investigated in [90] the specification and querying

of processes that involve personal tasks and data for mobileusers. A personal workflow

management system coordinates these processes. While Hwangand Chen focus on

the specification and querying ofsimplepersonal processes (e.g., without support of

control flow constructs likesplit and join) for mobile users, our approach is general

enough for both fixed and mobile users and therefore can specify personalized services


that fulfill complex user requirements. A similar effort is IBM’s PerCollab [42], which

is a middleware system that integrates multiple communication devices into workflow

systems. Relying on a BPEL engine and a context service, tasks can be proactively

pushed to users. However, PerCollab does not consider the personalized specification

of business processes.

3.7 Summary

In this chapter, we have presented a service composition model for specifying person-

alized and adaptive composite services in dynamic environments. The main features

of the model are:

• A service composition model based on revised statecharts modeling language.

• A set of user preferences that can be applied to recurrent process schemas for

the personalization of services provisioning.

• A divide-and-conquer approach to manage large amounts of services by group-

ing them into communities. Communities are responsible for the management

of their membership and for the runtime selection of services against user’s pref-

erences.

• A policy-based, multi-level exception handling approach for specifying excep-

tion handling strategies of composite services.

In order to validate our personalized and adaptive service composition model, we

have implemented a prototype that provides tools for: i) specifying process schemas

using a visual editor; ii) configuring process schemas usingpersonal preferences; and

iii) creating service communities and registering services with communities. In addi-


tion, UDDI registry was used for the Web service advertisement and discovery. More

details on the implementation can be found in Chapter 6.

Chapter 4

Tuple Space-Driven Service

Orchestration

During the execution of a composite service, the participating services need to co-

ordinate with each other and with the composite service in order to ensure that the

business logic of the composite service is enforced. This process is often termedor-

chestration. In existing systems for service composition [40, 149, 42, 90, 172], the

orchestration is ensured by a single process which acts as a central scheduler. These

orchestration models assume that the connection between the central scheduler and

the component services is continuously available, with thesame characteristics (e.g.,

latency, bandwidth, reliability). Such assumptions are not valid in the case of compos-

ite services for users in dynamic environments (e.g., mobile users), where executions

are initiated and followed up by, and especially for, a given(possibly mobile) client.

Indeed, clients may be disconnected during the execution ofa composite service. In

addition, centralized orchestration paradigms suffer of the availability and scalability

problems [45, 18]. Accordingly, we advocate that in order toachieve flexible and

scalable execution of personalized composite services in dynamic environments, the

participating services should beself-managed: they should be capable of coordinating

their actions in an autonomous way, without having to continuously synchronize with

a central entity, which could lead to idle periods and timeouts due to disconnections.

Chapter 4. Tuple Space-Driven Service Orchestration 82

In our proposed execution model, the self-orchestration isachieved by means of

execution controllers. A controller is associated with a service and is responsible for

monitoring and controlling service executions. The knowledge required by a controller

is statically extracted from the specification of personalized composite services. To

deal with the dynamic issues (e.g., disconnection) of the service provisioning environ-

ments, we propose atuple spaces[4] based orchestration model where the knowledge

of the service execution is represented in the form ofcontrol tuplesthat are placed in

and retrieved from the controller’stuple space.

In this chapter, we give a detailed description of our proposed composite service

execution model [152, 153]. Section 4.1 gives an overview ofthe proposed service

execution model. Section 4.2 illustrates the basic ideas ofthe execution model us-

ing our digital class assistant example. Section 4.3 presents some basic concepts and

Section 4.4 provides details of the control tuples that are used in our execution model

and shows how they are used to achieve self-orchestration. Then, Section 4.5 provides

algorithms for the generation of control tuples from personalized composite service

definitions and Section 4.6 discusses the control tuples enforcement. Section 4.7 an-

alyzes the centralized and distributed orchestration approaches from different aspects.

Finally, Section 4.8 provides an overview of the related work and Section 4.9 concludes

this chapter.

4.1 Design Overview

The proposed execution model is based on the idea that each state (task)t appearing

in a composite service specification is represented by anexecution controllerthat is

responsible for:

• Receiving notifications of completion from other controllers and determining


from these notifications when should statet be entered. These notifications of

completion include the relevant data items (i.e., the values of output parameters)

which have been gathered by the previous states visited during the execution.

• Invoking the service operation labellingt whenever all the preconditions for

enteringt are met. This invocation is done by sending a message to the Web

service and waiting for a reply.

• Upon completion of the service execution started in the previous step, notifying

this completion to the controllers of the states that may need to be entered next.

These notifications of completion contain all data items that need to be passed

on to the next state controllers.

• While statet is active, receiving notifications of external events (e.g., a cancel-

lation) and determining ift should be exited due to these event occurrences. If

so, the controller will interrupt the ongoing service execution and will send no-

tifications of “completion” to the controllers of the stateswhich potentially need

to be entered next.

In essence, the controller of a state is alightweight schedulerthat determines when

should a state be entered, and what should be done after the state is exited. The knowl-

edge needed by a controller in order to answer these questions at runtime is statically

extracted from the description of the personalized composite service (e.g., statecharts,

personal preferences, exception handling policies), and represented in the form ofcon-

trol tuplesas detailed in Section 4.4. The generation of control tupleswill be reported

in details in Section 4.5. Each controller is associated with atuple space[4] where the

control tuples of the corresponding task are stored. The details about the tuple space

model will be described in Section 4.3.


User Agent

AR Service QB Service-UNSW LF Service QP Service

2

3

4 5

6

Tuple space

Execution controller

1

7

TS

TS TS TS TS

TS

Control/data flow

Service invocation

Control tuple deployment

Legend

Figure 4.1: Tuple space based service orchestration

To deal with the possibility of resource-constrained computing devices—for exam-

ple, users may use mobile devices to invoke their personalized composite services—

we introduce the concept ofuser agent1 to facilitate the orchestration of personalized

composite services on behalf of a user. Software agents [186, 174, 83, 177]—which

motivated us in introducing user agents in our system—use their internal policies and

knowledge to decide when to take actions that are needed to realize a specific goal,

if necessary, they can even migrate as required. Internal policies can use context in-

formation (e.g., user preferences, device characteristics, and user location) and enable

agents to adapt to different computing and user requirements. By embedding exten-

sible knowledge and capabilities, agents extend services that make them capable of

providing personalized and adaptive services in dynamic environments.

Figure 4.1 gives an overview of the interactions during the enactment of a person-

alized composite service. When a user completes the configuration, her personalized

service is delivered to the user agent (step 1), which generates control tuples from the

service specification and deploys them to the tuple spaces ofthe involved Web ser-

1It should be noted that the concept of user agent is applicable to both mobile and fixed users.


vices/communities (step 2). After that, the controllers interact with their tuple spaces

(step 3) and enforce control tuples to i) invoke services (step 4), ii) interact with other

controllers (step 5), and iii) send service results to the user agent, which in turn, deliv-

ers the results to the user whenever it is appropriate (steps6 and 7). We will present

the enforcement of control tuples in Section 4.6.

Peer-to-Peer Control-flow Notification. A composite service execution is orches-

trated through peer-to-peer message exchanges between thecontrollers of the states

of the service’s description, and through message exchanges between the controllers

and the component services. The messages exchanged betweenthe controllers for the

purpose of notifying that a given state should/may be entered are calledcontrol-flow

notifications. A control-flow notification sent by a controllerc1 to a controllerc2 ex-

presses the fact that the execution of the state representedby c1 has completed, and

that c1 believes that the state represented byc2 needs to be entered. On the other

hand, the messages exchanged between the state controllersand the component ser-

vices are calledservice invocations/completions. Service invocations are performed

using SOAP, since every service in our system, whether elementary, composite, or

community-based, provides a SOAP entry point.

It should be noted that user agent acts as the controller of a personalized composite

service. When the service is invoked, the user agent sends a control-flow notification

to the controllers of the states which need to be entered in the first place. From that

point on, the execution of the composite service is orchestrated through peer-to-peer

interactions between the task controllers. At the end, the user agent receives back

the control-flow notifications indicating that the execution of the service instance is

terminated. The user agent can then return a completion message to the invoker.


Data Flow Notification. As stated in Section 3.2.2 of Chapter 3, the output param-

eters of a task may be needed either by the service requester or by other component

tasks of the composite service. The messages exchanged between controllers— con-

taining the values of the output parameters of a taskt1 that need to transmit to another

taskt2—are calleddata flow notifications. In Section 4.2, we will illustrate the mes-

sages exchanged between controllers and component services during the execution of

a composite service using our digital class assistant service.

4.2 An Orchestration Example

Figure 4.2 shows the messages exchanged by the controllers and the component ser-

vices during a particular execution of the composite servicedigital class assistant(see

Figure 3.2). The layout of the arrows indicates the type of the message (control-flow

notification, data flow notification, or service invocation/result) as explained in the leg-

end of the figure. The numbers labelling the arrows capture the temporal relationships

between the messages. For instance, message3 is sent after message2 that itself is

sent after message1. Some messages are exchanged as part of concurrent threads (e.g.,

for components in an AND state). In this case, the messages are given the same serial

number, followed by a character. For instance, the messagesstarting with5a and5b

in Figure 4.2 (e.g.,5a.1 and5b.1) are sent within concurrent threads because the

tasksAG andLO are components of two different concurrent regions of an ANDstate

(see Figure 3.2). Messages sent within the same thread are identified by serial numbers

within that thread. For instance, message5a.1, 5a.2, 5a.3, 5a.4, and5a.5 are

sequential messages exchanged within thread5a.

The messages are inserted into the tuple spaces of the corresponding execution

controllers (user agent). The tuple spaces then notify (viacallbackfunction) the rele-

vant controllers that will take the certain actions (e.g., sending out control-flow noti-


AR Service

AG Service

LO Service

QB Service

QV Service

QP Service

LF Service

Legend Tuple space Execution controller

Control-flow notification

Service invocation/completion

Data dependency notification

2

1

5a.1

5b.1

3

4

5a.2

5a.3

5a.4

5a.5

5b.2

5b.3 5b.4

5b.5

6.1 6.2

6.3

6.4

6.5

6.6

6.7

7

8 9

10

11

12

13

14

15

16

17

18

User Agent

TS

TS

TS

TS

TS

TS

TS

TS

TS

Figure 4.2: Interactions between the controllers and the component services during anexecution of digital class assistant

fications) according to the messages (e.g., service completions) and the control tuples

stored in the associated tuple spaces. Since we assume that atuple space is located

at the same machine of the controller (user agent), the messages between the tuple


space and the controller (user agent) are omitted. More details about the tuple space

paradigm can be found in Section 4.3.

The execution in this diagram starts when a user invokes the service digital class

assistant through her user agent (message1), which in turn, sends a control-flow no-

tification (message2) to the controller ofAR Service. The controller triggers the

service invocation (message3) after the interactions with its associated tuple space.

When the invocation of theAR Service is finished,AR Service returns an out-

put in a service completion message to the controller (message4).

The controller ofAR Service then dispatches a couple of messages: i) a control-

flow notification to the controller ofAG Service (message5a.1) and the controller

of LO Service (message5b.1); ii) a couple of data flow notification (i.e., messages

6.1 to 6.7) because the service outputs are needed by the user (e.g., message6.1

that is sent to the user agent), or by other components of the service (e.g., message6.7

that is sent to the controller ofLF Service). It should be noted that we distinguish

different types of messages for the purposes of illustrating the concepts of our exe-

cution model. It is possible—for example in the practical implementation—to merge

multiple messages together. For instance, message5a.1 and6.2 can be merged as

one single notification message.

When the invocations ofAG Service andLO Service are completed, their

corresponding controllers send control-flow messages (messages5a.4 and5b.4, re-

spectively) to the controller ofQB Service, which triggers the service invocation.

Assuming that the student wants to post her question, the controller of QB Service

sends a control-flow notification (message9) to the controller ofQP Service that

invokes the service (messages10 and11), and then dispatches a data flow notifica-

tion to the user agent (message12). Assuming that the class is over and the student

does not want to book a consultation (she has understood everything quite well), the


controller ofQP Service sends a control-flow notification to the controller ofLF

Service that invokesLF Service (messages14 and15). Once this invocation

is completed, a notification is sent to the user agent (message 17), and the overall

execution is completed. It is worth mentioning that for the sake of simplicity of the

illustrating purposes, we have not considered the cycles ofthe question asking com-

ponent (see Figure 3.2). However, the completed interactions of the controllers and

component services can be easily illustrated after the understanding of the basic idea

of the message exchanges from Figure 4.2.

4.3 Tuple Spaces and Control Tuples

In this section, we first overview the tuple space paradigm, then introduce the concept

of control tuples. Both of them lay the foundation of our service execution model.

4.3.1 Tuple Spaces: An Overview

The tuple space paradigm has been extensively researched—especially by the parallel

programming community—for over decades [4, 73, 35, 58, 126,69, 101]. The tu-

ple space model was conceived by researchers at Yale University and embodied in a

coordination language called Linda [4]. In Linda, a tuple space is a globally shared,

associatively addressed memory space that can be accessed concurrently by several

processes. It acts as a repository of a multiset of data structures calledtuples. Tuples

are anonymous and the communications of processes are de-coupled in both time and

space: providers and consumers do not need to be available atthe same time, and

the mutual knowledge of their locations is not necessary fordata exchange. Although

designed originally for parallel programming, the tuple space paradigm is recognized

as an attractive model for managing interactions among loosely coupled entities in


Primitive Primitive Functionality Blockingout(tpl) insert a tupletpl that can be composed of an arbitrary mix of actual

and formal fields into a tuple space. The tuple becomes visible to allcontrollers with access to that tuple space.

No

in(tp) extract a tuple that is matched against the templatetp. Tuples selectiontakes place through pattern matching on the tuple contents.The tuple isremoved from the tuple space.

Yes

read(tp) syntactically and semantically equivalent toin primitive, except thatthe matched tuple will not removed from the tuple space.

Yes

eval(tpl) similar toout primitive, except that it creates active rather than passivetuples, where separate controllers are spawned to evaluateeach of tuplesfields.

Yes

rdp(tp) similar toread primitive, except that it is nonblocking. Noinp(tp) similar toin primitive, except that it is nonblocking. No

Table 4.1: Operation primitives of tuple spaces

distributed and dynamic environments [35, 115].

The tuple space model provides a set of operation primitivesthat processes (e.g.,

execution controllers) can use to manage tuples. An execution controller can insert a

control tuple (Section 4.3.2) into a tuple space by performing theout primitive. For

example,out("failed(QPService,QP)","executionTimes(QPServi-

ce)<5", "retry(QPService)") emits a tuple with three string fields. This op-

eration is nonblocking. A detailed description of tuple space operation primitives can

be found in Table 4.1.

Extensive extensions to the Linda language have been made recently [107, 183,

35, 58, 126, 101]. For example, bothread andin primitives of Linda language are

blocking. The operatorsinp andrdp proposed in [107] are non-blocking versions

of read andin. TSpaces developed at IBM [183] is a combination of tuple space

and relational database technologies. Controllers can evenregister for event notifica-

tions, such as “let me know when a control-flow message is written to the tuple space”.

When the event occurs (i.e., the arrival of a control-flow message), the controllers

are notified through acallbackmethod (see Figure 4.3). Lime and L2imbo [126, 58]


Tuple Space 1. out

2. in

3. register for the injection of

4. callback

1. A controller of a service injects e.g., a control-flow notification to a tuple space

2. Another controller can get this message by performing an in operation.

3. the controller can also register with the tuple space to notify it about the arrival of this message

4. the controller will be notified by the tuple space about the arrival of the message

Figure 4.3: Tuple space operations

extends the Linda model to support mobility in both wired andwireless networks,

while MARS [35] introduces reactivity in tuple spaces for mobile agent coordination.

Finally, sTuples [101] combines the semantic Web and tuple space technologies to

provide a semantic infrastructure for tuple space model.

In the original Linda model, a single, global tuple space is provided as a repository

of all tuples that processes access. This design suffers from the issues like perfor-

mance, partitioning, and scalability. In our design, we exploit a multiple tuple spaces

model, rather than a single global tuple space, where tuple spaces are scattered across

the participating Web services of composite services (see Figure 4.2). In fact, support-

ing multiple tuple spaces removes the need to conduct all operations through a single

global tuple space on all machines, which is important for performance in distributed

environments and critical for environments where communications links are costly and

unreliable.


4.3.2 Control Tuples

The concept of control tuples in our execution model is defined as the following:

Definition 1 (Control tuple). A control tuple is a rule of the formE [C]/A where:

• E is a conjunction of execution events. Execution events are generated in re-

sponse to changes of the status of service execution environments, including

execution exceptions. For example,entered(l) means that the user has en-

tered the locationl. Table 4.2 gives some events supported in our system2. The

conjunction of two eventse1 ande2 is denoted ase1 ∧ e2 and the semantics is

that if an occurrence ofe1 and an occurrence ofe2 are registered in any order,

then an occurrence ofe1 ∧ e2 is generated.

• C is a Boolean expression that combines conditions on execution states includ-

ing event parameter values and service information (e.g., inputs and outputs of

tasks).

• A is a sequence of execution actionsaction1; action2; . . . ; actionn. The ac-

tions are executed in the order specified by the sequence. Some selected actions

supported in our approach are given in Table 4.3 (the signatures are omitted for

clarity reasons).�

Briefly, the basic semantics of a control tuple is as follows: when the event(s) of

the tupleE is triggered and if its condition(s)C evaluates to true, the corresponding

action(s)A will be performed.

2It should be noted that the exception events (e.g.,failed) are not included in this table. We haveintroduced them in Chapter 3 (see Table 3.4).


Events Descriptionsentered(locationl) the user has entered the locationl.started(timeIntervali) the current time is equal to the lower bound of intervali.ready(parametersp) the values of the input parametersp are available.completed(services) the notification of completion of the execution is received by the

controller attached to services.presentable(resultr, deviced) the service resultr is evaluated as presentable in the user’s device

d.arrived(resultr, useragenta) the service resultr is received by the user agenta.

Table 4.2: Selected events supported in our system

4.4 Service Orchestration Tuples

We provides two types of control tuples for the coordinationof personalized composite

service executions, namelyservice invocation tuplesandexception handling tuples.

4.4.1 Service Invocation Tuples

There are two kinds of service invocation tuples: i)pre-invocation tuplescontain the

knowledge to answer,beforethe execution of this task, questions such as what are the

actions that need to be performed and what are the conditionsthat need to be satisfied,

and ii) post-invocation tuplescontain the knowledge to answer,after an execution of

this task, questions such as which entities (e.g., other tasks) need to be notified of

this completion, and which output needs to be sent to which entity (e.g., the user). In

the following, we formally define the concepts of pre-invocation and post-invocation

tuples of a task.

First of all, we introduce the concept ofcompound transition, which will be used

in the definitions of service invocation tuples. As discussed in our service composition

model (see Chapter 3), a statechart can have compound states (AND and OR states)

which serve to decompose the statechart into substates and specify regions of the stat-

echart which can be executed concurrently. Due to this feature, there can be multiple


Actions Descriptionsnotify(taskt) send a notification of completion to taskt.sendResult(outputO, re-ceiverre)

send the values of the outputO to the receiverre, which could bea user, the user’s agent or other tasks.

transform(serviceResult r,tranformServices, deviced)

transform service resultr using the transformation services ac-cording to the capabilities of the user’s device.

execute(taskt) invoke the taskt.retry(services) allows to invoke the servicesanother time after a failure.informNewLocation(locationnewL, serviceSetSC)

inform the locationnewL of a user to the relevant Web servicesSC.

collectData(inputParameterin, supplyingSourcess)

collect the value of the input parameterin using the supplyingsourcess.

reassign(taskt, services) delegate the invocation of taskt to a services.

Table 4.3: Selected actions supported in our system

direct and indirect ways of transitioning from a given basicstate to another basic state.

In other words, when exiting a given state, there are a numberof transitions that can be

taken, some of which are simple (e.g., the transition betweenQB andQP in Figure 3.2)

and some are compound (e.g., the transition betweenQP andCB in Figure 3.2). Hence,

it is important to determine how to route control-flow notifications and data items be-

tween basic states. Intuitively, a compound transition is apath (i.e., a list of linked

transitions) going from a basic state to another basic statewithout passing through any

other basic state.

Definition 2 (Compound transition). A compound transitionCT is a sequence of

transitionstr1, tr2, ..., trn belonging to a given statechart, such that:

• source(tr1)3 is a basic state,

• target(trn) is a basic state, and

• for all i in [1..n-1], eithertarget(tri) is the final state of a region belonging to

the compound statesource(tri+1), or source(tri+1) is the initial state of a region

3Here, source(tr) denotes the source state of transitiontr, while target(tr) denotes the target state oftr.


belonging to the compound state target(tri).

Under these conditions,CT is said to connectsource(tr1) with target(trn), i.e.,

source(CT ) = source(tr1) andtarget(CT ) = target(trn). The condition part ofCT ,

notedCond(CT ), is the conjunction of the conditions labelingtr1, tr2, ..., trn, ex-

pressed asCond(CT ) = {c1 ∧ c2 ∧ · · · ∧ cn}, whereci is the condition labeling

transitiontri. �

Example 4.4.1 (Compound Transition). In Figure 3.2, a compound transition exists

betweenQP andCB (CT =< trq4, tr3 >) because the target state of transitiontrq4 is

the final state of the compound stateQuestion Asking, which is the source state

of transitiontr3. However,< trq4, tr3, tr5 > is not a compound transition.

It should be noted that although this definition of compound transition is specific

to statecharts, a similar concept can be defined for virtually any other language for

process-based service composition (e.g., BPEL). The techniques that we present here

can thus be applied to other languages, as long as a definitionof compound transition

for the language at hand is provided. After the introductionof the concept of compound

transition, we will give the definitions of the service invocation control tuples in the

following.

Definition 3 (Pre-invocation tuple). The pre-invocation tuples of taskt of a person-

alized composite serviceCS include two kinds of control tuples:data collectionand

preconditiontuples. The former is a control tuple such that:

• E is empty.

• C is a conjunction of temporal and spatial constraints oft, i.e., Θτ (t) and

Θζ(t). If t does not have any constraint,C is interpreted astrue.


• A are actions in the form ofcollectData(in,ss), wherein is an input

parameter whose value should be obtained from a supplying sourcess, which

could be an XPath query or the user.

While the precondition is a set of control tuples such that:

• E is a conjunction of eventsready(Θι(t)) and a set ofcompleted(t′),

wheret′ is a task that there exists a compound transitionCT such that source(CT )

=t′ and target(CT )=t. The eventcompleted(t′) is raised when a notification

of completion is received from taskt′.

• C is a conjunction of temporal and spatial constraints oft, i.e., Θτ (t) and

Θζ(t). If t does not have any constraint,C is interpreted astrue.

• A is an action in the form ofexecute(t), which invokes the taskt. �

Example 4.4.2 (Pre-invocation tuple). In our example (see Figure 3.2), there are two

pre-invocation tuples ofQP: i) [ Υ(between,[6:00pm Monday, 9:00pm Monday)∧Γ(Qu-

ad01A)]/collectData(subjectID,document(RCV(QP))/subjectID); collectData(question,

Andrew), and ii) ready(Θι(QP ))∧completed(QB)[Υ(between,[6:00pm Monday, 9:00-

pm Monday)∧Γ(Quad01A)]/execute(QP), whereΘι(QP ) is the set of the input param-

eters of taskQP. The first control tuple (a data collection tuple) indicatesthat if the

current time is between6:00pm and9:00pm on Monday and the user is currently

in the lecture room (i.e.,Quad01A), collect values for input parameterssubjectID

andquestion, by executing the XPath query and requesting to the user (i.e., An-

drew), respectively. The second control tuple (a precondition tuple) indicates that

when all the values of input parameters ofQP are available andQB is finished, if cur-

rent time is between6:00pm and9:00pm on Monday and the user is in the lecture

room, the invocation ofQP will start.


Definition 4 (Post-invocation tuple). The post-invocation tuples oft of CS contain a

set of control tuples such that:

• E is an eventcompleted(t). The event is generated when the execution of

taskt is completed.

• There exists a compound transitionCT such that source(CT )=t and target(CT )=t′.

• C is Conjunction(Cond(CT )), where Conjunction(c1 ∧ c2 ∧ · · · ∧ cn)={c1, c1,. . . ,

cn}.

• A are actionsnotify(t′) and a set ofsendResult(O, r). TheO is a set

of output parameters whose values need to be delivered to a receiverr, which

could be the user or another task ofCS. The actions are executed in the order

specified asaction1; action2; . . . ; actionn. �

Example 4.4.3 (Post-invocation tuple). In the running example, the post-invocation

tuple ofCB is: {completed(CB)[true]/notify(LF);sendResult(cons-

ultationDetails,Andrew)}. This tuple indicates that when the execution of

CB is completed, taskLF should be notified of this completion and the value of output

parameterconsultationDetails should be sent to the agent of Andrew.

4.4.2 Exception Handling Tuples

Definition 5 (Exception handling tuple). An exception handling tuple acts as an in-

struction to execute a particular action if a specific exception event occurs and a spe-

cific condition(s) holds. It is a control tuple such that:

• E is an exception event. Examples of exception events can be found in Table 3.4.


• C is a conjunction of conditions on execution states including event parameter

values and service information (e.g., input and output of tasks).

• A is an exception handling action. Examples of exception handling actions are:

i) retry(s), allows to re-invoke a services after a failure; ii)forward(s1,s2),

allows a services1 to forward an invocation message to another services2; iii)

transform(r,s,d), allows to transform service resultr using the transfor-

mation services according to the capabilities of the user’s deviced. �

Example 4.4.4 (Exception handling tuple). The tupleunpresentable(r,d)[t-

rue]/transform(r, TS,d) indicates that if the service resultr can not be dis-

played in the user’s current deviced, the result will be sent to a transformation service

TS for adaptation.

4.4.3 Discussion

The ECA model was originally developed in active database systems [135] and has

been widely used in workflow and business processes management [40, 48, 59, 27].

Although the ECA model has a sound theoretical basis, it is noteasy to visualize the

meaning of rules and, thus, very difficult for users to understand and manage them. In

addition, the previous approaches require a considerable amount of manual efforts in

generating rules, causing many difficulties in dealing withcomplex processes [38].

Our approach, in fact, combines the techniques of graphicalprocess representa-

tion and ECA rules. The statechart based service compositionmodel provides conve-

nience for a human user to grasp the actual processes, while ECA rules (i.e., control

tuples in PCAP) are used to transform the graphical model of composite services into

a machine-readable form so that the execution of the composite services can be per-


formed automatically. In particular, we developed an algorithm to systematically an-

alyze composite service specifications, which in turn, automatically generates service

orchestration rules, based on a set of abstracted events andactions. We will discuss the

algorithm in Section 4.5.

The most significant benefit of realizing service orchestration by means of control

tuples (in the form of ECA rules) is what we calledknowledge independence, in the

sense that control tuples are specified and stored separately from a composite Web

service specification. This provides the possibility of distributing control tuples to

participating Web services, thereby realizing a fully distributed execution of composite

services.

Our design of service orchestration tuples possesses two advantages. Firstly, the

knowledge (i.e., pre-invocation, post-invocation, and exception handling) of the execu-

tion of a task is expressed in the form of tuples, which provides the possibility to store

and operate the knowledge using powerful coordination models such as tuple spaces.

Tuple spaces have the advantage of providing direct supportfor asynchronous interac-

tions in which thesender(e.g., the client device) and thereceiver(e.g., a component

service) are separated in both space and time. This enables users to disconnect—either

voluntarily to save communication cost, or involuntarily because of breakdowns of

communications—at any time and re-synchronize with the underlying infrastructure

upon reconnection. Secondly, the design of pre-invocationand post-invocation tuples

considers both the control flow and data dependencies of the personalized composite

services. In particular, when the execution of a task is completed, only the output pa-

rameters whose values are needed by other entities (e.g., the user or other tasks of the

composite services) are dispatched. As a result, the communication requirements are

minimized.


4.5 Control Tuples Generation

In this section, we describe in turn the algorithms for generating the service invocation

and exception handling tuples from personalized compositeservices.

4.5.1 Pre-Invocation Tuples Generation

The generation of pre-invocation tuples of a task relies on the personalized attributes of

the task (e.g., temporal and spatial constraints), data dependencies of input parameters,

and control flows associated with the task. The task’sincomingtransitions are analyzed

and pre-invocation tuples are generated for each incoming transition of the task.

The algorithm for the generation of pre-invocation tuples of a task is given in Fig-

ure 4.4. It takes as input a taskt and produces a set of pre-invocation tuples fort.

The algorithm analyzes the data dependencies of the input parameters (ID, line 2)

and the incoming transitions oft (T RI , line 1). FromID, a set of actions (CD) is

created prescribing which supplying source should be used in order to get the value

of which input parameter (lines 4-7). The data collection tuple of t is then created by

putting temporal and spatial constraints (Θτ andΘζ) as condition andCD as action

(line 8). The pre-invocation tuples oft is the union of the data collection tuple and the

precondition tuples associated with the incoming transitions oft (lines 9-11).

The function namedPreProcT computes the preconditions of a transition. It

takes as input a transitiontr, and returns a set of precondition tuples associated with

this transition. PreProcT distinguishes the cases where the source of the transi-

tion is a basic state, an initial state, and compound state (i.e., AND or OR state).

In the first case, the preconditionready(Θι)∧completed(source(tr))[Θτ

and Θζ]/execute(t) is created, meaning that when all the values of the input

parameters oft are available, and the execution of tasksource(tr) is finished, if the


Algorithm : PreInvInput : tasktOutput : the set of pre-invocation tuplesPRE

1: LetT RI={tr1,tr2,...,trn} be incoming transitions oft.2: Let ID={id1,id2,...,idm} be input data dependencies oft. idi = (ini, ssi) meaning

that the value of input parameterini should be obtained from the supplying sourcessi.3: PRE ← φ4: LetCD ← φ be the set including actions that collect values for input parameters.5: for all idi ∈ ID do6: CD ← CD ∪ collectData(ini, ssi)7: end for8: PRE ← [Θτ and Θζ ]/CD /*data collection tuples*/9: for all tri ∈ T RI do10: PRE ← PRE ∪ PreProcT(tri)11:end for12:return PRE

13: PreProcT(tr)=14: if source(tr) is a basic statethen

{ready(Θι)∧completed(source(tr))[Θτ andΘζ ]/execute(t)}15: else ifsource(tr) is an initial statethen16: letSUP = superstate(source(tr))17: if SUP is the topmost state of the statechart,then18: {ready(Θι)[Θτ andΘζ ]/execute(t)}19: elselet {st1, st2, . . . ,stn} be the incoming transitions ofSUP20: PreProcT(st1)∪PreProcT(st2). . .∪PreProcT(stn)21: else ifsource(tr) is an OR statethen22: let{ft1, ft2, . . . ,ftn} be the final transitions of source(tr)23: PreProcT(ft1)∪PreProcT(ft2)∪ . . .∪ PreProcT(ftn)24: else/* source(tr) is an AND state */25: let{CR1, CR2, . . . ,CRn} be the concurrent regions of source(tr),26: let{ft1 CR1, ft2 CR1, . . . ,ftn CR1} be the final transitions of ofCR1,27: let{ft1 CR2, ft2 CR2, . . . ,ftn CR2} be the final transitions of ofCR2,28: . . .29: let{ft1 CRn, ft2 CRn, . . . ,ftn CRn} be the final transitions of ofCRn

30: (PreProcT(ft1 CR1)∪ . . .∪ PreProcT(ftn CR1)) ×31: (PreProcT(ft1 CR2)∪ . . .∪ PreProcT(ftn CR2)) ×32: . . .33: (PreProcT(ft1 CRn)∪ . . .∪ PreProcT(ftn CRn))

Figure 4.4: Algorithm for generation of pre-invocation tuples (PreInv)

temporal and spatial constraints are satisfied, taskt will be executed (line 14). In the

second case (the transitiontr stems from an initial state), the incoming transitions of

its superstate are considered and one or several precondition tuples are generated for

each of them (lines 15-20). Notice that if the superstate oftr is the topmost state of


{e1[c1]a1, e2[c2]a2, . . . ,en[cn]an})× {e′1[c′1]a′1, e′2[c′2]a′

2, . . . ,e′n[c′n]a′n}=

{e1 ∧ e′1[c1 ∧ c′1]a1 ∧ a′1, e1 ∧ e′2[c1 ∧ c′2]a1 ∧ a′

2, . . . ,e1 ∧ e′n[c1 ∧ c′n]a1 ∧ a′n,

e2 ∧ e′1[c2 ∧ c′1]a2 ∧ a′1, e2 ∧ e′2[c2 ∧ c′2]a2 ∧ a′

2, . . . ,e2 ∧ e′n[c2 ∧ c′n]a2 ∧ a′n,

. . .

en ∧ e′1[cn ∧ c′1]an ∧ a′1, en ∧ e′2[cn ∧ c′2]an ∧ a′

2, . . . ,en ∧ e′n[cn ∧ c′n]an ∧ a′n }

Figure 4.5: Cartesian production of ECA rule sets

the statechart,tr is aninitial transition of the composite service and the precondition

tuple therefore is{ready(Θι)[Θτ and Θζ]/execute(t)}. In the third case

(the transitiontr stems from a compound state), the functionPreProcT is applied

recursively to the final transitions of the compound state, and the results are merged

(lines 21-33). In the case of an OR state, the merging is a simple set union (line 23).

In the case of an AND state, each concurrent region is treatedas an OR state, and the

precondition tuples obtained for each concurrent region are merged through aCarte-

sian product(lines 25-33), meaning that the AND state is exited (i.e., task t can be

executed) if one of the final transitions in each of the concurrent regions is taken.

The binary operator× (Cartesian product) used in this algorithm takes as parame-

ters two sets ofE [C]/A rules (saySR1 andSR2) and generates a set ofE [C]/A rules

by combining each element ofSR1 with each element ofSR2, where the combination

of a rulee1[c1]/a1 with another rulee2[c2]/a2 is e1∧e2[c1∧c2]/a1∧a2 (see Figure 4.5).

4.5.2 Post-Invocation Tuples Generation

Similarly, Figure 4.6 describes the algorithmPostInv for generating post-invocation

tuples for a task. The algorithm takes as input a taskt, and produces a set of post-

invocation tuples. The algorithm analyzes the data dependencies of the output param-

eters (OD, line 2) and the outgoing transitions oft (T RO, line 1). FromOD, a set

of actions (i.e.,RD) is created indicating which outputs should be delivered towhich


Algorithm : PostInvInput : tasktOutput : the set of post-invocation tuplesPOST

1: LetT RO={tr1,tr2,. . . ,trn} be outgoing transitions oft.2: LetOD={od1,od2,. . . ,odm} be output data dependencies oft. odi = (Oi, ri) meaning that

output parametersOi should be delivered tori.3: POST ← φ4: LetRD← φ be the set including actions that deliver outputs to the receivers.5: for all odi ∈ OD do6: RD ←RD ∪ sendResult(Oi, ri)7: end for8: for all tri ∈ T RO do9: POST ← POST ∪ AddAction(RD, PostProcT(tri))10:end for11:return POST

12: PostProcT(tr)=13: if target(tr) is a basic statethen {completed(source(tr))[cond(tr)]/notify(target(tr))}14: else iftarget(tr) is a compound statethen15: let{it1, it2, . . . , itk} be the initial transitions of target(tr)16: AddCond(cond(tr), PostProcT (it1)∪PostProcT(it2)∪. . .∪PostProcT(itk))17: else iftarget(tr) is a final statethen18: letSUP=superstate(target(tr))19: if SUP is the topmost state of the statechartsthen20: {completed(source(tr))[cond(tr)]/notify(SUP)}21: else ifSUP is an OR statethen AddCond(cond(tr), PostInv(SUP))22: else

⋃

s∈CTargets(SUP)

{completed(source(tr))[cond(tri)]/notify(s)} }

23: AddCond(c, {e1[c1]a1, e2[c2]a2, . . . ,en[cn]an}) = {e1[c andc1]a1, e2[c andc2]a2, . . . ,en[candcn]an}

24: AddAction(A, {e1[c1]a1, e2[c2]a2, . . . ,en[cn]an}) = {e1[c1]a1, e2[c2]a2, . . . ,en[cn]an} ∪⋃

a∈A

{e1[c1]a, e2[c2]a, . . . ,en[cn]a }

25: CTargets(t)={target(CT )| CT is a compound transition∧ source(CT )=t}

Figure 4.6: Algorithm for generation of post-invocation tuples (PostInv)

receivers (lines 4-7). The post-invocation set oft is the union of the post-invocation

tuples associated with the outgoing transitions oft (lines 8-10).

The post-invocation tuples for each outgoing transition ofa task are generated by

a function namedPostProcT, which takes as input a transitiontr, and returns a

set of post-invocation tuples including the postprocessing actions associated with this

transition. There exist various cases. Whentr leads to a basic state (sayt′), the post-

invocation tuplecompleted(source(tr))[c]notify(t′) is created, meaning


that after the execution of the task is completed, if the condition c is true, a noti-

fication must be sent to the task controller oft′ (line 13). If an outgoing transition

points to a compound state, one post-invocation tuple is generated for each of the ini-

tial transitions of this compound state (lines 14-16). Finally, if the outgoing transition

points to a final state of a compound state, the outgoing transitions of this compound

state are considered in turn, and one or several post-invocation tuples are produced for

each of them (lines 17-22). Three auxiliary functionsAddCond, AddAction, and

CTargets are described in lines 23-25 using a functional programmingstyle. Note

thatPostProcT does not handle the output data dependencies of the task (i.e.,RD),

which need to be added to the tuples generated byPostProcT (line 9).

4.5.3 Exception Handling Tuples Generation

Exception handling tuples are generated from pre-defined exception handling policies

(Section 3.5). Since exception handling policies are expressed as extended Ponder

obligation polices that are also event-condition-action rules, the generation of excep-

tion handling tuples from exception handling policies is straightforward.

The generated tuples are then injected into the tuple spacesof execution controllers

and/or the user agent. The information on where an exceptionhandling tuple should

be uploaded is specified in thetarget entity of the corresponding exception handling

policy. As we introduced in Section 3.5, there are three different kinds of targets,

namelycomponent service, service community, anduser agent:

• If the target of a policy is acomponent service, the generated exception handling

tuples should be injected into the tuple space of the execution controller of the

service. For example, the tuple generated from theServiceFailure policy

(Table 3.5) should be put into the tuple space of the controller ofQPService.


• If the target of a policy is aservice community, the generated exception handling

tuples should be injected into the tuple space of the execution controller of the

community. For example, the tuple generated from theNewMember policy

(Table 3.5) should be emitted to the tuple space of the controller of QBS-UNSW.

• If the target of a policy is auser agent, the generated exception handling tuples

should be injected into the tuple space of the user agent. Forexample, the tuple

generated from theResultDelivery policy (Table 3.5) should be emitted to

the tuple space of the user agent (i.e.,Andrew-Agent).

It should be noted that currently we do not handle certain unexpected adverse con-

ditions. For example, we assume that the components responsible for the composite

services orchestration (e.g., user agents, execution controllers) do not fail, which in

fact, could be failed themselves due to unpredictable exceptions. One possible solu-

tion to address such failures is awatchdogmechanism where two identical controllers

are running at different servers. Only one is employed during the service orchestration.

The second one is spare that monitors the first one. If the firstone fails, the second one

contacts the controller of the composite service, which relocates the invocations of the

service to its spare controller, probably rewrites some relevant control tuples and de-

ploys them to the corresponding tuple spaces. There are alsomany other solutions that

are adaptable from research fileds like databases [28] and Web servers [37]. However,

this is not the focus of our work.

4.6 Control Tuples Enforcement

The orchestration of personalized composite services is realized by enforcing the con-

trol tuples. The enforcement of control tuples is a process that involves interactions

between several elements, namely theexecution controller, theevent manager, and the


context manager. These three elements form what we callservice container.

Each service is associated with a controller that monitors and controlls the service

execution and each controller is associated with a tuple space where the orchestration

tuples are stored. A controller enforces the control tupleswith the help of the event

manager and the context manager. The event manager is responsible for disseminat-

ing events (including exceptions) registered by the controller, while the context man-

ager is responsible for collecting context information from context providers. Context

providers can be components inside the system (e.g., controllers provide execution sta-

tus of services, a user agent provides the user’s location),or third party entities outside

the system (e.g.,GlobalWeather Web service provides forecasted weather infor-

mation). The event manager and context manager provide an extensible interface in

the sense that new events and contexts can be easily added forspecific personalized

composite services.

Figure 4.7 illustrates the enforcement process. When the control tuples, which are

generated from a personalized composite service by a user agent, are injected into the

tuple space of a Web service (step 1), the service’s execution controller parses the con-

trol tuples (step 2), retrieves relevant information (e.g., events, conditions, and actions),

and registers the events (e.g.,failed) to the event manager (step 3). The event man-

ager then subscribes relevant contexts needed by the events(e.g.,executionStatus

for eventfailed) to the context manager (step 4), which collects the contextval-

ues from relevant context providers. The event manager firesand distributes events

if the corresponding conditions4 are matched (e.g.,executionStatus=“failed”)

(step 5). Upon receiving the notifications (i.e., the occurrence of the events) from the

event manager, the controller extracts the corresponding control tuples from the tuple

space (step 6), evaluates the conditions, and performs the proper actions, e.g., service

4Note that the event manager maintains the information of events, for example, which context(s) isrelated to an event occurrence and in what condition.


Web Service

2 Execution controller

Event manager Context

manager

Tuple Space

User Agent

1

4

Context provider

Context provider

Context provider 3 5

7

Service Container

6

control tuples

contexts

control tuples

event notification

event subscription

control tuples

contexts

TS

Figure 4.7: Interactions of control tuple enforcement

invocation (step 7).

Example 4.6.1 (Control tuple enforcement). To illustrate how the control tuples are

enforced, consider{completed(CB)[true]/notify(LF);sendResult(c-

onsultationDetails,Andrew)}, a post-invocation tuple of taskCB of our dig-

ital class assistant (Figure 3.2). When the tuple is generated and injected into the

tuple space ofCB, the controller ofCB analyzes the tuple and registers the event

completed(CB) with the event manager ofCB. The event manager then interacts

with the context manager for the contextexecutionStatus, which is provided by

the controller ofCB, and evaluates the conditionexecutionStatus="OK". If the

condition evaluates to true, the event manager fires the event completed(CB) and

notifies the controller. At this point, the controller extracts the tuple from the tuple

space, evaluates its condition (true in default), and sendsa notification message to the

controller ofLF (i.e.,notify(LF)) and the consultation details to the user agent of


Andrew (i.e.,sendResult(consultationDetails, Andrew)).

4.7 Analysis of Centralized and Distributed Orchestration

In our proposed distributed orchestration approach—as illustrated in Figure 4.8 (b)—

the execution controller of a statet (together with its corresponding tuple space) is

placed in thesame machine as the service invoked int. As a result, every notification—

either control-flow or data flow—potentially entails aphysical message exchange(i.e.,

a message exchanged between different physical machines).On the other hand, an

invocation to a component service does not involve any physical message exchange.

In practice however, a controller and the component servicethat it invokes can be

located in separate machines, in which case a message from a controller to the com-

ponent service entails a physical message exchange. Furthermore, several controllers

can be placed in the same physical machine, so that a control-flow notification ex-

changed between these controllers does not entail any physical message exchange. In

an extreme case, all the controllers can be placed in the samephysical machine. We

will subsequently call this orchestration approachcentralized, since the set of all the

controllers placed in a single physical machine can be seen as forming a central sched-

uler (Figure 4.8 (a)). Due to its simple implementation, many Web service composition

approaches are based on this centralized orchestration paradigm [40, 149, 42, 90, 172].

Both centralized and distributed approaches have their own merits and demerits.

For example, the centralized approach is easier to implement but suffers from com-

munication bottleneck of the central scheduler. Meanwhile, the distributed approach

is more scalable and reliable but introduces communicationoverhead (e.g., more ex-

changed messages). In the sequel, we analyze the distributed and the centralized ap-

proaches in terms of scalability, performance, and messageexchanges.


CompositeService

Service1

Service2

Service3

Composite Service

Service1

Service2

Service3

Control flow notification

Data flow notification

( a ) ( b )

Tuple space

Controller

TS TS

TS

TS

TS

TS

Figure 4.8: Control-flow and data-flow notifications of (a) centralized and (b) dis-tributed orchestration approach

4.7.1 Scalability and Performance

As Figure 4.8 (a) shows, in the centralized approach, the controller of a composite ser-

vice serves not only as a central scheduler for control-flow notifications, but also as a

hub for all the data communications. The controller forwards data between two com-

ponent services when the data produced by one service is needed by another. Since the

data is sent indirectly, redundant data traffic is resulted.Therefore, the controller of the

composite service becomes acommunication bottleneckwhen large volumes of data

(e.g., multimedia data) are exchanged among services. Furthermore, the controller

becomes thecritical system resource because all the communications go through the

controller. The approach is especially problematic in a Webservice composition en-

vironment where the participating services are autonomousand heterogeneous. The

centralized communication topology makes the approach hard to scale.


Since all the communications go through the controller, it is easy to deduce that

the performance of the centralized approach will decrease quickly with the increasing

of the number of component services and the number of requests (i.e., workload).

Another severe problem is the risk of the single point of failure, which can compromise

the overall fault-tolerance of the composite services.

In contrast, for the distributed approach proposed in our work, the control-flow and

data dependency notifications are exchanged directly between participating services

without going through the controllers of composite services. The redundant data traffic

caused by the forwarding of data through composite servicesis therefore eliminated.

In distributed approach, the workload is splitted evenly among the component services,

instead of being allocated solely to the controller of a composite service. As a result,

the communication load on the controller of the composite service is alleviated. Since

the communications are distributed to the participating services, the performance of

composite services i) is not affected by the number of the component services; and

ii) is not sensitive to workloads. In addition, instead of the single point of failure, the

distributed approach permits a graceful degradation of theoverall performance if one

or more component services become unavailable.

4.7.2 Message Exchanges

The advantages of the distributed approach (e.g., scalability, better performance for

large composite services with high workloads), however, donot come for free. It may

introduce a communication cost (i.e., more exchanged messages). In this section, we

compare the both approaches in terms of physical message exchanges. Specially, we

estimate the maximum number of physical message exchanges required by a compos-

ite service execution, in terms of the number of invocationsto component services

involved by this execution. These physical message exchanges can result either from


control-flow notifications or from invocations to componentservices.

The worst-case number of physical message exchanges required by an execution

of a composite service involvingn invocations to component services is2×n. Indeed,

in this approach only the invocations to component servicesand data flow notifications

entail physical message exchanges: the control-flow notifications do not. Moreover,

each invocation to a component service requires two messages: one from the con-

troller to the component service and another from the component service back to the

controller.

The worst-case number of physical message exchanges required by an execution

of a composite service involvingn invocations to component services, is bounded by

m × (n + 1), wherem is the number of basic states in the corresponding statechart.

The reasoning behind this bound is the following. First, we note that only the control-

flow and data flow notifications require physical message exchanges: the invocations

to component services do not require so, since the controller that performs this invo-

cation is located in the same machine as the component service that is invoked. Next,

we note that each time that a basic state is exited, at mostm notifications are sent by

the controller of this state:m − 1 to its fellow controllers and 1 to the user agent.

Hence, after an invocation to a component service is completed and the corresponding

state is exited, at mostm physical message exchanges take place. If the composite ser-

vice execution involvesn invocations to component services,n×m physical message

exchanges take place during it. Moreover, when the composite service begins its exe-

cution, at mostm messages are sent by the user agent to the controllers. Overall, the

worst-case number of physical message exchanges is thusm + m× n = m× (n + 1).

The above is a tight bound as evidenced by the example in Figure 4.9. In this ex-

ample, each time that one of the states labelledt1, · · · , tm is exited, the corresponding

controller must send one control-flow notification to each ofthe other controllers, and


t1

t2

tm

C1

C2

Figure 4.9: Worst-case scenario for the distributed orchestration approach.

one to the user agent. Indeed, in the worst-case none of the controllers is able to fully

evaluate the conditionsC1 andC2: these conditions may involve one data item from

each of the invocations tot1, · · · , tm, so that each controller must send the data item

that it collects to all the other controllers and let them evaluate these conditions when

they have all the data items required. Hence, each invocation to a component service is

followed bym control-flow notifications, leading to a total ofm×n physical message

exchanges. This, added to them messages that the controller of the composite ser-

vice needs to send to the controllers of the states labelledt1, · · · , tm, yields exactly the

above bound. The above however is an extreme case. In practice, provided that there

are no or few AND-states followed by conditional branches such as that of Figure 4.9,

one can expect that the distributed approach requires less physical message exchanges

than above bound. A detailed performance study of both distributed and centralized

approaches can be found in Chapter 6.


4.8 Related Work

Composite services orchestration is a very active area of research and development.

There are quite a number of projects that have addressed the issues of specification

and enactment of composite services [40, 149, 42, 90, 172, 7]. The underlying exe-

cution model of these projects is based on a centralized process execution engine that

is responsible for scheduling, dispatching, and controlling the execution of all the in-

stances of a composite service. This contrasts with our work’s distributed execution

approach where the control flow and data flow notifications aredirectly exchanged

between participating component services without going through the controller of a

composite service.

CPM [45] supports the execution of inter-organisational business processes through

peer-to-peer collaboration between a set of workflow engines, each representing a

player in the overall process. A major difference between CPMand our work, is that

in CPM, the number of messages exchanged between the players is not optimised. In-

stead, each time that a process terminates a task, it must notify it to all the other players.

Hence, if a process involvesn tasks andmplayers, its execution requires the exchange

of n × m messages: far more than required as shown in our analysis. Moreover,

CPM requires that all the players participating in an inter-organizational process de-

ploy a full-fledged workflow engine to cater for the coordination with the other players,

whereas in our work the coordination between entities is handled through lightweight

schedulers (the state controllors).

Our work’s distributed orchestration model has also some similarities with the one

used in the Mentor distributed workflow system [127]. Given aworkflow specified

as a state and an activity chart, Mentor partitions it into several sub-workflows, each

encompassing all the activities that are to be executed by a given entity within an or-

ganisation (thereby assuming that this information is statically known). Each of these


sub-workflows is itself specified as a statechart. [127] describes some optimization

techniques that reduce the number and the size of the messages exchanged by the

sub-workflows, leading to aweak synchronisationmodel close (though using different

techniques) to that of our work. Also in the context of the Mentor project, [76] further

considers the issue of configuring a distributed workflow system in order to meet per-

formance and availability constraints while minimising the system costs. [41] proposes

a decentralized orchestration approach where a composite Web service specification is

partitioned and executed at distributed locations. Both approaches differ from our

work’s, in that they are only applicable when the assignmentof activities to their exe-

cuting entities is known during the deployment of the workflow, which is a restrictive

assumption in the context of service composition where providers can leave and join a

community or alter the characteristics of their offers (e.g., the QoS or the price) after

the composite service has been defined and deployed. In addition, both approaches

depend on full-fledged execution engines (e.g., BPWS4J5) for the execution of par-

titions, which contrasts with our lightweight coordination controllers. OSIRIS [148]

also feature a distributed, peer-to-peer service orchestration model. OSIRIS proposes

a distributed process engine that routes process instancesdirectly from one node to the

next ones. The meta information of a composite service is maintained in global repos-

itories and distributed to participating nodes. The generation of such meta information

from composite service specifications, however, is not given.

Finally, the use of tuple spaces is well received by the Web services community [69,

51, 136]. In TSpaces Services Suite (TSSuite) [69], the authors have developed a set of

tuple spaces based tools to help in the development and management of Web services.

These tools aim at simplifying the creation, deployment, configuration, and invocation

of services. In JOpera project [136], authors exploit tuplespace to store the state

information during the enactment of composite services. Compared to the work in

5OASIS Business Transaction Protocol, http://www.oasis-open.org/business-transaction/.

http://www.oasis-open.org/business-transaction




JOpera and TSSuite, our use of tuple spaces is one step forward. Indeed, we use tuple

spaces to orchestrate Web services provisioning and exception handling. In PageSpace

project [51], a tuple space based architecture is introduced for designing interactive

applications on the Web. Unlike our distributed tuple spaces model, all these projects

feature a single, global tuple space that is quite limited interms of performance and

scalability and therefore is inappropriate for the services provisioning in distributed

and dynamic environments.

4.9 Summary

In this chapter, we have presented a tuple spaces based service orchestration model for

the enactment of personalized and adaptive composite services. The main features of

our execution model include:

• The model is distributed in the sense that the component services participating in

a composite service interact with each other—via a lightweight scheduler called

execution controller—to ensure that the control and data flow dependencies ex-

pressed in the specification of the composite service are respected,

• The model is tuple spaces based where the knowledge of the service coordination

is represented in control tuples stored in multiple tuple spaces that are associated

with the component services,

• The orchestration of composite services exploits an event triggering mechanism

where the communications of the orchestration are asynchronous, which makes

our execution model applicable not only in full-fledged wired environments, but

also in unreliable wireless environments, and

• The model provides the support of run-time exceptions handling for adaptive


and flexible execution of composite services.

We have implemented the proposed execution model and also conducted a couple

of experiments for the performance evaluation of the model,including the performance

comparison of centralized and distributed approaches. We will report the details of the

implementation and performance evaluation in Chapter 6.

Chapter 5

Robust Web Services Provisioning in

an Environment of Computing

Resources

Prompt responses and robustness are of paramount importance to Web services provi-

sioning [55, 94, 173, 100]. It is costly for an enterprise if its services are down, for

even a few minutes. Such situations like service delay and unavailability could be vi-

tal and are not acceptable for many important Web applications (e.g., mission-critical

applications of companies). Unfortunately, given that thenumber of requests of a Web

service is potentially huge, a single service host may not besufficient to provide low

response times and may be completely unavailable. It is hence reasonable to run mul-

tiple instances of a service on a cluster of computing resources and to route incoming

requests within the cluster in a way that there is no load skew.

In this chapter, we propose techniques for robust Web services provisioning [113,

114, 112]. The proposed approach builds upon the system model introduced in Chap-

ter 3 and 4. The core part of our design is a new service container component (see Sec-

tion 4.6) calledservice migrator. A service migrator, which is associated with amobile

Web service, can instantiate an instance of the service at appropriate idle computing

Chapter 5. Robust Web Services Provisioning 118

resources during runtime on demand and therefore, reduces the risk of the service be-

ing unavailable. Furthermore, due to load balancing, a faster processing of service

requests can be achieved. To facilitate dynamic resources selection, we introduce a

flexible, semi-structured data model for the description ofservices and resources, as

well as amatchmakingalgorithm for selecting computing resources against the re-

quirements of Web services. To achieve optimized overall performance of a composite

service, we propose a multi-phase execution planning approach where resources are

selected for the components of the composite service based on a number of criteria

such as communication cost.

The chapter is organized as follows. In Section 5.1, we introduce our model for

robust services provisioning, in particular the functionalities of service migrators and

their interactions with other components such as service controllers, matchmaker, and

computing resources. Then, in Section 5.2, we present a datamodel for describing ser-

vices and resources, and an algorithm for resources matchmaking. In Section 5.3, we

propose a multi-phase execution planning algorithm for composite services. Finally,

we discuss the related work in Section 5.4 and conclude the chapter in Section 5.5.

5.1 The Proposed Model for Robust Service Provisioning

In this section, we will present our model for robust services provisioning after the

introduction of the concept of mobile Web services.

5.1.1 Mobile Web Services

Providing Web services to a large number of users might be problematic because: i)

a single service host may not be sufficient to guarantee a low service response time if

a lot of users access the service concurrently; and ii) the service will be completely


unavailable if there is any problem with the service or the service host. Therefore, it

is ideal that a service can be initialized at multiple service hosts and the invocation

request of the service can be always directed to the service host with lower workload.

Code mobility is a powerful concept in general for handling load balancing, per-

formance optimization, fault tolerance, and disconnections [72]. Code mobility would

contribute significantly to prompt service responses in thesense that heavy loaded or

unavailable service hosts can be replaced dynamically by light loaded service hosts.

Currently, there are many mobile code technologies like Aglets [3], Java [162], Suma-

tra [2], andµCode [124]. These technologies form the solid underpinningsof our

approach for robust services provisioning.

We distinguish betweenmobile and stationaryservices. Stationary services are

location dependent. Such a service can not move because e.g., the service needs to

access a DBMS that is only available on its dedicated server. Meanwhile, mobile

Web services are services with migration ability [113, 100]. On the one hand, mobile

Web services dynamically interacts with other services or clients, integrating existing

services, and being part of another (composite) service, asan ordinary Web services.

On the other hand, mobile Web services has the migration ability as a mobile agent,

facilitating local interaction with a service or selectionof computing resources to use.

Mobile Web services are location independent. They are stateless (i.e., the internal

state of such a service is discarded after a request is processed) and do not require

special resources or permissions. A mobile Web service can therefore be executed on

arbitrary service hosts whose capabilities satisfy the requirements of the service (see

Section 5.2).

Mobile Web services provide a number of distinct features. Firstly, mobile Web

services can migrate to the client sites where services are invoked as local calls. It

is extremely useful when the data (input and output of the services) are huge since


the data do not have to be put on the network. Secondly, mobileWeb services can

dynamically select a host to migrate so that they can use the computing resources to

accomplish their tasks or to achieve load balancing. Thirdly, mobile Web services pro-

vide a solution to the robust service provisioning in mobilecomputing environment in

which limited resources and unstable connections are a norm. Services can be always

migrated to more stable hosts.

Mobile Web services recently attracts a significant interest [46, 120, 110, 95, 113,

100]. The works proposed in [113, 95] consider mobile Web services as synthesis of

Web services and mobile agents. While the work in [110] develops an XML-based

mobile code language called X# and presents an approach to enabling Web services

containers to accept and run mobile codes. It should be notedthat proposing tech-

niques for the development of mobile Web services is not the focus in the work of this

dissertation. Instead, we use the concept of mobile Web services in our model for the

robust services provisioning.

5.1.2 Robust Services Provisioning

Central to our design towards a robust provisioning of composite services are a set of

service hosts, a monitoring service, an extension to the concept ofexecution controller

(introduced in Chapter 4), and a new service container component namedservice mi-

grator. A service host is a computing resource1 that is running a runtime engine where

service codes can be executed. Service hosts can register themselves at a UDDI reg-

istry using appropriate tModel2 (e.g.,ServiceHost) so that they can be found by

services. A monitoring service monitors the status of a computing resource or the

server of a Web service (e.g., CPU and memory usage). The extended execution con-

1In the remainder, we will use terms service host, computing resource, and resource interchangeably.2In UDDI, a tModel provides a semantic classification of the functionality of a service or a resource,

together with a formal description of its interfaces.


trollers interact with the monitoring services. If the value of a monitored item is be-

yond a critical point—which can be set by the service provider—and the service is

moveable, the controller sends a migration request to the service migrator to move the

execution of the service to another service host. If no such aservice host is available

or the Web service can not move, the controller triggers an exception handling policy

(see Chapter 3), if such a policy has been specified by the service provider.

A service migrator is associated with each task appearing ina composite service

specification and is responsible for:

• Receiving service migration requests from the execution controller associated

with the same task and sending a matchmaking request to thematchmakerto

find an appropriate computing resource. The matchmaking requests include the

relevant information (e.g., service requirements) that will be used by the match-

maker for the resource selection.

• Loading the service codes (of mobile Web services) onto the computing resource

recommended by the matchmaker,

• Dispatching a mobile agent to the site of the resource for invoking the service.

Upon completion of the invocation, the results are carried back by the mobile

agent to the service migrator, which in turn, notifies the service controller about

this completion.

Similar to execution controllers, the service migrator of atask is a light weight

scheduler that helps the controller to execute the associated mobile Web service in

other computing resources whenever it is necessary.

Figure 5.1 gives an overview of the interactions among different components dur-

ing the service migration. When a monitored item is beyond thecritical point (e.g.,


Match Maker

Service

Service Container

migrate service Mobile agent

Internet server

Runtime engine

Service host

Service Migrator

Computing resource registration

Legend

2

3

4

5

6 1

7

register

Resource Repository

Tuple Space

Service Controller

Monitoring service

Computing Resources

TS

Figure 5.1: Interactions of service migration

the CPU usage of the server is higher than 90%, see step 1), the controller of a service

sends a migration request to the service migrator (step 2). The migrator interacts with

the matchmaker for the recommendation of an appropriate service host (steps 3 and 4).

If there is such a service host exists, the migrator loads theservice code to the host and

dispatches a mobile agent for the service invocation and result collection (steps 5 and

6). Otherwise, the migrator informs the controller, which then may trigger exception

handling tuples (e.g., forward the service invocation to another Web service). It should

be noted that the service container also contains components like the event manager

and the context manager (see Chapter 4). We did not include these two components in

Figure 5.1 for the sake of clarity.

The selection of computing resources is based on a data modelfor describing ser-

vices and computing resources and a matchmaking algorithm for resources selection.

We will give a detailed description of the approach in Section 5.2.

Due to the benefits of code mobility, the overall performanceof composite services


provisioning can even be further improved. For example, multiple component services

can be gathered in a single site or several sites in a same domain for the invocation to

reduce the communication cost. In Section 5.3, we propose anexecution planning ap-

proach to optimally select resources on which the executionof the component services

take place.

It should be noted that the proposed techniques also contribute to reliable service

execution because unavailable service hosts can be replaced dynamically by available

ones. In this sense, the approaches proposed in this chapteris complementary to the

ones that we have proposed in previous chapters (e.g., service communities and excep-

tion handling policies) in terms of service reliability.

5.2 Resources Matchmaking

The basic idea of resources matchmaking is not complicated:service migrators and

resource providers advertise their requirements and characteristics of the Web services

and resources; a designated matchmaking service (i.e.,matchmaker) matches the ad-

vertisements in a manner that meets the requirements and constraints specified in the

respective advertisements. In this section, we first propose a data model for the descrip-

tion and advertisement of Web services and resources. We then describe our approach

on resources matchmaking and selection.

5.2.1 Advertising Services and Resources

The providers of resources or services need to advertise thecharacteristics and re-

quirements of the resources or services. The resource (resp., service) descriptions are

defined by the providers and sent to the matchmaker (resp., service migrator) for reg-

istration.


Resource Description. Two important features of the resource data model are: (i) it

is a semi-structured data model. No specific schema is required so that the system

can work naturally in a heterogeneous environment, and (ii)the data model allows

providers to express resource constraints (e.g., the services they are willing to serve).

Table 5.1 shows the description of a workstation.

There are two main parts in the description:attributesandconstraints. The At-

tributes part includes characteristics of a resource, suchas location, CPU usage, and

free memory. Note that the values of some characteristics change over time (i.e.,dy-

namic characteristics). The amount of free memory, free storage space, and CPU

usage are samples of such characteristics. The values of dynamic characteristics can

be obtained via a daemon process running on the resource thatperiodically collects

the relevant information. Attributes may be either simple integer, real, or string con-

stants, or complicated expressions constructed with arithmetic and logical operators

and list constructors. For example,untrusted in Table 5.1 is a complicated expres-

sion that represents a list, which contains two addresses that the workstation dose not

trust. In the reality, the workstation will not accept any request fromdoc.it.ac.jp

or esc.soony.net. Particularly, we introduce the attributedomain for resources

in our data model. Resources in one domain are physically close to each other. For

example, computing resources in the building of the School of Computer Science and

Engineering at UNSW can be grouped in one domain named with the identification

of the school building,K17. By introducing the attribute ofdomain, it is possible to

execute components of a composite service— as many as possible—in the resources

of the same domain to reduce the communication cost, which therefore significantly

improves the execution performance of the composite service.

The Constraints part includes constraint expressions defined by the resource provider

for the allocation of this resource. For example, the resource will not be offered to any


Attributes:resource-identifier = “UNSW-DB001”;type = “Workstation”;description = “workstation of database group at UNSW”;provider-identifier = “UNSW007”;diskfree = 10240; //megabytesmemoryfree = 512; //megabytesCPUfree = 90%; //percentcache = 8; //megabytesOpSys = “SOLARIS251”;location = “dbg.cse.unsw.edu.au”;price = 10; //electronic coins per hourdomain = “K-17” //resource domainuntrusted = {“doc.it.ac.jp”, “esc.soony.net”}

Constraints:other.location != member(untrusted)

Table 5.1: Data model describing a workstation

process from company A (e.g., it always delays the payments). It should be noted

that multiple descriptions (services or resources) might use the same attribute name.

For example, attributelocation is used in both service and resource descriptions.

It is necessary, therefore, to distinguish which attributeis being referred in constraint

expressions. To solve this problem, we introduceattribute reference. An attribute ref-

erence in the form ofself.attributenameof a description refers to an attribute inside

the description, whileother.attributenamerefers to an attribute outside the description

(i.e., other descriptions). If neitherselfnor other is mentioned explicitly, we assume

that the attribute has aselfprefix.

From Table 5.1, we can see that the workstation has 512 megabytes free memory

and is running SUN SOLARIS 2.5. The workstation is provided byUNSW and lo-

cated atdbg.cse.unsw.edu.au. The monetary processing cost charged by this

resource is 10 electronic coins3 per hour. In reality, a resource provider can publish

3We useelectronic coininstead of US dollar as the unit of price to make our system globally appli-


multiple prices for different processing cycles (Table 5.2). Furthermore, the work-

station will not accept any request fromdoc.it.ac.jp andesc.soony.net

because they are listed inuntrusted.

peaktimeprice = 10; //9am-6pm: office hours on working daysoff peaktimeprice = 7; //6pm-9am: after office hours on working daysholidaytimeprice = 5 //during holidays and week ends

Table 5.2: Pricing example

Service Description. In a similar manner to a resource description, service data

model also has two main parts:Attributesand Requirements. The Attributes part

includes characteristics of a service, such as location, service provider, input param-

eters, and output parameters. Although one service can havemultiple operations, we

consider one operation for clarity reasons. The Requirements part includes execution

needs of the service towards the available resources. For example, a service may re-

quire at least 128K bytes of free memory to be executed.

Table 5.3 shows a description of aconsultation booking Web service. In

the example, the service charges 5 electronic coins each time for the execution. To

execute this service, a resource must have more than 200K bytes of free disk space

and at least 128K bytes of free memory. Furthermore, the service needs to be executed

under SOLARIS251 environment.

More important feature of our data model is that we introducethe properties like

avg-size-of-input, avg-size-of-output, andproxies. The commu-

nication performance is a main concern. The attributesavg-size-of-input and

avg-size-of-output can be helpful in deciding where a service should be exe-

cable.


Attributes:service-identifier = “UNSW267”;isMobile = “yes”; //whether the service can move to other placesdescription = “a consultation booking service”;provider-identifier = “UNSW”;location = “dbg.cse.unsw.com.au”;operation = “consultBooking”; //service operationinput-parameters = {String PreferredDate, String SubjectID, String StudentID,

String Professor};output-parameters = {XMLDoc consultBookingDetails};avg-size-of-input = 7; //kbytesavg-size-of-output = 20; //kbytesprice = 5; //electronic coins per invocationproxies = {“UNSW007”, “UNSW-DB001”}; //proxies of service

Requirements:other.diskfree > 200; //Kbytesother.memoryfree >= 128; //Kbytesother.OpSys = “SOLARIS251”

Table 5.3: Data model describing a service

cuted in order to achieve the best communication performance. For example, assume

that service A receives only 20K bytes as its input, but the output will be 20,000K bytes

(e.g., retrieving a video fragment based on a text query). Inaddition, the output needs

to be sent to service B. In this case, it is better to execute A atthe site of B, if A can

be transferred to other sites and the resource at the site of Bsatisfies the execution re-

quirements of A. Figure 5.2 illustrates this scenario. The values of these attributes can

be derived from the execution history. Each service stores ahistory of service execu-

tion in a local log, along with the associated values of the relevant attributes (e.g., size

of input/output parameters).

The attributeproxies is used to avoid service code transmission by keeping

copies of the service in the sites of somecompanionresources. Consequently, the

transmission time is avoided because the service provider does not need to send the

copy of the service if it is executed using one of these companion resources. The


20Mbyte Video

Execution controller

Tuple space

Data flow

Service migration

Service host

Legend

Service A Service B

A

TS

TS

TS

TS

Figure 5.2: Very large data flow between two Web services

companion resources can be manually defined by service provider (e.g., he may prefer

to use the resourceUNSW007), or derived from the execution history of the service

(e.g., service provider may choose those resources that have been used frequently as

companion resources of the service).

Discussion. The data model proposed for the description of services and resources

is highly flexible and extensive. Our data model possesses several beneficial features.

Firstly, the semi-structured data model dose not need a specific schema, which enables

the representation of many different kinds of services and resources without compli-

cating the matchmaker that has to evaluate only several well-known attributes to de-

termine compatibility. Secondly, we integrate queries (i.e., resource constraints and

service requirements)—that facilitate the resource matchmaking (introduced in Sec-

tion 5.2.2)—into the data model. Thus, our data model unifiesschema, data and query

into a single specification. Thirdly, our data model considers the specific features

of computing resources (e.g., dynamic attributes) and Web services (e.g., input/output


size), which makes the model expressive enough for describing resources and services.

Finally, the data model allows resource providers to express their serving willingness

(e.g., excluding a particular service or user to use the resource).

It is worth mentioning that the advertisements must be constructed to comply with

anadvertising protocolagreed by the matchmaker and the service migrator. The ad-

vertising protocol defines basic conventions regarding what the matchmaker expects to

find in an advertisement if it is to be included in the matchingprocess. For example,

during the procedure of matching resources to a service thatrequires at least 128K

bytes memory, the matchmaker knows to find attributememoryfree in the adver-

tisements of the resources. We will describe in detail our matchmaking algorithm in

the next.

5.2.2 Matchmaking Process

Matchmaking is defined as a process that requires a service description as input and

returns a set ofmatchedcomputing resources. A computing resource is matched with

a service if both the requirement expressions of the serviceand the constraints of the

resource are evaluated to true.

Matchmaking Interactions. Figure 5.3 shows the interactions in a matchmaking

process. Service migrators and resource providers construct descriptions describing

their requirements and attributes and send them to the matchmaker (step 1). These

descriptions must be created to conform to the advertising protocol specified by the

matchmaker. In other words, a meaning must be attached to some particular attributes.

For example, the advertising protocol may specify that the attribute memoryfree

indicates the amount of free memory of the computing resources.

The matchmaker then invokes amatchmaking algorithmby which matches are


Matchmaker

Match algorithm (2)

Resource Repository

Service

Advertisement (1) Advertisement (1)

Match notification (3)

Match notification (3)

Claiming (4) Resource

Figure 5.3: Interactions in the matchmaking process

identified (step 2). The invocation includes finding service-resource description pairs

that satisfy the constraints and requirements of resourcesand services. We will detail

this step later. After the matching step, the matchmaker notifies the service migrator

and the resource providers (step 3). The service migrator and the resource provider(s)

then contact each other and establish a working relationship (step 4). It should be noted

that a matched resource of a service does not mean that the resource is allocated to the

service. Rather, the matching is a mutual introduction between services and resources

and the real working relationship can be consequently builtafter the communication

between two parts.

The separation of matching and claiming has some significantadvantages. The

most important benefit from the separation is the tolerationto the changes of resources

and services. As we always mentioned before, the state of Webservices and resources

may be continuously changing in dynamic environments. There is a possibility that

the matches made by the matchmaker are based on the stale advertised information.

Claiming allows the provider of services and resources toverify their requirements and

constraints in terms of their current states. A more secure system is another benefit


Attributes: resource-identifier = “UNSW-DB001”; type = “workstation”; description = “workstation of DB group”; provider-indentifier = “UNSW007”; diskfree = 10240000; //kbyte memoryfree = 512000; //kbyte CPUfree = 90%; cache = 8; //megabyte OpSys = “SOLARIS251”; location = “dbg.cse.unsw.edu.au”; price = 3; domain = “K17”; untrusted = {“doc.it.ac.jp”, “esc.soony.net”} Constraints: other.location != member(untrusted)

Resource

Attributes: service-identifier = “UNSW267”; isMobile = “yes” description = “a consultation booking service”; location = “dbg.cse.unsw.edu.au”; provider-indentifier = “UNSW”; input-parameters = {String PreferredDate, …}; output-parameters = {XMLDocument consultBookingDetails}; avg-size-of-input = 7; //kbytes avg-size-of-output = 20; //kbyte proxies = {“UNSW-DB001”, “UNSW007”}; price = 10; Requirements: other.diskfree > 200; //kbytes other.memoryfree >= 128; //kbytes other.OpSys = “SOLARIS251”

Service

Figure 5.4: A matchmaking example

from the separation in the sense that in the claiming phase, the providers of resources

and services could verify their identities using cryptographic techniques before build-

ing the working relationship.

Expression Evaluation. Expression evaluation plays an important role in the match-

making process. To evaluate a requirement expression in a service description, the at-

tribute of the expression is replaced with the value of the corresponding attribute of the

resource. If the corresponding attribute does not exist in the resource description, the

attribute of the expression is replaced with the constantundefined. In our match-

making algorithm, expressions containingundefined are eventually evaluated as

false. The constraints of the resource descriptions have the similar evaluation process.

Figure 5.4 shows the matchmaking process of the example computing resource and

the consultation booking service (see Table 5.1 and Table 5.3). The consultation book-

ing service needs at least 128K bytes free memory to run the service. The matchmaker


scans the description of the computing resource (left side of the figure) for the attribute

memoryfree4. The value of the attribute (i.e., 512000K bytes) is used to replace the

attribute in the expression (i.e., 512000>= 128), which is in turn evaluated totrue

by the matchmaker. Upon the completion of the matchmaking, we can see that the

computing resource and the consultation booking service are matched each other.

When receiving a request from a service migrator, the matchmaker takes the ser-

vice description, evaluates all the resources advertised in the matchmaker using the

matchmaking algorithm described above, and returns a set ofmatched resources to the

service migrator. To express it more precisely, we present apiece of pseudo code in

Table 5.4.

5.2.3 Resources Selection

For a specific service, there are always multiple computing resources matched for exe-

cuting the service. The service provider, therefore, should choose the best resource (or

top N best resources) that satisfies her particular needs among the matched resources.

We exploit a similar selection approach as proposed for service communities in

Chapter 3 (see Section 3.3). In particular, each component service is associated with a

scoring functionthat interprets aselection policywhich specifies preferences over re-

sources of a component service. It is amulti-criteria utility function(see equation 3.1).

The scoring service computes the weighted sum of criteria scores using the weight

property of each selection criterion. It selects the resource of a component service that

produces the higher overall score according to the multi-criteria utility function.

Several criteria—such asprice, availability, reliability, and reputation—can be

used in the function. Since these criteria have the similar meaning and calculating

4As we stated before, the matchmaker maintains an advertising protocol that specifies which attributeshould be look at.


doMatchMaking(serviceDescription){SET matchedResources to emptyFOR every advertised resource in RepositoryDO {

matchRequirements=matchRequirements(serviceRequirements,resourceDescription)

matchConstraints=matchConstraints(resourceConstraints, serviceDescription)IF (matchRequirements andmatchConstraints)

addResource(matchedResources, resourceDescription)}

RETURN matchedResources}

matchRequirements(SR,RD){SET matchRequirements to falseFOR every requirement expression inSR DO {

IF evaluation(requirement)SET matchRequirements to true

ELSESET matchReuirements to falseBREAK

}

RETURN matchRequirements}

matchConstraints(RC, SD){SET matchConstraints to falseFOR every constraint expression inRC DO {

IF evaluation(constraint)SET matchConstraints to true

ELSESET matchConstraints to falseBREAK

}

RETURN matchConstraints}

Table 5.4: Pseudocode for resource matchmaking

functions, we will not repeat the details here. To learn moreinformation about the

multi-criteria selection approach, readers are referred to Section 3.3.


Another important criterion proposed in our approach islocation of computing re-

sources. The location criterion aims at gathering the maximum number of components

of a composite service to be executed in the same site (i.e., using the same computing

resource). As a consequence, remote interactions and communications between com-

ponent services can be avoided. The selection of resource for a component depends

on the location (i.e., computing resource) of its predecessor. We will show how the

location criterion is used in the composite service execution planning in Section 5.3.

By using multi-criteria selection function, the best computing resource can be se-

lected from the matched resources, which will be contacted by the service migrator

for the consequent operations (e.g., migrate service code and invoke the service at the

resource).

A service migrator may select a number of matched resources (e.g., top N best

resources) to form apool of service hostsfor the service. If the server where the

service is currently running is heavily loaded, the migrator generates a new instance of

the service (i.e., migrate a copy of the service and invoke it) on a service host with low

workload in the pool.

Multiple service hosts of a service can significantly increase the service availability.

Suppose that the mean time between failures (MTBF) and the mean time to repair

(MTTR) of a single host areMT BF andMT T R respectively, according to [141],

the availability of the host of one single host can be calculated using the following

formula:

A =MT BF

MT BF +MT T R(5.1)

The availability of the service withn service hosts depends on the availability of the

pool of service hosts, which can be calculated as follows:


AS =n

∑

i=1

Ai(1−A)n−i = 1− (1−A)n (5.2)

To show the benefit that multiple service hosts bring to the availability of services,

we assume a number of very unreliable service hosts withbf = 24h andtr = 6h5, the

availability of a pool with 8 such service hosts is 99.9997%,which means, the service

will only be unavailable for about 1.3 minutes a year.

5.3 Composite Service Execution Planning

So far, we only consider the resource selection for a component service where the se-

lection is determined independently to other tasks of composite services. Although

this approach is sound enough to improve the availability ofan individual service exe-

cution (e.g., move the service to a new resource for the invocation in case of overload

of the service server), theoverall performanceof the composite service may not be

optimized. For example, component services in a composite service may choose re-

sources in various domains. From a particular component service point of view, the

performance is the best. Whereas from the composite service point of view, the perfor-

mance might not be the best because these component servicescan be put in resources

of the same domain where the communication cost can be dramatically reduced. In this

section, we first introduce the concept ofexecution planand then present an approach

for selecting an optimal execution plan for a composite service.

5The availability of the hosts is 80%, which means that the hosts are not available for 4.8 hourseveryday.


5.3.1 Execution Plan: An Overview

As stated before, the components of a composite service can be executed using several

resources. Therefore, there can be multipleexecution plansfor a composite service.

By execution plan, we mean those resources which can be used toexecute a composite

service.

Assume a composite serviceCS hasm component services,CSc = {s1, s2, · · · , sm},

an execution planp of CS is defined as follows:

Definition 6 (Execution plan). p = {< s1, r1 >,< s2, r2 >, · · · , < sm, rm >} is an

execution plan of composite serviceS if:

•⋃m

i=1 si = CSc, and

• for each 2-tuple< si, ri > (i ∈ [1,m]) in p, the servicesi is executed in resource

ri. �

In fact, an execution plan indicates which resource is used for each component of

a composite service. Note that the number of resources is notnecessarily equal to

the number of component services because some component services could share one

resource in order to reduce the communication costs.

5.3.2 A Multi-Phase Execution Planning

Building an optimal execution plan consists of several phases. In the following, we

will describe and illustrate the steps using our class assistant service as an example.

Phase 1: Matching resources.The purpose of this phase is to search for the resources

on which the component services could be executed. It shouldbe noted that only

those component services that are movable (i.e., their codes can be transferred to other


computing resources) involve in this stage. For simplicityreasons, we only consider

these mobile Web services6.

The matchmaker evaluates the requirement and constraint expressions of the ser-

vices and resources. If all the requirements of a component servicesi are evaluated

to true using the attributes of a resourceri, and all the constraint expressions of the

resourceri are evaluated totrue using the attributes of the servicesi, we sayri is a

matched resourceof si. A reference to a non-existent attribute evaluates to the con-

stantundefined which is treated asfalse. Since there could be multiple matched

resources of a specific service, for each component servicesi of a composite service

CS, the results of the matching phase ofCS are:

Ri = {ri1, ri2, · · · , rik} (5.3)

M = {< s1,R1 >,< s2,R2 >, · · · , < sm,Rm >} (5.4)

whereRi is the set of matched resources of servicesi ∈ CSc. M is the matching

results ofCS.

For example, the matching results of class assistant (see Figure 3.2) are given in

Figure 5.5 (a). From the table we can see that resourcesr1, r2 andr3 can be used

to execute serviceattendance reminder. The resourcer1 can also be used to

execute serviceAG, QB, QP, andLF. The descriptions of resourcesr1, r2, r3, r4, r6, r7,

r9, r10, r11, andr12 are not given here for reasons of brevity. Figure 5.5 (b) gives the

domain information of these matched resources. For instance, resourcesr1, r2, r3, and

r4 belong to a domain namedK-17.

6The component services that can not move (i.e., stationary services) have only one “matched”resource (i.e., their own service servers).


Task Matched resourcesAR {r1, r2, r3}AG {r1, r4}LO {r4, r5, r6}QB {r1, r7, r8}QV {r4, r8, r9}QP {r1, r9}CB {r3, r7, r10, r11}LF {r1, r10, r8, r12}

(a)

K-17 r1 r2

r3 r4

J-10 r5 r6

r7 r8

C-8 r9 r10

r11 r12

(b)

Figure 5.5: (a) Matched resources of the digital class assistant service; (b) domains ofthe matched resources

Phase 2: Pruning phase.For services which are in different concurrent areas of an

AND state in the statecharts ofCS, if a resourcer is shared by several component

services, each component service belongs to different concurrent areas of the AND

state, arematch proceduremust be performed to ensure that these component services

can be executed inr concurrently.

For example, in Figure 3.2,AG andLO require at least 150K bytes and 120K bytes

of free memory to carry out their executions, respectively.Suppose that resourcer4

has 260K bytes of free memory. Intuitively,r4 meets the requirements of bothAG

andLO separately. However,r4 does not meet the requirements whenAG andLO are

executed at the same time because they need 270K bytes of freememory totally. As a

result, the resourcer4 is removed from the sets of the matched resource ofAG andLO.

Phase 3: Generating execution plan.Since each component servicesi (si ∈ CSc)

has a set of matched resources (Ri), the association of a component service with a

specific resource has to be completed in order to build an execution plan for composite

serviceCS.

Step 1: Initially, the work starts with the first component service si (i = 1) of the


composite serviceCS. In this step, a best resource will be selected fromRi

using the cost model we developed in (3.1). For the illustration purpose, we

consider two criteria:price andreliability. Therefore, the score of

a resourcer (r ∈ Ri) is computed using the following formula:

U(r) = wpri · Scorepri(r) + wrel · Scorerel(r) (5.5)

Herewpri andwrel are weights forprice andreliability, respec-

tively. The scoring functions (i.e.,Scorepri(r) andScorerel(r)) are pro-

vided by composite service provider. However, end users cancustomize

the weights for the selection criteria in order to find a desired resource for

the component service. For example, if the price is the most important fac-

tor to a customer, she can setwpri to 1 andwrel to 0. For each resource,

a score is computed using above utility function and the resource with the

maximal value ofU(r) is selected. If there is more than one resource which

have the same maximal value ofU(r), then a resource will be chosen ran-

domly from them. Suppose that resourceri is finally selected to execute

servicesi, the plan for executing servicesi is represented as< si, ri >.

Step 2: After the preparation of the first component servicesi (i = 1) is finished,

the resources should be selected for the remaining component services

si (i = 2 . . . m). The location criterion is considered at this stage. Note

that the location criterion is privileged to other two criteria because of the

reasons previously discussed (see Section 5.2.3). Obviously, the resource

that is going to be assigned to a component servicesi (i = 2 . . . m) depends

on the location of the resource that is assigned to its predecessorsi−1. Ta-

ble 5.5 illustrates the algorithm that is adopted for resource selection (we

assume that< si−1, ri−1 > is already established). In particular, if the re-


sourcesRi of servicesi contains the resource selected forsi−1 (i.e., ri−1),

the resource should also be selected forsi (lines 3-6 of Table 5.5). Other-

wise, a number of resourcesRdomain that have the same domain asri−1 are

selected fromRi (lines 7-14). A best resource is selected from theRdomain

by using the utility function in Step 1 (lines 15-24). If there is no resource

having the same domain withri−1, a resource will be selected using the

utility function by going to Step 1 (lines 25-27).

For example, suppose thatr9 is selected forQP, a resource will be selected

from r10 andr11 for CB becauser9, r10, andr11 has the same domain (see

Figure 5.5 (b)).

Finally, the execution planp is built. We say that the built execution plan is an

optimizedexecution plan of composite serviceCS.

After the optimized execution plan ofCS is built, when the composite serviceCS

is invoked, the migrator of its component services are in charge of migrating and in-

voking the services in the assigned computing resources. Itshould be noted that the

orchestration of the composite service (i.e., control flow routing policies) that we in-

troduced in Chapter 4 remains unchanged. In other words, our proposed execution

planning approach provides additional execution control information (i.e., on which

resources the component services should be executed) for achieving the high availabil-

ity and better performance of composite services.

5.3.3 Interleaving Service Execution and Planning

From previous description, it is shown that the service planning and execution is a

sequential process: composite services are executedafter the execution plans are made

and deployed. It is easy to see that this approach still is notperfect due to the temporal


Algorithm

1: ∀ i, i = 2, . . . ,m2: for each< si,Ri >3: if (ri−1 ∈ Ri)4: then begin5: establish< si, ri−1 > //ri−1 is selected to executesi

6: end7: else begin8: setRdomain to empty //the resources with the same domain asri−1

9: for eachrj ∈ Ri

10: if domain(rj) = domain(ri−1)11: then begin12: addResource(Rdomain, rj)13: end14: end for15: if size(Rdomain) = 116: then begin17: establish< si,Rdomain[0] > //the only resource is selected to

executesi

18: end19: else begin20: if size(Rdomain) > 121: then begin22: Ri =Rdomain

23: go to Step 1 //use utility function to select a resource for si

24: end25: else begin26: go to Step 1 //use utility function to select a resource for si

27: end28: end29: end

Table 5.5: Algorithm for composite service resource selection

interval between services planning and execution. For instance, a computing resource

r has been selected at timet1 (service planning) to execute services because its free

disk capacity meets the execution requirements ofs. However, the free disk capacity


(s1, r1)

Legend

Finished task Being-executed task Being-planned task

(s2, r2)

(s3, r?)

(s5, r?)

(s4, r?)

Unplanned task

P

P

E

E P

F

F

U

U

Figure 5.6: Interleaving service planning and execution

of r may decrease at timet2 (service execution) and might not meet the requirement

of s any more whens needs to be executed onr. Intuitively, the interval of service

planning and execution should beminimizedin order to ensure the availability of the

appropriate computing resources.

Our solution to the challenge is an approach that interleaves the service planning

and execution. The approach takes advantage of the researchdone in distributed ar-

tificial intelligence (DAI) [26] in general and the planningfield [133] in particular.

The basic idea of our approach is todecomposethe planning process into several steps

where each step takes care of a portion (one or several tasks of a composite service)

of the plan. In addition, the planning and the execution of composite services are con-

ducted in parallel in the sense that the resource ofsi+1 is being prepared whilesi is

being executed. The service planning is always one-step ahead of the service execu-

tion. It should be noted that we facilitate the service planning successively (i.e., one

service after another), according to the sequence encoded in the statecharts of the com-

posite service. The only exception is the services contained in AND states. Services

in different concurrent areas of an AND state are planned in parallel.


Figure 5.6 illustrates the idea of interleaving service planning and execution using

a simple composite service:

Step 1: First of all, the execution planner starts the preparation of s1. The pro-

cess involves the resources matchmaking and the resource selection. It is

a process that combines phase 1 and step 1 of phase 3 of the approach we

presented in Section 5.3.2, except that we only consider a single service

(i.e., s1). The information of the selected resource is sent to the service

migrator ofs1.

Step 2: The service migrator ofs1 informs the corresponding controller that starts

the invocation ofs1. At the same time, the execution planner prepares

the resources for the service(s) that is executed afters1. This process is

a combination of phase 1 (resource matchmaking) and step 2 ofphase 3

(resource selection) of the approach we presented in Section 5.3.2, except

that we only consider the service(s) that is executed afters1. If the tasks

are in an AND state, phase 2 in the approach we presented in Section 5.3.2

needs also to be involved for pruning purpose. For example, in Figure 5.6,

phase 2 should be applied to taskss3 ands4 because they are in the different

concurrent regions of an AND state.

Step 3: The service planner notifies the service migrator(s)of the selected resource(s),

which in turn, informs the corresponding controller(s). The controller(s)

invokes the associated service(s) when their preconditions are satisfied.

Meanwhile, the service planner begins to prepare the resource(s) for the

services that are executed after the planned service(s).

Step 4: The service planning and execution are carried out concurrently in this way

until the last task is planned and executed.


To handle unexpected adverse conditions (e.g., failure of the selected resource),

the service planner stores the information of a pool of resources of servicesi—for

example, theN best ranked resources ofsi—for a later use. If the service migrator

of si faces any difficulty in the execution ofsi at the selected resourceri, it immedi-

ately contacts the service planner. Since the service planner is now working on the

preparation of the remaining component services, it will i)stop its preparation work

and browse the stored pool of resources, ii) select one resource, iii) inform the service

migrator about this resource, and finally iv) update the poolof resources (by removing

the selected resource). Resources in the pool are not deleteduntil the service planner

receives a notification message from the migrator that the execution of servicesi has

been successfully completed.

5.4 Related Work

In this section, we examine some related work on Web service provisioning approaches,

matchmaking architectures, and load balancing techniques.

5.4.1 Web Service Provisioning Approaches

WebL [102] is a programming language for Web document processing based on the

concept of service combinator proposed in [36]. Service combinators are used to make

access to services more reliable and to simplify the handling of failures. Web++ [173]

is a system for fast and reliable Web usage. Web++ achieves high availability by

dynamically replicating Web data among multiple Web servers. Both of the work,

unfortunately, focus not on Web services, but on common Web resources like Web

pages.

The eFlow system [40] provides dynamic service selection technique that is sim-


ilar to our service communities. With dynamic service selection, a composite service

searches for component services based on available metadata, its own internal state,

and a rating function. In contrast to these works, our work allows highly available

Web services by dynamically move the execution of services to other service hosts.

The work presented in [100] is the most similar one to our work. In [100], au-

thors propose a dispatcher service that is capable of automatic service replication. The

dispatchers are similar to service migrators in our work. However, the strategies on

service hosts selection have not been discussed in [100]. Instead, a dispatcher is re-

sponsible for a set of service hosts that are known a priori. In addition, their approach

only considers individual services, not composite services. Comparing to their work,

we not only present a data model for resources matchmaking where appropriate ser-

vice hosts are selected dynamically, but also present a multi-phase execution planning

mechanism for the high availability and best overall performance of composite Web

services.

In [43], authors have introduced a reactive service composition architecture for

pervasive computing environments. The architecture consists of five layers: network,

service discovery, service composition, service execution, and application. While re-

viewing the work of [43], we were interested in the service execution layer. During

the execution of services, this layer might want to optimizethe bandwidth required to

transfer data over the wireless links between services and hence, execute the services

in an order that minimizes the bandwidth utilization. This optimization approach is

similar to the location criterion that we have introduced inthe service execution plan-

ning algorithm. With that criterion, the cross-network traffic between the resources

can be reduced; this avoids extra data transfer between distant resources.

Finally, the Web Service Reliability (WS-Reliability) specification [159] is an in-

dustry effort started in January 2003, by a group of leading IT vendors, consisting of


Fujitsu, Hitachi, NEC, Oracle, Sonic Software and Sun Microsystems. WS-Reliability

is a specification for open, reliable Web services messagingincluding guaranteed de-

livery, duplicate message elimination and message ordering. The reliability features

are based on extensions to the Simple Object Access Protocol(SOAP). However, al-

though the specification was named as “Web service reliability”, it deals less with the

overall reliability of Web services than with “Web servicesreliable message delivery”.

Even with respect to messaging, the specification still remains incomplete. For exam-

ple, it describes reliable asynchronous delivery but does not address many other issues

such as publish-and-subscribe.

5.4.2 Matchmaking Approaches and Load Balancing Architectures

InfoSleuth [130, 131] is an agent-based information discovery and retrieval system

that adoptsbroker agentsto perform the syntactic and semantic matchmaking. The

broker agent matches agents that require services with the agents that can provide such

services. In InfoSleuth, the service capabilities is written in LDL++ [47], a logical

deduction language.

RETSINA [164] is a multiagent system for dynamic service matchmaking on the

Web. The authors distinguished three kinds of agents in Cyberspace:service provider,

service requester, andmiddle agent. An appropriate service provider is matched to

a requester through the middle agent. A language is designedfor the description of

agents capabilities.

In contrast, our matchmaking between services and resources is based on a flexible,

semi-structured data model where providers of services andresources can express their

constraints and requirements. In addition, we propose a multi-criteria utility function

for selecting optimal resources for particular services.

A lot of efforts have been done in the area of load balancing [37, 77, 119]. Grid


computing [77] focuses on distributed computing in wide area networks involving

large amounts of data and/or computing power using computers managed by multi-

ple organizations. Our service migrators focus on executing services at spare service

hosts. In addition, mobile agents are used for the service invocation. In contrast to dis-

patchers for Web servers in [37], service migrators can not assume that all requests to

services produce the same amount of load because computational demands of different

services might be very different.

Within the context ofΨ [119], the authors suggest the creation of an ad-hoc dis-

tributed platform to transparently offload portions of a service from a resource con-

strained device to a nearby server. In fact, if a device becomes resource constrained

at run time and believes it can beneficially use nearby resources, it automatically and

transparently offloads part of the service to them. The suggested platform can dynam-

ically decide how much of the surrounding resources to use. The platform philosophy

presents similarities with the service composition approach. In this approach all the

services are offloaded from their original sites to the computing resource sites that have

the capacity to handle their execution. We offload the whole services and not portions

of them based on the commitments that resource sites will provide. Commitments are

an important element of the approach operation.

5.5 Summary

In this chapter, we have presented novel techniques for flexible and reliable Web ser-

vices execution in dynamic environments. The main featuresof the approach are:

• The concept of service migrator that addresses load balancing and high avail-

ability issues of service provisioning.

• A flexible, semi-structured data model for the description of services and re-


sources.

• A matchmaker that dynamically matches resources for services, as well as a cost

model for resources selection, and

• A multi-phase service execution planning approach for the high availability and

the optimized overall performance of composite services.

We have implemented the proposed techniques in our prototype. The details on the

implementation can be found in Chapter 6.

Chapter 6

Implementation and Performance

Study

This chapter is devoted to the implementation and performance study of our proposed

service composition approach [151, 154, 19]. We implemented these techniques in-

side theSelf-Servprototype. The Self-Serv system aims at providing a comprehensive

platform for Web services creation, composition, and invocation in distributed and dy-

namic environments [17]. To validate the feasibility and benefits of our approach, we

developed several composite services using the prototype system. We then conducted

an extensive performance study of our composition approach.

This chapter is organized as follows. In Section 6.1, we givea brief overview of the

Self-Serv prototype. In Section 6.2 and Section 6.3, we describe some implementation

details of Self-Serv. Then, in Section 6.4, we present a scenario that illustrates the main

features of the Self-Serv system. In Section 6.5, we report the results of a usability

study and a set of performance studies of Self-Serv. Finally, in Section 6.6 we provide

a summary of the chapter.

Chapter 6. Implementation and Performance Study 150

6.1 Self-Serv Prototype: An Overview

The Self-Serv system aims at providing an integrated, uniform, and flexible platform

for discovering, composing, deploying, and accessing Web services in dynamic and

distributed environments. It has been completely implemented in Java and based on

standards like XML, SOAP, WSDL, and UDDI. Java2WSDL—a tool provided by

Apache Axis[8]—is used to generate WSDL (Web Services Description Language)

descriptions from the Java class files so that all the components of Self-Serv are in-

voked as Web services. This allows uniformity in the specification and development

tools, in line with the principle of service oriented architecture (SOA) [134].

We present the system architecture of Self-Serv in Figure 6.1. The architecture

consists of a service composition environment (also calledtheservice manager) and a

service runtime execution environment (also called theservice container). The former

is used for defining and deploying services including atomicservices, composite ser-

vices, and service communities, while the latter acts as a middleware for orchestrating

composite services and performing dynamic service and resource selection.

The services registered in Self-Serv form the so-calledpool of services, and they

can be composed with others to form new services (see Figure 6.1), which are them-

selves registered and added to the pool. Services are all provided with a SOAP-based

programmatic interface. Atomic services typically wrapproprietaryapplications like

application programs, workflows, databases, etc. Servicesare provided by service

providers. Similarly, the resources are provided by resource providers and are reg-

istered in Self-Serv. Both services and resources are published and discovered in a

UDDI registry.

We use state-of-the-art technologies for the implementation of Self-Serv. Table 6.1

gives a summary of these technologies. Self-Serv services are deployed using Apache


Database Application Web-accessible program

Self-Serv Service Manager

Service/Resource Discovery Engine

Service Builder

Workflow

Service Deployer

Service Planner

UDDI Registry

Internet

Communities C1 C2 C3

CS1 CS2

AS1 AS2 AS3 AS4

Composite Services

Atomic Services

Service/resource advertisement

Service/resource discovery

is register with

is composed of

Resource provider

requests/results

Self-Serv interface

Service provider

service container

Legend

tuple space

Context manager

Event manager Execution controller

Service migrator

TS

TS TS TS TS

TS

TS TS TS

TS

Pool of services

End user

Figure 6.1: Architecture of Self-Serv system

Axis. In our implementation, we useApache Tomcat[9] as a Web server where Apache

Axis is deployed. Apache Axis provides not only a server-side infrastructure for de-

ploying and managing services (with the better performancethan its former version

Apache SOAP), but also a client-side API for invoking these services. Each service

has adeployment descriptorthat includes the unique identifier of the Java class to be

invoked, session scope of the class, and operations in the class available for the clients.

Each service is deployed using the service management client by providing its descrip-


Product Version Usage DescriptionsApache Axis 1.2 SOAP engine, also used to convert applications to WSDL

descriptions.IBM WSTK 2.4 UDDI registry, UDDI API for publishing and inquiring

about Web services.Jakarta Tomcat 5.5 Web server.Context Toolkit N/A Used to implement contexts.IBM TSpaces 2.1.2 Used to implement tuple spaces.HP Jena Toolkit 1.6.1 Used to implement resources.Java JDK 1.4 Used to implement travel planning, class assistant legacy

applications.Oracle 8.1.7 Application databases.JDBC 2.0 Database connections.IBM Aglets 2.0 Used to implement mobile agents.kXML 2.0 XML parser for services running on mobile devices.kSOAP 2.0 SOAP parser for services running on mobile devices.WebSphere StudioDevice Developer

5.7.1 Used to develop and test J2ME applications.

Table 6.1: Enabling technologies in Self-Serv

tor and the URL of the Axis servlet rpcrouter. We adopt IBM Web Services Toolkit

2.4 (WSTK) [92] to access a private UDDI registry.

Resources are expressed in Resource Description Framework (RDF) [29] speci-

fications. We use HP Jena toolkit [96] for manipulating RDF documents. Context

Toolkit [145], IBM TSpaces [69], and IBM Aglets [3] are used to implement contexts,

tuple spaces, and mobile agents, respectively.

Finally, to support mobile users (i.e., end users who accessSelf-Serv using mo-

bile devices), Self-Serv provides a specific application that can be downloaded and

installed on mobile devices, supplying the user with an interface for the access of

Self-Serv environment. We adopt IBM WebSphere Studio DeviceDeveloper [91] for

the application development. We use kXML [104] and kSOAP [103] to parse XML

documents and SOAP messages on mobile devices. To show how these technologies

are used in our implementation of Self-Serv, we will describe in the sequel the design

and implementation of the service composition and runtime execution environments


in Section 6.2 and Section 6.3, respectively.

As a proof of concept, we developed several applications using Self-Serv, including

a travel planning service[151] and aclass assistant service[152]. These services are

complex and integrate multiple services for fulfilling particular goals (e.g., planning a

trip). We also conducted an extensive experimental performance study of Self-Serv,

which will be reported in Section 6.5.

6.2 Service Composition Environment

The service composition environment consists of a set of integrated tools that allows

service developers and users to create and execute services. It is composed of the

following component tools: service/resource discovery engine, service builder, service

deployer, and service planner.

6.2.1 Service/Resource Discovery Engine

The service/resource discovery engine facilitates the advertisement and location of

services and resources. It is implemented using SOAP, WSDL, and UDDI [10]. We

adopt the Resource Description Framework (RDF) [29] to describe the resources be-

cause RDF is a standard language recommended by the World WideWeb Consortium

(W3C) [175] for machine understandable descriptions of resources on the Web. We de-

fine a RDF schema for the resource description data model proposed in Section 5.2.1.

Table 6.2 shows the excerpt of the schema. Each resource is represented as a RDF

document. Table 6.3 is a RDF description of the example illustrated in Table 5.1. For

each resource, a tModel1 of typeresourceSpec is created. The tModel includes

1In UDDI, a tModel provides a semantic classification of the functionality of a service or a resource,together with a formal description of its interfaces.


<rdf:RDF xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”><rdf:Description ID=“Attributes”>

<rdf:type rdf:resource=“http://www.w3.org/1999/02/22-rdf-syntax-ns#Property”/></rdf:Description><rdf:Description ID=“Constraints”>

<rdf:type rdf:resource=“http://www.w3.org/1999/02/22-rdf-syntax-ns#Property”/></rdf:Description><rdf:Description ID=“Resource-Identifier”>

<rdf:type rdf:resource=“http://www.w3.org/1999/02/22-rdf-syntax-ns#Property”/><rdfs:subPropertyOf rdf:resource=“#Attributes”/>

</rdf:Description><rdf:Description ID=“Type”>

<rdf:type rdf:resource=“http://www.w3.org/1999/02/22-rdf-syntax-ns#Property”/><rdfs:subPropertyOf rdf:resource=“#Attributes”/>

</rdf:Description>. . .

Table 6.2: Example of RDF schema

a tModel key, a name (i.e., resource name), an optional description, and a URL that

points to the location of the resource description document.

The Web Services Description Language (WSDL) is used to specify Web services.

Since WSDL focuses on how to invoke a Web service, some of the attributes in our pro-

posed service description data model are not supported by WSDL (e.g., service price

and proxies). Such attributes are also specified as tModels.Each tModel represents

the specification of one attribute. Table 6.4 shows the example of servicePrice

tModel. The specification of the service price is described in an XML document

http://localhost:80/servicePrice.xml. The keys of these tModels are

included into thecategoryBag of the tModel of a Web service so that the Web

service knows the descriptions of these attributes.

Service registration, discovery and invocation are implemented by SOAP calls.

When a service registers with a discovery engine, a UDDI SOAP request containing the

service description in WSDL is sent to the UDDI registry. After a service is registered

http://www.w3.org/1999/02/22-rdf-syntax-ns#%E2%80%9D

http://www.w3.org/1999/02/22-rdf-syntax-ns#Property%E2%80%9D%00




http://localhost:80/servicePrice.xml










<?xml version=“1.0”><rdf:RDF

rdf:RDF xmlns:rdf=‘http://www.w3.org/1999/02/22-rdf-syntax-ns#’r=‘http://www.cse.unsw.edu.au/ selfserv/resources/resources.xsd#’><rdf:Description rdf:about=“an example of workstation”>

<r:Attributes rdf:parseType=“Resource”><r:Resource-Identifier>UNSW-DB001</r:Resource-Identifier><r:Type>Workstation</r:Type><r:Description>workstation of database group at UNSW</r:Description><r:Provider-Identifier>UNSW007</r:Provider-Identifier><r:Diskfree>10240</r:Diskfree><r:Memoryfree>512</r:Memoryfree><r:CPUfree>90%</r:CPUfree><r:Cache>8</r:Cache><r:OpSys>SOLARIS251</r:OpSys><r:Location>dbg.cse.unsw.edu.au</r:Location><r:Price>10</r:Price><r:Domain>K17</r:Domain><r:Untrusted>

<rdf:Bag><rdf:li>doc.it.ac.jp</rdf:li><rdf:li>esc.soon.net</rdf:li>

</rdf:Bag></r:Untrusted>

</r:Attributes><r:Constraints rdf:parseType=“Resource”>

<r:Other.Location>!member(untrusted)</r:Other.Location></r:Constraints>

</rdf:Description></rdf:RDF>

Table 6.3: Example of RDF description

in the UDDI registry, it can be located by sending the UDDI SOAP request (e.g.,

business name, service type) to the UDDI registry.

The discovery engine is implemented using the IBM Web Services Toolkit 2.4

(WSTK). WSTK provides several components and tools for Web service development

(e.g., UDDI, WSDL, SOAP). In particular, we use the UDDI Java API (UDDI4J)

to access a private UDDI registry (i.e, hosted by the Self-Serv platform), as well as

the WSDL generation tool for creating the WSDL documents and SOAP service de-

http://www.w3.org/1999/02/22-rdf-syntax-ns#%E2%80%99

http://www.cse.unsw.edu.au


<tModel tModelKey=“uuid:9856f21e-badd-492b-21rt408f6645”><name>servicePrice</name><description lang=“en”>Specification of service price</description><overviewDoc>

<description lang=“en”>service price</description><overiewURL>http://localhost:80/servicePrice.xml</overviewURL>

</overviewDoc></tModel>

Table 6.4: serviceType tModel

scriptors required by the discovery engine. Details about the implementation of the

discovery engine are presented in [154].

6.2.2 Service Builder and Service Planner

The service builder assists service developers in the creation and maintenance of atomic

services, service communities, and composite services. Itprovides an editor for de-

scribing the statechart diagram of a composite service operation, for creating and con-

figuring service communities and atomic services, and for importing operations from

existing Self-Serv services into composite services and communities. A search and

browse facility is offered to locate component services using the service discovery en-

gine and import their operations into states. The WSDL descriptions of services are

automatically generated and then published to the UDDI registry.

It should be noted that the service builder also supports thespecification of process

schemas. We designed an XML schema for process description.Each process is rep-

resented in an XML document and has a business entry in the UDDI registry, with a

tModel of typeprocessSpec. Service developers can design their new composite

services (e.g., via specifying particular preferences) ontop of these schemas.

The service execution planner is the module that plans the optimal resources for the

http://localhost:80/servicePrice.xml


execution of a composite service, implementing the approach presented in Section 5.3.

A search facility is offered to locate services and resources using the service/resource

discovery engine. We use HP Jena toolkit [96] for parsing RDF documents. The infor-

mation of the matched resource of a particular service should be sent to the controller

of this service.

6.2.3 Service Deployer

The service deployer is responsible for generating controltuples of every task of a

composite service statechart, using the algorithms presented in Section 4.5. The input

of the programs implementing these algorithms are statecharts represented as XML

documents (which are generated by the service builder), while the outputs are control

tuples formatted in XML as well.

Once the control tuples are generated, the service deployerassists the service de-

signer in the process of uploading these tuples into the tuple spaces of the correspond-

ing component services and the composite service. It is worth mentioning that the stat-

echart implementing a composite service is not uploaded/downloaded into the hosts of

the component services. Instead, a host providing a services will only receive the

control tuples of the states where an invocation tos is made. In this way, it is not

required that each participant of the Self-Serv platform deploys the whole system. In-

stead, the only parts of the system which are required by all the participants are the

classes implementing the service containers (see Section 6.3).

A service may be involved in several compositions (e.g.,s may be a component of

bothCS1 andCS2), and may even be referenced more than once in a given composition

(e.g., the statet1 of CS invokes the operationop1 of s, and the statet2 of CS invokes

the operationop2 of s). Consequently, the host of a services may need to store several

sets of control tuples. In order to ensure that a controller is able to retrieve the right


tuples at the right moment, each tuple is identified by a pair (cs-id, task-id), where

cs-id is the identifier of a composite service andtask-id is the identifier of a state of

cs-id’s statechart.

6.3 Service Execution Environment

The service execution environment is implemented by a service container that includes

four Java classes:execution controller, event manager, context manager, andservice

migrator. These classes are relatively lightweight, and the only infrastructure that they

require are standard Java libraries, a JAXP-compliant XML parser, a SOAP server, and

Tahiti (a tiny Aglets server program). In the current implementation, we use Oracle’s

XML Parser 2.0 and IBM’s Apache Axis 1.2. For any Web service wishing to partici-

pate in the Self-Serv platform, the administrator of the service needs to download and

install the service container, together with a tuple space.

6.3.1 Execution Controller

The functionalities of an execution controller are realized by a pre-built Java class,

calledController. This class provides an operation calledcoordinate for re-

ceiving messages, managing service instances (i.e., creating and deleting instances),

registering events to the event manager, triggering actions, tracing service invocations,

and communicating with other controllers. The controller relies on the tuple space of

the associated service to manage service activities. Controllers monitor and control

service activities by creating and reading tuples of their associated space as well as

injecting (uploading) tuples in spaces associated with their peers.

Tuple spaces are implemented using IBM TSpaces [183], which is a network com-

munication buffer with database capabilities. Controllerscommunicate asynchronously


through the shared spaces by writing, reading, and taking control tuples. Each tuple is

implemented as a vector of Java objects.

6.3.2 Event Manager and Context Manager

The event manager and context manager are two components that are attached to a

service. The context manager detects, collects, and disseminates context information

while the event manager fires and distributes events. The context manager is built on

top of the Context Toolkit [145], a package that supports the development of context-

aware applications. In particular, we implemented contextproviders as a set of context

widgets that encapsulates context information and providemethods to access them.

Each context widget has a set of attributes that can be queried by the context manager.

The context manager can also register to be notified of context changes detected by

the widget. The communications between context widgets andapplications (e.g., the

context manager) are implemented based onBaseObject class, provided by the

toolkit.

The event manager is mapped onto a class calledeventManager, which pro-

vides methods for receiving messages, including subscribing messages from the con-

troller of a service and context information from the context manager, and notifying

the fired events to the controller. In particular, the classeventManager implements

a process that runs continuously, listening to the incomingmessages. The messages

are identified bysubscription, or context. The former are the messages sub-

scribing events, while the latter are the messages notifying the updated context. When

theeventManager receives a message, it first examines the identifier of the message

and proceeds as follows:

• if it is a subscribing message, extracts the subscribed event and adds the event to

anevent pool, which maintains all the subscribed events,


• if it is a context message, extracts the context informationand examines the

events in the event pool. If the context matches an event, fires the event and

notifies the controller.

6.3.3 Service Migrator

The controller of a service sends a notifying message to the service migrator if the

service will be executed in another resource host. The service migrator is implemented

in a class calledMigrator, which is responsible for: (i) uploading the service to the

resource host, if applicable, and (ii) dispatching a mobileagent to the host for service

invocation and result collection.

We have adopted Aglets [3] for implementing mobile agents which invoke ser-

vices in the resource hosts and return the invocation results. ServiceInvokeris an

aglet which needs to be downloaded together with theMigrator. It is a static

aglet. When a service needs to move to a resource host,serviceInvoker creates

a slave calledserviceInvokerSlave, and passes the destination (e.g., resource host) to

theserviceInvokerSlave. ServiceInvokerSlave is the labour aglet that

actually goes to the resource site. Upon arrival at the resource site,doJob method of

theserviceInvokerSlave is called, which performs the real work that we assign

to the slave (i.e., invoking the service). When theserviceInvokerSlave returns

to the service site, callBack method of the master agletserviceInvoker is

activated. The results are passed as an argument of thecallBack method. The

serviceInvoker aglet then extracts and passes the results to theMigrator. The

Migrator in turn sends the invocation results to the controller.


6.4 Demo Scenario

We present a class assistant scenario that illustrate the main features of Self-Serv. We

consider the case of a college student Andrew who wants to manage his class activ-

ities using his mobile computer (e.g., Pocket PC). Andrew would like an attendance

reminder notifies him—ten minutes before the lecture—aboutthe time and place of

the lecture. During the lecture, Andrew would like to browsethe questions asked by

other students using his PDA and to vote for a posted questionor to post a new ques-

tion. After the class, Andrew may need to book a consultationand he always likes

to provide some feedbacks for the lecture (detailed description of the scenario can be

found in Chapter 1.2).

The fulfillment of Andrew’s needs requires accessing different Web services pro-

vided by the university, such asattendance reminder, question posting,

andconsultation booking. Andrew can access these services individually or

invoke a single composite Web service. In the following, we will describe the main

steps for composing, deploying, and executing such a service using Self-Serv. In par-

ticular, we will demonstrate: (i) how to define a composite service for the class assis-

tant scenario, (ii) how to deploy and register the service, and (iii) how to locate and

execute the service.

Step 1: Defining a composite service.The service builder assists developers in

the creation and maintenance of communities and composite services. It

offers agraphical user interface(GUI) allowing service designers to de-

scribe the statechart diagram of a composite service operation services, to

create and configure service communities, and to import operations from

existing Self-Serv services into composite services and communities. A

search and browse facility is offered to locate component services using


(a) Specifying composite services

(b) Discovering component services

Figure 6.2: Defining services in Self-Serv


Figure 6.3: Configuration of process schemas on PDAs

the service discovery engine (Figure 6.2 (b)) and import their operations

into states. After the definition of a composite service is completed, the

service is translated into an XML document. The composite service of the

class assistant is defined as shown in Figure 6.2. The component services

referenced in the composite service are assumed to have beenpreviously

registered with the discovery engine. During this registration process, the

service container classes have been downloaded via the Service Deployer,

and installed in the hosts of the component services.

It should be noted that service developers can define composite services on

top of process schemas. First, the developers search the discovery engine

to find the appropriate process schemas. When a schema is selected, its

specification is loaded into the editor where developers canspecify their

services based on it. In addition to the editor designed for desktop users,

we also provide a tool where mobile users can configure process schemas

using their mobile devices (see Figure 6.3).


Figure 6.4: Deploying control tuples

Step 2: Deploying and registering a composite service.Once a composite service

has been defined, the Service Deployer assists the service designer during

the deployment process. This process takes as input the XML description

of the composite service and involves two steps: (i) generating the control

tuples of each state of the composite service statechart, and (ii) uploading

these tuples into the tuple spaces of the component services. Figure 6.4

shows the control tuples of taskAR of the class assistant service.

The composite service also needs to be registered with the Service Dis-

covery Engine so that it can be located and executed. A service can be

published with the UDDI registry using thePublishpanel offered by the

Service Discovery Engine. Before a service can be published,its WSDL


(a) Inputting feedback (b) Browsing questions

Figure 6.5: Execution of the composite service

descriptions should be created and deployed. This essentially means plac-

ing the WSDL descriptions so that they can be retrieved using public URLs.

The information of the service (e.g., service name, locations of WSDL de-

scriptions) and of the provider of the service (e.g., provider name, contact

data) is entered via thePublish panel. When thePublish button is

clicked, the Service Discovery Engine publishes the service details in the

UDDI registry.

Step 3: Executing a composite service.An end user can locate Web services from

the UDDI registry. The user can search Web services by providers, service

names or operations. The query yields a list of service providers with all

its services and all operations provided by the services.

An end user can execute a specific operation of a service by clicking on the

Invoke button. When the controller of the composite service receives the

request, it sends a message to the controller of the state(s)in the statechart


which need(s) to be entered in the first place. This/these controller(s) in-

voke their underlying service(s). Then, the orchestrationof the composite

service execution is carried out through peer-to-peer message exchanges

between the controllers. During the execution, an execution window may

pop up , which enables the end user supplying values of some parameters

that are needed to execute the service (e.g.,comments, see Figure 6.5

(a)). Meanwhile, some service results may be delivered to the end user

(e.g., posted questions by other students, see Figure 6.5 (b)). Eventually,

the controllers of the states which are exited in the last place send their no-

tification of termination back to the controller of the composite service. At

this point, the execution of the composite service is completed.

It should be noted that in this scenario, we demonstrate the execution of

composite services where mobile users are involved. For desktop users,

Self-Serv also provides an interface for searching and invoking services.

Readers are referred to a demonstration paper [151] for more details.

6.5 Usability and Performance Study

To evaluate the proposed service composition approach, we conducted an extensive

empirical performance study using our implemented Self-Serv prototype system. The

aim of our performance study is twofold. First, we investigate the potential usage of the

proposed service composition platform via a usability study. Second, we compare the

performance of our proposed service composition techniques from various aspects in-

cluding scalability, execution cost, and adaptation effectiveness of composite services.

We report our findings in Section 6.5.1 and Section 6.5.2, respectively.


1

0

0 5

12 17

Probably yes

Yes Have no idea

No

Probably no

Figure 6.6: The responses to the willingness of using Self-Serv

6.5.1 Usability Evaluation

We conducted a usability study to evaluate users’ willingness to use the system, and

their perception of the system’s utility and ease of use. According to [129, 147], these

aspects are fundamental determinants of system adoption.

We presented our system to 18 people, all from different backgrounds (8 under-

graduate students, 2 masters students, and 8 PhD students).The presentation included

a PowerPoint show of the system overview, a demonstration ofthe usage of the Self-

Serv system, and the digital class assistant service, the prototype application built on

top of Self-Serv. The participants were then asked to use thesystem and to report their

experience by answering a questionnaire.

The feedback from the participants was quite encouraging. Fourteen people re-

ported that they understood the design principles of Self-Serv very well after their

usage of the system, while four indicated a partial comprehension. However, lacking

the technical knowledge about the system does not seem to prevent students from us-

ing it. Most people (17) expressed their willingness to use the system in designing and

accessing composite Web services. Only 1 person had no idea whether he would use

the system (see Figure 6.6).


0

10

20

30

40

50

60

Sp

ecif

icat

ion

tim

e (m

inu

te )

1st 2nd 3rd 4th 5th 6th

Service specification

Figure 6.7: The time used for specifying the digital class assistant service

We evaluated the learnability and efficiency of Self-Serv system by asking the par-

ticipants to create the digital class assistant service andfive other composite services

using our service composition tools. These five services have the same complexity

as the digital class assistant service (i.e., they have the same number of component

services and same control flows). The participants were asked to create these services

and record the time used. We found that users spent more time on their first attempt.

The average time they spent is 53 minutes. However, after users know how to use

the system, they can specify services efficiently. Compared to the first attempt, the

average time used for specifying the rest five services is only 18 minutes. We can see

that it took about 35 minutes for the participants to learn how to use Self-Serv system.

Figure 6.7 shows the time spent by a participant in the specification of the six services.

We also collected the feedback of the participants on our Self-Serv system design.

The results are summarized in Table 6.5. From the table, we can see that most partic-

ipants can use the system with little efforts. In fact, threepeople even enjoyed their

experience in using Self-Serv. The ease-of-use component that most people agreed—

with no surprise—is the service editor that provides a visual interface where composite


Questions ResponsesA B C

What is your opinion on the system interface design: (A) clearand easy to follow; (B) some confusions butgenerally can be followed; (C) needs redesign

5 10 3

Describe your experience in using the tools: (A) easy to use and enjoy; (B) spent some time to get familiarwith; (C) spent too much effort and frustrated

3 12 5

Which component of Self-Serv is the most interesting one and is easy to follow: (A) discovery engine; (B)service editor; (C) distributed execution

5 9 4

Which tool of Self-Serv is the most difficult one to use: (A) discovery engine; (B) service editor; (C)PDA-based service configuration

2 5 11

For the service configuration, which one you prefer to use: (A) desktop version; (B) PDA version; (C) doesnot matter*

11 2 4

* One person did not respond to this question.

Table 6.5: Evaluation results of the system design

services can be specified by drawing statechart diagrams.

However, most participants (11) ratedPDA service configurationtool as the most

difficult one to use. The tool was implemented as a mobile software running on PDAs

where mobile users specify their user preferences of process schemas (see Figure 6.3).

From Table 6.5, we can see that although most people had anot so badexperience in

using the configuration tool, very few people (2) would like to use the PDA version if

they are given both versions of configuration tool (i.e., Desktop PC and PDA). Reasons

that prevent people from using PDA based configuration tool include: i) difficulties in

operating the interface, ii) slow interaction speed, and iii) more importantly, endless

anxiety on the battery power and network connections of PDAs. We also found out

that the people who gave the low ease-of-use ratings are generally not familiar with

handheld computing devices. Some of them have even never used a PDA before. In

any case, user training on how to use such kinds of devices would help alleviate some

of this anxiety.

Finally, the feedback on our class assistant application from the participants is also

inspiring. All people agreed that this novel application would enhance their partic-

ipation in the classrooms and would improve their learning efficiency, especially to

those who are diffident about asking questions in the public.All people also expressed


their willingness to use similar systems subject to market availability2. Clearly, the

success of running such an application in highly dynamic environment is based on the

techniques proposed in our Self-Serv platform.

6.5.2 Performance Evaluation

We conducted experiments using the implemented prototype system. This section

presents three experimental results. The first experiment shows the cost of deploying

composite services in Self-Serv. The second experiment compares the performance

between our distributed services orchestration approach and the centralized orches-

tration approach including: i) the number of physical messages required to execute

composite services; ii) the workload distribution; and iii) the service response time

with different message sizes. The third experiment studiesthe effectiveness of the

system’s adaptation.

For the experiments, we used the implemented class assistant service (CAS), shown

in Figure 3.2. It should be noted that the reason that we chosethis scenario is because

the environment that users interact with is highly dynamic.We conducted experiments

using a PDA and a cluster of PCs running the prototype system. AMitac Mio 168

GPS integrated Pocket PC is used as a mobile device that connects the 11Mb Lucent

802.11b access points installed in the building of the School of Computer Science and

Engineering at UNSW. A cluster of PCs was used to run the remaining part of the

system. One of them is dedicated to the class assistant composite service while others

are servers for component services. All PCs have the same configuration of Pentium

III 933MHz and 512Mb RAM. Each PC runs Debian Linux and the Java2 Standard

Edition V1.4.2, and is connected to a LAN through 100Mbits/sec Ethernet cards.

2It is safe to expect that such applications will be emerged inthe near future with the flourish ofubiquitous computing and service computing. UCSD’s ActiveClass [81, 82] is an example although itwas implemented in a client-server infrastructure.


Deployment Cost. The purpose of this experiment is to measure the deployment

cost (i.e., time required to generate and upload the controltuples of a service) of a

composite service using Self-Serv. In the experiment, we created several composite

services with different number of component services and recorded the time taken by

the deployment of each composite service. The services werecreated by randomly

adding tasks to the composite service of class assistant. The deployment procedure

includes generating control tuples for each component service and uploading the tuples

to the tuple spaces associated with the service. We deployedeach composite service

10 times and computed the average deployment time.

No. of component service 8 15 20 30 40 50Deployment cost(second) 7.2 8.2 9.7 12.9 16.1 18.8

No. of component service 60 70 80 90 100 110Deployment cost(second) 22.1 26.3 31.3 32.7 34.8 35.4

Table 6.6: The deployment cost of composite services.

Table 6.6 plots the time for deploying a composite service interms of the number

component services. For example, it only spends 7.2 secondsto deploy a composite

service which has 8 component services and 9.7 seconds for the one with 20 compo-

nent services. This table shows that for large composite services (e.g., with more than

50 component services), the deployment speed tends to be of 3component services

per second.

Although the experiments were conducted in a local-area network, one can expect

deployment speeds over large-area networks that would allow to deploy services with

dozens of components a few minutes. However, our approach isstill much more com-

petitive than other service deployment means (e.g., deploymanually) which could take

several days or even couple of weeks.


Distributed Orchestration Versus Centralized Orchestration. The purpose of this

experiment is to study and compare the performance of our distributed orchestration

model with that of the centralized one. The comparison was done by measuring:

• the number of overall physical message exchanged,

• the distribution of workload (i.e., number of messages handled at a given host)

across participant hosts, and

• the service response time (i.e., the overall time used from sending a request to a

service to receiving a result from the service).

In the implementation of the centralized approach, acentral scheduleris respon-

sible for sending and receiving messages to and from the component services. The

central scheduler is located in the same machine as the classassistant service, while

the component services (e.g.,consultation booking service) are located in the

other machines. The physical message exchanges in the centralized model correspond

to the messages exchanged between the central scheduler andthe component services.

On the other hand, in the implementation of the distributed approach, the service

container (including execution controller, event manager, context manager, and service

migrator) of a task and the component service invoked in thistask are located in the

same machine, i.e. each pair (service container, componentservice) is located in a sep-

arate machine, while the container of the class assistant service is located in its own

machine. The physical message exchanges in this approach correspond to the mes-

sages exchanged between the controller of the composite service and the controllers of

its component services, as well as those exchanged between the component controllers.

It should be noted that we do not count the messages exchangedbetween components

of the same service containers (e.g., messages exchanged between the event manager

and the controller) because they are located in the same machines.


We executed class assistant service and counted the number of physical messages

exchanged under these two orchestration models. It is worthing mentioning that we

did not implement the loop of question asking in the service (see Figure 3.2). Also note

that there are two branches in the class assistant service, so we executed the composite

service using all the possible combinations oftruth values of the branching conditions.

Table 6.7 shows the results of these simulations.

Combination of branch conditions Number of messagesBranching conditions

No. listed answered distributed centralized1 yes yes 14 122 yes no 15 143 no yes 14 124 no no 15 14

Average 14.5 13

Table 6.7: The number of exchanged messages in the executionof the class assistantservice

From the table we can see that for every possible combination, the distributed

model requires slightly more physical message exchanges than the centralized one.

For example, in case 3 of Table 6.7 (i.e., the question has notbeen asked by other stu-

dent and all the student’s questions have been answered by the lecturer), 12 messages

are exchanged in the centralized model, whereas 14 messagesare exchanged in the

distributed model. Overall, the average number of physicalmessage exchanges under

the distributed model is 14.5, while it is 13 for centralizedone. The reason that our

distributed model requires more exchanged messages is because taskAttendance

Reminder has to send data notifications (i.e., 7 messages) to all the rest tasks of the

class assistant service (see Table 3.1). It should be noted that there are many cases

where the distributed orchestration approach requireslessexchanged messages than

the centralized approach. One example is reported in [17].


0

1

2

3

4

5

6

Nu

mb

er o

f re

ceiv

ed

mes

sag

es

CAS AR AG LO QB QP QV CB LF

Composite and component services

Distributed Centralized

(a)

0

1

2

3

4

5

6

7

Nu

mb

er o

f re

ceiv

ed

mes

sag

es

CAS AR AG LO QB QP QV CB LF

Composite and component services


(b)

Figure 6.8: Workload allocation in the execution of the class assistant service in: (a)case 1, and (b) case 2

We also measured the workload allocation of the participanthosts (i.e., the hosts

of class assistant service and its components), by countingthe number of messages

received at each participant host. Figure 6.8 shows the results for case 1 and 2. Other

two cases yielded similar results.


The results of both cases show that in the centralized model,messages are not

distributed evenly. In particular, the machine hosting thecentral scheduler receives

many messages (e.g., 7 messages in (b) of Figure 6.8). On the other hand, other ma-

chines only receives 1 message each. Half of the messages arereceived and handled

by the central scheduler. In contrast to the centralized model, the workload of the

distributed model is spread gracefully among the machines.Compared to the central-

ized approach, the class assistant service only receives and handles 2 messages in the

distributed approach. The above experiments consider onlyone execution instance of

CAS. However, we can estimate that there could be 7,000 messageshandled by the cen-

tral scheduler if 1,000 executions run concurrently. While for our distributed model,

the controller ofCAS would only receive 2,000 messages. As a result, the distributed

execution model is more scalable.

Finally, we conducted another experiment to investigate the execution performance

of distributed and centralized execution models, with different size of exchanged mes-

sages. In the experiment, we assume that the size of all exchanged messages remains

the same during the service execution. The size of messages ranges over the values 1K,

2K, 4K, 16K, 32K, 64K, 128K, 256K, 512K, and 1024K. For each message size, we

executedCAS 10 times and computed the average service response time. Theresults

for case 1 is shown in Figure 6.9. Similar results were obtained for the other cases.

From Figure 6.9 (a) we can see that, in both the distributed and the centralized

approach, the service response time does not change greatlywhen the size of messages

is small. For example, for the distributed approach, the service response time changes

slowly from 11.02 seconds to 15.3 seconds when the message size grows from 1K to

8K. In addition, the response time of the distributed approach is slightly bigger than

the response time of the centralized approach. To make it easy to compare, we depict

the service response time of both approaches with the message sizes from 1K to 32K,


0200400600800

100012001400160018002000

1 2 4 8 16 32 64 128 256 512 1024

Message size (K)

Ser

vice

res

po

nse

tim

e (s

eco

nd

s)


(a)

10

12

14

16

18

20

22

24

26

28

30

1 2 4 8 16 32

Message size (K)

Ser

vice

res

po

nse

tim

e (s

eco

nd

s)


(b)

Figure 6.9: The response time of the composite serviceCAS

in Figure 6.9 (b). It is shown that, in the distributed approach, the response time is

11.02 seconds when the message size is 1K and it is 10.52 seconds in the centralized

approach. The main reason of more time required for distributed approach is due to

the number of exchanged messages in the distributed approach is more than the one in

the centralized approach.


We also note that when the size of messages increases, the service response time of

the centralized approach increases more sharply than that of the distributed approach

(see Figure 6.9 (a)). This is due to the reason that the messages in the centralized

approach need to systematically transit through a central scheduler which easily con-

stitutes a bottleneck.

Adaptation Effectiveness. The purpose of this experiment is to study the effective-

ness of the system’s adaptation to dynamic environments. The experiment was done

by comparing the performance of the system with and without exception handling

mechanism.

For experimental purposes, we specified aTimeout policy: “if the waiting time

is longer than 5 seconds during the invocation of a service, cancel the invocation and

execute the substitute service”, and used this policy in the experiment to see how effec-

tive our system is while the network is overloaded. The exception handling tuples were

generated from the policy and injected into the tuple spacesof the services. To simulate

the overloads of the network, we defined aservice delaythat makes the services sleep

for a specific amount of time (e.g., 1000 ms) before their acceptance of the invocation

requests. We then executed the two versions ofCAS with various network overloads

and measured the time used. The network overloads we simulated range from 1,000ms

to 10,000ms. Under each network overload condition, we executedCAS 10 times and

computed the average service response time. The result is depicted in Figure 6.10.

From Figure 6.10 (a) we can see that, exception handling mechanism significantly

improved the system performance. When service delays are less than 5 seconds, for

exception handling approach and non exception handling approach, there is no major

impact on the service performance because the exception handling policy is not ap-

plied yet due to unsatisfied condition of the exception handling tuples. However, the


020406080

100120140160180200

0 1 2 3 4 5 6 7 8 9 10

Service delay (second)

Ser

vice

res

po

nse

tim

e (s

eco

nd

)

with exception handling

without exception handling

(a)

30

40

50

60

70

80

90

100

110

0 1 2 3 4 5

Service delay (second)

Ser

vice

res

po

nse

tim

e (s

eco

nd

)

with exception handling

without exception handling

(b)

Figure 6.10: System performance with and withoutTimeout policy

performance difference of both approaches becomes significant when the service de-

lay is increased. For example, when the service delay is 10 seconds, it spends 178.568

seconds to executeCAS without exception handling mechanism, while only 103.780


seconds for the one with exception handling. In particular,with the exception han-

dling, the response time of the application tends to level off because the controllers

select new services with less workloads for the invocation instead of waiting for the

overloaded ones.

It is also interesting to note that when the delay time is lessthan 5 seconds, the

response time of the application with exception handling isslightly higher than the

one without exception handling. For example, it takes 91.736 seconds to execute the

former when the delay is 4 seconds, while for the latter, the time spent is 89.876

seconds. For a better illustration purpose, we depict the system performance ofCAS

when the delay time is less than 5 seconds in Figure 6.10 (b). The reason of the higher

service response time is due to the overhead introduced by the processing of exception

handling tuples. However, we do not consider this to be a significant performance

overhead, comparing with the performance achieved by the exception handling tuples.

6.6 Summary

In this chapter, we have presented the implementation of ourproposed techniques in

a prototype systemSelf-Serv. During the implementation, a number of emerging Web

services technologies have been used and tested in our system. To validate the feasi-

bility and benefits of our proposed approaches, we developedseveral applications on

top of the platform and conducted an extensive performance study. The findings can

be summarized as follows. First, the developed applications illustrate that our system

can provide an efficient support for specifying, deploying,and accessing composite

services. Indeed, the feedback from our usability study is quite positive and inspir-

ing: most participants rated it as an ease-of-use tool and almost all of them expressed

the willingness to use it for specifying and accessing composite services. Second, the

experimental results reveal that our distributed service orchestration approach is more


scalable and outperforms the centralized approach when theexchanged messages be-

come bigger. Third, our approach is more robust and adaptivein highly dynamic

environments, and leads to more faster execution of composite services.

Chapter 7

Conclusions

In this chapter, we summarize the contributions of this dissertation and discuss some

future research directions for Web services composition.

7.1 Summary

In the recent years, Web services composition is emerging asa promising technology

for the effective automation of application-to-application collaborations and attracts a

significant industry and research interest [15, 50, 39, 7, 117]. However, with growth in

importance of business process automation and highly dynamic nature of the Internet,

Web services composition has taken on a new significance and importance. Adequate

solutions to this problem will be very important for making enterprise systems more

flexible, robust and usable in the future.

In this dissertation, we have proposed a generic approach for the provisioning of

composite Web services in dynamic and distributed environments. We also provided

an implementation of our approach in theSelf-Servprototype. In particular, we sum-

marize our main research contributions in the following:

• Personalized and Adaptive Composition of Web Services:We proposed a service

composition model where Web services can be composed in a personalized and

Chapter 7. Conclusions 182

adaptive manner [152, 19, 17, 153]. Composite Web services are modeled based

on statecharts [85]. To cater for the large amount and dynamic nature of Web

services, we proposed a divide-and-conquer approach that groups services into

communities. Service communities are essentially containers of substitutable

services. They provide descriptions of desired services (e.g., providing flight

booking interfaces) without referring to any actual provider. Actual providers

can register with any community of interest to offer the desired service. At run-

time, the community is responsible for selecting the service offer that best fits a

particular user profile in a specific situation.

To speed up and ease the development of composite services, we used the con-

cept of process schema, which is a reusable and extensible business process

skeleton devised to reach a particular goal. Users can then adjust this process

schema with their personal contextual preferences and constraints, rather than

building a new service from scratch. To handle the exceptions (e.g., service

failures, network errors) happened in the service provisioning, we developed a

policy-based approachwhere a set of exception handling policies can be speci-

fied to proactively react to runtime exceptions. Policies are expressed and con-

trolled at a high level of abstraction, separating from the composite service’s

functionality. In this way, service designers can dynamically add, remove, and

modify policies, to reconfigure the composite services without changing com-

posite service functionalities (e.g., control flow embedded in statecharts).

• Tuple Space Driven Service Orchestration:We proposed a distributed, tuple

spaces based composite service execution model to achieve flexible and scal-

able execution of composite services in dynamic environments [152, 153]. In

our model, the execution of participating services of composite services isself-

managed: they are capable of coordinating their actions in an autonomous way,


without having to continuously synchronize with a central entity. The self-

orchestration is achieved by means ofexecution controllers. A controller is as-

sociated with a service and is responsible for monitoring and controlling service

executions. The knowledge required by a controller is statically extracted from

the specification of composite services.

To deal with the dynamic issues (e.g., disconnection) of theservice provisioning

environments, we proposed atuple space[4] based orchestration model where

the knowledge of the service orchestration is represented in the form ofcontrol

tuplesthat are placed in and retrieved from the tuple spaces associated with the

services. The control tuples are represented as event-condition-action (ECA)

rules where the enforcement of the orchestration of composite services is based

on an event triggering mechanism. The communications of theservice orches-

tration are asynchronous and de-coupled in both time and place.

• Robust Web Services Provisioning:We proposed novel techniques for optimal

and robust Web services provisioning [113, 114, 112]. We extended the system

model and introduced a new service container component calledservice migra-

tor. A service migrator, which is associated with a mobile Web service, can

instantiate an instance of the service at appropriate idle computing resources

during runtime on demand and therefore, reduces the risk of the service being

unavailable. Furthermore, due to load balancing, a faster processing of service

requests can be achieved.

To facilitate dynamic resources selection, we introduced aflexible and semi-

structured data model for the description of services and resources, as well as a

matchmakingalgorithm for selecting computing resources against the require-

ments of Web services. To achieve optimized overall performance of a com-

posite service, we proposed a multi-phase execution planning approach where


resources are selected for the components of the composite service based on a

number of criteria such as communication cost.

• Implementation and Performance Study:We implemented these techniques in-

side the Self-Serv prototype [151, 154, 19]. We adopted a number of state-of-

the-art technologies for the implementation of the prototype, including emerging

Web service standards like WSDL [49], SOAP [155], and UDDI [10]. Our im-

plementation has led to a comprehensive platform for Web services creation,

composition, and invocation in distributed and dynamic environments.

To validate the feasibility and benefits of our approach, we developed several

composite services using the prototype system and conducted an extensive per-

formance study. First, we investigated the potential usageof the proposed ser-

vice composition platform via a usability study. Second, westudied the per-

formance of our approach from various aspects including scalability, execution

cost, and adaptation effectiveness.

7.2 Future Directions

Although Web services composition has been heavily investigated in the last few years,

several research issues still need to be addressed. In particular, we identify the follow-

ing directions for future research: automatic compositionof Web services and the

support of security and mobility.

• Automatic Composition of Web Services:It is a common understanding that

companies should react promptly to today’s ever changing market requirements

in order to remain competitive. Service providers therefore need tools and tech-

niques to quickly develop and deploy interesting applications for their clients. It

is appealing that the composition of Web services can be “automated” by avoid-


ing human intervention as much as possible. Automatic service composition ap-

proaches typically exploit the Semantic Web [22] and AI planning techniques.

By giving a set of component services and a specified requirement (e.g., user’s

request), a composite service specification can be generated automatically [21].

However, realizing a fully automatic service composition is still very difficult

and presents several open issues [20]. The basic weakness ofmost of research

efforts proposed so far is that Web services do not share a full understanding

of their semantics, which largely affects the automatic selection of services. In-

deed, a complete solution for delivering Semantic Web services is still on the

way and far from mature [34]. Other issues like the verification and optimization

of composite Web services are also critical to the success ofautomated service

composition. Currently, the first results on automatic composition of Web ser-

vices are those presented in [117, 116, 169, 32]. We expect more research effort

in this direction.

• Security Support of Service Composition:Web service composition technologies

promise a cheap and effective means for application integration over the Internet

(e.g., developing B2B applications). However, beyond the functional aspects,

non-functional composition properties like security and trust are of utmost im-

portance for service composition techniques to be adopted.There are several

security issues—such as confidentiality, integrity, privacy, authentication, and

authorization—that must be considered in the context of service composition.

For example, it is important to guarantee the fairness of thevalues of QoS cri-

teria when a service community selects Web services from itsmembers. For

a bank payment service, it is not appropriate that anyone cansee the sensitive

information transferred between the composite service andthe requester. There

are several specifications for Web service security being recently emerged such


as WS-Security [128], WS-Trust [66], and WS-Federation [65]. However, these

specifications have not yet found their way to composite Web services. A nat-

ural solution is to extend service composition languages (e.g., BPEL) with new

constructs to support such non-functional concerns. Nevertheless, mixing the

specification of the core logic of the service composition with the specifications

of security features would make the composition too complexand hard to main-

tain and evolve. The effective handling security issues at the composite service

level, should be therefore facilitated by other specifications that are separated

from the composite service’s functionality. A few emerged research efforts in

this area are proposed such as [44, 158].

• Mobility Support of Service Composition:In our future work, we also intend

to extend our model to support seamless access of composite services among

multiple computing devices. Indeed, during the invocationof a Web service,

especially the one having long running business activitiesor with complex tasks

(e.g., composite services), users are more likely to be switching from device

to device (e.g., from office PCs to PDAs) [46, 42, 90]. Applications can not

be allowed to terminate and start again simply because userschange devices.

Instead, the access of Web services should beoperational continuous. In other

words, users should not experience a break during the service invocation while

they are moving. This is extremely important for the people in time critical

working environments (e.g., doctors in hospitals). Another important direction

is to support team work where multiple (mobile) users can virtually collaborate

with each other in the same business processes.

BIBLIOGRAPHY

[1] Wil M.P. van der Aalst, Arthur H.M. ter Hofstede, Bartek Kiepuszewski, andAlistair P. Barros. Workflow Patterns.Distributed and Parallel Databases,14(1):5–51, 2003.

[2] Anurag Acharya, M. Ranganathan, and Joel Saltz. Sumatra:A Language forResource-Aware Mobile Programs.Mobile Object Systems: Towards the Pro-grammable Internet, pages 111–130, 1997.

[3] Aglet. http://www.trl.ibm.com/aglets/.

[4] Sudhir Ahuja, Nicholas Carriero, and David Gelernter. Linda and Friends.IEEE Computer, 19(8):26–34, August 1986.

[5] James F. Allen. Maintaining Knowledge about Temporal Intervals. Communi-cations of the ACM, 26(11):832–843, 1983.

[6] Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju. Web Ser-vices Concepts, Architectures and Applications. Springer Verlag, 2004.

[7] Tony Andrews et.al. Business Process Execution Languagefor Web Services1.1. http://www-106.ibm.com/developerworks/library/ws-bpel.

[8] Apache Axis. http://ws.apache.org/axis/index.html.

[9] Apache Tomcat. http://jakarta.apache.org/tomcat.

[10] Ariba Inc, Microsoft Co, and IBM Co. Universal Description, Discovery andIntegration of Business for the Web. http://www.uddi.org, 2000.

[11] Daniel Austin, Abbie Barbir, Christopher Ferris, and Sharad Garg. Web Ser-vices Architecture Requirements. http://www.w3.org/TR/wsa-reps.

[12] Karim Baina, Boualem Benatallah, Fabio Casati, and Farouk Toumani. Model-Driven Web Service Development. InProc. of the 16th International Confer-ence on Advanced Information Systems Engineering (CAiSE’04), Riga, Latvia,June 2004.

[13] Arindam Banerji et.al. Web Services Conversation Language (WSCL).http://www.w3.org/TR/wscl10.

[14] Boualem Benatallah, Fabio Casati, Farouk Toumani, and Rachid Hamadi. Con-ceptual Modeling of Web Services Conversations. InProc. of the 15th Interna-tional Conference on Advanced Information Systems Engineering (CAiSE’03),Klagernfurt/Velden, Austria, June 2003.

http://www.trl.ibm.com/aglets

http://www-106.ibm.com/developerworks/library/ws-bpel

http://ws.apache.org/axis/index.html

http://jakarta.apache.org/tomcat

http://www.uddi.org

http://www.w3.org/TR/wsa-reps

http://www.w3.org/TR/wscl10

BIBLIOGRAPHY 188

[15] Boualem Benatallah and Fabio Casati, editors. Special Issue on Web Services.Distributed and Parallel Databases, An International Journal, 2002.

[16] Boualem Benatallah, Marlon Dumas, Marie-Christine Fauvet, Fethi A. Rabhi,and Quan Z. Sheng. Overview of Some Patterns for Architecting and ManagingComposite Web Services.ACM SIGecom Exchanges, 3(3):9–16, 2002.

[17] Boualem Benatallah, Marlon Dumas, and Quan Z. Sheng. Facilitating the RapidDevelopment and Scalable Orchestration of Composite Web Services. Dis-tributed and Parallel Databases, An International Journal, 17(1):5–37, 2005.

[18] Boualem Benatallah, Marlon Dumas, Quan Z. Sheng, and AnneH.H. Ngu.Declarative Composition and Peer-to-Peer Provisioning of Dynamic Web Ser-vices. InProc. of 18th IEEE International Conference on Data Engineering(ICDE’02), San Jose, USA, February 2002.

[19] Boualem Benatallah, Quan Z. Sheng, and Marlon Dumas. The Self-Serv Envi-ronment for Web Services Composition.IEEE Internet Computing, 7(1):40–48,January/February 2003.

[20] Daniela Berardi, Giuseppe De Giacomo, and Diego Calvanese. AutomaticComposition of Process-based Web Services: A Challenge. InProc. of the14th International World Wide Web Conference (WWW’05), Chiba, Japan, May2005.

[21] Daniela Berardi, Giuseppe De Giacomo, and Massimo Mecella. Basis for Au-tomatic Service Composition. Tutorial at the 14th International World WideWeb Conference (WWW’05), May 2005.

[22] Tim Berners-Lee, James Hendler, and Ora Lassila. The Semantic Web.Scien-tific American, May Issue, 2001.

[23] Elisa Bertino, Munir Cochinwala, and Marco Mesiti. UCS-Router: A PolicyEngine for Enforcing Message Routing Rules in a Universal CommunicationSystem. InProc. of the 3th International Conference on Mobile Data Manage-ment (MDM’02), Singapore, 2002.

[24] Aysu Betin-Can, Tevfik Bultan, and Xiang Fu. Design for Verification for Asyn-chronously Communicating Web Services. InProc. of the 14th InternationalWorld Wide Web Conference (WWW’05), Chiba, Japan, May 2005.

[25] Claudio Bettini, Sushil Jajodia, X. Sean Wang, and Duminda Wijesekera.Provisions and Obligations in Policy Management and Security Applications.In Proc. of the 28th International Conference on Very Large DataBases(VLDB’02), Hong Kong, China, 2002.

BIBLIOGRAPHY 189

[26] Alan H. Bond and Les Gasser.Readings in Distributed Artificial Intelligence.Morgan Kaufman Publishers, 1988.

[27] Marco Brambilla, Stefano Ceri, Sara Comai, and Christina Tziviskou. Excep-tion Handling in Workflow-Driven Web Applications. InProc. of the 14th in-ternational conference on World Wide Web (WWW’05), pages 128–137, Chiba,Japan, May 2005.

[28] Robert Breton. Replication Strategies for High Availability and Disaster Re-covery.Data Engineering Bulletin, 21(4):38–43, 1998.

[29] Dan Brickley and R.V. Guha. Resource Description Framework (RDF) SchemaSpecification. http://www.w3.org/TR/rdf-schema.

[30] Peter J. Brown, John D. Bovey, and Xian Chen. Context-Aware Applications:From the Laboratory to the Marketplace.IEEE Personal Communications,4(5):58–64, 1997.

[31] Thomas Buchholz, Michael Krause, Claudia Linnhoff-Popien, and MichaelSchiffers. CoCo: Dynamic Composition of Context Information. In Proc. ofthe First Annual International Conference on Mobile and Ubiquitous Systems:Networking and Services (MobiQuitous’04), Boston, Massachusets, USA, Au-gust 2004.

[32] Tevfik Bultan, Xiang Fu, Richard Hull, and Jianwen Su. Conversation Speci-fication: A New Approach to Design and Analysis of E-service Composition.In Proc. of the 12th International Conference on World Wide Web (WWW’03),Budapest, Hungary, May 2003.

[33] Christoph Bussler.B2B Integration: Concepts and Architecture. Springer Ver-lag, 2003.

[34] Liliana Cabral, John Domingue, Enrico Motta, Terry Payne, and FarshadHakimpour. Approaches to Semantic Web Services: An Overview and Com-parisons. InProc. of First European Semantic Web Symposium (ESWS’04),Heraklion, Crete, Greece, May 2004.

[35] Giacomo Cabri, Letizia Leonardi, and Franco Zambonelli. Engineering MobileAgent Applications via Context-Dependent Coordination.IEEE Transactionson Software Engineering, 28(11):1039–1055, November 2002.

[36] Luca Cardelli and Rowan Davies. Service Combinators for Web Computing.IEEE Transactions on Software Engineering, 25(3):309–316, 1999.

http://www.w3.org/TR/rdf-schema

BIBLIOGRAPHY 190

[37] Valeria Cardellini, Emiliano Casalicchio, Michele Colajanni, and Philip S. Yu.The State of the Art in Locally Distributed Web-Server Systems. ACM Com-puting Surveys, 34(2):263–311, 2002.

[38] Fabio Casati.Models, Semantics, and Formal Methods for the Design of Work-lows and Their Exceptions. PhD thesis, Politecnico di Milano, Italy, 1999.

[39] Fabio Casati, Dimitrios Georgakopoulos, and Ming-ChienShan, editors. Spe-cial Issue on E-Services.VLDB Journal, 24(1), 2001.

[40] Fabio Casati and Ming-Chien Shan. Dynamic and Adaptive Composition ofE-Services.Information Systems, 26(3):143–162, May 2001.

[41] Girish B. Chafle, Sunil Chandra, Vijay Mann, and Mangala Gowri Nanda. De-centralized Orchestration of Composite Web Services. InProc. of the 13th in-ternational World Wide Web conference (WWW’04), pages 134–143, New York,USA, May 2004.

[42] Dipanjan Chakraborty and Hui Lei. Extending the Reach of Business Processes.IEEE Computer, 37(4):78–80, April 2004.

[43] Dipanjan Chakraborty, Filip Perich, Anupam Joshi, Timpthy Finin, and YelenaYesha. A Reactive Service Composition Architecture for Pervasive ComputingEnvironments. InProc. of the 7th Personal Wireless Communications Confer-ence (PWC’03), Singapore, October 2002.

[44] Anis Charfi and Mira Mezini. Middleware Services for Web Service Com-positions. InProc. of the 14th International World Wide Web Conference(WWW’05), Chiba, Japan, May 2005.

[45] Qiming Chen and Meichun Hsu. Inter-Enterprise Collaborative Business Pro-cess Management. InProc. of 17th IEEE International Conference on DataEngineering (ICDE’01), Heidelberg, Germany, April 2001.

[46] Yih-Farn R. Chen and Charles Petrie. Ubiquitous Mobile Computing. IEEEInternet Computing, 7(2):16–17, 2003.

[47] D. Chimenti, R. Gamboa, R. Krishnamurthy, S. A. Naqvi, S. Tsur, and C. Zan-iolo. The LDL System Prototype.IEEE Transactions on Software Engineering,2(1):76–90, 1990.

[48] Dickson K.W. Chiu, Qing Li, and Kamalakar Karlapalem. Web Interface-Driven Cooperative Exception Handling in ADOME Workflow ManagementSystem.Information Systems, 26(2):93–120, 2001.

BIBLIOGRAPHY 191

[49] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web ServicesDescription Language (WSDL).http://msdn.microsoft.com/xml/general/wsdl.asp, September 2000.

[50] Jen-Yao Chung, Kwei-Jay Lin, and Richard G. Mathieu, editors. Special Issueon Web Services Computing.IEEE Computer, 36(10), October 2003.

[51] Paolo Ciancarini, Robert Tolksdorf, Fabio Vitali, Davide Rossi, and AndreasKnoche. Coordinating Multiagent Applications on the WWW: A Reference Ar-chitecture. IEEE Transactions on Software Engineering, 24(5):362–375, May1998.

[52] James Clark and Steve DeRose. XML Path Language (XPATH) Version 1.0.http://www.w3.org/TR/xpath, November 1999.

[53] Chris Clifton, Irini Fundulaki, Richard Hull, Daniel Lieuwen, and ArnaudSahuguet. Privacy-Enhanced Data Management for Next-Gerneration e-Commerce (Tutorial). InProc. of the 29th International Conference on VeryLarge Data Bases (VLDB’03), Berlin, Germany, September 2003.

[54] Edward E. Cobb. The Evolution of Distributed Component Architectures. InProc. of the 9th International Conference, CoopIS, pages 7–21, Trento, Italy,September 2001.

[55] Francisco Curbera, Rania Khalaf, Nirmal Mukhi, Stefan Tai, and Sanjiva Weer-awarana. The Next Step in Web Services.Communications of The ACM,46(10):29–34, 2003.

[56] Fransico Curbera, Matthew Duftler, Rania Khalaf, William Nagy, NirmalMukhi, and Sanjiva Weerawarana. Unraveling the Web Services Web: An In-troduction to SOAP, WSDL, and UDDI.IEEE Internet Computing, 6(2):86–93,March 2002.

[57] Nicodemos Damianou, Naranker Dulay, Emil Lupu, and Morris Sloman. ThePonder Policy Specification Language. InProc. of the 2nd International Work-shop on Policies for Distributed Systems and Networks (Policy’01), Bristol, UK,January 2001.

[58] Nigel Davies, Adrian Friday, Stephen P. Wade, and Gordon S. Blair. L2imbo:A Distributed Systems Platform for Mobile computing.ACM Mobile Networksand Applications (MONET), 3(2):143–156, 1998.

[59] Umeshwar Dayal, Meichun Hsu, and Rivka Ladin. Organizing Long-RunningActivities with Triggers and Transactions. InProc. of the ACM International

http://msdn.microsoft.com/xml

http://www.w3.org/TR/xpath

BIBLIOGRAPHY 192

Conference on Management of Data (SIGMOD’90), pages 204–214, AtlanticCity, New Jersey, USA, May 1990.

[60] Anind K. Dey. Context-Aware Computing: The CyberDesk Project. TechnicalReport SS-98-02, AAAI 1998 Spring Symposium on Intelligent Environments,March 1998.

[61] Anind K. Dey and Gregory D. Abowd. Towards a Better Understanding of Con-text and Context-Awareness. Technical Report GIT-GVU-99-22, GVU Center,Georgia Institute of Technology, June 1999.

[62] Asuman Dogac, editor. Special Issue on Electronic Commerce. ACM SIGMODRecord, 27(4), December 1998.

[63] Marlon Dumas and Arthur ter Hofstede. UML Activity Diagrams as a workflowspecification language. InProc. of the International Conference on the UnifiedModeling Language (UML), Toronto, Canada, October 2001. Springer Verlag.

[64] Electronic Business XML (ebXML). http://www.ebxml.org/.

[65] Siddharth Bajaj et. al. Web Services Federation Language (WS-Federation).http://ftpna2.bea.com/pub/downloads/WS-Federation.pdf.

[66] Steven Adderson et. al. Web Services Trust Language (WS-Trust).http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf.

[67] D. Fensel and C. Bussler. The Web Service Modeling Framework WSMF.Electronic Commerce Research and Applications, 1(2):113–137, 2002.

[68] M. Fisher. Java Web Services Tutorial 1.0.http://java.sun.com/webservices/docs/1.0/tutorial.

[69] Marcus Fontoura, Toby Lehman, Dwayne Nelson, Thomas Truong, and YuhongXiong. TSpaces Services Suite: Automating the Developmentand Managementof Web Services. InProc. of the 12th International World Wide Web Conference(WWW’03), Budapest, Hungary, May 2003.

[70] David Franklin and Joshua Falschbart. All Gadget and NoRepresentationMakes Jack a Dull Environment. Technical Report SS-98-02, AAAI 1998Spring Symposium on Intelligent Environments, March 1998.

[71] Karen A. Frenkel. Brian K. Reid: A Graphics Tale of A HackerTracker.Com-munications of the ACM, 30(10):820–823, October 1987.

http://www.ebxml.org

http://ftpna2.bea.com/pub/downloads/WS-Federation.pdf

http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf

http://java.sun.com

BIBLIOGRAPHY 193

[72] Alfonso Fuggetta, Gian Pietro Picco, and Giovanni Vigna. Understanding CodeMobility. IEEE Transactions on Software Engineering, 24(5):342–361, May1998.

[73] David Gelernter. Generative Communication in Linda.ACM Transactions onProgramming Languages and Systems, 7(1):80–112, January 1985.

[74] General Packet Radio Service. http://www.gsmworld.com/technology/gprs/intro.shtml.

[75] Dimitrios Georgakopoulos, Mark F. Hornick, and Amit P.Sheth. An Overviewof Workflow Management: From Process Modeling to Workflow AutomationInfrastructure.Distributed and Parallel Databases, 3(2):119–153, 1995.

[76] Michael Gillmann, Jeanine Weißenfels, Gerhard Weikum, and Achim Kraiss.Performance and Availability Assessment for the Configuration of DistributedWorkflow Management Systems. InProc. of the 7th International Confer-ence on Extending Database Technology, pages 183–201, Konstanz, Germany,March 2000. Springer.

[77] Globus Project. http://www.globus.org/.

[78] Esin Gokkoca, Mehmet Altinel, Ibrahim Cingil, E.NesimeTatbul, Pinar Koksal,and Asuman Dogac. Design and Implementation of a Distributed WorkflowEnactment Service. InProc. of Int. Conference on Cooperative InformationSystems (CoopIS), Charleston, USA, June 1997. Springer Verlag.

[79] Google. Google Web APIs Service. http://www.google.com/apis. Date visited:July 30, 2005.

[80] Paul Grefen, Karl Aberer, Yigal Hoffner, and Heiko Ludwig. CrossFlow:Cross-Organizational Workflow Management for Service Outsourcing in Dy-namic Virtual Enterprises.Special Issue on Infrastructure for Advanced E-Services, Bulletin of the Technical Committee on Data Engineering, 24(1),March 2001.

[81] William G. Griswold, Robert Boyer, Steven W. Brown, and TanM. Truong. AComponent Architecture for an Extensible, Highly Integrated Context-AwareComputing Infrastructure. InProc. of the 25th International Conference onSoftware Engineering (ICSE’03), Oregon, Portland, May 2003.

[82] William G. Griswold, Patricia Shanahan, Steven W. Brown, Robert Boyer,Matt Ratto, R. Benjamin Shapiro, and Tan Minh Truong. ActiveCampus: Ex-periments in Community-Oriented Ubiquitous Computing.IEEE Computer,37(10):73–81, October 2004.

http://www.gsmworld.com

http://www.globus.org

http://www.google.com/apis

BIBLIOGRAPHY 194

[83] Robert Guttman, Alexandros Moukas, and Pattie Maes. Agent-Mediated Elec-tronic Commerce: A Survey.Knowledge Engineering Review, 13(2), July 1998.Special Issue on Practical Applications of Agents.

[84] David Harel. Statecharts: A Visual Formalism for Complex Systems.Scienceof Computer Programming, 8(3):231–274, June 1987.

[85] David Harel and Amnon Naamad. The STATEMATE Semantics of Statecharts.ACM Transactions on Software Engineering and Methodology, 5(4):293–333,October 1996.

[86] Karen Henricksen and Jadwiga Indulska. A Software Engineering Frameworkfor Context-Aware Pervasive Computing. InProc. of the Second IEEE AnnualConference on Pervasive Computing and Communications (PerCom’04), Or-lando, Florida, USA, March 2004.

[87] Richard Hull, Bharat Kumar, and Daniel Lieuwen. Towards Federated PolicyManagement. InProc. of the 4th International Workshop on Policies for Dis-tributed Systems and Networks (POLICY’03), Lake Como, Italy, June 2003.

[88] Richard Hull, Philip Neaves, and James Bedford-Roberts. Towards SituatedComputing. InProc. of the 1st IEEE International Symposium on WearableComputers, Washington D.C., USA, 1997.

[89] Hurwitz Group. Using Web Services to Drive the Next Generation of Appli-cations. http://www.wrq.com/products/whitepapers/webservices. Date visited:May 30, 2005.

[90] San-Yih Hwang and Ya-Fan Chen. Personal Workflows: Modeling and Man-agement. InProc. of the 4th International Conference on Mobile Data Man-agement (MDM’03), Melbourne, Australia, January 2003.

[91] IBM WebSphere Studio Device Developer.http://www-306.ibm.com/software/wireless/wsdd/.

[92] IBM WSTK Toolkit. http://alphaworks.ibm.com/tech/webservicestoolkit.

[93] Jadwiga Indulska, Ricky Robinson, Andry Rakotonirainy, and Karen Henrick-sen. Experiences in Using CC/PP in Context-Aware Systems. InProc. of the4th International Conference on Mobile Data Management (MDM’03), Mel-bourne, Australia, 2003.

[94] David B. Ingham, Santosh K. Shrivastava, and Fabio Panzieri. ConstructingDependable Web Services.IEEE Internet Computing, 4(1):25–33, 2000.

http://www.wrq.com/products/whitepapers/web

http://www-306.ibm.com

http://alphaworks.ibm.com/tech/webservicestoolkit

BIBLIOGRAPHY 195

[95] Fuyuki Ishikawa, Nobukazu Yoshioka, Yasuyuki Tahara,and Shinichi Honiden.Toward Synthesis of Web Services and Mobile Agents. InProc. of AA-MAS’2004 Workshop on Web Services and Agent-based Engineering (WS-ABE2004), New York, USA, July 2004.

[96] Jena Toolkit. A Semantic Web Framework for Java.http://jena.sourceforge.net/.

[97] N.R. Jennings, T.J. Norman, P. Faratin, P. O’Brien, and B. Odgers. Autonomousagents for business process management.Journal of Applied Artificial Intelli-gence, 14(2):145–189, 2000.

[98] Markus Keidl and Alfons Kemper. Towards Context-Aware Adaptable WebServices. InProc. of the 13th International World Wide Web Conference(WWW’04), New York, USA, May 2004.

[99] Markus Keidl, Stefan Seltzsam, , Konrad Stocker, and Alfons Kemper. Ser-viceGlobe: Distributing E-Services Across the Internet. In Proc. of the 28thInternational Conference on Very Large Databases (VLDB’02), Hong Kong,China, August 2002.

[100] Markus Keidl, Stefan Seltzsam, and Alfons Kemper. Reliable Web Service Ex-ecution and Deployment in Dynamic Environments. InProc. of the 4th VLDBWorkshop on Technologies for E-Services (VLDB-TES03), Berlin, Germany,September 2003.

[101] Deepali Khushraj, Ora Lassila, and Tim Finin. sTuples: Semantic Tuple Spaces.In Proc. of the First Annual International Conference on Mobileand UbiquitousSystems: Networking and Services (MobiQuitous’04), Boston, Massachusets,USA, August 2004.

[102] Thomas Kistler and Hannes Marais. WebL-A ProgrammingLanguage for theWeb. In Proc. of 7th International World Wide Web Conference (WWW’98),Brisbane, Australia, April 1998.

[103] kSOAP. http://ksoap.objectweb.org.

[104] kXML. http://kxml.enhydra.org.

[105] Amaia Lazcano, Gustavo Alonso, Heiko Schuldt, and C. Schuler. The WISEApproach to Electronic Commerce.Journal of Computer Systems Science andEngineering, 15(5), September 2000.

http://jena

http://ksoap.objectweb.org

http://kxml.enhydra.org

BIBLIOGRAPHY 196

[106] Amaia Lazcano, Heiko Schuldt, Gustavo Alonso, and Hans-Jorg Schek. WISE:Process based E-Commerce.IEEE Data Engineering Bulletin, Special Issue onInfrastructure for Advanced E-Services, 24(1):46–51, March 2001.

[107] Jerrold S. Leichter. Shared Tuple Memories, Shared Memories, Buses andLANs-Linda Implementation Across the Spectrum of connectivity. PhD thesis,Yale University, New Haven, CT, USA, July 1989.

[108] Frank Leymann. Web Services Flow Language (WSFL). http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

[109] Frank Leymann and D. Roller.Production Workflow: Concepts and Techniques.Prentice Hall, Upper Saddle River, NJ, USA, 2000.

[110] Pu Liu and Michael J. Lewis. Mobile Code Enabled Web Services. InProc. ofIEEE International Conference on Web Services (ICWS’05), Orlando FL, USA,July 2005.

[111] Leonidas Lymberopoulos, Emil Lupu, and Morris Sloman. An Adaptive Policy-Based Framework for Network Services Management.Journal of Network andSystems Management, 11(3):277–303, 2003.

[112] Zakaria Maamar, Quan Z. Sheng, and Boualem Benatallah. Interleaving WebServices Composition and Execution Using Software Agents and Delegation. InProc. of AAMAS’03 Workshop on Web Services and Agent-based Engineering,Melbourne, Australia, 2003.

[113] Zakaria Maamar, Quan Z. Sheng, and Boualem Benatallah. On Composite WebServices Provisioning in an Environment of Fixed and MobileComputing Re-sources. Information Technology and Management Journal, Special Issue onWorkflow and e-Business, Kluwer Academic Publishers, 5(3-4):251–270, 2004.

[114] Zakaria Maamar, Quan Z. Sheng, Boualem Benatallah, and Ghazi Alkhatib. AThree-Level Specification Approach for an Environment of Software Agentsand Web Services.Electronic Commerce Research and Applications, 3(3):214–231, 2004.

[115] Cecilia Mascolo, Licia Capra, and Wolfgang Emmerich. Mobile ComputingMiddleware (A Survey). InAdvanced Lectures on Networking (NETWORK-ING’02), Pisa, Italy, May 2002.

[116] Sheila A. McIlraith, Tran Cao Son, and Honglei Zeng. Semantic Web Services.IEEE Intelligent Systems, 16(2):46–53, March 2001.

http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

BIBLIOGRAPHY 197

[117] Brahim Medjahed.Semantic Web Enabled Composition of Web Services. PhDthesis, Virginia Polytechnic Institute and State University, Falls Church, Vir-ginia, USA, 2004.

[118] Brahim Medjahed, Athman Bouguettaya, and Ahmed K. Elmagarmid. Com-posing Web Services on the Semantic Web.The VLDB Journal, 12(4):333–351,2003.

[119] Alan Messer, Ira Greenberg, Philippe Bernadat, Dejan S. Milojicic, DeqingChen, Thomas J. Giuli, and Xiaohui Gu. Towards a Distributed Platform forResource-Constrained Devices. InProc. of the 22nd International Conferenceon Distributed Computing Systems (ICDCS’02), Vienna, Austria, July 2002.

[120] Microsoft and Vodafone. Mobile Web Services Technical Roadmap.http://www.microsoft.com/serviceproviders/resources/bizresmwsroadmap.mspx.Date visited: June 10, 2005.

[121] Nikola Milanovic and Miroslaw Malek. Current Solutions for Web ServiceComposition.IEEE Internet Computing, 8(6):51–59, November 2004.

[122] C. Mohan. A Survey and Critique of Advanced Transaction Models. InProc.of the ACM International Conference on Management of Data (SIGMOD’94),page 521, Minneapolis, Minnesota, USA, 1994.

[123] Rebecca Montanari, Emil Lupu, and Cesare Stefanelli. Policy-Based DynamicReconfiguration of Mobile-Code Applications.IEEE Computer, 37(7):73–80,2004.

[124] µCode. http://mucode.sourceforge.net/.

[125] Tadao Murata. Petri Nets: Properties, Analysis, and Applications.Proceedingsof the IEEE, 77(4):541–580, 1989.

[126] Amy L. Murphy, Gian P. Picco, and Gruia-Catalin Roman. LIME: A Mid-dleware for Physical and Logical Mobility. InProc. of the 21st InternationalConference on Distributed Computing Systems (ICDCS’01), Mesa, AZ, April2001.

[127] Peter Muth, Drik Wodtke, Jeanine Weissenfels, Angelika K. Dittrich, and Ger-hard Weikum. From Centralized Workflow Specification to Distributed Work-flow Execution.Journal of Intelligent Information Systems, 10(2), March 1998.

[128] Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, and Ronald Monzillo.Web Services Security: SOAP Message Security 1.0. http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-mesage-security-1.0.pdf.

http://www.microsoft.com/serviceproviders/resources/bizresmwsroadmap.mspx

http://mucode.sourceforge.net

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-mesage-security-1.0.pdf



BIBLIOGRAPHY 198

[129] Jakob Nielsen. The Usability Engineering Life Cycle.IEEE Computer,25(3):12–22, 1992.

[130] Marian H. Nodine, William Bohrer, and Anne H. H. Ngu. Semantic BrokeringOver Dynamic Heterogeneous Data Sources in InfoSleuth. InProc. of the IEEEInternational Conference on Data Engineering (ICDE’99), Sydney, Australia,March 1999.

[131] Marian H. Nodine, Anne H. H. Ngu, Anthony R. Cassandra, and WilliamBohrer. Scalable Semantic Brokering over Dynamic Heterogeneous DataSources in InfoSleuthTM. IEEE Transactions on Knowledge and Data En-gineering, 15(5):1082–1098, 2003.

[132] Peter B. O’Kelly. B2B Content and Process Integration.http://www.psgroup.com/, November 2000.

[133] Massimo Paolucci, Onn Shehory, and Katia Sycara. Interleaving Planningand Execution in a Multiagent Team Planning Environment. Technical ReportCMU-RI-TR-00-01, Robotics Institute, Carnegie Mellon University, January2000.

[134] Mike P. Papazoglou and Dimitrios Georgakopoulos (Eds.). Special issue onService-Oriented Computing.Communications of the ACM, 46(10):24–89,2003.

[135] Norman W. Paton and Oscar Dıaz. Active Database Systems.ACM ComputingSurveys, 31(1):63–103, 1999.

[136] Cesare Pautasso and Gustavo Alonso. JOpera: A Toolkit for Efficient VisualComposition of Web Services.International Journal of Electronic Commerce,9(2):107–141, Winter 2004-5.

[137] Arjan J.H. Peddemors, Marc M. Lankhorst, and Johan de Heer. Presence,Location, and Instant Messaging in a Context-Aware Application Framework.In Proc. of the 4th International Conference on Mobile Data Management(MDM’03), Melbourne, Australia, 2003.

[138] Chris Peltz. Web Services Orchestration and Choroegraphy. IEEE Computer,36(10):46–52, 2003.

[139] Giacomo Piccinelli, Giuliano Di Vitantonio, and Leonid Mokrushin. DynamicService Aggregation in Electronic Marketplaces.Computer Networks Journal,Special Issue on Electronic Business Systems, 37(2):95–109, 2001.

http://www

BIBLIOGRAPHY 199

[140] Shankar R. Ponnekanti and Armando Fox. SWORD: A Developer Toolkit forWeb Service Composition. InProc. of the 11th International World Wide WebConference, Honolulu, USA, May 2002.

[141] R. Ramakumar. Engineering Reliability: Fundamentals and Applications.Prentice Hall, 1996.

[142] Stephanie Riche and Gavin Brebner. Storing and Accessing User Context.In Proc. of the 4th International Conference on Mobile Data Management(MDM’03), Melbourne, Australia, 2003.

[143] Doug Riecken. Personalized Views of Personalization.Communications of TheACM, 43(8):27–28, 2000.

[144] Manuel Roman, Christopher Hess, Renato Cerqueira, Anand Ranganathan,Roy H. Campbell, and Klara Nahrstedt. A Middleware Infrastructure for ActiveSpaces.IEEE Pervasive Computing, 1(4):74–83, October 2002.

[145] Daniel Salber, Anind K. Dey, and Gregory D. Abowd. The Context Toolkit:Aiding the Development of Context-Enabled Applications. InProc. of the Con-ference on Human Factors in Computing Systems (CHI’99), Pittsburgh, PA,USA, May 1999.

[146] Bill Schilit and Marvin Theimer. Disseminating ActiveMap Information toMobile Hosts.IEEE Network, 8(5):22–32, 1994.

[147] Jean Scholtz and Sunny Consolvo. Toward a Framework forEvaluatingUbiquitous Computing Applications.IEEE Pervasive Computing, 3(2):82–88,April/June 2004.

[148] Christoph Schuler, Roger Weber, Heiko Schuldt, and Hans-Jorg Schek. Peer-to-Peer Process Execution with Osiris. InProc. of the First International Con-ference on Service-Oriented Computing (ICSOC’03), pages 483–498, Trento,Italy, December 2003.

[149] Hans Schuster, Dimitrios Georgakopoulos, Andrzej Cichocki, and DonaldBaker. Modeling and Composing Service-Based and Reference Process-BasedMulti-enterprise Processes. InProc. of the 12th International Conferenceon Advanced Information Systems Engineering (CAiSE’00), Stockholm, June2000.

[150] Quan Z. Sheng and Boualem Benatallah. ContextUML: A UML-Based Mod-eling Language for Model-Driven Context-Aware Web Service Development.In Proc. of the 4th International Conference on Mobile Business(ICMB’05),Sydney, Australia, July 2005.

BIBLIOGRAPHY 200

[151] Quan Z. Sheng, Boualem Benatallah, Marlon Dumas, and Eileen Mak. SELF-SERV: A Platform for Rapid Composition of Web Services in a Peer-to-PeerEnvironment. InProc. of the 28th International Conference on Very LargeDatabases (VLDB’02), Hong Kong, China, August 2002.

[152] Quan Z. Sheng, Boualem Benatallah, Zakaria Maamar, Marlon Dumas, andAnne H.H. Ngu. Enabling Personalized Composition and Adaptive Provision-ing of Web Services. InProc. of the 16th International Conference on AdvancedInformation Systems Engineering (CAiSE’04), Riga, Latvia, June 2004.

[153] Quan Z. Sheng, Boualem Benatallah, Zakaria Maamar, and Kerry Taylor. Per-sonalized and Adaptive Provisioning of Composite Web Services.ACM Trans-actions on the Web (TWEB), 2006, submitted.

[154] Quan Z. Sheng, Boualem Benatallah, Rayan Stephan, EileenMak, and Yan Q.Zhu. Discovering E-Services Using UDDI in SELF-SERV. InProc. of theInternational Conference on E-Business, Beijing, China, May 2002.

[155] Simple Object Access Protocol (SOAP). http://www.w3.org/TR/SOAP.

[156] Evren Sirin, James A. Hendler, and Bijan Parsia. Semi-Automatic Compositionof Web Services using Semantic Descriptions. InProc. of the 1st Workshopon Web Services: Modeling, Architecture and Infrastructure (WSMAI’03), Inconjunction with ICEIS 2003, pages 17–24, Angers, France, April 2003.

[157] David Skogan, Roy Gronmo, and Ida Solheim. Web Service Composition inUML. In Proc. of the 8th International IEEE Enterprise DistributedObjectComputing Conference (EDOC’04), California, USA, September 2004.

[158] Halvard Skogsrud, Boualem Benatallah, and Fabio Casati.Model-Driven TrustNegotiation for Web Services.IEEE Internet Computing, 7(6):45–52, Novem-ber/December 2003.

[159] Web Service Reliability Specification.http://sunonedev.sun.com/platform/technologies/ws-reliability.v1.0.pdf.

[160] SQLData. Simple Object Access Protocol. http://www.soapclient.com.

[161] Markus Stolze and Michael Strobel. Utility-based Decision Tree Optimization:A Framework for Adaptive Interviewing. InProc. of the 8th International Con-ference on User Modeling (UM’01), Sonthofen, Germany, July 2001.

[162] Sun Microsystems Inc. The Java Language: An Overview.http://java.sun.com/docs/overviews/java/java-overview-1.html.

http://www.w3.org/TR/SOAP

http://sunonedev.sun.com

http://www.soapclient.com

http://java

BIBLIOGRAPHY 201

[163] SWWS Consortium. Semantic Web Enabled Web Services.http://swws.semanticweb.org/public_doc/D3.1.pdf.

[164] Katia Sycara, Matthias Klusch, Seth Widoff, and Jianguo Lu. Dynamic Ser-vice Matchmaking Among Agents in Open Information Environments. ACMSIGMOD Record, 28(1):47–53, 1999.

[165] Satish Thatte. XLANG: Web Services for Business Process Design.http://www.ebpml.org/xlang.htm.

[166] The OWL Service Coalition. OWL-S: Semantic Markup of Web Services.http://www.daml.org/services/owl-s/1.0/.

[167] The Unified Modeling Language (UML) Version 1.5.http://www.omg.org/technology/documents/formal/uml.htm.

[168] Doug Tidwell. Web Services: The Web’s Next Revolution.http://www-106.ibm.com/developerworks/edu/ws-dw-wsbasics-i.html.

[169] Paolo Traverso and Marco Pistore. Automated Composition of Semantic WebServices into Executable Processes. InProc. of the Third International Seman-tic Web Conference (ISWS’04), Hirashima, Japan, November 2004.

[170] Jeffrey D. Ullman and Jennifer Widom.A First Course in Database Systems.Prentice-Hall, 1997.

[171] Universal Mobile Telecommunication System.http://www.elantelco.com/what_is_umts.html.

[172] Debra VanderMeer, Anindya Datta, Kaushik Dutta, Helen Thomas, Krithi Ra-mamritham, and Shamkant B. Navathe. FUSION: A System Allowing DynamicWeb Service Composition and Automatic Execution. InProc. of the IEEE In-ternational Conference on E-Commerce(CEC’03), California, USA, June 2003.

[173] Radek Vingralek, Yuri Breitbart, Mehmet Sayal, and Peter Scheuermann.Web++: A System for Fast and Reliable Web Service. InUSENIX AnnualTechnical Conference, General Track, Monterey, CA, USA, June 1999.

[174] Nir Vulkan and Nicholas R. Jennings. Efficient Mechanisms for the Supply ofServices in Multi-Agent Environments.Decision Support Systems, 28(1–2):5–19, 2000.

[175] W3C. The World Wide Web Consortium. http://www13.w3.org/.

[176] Andy Ward, Alan Jones, and Andy Hopper. A New Location Technique for theActive Office. IEEE Personal Communications, 4(5):42–47, 1997.

http://swws

http://www.ebpml.org/xlang.htm

http://www.daml.org/services/owl-s/1.0

http://www.omg

http://www-106.ibm.com/developerworks/edu/ws-dw-wsbasics-i.html

http://www-106.ibm.com/developerworks/edu/ws-dw-wsbasics-i.html

http://www.elantelco

http://www13.w3.org

http://www13.w3.org

http://www13.w3.org

BIBLIOGRAPHY 202

[177] Gerhard Weiss, editor.Multiagent Systems: A Modern Introduction to Dis-tributed Artificial Intelligence. MIT Press, 1999.

[178] Workflow Management Coalition. Terminology & Glossary.http://www.wfmc.org/standards/docs/TC-101_term_glossary_v3.pdf.

[179] Workflow Management Coalition. The Workflow Reference Model.http://www.aiim.org/wfmc/standards/docs/tc003v11.pdf.

[180] Workflow Management Coalition. Workflow Process Definition Interface -XML Process Definition Language (XPDL).http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf, 2002.

[181] Steven Wright, Ritu Chadha, and George Lapiotis editors.Special Issue onPolicy-Based Networking.IEEE Network, 16(2):8–56, 2002.

[182] WSMO Working Group. Web Service Modeling Ontology, DERIWorkingDrafts. http://www.wsmo.org/TR/d2/v1.1/.

[183] P. Wyckoff, S. W. McLaughry, T. J. Lehman, and D. A. Ford. T Spaces.IBMSystems Journal, 37(3):454–474, 1998.

[184] Beverly Yang and Hector Garcia-Molina. Comparing Hybrid Peer-to-Peer Sys-tems. InProc. of 27th Int. Conference on Very Large Data Bases, Roma, Italy,2001.

[185] Jian Yang and Mike P. Papazoglou. Web Component: A Substrate for WebService Reuse and Composition. InProc. of the 14th International Conferenceon Advanced Information Systems Engineering (CAiSE’02), Toronto, Canada,June 2003.

[186] Franco Zambonelli, Nicholas R. Jennings, and Michael Wooldridge. Develop-ing Multiagent Systems: The Gaia Methodology.ACM Transactions on Soft-ware Engineering and Methodology, 12(3):317–370, July 2003.

[187] Liangzhao Zeng, Boualem Benatallah, Marlon Dumas, Jayant Kalagnanam, andQuan Z. Sheng. Quality Driven Web Services Composition. InProc. of the12th International World Wide Web Conference (WWW’03), Budapest, Hungary,May 2003.

http://www

http://www.aiim.org/wfmc/standards/docs/tc003v11.pdf

http://www.wfmc.org

http://www.wsmo.org/TR/d2/v1.1

Appendix A

Curriculum Vitae

Personal Information

Full Name: Quanzheng (Michael) ShengTelephone: +61 2 6216 7097Email: [email protected] Page: http://www.ict.csiro.au/staff/Michael.ShengResidency: Australian citizen

Research Interests

E-Commerce, Internet Computing, Web Services, Business Process Integration, Se-mantic Web, Mobile Web Services, and Databases

Highlights

1. Published more than 20 refereed technical papers in: i) top journals includingThe VLDB Journal, IEEE Internet Computing, DAPD, Information Technolo-gies and Management; and ii) international conferences such as IEEE ICDE’02,VLDB’02, CAiSE’04, ICMB’05.

2. Participated actively in academic activities: i) organizing, or being invited asPC member for, more than 15 international conferences and workshops such asACM SAC’06, IEEE ICPADS’05, WISE’05, ICSOC’05, IEEE WEC’04, and ii)served as an external reviewer for many journals and conferences.

3. Awarded selective and prestigious Microsoft Research Fellowship (2003-2004)due to academic achievements.

4. Advanced programming experience in Java, C++, XML, databases

mailto:[email protected]

http://www.ict.csiro.au/staff/Michael.Sheng

Curriculum Vitae 204

Awards, Honors, Fellowships

2003-2004 Microsoft Research Fellowship, Microsoft Research Asia (MSRA)June 2004 CAiSE 2004 scholarship, partially support the conference attendance2003-2005 Postgraduate scholarship, APA/SEA, UNSW2002-2003 Postgraduate scholarship, CSE IPRS, UNSW1999-2000 CSC Research Fellowship, China Scholarship Council1996-1997 2nd prize of XAC’s Modernization of Management, XAC1995-1996 3rd prize of XAC’s Technical Achievements, XAC1990-1993 Renmin Scholarship (every year), BUAA

Education

2001-2005 Ph.D. in Computer ScienceSchool of Computer Science and EngineeringThe University of New South Wales (UNSW). Sydney, AustraliaDissertation:Composite Web Services Provisioning

in Dynamic EnvironmentsSupervisor: Associate Professor Boualem Benatallah

1989-1993 B.E. in Information SystemsBeihang University (BUAA). Beijing, ChinaFinal rank as top 5

1986-1989 High School DiplomaHuaqing High School. Xi’an, ChinaFinal rank as top 1 from 517

Affiliations

1. Member of IEEE Computer Society, IEEE Communications Society

2. Member of Association for Computing Machinery (ACM)

3. Member of IEEE Service Computing Forum


Research Experience

Nov 2005-present Research scientist at CSIRO ICT CentreWork on various projects in the Information Engineering Laboratory.

Nov 2003-Feb 2004 Intern at Microsoft Research Asia (MSRA)Participated in the research project ProFITS, in charge of seamless pro-visioning of Web services in wireless environments.

Jul 2001- Oct 2005 PhD student at CSE, UNSWWorked on a project for composite Web services provisioning in dy-namic environments. I designed and implemented a prototype systemnamedSelf-Serv. The work was published in several conference papersincluding 28th VLDB’02, 18th IEEE ICDE’02, 16th CAiSE’04, and4th IEEE ICMB’05, together with journal papers including IEEE Inter-net Computing, DAPD journal, and a submission to ACM Transactionson the Web. This work has been frequently cited by other researchers.

Sep 2000-Jun 2001 Visiting Research Fellow at CSE, UNSWTook part in AgFlow (a collaborative project being undertaken betweenUNSW and JustinWin Technologies Pty Ltd, managed by Dr BoualemBenatallah) research prototype implementation. The prototype wasdemonstrated on VLDB’01 in September 2001, Rome, Italy.

Participated in the research project about dynamic workflow adaptationand evolution.

Jul 1999-Jul 2000 Visiting Research Fellow at CSE, UNSWParticipated in the research project CMVF (on multimedia database)managed by Prof. Anne H.H. Ngu. I developed a Web-based prototypeusing C++/C, perl and JAVA. The research work resulted in a publica-tion in VLDB Journal and a demonstration paper in ACM SIGMOD’03.


Industrial Experience

Jan 1996-Jul 1999 Deputy Director at Software Development Group (SDG), ComputerCentre, Xi’an Aircraft Company (XAC), ChinaI managed 8 software engineers in software system development. TheprojectVolvo Bus Parts Purchase and Supply Management Systemwonthe second prize of XAC’s Modernization of Management. I was theteam leader of the project (version 1 and 2).

Sep 1994-Dec 1995 Team Leader at SDG, Computer Center, XACI managed 4 software engineers in software development. The projectAircraft Purchased Parts Management Systemwon the third prize ofXAC’s Technical Achievements in 1995.

Jul 1993-Aug 1994 Programmer at SDG, Computer Center, XACI was a programmer in software development. The project “AircraftCompany Finance Information System” won the 2nd prize of XAC’sModernization of Management in 1995.

Publications

Papers submitted

1. “Personalized and Adaptive Provisioning of Composite Web Services”. Quan Z. Sheng,Boualem Benatallah, Zakaria Maamar, and Manoj Chandra. ACM Transactions on theWeb, 2006 (submitted).

Refereed book chapters

2. “Configurable QoS Computation and Policing in Dynamic Web Service Selection”.Anne H.H. Ngu, Yintong Liu, Liangzhao Zeng, andQuan Z. Sheng. In Service Ori-ented Computing, Dimitrios Geograkopoulos and Mike Papazoglou (Ed). MITPress, toappear.

3. “Agent-Based Support for Service Composition”. Zakaria Maamar,Quan Z. Sheng,and Boualem Benatallah. In Extending Web Services Technologies: the Use of Multi-Agent Approaches, L. Cavedon, et.al. (Ed)., Springer, 2005.


Refereed journal and conference publications

4. “ContextUML: A UML-Based Modeling Language for Model-Driven Context-AwareWeb Services Development”.Quan Z. Sheng, and Boualem Benatallah. In Proc. of The4th International Conference on Mobile Business (ICMB’05), IEEE Computer Society.11-13 July 2005, Sydney, Australia.

5. “Facilitating the Rapid Development and Scalable Orchestration of CompositeWeb Ser-vices”. Boualem Benatallah, Marlon Dumas,Quan Z. Sheng. Distributed and ParallelDatabases, An International Journal, Kluwer Academic Publishers, Vol17 No 1, pp5-37,January, 2005. (8 citations according scholar.google.com1)

6. “Enabling Personalized Composition and Adaptive Provisioning of Web Services”.QuanZ. Sheng, Boualem Benatallah, Zakaria Maamar, Marlon Dumas, Anne H.H. Ngu. InProc. of the 16th International Conference on Advanced Information Systems Engi-neering (CAiSE’04), 7-11 June 2004, Riga, Latvia. (acceptance ratio: 21%) (5 citationsaccording scholar.google.com)

7. “Towards an Approach for Coordinating Personalized Composite Services in an Envi-ronment of Mobile Users”. Zakaria Maamar,Quan Z. Sheng, Boualem Benatallah.In Proc. of Ubiquitous Mobile Information and Collaboration Systems (UMICS2004),Lectures Notes in Computer Science (LNCS 3272), Held in conjunction with CAiSE’04.7-8 June 2004, Riga, Latvia.

8. “Towards a Conversation-driven Composition of Web Services”. Zakaria Maamar,QuanZ. Sheng, Boualem Benatallah. Web Intelligence and Agent Systems: An InternationalJournal (WIAS), IOS Press, ISSN 1570-1263, Vol 2(2), 2004.

9. “On Composite Web Services Provisioning in an Environment of Fixed andMobileComputing Resources”, Zakaria Maamar,Quan Z. Sheng, Boualem Benatallah. In-formation Technology and Management, Kluwer Academic Publishers, Vol 5, No 3-4,2004. (19 citations according scholar.google.com)

10. “A Three-Level Specification Approach for an Environment of Software Agents andWeb Services”. Zakaria Maamar,Quan Z. Sheng, Boualem Benatallah, and GhaziAlkhatib. Electronic Commerce Research and Applications Journal, ElsevierSciencePublisher, Vol 3 No 3, pp 214-231, 2004.

11. “The Self-Serv Environment for Web Services Composition”, Boualem Benatallah,QuanZ. Sheng, Marlon Dumas. IEEE Internet Computing, Vol 7, No 1, pp 40-48, Jan/FebIssue, 2003. IEEE Computer Society. (133 citations according scholar.google.com)

1The citation information was collected in March 2006.


12. “Quality Driven Web Service Composition”, Liangzhao Zeng, BoualemBenatallah,Marlon Duams, Jayant Kalagnanam,Quan Z. Sheng, In Proc. of the 12th InternationalWorld Wide Web Conference (WWW2003), 20-24 May 2003, Budapest,Hungary. (ac-ceptance ratio: 14%) (122 citations according scholar.google.com)

13. “CMVF: A Novel Dimension Reduction Scheme for Efficient Indexing inA Large Im-age Database”, Demonstration paper, Jialie Shen, Anne H.H. Ngu, John Shepherd, DuQ. Huynh,Quan Z. Sheng. In Proc. of ACM SIGMOD Conference, June 9-12, 2003,San Diego, California, USA

14. “Selection of Web Services for Composition Using Location of ProviderHosts Crite-rion”, Zakaria Maamar,Quan Z. Sheng, Boualem Benatallah. In Proc. of UbiquitousMobile Information and Collaboration Systems (UMICS 2003), Held in conjunctionwith CAiSE’03. 16-17 June 2003, Austria

15. “An Adaptive Document Version Management Scheme”, Boualem Benatallah, Mehre-gan Mahdavi, Phuong Nguyen,Quan Z. Sheng, Lionel Port, Bill McIver. In Proc.of the 15th International Conference on Advanced Information Systems Engineering(CAiSE’03), 16-20 June 2003, Austria. (acceptance ratio: 21%)

16. “Interleaving Web Services Composition and Execution Using SoftwareAgents andDelegation”, Zakaria Maamar,Quan Z. Sheng, Boualem Benatallah. In Proc of AA-MAS’03 Workshop on Web Services and Agent-based Engineering, 14-15 July 2003,Melbourne, Australia. (13 citations according scholar.google.com)

17. “Overview of Some Patterns for Building and Managing Composite Web Services”,Boualem Benatallah, Marlon Duams, Fethi Rabhi, Marie Fauvet,Quan Z. Sheng. ACMSIGecom Exchanges, Vol 3, No 3, pp 9-18, August 2002, ACM Press. (26 citationsaccording scholar.google.com)

18. “SELF-SERV: A Platform for Rapid Composition of Web Services in a Peer-to-Peer En-vironment”,Quan Z. Sheng, Boualem Benatallah, Marlon Dumas, Eileen Oi-Yan Mak.In Proc. of the 28th International Conference on Very Large Data Bases (VLDB’02),August 20-23, 2002, Hong Kong, China. (53 citations according scholar.google.com)

19. “A Unified Framework for Composing E-/M-Services”, Zakaria Maamar, Boualem Be-natallah,Quan Z. Sheng, In Proc. of the First International Workshop on M- services:Concepts, Approaches, Tools, 26 June 2002, Lyon France.

20. “Declarative Composition and Peer-to-Peer Provisioning of Dynamic Web Services”,Boualem Benatallah, Marlon Dumas,Quan Z. Sheng, Anne H.H. Ngu. In Proc. of the18th IEEE International Conference on Data Engineering 2002 (ICDE’02), pp 297-308,


San Jose, California, USA, Feb, 2002. (acceptance ratio: 18%) (124citations accordingscholar.google.com)

21. “Discovering E-Services Using UDDI in SELF-SERV”,Quan Z. Sheng, Boualem Be-natallah, Rayan Stephan, Eileen Oi-Yan Mak. In Proc. of International Conferenceon E-Business (ICEB2002), May 23-26, 2002, Beijing China. (6 citations accordingscholar.google.com)

22. “Towards a Composition Framework for E-/M-Services”, Zakaria Maamar, BoualemBenatallah,Quan Z. Sheng. In Proc. of Workshop on Ubiquitous Agents on Embed-ded, Wearable, and Mobile Devices (ACM), 16 July 2002, Bologna, Italy. (8 citationsaccording scholar.google.com)

23. “Study on Image Processing for Video-Based Traffic Measurement and Vehicle Classi-fication”, Yan Q. Zhu andQuan Z. Sheng. Road & Transport Research, Vol 11, No 2,pp 42-49, June 2002. ARRB TR.

24. “Combining Multi-Visual Features for Efficient Indexing in A Large Image Database”,Anne H.H. Ngu,Quan Z. Sheng, Du Q. Huynh and Ron Lei. Very Large Data BaseJournal (VLDB Journal), Vol 9, No 4, pp 279-293, March 2001. Springer Verlag. (11citations according scholar.google.com)

Formal Presentations

1. Conference talk at ICMB’05, “ContextUML: A UML-Based Modeling Language forModel-Driven Context-Aware Web Services Development”, 11 July 2005, Sydney, Aus-tralia

2. Conference talk at CAiSE’04, “Enabling Personalized Composition andAdaptive Pro-visioning of Web Services”, 10 June 2004, Riga Latvia.

3. Conference talk at UMICS’04, “Coordination of Personalized Composite Web Ser-vices”, 8 June 2004, Riga Latvia

4. Invited talk at Microsoft Research Asia (MSRA), “Web Service Provisioning in Dy-namic Environments”, 12 December 2003, MSRA, Beijing, China

5. Conference talk at AAMAS’03 Workshop, “Interleaving Web Services Composition andExecution Using Software Agents and Delegation”, 14 July 2003, Melbourne, Australia

6. Software Demonstration at 28th VLDB’02 Conference, “SELF-SERV: A Platform forRapid Composition of Web Services in a Peer-to-Peer Environment”, August 20-23,Hong Kong, China


Professional Services

1. Program Committee Member, The 21st Annual ACM Symposium on Applied Comput-ing (SAC’06), Handheld Computing Track, Dijon, France, April 23-27,2006

2. Program Committee Member, The 2nd IEEE International Workshop on Web and Mo-bile Information Systems (WAMIS’06), with 20th IEEE AINA’06, Vienna, Austria,April 18, 2006

3. Publicity Co-Chair, The 3rd International Conference on Service-Oriented Computing(ICSOC’05), Amsterdam, The Netherlands, December 12-15, 2005

4. Session Chair, on “Architectural and Modeling Issues”, The 4th International Confer-ence on Mobile Business (ICMB’05), Sydney, Australia, July 11-13, 2005

5. Program Committee Member, The 6th International Conference on Web InformationSystems and Engineering (WISE’05), New York, USA, November 20-22, 2005

6. Program Committee Member, The 11th IEEE International Conference onParallel andDistributed Systems (ICPADS’05), July 20-22, 2005, Fukuoka, Japan

7. Program Committee Member, The Service-Oriented Computing and Agent-based En-gineering Workshop (SOCABE’05), with AAMAS05, July 25-26, 2005,Utrecht, TheNetherlands.

8. Program Committee Member, IEEE International Conference on e-Technology, e- Com-merce, and e-Service (EEE’05), 29 March 1 April 2005, Hong Kong,China.

9. Program Committee Member, International Workshop on Context for WebServices(CWS’05), in conjunction with Context’05, July 5, 2005, Paris, France.

10. Program Committee Member, 2nd International Workshop on Ubiquitous Computing,May 24-25, 2005, Miami, USA

11. PC member, 4th International Workshop on Wireless Information Systems(WIS 2005),May 24-25, 2005, Miami, USA

12. Publicity co-chair, the 1st IEEE international workshop on electroniccontracting (WEC),July 6, 2004, San Diego, USA

13. Program Committee Member, 2nd Workshop on Web Services and Agent-based Engi-neering, with AAMAS’04. July 19, 2004, New York, USA.

14. Program Committee Member, Workshop on Handheld Computing, held as part of ISICT’04,June 16 - 18, 2004, Las Vegas, USA


15. Program Committee Member, the 3rd International Workshop on WirelessInformationSystems (WIS), April 13-14 2004, Porto, Portugal

16. Program Committee Member, International Workshop on Ubiquitous Computing, inconjunction with ICEIS’04, April 13-14, 2004, Porto, Portugal

17. Program Committee Member, 1st Workshop on Web Services and Agent-based Engi-neering, July 14 2003, Melbourne, Australia

18. Program Committee Member, the 2nd International Workshop on M-Services, in con-junction with ISMIS’03, October 2003, Meabashi, Japan

19. External reviewer for i) journals like IEEE Transactions on Systems,Man, and Cyber-netics (special issue on M-Services), IEEE Transactions on Knowledge and Data Engi-neering, Distributed and Parallel Databases, WWW Journal, IEEE Internet Computing,VLDB Journal, IJCIS, and ii) international conferences such as ICDE’03, ICWS’03,ADC’03, CooPIS’02, CAiSE’03, TES’02, TES’03, SAC’04, EDBT’04, BPM’04, CCC-T’04, IFIP MOBIS’04, VLDB TES’04, WISE2004, CooPIS04, PDCN2005, iCITA’05,SISC’05, ICWS’05, CCCT’05, WAIM’05, BPM’05, ICDE’06, VLDB’06

Teaching Experience

2002-2005 Tutor/Demonstrator/Mentor fore-Commerce System Implementation

2002 Tutor forDatabase Systems

2003 Honours thesis supervisionDaniel Paik (Bachelor of Software Engineering)Thesis:Personal Web Services

2003 Honours thesis supervisionSiu Kit Raymond Lui (Bachelor of Engineering)Thesis:Web services Composition in Hybrid Environments

2004 Honours thesis supervisionManoj Chandra (Bachelor of Software Engineering)Thesis:An Execution Environment for Personalized Composite Services

2004 Honours thesis supervisionJosephine Petrina Kotjik (Bachelor of Engineering)Thesis:Research Group Portal: Design and Implementation


Skills

1. Proficient in B2B interoperability and E-Commerce standards (UDDI, SOAP, WSDL,RosettaNet, EDI, WSFL, BPEL), Service oriented architecture

2. Familiar with UML and model driven approach.

3. Languages: proficient in C++, C, JAVA, Oracle Developer 2000, PL/SQL, HTML,XML; familiar with Cobol, Pascal, Fortran and Basic.

4. Databases: Oracle, Visual Foxpro, Foxbase, dBaseIV, DB2.

5. Operating systems: familiar with UNIX, Windows NT, Windows95/98, Novell

composite web services provisioning in dynamic environments

Documents