Composite Web Services Provisioning in Dynamic Environments
Transcript of 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.
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-
Chapter 1. Introduction 3
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].
Chapter 1. Introduction 4
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,
Chapter 1. Introduction 5
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
Chapter 1. Introduction 6
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
Composing Services for SR2
Composing Services for SR3
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
Chapter 1. Introduction 7
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:
Chapter 1. Introduction 8
• 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
Chapter 1. Introduction 9
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-
Chapter 1. Introduction 10
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-
Chapter 1. Introduction 11
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-
Chapter 1. Introduction 12
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
Chapter 1. Introduction 13
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
Chapter 2. Background 17
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-
Chapter 2. Background 18
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
Chapter 2. Background 19
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
Chapter 2. Background 20
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-
Chapter 2. Background 21
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-
Chapter 2. Background 22
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
Chapter 2. Background 23
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
Chapter 2. Background 24
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.
Chapter 2. Background 25
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.
Chapter 2. Background 26
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].
Chapter 2. Background 27
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.
Chapter 2. Background 28
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).
Chapter 2. Background 29
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
Chapter 2. Background 30
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
Chapter 2. Background 31
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
Chapter 2. Background 32
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
Chapter 2. Background 33
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
Chapter 2. Background 34
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.
Chapter 2. Background 35
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.
Chapter 2. Background 36
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.
Chapter 2. Background 37
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
Chapter 2. Background 38
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.
Chapter 2. Background 39
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
Chapter 2. Background 40
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.
Chapter 2. Background 41
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
Chapter 2. Background 42
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
Chapter 2. Background 43
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
Chapter 3. Personalized and Adaptive Composition Model 47
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.
Chapter 3. Personalized and Adaptive Composition Model 48
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-
Chapter 3. Personalized and Adaptive Composition Model 49
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
Chapter 3. Personalized and Adaptive Composition Model 50
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
Chapter 3. Personalized and Adaptive Composition Model 51
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
Chapter 3. Personalized and Adaptive Composition Model 52
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].
Chapter 3. Personalized and Adaptive Composition Model 53
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
Chapter 3. Personalized and Adaptive Composition Model 54
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.
Chapter 3. Personalized and Adaptive Composition Model 55
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
Chapter 3. Personalized and Adaptive Composition Model 56
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
Chapter 3. Personalized and Adaptive Composition Model 57
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
Chapter 3. Personalized and Adaptive Composition Model 58
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
Chapter 3. Personalized and Adaptive Composition Model 59
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.
Chapter 3. Personalized and Adaptive Composition Model 60
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
Chapter 3. Personalized and Adaptive Composition Model 61
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
Chapter 3. Personalized and Adaptive Composition Model 62
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.
Chapter 3. Personalized and Adaptive Composition Model 63
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);
Chapter 3. Personalized and Adaptive Composition Model 64
• 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.
Chapter 3. Personalized and Adaptive Composition Model 65
• 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
Chapter 3. Personalized and Adaptive Composition Model 66
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
Chapter 3. Personalized and Adaptive Composition Model 67
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
Chapter 3. Personalized and Adaptive Composition Model 68
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)
Chapter 3. Personalized and Adaptive Composition Model 69
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
Chapter 3. Personalized and Adaptive Composition Model 70
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.
Chapter 3. Personalized and Adaptive Composition Model 71
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].
Chapter 3. Personalized and Adaptive Composition Model 72
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.
Chapter 3. Personalized and Adaptive Composition Model 73
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-
Chapter 3. Personalized and Adaptive Composition Model 74
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.
Chapter 3. Personalized and Adaptive Composition Model 75
• 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).
Chapter 3. Personalized and Adaptive Composition Model 76
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
Chapter 3. Personalized and Adaptive Composition Model 77
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
Chapter 3. Personalized and Adaptive Composition Model 78
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
Chapter 3. Personalized and Adaptive Composition Model 79
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-
Chapter 3. Personalized and Adaptive Composition Model 80
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
Chapter 4. Tuple Space-Driven Service Orchestration 83
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.
Chapter 4. Tuple Space-Driven Service Orchestration 84
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.
Chapter 4. Tuple Space-Driven Service Orchestration 85
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.
Chapter 4. Tuple Space-Driven Service Orchestration 86
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-
Chapter 4. Tuple Space-Driven Service Orchestration 87
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
Chapter 4. Tuple Space-Driven Service Orchestration 88
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
Chapter 4. Tuple Space-Driven Service Orchestration 89
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
Chapter 4. Tuple Space-Driven Service Orchestration 90
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]
Chapter 4. Tuple Space-Driven Service Orchestration 91
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.
Chapter 4. Tuple Space-Driven Service Orchestration 92
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).
Chapter 4. Tuple Space-Driven Service Orchestration 93
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
Chapter 4. Tuple Space-Driven Service Orchestration 94
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.
Chapter 4. Tuple Space-Driven Service Orchestration 95
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.
Chapter 4. Tuple Space-Driven Service Orchestration 96
• 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.
Chapter 4. Tuple Space-Driven Service Orchestration 97
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.
Chapter 4. Tuple Space-Driven Service Orchestration 98
• 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-
Chapter 4. Tuple Space-Driven Service Orchestration 99
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.
Chapter 4. Tuple Space-Driven Service Orchestration 100
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
Chapter 4. Tuple Space-Driven Service Orchestration 101
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
Chapter 4. Tuple Space-Driven Service Orchestration 102
{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
Chapter 4. Tuple Space-Driven Service Orchestration 103
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
Chapter 4. Tuple Space-Driven Service Orchestration 104
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.
Chapter 4. Tuple Space-Driven Service Orchestration 105
• 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
Chapter 4. Tuple Space-Driven Service Orchestration 106
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.
Chapter 4. Tuple Space-Driven Service Orchestration 107
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
Chapter 4. Tuple Space-Driven Service Orchestration 108
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.
Chapter 4. Tuple Space-Driven Service Orchestration 109
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.
Chapter 4. Tuple Space-Driven Service Orchestration 110
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
Chapter 4. Tuple Space-Driven Service Orchestration 111
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
Chapter 4. Tuple Space-Driven Service Orchestration 112
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.
Chapter 4. Tuple Space-Driven Service Orchestration 113
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
Chapter 4. Tuple Space-Driven Service Orchestration 114
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/.
Chapter 4. Tuple Space-Driven Service Orchestration 115
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
Chapter 4. Tuple Space-Driven Service Orchestration 116
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
Chapter 5. Robust Web Services Provisioning 119
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
Chapter 5. Robust Web Services Provisioning 120
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.
Chapter 5. Robust Web Services Provisioning 121
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.,
Chapter 5. Robust Web Services Provisioning 122
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
Chapter 5. Robust Web Services Provisioning 123
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.
Chapter 5. Robust Web Services Provisioning 124
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
Chapter 5. Robust Web Services Provisioning 125
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-
Chapter 5. Robust Web Services Provisioning 126
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.
Chapter 5. Robust Web Services Provisioning 127
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
Chapter 5. Robust Web Services Provisioning 128
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
Chapter 5. Robust Web Services Provisioning 129
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
Chapter 5. Robust Web Services Provisioning 130
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
Chapter 5. Robust Web Services Provisioning 131
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
Chapter 5. Robust Web Services Provisioning 132
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.
Chapter 5. Robust Web Services Provisioning 133
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.
Chapter 5. Robust Web Services Provisioning 134
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:
Chapter 5. Robust Web Services Provisioning 135
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.
Chapter 5. Robust Web Services Provisioning 136
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
Chapter 5. Robust Web Services Provisioning 137
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).
Chapter 5. Robust Web Services Provisioning 138
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
Chapter 5. Robust Web Services Provisioning 139
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-
Chapter 5. Robust Web Services Provisioning 140
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
Chapter 5. Robust Web Services Provisioning 141
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
Chapter 5. Robust Web Services Provisioning 142
(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.
Chapter 5. Robust Web Services Provisioning 143
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.
Chapter 5. Robust Web Services Provisioning 144
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-
Chapter 5. Robust Web Services Provisioning 145
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
Chapter 5. Robust Web Services Provisioning 146
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
Chapter 5. Robust Web Services Provisioning 147
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-
Chapter 5. Robust Web Services Provisioning 148
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
Chapter 6. Implementation and Performance Study 151
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-
Chapter 6. Implementation and Performance Study 152
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
Chapter 6. Implementation and Performance Study 153
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.
Chapter 6. Implementation and Performance Study 154
<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
Chapter 6. Implementation and Performance Study 155
<?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-
Chapter 6. Implementation and Performance Study 156
<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
Chapter 6. Implementation and Performance Study 157
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
Chapter 6. Implementation and Performance Study 158
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
Chapter 6. Implementation and Performance Study 159
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,
Chapter 6. Implementation and Performance Study 160
• 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.
Chapter 6. Implementation and Performance Study 161
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
Chapter 6. Implementation and Performance Study 162
(a) Specifying composite services
(b) Discovering component services
Figure 6.2: Defining services in Self-Serv
Chapter 6. Implementation and Performance Study 163
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).
Chapter 6. Implementation and Performance Study 164
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
Chapter 6. Implementation and Performance Study 165
(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
Chapter 6. Implementation and Performance Study 166
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.
Chapter 6. Implementation and Performance Study 167
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).
Chapter 6. Implementation and Performance Study 168
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
Chapter 6. Implementation and Performance Study 169
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
Chapter 6. Implementation and Performance Study 170
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.
Chapter 6. Implementation and Performance Study 171
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.
Chapter 6. Implementation and Performance Study 172
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.
Chapter 6. Implementation and Performance Study 173
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].
Chapter 6. Implementation and Performance Study 174
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
Distributed Centralized
(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.
Chapter 6. Implementation and Performance Study 175
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,
Chapter 6. Implementation and Performance Study 176
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)
Distributed Centralized
(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)
Distributed Centralized
(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.
Chapter 6. Implementation and Performance Study 177
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
Chapter 6. Implementation and Performance Study 178
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
Chapter 6. Implementation and Performance Study 179
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
Chapter 6. Implementation and Performance Study 180
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,
Chapter 7. Conclusions 183
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
Chapter 7. Conclusions 184
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-
Chapter 7. Conclusions 185
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
Chapter 7. Conclusions 186
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
Curriculum Vitae 205
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.
Curriculum Vitae 206
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.
Curriculum Vitae 207
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.
Curriculum Vitae 208
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,
Curriculum Vitae 209
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
Curriculum Vitae 210
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
Curriculum Vitae 211
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
Curriculum Vitae 212
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