Minh Tuan Nguyen Thesis

Feature-based Composition and Delivery
of Customisable Web Services

Minh Tuan Nguyen

Submitted in fulfillment of the requirements
of the degree of Doctor of Philosophy

Faculty of Information and Communication Technologies
Swinburne University of Technology

2013
i

Abstract

Service variability refers to the existence of multiple service variants which are derived
from the same Web service for use in different business contexts. Supporting service
variability using concepts of conventional Web services causes inefficiency in service
description, publication, and consumption. In this thesis, we propose the concept of
customisable Web services and describe a suite of techniques for enabling the develop-
ment, provisioning and consumption of such services.
Enabling the use of customisable services requires a comprehensive approach for the
modeling and the management of service variability. However, individual works in the
related literature only address limited aspects of service variability. In particular, existing
approaches suffer from the following five main problems. Firstly, their customisation
mechanisms are complex and do not enable the customisation of both service interface
and service implementation. Secondly, their customisation procedures enforce tight
coupling between service providers and service consumers. Thirdly, they do not address
the issues related to runtime provisioning of customisable services. Fourthly, those works
that support customisable atomic services lack the consideration of engineering tech-
niques for adapting and provisioning service implementation. Fifthly, those works that
support customisable composite services do not take into account variability dependen-
cies between a customisable composite service and its customisable partner services.
For the first problem, we propose a feature-based service customisation framework
that not only simplifies service customisation by performing such operations at the
requirement level but also enables service customisation at both service interface and
service implementation levels. With respect to the second problem, we propose WSVL
(Web Service Variability description Language) for specifying the customisation proce-
dure and enabling loose coupling between service providers and service consumers. For
the third problem, we describe a service provisioning architecture that extends existing
service platforms to provision customisable services. To address the fourth problem, we
propose engineering techniques for the explicit capturing and instantiation of variability
in service implementation, thus enabling the use of customisable atomic services. And for
the fifth problem, we define techniques for composing customisable services that take
into account variability dependencies with customisable partner services. Altogether, we
define a complete solution for developing, provisioning and consuming both customisable
atomic services and customisable composite services.

ii
To quantitatively evaluate our approach, we have utilised the case study of Amazon
Web Service (AWS). The AWS is a large and complex Web service for AWS customers
to interact with Amazon cloud infrastructure. We have applied our techniques to redesign
the AWS as a customisable service and deploy it on our service provisioning middleware.
Our automated experiments have shown that for light-weight and medium-weight service
customers who do not require many advanced features for the AWS, a significant
efficiency in terms of service consumption and provisioning can be achieved with our
approach.

iii
Declaration

This is to certify that this thesis contains no material which has been accepted for the
award of any other degree or diploma and that to the best of my knowledge this thesis
contains no material previously published or written by another person except where due
reference is made in the text of the thesis. Where the work is based on joint research or
publications, I have disclosed the relative contributions of the respective workers or
authors.

Minh Tuan Nguyen
June 2013
Melbourne

iv
Acknowledgements

My sincere thanks go to my coordinating supervisor Dr Alan Colman. Thank you, Alan
for your enormous support and great supervision, for many hours spent discussing my
work and reviewing my papers/thesis. I really appreciate the freedom you have given me
to explore my idea. Your philosophy of research and biological view of software systems
have been inspiring and helped me a lot in formulating my work. I would also like to
express my deep gratitude to my second supervisor Professor Jun Han who granted my
candidature and scholarship. Jun has always been available whenever I need his com-
ments and thoughts on my work. Jun is a role model of an outstanding researcher from
whom I have learnt a lot. My warm thanks also go to my former colleague Muhammad
Adeel Talib. It is through intensive discussion with Jun, Alan and Adeel that I was
initiated to this thrilling topic of service variability.
Many thanks to the members of the Context Aware Adaptive Architecture Research
(CAAAR) group for creating an inspiring and collaborative environment. Thanks to many
members of the Swinburne University Centre for Computing and Engineering Software
Systems (SUCCESS) research centre (Sira, Saiful, Tan, Huan, to name a few) for being
such good friends. I would also like to express my gratitude to my Vietnamese friends at
Swinburne (Dr Minh Hong Tran, Oai Dai, Dr Bao Vo, to name a few) for helping me
during my candidature. Special thanks go to Smart Services CRC for sponsoring my PhD
candidature and annual travels to exchange with PhD students from other universities.
I would like to thank many domestic and international researchers who I met while
attending conferences. Special thanks must go to Dr Helen Paik, Dr Michael Sheng, Dr
David Benavides, and Dr Matthias Galster for your fruitful and inspirational chats during
conferences. I am especially grateful to Professor Krzysztof Czarnecki and his colleagues
for providing the feature modeling tool which plays an important part in my prototype
system. Acknowledgement is also due to many anonymous reviewers of my papers whose
comments helped to improve this work.
Finally, I want to thank my family (parents, parents-in-law, brothers and sisters) for
their constant love and support. Especially, I would like to express my deepest gratitude
to my wife Thi Lan Anh Phan without whom I could not have reached this long-waiting
moment of my life. Thank you, Lan Anh, for your support, patience, sympathy and
endurance during my surprisingly struggling research life. And thank you, Lan Anh, for
giving birth to our little angel, Ha Duong Nguyen, who, since her birth, has been a huge
motivation for me to complete this thesis.

v
Contents
Abstract .................................................................................................................... i
Declaration ............................................................................................................. iii
Acknowledgements ................................................................................................ iv
Contents ................................................................................................................... v
List of Figures ........................................................................................................ xi
List of Tables.......................................................................................................... xv
List of Definitions ................................................................................................ xvi
List of Examples ................................................................................................. xvii
List of Publications .............................................................................................. xix
1. Introduction ........................................................................................................ 1
1.1 Service ecosystems and service variability .............................................. 1
1.2 Addressing service variability with existing technologies ....................... 3
1.2.1 Super-service approach versus all-service-variant approach........ 3
1.2.2 Variability management and Software Product Line ................... 5
1.3 Service customisation approach and customisable services ..................... 5
1.4 Problem statement .................................................................................... 7
1.5 Feature-based composition and delivery of customisable services .......... 8
1.6 Thesis outline .......................................................................................... 10
2. Background, Analytical Framework and Literature Review ........................... 15
2.1 Software variability ................................................................................ 15
2.1.1 Overview of software variability ................................................ 15
2.1.2 Software Product Line ................................................................ 16
2.1.3 Feature models ............................................................................ 17
2.1.4 Variability management ............................................................. 20
2.2 An analytical framework for analysing service variability .................... 23
2.2.1 Three types of service variability ............................................... 23
2.2.2 Service variability communication ............................................. 25

vi
2.2.3 Revision of inherited characteristics .......................................... 26
2.2.4 An analytical framework of service variability
characteristics ............................................................................. 28
2.3 Reviewing literature on service variability ............................................ 30
2.3.1 Variability in atomic services .................................................... 31
2.3.2 Variability in BPEL-based composite services .......................... 33
2.3.3 Variability in BPMN-based composite services ........................ 35
2.3.4 Variability in UML-based composite services .......................... 37
2.3.5 Variability in composite services using other notations ............ 39
2.3.6 Summary of characteristics of related work .............................. 40
2.4 Research gaps ......................................................................................... 42
2.4.1 Customisation framework .......................................................... 42
2.4.2 Interface description language ................................................... 43
2.4.3 Provisioning architecture ........................................................... 43
2.4.4 Atomic service realisation .......................................................... 44
2.4.5 Composite service realisation .................................................... 44
2.5 Summary ................................................................................................ 44
3. Feature-based Service Customisation Framework .......................................... 47
3.1 The Swinsure Insurance Web service and feature models ..................... 48
3.2 Overview of the customisation framework ............................................ 50
3.2.1 Benefits of separating the two operation modes ........................ 51
3.3 Customisable service as a product family .............................................. 51
3.3.1 A template approach for representing software variants ........... 53
3.3.2 Mapping between variant features and software variants .......... 54
3.4 Service customisation mode .................................................................. 55
3.4.1 Feature models for representing customisation options ............. 55
3.4.2 Customisation request as selected and disabled features ........... 58
3.4.3 Feature-based service variant derivation ................................... 67
3.4.4 Customisation response ............................................................. 69

vii
3.5 Analysis of the customisation framework against service
variability characteristics ........................................................................ 70
3.6 Summary ................................................................................................. 72
4. Web Service Variability Description Language (WSVL) ............................... 73
4.1 Motivations for WSVL ........................................................................... 74
4.1.1 Exploiting the messaging paradigm for implementing the
service customisation function ................................................... 75
4.1.2 Exposing service variability at both feature level and
technical level in service variability communication ................. 76
4.1.3 Customisation contracts and WSVL .......................................... 77
4.2 Web Service Variability description Language (WSVL) ....................... 77
4.2.1 Overview of WSVL .................................................................... 77
4.2.2 Description of customisation options ......................................... 78
4.2.3 Description of customisation endpoint ....................................... 81
4.2.4 Description of service capability ................................................ 83
4.2.5 Description of feature mapping .................................................. 85
4.2.6 WSVL and variability dependencies .......................................... 87
4.3 Engineering and validating WSVL documents ...................................... 89
4.3.1 Overview .................................................................................... 90
4.3.2 Feature modeling and prototype tool .......................................... 91
4.3.3 Service capability modeling and prototype tool ......................... 93
4.3.4 Feature mapping and prototype tool ........................................... 95
4.3.5 Verifying and using engineering models .................................... 97
4.4 Analysis of WSVL against service variability characteristics ............. 100
4.5 Summary ............................................................................................... 102
5. An Architecture for Provisioning Customisable Services ............................. 103
5.1 Benefits of extending existing service platforms ................................. 104
5.2 Additional functions for provisioning customisable services .............. 105
5.3 The service provisioning architecture .................................................. 105

viii
5.3.1 Overview .................................................................................. 105
5.3.2 Components of the architecture ............................................... 106
5.3.3 Interaction among components ................................................ 108
5.4 Handling partial customisation requests .............................................. 109
5.4.1 Overview .................................................................................. 109
5.4.2 Deriving WSVL documents for refined customisable
services ..................................................................................... 111
5.4.3 Runtime representation of refined customisable services ........ 115
5.4.4 Processing customisation requests destined for refined
customisable services ............................................................... 116
5.5 Analysis of the service provisioning architecture against service
variability characteristics ..................................................................... 116
5.6 Summary .............................................................................................. 117
6. Enabling Customisable Atomic Services ...................................................... 119
6.1 Reviewing engineering techniques for conventional Web services .... 120
6.1.1 Top-down approach versus bottom-up approach ..................... 120
6.1.2 The JAX-WS standard ............................................................. 121
6.2 Engineering the configurable service implementation ........................ 122
6.2.1 Variability in the service skeleton ............................................ 123
6.2.2 Variability in the business logic ............................................... 124
6.3 Runtime variability resolution ............................................................. 126
6.4 Prototype implementation and evaluation ........................................... 127
6.4.1 Implementing the service provisioning architecture ................ 127
6.4.2 Implementing the Swinsure Insurance Web service ................ 130
6.4.3 Extending consumer prototype tool ......................................... 130
6.4.4 Evaluating the operations of the service provisioning
architecture and the example customisable service ................. 132
6.5 Analysis of techniques for enabling customisable atomic services
against service variability characteristics ............................................. 136
6.6 Summary .............................................................................................. 138

ix
7. Composing Customisable Composite Services .............................................. 141
7.1 Research scope and requirements in supporting customisable
composite services ................................................................................ 142
7.1.1 Research scope ......................................................................... 142
7.1.2 Requirements ............................................................................ 143
7.2 The Swinsure claim handling process and variability inter-
dependencies ......................................................................................... 144
7.2.1 Swinsure claim handling process ............................................. 144
7.2.2 Swinpay Web service and variability inter-dependencies ........ 146
7.3 Benefits of modeling variability inter-dependencies ............................ 148
7.3.1 Variability inter-dependencies and runtime variability
resolution .................................................................................. 149
7.3.2 Benefits of modeling variability inter-dependencies ................ 150
7.4 Variability-enabled BPMN (VBPMN) ................................................. 151
7.4.1 Extending BPMN for representing variation points and
variants ..................................................................................... 152
7.4.2 Modeling variability intra-dependencies .................................. 160
7.4.3 Modeling variability inter-dependencies .................................. 162
7.5 Developing and resolving variability in process-based service
compositions ......................................................................................... 164
7.5.1 Developing process-based service compositions ..................... 165
7.5.2 Deriving WSVL description ..................................................... 167
7.5.3 Deriving executable process variants ....................................... 168
7.6 Prototype system and evaluation .......................................................... 171
7.6.1 Conformity ............................................................................... 171
7.6.2 Applicability ............................................................................. 172
7.6.3 Feasibility and prototype system .............................................. 173
7.6.4 The prototype system ............................................................... 173
7.7 Analysis of techniques for enabling customisable composite
services against service variability characteristics ............................... 177
7.8 Summary ............................................................................................... 179

x
8. Case Study and Evaluation ............................................................................ 181
8.1 Case study ............................................................................................ 181
8.1.1 Revisiting the inefficiency of the super-service approach ....... 183
8.2 Redesign the AWS as a customisable service ...................................... 184
8.2.1 Overview .................................................................................. 184
8.2.2 Variability modeling ................................................................ 185
8.2.3 Skeleton service implementation ............................................. 191
8.2.4 Service deployment .................................................................. 196
8.3 Evaluation ............................................................................................ 200
8.3.1 Metrics ..................................................................................... 201
8.3.2 Experimental settings ............................................................... 202
8.3.3 Experiment results ................................................................... 208
8.4 Limitations of the evaluation ............................................................... 211
8.5 Summary .............................................................................................. 212
9. Conclusion and Future Work ......................................................................... 213
9.1 Service variability characteristics addressed in this thesis .................. 213
9.2 Contribution ......................................................................................... 214
9.3 Future work .......................................................................................... 217
9.4 Final words ........................................................................................... 218
Appendix A: XML Schema for WSVL ............................................................... 221
Appendix B: The WSVL Description of the Swinsure Insurance Web
service ............................................................................................................ 225
Appendix C: VBPMN Metamodel ...................................................................... 237
Appendix D: Glossary ......................................................................................... 239
References ........................................................................................................... 247

xi
List of Figures
Figure 1.1 - An example of service variability ....................................................... 2
Figure 1.2 - Traditonal approaches for addressing service variability .................... 3
Figure 1.3 - Service customisation approach .......................................................... 6
Figure 1.4 - Chapter distribution and research gaps ............................................. 10
Figure 2.1 - Overview of SPL engineering (Adapted from (Pohl 2005)) ............. 17
Figure 2.2 - A feature model representing variability of a claim handling
process ........................................................................................................... 18
Figure 2.3 - Overview of variability management ................................................ 21
Figure 2.4 - Conceptual overview of service variability ....................................... 24
Figure 2.5 - Characteristics of service variability ................................................. 28
Figure 2.6 - Overview of research gaps ................................................................ 42
Figure 3.1 - Focus of this chapter.......................................................................... 47
Figure 3.2 - A feature model for Swinsure Insurance Web service ...................... 49
Figure 3.3 - Overview of the customisation framework ....................................... 50
Figure 3.4 - Similarity between product families and customisable services ....... 52
Figure 3.5 - Template approach versus composition approach ............................. 53
Figure 3.6 - Overview of the domain engineering process for customisable
services .......................................................................................................... 54
Figure 3.7 - Overview of service variant derivation process ................................ 67
Figure 3.8 - Complete customisation versus partial customisation ...................... 68
Figure 3.9 - Service variability characteristics addressed in this chapter ............. 70
Figure 4.1 - Focus of this chapter.......................................................................... 73
Figure 4.2 - Overview of WSVL........................................................................... 74
Figure 4.3 - Components of WSVL ...................................................................... 78
Figure 4.4 - Example of an invalid feature model ................................................ 80
Figure 4.5 - Swinbroker business process ............................................................. 88
Figure 4.6 - Overview of engineering WSVL documents .................................... 90
Figure 4.7 - Feature metamodel (adapted from (Czarnecki 2005d)) .................... 91
Figure 4.8 - Feature modeling tool ........................................................................ 92
Figure 4.9 - Service interface metamodel ............................................................. 93
Figure 4.10 - Service capability modeling tool ..................................................... 94

xii
Figure 4.11 - Feature mapping metamodel ............................................................ 95
Figure 4.12 - Feature mapping tool ....................................................................... 96
Figure 4.13 - Model transformation process ......................................................... 98
Figure 4.14 - Screenshots for verifying correctness of engineering models ......... 99
Figure 4.15 - Service variability characteristics addressed in this chapter .......... 100
Figure 5.1 - Focus of this chapter ........................................................................ 103
Figure 5.2 - Overview of the service provisioning architecture .......................... 106
Figure 5.3 - Handling partial customisation requests .......................................... 110
Figure 5.4 - A specialised feature model ............................................................. 112
Figure 5.5 - The description of service capability after specialisation ................ 113
Figure 5.6 - The description of feature mapping after specialisation .................. 114
Figure 5.7 - Service variability characteristics addressed in this chapter ............ 117
Figure 6.2 - A JAX-WS example ........................................................................ 122
Figure 6.3 - New JAX-WS annotation type ........................................................ 123
Figure 6.4 - Example of the new JAX-WS annotation ........................................ 124
Figure 6.5 - Example of JAX-WS Web Service Context .................................... 125
Figure 6.6 - Runtime representation of customisable services and service
variants ........................................................................................................ 128
Figure 6.7 - Initialise Web Service Context ........................................................ 129
Figure 6.8 - The prototype system on Amazon cloud and consumer
prototype tool ............................................................................................... 131
Figure 6.9 - Validation of customisation requests ............................................... 132
Figure 6.10 - Reuse of service variants ............................................................... 133
Figure 6.11 - Management page for deployed service variants ........................... 134
Figure 6.12 - Verifying service capability of service variants ............................ 135
Figure 6.13 - Service variability characteristics addressed in this chapter .......... 136
Figure 7.2 - Swinsure claim handling process ..................................................... 145
Figure 7.3 - Swinpay feature model .................................................................... 146
Figure 7.4 - Swinpay WSVL ............................................................................... 147
Figure 7.5 - Variability inter-dependencies ......................................................... 149

xiii
Figure 7.6 - Variability metamodel ..................................................................... 152
Figure 7.7 - Metamodel extension for modeling variability in control flow ...... 153
Figure 7.8 - Metamodel extension for modeling variability in data flow ........... 155
Figure 7.9 - Metamodel extension for modeling variability in message flow .... 158
Figure 7.10 - Mapping metamodel for variability intra-dependencies ............... 161
Figure 7.11 - Capturing variability intra-dependencies ...................................... 162
Figure 7.12 - Mapping metamodel for variability inter-dependencies ............... 163
Figure 7.13 - Capturing variability inter-dependencies ...................................... 163
Figure 7.14 - Overview of developing process-based service compositions ...... 165
Figure 7.15 - An excerpt of the WSVL description for Swinsure claim
handling process .......................................................................................... 168
Figure 7.16 - A feature configuration for Swinsure claim handling process ...... 169
Figure 7.17 - A process variant of the sub-process for collecting excess fee ..... 170
Figure 7.18 - A screenshot of the process modeling tool .................................... 174
Figure 7.19 - Service variability characteristics addressed in this chapter ......... 178
Figure 8.1 - Overview of redesigning the AWS ................................................. 185
Figure 8.2 - AWS feature model ......................................................................... 186
Figure 8.3 - AWS feature constraints .................................................................. 188
Figure 8.4 - AWS service capability model ........................................................ 189
Figure 8.5 - AWS feature mapping model .......................................................... 190
Figure 8.6 - An excerpt of the generated code .................................................... 192
Figure 8.7 - An excerpt of the generated SEI...................................................... 193
Figure 8.8 - An excerpt of the generated service implementation class ............. 194
Figure 8.9 - An excerpt of the annotated SEI...................................................... 195
Figure 8.10 - Screenshot for the generated AWS customisation frontend .......... 196
Figure 8.11 - Feature model registration with Feature model manager .............. 198
Figure 8.12 - Service registration with Variant profile repository ...................... 199
Figure 8.13 - An excerpt of the Runtime customisation and management
engine implementation ................................................................................ 200
Figure 8.14 - Light-weight service variants ........................................................ 203
Figure 8.15 - Medium-weight service variants ................................................... 204
Figure 8.16 - Heavy-weight service variants ...................................................... 205

xiv
Figure 8.17 - Overview of the experiment .......................................................... 207
Figure 8.18 - Number of service operations ........................................................ 209
Figure 8.19 - Loaded classes (%) ........................................................................ 210
Figure 8.20 - Memory consumption (%) ............................................................. 210
Figure 9.1 - Service variability characteristics addressed in this thesis .............. 213

xv
List of Tables
Table 2.1 - Interpretation of three levels of abstraction for Web services ............ 27
Table 2.2 - Summary of the characteristics of related works ................................ 41
Table 7.1 - Variant service capabilities and presence conditions for Swinpay
Web service ................................................................................................. 148

xvi
List of Definitions
Definition 3.1 - Customisation options.................................................................. 56
Definition 3.2 - Customisation request .................................................................. 58
Definition 3.3 - Ill-formed and well-formed customisation requests .................... 59
Definition 3.4 - Inferred customisation request ..................................................... 60
Definition 3.5 - Maximally inferred customisation request .................................. 62
Definition 3.6 - Maximise function ....................................................................... 63
Definition 3.7 - Normalised customisation request ............................................... 64
Definition 3.8 - Normalise function ...................................................................... 64
Definition 3.9 - Optimised customisation request ................................................. 64
Definition 3.10 - Valid customisation request ....................................................... 65
Definition 3.11 - Complete and partial customisation requests ............................ 66

xvii
List of Examples
Example 2.1 - A partial feature configuration ...................................................... 19
Example 2.2 - A complete feature configuration .................................................. 19
Example 3.1 - An example of customisation options ........................................... 57
Example 3.2 - A customisation request ................................................................ 58
Example 3.3 - An inferred customisation request after adding mandatory
features .......................................................................................................... 60
Example 3.4 - An inferred customisation request after considering the
feature hierarchy ........................................................................................... 61
Example 3.5 - An inferred customisation request after considering group
cardinalities ................................................................................................... 61
Example 3.6 - An inferred customisation request after considering cross-tree
constraints ..................................................................................................... 61
Example 3.7 - An optimised customisation request .............................................. 65
Example 3.8 - A complete customisation request ................................................. 66
Example 3.9 - A partial customisation request ..................................................... 69
Example 4.1 - Description of customisation options ............................................ 79
Example 4.2 - Description of customisation endpoint .......................................... 82
Example 4.3 - An example of customisation messages ........................................ 83
Example 4.4 - Description of service capability ................................................... 84
Example 4.5 - Description of feature mapping ..................................................... 86
Example 4.6 - Java snippet for validating feature configuration .......................... 97
Example 7.1 - Variability in control flow (a fragment of the main claim
handling process) ........................................................................................ 154
Example 7.2 - Nesting control flow variability (a fragment of the sub-
process for calculating repairing cost) ........................................................ 155
Example 7.3 - Variability in data flow (abstract view) (a fragment of the
sub-process for collecting excess fee from end-users) ................................ 156
Example 7.4 - Variability in data flow (expanded and detailed views) .............. 156
Example 7.5 - Optional data flow variant (a fragment of the sub-process for
collecting excess fee from end-users) ......................................................... 157

xviii
Example 7.6 - ConsumerTasks and variability in message flow (a fragment
of the sub-process for collecting excess fee from end-users) ...................... 159
Example 7.7 - PartnerTask and variability in message flow (a fragment of
the sub-process for collecting excess fee from end-users) .......................... 160

xix
List of Publications
This thesis is largely based on the following peer-reviewed articles for which I am the
primary author.
Book chapter:
Tuan Nguyen, Alan Colman, and Jun Han (2012) (to appear). Comprehensive Variability
Modeling and Management for Customizable Process-Based Service Composi-
tions. Handbook on Web Services. Athman Bouguettaya, Quan Z. Sheng, and
Florian Daniel (eds). Springer-Verlag: Berlin, Heidelberg, New York.
Conference papers:
Tuan Nguyen and Alan Colman (2010). A Feature-Oriented Approach for Web Service
Customization. IEEE International Conference on Web Services (ICWS 2010), Mi-
ami, USA (393-400).
Tuan Nguyen, Alan Colman and Jun Han (2011). Modeling and Managing Variability in
Process-Based Service Compositions. Service-Oriented Computing (ICSOC 2011).
G. Kappel, Z. Maamar and H. Motahari-Nezhad, Springer. 7084: (404-420).
Tuan Nguyen, Alan Colman and Jun Han (2012). Enabling the Delivery of Customizable
Web Services. IEEE International Conference on Web Services (ICWS 2012), Ha-
waii, USA (138-145).
Workshop papers:
Tuan Nguyen, Alan Colman, Muhammad Adeel Talib, and Jun Han (2011). Managing
service variability: state of the art and open issues. 5
th
International Workshop on
Variability Modeling of Software-Intensive Systems (VaMoS 2011), Namur, Bel-
gium. ACM (165-173).
Tuan Nguyen, Alan Colman and Jun Han (2011). A Web Services Variability Description
Language (WSVL) for Business Users Oriented Service Customization. Interna-
tional Workshop on User-Focused Service Engineering, Consumption and
Aggregation (USECA 2011) International Conference on Web Information Sys-
tem Engineering (WISE) workshop, Sydney, Australia.

1

1. Introduction
Service Oriented Architecture (SOA) has become the predominant architectural style for
architecting and developing business applications. In SOA, services are fundamental
building blocks that enable the reuse of business functionalities within and across
organizations. As reuse becomes the driving factor for the development of cost-
effective, agile and high quality business applications, services are being reused by an
increasing number of service consumers. Although these service consumers share the
core requirements for the provided services, their requirements are often slightly different
from one to another. As discussed later in Section 1.2, using existing technologies to deal
with commonalities and differences (aka. variability) in service consumers requirements
proves to be inefficient in terms of service description, publication and consumption. This
thesis addresses the problem of how to compose and deliver customisable services as a
way to address these inefficiencies. In this chapter, we introduce this research problem
and its context, and outline our approach to addressing it.
1.1 Service ecosystems and service variability
Along with the proliferation of SOA and Web service infrastructure, many Web service
providers are interconnecting their offerings in an unforeseen ways, giving rise to Web
service ecosystems (Barros 2006). Service ecosystems exhibit the following characteris-
tics:
The distinction between service providers and service consumers is blurring and
is dependent on the viewpoint. A service consumer with respect to one service
provider becomes service provider to other service consumers.
Services are consumed, repackaged, and recursively composed to produce various
business applications.
The relationships between service providers and service consumers in service
ecosystems are many-to-many. One service consumer reuses services from many
service providers, while one service provider provides the same service to many
service consumers. This results in significant interdependencies among service
providers in providing and consuming services.
Last but not least, the interaction among service providers is dynamic. Such dy-
namism enables emerging service delivery models like on-demand service
provisioning (Barros 2011).
Chapter 1 - Introduction
2
In service ecosystems, service providers have to respond to demands from a variety
of service consumers. In addition to common requirements, each service consumer
usually has distinct requirements which are different from other service consumers. That
is, there is variability (i.e. commonalities and differences) in consumer requirements that
service providers have to take into account. Such requirement variability necessitates the
existence of different variations of a service, namely service variants, for use by different
service consumers. In this thesis, we use the term service variability to refer to the
ability of a service to incorporate multiple service variants in its capability.
Figure 1.1 presents an example of service variability. The example illustrates a num-
ber of service variants, represented by leaf nodes. These service variants are specialised
from an original generic Web service, represented by the root node, that provides quotes
for building insurance policies. There are service variants for providing quotes for
residential insurance policies (i.e. the building is used for residential purpose). Other
service variants are for business insurance policies (i.e. the building is used for business
purpose). Each category can be further specialised to take into account optional types of
extra covers (i.e. accidental damage, extended third party liability, fusion cover) to be
included.
There are common and variant service capabilities among service variants. Com-
mon service capabilities are shared by all service variants, while variant service
capabilities are only available in some service variants. For instance, while all service
variants in Figure 1.1 provide the service capabilities (or service operations) for querying
quotes, only service variants for residential insurance policies have service capabilities
for checking occupancy types (e.g. owner occupied or tenanted). In addition, there are
dependencies (i.e. inclusion or exclusion relationships) among variant service capabili-

Figure 1.1 - An example of service variability
Building Insurance
Quote Service
Residential
Insurance
Business
Insurance
with Extra
Cover
without
Extra Cover
with Extra
Cover
without
Extra Cover
Accidental
Damage
Fusion
Cover
Accidental
Damage
Extended 3
rd
Party Liability
Fusion
Cover
1.2 Addressing service variability with existing technologies
3
ties. For instance, the variant service capabilities for adding extended third party
liability extra cover and the variant service capabilities for checking occupancy types
cannot co-exist (i.e. mutually excluded) (i.e. Extended third party liability extra cover
is only available to business insurance policies).
1.2 Addressing service variability with existing technologies
1.2.1 Super-service approach versus all-service-variant approach
Service variability can be addressed by using existing service technologies. To this end,
there are two alternative approaches: i) super-service approach, and ii) all-service-variant
approach (cf. Figure 1.2). In super-service approach, service providers produce a super-
service which contains a superset of service capabilities required for all service variants.
In contrast, for all-service-variant approach, service providers create all service variants
as independent entities.
A super-service comprises of a complete service interface description which cap-
tures all service capabilities and a complete service implementation which caters for all
service variants. Based on the complete service interface description, service consumers
need to selectively consume the relevant service capabilities belonging to service variants
that they require. The complete service implementation typically supports behaviors
specific to each service variant by dynamic switching between alternative behaviors
within its business logic. The main advantage of the super-service approach is that it
provides service consumer a single entry to consume services. There is only one service
interface description for all service variants so that the overhead of describing and
publishing these service variants is minimal for service providers. However, the approach
has a number of disadvantages as follows:

Figure 1.2 - Traditonal approaches for addressing service variability
Service middleware
Complete service
implementation
Service
endpoint
Complete
service
interface
description
Service middleware
Variant implementation
Variant
interface
Variant Variant
Variant Variant
Variant
interface
Variant
interface
a) Super-service approach b) All-service-variant approach
4
All service consumers are presented the same service interface description which
contains irrelevant service capabilities. Such irrelevant information induces extra
overhead for service consumers in consuming services. This extra overhead is ex-
acerbated by the widespread use of MDEbased automation techniques in service
development (e.g. the automated generation of service skeleton from the service
interface description (Balani 2009)).
Due to the use of single service implementation, the runtime instance of a service
variant usually contains unnecessary business logic which is only required by
other service variants. Such unnecessary business logic is only excluded at
runtime through dynamic evaluation. The presence of such unnecessary business
logic results in inefficient resource usage for service providers.
Service consumers need to check dependencies among variant service capabilities
which are usually described in natural languages. Otherwise, service consumers
will choose a wrong combination of variant service capabilities which are not
supported by the super-service.
The all-service-variant approach helps to address a number of issues associated with
the super-service approach. Firstly, since each service variant is an independent entity
with its own service interface description, each service consumer is provided one service
variant with the exact service capabilities that the service consumer requires. Consequent-
ly, there is no extra overhead for service consumers in consuming services. Secondly,
each service variant has its own service implementation which is pruned to its service
interface description. Therefore, resource usage by runtime service instances is opti-
mised. Thirdly, service consumers do not have to check dependencies among variant
service capabilities since these dependencies have already been considered by service
providers when creating service variants. However, the all-service-variant approach also
has following disadvantages:
The number of service variants is proportional to the number of service interface
descriptions that service providers need to prepare and publish. Note that these
service interface descriptions are largely equivalent due to the existence of com-
mon service capabilities. Therefore, the higher the number of service variants is,
the more redundancy it will be with respect to service description and publication.
There are more overhead for service providers to manage multiple service vari-
ants both internally (within service providers service infrastructures) and
externally (with respect to service consumers).
1.3 Service customisation approach and customisable services
5
1.2.2 Variability management and Software Product Line
In addition to above mentioned problems, one possible issue with both approaches is
related to how variability in the service implementation is managed when developing
services (i.e. design time) and deploying services (i.e. runtime). Variability management
facilitates the dynamic switching between alternative behaviors for the super-service
approach. As for the all-service-variant approach, variability management assists the
development of independent service variants which share common service capabilities.
When variability is not explicitly or efficiently managed, it is not possible to achieve
high-level of software reuse in developing the service implementation to which multiple
service variants are involved. In addition, it becomes difficult for service providers to
evolve the service implementation (e.g. adding a new service variant or adjusting behav-
iors of existing service variants) (Sun 2009).
Variability management has been studied in the SPL (Software Product Line) re-
search domain (Pohl 2005). Researches in SPL have shown that, in order to achieve high-
level of software reuse and software evolution when developing a family of related
software products (aka. product families), it is essential to systematically identify and
manage variability. Specifically, the SPL engineering paradigm relies on the use of
feature models which capture variability of a product family at a high level of abstraction
(i.e. the requirement level). Feature models drive the development of reusable assets for
the product family, as well as facilitate the derivation of software artefacts specific to
each product. The adaptation and extension of concepts and techniques from SPL to the
service computing domain is important to effectively manage service variability.
When the number of service variants is small, the problems associated with tradi-
tional approaches (i.e. super-service approach and all-service-variant approach) are not
significant. However, given the increasing interdependencies among service providers in
service ecosystems, we argue that addressing service variability using existing technolo-
gies will become problematic. Therefore, a fundamental revision of the role and
functionalities of services in service ecosystems, and the enhancement of engineering
techniques for designing and developing such services are required to efficiently address
issues related to service variability.
1.3 Service customisation approach and customisable services
In this thesis, we show how a service customisation approach and the use of customisable
services address issues related to service variability. There have been a number of
approaches for addressing some aspects of service customisation. For instance, (Stollberg
6
2010) shows how to use MDE techniques to customise service interfaces, while (Liang
2006) presents an approach for encapsulating customisation messages with the WS-
Policy framework. Unlike these approaches, we focus on a comprehensive service
customisation approach which promotes customisable services, and explicitly identifies
and manages variability in the development, deployment, and provisioning of such
customisable services (Figure 1.3).
A customisable service is a service that enables service consumers to determine
the variant of the service they get. In particular, a customisable service has an interface
description (i.e. Service customisation description) which specifies how the service
should be customised. Based on the description, service consumers are able to customise
service capabilities. As the result of service customisation, one particular service variant
is dynamically generated for the requesting service consumers. Such a service customisa-
tion approach inherits benefits from both the super-service approach and the all-service-
variant approach while solving their inherent shortcomings.
Similar to the super-service approach, a service customisation approach provides
service consumers a single entry to customise and consume services. There is a single
service interface description for a customisable service. And there is no need for the
description and publication of all service variants. Therefore, the overhead of service
description and publication is minimised for service providers. In addition, the service
customisation approach enables service consumers to have access to and consume only
one service variant. This is similar to the all-service-variant approach and helps to both
reduce overhead in service consumption and enable efficient resource usage by runtime
service instances. When variability is efficiently identified and managed, such a service

Figure 1.3 - Service customisation approach
Customisable service
implementation
Service
customisation
description
Customisation
engine
Variant
interface
Dynamically generated
service variant
Service middleware
1.4 Problem statement
7
customisation approach also solves the issues related to software reuse and software
evolution.
Similar to the all-service-variant approach, such a service customisation approach
may take into account dependencies among variant service capabilities when generating
service variants. Consequently, service consumers are freed from checking such depend-
encies. In addition, each service variant is a runtime instance which is dynamically
generated according to a service consumers request. Therefore, there is less overhead in
managing service variants compared to the static deployment and management of all
service variants in the all-service-variant approach.
1.4 Problem statement
The aim of this research is to develop a service customisation approach and enable the
use of customisable services to address issues related to service variability in service
ecosystems. We will develop a set of concepts and techniques which provide a compre-
hensive solution for the engineering, provisioning and consumption of customisable
services. In particular, the research tackles the following specific issues:
A service customisation framework: as the core element of a service customisa-
tion approach, an efficient mechanism is required which enables service
consumers to customise services. The mechanism needs to support the automated
derivation of service variants with variant service interface description and vari-
ant service implementation.
An interface description language for customisable services: Similar to conven-
tional services, a customisable service needs to have an interface described in a
machine-processable format. A service interface description specifies the varia-
bility of the customisable service, the procedure by which the service can be
customised, and what should be expected as the result of service customisation.
The service interface description provides a single entry by which the service is
customised and service variants are consumed regardless of how the service is
implemented internally.
A service provisioning architecture: The use of customisable services requires
the enhancement of existing service platforms to incorporate additional functions,
such as the dynamic derivation and deployment of service variants. In this specif-
ic issue, we investigate how to extend existing service platforms to support the
deployment and provisioning of customisable services.
8
Software engineering techniques for modeling and developing customisable
atomic services: Customisable atomic services need to be developed so that vari-
ant service implementations can be automatically derived as the result of service
customisation. To this end, it is essential to model variability in the implementa-
tion of customisable atomic services. In addition, a mechanism for the proper
instantiation of variability and generation of variant service implementation is re-
quired. As an integral part of a complete solution for supporting customisable
services, customisable atomic services will be deployed in the provisioning archi-
tecture and exposed through a service interface description to service consumers.
Software engineering techniques for composing customisable composite ser-
vices: Similar to atomic services, techniques are required for developing
customisable composite services. In addition to issues considered for customisa-
ble atomic services, the modeling and development of customisable composite
services needs to take into account the existence of customisable partner services,
as well as the dependencies between a customisable composite service and its
customisable partner services. Due to the recursive nature of service composi-
tions, there might also be recursive dependencies between a customisable
composite service and other customisable services.
While service variability is generally used to refer to both variability in the service
functionalities and variability in non-functional properties of services, this thesis is
particularly focus on the former case. Issues related to variability in non-functional
properties are outside the scope of this thesis.
1.5 Feature-based composition and delivery of customisable
services
This thesis presents a feature-based approach for the composition and delivery of cus-
tomisable services. There is a strong similarity between a customisable service and a
product family considered in the SPL. In particular, a customisable service can be
regarded as a product family, while a service variant is one product derived from the
product family. Utilising this similarity, we develop an approach that extends the con-
cepts of feature models and techniques in the SPL to enable the engineering, provisioning
and consumption of customisable services. The key components of our approach are:
Feature-based service customisation framework: We exploit feature models to
capture variability in consumer requirements with respect to a service. Based on
feature models, variability in the architecture and implementation of customisable
1.5 Feature-based composition and delivery of customisable services
9
services is identified and managed. Service consumers are able to customise ser-
vices by specifying the features they want and the features they do not want
following constraints defined in feature models. Based on consumers requests,
service providers dynamically derive service variants. Our feature-based service
customisation framework allows service consumers to efficiently customise ser-
vices at the requirement level, as well as enables the derivation of service variants
at both the service interface level and the service implementation level.
WSVL (Web Service Variability description Language): We define WSVL for
describing the interface of customisable services. The WSVL extends WSDL to
enable the realisation of the feature-based service customisation framework in a
service-oriented way. A WSVL description is a customisation contract which en-
ables loose coupling between service providers and service consumers with
respect to the consumption of customisable services.
An architecture for service provisioning: The service provisioning architecture
consists of a number of components specialised for performing different func-
tions of service customisation (e.g. validation of customisation requests or service
variant lifecycle management). It provides a blueprint for service providers to ex-
tend their existing service platforms in order to accommodate customisable
services. The architecture conforms to the feature-based service customisation
framework and is applicable to the deployment of WSVL-based customisable
services regardless of whether they are atomic or composite.
Extending J AX-WS standard for engineering customisable atomic services:
Variabilities in the implementation of a customisable atomic service are the re-
finement of variabilities captured in its service interface description (i.e. WSVL
description). We extend the JAX-WS standard so that variability in the service
implementation is explicitly captured and is mapped to variability in the feature
model. Based on this mapping, we define a variability resolution mechanism
which enables the dynamic derivation of service variants as the result of service
customisation. Customisable atomic services are compatible with our service
provisioning architecture to support service provisioning and consumption.
Extending BPMN standard for composing customisable composite services: We
extend BPMN 2.0 to enable the comprehensive modeling of variation points and
variants in process-based service compositions. We also define techniques for
capturing variability dependencies between a customisable composite service and
its customisable partner services. These variability dependencies are modeled
10
with respect to WSVL descriptions of customisable partner services. Service cus-
tomisation results in an executable process variant which is exposed as a service
variant. In addition, services are recursively customised based on the captured
variability dependencies. Similar to customisable atomic services, a customisable
composite service is described at the service interface level by a WSVL descrip-
tion and is compatible with the service provisioning architecture for service
provisioning and consumption.
1.6 Thesis outline
This thesis is organised as follows. Chapter 2 reviews the literature related to service
variability and service customisation, and identifies research gaps that the thesis then
addresses. Each research gap will be individually addressed in one separate chapter from
Chapter 3 to Chapter 7 (cf. Figure 1.4). In particular, Chapter 3 and Chapter 4 respective-
ly address two research gaps related to the external view of service customisation (i.e.
service customisation from service consumers viewpoint). Specifically, Chapter 3
presents a feature-based service customisation framework that allows service consumers
to customise services, while Chapter 4 describes WSVL for specifying the service
interface of customisable services. On the other hand, Chapter 5 through to Chapter 7
address research gaps related to the internal view of service customisation (i.e. how
service providers prepare and provide customisable services). In particular, Chapter 5
discusses an architecture for provisioning customisable services. Chapter 6 describes
techniques for developing customisable atomic services, while Chapter 7 defines tech-
niques for developing customisable composite services. Chapter 8 discusses a case study
and the overall evaluation of our approach. We conclude the thesis and discuss the future
work in Chapter 9.
Chapter 2 discusses characteristics of service variability and the extent to which re-
lated work supports those characteristics. We classify service variability characteristics

Figure 1.4 - Chapter distribution and research gaps
Customisation
framework
Atomic service
realisation
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
Consumer Partner Interface description
language
Composite service
realisation
Provisioning architecture
Ch3
Ch4
Ch6
Ch7
Ch5
1.6 Thesis outline
11
into two categories. The first category contains characteristics that service variability
inherits from the more general concept of software variability. The second category
contains characteristics which are distinct to the service computing domain. Based on
these characteristics we review the literature and analyse how far related work is able to
support service variability. The analysis leads to the identification of five research gaps
that will be addressed in this thesis: i) an efficient service customisation framework, ii) a
language for realising the customisation framework in service-oriented way, iii) a service
provisioning architecture, iv) the realisation of customisable atomic services, and v) the
realisation of customisable composite services. These research gaps are demonstrated as
boxes with dashed lines in Figure 1.4.
Chapter 3 discusses our feature-based service customisation framework. We describe
two operation modes for customisable services: customisation mode and consumption
mode. The customisation mode enables the customisation of the service to produce
service variants which are conventional services. Service variants are invoked in the
consumption mode in the same way as conventional services. We exploit the concept of
feature models to realise the customisation mode. In particular, we use a feature model to
capture service variability and represent customisation options. Service consumers are
able to customise services by specifying selected features and disabled features in
customisation requests. The chapter discusses different variations of customisation
requests (e.g. inferred customisation requests or optimised customisation requests) which
are semantically equivalent with respect to the result of service customisation. In addi-
tion, the chapter defines different types of customisation requests (i.e. valid or invalid,
complete or partial). Different types have different impacts on customisation responses.
For instance, the processing of a complete customisation request results in a service
variant which is a true conventional service. In contrast, the result of service customisa-
tion with respect to a partial customisation request is a refined customisable service.
Chapter 3 also discusses key ideas of engineering customisable services as configurable
artefacts where all configuration points are mapped to variant features in the feature
model. This approach enables the dynamic derivation of variant service implementations.
Chapter 4 describes WSVL. The WSVL captures four types of information: i) cus-
tomisation options, ii) customisation endpoint, iii) service capability, and iv) feature
mapping. A WSVL description for a customisable service advertises service variability at
the feature level (i.e. customisation options), service variability at the service interface
level (i.e. service capability), and the relationships between the two (i.e. feature map-
ping). The description also specifies the abstract and concrete definitions of customisation
12
operations and customisation messages (i.e. customisation endpoint). WSVL descriptions
enable the realisation of the service customisation framework in a service-oriented way,
as well as facilitate the reuse of service variability. This chapter also presents our MDE
techniques for engineering and verifying the correctness of WSVL documents.
Chapter 5 discusses an architecture for deploying and provisioning customisable ser-
vices. The chapter discusses the role and functionalities of the components in the service
provisioning architecture and their interactions. In addition, we describe how the service
provisioning architecture works with respect to complete customisation requests and
partial customisation requests. The service provisioning architecture is generic and
applicable to both customisable atomic services and customisable composite services.
While this chapter discusses generic components of the service provisioning architecture,
the detail for the component Configurable service implementation, which is specific to
the types of services (i.e. atomic or composite), is left to subsequent two chapters. This
detail involves techniques for: i) engineering the configurable service implementation,
and ii) dynamic resolution of variability in the configurable service implementation.
Chapter 6 presents our techniques for engineering the component Configurable ser-
vice implementation for customisable atomic services. We identify two types of
variability in the service implementation: i) variability in the service skeleton, and ii)
variability in the business logic. To support these two types, we extend JAX-WS standard
(Kotamraju 2009) which is a widely-used standard for engineering conventional atomic
services. The extension consists of new annotation types as well as the extended use of
the Web Service Context in JAX-WS in order to address the two types of variability
respectively. We also define a technique for the dynamic resolution of variability with
respect to this extension. This chapter also presents our prototype implementation of the
service provisioning architecture, an example customisable service, and a consumer
prototype tool to perform service customisation. The whole prototype system is success-
fully deployed on Amazon cloud and enables various evaluations of our techniques (e.g.
the validation of customisation requests or lifecycle management of service variants).
Chapter 7 presents the techniques for supporting customisable composite services.
The chapter discusses the implications and benefits of capturing variability dependencies
between a customisable composite service and customisable partner services with respect
to runtime variability resolution. We then present VBPMN (Variability-enabled BPMN)
which is our extension of BPMN 2.0, for the comprehensive modeling and management
of variability in composite services. VBPMN also facilitates the modeling of above
mentioned variability dependencies given that customisable partner services are described
1.6 Thesis outline
13
by WSVL. In addition, VBPMN enables the use of WSVL for describing the interface of
customisable composite services. The chapter defines a variability resolution mechanism
which enables the derivation of process variants as the result of service customisation.
The chapter also discusses how service is recursively customised based on the captured
variability dependencies. At the end of the chapter, we discuss the conformity and
applicability of our approach. We also introduce a prototype system which illustrates the
feasibility of our techniques in supporting customisable composite services.
Note that in each technical chapter (i.e. Chapter 3 to Chapter 7), we describe the re-
search gap that the chapter addresses at the beginning of the chapter. These research gaps
are identified and presented in Chapter 2 as the result of our literature review. In addition,
at the end of each chapter, we analyse the techniques presented in the chapter against
service variability characteristics that we also identified in Chapter 2. This format
demonstrates how each chapter contributes to our overall solution for supporting the use
of customisable services in service ecosystems.
Chapter 8 presents the case study of Amazon Web Service (aka. AWS) and the over-
al evaluation of our approach. The AWS is a cloud computing service that allows
businesses to obtain and manage computing resources. The AWS is designed as a super
service that incorporates service operations required by all of its clients regardless of their
varying needs. In this chapter, we discuss the redesign of this AWS as a customisable
service (aka. customisable AWS) based on our service customisation approach. We also
describe the deployment of this customisable AWS on our service middleware (i.e.
prototype implementation of the service provisioning architecture). To evaluate our
approach, we identify three metrics that represent the efficiency in service provisioning
and service consumption. We then describe experiments for collecting these three metrics
in the case study of the customisable AWS, discussing the experiment results as well as
the limitations of our evaluation.
Chapter 9 concludes the thesis by discussing its contribution to the field of service
computing. We then discuss the future work that could be done to further facilitate the
introduction of customisable services in service ecosystems.

15

2. Background, Analytical Framework and Literature Review
Enabling the composition and delivery of customisable services requires a comprehensive
approach that supports all aspects pertaining to the modeling and management of service
variability. This chapter discusses characteristics of service variability and the extent to
which related work supports those characteristics. We also identify research gaps that this
thesis then addresses.
The concept of service variability has its genesis in software variability. Therefore,
we devote section 2.1 to the discussion about software variability and how it is supported
in literature. In particular, we provide an overview of software variability in section 2.1.1.
Section 2.1.2 discusses SPL (Software Product Line) which is an efficient engineering
paradigm for supporting software variability. Section 2.1.3 presents feature models which
are key elements in modeling and managing variability in SPL. In section 2.1.4, we
describe concepts and concerns related to variability management.
In section 2.2, we set up an analytical framework for considering service variability.
While inheriting characteristics from software variability, service variability exposes
several distinct characteristics due to the nature of service computing. We discuss these
distinct characteristics in two categories: i) types of service variability, and ii) service
variability communication. Based on this discussion, we summarise both inherited
characteristics and distinct characteristics of service variability in the form of a feature
model. We also elaborate preferred service variability characteristics for the composition
and delivery of customisable services. This provides a basis for reviewing literature
related to service variability.
In section 2.3, we discuss related work and summarise how far related work is able
to address the identified characteristics. We classify related work into several categories
according to the type of services (i.e. atomic or composite), as well as the underlying
techniques for implementing services (i.e. BPEL, BPMN, or UML). The section con-
cludes with a comparative table that summarises characteristics of the reviewed work.
In section 2.4, we present five research gaps that will be addressed in this thesis. We
then conclude the chapter in section 2.5.
2.1 Software variability
2.1.1 Overview of software variability
Software variability refers to the ability of a software system to be efficiently extended,
changed, customized or configured for use in a particular context (Svahnberg 2005).
Chapter 2 - Background, Analytical Framework and Literature Review
16
The variability of a software system might be either implicit (i.e. hidden in the implemen-
tation without explicit documentation about where and how variation might occur) or
explicit (Chen 2009). In addition, software variability might be ad-hoc (i.e. happen by
chance) or systematic as the result of a strategic plan (Babar 2010). A software system
with an explicit and systematic variability approach will facilitate proactive reuse and
ease its evolution (Gurp 2001). In addition, when the number of variants is large, the
systematic identification and management of software variability will bring about high
productivity, reduced cumulative cost, and high quality production (Kang 2002; Lee
2002). Research has shown that the threshold of the number of variants for this transition
is approximately three (McGregor 2002).
2.1.2 Software Product Line
Software Product Line (SPL) is a software engineering paradigm that considers software
variability as a first-class entity (Pohl 2005). While traditional software engineering
paradigms focus on the development of a single software product, SPL is concerned with
the development of a family of related software products (Bosch 2009). In particular, SPL
relies on the systematic identification and management of variability throughout the
lifecycle of software development to facilitate reuse (Kang 2002). In SPL, a particular
product is developed from reusable assets, rather than from scratch as can be seen in
single software product development (Figure 2.1).
SPL clearly separates two processes of software development: domain engineering
process and application engineering process. The domain engineering process defines
the commonality and the variability of the product line, as well as constructing reusable
artefacts that accomplish the desired variability. The domain engineering process also
defines a mechanism by which variability is resolved. In contrast, the application engi-
neering process is concerned with the derivation and development of particular products
from reusable artefacts. Applications specific requirements are taken into account and
variability mechanisms defined in the domain engineering process are followed in order
to develop the product in a timely manner with least cost and highest quality.
As demonstrated in Figure 2.1, both the domain engineering process and the applica-
tion engineering process encompass all phases of traditional software development life
cycles (SDLC): requirement elicitation, architecture design, component implementation,
and testing. This is because both processes are specialisation of traditional SDLC for
different purposes. While the domain engineering process focuses on development for
reuse, the application engineering process focuses on development by reuse.
17
2.1.3 Feature models
Feature models are key elements for identifying and managing variability (Lee 2006).
During the domain engineering process of a software product line, feature models help to
scope the domain, defining the commonalities and differences of member products, as
well as driving the identification and realization of variability within architectural and
implementation artefacts. During the application engineering process, feature models
facilitate the derivation of particular products from domain artefacts.
Feature models were first introduced in the FODA (Feature-Oriented Domain Anal-
ysis) report (Kang 1990). Since then, many extensions have been done to accommodate
additional concerns, such as feature cardinalities and group cardinalities (e.g. Riebisch
2002; Czarnecki 2005c), feature attributes (e.g. Kang 1998; Czarnecki 2005d; Batory
2006), or feature relationships (e.g. Griss 1998; Gurp 2001; Lee 2002). The most com-
plete and expressive notation is the Cardinality-Based Feature Modeling (CBFM)
technique (Czarnecki 2005c) which we will describe in the following paragraphs.

Figure 2.1 - Overview of SPL engineering (Adapted from (Pohl 2005))
Domain
Requirements
Engineering
Domain
Design
Domain
Realisation
Domain
Testing
Domain artefacts & Variability model
Requirements Architecture Components Tests
D
o
m
a
i
n

E
n
g
i
n
e
e
r
i
n
g
Application
Requirements
Engineering
Application
Design
Application
Realisation
Application
Testing
Application 1 - Artefacts & Variability model
Requirements Architecture Components Tests A
p
p
l
i
c
a
t
i
o
n

E
n
g
i
n
e
e
r
i
n
g
Application N - Artefacts & Variability model
18
Figure 2.2 shows a feature model representing variability of a claim handling pro-
cess. The semantics of this feature model will be discussed in section 7.2.1. In this
section, we only use the feature model to demonstrate generic concepts of feature models.
A feature model is a hierarchical tree of features with composed-of relationships. For
instance, the feature Claim handling process is composed of four features: Cover
type, Bill payer, Extra cover, and Excess. Each feature is annotated with feature
cardinality which determines the lower bound and the upper bound for the feature to
appear in one feature configuration (described later in this section) when its parent
feature is selected. Feature cardinality is represented above the corresponding feature. For
instance, the cardinality [0-1] for the feature Extra cover implies that this feature might
be selected or disabled when its parent feature Claim handling process is selected.
Similarly, the cardinality [1-1] for the feature Repair specifies that this feature is
always selected when the feature Cover type is selected. From a feature models
perspective, there are two types of features: mandatory features and variant features.
Mandatory features appear in all feature configurations while variant features only

Figure 2.2 - A feature model representing variability of a claim handling process
[1-1]
Claim handling process
Excess
Unoccupied excess
[1-1]
Cover type
[1-1]
[a-b]
Feature
Cardinality
Feature
Group
Composed-of
Relationship
Feature
Legend
Constraints
Broker specified excludes End-user
Deducted requires End-user
[1-1]
Pay in advance
Credit card BPAY
[1-1] [0-1]
[1-1]
Deducted
Bank transfer
Extra cover
[0-1]
Repair
End-user specified Broker specified
Rebuild
End-user Broker
[1-1]
[1-1]
Bill payer
Temporary accommodation
[0-1] [0-1] [1-1]
Payment time
[a-b]
Group
Cardinality
19
appear in one or a number of feature configurations. A special type of variant features is
optional features whose feature cardinalities are [0-1] (e.g. feature Extra cover).
A set of features can be organised into a feature group. These features are referred to
as grouped features. For instance, the features Broker and End-user form one
feature group. Group cardinality is annotated below the parent feature of a feature group
to specify the lower bound and the upper bound of the number of grouped features to be
included in one feature configuration when the parent feature is selected. For instance, the
group cardinality [1-1] for the feature Bill payer implies that the two grouped features
Broker and End-user are alternative with respect to the feature Bill payer. Note
that grouped features are another type of variant features.
In addition to feature hierarchy, there are cross-tree constraints, called feature con-
straints, which describe the inclusive and exclusive dependencies among features (cf. the
constraint box). For instance, the selection of the feature Broker specified will exclude
the selection of the feature End-user, while the selection of the feature Deducted
will require the selection of the feature End-user in one feature configuration.
Feature configuration is derived from a feature model by completely or partially
resolving variability within the feature model (i.e. selecting or disabling variant features).
A feature configuration contains a set of selected features and a set of disabled features. A
complete variability resolution results in a complete feature configuration. For complete
feature configuration, the states of all variant features in the feature model have already
been decided (i.e. selected or disabled). In contrast, a partial variability resolution results
in a partial feature configuration. There exists at least one variant feature whose state has
not been decided in a partial feature configuration. Variability in a feature model can be
resolved through multiple stages, each of which produces a partial feature configuration,

Example 2.1 - A partial feature configuration

Example 2.2 - A complete feature configuration
20
before being completely resolved to produce a complete feature configuration. For
instance, Example 2.1 demonstrates a partial feature configuration. is a tuple of two
sets. The first set contains selected features while the second set contains disabled fea-
tures. The state of, for instance, features Extra Cover and Unoccupied Excess have
not been decided. In contrast, Example 2.2 presents a complete feature configuration.
A feature model is an efficient abstraction of service variability and provides an ef-
fective means for communicating variability between different stakeholders. In addition,
it has a strong mathematical underpinning which helps to query and reason about validity
of feature configurations (Benavides 2010). Consequently, feature models provide an
efficient way for capturing and managing service variability.
There are many techniques for formalizing and validating feature models and feature
configurations. Some techniques are based on propositional logic (e.g. Batory 2005;
Czarnecki 2005e; Jing 2005; Thum 2009; Benavides 2012). Others use constraint
programming (e.g. Benavides 2006; Segura 2008; White 2008; White 2009). Another
class of techniques use description logic to analyse feature models (Wang 2005; Fan
2006; Wang 2007; Zaid 2009). In addition to different logic representations, these
techniques use different solvers (i.e. BDD (Whaley 2007), SAT (Berre 2013), CSP
(Tsang 1993)) for supporting the reasoning. Note that each logic representation and solver
have different impact in the time and memory performance of the analysis process with
respect to one analysis operation. There is not an optimum logic representation and solver
for all the operations that can be performed with a feature model. In terms of tooling
support, FAMA framework (Benavides 2012) is the most widely used open source for
feature model validation that integrates different logic presentations and different solvers.
In our work, we also exploit FAMA framework for supporting the validation of feature
configurations in implementing prototype systems.
2.1.4 Variability management
Variability management is defined as a set of activities for explicitly representing
variability in software artifacts throughout the lifecycle, managing dependences among
different variabilities, and supporting the instantiation of the variabilities (Schmid
2004). Figure 2.3 presents an overview of different concepts related to variability man-
agement and their relationships.
21
There are two main concerns in managing variability: variability modeling and vari-
ability instantiation (Lee 2006). Variability modeling comprises of variability
representation and dependency description (Bachmann 2004). Variability representation
involves the identification and introduction of variation points and variants in domain
artefacts. And dependency description captures constraints in binding variants to variation
points. On the other hand, variability instantiation deals with the binding of appropriate
variants to variation points in domain artefacts to derive particular products. Variability
instantiation is also referred to as variability resolution. In this thesis, we use these two
terms interchangeably. Note that dependency description provides essential information
so that variability can be correctly resolved to produce valid products (Chastek 2002;
Sinnema 2006b).
2.1.4.1 Concerns for variability modeling
To effectively model variability, the following concerns need to be taken into account:
Abstraction levels: Variability exists at different levels of abstraction (i.e. system
requirements, architectures, and component implementation) (Sinnema 2007). In
general, variability is defined at some levels of abstraction and is refined at lower
abstraction levels. That is, variability at lower abstraction levels helps to realize
variability at higher abstraction levels. Throughout this thesis, we generally refer
to the relationship between variability at a level of abstraction and variability at
a lower level of abstraction as refinement relationships. Note that the lower
level of abstraction that variability is defined, the more complex and the higher
amount of variability that needs to be considered. For instance, variability in
component implementation helps to implement variability in software architec-
tures which in turn helps to realize variability in software requirements. As a

Figure 2.3 - Overview of variability management
Variability
representation
Dependency
description
Variability
instantiation
Variability management
Variability modeling
22
result, the amount of variability in component implementation is much higher
than the one in software requirements.
Variation points and variants: Variability is represented in software artefact as a
set of variation points and variants (Bayer 2006). A variation point is a location in
software artefacts where variation might occur. Each variation point is associated
with a number of variants from which one or several will be bound to the varia-
tion point when variability is resolved. For instance, a variability in software
requirements might be represented as a variation point with two alternative re-
quirements as variants. One requirement will be chosen to a particular class of
consumers.
Variability constraints: There are restrictions when binding variants to variation
points (Becker 2003). These restrictions are often defined in terms of requires
and excludes relations and expressed as the binding of variant A1 to variation
point A requires/excludes the binding of variant B1 to variation point B. In more
complex cases, variability constraints can restrict the binding among more than
two variation points. Variability constraints are also referred to as variability de-
pendencies in literature. In this thesis, we use these two terms interchangeably.
External variability versus internal variability: While various variabilities might
exist in software systems, only some of them are of interest to consumers. These
variabilities are referred to as external variability (Pohl 2005). Other variabilities
are the concern only to providers in order to completely support and realize soft-
ware variability. These variabilities are referred to as internal variability. One
example of external variability is different capabilities provided by a software
system that consumer can select. And one example of internal variability is dif-
ferent techniques for implementing the software system.
2.1.4.2 Concerns for variability instantiation
Variability can be instantiated at several stages during the construction of a software
system (e.g. Jarzabek 2001; Asikainen 2004; Zhang 2004; Svahnberg 2005). Alternative-
ly, variability can also be instantiated during the execution of a software system (e.g.
Cetina 2009; Capilla 2011; J. Bosch 2012; Jan Bosch 2012). The latter is generally
referred to as runtime or dynamic variability instantiation. In the context of this work, we
only focus on runtime variability instantiation. For this, the following concerns for
instantiating variability are relevant:
2.2 An analytical framework for analysing service variability
23
Automated: When variability of a product family is fully captured in domain ar-
tefacts, particular products can be automatically derived using such techniques as
model transformations (Perrouin 2008). On the other hand, in SPLs that are not
fully automated, further development is required to produce final products after
resolving variability in domain artefacts. Automated variability instantiation is
the focus of generative programming (Czarnecki 2005a).
Staged instantiation: Due to the existence of variability at different levels of ab-
straction and their refinement relationships, the effective approach to variability
instantiation is to resolve variability at the highest level of abstraction and auto-
matically propagate the decision downward lower levels of abstraction (Sinnema
2006a). In this way, developers who need to resolve variability only have to deal
with the fewest number of variation points and variants, while maintaining the va-
lidity of the variability instantiation process.
Similar to software variability, Web services also exhibit variability due to the increasing
number of service consumers with respect to one service and the variability in consumer
requirements. As discussed in Chapter 1, we define service variability as the ability of a
service to incorporate multiple service variants in its capability.
In addition to characteristics inherited from software variability, service variability
also exhibits distinct characteristics due to the nature of service computing (Nguyen
2011d). In particular, we have identified two concerns specific to service variability: 1)
the existence of three types of service variability; and 2) the needs for service variability
communication. In the next two subsections, we elaborate these two concerns. We then
revisit existing concerns of software variability in the service computing context. At the
end of this section, we present an analytical framework capturing the full set of service
variability characteristics.
2.2.1 Three types of service variability
In general, there are three different types of variability in Web services: exposed variabil-
ity, composition variability, and partner variability. Exposed variability refers to
variability in the interface description of a service. It describes different capabilities (e.g.
operations or messages) that a service can provide. Composition variability refers to
variability in the service implementation to realise exposed variability. The third type,
partner variability, only exists in composite services. It expresses variability in the
24
interaction between a composite service and partner services. Partner variability is bound
to exposed variability of partner services and reflects service variability reuse.
Figure 2.4 represents the three types of service variability and their relationships.
The distinction between exposed variability and composition/partner variability reflects
the principle of separating service interfaces and service implementations in SOC. This
separation is essential to enable the loose coupling between service providers and service
consumers. Since service interfaces and service implementations are two separate but
complement parts of services, variability of both artifacts needs to be addressed. In
addition, the distinction between composition variability and partner variability origi-
nates from the principle of service reuse and service composition in SOC. In composing a
customisable service, besides variabilities that a service provider can realize using the
composition logic, there are variabilities that the service provider can reuse from other
service providers. This distinction helps to make explicit different sources of variability
and facilitates the management of service variability in service compositions. The
distinction between composition variability and partner variability represents an ad-
vanced feature of service reuse that we call the reuse of service variability.
The distinction of three types of service variability is related to concepts of external
variability and internal variability in SPL. In particular, exposed variability is a subtle
variation of external variability. In SPL, external variability represents all variabilities
which are visible and relevant to consumers concerns. Some of those variabilities
encompass implementation aspects such as technology platforms to be used. In contrast,
exposed variability only captures variability at the service interface level. Similarly,
internal variability in SPL can be largely regarded as a superset of composition variabil-
ity and partner variability in service computing context.

Figure 2.4 - Conceptual overview of service variability
Exposed Variability
Composition Variability
Partner Variability
Loosely-coupled
Variability
Communication
Composite Service Partner Services
Composite Service
Atomic Service
Partner Exposed
Variability
External Variability in SPL Internal Variability in SPL
25
2.2.2 Service variability communication
To enable service variability reuse and facilitate service customisation, service variability
information needs to be described and exchanged between service providers and service
consumers. We define variability communication as a mechanism for describing and
exchanging variability information between providers and consumers in order to facili-
tate the modeling and instantiation of variability at the service consumer side as well as
propagating the consequence of variability instantiation toward the service provider.
While variability communication has also been a concern for software variability
(Halmans 2003), its nature is very different from the one required for service variability.
In particular, variability communication in SPL is usually informal, technology-
dependent, and static. In conventional SPL, the communication of software variability is
generally human-to-human using natural languages. In addition, the process involves the
description of variability using some proprietary tools or platforms. And consumers of a
SPL usually require provider-based design-time derivation of a particular product.
In contrast, variability communication for service variability needs to be formal,
technology-independent, and dynamic. Since service providers do not know about service
consumers in advance and need to provide services to as many service consumers as
possible, it is essential that service variability information is described by a formalised
language. In addition, service providers should not make any assumption on technologies
used by service consumers in interpreting service variability information. Consequently,
such formalised language should not be built based on a proprietary technology to lessen
the dependency with service consumers. In addition, service consumers need to reuse
both services and service variability to produce software products and possibly provide
new variability to another tier of consumers. This software delivery model necessitates
consumer-based runtime derivation of products and makes variability communication
dynamic.
In summary, the most effective way for exchanging service variability information is
through the use of a standardized language. And the key requirements for such a language
are:
Formality: Service variability needs to be described using a formalized language
to enable the interoperability and machine-processable ways of interaction be-
tween service providers and service consumers. In particular, since the
relationship between service providers and service consumers is many-to-many,
the use of such formalized language will lessen the dependencies (aka. coupling)
between relevant players.
26
Technology independence: There are different ways for describing the variability
of a Web service depending on how variability is modeled. When such descrip-
tion relies on a proprietary technology, consumers are restricted to using the same
technology. In contrast, if the description is abstracted from a specific technolo-
gy, consumers will be more flexible in utilising service variability and will be less
coupled to providers.
Self-describing: The language needs to capture sufficient information to support
not only variability modeling but also variability instantiation at the consumer
side, as well as the consequences of variability instantiation at the provider side.
In addition, such information needs to facilitate the dynamic consumption of ser-
vice variability.
2.2.3 Revision of inherited characteristics
Given the nature of service variability as described above, we revise characteristics that
service variability inherits from software variability. In particular, there are further
concerns regarding both variability modeling and variability instantiation.
2.2.3.1 Abstraction levels
As discussed in section 2.1.4.1, for any software system, there are three levels of abstrac-
tion (i.e. Requirement, Architecture, and Implementation) at which variability needs to be
modeled. However, the interpretation of these levels is dependent on whether the service
in question is atomic or composite. With respect to atomic services, these three levels are
feature, service interface model, and service implementation respectively (Table 2.1).
With respect to composite services, there are different ways for implementing ser-
vice composition (e.g. Hans Weigand 2008; Nancy 2008). However, in this research, we
particularly focus on process-based service compositions. These are prevalent approaches
for developing composite services using process modeling techniques. As such, BPMN
(Business Process Model and Notation) (OMG 2011a) will be used for representing the
architecture. And BPEL (Business Process Execution Language) (Jordan 2007) will be
used for describing the implementation of composite services. With regard to the archi-
tecture of service compositions, UML Activity Diagram (UML AD) provides similar
constructs to BPMN. Therefore, we also consider UML AD as a solution for achieving
process-based service compositions. In summary, three levels of abstraction for compo-
site services should be interpreted as feature, BPMN/UML AD models, and BPEL
process definition respectively.
27
Table 2.1 - Interpretation of three levels of abstraction for Web services
Abstraction level Atomic services Composite services
Requirement Feature model Feature model
Architecture Service interface model BPMN/UML AD
Implementation Service implementation BPEL

2.2.3.2 Variability constraints
Due to the reuse of service variability, there are two types of variability constraints that
need to be modeled:
Variability intra-dependencies: This type captures variability dependencies with-
in a service. In other words, this type consists of variability dependencies for
exposed variability and composition variability. It is generally referred to as vari-
ability constraints in literature since there has not been a work considering the
second type below.
Variability inter-dependencies: This type represents variability dependencies be-
tween a composite service and its partner service. In other words, they capture
variability dependencies between composition variability and partner variability.
Variability inter-dependencies reflect the situation when the resolution of variability
in the composite service requires the resolution of variability at partner services. And it
may have ripple effect in service ecosystems since service composition is recursive.
Therefore, variability inter-dependencies are very important in modeling and managing
service variability.
2.2.3.3 Variability instantiation
Further to two concerns described in section 2.1.4.2, there are other three concerns
regarding the instantiation of service variability:
Who (Provider/Consumer): Conventional SPL assumes providers to be the ones
who resolve variability based on the consultation with consumers. For service
variability and service customisation, it becomes necessary that consumers are al-
so able to instantiate variability. To this end, variability communication between
service providers and service consumers needs to be supported.
Level (I nterface/Implementation): Variability can be instantiated at either ser-
vice interface or service implementation level. Given the high number of service
consumers and the emergence of new software delivery models utilizing Web
services such as multi-tenant SaaS applications (van der Aalst 2011; Ghaddar
28
2012), it is essential that variability instantiation occurs at both levels and be con-
sistent with each other.
Recursive: Due to variability inter-dependencies among different services, varia-
bility instantiation in many cases is not confined to one service. Instead, the
instantiation of variability in one service might require the instantiation of varia-
bility in partner services and so on. Therefore, recursive is an important
characteristic in the instantiation of service variability.
2.2.4 An analytical framework of service variability characteristics
2.2.4.1 Overview
The full set of characteristics of service variability can be organised in the form of a
feature model as shown in Figure 2.5. In this feature model, all leaf features represent
service variability characteristics and parent features (i.e. non-leaf features) show con-
cerns accommodating the child features. Among all service variability characteristics,
distinct characteristics discussed in sections 2.2.1 and 2.2.2 are represented with under-
lined italic font name. In contrast, inherited characteristics which were discussed in
section 2.1.4 and re-considered in section 2.2.3 are represented with normal font name.
Note that variability communication is a distinct property of service variability that

Figure 2.5 - Characteristics of service variability
Service variability
Variability instantiation
Internal
Composition
variability
Partner
variability
External
Automated Inter-
dependencies
Exposed
variability
Variability
communication
Formality Technology
independence
Self-
describing
Staged
instantiation
Who
(Provider/
Consumer)
Level
(Interface/
Implementation)
Recursive Abstraction
level
Requirement
Architecture Implementation
Variation
points and
variants
Variability
constraints
Intra-
dependencies
Feature
name
Distinct
characteristics
Feature
name
Inherited
characteristics
29
involves concerns from both variability modeling and variability instantiation. Therefore,
we represent it as a direct child feature of service variability. Furthermore, the interpreta-
tion of the three levels of abstraction (i.e. Requirement, Architecture, and
Implementation) will be dependent on the type of services in question (i.e. atomic or
composite) as discussed in section 2.2.3.1.
2.2.4.2 Preferred characteristics for supporting customisable services
To enable the composition and delivery of customisable services, service variability
needs to be efficiently modeled and managed. Specifically, it is essential to consider all
three types of service variability (i.e. exposed variability, composition variability, and
partner variability) when applicable. As discussed in section 2.2.1, exposed variability
and composition variability present in both atomic and composite services, while partner
variability is only applicable to composite services. In addition, service variability needs
to be considered from the highest level of abstraction (i.e. the requirement level) and be
further refined to lower levels of abstraction (i.e. the architecture level and the implemen-
tation level). This systematic approach enables the comprehensive and efficient way for
modeling variability. In any case, variability dependencies (i.e. both variability intra-
dependencies and variability inter-dependencies) need to be considered as first-class
entities so that valid variability instantiation can be performed. Note that variability intra-
dependencies appear in both atomic and composite services, while variability inter-
dependencies only exist in composite services due to the presence of partner variability.
As discussed, variability instantiation (or variability resolution) is a process for
achieving service customisation. For customisable services, it is essential to support
automated variability instantiation which produces a service variant as a result of service
customisation. And variability instantiation needs to be performed at both the service
interface level and the service implementation level to enable efficient resource usage.
Due to the existence of partner variability and variability inter-dependencies, the
customisation of composite services also needs to take into account recursive variability
instantiation.
Another key property for delivering customisable services is allowing service con-
sumers to customise services. To this end, there are two key concerns. Firstly, the
customisation process needs to be simplified and consumer-oriented. We argue that this
concern can be addressed with the following three key elements: i) capturing variability at
the requirement level, ii) supporting service consumers to customise services at that level,
and iii) exploiting staged instantiation to automatically propagate variability resolution
30
decisions to lower levels of abstraction. Secondly, service variability needs to be effi-
ciently communicated to service consumers. Variability communication facilitates service
consumers in interpreting the variability of a service, control the customisation process,
as well as support the modeling of variability inter-dependencies and recursive service
customisation (in the case of composite services). To this end, all three characteristics of
variability communication (i.e. Formality, Technology independence, and Self-
describing) need to be properly addressed.
2.3 Reviewing literature on service variability
In this section, we review the literature on service variability using the characteristics
identified above. There are three remarks regarding the inclusion and exclusion of works
for this literature review:
i. Our research focuses on variability in functionalities of Web services. We ex-
clude approaches that address variability in non-functional properties of services
(e.g. Mohabbati 2011; Mahdavi-Hezavehi 2012; Moustafa 2012; Ognjanovic
2012).
ii. This literature review focuses particularly on software engineering techniques for
enabling the composition and delivery of customisable services. For this reason,
we do not include works discussing general relationships between SOA and SPL
(e.g. how these two engineering paradigms address software reuse (Jaejoon Lee
2007; Adam 2008; Cohen 2010; Galster 2011)).
iii. With respect to composite services, we focus on process-based service composi-
tion. Specifically, we consider the use of widely-adopted process
modeling/specification techniques: BPMN/UML and BPEL. For comprehensive-
ness, we also describe other modeling techniques such as EPC or YAWL.
Our review of the literature is organised into several categories. The first category
considers variability in atomic services, while other four categories discuss variability in
composite services. Among these four categories, three categories correspond to three
underlying techniques for realising process-based composite services (i.e. BPEL, BPMN
or UML). And the last category discusses the use of other process modeling notations (i.e.
EPC, YAWL). Each category is discussed in one subsection with the same structure. The
first half of the subsection presents the overview of works in that category, while the
second half is our analysis based on the identified service variability characteristics. The
analysis will be summarised in Table 2.2 at the end of this section.
31
2.3.1 Variability in atomic services
Identifying and modeling variability in the service interface description is the main focus
of related works that consider variability in atomic services. For this reason, these works
can be classified into two groups: i) those that do not consider variability in the service
implementation, and ii) those that partially support variability in the service implementa-
tion.
Note that two works in this category (Chang 2007; Yukyong 2008) assume the use
of business processes as service implementation (i.e. composite services). However, we
categorize them here due to their limited support for variability in business processes, as
well as their explicit support for variability in service interface description which is
usually lacking in categories for composite services
2.3.1.1 Overview
With regard to the first group, Web Service Offering Language (WSOL) (Tosic 2002;
Tosic 2003) aims to describe different classes of a Web service. All classes (aka. service
variants) have the same functional capabilities but each class is determined by one
combination of constraints (e.g. QoS, access rights). Based on the WSOL description,
consumers are able to choose the most appropriate service variant (or a class) matching
their quality requirements. WSOL provides a mechanism that facilitates service consum-
ers in selecting service variants. However, it does not require the derivation of service
implementation for each selected service variant. Instead, service implementation remains
intact before and after service variant selection.
(Liang 2006) extends the WS-Policy framework to incorporate customisation poli-
cies (aka. customisation options) and enforce the validity of customisation requests.
Customisation policies describe how information in the service interface description can
be altered, such as adding new elements or removing existing attributes to/from existing
data types. Customisation requests build upon customisation policies and are used by
service providers to enact changes to a Web service. While this work particularly consid-
ers service customisation, variability instantiation
1
is only performed at the service
interface level, not the service implementation level.

1
Throughout this thesis, the two terms variability instantiation and variability resolution are
used as synonyms for service customisation. All of them refer to the process in which variabil-
ity of a Web service at either the service interface level or the service implementation level is
resolved to produce one particular service variant.
32
Stollberg et al. (Stollberg 2009; Stollberg 2010; Barros 2011) defines a set of meta-
models for modeling variability in service interface models. Consumers are able to use
the variability model to customise the Web service and derive a refined service interface
matching their requirements. Both variability modeling and variability instantiation need
to be performed using the Eclipse EMF modeling framework (Eclipse 2012b). Similar to
(Liang 2006), service customisation is limited to the service interface customisation,
while service implementation is assumed to cater for all possible customisation options.
For the second group, (Jiang 2005) proposes to apply the concept of application
frameworks in modeling and implementing variable Web services. In particular, they use
UML class diagrams to represent the common service model of a family of Web services.
The service model is specialised to create the service interface, as well as facilitating the
implementation of each variant Web service.
(Chang 2007; Yukyong 2008) define a general XML schema for representing varia-
bility in service artefacts. The variability XML schema can be used to extend existing
XML schemas for describing variability in service interface description (using WSDL)
and business process definition (using BPEL). From these variability descriptions, a
decision model is used to instantiate variability and to derive a service variant.
2.3.1.2 Analysis
With respect to variability modeling, works in either group mainly capture variability in
service interface models (cf. the architecture abstraction level characteristic in Table 2.2)
as discussed. They do not fully support variability in service implementation (cf. the
implementation abstraction level characteristic). In addition, none of these works sup-
ports variability at the requirement abstraction level.
With respect to variability instantiation, since the second group of techniques does
not fully capture variability in service implementation, none of the techniques in this
group is able to support automated generation of service variants (cf. the automated
characteristic). On the other hand, the first group of techniques only supports automated
variability instantiation at the service interface level (cf. the level (inter-
face/implementation) characteristic). Most importantly, since variability at the
requirement abstraction level is not considered, variability instantiation is performed at a
low level of abstraction (i.e. architecture abstraction level) which involves a larger
number of variation points and variants. Consequently, variability instantiation requires
the understanding of technical details and can be complex.
33
Variability communication is only supported by techniques in the first group since
these techniques enable automated variability instantiation and aim at enabling service
customisation. They all use a formalized language to capture service variability and allow
consumers to customise the service (cf. the Formality characteristic). However, Stollberg
et al. uses a language which is dependent on the Eclipse EMF framework. This requires
consumers to use the same modeling framework in customising services and enforces
tight coupling between service providers and service consumers. Both (Liang 2006) and
WSOL avoid this problem by extending Web service standards (i.e. WS-Policy or
WSDL) (cf. the Technology independence characteristic). However, the language used by
(Liang 2006) is not expressive enough. In particular, this language is missing the infor-
mation about how to construct and where to exchange customisation messages.
Consequently, the language is not self-described (cf. the Self-describing characteristic).
Only the WSOL fulfills all characteristics of variability communication.
2.3.2 Variability in BPEL-based composite services
Works that support variability in BPEL processes propose different ways for introducing
variation points and variants into BPEL processes. Some works extend the XML schema
for BPEL, while others integrate BPEL processes with external concerns like aspects or
business rules. A commonality of these works is the support for process configura-
tion/adaptation as a result of variability instantiation. However, none of these works takes
into account variability of partner services. We classify these works into two categories:
i) ones that explicitly model and manage variability, and ii) ones that address process
adaptation.
2.3.2.1 Overview
In the first category, VxBPEL (Sun 2008; Koning 2009) defines an XML schema
extension for the BPEL language in order to incorporate variation points and variants into
business process definitions. The extension also defines high-level variation points, called
configurable variation points, to capture dependencies among variation points. The use
of configurable variation points enabled staged instantiation since decisions at the higher
level of abstraction are automatically propagated to the lower level of abstraction.
VxBPEL uses a configuration file which contains high-level variability resolution
decisions to instantiate variability at runtime.
Variability descriptor (Mietzner 2008a; Mietzner 2008b; Mietzner 2009) is another
technique in the first category. The authors propose a variability description language for
34
capturing and instantiating variability. A variability description is separated from any
software artefacts, i.e. business process definition, service interface description, and
process deployment description. The description specifies locations of variation points in
software artefacts and provides information about corresponding variants. In addition, the
description defines the order by which variation points should be bound, as well as the
dependencies in binding those variation points. Variability description not only enables
the modeling of variability across different software artefacts, but also provides infor-
mation so that variability is consistently resolved to produce one variant composite
service.
Works in the second category are relatively similar in terms of adapting business
processes. They all consider changing business processes at runtime by removing BPEL
activities, replacing an activity with another process fragment, or adding a new process
fragment. However, they differ in the way such changes are enacted. Some works exploit
techniques from aspect-oriented programming to weave cross-cutting concerns (Charfi
2007; Chen ; Baresi 2012). Other works utilize business rules or policies to accommodate
changes (Charfi 2004; Baresi 2007; Baresi 2011; Groefsema 2011; Montangero 2011).
There is also work that uses events to enact changes and adaptation (Barros 2007;
Hermosillo 2010). These works are summarised in Table 2.2 as Aspects, Rules or poli-
cies, and Events respectively.
2.3.2.2 Analysis
A commonality across works in both categories is the support of variability modeling in
the implementation of composite services (i.e. BPEL definition). This is the lowest level
of abstraction for process-based service composition. However, none of these works
considers variability modeling at the architecture level or the requirement level. With the
exception of Mietzner et al. (Mietzner 2008a; Mietzner 2008b; Mietzner 2009) all works
only support composition variability. Mietzner et al. also address exposed variability
along with composition variability. Most importantly, all of these works only consider
variability within the service composition itself, without taking into account variability in
partner services. Consequently, they do not support partner variability, as well as support-
ing variability inter-dependencies between the composite service and partner services.
With respect to variability instantiation, works in both categories assume service
providers as the one who triggers variability resolution. Consequently, consumers have no
means to refine the service capability based on their requirements, yet need to consume a
service variant as provided. In addition, while works in the first category enable automat-
35
ed variability instantiation, works in the second category requires external factors such as
aspects, rules, or events. Since these factors are sometime fed by human developers
2
, we
consider these works as partially supporting automated variability instantiation. Regard-
less of whether variability instantiation is fully or partially automated, staged instantiation
is not supported in most works since variability is only modeled at the lowest level of
abstraction. The only exception is VxBPEL in which low level variation points are
organized into higher-level variation points. Consequently, variability resolution can be
done at the high level of abstraction and be propagated to the lower abstraction level.
Lastly, since partner variability is not modeled, recursive nature of variability instantia-
tion is not taken into account in all works.
As described, in all of these works, it is the service providers responsibility to in-
stantiate variability. Therefore, the exchange of variability information is not considered.
However, in Variability descriptor (Mietzner 2008a; Mietzner 2008b; Mietzner 2009),
variability information is explicitly described using a formalized language.
2.3.3 Variability in BPMN-based composite services
A main concern for works in this category is the modeling of variability at the architec-
tural level (i.e. BPMN models). Some works discuss variability instantiation and the
propagation of variability resolution decisions from the architectural level to the service
(process) implementation level. In contrast, others do not explicitly address concerns
related to variability instantiation. Similar to BPEL-based approaches, works in this
category do not consider partner variability and variability inter-dependencies.
2.3.3.1 Overview
In Provop (Hallerbach 2009; Hallerbach 2010) a reference process model is defined with
predefined adjustment points. For each adjustment points, change operations are defined
so that the application of a sequence of change operations with respect to the reference
process model will result in a process variant. Examples of change operations are
deleting a process fragment between two adjustment points or inserting a new process
fragment between adjustment points. Change operations, which are usually applied
together, are organized into change options. As such, change options help to capture
variability intra-dependencies.

2
The factors can be automatically provided if the system is designed to do so by using, for
instance, an additional component for runtime monitoring and enactment.
36
Schnieders et al. (Schnieders 2006; Schnieders 2007) specify a number of variability
mechanisms for introducing variation points and variants into business process models.
Five mechanisms introduced are inheritance, parameterization, extension, encapsulation,
and design pattern. To implement these mechanisms, the authors adapt the concepts of
stereotype in UML2 specification to BPMN. As the result, BPMN model elements can be
marked with <<VarPoint>> for variation points, <<Variant>> for variants, or <<Alter-
native>> for alternative variants. Based on this extension, the authors exploit SPL
engineering paradigm for modeling variability at the feature level (i.e. requirement level),
the BPMN level (i.e. architecture level) and implementation level. Variability resolution
in the feature model will be propagated through the BPMN model to the implementation
so that a process variant can be achieved.
(Charfi 2010) and (Machado 2011) exploit aspect-orientation techniques for variabil-
ity modeling in BPMN models. In particular, they extend BPMN with new element types
for describing aspects, point cuts, and advices. Different types of aspects are supported.
For instance, before or after aspects enforce the addition of advices before or after
the locations in process models that match the point cuts. Similarly, around aspects
define that the corresponding elements matching the point cuts are replaced by the
advices. Consequently, these new model elements help to weave cross-cutting concerns
like compliance, auditing, or billing into a process model.
(Weidmann 2011) extends BPMN with new modeling elements for representing var-
iability. In particular, the technique defines variable region as a placeholder for different
variants. Each variant is a process fragment especially marked with a fragment start link
and a fragment end link to signify its role. Dependencies among variable regions are used
to specify the order by which variable regions need to be bound. In addition, the tech-
nique utilizes enabling conditions to denote binding constraints.
2.3.3.2 Analysis
With respect to abstraction levels of variability modeling, most of these works solely
focus on variability in BPMN models (i.e. architecture abstraction level). Only Schnie-
ders et al. (Schnieders 2006; Schnieders 2007) fully supports variability at all levels (i.e.
requirement, architecture, and implementation). Consequently, this technique is able to
support automated variability instantiation to derive a process (service) variant. For other
techniques, it is generally possible to exploit the mapping between BPMN elements and
BPEL elements defined in the BPMN specification to address variability at the imple-
37
mentation level
3
. However, this requires that variability in both control flow and data flow
of service compositions is modeled. Since all other techniques only consider variability in
control flow, we regard them as partially supporting automated variability instantiation.
Only Schnieders et al. (Schnieders 2006; Schnieders 2007) and Provop can support
staged instantiation. This is because, in (Schnieders 2006; Schnieders 2007), variabilities
at all levels of abstraction as well as their relations are modeled explicitly. Similarly,
Provop organizes change operations into change options to simplify the variability
instantiation process.
None of these works considers partner variability or takes into account variability
inter-dependencies. Neither do they consider recursive variability instantiation. In
addition, these works do not take into account exposed variability. Therefore, variability
instantiation is neither supported nor applicable to service interface.
Another commonality among these works is the assumption that service providers
will perform variability resolution. As the result, variability communication is not
supported by all of these works.
2.3.4 Variability in UML-based composite services
Since UML activity diagrams provide similar semantics to BPMN, a number of tech-
niques have extended UML activity diagrams to support variability in composite services.
Compared to BPMN, UML provides a flexible extension mechanism by means of profiles
or stereotypes. This extension mechanism is exploited by works in this category to model
variation points and variants. However, UML is a generic modeling language and is not
as expressive as BPMN with respect to process modeling. Consequently, a substantial
extension of UML is required if there is a need to comprehensively model composite
services. Similar to the previous two categories, works in this category only consider
variability within the composite services themselves rather than taking a complete view
of variability within and across service compositions.

3
Our technique, as described in Chapter 7, exploits this approach. However, we take into account
variability in all three aspects of service compositions (i.e. control flow, data flow, and message
flow). Consequently, our technique is able to not only address variability in the implementation of
composite services, but also capture variability inter-dependencies between composite services and
partner services.
38
2.3.4.1 Overview
(Razavian 2008) proposes an extension to UML activity diagram by defining a UML
profile. The UML profile enables the introduction of variation points and variants into
UML models for composite services. In this technique, variabilities in not only the
control flow but also the data flow are captured. Therefore, even though variabilities are
only modeled at the architecture level, it is possible to automatically generate a service
variant when resolving variability in the UML models. In addition, the technique supports
the hierarchical representation of variability using the decomposition property of ele-
ments in UML activity diagrams. Consequently, it helps to simplify the variability
resolution process.
(Hadaytullah 2009) proposes the use of specialization patterns for supporting varia-
bility instantiation. Starting from a model template incorporating all UML models of
service variants, the technique facilitates the creation of specialization patterns denoting
variation points and variants. Specialization patterns are then used to produce tasks which
guide developers in binding variants to variation points in order to derive the UML model
of a service variant. With respect to variability modeling, this work only supports varia-
bility in the control flow of a composite service. Consequently, the result of variability
instantiation is only an UML model of a service variant, rather than an executable service
implementation.
(Sun 2009) defines an extension to UML for modeling variability in the architecture
of composite services using UML diagrams. In particular, their extension supports class
diagrams, activity diagrams and sequence diagrams. In addition, they use feature models
for capturing variability at the requirement level and utilize VxBPEL (Koning 2009) for
representing variability at the implementation level. The technique exploits the
COVAMOF framework (Sinnema 2004; Sinnema 2006a; Sinnema 2006b) for managing
service variability throughout all levels of abstraction. The COVAMOF framework
enables efficient variability instantiation since high-level variability resolution (i.e.
feature level) can be automatically propagated to lower levels of abstraction.
In Apto framework (Jaroucheh 2010), UML class diagrams are used to represent all
BPEL elements and to model composite services. The framework defines evolution
primitives for altering any element of UML models, such as adding, deleting or modify-
ing model elements. Evolution primitives are then organized into evolution fragments for
managing dependencies among them. To trigger an adaptation of a process, the Apto
framework defines context models and linkage models for associating context infor-
39
mation to corresponding evolution fragments. Consequently, the framework enables
context-aware adaptation of process-based service composition.
2.3.4.2 Analysis
With respect to variability modeling, (Sun 2009) is the most promising technique since
variability at all levels of abstraction is explicitly considered. On the other hand,
(Razavian 2008) and (Jaroucheh 2010) only support variability at the architecture level.
However, these techniques capture all aspects of variability so that variability in the
implementation level is automatically covered. Therefore, we regard these techniques as
partially supporting variability at the implementation level. (Jaroucheh 2010) partially
supports variability at the requirement level due to the use of context models for captur-
ing high-level variability, while the other two works do not consider this level.
A commonality of the works in this category is that they only consider composition
variability but overlook exposed variability and partner variability. In addition, they do
not address variability inter-dependencies between the composite service and partner
services. Nor do they take into account recursive variability instantiation.
Most of these works support automated variability instantiation with some works al-
so utilize staged instantiation. However, variability instantiation is limited to the
implementation level only and the interface level is not considered. All works assume
service providers to be the ones who trigger variability resolution. As the result, none of
these works supports any characteristic of variability communication.
2.3.5 Variability in composite services using other notations
Other notations are available for modeling composite services. Notable ones are EPC
(Event-driven Process Chains) (van der Aalst 1999), YAWL (Yet Another Workflow
Language) (van der Aalst 2005). These notations have already been extended for support-
ing variability, such as Configurable EPC (La Rosa 2011) or Configurable YAWL (e.g.
Gottschalk 2008; Lnn 2012). While variability modeling and variability instantiation are
supported to a certain extent, major shortcomings of these works are:
Exposed variability is not considered and variability instantiation is only limited
to service implementation (i.e. variability instantiation for service interface is not
supported).
The consideration of partner variability is omitted. Neither do they support varia-
bility inter-dependencies or recursive variability instantiation.
40
They assume service providers to be the ones who trigger variability instantiation.
Consequently, variability communication is not supported.
Note that while BPMN/UML/BPEL supports imperative process specifications, the-
se notations focus on declarative approaches for process modeling. There are advantages
and disadvantages with respect to each type of process modeling (Kapuruge 2010). The
selection of one type to another largely depends on the application domain of the corre-
sponding composite services. As discussed above, either technique exhibits the same
shortcomings with respect to addressing service variability. For this reason, we particular-
ly focus on imperative approaches in this thesis. Challenges for supporting service
variability with respect to declarative approaches are considered in our future work.
2.3.6 Summary of characteristics of related work
Table 2.2 summarises related works with respect to the characteristics of service variabil-
ity identified in section 2.2. Characteristics marked with a tick are clearly addressed, or
can be clearly inferred, from the work reviewed. On the other hand, characteristics
marked with a cross are not addressed and it is difficult to see how the work could
support such features. And characteristics marked with a tilde ~ are partially supported, or
else they are not addressed yet it can be reasonably inferred that they could be partially
supported. The extent of how a characteristic is partially supported has been described
appropriately in its specific context.
As can be seen from Table 2.2, none of related works addresses all characteristics for
enabling customisable services discussed in section 2.2.4.2. For instance: i) approaches
for atomic services do not consider variability instantiation at the service implementation
level, ii) approaches for composite services do not take into account partner variability
and variability inter-dependencies, or iii) there are only a few works allow service
consumers to customise services with very limited support (i.e. with respect to variability
communication and variability instantiation). In the following section, we identify five
research gaps that this thesis addresses to overcome this shortcoming.

41
Table 2.2 - Summary of the characteristics of related works

4
N/A denotes characteristics that are not applicable to the work under review.
5
Character P or C represents Provider or Consumer respectively
6
Abbreviations Inf and Imp stand for Interface and Implementation respectively
7
With respect to composite services, we only model variability at the architecture level by
comprehensively extending BPMN 2.0 in all three aspects of service composition: control flow,
data flow, and message flow. We then exploit the mapping between BPMN elements and BPEL
elements defined in the BPMN specification to address variability at the implementation level. The
detail is discussed in Chapter 7.

I
n
t
r
a
-
d
e
p
e
n
d
e
n
c
i
e
s

I
n
t
e
r
-
d
e
p
e
n
d
e
n
c
i
e
s

R
e
q
u
i
r
e
m
e
n
t

A
r
c
h
i
t
e
c
t
u
r
e

I
m
p
l
e
m
e
n
t
a
t
i
o
n

E
x
p
o
s
e
d

v
a
r
i
a
b
i
l
i
t
y

C
o
m
p
o
s
i
t
i
o
n

v
a
r
i
a
b
i
l
i
t
y

P
a
r
t
n
e
r

v
a
r
i
a
b
i
l
i
t
y

F
o
r
m
a
l
i
t
y

T
e
c
h
n
o
l
o
g
y

i
n
d
e
p
e
n
d
e
n
c
e

S
e
l
f
-
d
e
s
c
r
i
b
i
n
g

A
u
t
o
m
a
t
e
d

S
t
a
g
e
d

i
n
s
t
a
n
t
i
a
t
i
o
n

W
h
o

(
P
r
o
v
i
d
e
r
/

C
o
n
s
u
m
e
r
)

L
e
v
e
l

(
I
n
t
e
r
f
a
c
e

/

I
m
p
l
e
m
e
n
t
a
t
i
o
n

R
e
c
u
r
s
i
v
e

A
t
o
m
i
c

Jiang 2005

N/A
4

N/A

P
5

N/A
Stollberg et al.

N/A

N/A
C5
Inf
6
N/A
Liang 2006

N/A

N/A

C Inf N/A
Tosic 2002

N/A

N/A

C Inf N/A
Chang 2007

P

Kim 2008

P

B
P
E
L

VxBPEL

P Imp
6

Variability
descriptor

P Both

Events

P Imp

Aspects

P Imp

Rules or policies

P Imp

B
P
M
N

Hallerbach 2010

P

Schnieders 2006

P Imp

Machado 2011

P

Weidmann 2011

P

Charfi 2010

P

U
M
L

Razavian 2008

P Imp

Hadaytullah 2009

P

Sun 2010

P Imp

Jaroucheh 2010

P Imp

O
t
h
e
r
s

C-EPC

P Imp

C-YAWL

P Imp

Our work

7

C Both

42
2.4 Research gaps
Based on our analysis of related works, we have identified five research gaps that will be
addressed in this thesis. Figure 2.6 shows these research gaps in relation to other compo-
nents of SOA. The first two research gaps (i.e. Customisation framework and Interface
description language) are mainly concerned with the external view of service customisa-
tion (i.e. the use of customisable services from service consumers viewpoints). In
contrast, the other three research gaps (i.e. Provisioning architecture, Atomic service
realisation and Composite service realisation) are related to the internal view of service
customisation (i.e. how service providers prepare and provision customisable services).
For internal view, Provisioning architecture addresses challenges common to both
atomic and composite services, while atomic service realisation and composite service
realisation deal with issues specific to atomic services and composite services respective-
ly. The main difference between the last two is the composite service realisation needs to
take into account interactions with partner services. Note that while we separate research
gaps into external view and internal view, all of them will be addressed in a consistent
manner to enable a complete and end-to-end solution. We further describe each research
gap in following subsections.
2.4.1 Customisation framework
As a core requirement in supporting customisable services, it is essential to have an
efficient customisation mechanism. Such customisation mechanism enables service
consumers to customise services. In addition, service customisation requires automated
variability instantiation at both the service interface level and the service implementation
level. As discussed in section 2.2.4.2, to simplify the customisation process and efficient-
ly support service consumers, it is preferable to allow consumers to customise services at
the requirement abstraction level and then automatically propagate such decisions
downward the service interface and the service implementation (i.e. staged instantiation).

Figure 2.6 - Overview of research gaps
Customisation
framework
Atomic service
realisation
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
language
Composite service
realisation
1
2
3
4
5
2.4 Research gaps
43
As shown in Table 2.2, none of related work supports service customisation to the extent
discussed above.
2.4.2 Interface description language
The above mentioned customisation framework enforces additional interactions between
service providers and service consumers compared to conventional service consumption.
In other words, there are additional functions that need to be in place for the consumption
of customisable services. Specifically, service variability information needs to be com-
municated between service providers and service consumers. In addition, the
customisation procedure needs to be specified and enforced in a service-oriented way to
enable the loose coupling between service providers and service consumers. To enable
the customisation framework, all of these concerns need to be taken into account. An
interface description language addresses service variability characteristics related to
variability communication (i.e. Formality, Technology independence, and Self-
describing), as well as recursive variability instantiation. While only few related works
address concerns related to an interface description language (Stollberg et al.; Tosic 2002;
Liang 2006), their approaches are still limited as shown in Table 2.2. In addition, these
approaches are also limited with respect to supporting a customisation framework
described above. In particular, they only support automated variability instantiation at the
service interface level.
2.4.3 Provisioning architecture
There are additional functions that need to be performed internally by service providers
(or their service platforms) for the provisioning of customisable services. These functions
are: i) checking the validity of the customisation process, ii) dynamic derivation and
deployment of service variants, and iii) managing service variant lifecycle. These addi-
tional functions require the enhancement of existing service platforms for accommodating
customisable services. While the second function has been considered in related works
supporting automated variability instantiation at the service implementation level (e.g.
Schnieders 2007; Koning 2009), none of the approaches addresses the other two func-
tions. In addition, these approaches do not consider the correspondence between internal
variability instantiation and the external customisation framework. Provisioning architec-
ture addresses service variability characteristics related to the customisation framework
(i.e. Automated, Staged instantiation, Level (Interface/Implementation)) from service
platforms viewpoints.
44
2.4.4 Atomic service realisation
Given an architecture for provisioning customisable services, an important question is
how to engineer those customisable services? The engineering of customisable services
addresses concerns related to variability modeling and instantiation. With respect to
customisable atomic services, related works provide very limited support since they only
consider variability at the service interface level. Atomic service realisation needs to take
into account both exposed variability and composition variability, as well as supporting
automated variability instantiation at both the service interface level and the service
implementation level. In addition, the technique needs to be consistent with the external
view of service customisation (i.e. customisation framework and interface description
language).
2.4.5 Composite service realisation
With respect to customisable composite services, a major shortcoming of related works is
that they do not consider partner variability and are not able to capture variability inter-
dependencies. All approaches assume that partner services are non-customisable. Conse-
quently, those approaches are not applicable to composite services orchestrated from
customisable partner services. Composite service realisation needs to consider exposed
variability, composition variability, and partner variability. In addition, both variability
intra-dependencies and variability inter-dependencies need to be explicitly modeled.
Similar to atomic service realisation, composite service realisation needs to support
automated variability instantiation at both service interface level and service implementa-
tion level, as well as being consistent with the external view of service customisation.
2.5 Summary
In this chapter, we have identified characteristics of service variability that are important
for enabling the composition and delivery of customisable services. There are characteris-
tics which are inherited from software variability and characteristics which are specific to
service computing. We have then reviewed the literature according the identified charac-
teristics. Our review reveals five research gaps toward supporting customisable services.
Each research gap focuses on several characteristics of service variability. These research
gaps will be addressed individually in five chapters from Chapter 3 to Chapter 7 of this
thesis. Altogether, we will provide a comprehensive approach for enabling the use of
customisable services. For comparison, the characteristics of our approach are included in
2.5 Summary
45
Table 2.2. In the corresponding chapters (i.e. chapter 3 to chapter 7), we will analyse our
techniques in detail with respect to these characteristics.

47

3. Feature-based Service Customisation Framework
This chapter discusses our customisation framework that allows service consumers to
customise services (Figure 3.1). In section 3.1 of this chapter, we present a motivating
example which will be used throughout the chapter to demonstrate various concepts of
service customisation. We also describe a feature model which captures the service
variability of the motivating example. The feature model helps to illustrate how variabil-
ity is represented from consumers viewpoint. Section 3.2 presents the overview of the
customisation framework. We describe two operation modes of a customisable service
(i.e. customisation mode and consumption mode) as well as the benefits of separating the
two modes.
Section 3.3 discusses our key concepts of developing a customisable service as a
product family. We will explain the strong similarity between customisable services and
product families which inspires the design of our solution. The section also details how
service providers prepare services for customisation.
In section 3.4, we discuss the detail of the service customisation mode. In particular,
subsection 3.4.1 presents our ideas of exploiting feature models for representing customi-
sation options, as well as the benefits of the approach. We then explain how service
consumers can formulate customisation requests by specifying selected and disabled
features in subsection 3.4.2. We also discuss different variations of a customisation
requests (e.g. inferred customisation requests and optimised customisation requests)
resulted from relationships among features, as well as two types of customisation requests
(i.e. complete and partial customisation requests). In subsection 3.4.3, we describe the
internal process within a customisable service for validating customisation requests and
deriving service variants. We also compare differences when handling the two types of

Figure 3.1 - Focus of this chapter
This chapter
Customisation
framework
Atomic service
realisation
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
language
Composite service
realisation
1
Chapter 3 - Feature-based Service Customisation Framework
48
customisation requests. Subsection 3.4.4 discusses customisation responses with respect
to these two types.
We analyse our customisation framework against characteristics of service variabil-
ity that we identified in Chapter 2 in section 3.5. Section 3.6 concludes this chapter.
3.1 The Swinsure Insurance Web service and feature models
In this section, we present a motivating scenario which we use repeatedly in this thesis to
demonstrate various aspects of our feature-based service customisation framework. The
motivating scenario is about a customisable Web service provided by Swinsure Insur-
ance. The Swinsure Insurance is a wholesale building insurance provider that provides a
building insurance business to various consumers (i.e. insurance brokers). These con-
sumers range from small-size brokers, who only need to give end-users quotes on their
building insurance policies, to medium-size brokers, who also provide end-users options
on purchasing insurance policies, to large-size brokers, who offer various extra covers as
well as the ability to manage policies online. As such, these consumers require both
common service capabilities and unique service capabilities. Unique service capabilities
are specific to individual broker.
After analysing consumer requirements, the Swinsure Insurance has identified the
following commonalities and differences in the service capabilities of its Web service.
Note that the description of each following item is illustrated with relevant features
represented in the feature model in Figure 3.2.
With respect to the creation of insurance policies (i.e. feature Policy Creation),
all brokers need the service capability for providing a quote (i.e. feature Quote
with feature cardinality [1-1]), while some brokers also need the service capabil-
ity for purchasing a policy (i.e. feature Purchase with feature cardinality [0-
1]).
There are two alternative policy types (i.e. feature Policy Type with group
cardinality [1-1]) that brokers provide: residential policy (i.e. feature Residen-
tial) and business policy (i.e. feature Business). The policy types depend on
the purpose for which a building is occupied. If the building is used for residency
purposes, the policy type is residential. Otherwise, if the building is used for run-
ning a business, the policy type is business.
Some brokers need to provide extra covers (i.e. optional feature Extra Cover
with group cardinality [1-3]). There are three types of extra covers from which
these brokers are able to select at least one and at most three: accidental damage,
3.1 The Swinsure Insurance Web service and feature models
49
fusion cover, and extended third party liability (i.e. feature Accidental Dam-
age, Fusion Cover, and Extended Third Party Liability respectively).
Swinsure Insurance provides two alternative payment methods (i.e. feature
Payment Method) that brokers can choose for their end-users: Credit card or
cover note (i.e. feature Credit Card and Cover Note respectively).
Some brokers need to provide advanced capabilities for end-users to manage pol-
icies online. These capabilities include one for querying existing policies (i.e.
feature Policy Query) and one for updating existing policies (i.e. feature Pol-
icy Query).
Among these variabilities there are also constraints which come from service pro-
viders policies to confine targeting market segments:
While both the policy query and policy update capabilities are optional, only the
policy query capability might operate alone. The policy update capability always
requires the policy query capability for proper operation (i.e. constraint Policy
Update requires Policy Query).
While all extra covers are applicable to business policies, residential policies only
accept two extra covers: accidental damage and fusion cover. That is, residential
policies cannot accommodate the extra cover extended third party liability (i.e.
constraint Residential excludes Extended Third Party Liability).

Figure 3.2 - A feature model for Swinsure Insurance Web service
Swinsure Insurance Web Service
Policy Creation Policy Query Policy Update
Quote Purchase
[1-1] [0-1] [0-1]
[1-1]
Policy Type Extra Cover
Residential Business
[1-1] [0-1]
[1-1] [0-1]
[1-3]
Accidental Damage Fusion Cover
Payment Method
[1-1]
[1-1]
Credit Card Cover Note
Extended Third Party Liability
[a-b]
Feature
Cardinality
Feature
Group
Composed-of
Relationship
Feature
Legend
Constraints
Policy Update requires Policy Query
Residential excludes Extended Third
Party Liability
[a-b]
Group
Cardinality
50
To capture the commonalities and differences among capabilities of Swinsure Insur-
ance Web service as requested by the customers, we use a feature model as shown in
Figure 3.2. Through the use of feature hierarchy, feature and group cardinality, as well as
cross-tree constraints, the feature model efficiently captures the variability of the Web
service at the requirement level.
3.2 Overview of the customisation framework
A customisable service operates in two modes: customisation mode and consumption
mode (Figure 3.3). The customisation mode involves activities in which consumers
comprehend the service customisability and make customisation decisions. In addition,
this accommodates interactions for exchanging customisation requests and customisation
responses. Internally, customisable services react to customisation requests through a
sequence of activities: i) validating customisation requests, ii) deriving and deploying
service variants, and iii) managing those service variants. The result of this process (i.e. a
service variant) is communicated to service consumers in customisation responses. In our
approach, feature models play a significant role during the customisation mode for both
representing customisation options and enabling service variant derivation.
In the consumption mode, a consumer has access to a particular service variant. The
service variant is a conventional service which exposes the exact service capabilities that
the consumer requires. Other service capabilities required by other consumers with

Figure 3.3 - Overview of the customisation framework
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
Consumer
Customisation Request
Customisation Response
Consumption Request
Consumption Response
Customisation mode
Consumption mode
Customisation
engine
Service
variant
Payment type
Execution
Credit card
[1-1]
BPAY Bank transfer
[1-1]
[1-1]
Confirmation
Cheque
User notification
Swinpay Web Service
[0-1] [1-1]
Feature model
3.3 Customisable service as a product family
51
different requirements are not accommodated by this service variant. Consequently, the
service consumer does not have to worry about those irrelevant service capabilities. Note
that the consumption mode is the operation mode conducted by any conventional service.
The core part of the customisation framework is the realisation of the customisation
mode so that a conventional service is produced as a result of service customisation.
Section 3.3 of this chapter presents the motivation and section 3.4 presents the detail of
our approach that exploits feature models to implement this customisation mode.
3.2.1 Benefits of separating the two operation modes
As discussed above, the customisation mode is for exchanging service customisation
parameters, while the consumption mode facilitates the exchange of service consumption
parameters. The separation of these two modes helps to reduce overhead in the consump-
tion of service variants since service consumption requests do not need to repeatedly
contain customisation parameters when invoking service variants. Neither do service
providers have to repeatedly validate those customisation parameters for each incoming
service consumption request related to one service variant. In addition, the separation of
the two modes reduces the overhead of correlating service consumption messages
pertaining to one service variant (Papazoglou 2007). Consequently, this approach is
especially useful to such application delivery models as multi-tenanted SaaS (Software as
a Service) (Ghaddar 2012).
In addition, the separation of the two modes opens up the possibility that each mode
is operated by different entities. The customisation mode might be performed by business
analysts who are only concerned with business objectives of a service variant. They
customise the service by examining features, the relationships among features to formu-
late a feature set which most matches their business objectives (Nguyen 2011b) (This
benefit is further explained when we describe our feature-based service customisation
framework in section 3.4). In contrast, the consumption mode is performed by software
developers who actually execute the business integration between consumer business
applications and the resulting service variant.
There is a strong similarity between a product family and a customisable service. Firstly,
both represent a set of applications (or variants) which share many common capabilities.
And each application has distinct capabilities which help to differentiate one application
from another. Secondly, they both need to explicitly define and manage variability so that
52
the instantiation of such variability will help to derive applications tailored to the specific
needs of consumers. Thirdly, the development of customisable services is analogous to
the domain engineering process, while the actual service customisation is similar to the
application engineering process (Figure 3.4).
Due to this similarity and the success of SPL techniques in capturing and managing
variability, we base the development of customisable services on SPL techniques
(Nguyen 2010). In particular, during the domain engineering process, we use a feature
model to capture service variability at the requirement level. This feature model will drive
the identification and the introduction of variation points and variants in reusable soft-
ware artefacts for service implementation. In particular, variability in the software
architecture of a service
8
is the refinement of service variability in the feature model. And
variability in the service implementation is again the refinement of variability in the
software architecture. During the application engineering process, the feature model
facilitates the automatic derivation of particular service variants. From this section, we
use the term domain artefacts to refer to reusable software artefacts created during the
domain engineering process. In contrast, the term application artefacts is used to refer
to software artefacts produced during the application engineering process. Application
artefacts comprise service variants.
The concrete techniques for developing customisable services are dependent on the
type of services in question (i.e. atomic or composite). In Chapter 6 and Chapter 7, we
consider each type of services respectively and explain how we take into account SOC
specific concerns when adapting and extending SPL techniques. Here, we describe two

8
Software architecture of a service refers to service interface models for atomic services or
business process models for process-based composite services.

Figure 3.4 - Similarity between product families and customisable services
Domain Engineering Process
Application Engineering Process
Customisable Services Development
Service Customisation
Product Family Customisable Service
53
engineering techniques which are shared by both atomic and composite services: i) a
template approach for representing software variants
9
in domain artefacts, and ii) the
mapping between variant features and software variants.
It should be noted that the similarity between SPL and customisable services, as well
as the exploitation of SPL techniques in addressing service variability have been dis-
cussed in literature. However, there has not been a comprehensive solution for supporting
service variability and enabling service customisation as discussed in the literature review
in Chapter 2. As far as we know, we are the first to provide a complete solution for
enabling the use of customisable services.
3.3.1 A template approach for representing software variants
To develop domain artefacts during the domain engineering process for a customisable
service, it is essential to be able to capture software variants. There are generally two
approaches for capturing software variants: i) template approach (e.g. Czarnecki 2005b),
and ii) composition approach (e.g. Mietzner 2008b) (Figure 3.5). For the template
approach, software variants are embedded within the domain artefact that contains
variation points. Each domain artefact becomes the superset of application artefacts for all
service variants. During the application engineering process, only software variants
pertaining to one particular service variant are retained, while other software variants are

9
Software variants is a generic term to refer to variants in domain artefacts.

Figure 3.5 - Template approach versus composition approach
Service model
portType1
operation1
operation2
portType2
operation3
operation4
Service model 1
portType1
operation1
portType2
operation3
Service model 2
portType1
operation2
Domain artefacts Application artefacts
(for 2 service variants)
Service model
portType1
operation2
portType2
operation3
operation4
Non-
variable
Template approach Composition approach
operation1
Software
variants
Software
variants
Domain artefacts
Application
engineering
Application
engineering
54
purged from domain artefacts to produce application artefacts for one service variant. The
template approach is demonstrated on the left-hand side of Figure 3.5 where we consider
a service model as a domain artefact. As for the composition approach, software variants
are maintained separately from the domain artefact that contains variation points. During
the application engineering process, these software variants are composed with domain
artefacts to produce application artefacts specific to one service variant. The composition
approach is illustrated on the right-hand side of Figure 3.5.
The main benefit of the template approach compared to the composition approach
is three-fold. Firstly, the existence of different software variants with respect to the same
variation point is explicit to developers. Secondly, developers are able to consider
software variants within its usage context and in relation to other relevant software
artefacts. Thirdly, developers are able to directly recognise the impact of variability
resolution. Altogether, the template approach helps to increase variability comprehension
as well as ease variability instantiation. The downside of the template approach is that
domain artefacts generally have bigger size than their counterparts in the composition
approach. However, given the advances in improving the modularity and managing the
complexity of software products, we argue that this is not a significant problem. There-
fore, in our approach, we follow the template approach to capture software variants for
both atomic and composite services.
3.3.2 Mapping between variant features and software variants
In addition to using the template approach, all software variants within domain artefacts
are mapped to variant features to signify their availability in a service variant. In particu-
lar, each software variant will be associated with a propositional formula of variant
features. Throughout this thesis, we use the term presence condition to refer to the
propositional formula that decides the availability of software variants. This presence

Figure 3.6 - Overview of the domain engineering process for customisable services
Feature
model
Domain
engineering
Configurable
artefacts
Configurable
service
interface
Configurable
service
implementation
drive
result contain
mapped
3.4 Service customisation mode
55
condition is expressed as If the variant features A
1
, A
2
,, A
n
are selected and the variant
features B
1
, B
2
,, B
m
are disabled, this software variant is available. During the
application engineering process, the presence condition will be evaluated with respect to
one feature configuration. If the evaluation result is true, the software variant will be
retained in the domain artefact. Otherwise, the software variant will be removed from the
domain artefact. The mapping between software variants and variant features enables the
specialisation of domain artefacts to produce application artefacts of one service variant
corresponding to one feature configuration. Consequently, it enables the feature-based
service customisation framework as described in section 3.4. Note that the rationale for
the format of presence conditions will be discussed in corresponding sections when we
consider concrete domain artefacts (i.e. section 4.2.5, section 6.2, and section 7.4.2).
As the result of using the template approach and specifying the mapping between
software variants and variant features, the domain engineering process will produce
domain artefacts as configurable artefacts (Figure 3.6). These configurable artefacts will
be used to enable the customisation of the service and automatically derive particular
service variants matching consumer requirements.
In this section, we describe our solution for realising the service customisation mode. In
particular, we explain how we exploit feature models to represent customisation options,
customisation requests and responses. In addition, we define different variations of
customisation requests which produce the same service variants as the result of service
customisation. We also introduce two types of customisation requests (i.e. complete
customisation requests and partial customisation requests) which have different impacts
on the resulting service variants. Throughout the section, we use our formalization of
feature models to facilitate the explanation and support our concepts.
3.4.1 Feature models for representing customisation options
One key requirement for the customisation framework is the ability to efficiently present
customisation options to service consumers (or service brokers as in the motivating
scenario). This involves not only the classification and organisation of customisation
options, but also the description of dependencies among those customisation options. A
straightforward solution is representing customisation options as alternative service
capabilities captured at the service interface level (e.g. Liang 2006; Stollberg 2010).
However, this approach is relatively complex due to the large number of customisation
56
options in the technical service interface descriptions as well as complex dependencies
among those options. In contrast, feature models provide an efficient way to capture
service variability at the highest level of abstraction (i.e. the requirement level). There-
fore, we propose the use of feature models as a service description artefact for
representing customisation options (Nguyen 2010). The formal definition of customisa-
tion options in the form of a feature model is presented in Definition 3.1.
This formalization is based on the description of CBFM feature models (Czarnecki
2005c) discussed in Chapter 2. There are two important remarks regarding this definition:
CBFM allows the definition of arbitrary feature cardinality (e.g. feature cardinali-
ty with the upper bound greater than one) for supporting feature cloning (i.e.
multiple selections of the same feature) in a feature configuration (Czarnecki
2005d; Czarnecki 2005e)). However, in our research, we confine feature cardinal-
ity to define only always-selected or optional (i.e. might be selected or disabled)
features with respect to their parent features. In other words, the domain of fea-
ture cardinality is . This assumption is applicable to variability of all
service-based systems which have been considered in literature (e.g. Schnieders
2007; Sun 2009).
A similar observation and assumption applies to cross-tree constraints. While in
some cases, complex cross-tree constraints (e.g. the selection of both features A
Definition 3.1 - Customisation options
Customisation options are represented by a feature model which is a tuple

where:
is a set of features which can be partitioned into disjoint sets of mandatory
features M and variant features V,
is the hierarchical (or compose-of) relation, i.e. a set of parent
and child relationships,

is a function which maps each feature to its feature

cardinality,

is a function which maps a parent feature of a feature

group to a group cardinality where refers to the set of natural numbers in-
cluding 0, and
is a set of cross-tree constraints which can be partitioned into
disjoint sets of require constraints
and exclude constraints
.
57
and B exclude the selection of feature C) might be necessary, we only consider
simple require and exclude constraints (i.e. feature A requires/excludes fea-
ture B) in this thesis.
In general, customisation options are represented as a set of features and various re-
strictions among features (e.g. feature cardinality, group cardinality, or cross-tree
constraints). An example of customisation options based on the feature model in Figure
3.2 is shown in Example 3.1.
3.4.1.1 Advantages of exploiting feature models
Comparing to approaches exposing variability in the technical service interface de-
scriptions as customisation options, there are a number of advantages in exploiting feature
models (Nguyen 2011b):
Reducing complexity: As a characteristic of service variability, the number of
variation points and variants increases when we go down the levels of abstraction
at which variability is modeled. Variability at the requirement level exhibits few-
er variation points and variants compared to the service interface level. Therefore,
our approach simplifies the customisation task for service consumers.
Technical blindness: Since variability is described at the requirement level, ra-
ther than the technical level, consumers do not have to be familiar with technical
realisation of services in order to perform customisation. In addition, during the
customisation process, consumers are able to reason about what a service variant
can achieve at a high level of abstraction, rather than the differences in low level
technical details of each service variant.

Example 3.1 - An example of customisation options
58
Dependencies among customisation options: Instead of describing the depend-
encies among customisation options using natural languages, feature models
enable the capturing of these dependencies as cross-tree constraints. This pro-
vides a consistent way for representing customisation options and facilitates the
reasoning of customisation decisions. In addition, the capability also facilitates
the automated validation of customisation decisions (discussed in section 3.4.3.1).
3.4.2 Customisation request as selected and disabled features
Given customisation options represented by a feature model, service consumers will
customise the service by deciding the features they want (i.e. selected features) and
features they do not want (i.e. disabled features). This is similar to configuring a feature
model to derive a feature configuration. In our approach, the set of enabled features and
disabled features (i.e. a feature configuration) becomes consumers customisation
decisions and is contained in a customisation request to which service providers will
react.
We also define as the set of customisation request . An example of a customi-
sation request is presented in Example 3.2.
Customisation options comprise of a set of mandatory features, a set of variant fea-
tures, and restrictions among variant features. A customisation request helps to resolve
variability in the feature model. In other words, the state of a number of variant features
will be decided. This variability resolution helps service providers to resolve variability in
service implementations in order to derive appropriate service variants. The details of the
service variant derivation process will be discussed in the next section. Here we discuss
the semantics of customisation requests.
Definition 3.2 - Customisation request
Given customisation options
, a
customisation request is a 2-tuple of the form (S,R) being S the set of features to
be selected and R the set of features to be removed (or disabled).

Example 3.2 - A customisation request
59
A customisation request is specified by service consumers. It might be ill-formed
(e.g. containing non-existing features) or well-formed. In addition, due to the restrictions
among variant features, the state of undecided variant features might be inferred from the
state of variant features specified in a customisation request. This inference brings about
different variations of customisation requests which are equivalent with respect to
variability resolution (aka. semantically equivalent customisation requests). A customisa-
tion request might be complete or partial. A complete customisation request has the state
of all variant features decided (by directly specified or indirectly inferred), while for
partial customisation requests the state of one or more variant features cannot be inferred
and is undecided. Lastly, a customisation request might be valid or invalid. Valid custom-
isation requests conform to customisation options (or the feature model) and can be used
for variability resolution while invalid customisation requests are not.
In the following subsections, we provide formal definitions and examples of differ-
ent variations and different types of customisation requests.
3.4.2.1 Ill-formed and well-formed customisation requests
An ill-formed customisation request explicitly violates the restrictions specified by a
feature model. It is meaningless with respect to variability resolution in the feature model,
as well as in the service implementation. Since customisation requests are specified by
service consumers, it is unavoidable for service providers to receive such ill-formed ones.
It is service providers role to verify the well-formedness of customisation requests
10
.

10
In Chapter 4, we discuss alternative approaches for service providers to realise the customisation
framework. One approach is that service providers prepare a dedicated UI (User Interface) (e.g. a
Web application) which service consumers can use to specify customisation requests. This
Definition 3.3 - Ill-formed and well-formed customisation requests
and a
customisation request . is said to be ill-formed if it has any of
following violation properties:
i. a non-existing feature is specified, i.e. or
ii. there exists a feature which is both selected and disabled, i.e. ,
iii. there exists a mandatory feature which is disabled, i.e. .
Otherwise, is called well-formed.
60
3.4.2.2 Inferred customisation request
A customisation request and its inferred versions are equivalent with respect to variability
resolution. A customisation request might be well-formed but one of its inferred versions
might become ill-formed. Therefore, expanding a customisation request by inferring more
features not only produces different variations of the customisation request, but also helps
to verify the conformance of the customisation request with respect to the feature model.
There are different rules for inferring additional features depending on restrictions
under consideration. The list of restrictions and the corresponding inference rules are as
follow (Batory 2006; Mendona 2008; Benavides 2010).
Mandatory features : Since mandatory features must not be disabled, any
mandatory feature which is not yet selected might be added to . For instance,
from the customisation request (Example 3.2), we can add the features
SwinsureInsuranceWebService and PolicyCreation to its selected feature list
(Example 3.3).
Feature hierarchy: A hierarchical relation implies that when a child feature is
selected, the parent feature must be selected as well. For instance, from the cus-
tomisation request (Example 3.3) in which the feature Accidental Damage

approach helps to avoid the use of ill-formed customisation requests. However, the approach has a
number of disadvantages so that we choose an alternative one which allows service consumers to
arbitrarily specify customisation requests.
Definition 3.4 - Inferred customisation request
and a
customisation request , an inferred customisation request
is a new customisation request that is inferred from by analysing

restrictions enforced by FM to add more feature(s) to either or or both, i.e.
, , and .

Example 3.3 - An inferred customisation request after adding mandatory
features
61
is selected, it is possible to conclude that the feature Extra Cover must be se-
lected (Example 3.4).
Group cardinality
: Given a feature group with the upper bound of its group

cardinality is n, if n grouped features are selected, all other grouped features can
be added to the disabled set. For instance, from the customisation request
(Example 3.4) in which the feature Residential is selected and the group cardi-
nality of the feature Policy Type is [1-1], it can be inferred that the feature
Business is disabled (Example 3.5).
This rule provides a simple way to check the conformance of a customisa-
tion request with respect to a group cardinality restriction. Suppose the upper
bound of the group cardinality for a feature group is n and more than n grouped
features are selected in one customisation request, any these grouped features can
also be added to the disabled set. This makes the inferred customisation request
ill-formed since it has the second violation property (cf. Definition 3.3)
Cross-tree constraints : A require relationship (e.g. f1 requires f2) implies

Example 3.4 - An inferred customisation request after considering the feature
hierarchy

Example 3.5 - An inferred customisation request after considering group
cardinalities

Example 3.6 - An inferred customisation request after considering cross-tree
constraints
62
that when f1 is selected, f2 must be selected or when f2 is disabled, f1 must be
disabled. Similar inference applies to exclude relationships. For instance, from
the customisation request (Example 3.5) and feature constraints as shown in
Example 3.1, it is possible to conclude that the features Policy Update and
Extended Third Party Liability must be disabled (Example 3.6).
3.4.2.3 Maximally inferred customisation request
Restrictions in a feature model might be applied multiple times until no further inference
is possible. The final customisation request is defined as maximally inferred customisa-
tion request. For instance,
(Example 3.6) is the maximally inferred customisation

request from .
Restrictions might be applied in different orders to a customisation request. Howev-
er, regardless of ordering, we can always reach a maximally inferred customisation
request. In addition, the resulting maximally inferred customisation requests are always
the same. This property can be proved as follows in two steps.
Property 1:
The inference process has finite steps.
Proof:
As defined in Definition 3.4, each time a restriction is applied to a customisation re-
quest, at least one feature in the feature set is added to either the selected feature set or
the disabled feature set such that . Since the number of features in the
feature set is finite, the inference process has finite steps
Property 2:
The maximally inferred customisation request is unique.
Proof:
Assume that there exist two maximally inferred customisation request
and
from the original customisation request . Since

Definition 3.5 - Maximally inferred customisation request
and a
customisation request , a customisation request
is
defined as the maximally inferred customisation request from CR if
is an inferred
customisation request and there does not exist an inferred customisation request from
.
63
is an inferred customisation request, from Definition 3.4 we have
and

. Therefore, if we analyse restrictions to
in the same ordering that we can

infer
from , we are able to add
and
to the respective sets of selected

features and disabled features in
. In other words, we have a new customisation

request
) which is possibly an inferred customisa-

tion request from
. However, as stated in Definition 3.5,
cannot be further
inferred. Therefore,
or

Equation 3.1

Equation 3.2
In a similar way, we also have

Equation 3.3

Equation 3.4
Since
and
, we have

Equation 3.5

Equation 3.6
Expand the left hand side of Equation 3.1 with Equation 3.5 and recall that union
operation is associative we have

Equation 3.7
Compare the left hand side of Equation 3.3 with the left hand side of Equation 3.7
and recall that union operation is symmetric, we can conclude that
. In a similar
fashion, we have
. Therefore

To facilitate our explanation, we also define maximise function as below.

Definition 3.6 - Maximise function
, a
maximise function F
MA X
: is a function which maps a customisation
request to its maximally inferred customisation request.
64
3.4.2.4 Normalised customisation request
Since all mandatory features must be selected, customisation decisions are in fact made
against variant features only. As defined in Definition 3.3, mandatory features should not
be specified as disabled to make a customisation request well-formed. In addition, there is
no need to specify mandatory features in the selected feature list. To simplify customisa-
tion requests, we introduce the concept of normalised customisation requests (Definition
3.7) and normalise function (Definition 3.8).
3.4.2.5 Optimised customisation request
Optimised customisation requests are the most complete and succinct form of customisa-
tion requests. There does not exist an undecided variant feature that can be further
inferred from these optimised customisation requests. In addition, it does not require the
unnecessary specification of mandatory features in its selected feature list. While opti-
mised customisation requests are semantically equivalent to the original customisation
Definition 3.9 - Optimised customisation request
and a
customisation request , an optimised customisation request
is the normalised customisation request of the maximally inferred customisa-

tion request from , i.e.
F
N O R M
(F
M A X
( )).
Definition 3.8 - Normalise function
, a
normalise function F
N O R M
: is a function which maps a customisation
request to its normalised customisation request.
Definition 3.7 - Normalised customisation request
and a
customisation request , a normalised customisation request
is the result of pruning mandatory features from such that

and
.
65
requests, they provide a better view of variability resolution at the feature level (i.e. what
variant features have already been decided and what variant features require further
decision) than the original ones. Consequently, optimised customisation requests help to
resolve variability in the service implementation to its maximal extent. An example of
optimised customisation requests inferred from the customisation request (Example
3.2) is shown in Example 3.7.
Another advantage of optimised customisation requests is the support in validating a
customisation request. We will discuss this advantage in section 3.4.2.6. It should be
noted that the optimised customisation request, normalised customisation requests,
inferred customisation requests are all semantically equivalent to the original customisa-
tion request. Consequently, the resulting customisation responses are the same regardless
of what variation of a customisation request is sent from service consumers. On the other
hand, the consideration of only optimal customisation requests helps to simplify the
explanation while not losing its generality.
3.4.2.6 Valid customisation request
Given all the operations to expand and simplify a customisation request following
restrictions defined in a feature model, we are able to define the validity of customisation
requests. A valid customisation request conforms to the feature model and can be used to
resolve variability in the feature model as well as variability in service implementation. In
contrast, invalid customisation requests cannot help to resolve variability.
The well-formedness and the validity of a customisation request are not the same.
An ill-formed customisation request is certainly invalid. However, even a well-formed
customisation request might be invalid if after expanding it to reach its optimised version,

Example 3.7 - An optimised customisation request
Definition 3.10 - Valid customisation request
, a
customisation request is valid if its optimised customisation request
is well-formed.
66
we get an ill-formed one. For instance, the customisation request
is well-formed. However, based on the
inference rule for require constraints, we are able to derive an inferred customisation
request which is ill-formed. As
such, ill-formed customisation requests explicitly violate constraints defined in the feature
model, while invalid well-formed customisation requests implicitly violate those con-
straints. Such violation only reveals when we expand the customisation request based on
restrictions among features. Well-formed customisation requests which are till well-
formed after their expansion based on all restrictions are valid customisation requests.
3.4.2.7 Complete and partial customisation requests
A customisation request might be complete or partial. In a complete customisation
request, the state of all variant features has already been decided. There is not any
variability left unresolved in the feature model. In contrast, a partial customisation request
leaves one or more variant features undecided. Partial customisation requests only
partially resolve variability in the feature model.
The completeness of customisation requests defines the extent to which variability in
the feature model should be resolved. For instance,
(Example 3.7) is a partial

customisation request while the
(Example 3.8) is a complete customisation requests.

Note that both complete and partial customisation requests might not be valid. In other
words, customisable services can only be customised with respect to valid complete or
valid partial customisation requests.
Definition 3.11 - Complete and partial customisation requests
, a
customisation request is said to be complete if its optimised customisa-
tion request
has all variant features decided, i.e.
.
Otherwise, when there exist variant feature undecided, i.e.
, is
said to be partial.

Example 3.8 - A complete customisation request
67
3.4.3 Feature-based service variant derivation
In the previous section, we discussed different variations of a customisation request, its
validity, as well as its completeness with respect to variability. In this section, we discuss
the internal activities within service providers to process those customisation requests.
3.4.3.1 The validation of customisation requests
Customisation requests are specified by service consumers and can be arbitrary. There-
fore, customisation requests need to be validated before being processed further. The
validation of a customisation request is similar to the validation of the feature configura-
tion contained in the customisation request with respect to a feature model. This
validation is one among many operations for automated analysis of feature models. The
validation is generally performed by translating both the feature model and the feature
configuration to propositional formulas in which features become propositional variables.
A satisfiability solver or SAT solver (En 2004; Mari 2009) is then used to determine if
those propositional formulas are satisfiable (i.e. the customisation request is valid)
(Batory 2006; Benavides 2010). Section 6.4.1 of this thesis discusses our prototype
implementation for validating customisation requests based on this approach.
3.4.3.2 Service variant derivation
Given a valid customisation request, the customisation engine will derive and deploy a
service variant. The feature configuration encapsulated in the customisation request will
drive this derivation process so that a service variant is automatically generated. The

Figure 3.7 - Overview of service variant derivation process
Feature
configuration
Variability
instantiation
Configurable
artefacts
Service
variant
Configurable
service
interface
Configurable
service
implementation
Variant
service
interface Variant
service
implementation
Feature
model
mapped
input
input
output
contain
contain
68
overview of this derivation process is demonstrated in Figure 3.7.
As the result of the domain engineering process (Figure 3.6), a customisable service
is developed as configurable artefacts which represent both configurable service interface
and configurable service implementation. All software variants within these configurable
artefacts are mapped to variant features in the feature model. The variability instantiation
process takes into account this mapping and propagates customisation decisions at the
feature level to the configurable artefacts so that variation points within domain artefacts
are resolved. The result of the process is a service variant represented as a variant service
interface and a variant service implementation.
3.4.3.3 Handling complete and partial customisation requests
As defined in section 3.4.2.7, a valid customisation request might be complete or partial.
These two types of customisation requests have different usage contexts. For complete
customisation requests, since all variabilities in the feature model have already been
decided, all variation points in configurable artefacts are resolved. Consequently, the
resulting service variant has determined behavior and is ready to be invoked by end-users
(Figure 3.8). In contrast, partial customisation requests do not contain sufficient infor-
mation to resolve all variant features. Consequently, a number of variation points in
configurable artefacts are left un-resolved. The resulting service variant still has undeter-
mined behavior and is not ready to be consumed by end-users. Instead, the resulting
service variant is still a customisable service with refined variability (i.e. more limited
customisation options). Therefore, partial customisation requests are useful when service

Figure 3.8 - Complete customisation versus partial customisation
Complete
customisation
input
Complete
customisation
request
input
Broker
result
Determined
service variant
Second-tier
broker
Partial
customisation
input
Partial
customisation
request
input
Broker (aka.
First-tier broker)
result
Refined
customisable service
End-user
consume consume
69
brokers (aka. first-tier brokers) wish to re-broker customisable services to second-tier
brokers with refined customisation options. The use of partial customisation requests
enables multi-stage service customisation by multi-tier brokers.
While for either case, the result of the variant derivation process is a service variant,
we will use two terms Determined service variant and Refined customisable service
in this thesis when we need to explicitly distinguish the two cases. As an example, let us
consider a customisation request shown in Example 3.9. Customising the Swinsure
Insurance Web Service based on this customisation request will result in a new customis-
able service for getting quotes related to residential building insurance policies.
Consumers of the new customisable service (i.e. second-tier brokers) are still able to
customise two extra covers (i.e. Accidental Damage and Fusion Cover) as well as
choose to disable or enable policy purchase with an appropriate payment method.
3.4.4 Customisation response
The result of the customisation process is various depending on the type of customisation
requests. For complete customisation requests, determined service variants are conven-
tional services. Therefore, customisation responses will be the service interface
descriptions of those services (i.e. WSDL descriptions) or the URIs from which the
WSDL descriptions can be retrieved. In the case of partial customisation requests,
customisation responses should give second-tier brokers the ability to comprehend and
customise the refined customisable services in a similar way to what first-tier brokers do
with the original customisable services. In Chapter 4, we introduce a language, called
WSVL (Web Service Variability description Language) for describing customisable
services and facilitating first-tier brokers in customising the services. Hence, for partial
customisation requests, customisation responses will be the WSVL descriptions of refined
customisable services or the URIs from which the WSVL descriptions can be retrieved.

Example 3.9 - A partial customisation request
70
3.5 Analysis of the customisation framework against service
variability characteristics
We analyse our customisation framework against characteristics of service variability that
we identified in Chapter 2. In particular, the customisation framework has addressed the
following characteristics (cf. Figure 3.9):
Who (Provider/Consumer): In our customisation framework, service consumers
are presented with customisation options which are specified by a feature model.
Consumers are able to decide features they want and features they dont want ac-
cording to their requirements. Based on consumer decisions, service providers
derive service variants matching specific needs of service consumers. Therefore,
the customisation framework supports service consumers as the ones who per-
form customisation.
Automated: While engineering techniques are dependent on the type of services
(i.e. atomic or composite)
11
, both atomic services and composite services are de-

11
The details of these engineering techniques will be discussed in Chapter 6 (for customisable
atomic services) and Chapter 7 (for customisable composite services).

Figure 3.9 - Service variability characteristics addressed in this chapter
Service variability
Internal
Composition
variability
Partner
variability
External
Automated Inter-
dependencies
Exposed
variability
Variability
communication
independence
Self-
describing
Staged
instantiation
Who
(Provider/
Consumer)
Level
(Interface/
Implementation)
level
Requirement
Architecture Implementation
Variation
points and
variants
Variability
constraints
Intra-
dependencies
Customisation mechanism
3.5 Analysis of the customisation framework against service variability
characteristics
71
veloped as configurable artefacts. In particular, service variability at the highest
level of abstraction (i.e. the feature model) is refined to configurable points (i.e.
variation points and variants) in the software architecture, then to configurable
points in the implementation of the service during the domain engineering pro-
cess. This enables the comprehensive modeling of variability in configurable
artefacts. In addition, the presence conditions of software variants in such config-
urable artefacts are captured. This enables the automated derivation of service
variants according to the feature configuration contained in a customisation re-
quest.
Requirement abstraction level: Service variability is modeled at the requirement
level by means of feature models. In addition, service consumers are allowed to
customise services at this level of abstraction. As discussed in section 2.2.4.2,
modeling service variability and enabling service customisation at the require-
ment level help to reduce consumer overhead of dealing with a large number of
customisation options.
Staged instantiation: In our customisation framework, we maintain the mapping
between variability in the feature model and variability in configurable artefacts.
This mapping defines the presence conditions of software variants in configurable
artefacts as propositional formulas of variant features. Consequently, the mapping
enables the propagation of customisation decisions (i.e. feature configurations) at
the feature level towards lower levels of abstraction during the service variant
derivation process. In other words, our customisation framework supports staged
instantiation and helps to simplify service customisation.
Level (I nterface/Implementation): During the domain engineering process, vari-
abilities in domain artefacts (i.e. both service interface and service
implementation) are explicitly captured by exploiting the template approach. In
addition, the identification of such variabilities is all driven by high-level service
variability captured in the feature model so that they are consistent to each other.
During the application engineering process, variability instantiation is performed
at both the service interface level and the service implementation level by collec-
tively pruning unnecessary elements from domain artefacts.
The explanation of some characteristics (i.e. Automated, Staged instantiation and
Level (I nterface/Implementation)) is not comprehensive due to the missing details of
concrete techniques. We will re-analyse these characteristics in Chapter 6 and Chapter 7
when we present techniques for engineering atomic and composite services respectively.
72
3.6 Summary
In this chapter, we have described a feature-based approach for realising the customisa-
tion framework. A customisable service operates at two modes: customisation mode and
consumption mode. The customisation mode enables the customisation of the service to
produce service variants that are conventional services. Service variants are consumed in
the consumption mode in a same way as conventional services. To realise the customisa-
tion mode, we exploit the concept of feature models. In particular, we use a feature model
to capture service variability and represent customisation options. Service consumers are
able to customise services by specifying selected features and disabled features in
customisation requests. There are different variations of customisation requests. In
addition, a customisation request might be valid or invalid, complete or partial. We also
discussed the internal behavior of customisable services to produce customisation
responses. The internal realisation of customisable services is based on SPL techniques.
In particular, a customisable service is developed as configurable artefacts where all
configuration points are mapped to variant features. The mapping enables the automated
derivation of service variants given a feature configuration contained in customisation
requests. The internal behavior of a service will be slightly different with respect to
complete and partial customisation requests. We also explained in the chapter how the
approach addresses service variability characteristics and enables an efficient customisa-
tion framework. This chapter discussed our key concepts in supporting customisable
services. In the following chapters, we present our techniques to realise these concepts,
and enable the composition and delivery of customisable services.

73

4. Web Service Variability Description Language (WSVL)
This chapter discusses WSVL (Web Service Variability description Language) which is
our extension of WSDL for describing the service interface of customisable services. A
WSVL document plays the role of a customisation contract which specifies and enforces
the use of service variability information. It formalises the interactions between service
providers and service consumers so that the customisation framework can be realised in a
service-oriented way. WSVL is our approach for an interface description language
(Figure 4.1).
Section 4.1 discusses motivations for a customisation contract. In particular, we de-
scribe three functions that a customisable service should perform with respect to service
consumers: i) variability communication, ii) service customisation, and iii) variant
provisioning. The first two functions are specific to customisable services, while the last
function is also performed by conventional Web services. We discuss alternative options
for the realisation and the provisioning of these three functions in subsection 4.1.1 and
4.1.2 respectively. Based on these discussions, we propose the concept and describe the
benefits of customisation contracts in subsection 4.1.3.
In section 4.2, we describe WSVL in detail. There are four types of information cap-
tured in a WSVL document: i) customisation options, ii) customisation endpoint, iii)
service capability, and iv) feature mapping. After presenting the overview of the language
in subsection 4.2.1, we elaborate each type of information in a separate subsection. The
explanation is demonstrated with examples from a WSVL document describing the
Swinsure Insurance Web service presented in Chapter 3. While the semantics of each
type of information is constrained by our WSVL XML schema, there are additional

Customisation
framework
Atomic service
realisation
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
language
Composite service
realisation
2
This chapter
Chapter 4 - Web Service Variability Description Language (WSVL)
74
restrictions which cannot be enforced by the schema. When appropriate, we will discuss
these additional restrictions in the corresponding subsections.
Section 4.3 presents our MDE (Model-Driven Engineering) techniques for engineer-
ing WSVL documents. The techniques enable the creation of WSVL documents which
not only conform to the WSVL XML schema but also satisfy additional restrictions
discussed in section 4.2. After describing the overview of engineering techniques in the
subsection 4.3.1, we dedicate each individual subsection for discussing techniques and
prototype tools for developing one type of information in WSVL. The validation of
additional restrictions is also discussed respectively. In the last subsection 4.3.5, we
present a transformation technique which helps developers verify the correctness of
engineering models before generating a WSVL document.
In section 4.4, we evaluate the use of WSVL against characteristics of service varia-
bility that we identified in Chapter 2. We then conclude the chapter in section 4.5.
4.1 Motivations for WSVL
There are three functions that a customisable service should perform with respect to
service consumers (Figure 4.2). The first function, called variability communication,
enables the specification and the exchange of service variability information. This
function is necessary to advise customisation options to service consumers, as well as
facilitates service consumers in using service variability. The second function, called
service customisation, allows consumers to customise the service and derive service
variants. The third function, called variant provisioning, refers to the provisioning of
service variants with particular service capabilities matching consumer requirements. The

Figure 4.2 - Overview of WSVL
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
Consumer
Service customisation
Variant provisioning
Customisation
engine
Service
variant
WSVL
Variability communication
4.1 Motivations for WSVL
75
first two functions are performed in the customisation mode, while the last function is
conducted in the consumption mode described in Chapter 3.
The variant provisioning function is the fundamental function which is also per-
formed by conventional Web services using the messaging paradigm
12
(Chappell 2004),
while the other two functions are specific to customisable services. The implementation
and the provisioning of these two functions in a proper way help to broaden the use of
customisable services. In the following sub-sections, we discuss these two functions and
their alternative realisation in detail. The discussion leads to the concept of customisation
contracts for customisable services.
4.1.1 Exploiting the messaging paradigm for implementing the service
customisation function
There are two alternative approaches for implementing the service customisation func-
tion. In the first approach, the service customisation function is performed through a
dedicated UI (User Interface) (e.g. a Web application) prepared by service providers.
Service consumers use the UI to select and disable features to formulate customisation
requests. The submission of customisation requests then triggers the customisation engine
to derive service variants. In contrast, the second approach exploits the messaging
paradigm used by conventional Web services. Specifically, service providers explicitly
specify the service customisation function as sets of exchanged customisation messages
(i.e. customisation requests and customisation responses). Consumers are free to use any
method or technology for invoking the service customisation function.
A dedicated UI provides a simple way to implement service customisation function.
However, there are a number of disadvantages. Firstly, the UI might (and very likely)
vary from one service provider to another. For each service to be customised, service
consumers are restricted to one specific mechanism (e.g. graphical notations, designs) for
customising services. Consequently, the variation in UI will increase consumer overhead
when a consumer needs to consume a number of customisable services from different
providers. Secondly, a dedicated UI cannot support dynamic service customisation. In
such dynamic environments as service ecosystems where there exist variability inter-
dependencies
13
between customisable composite services and customisable partner
services, it is required that the customisation of the composite services will automatically

12
By messaging paradigm, we mean that the capability of conventional Web services are
described through an explicit specification of request messages and response messages.
13
Variability inter-dependencies will be further discussed in section 4.2.6.2.
76
trigger the customisation of partner services. This dynamism is not possible with a static
dedicated UI. Thirdly, the use of dedicated UIs makes it difficult for service consumers to
integrate service customisation process into their own development environments.
Typically, customisation procedure is not explicit and is not abstracted as an API (Appli-
cation Programming Interface). The missing of such API hinders its integration.
In contrast to dedicated UIs, the explicit specification of customisation requests and
customisation responses using the messaging paradigm opens up the opportunity for
service consumers to have a consistent way of performing service customisation regard-
less of who and how many service providers are involved. In addition, service consumers
are able to dynamically customise services based on their runtime needs. Last but not
least, service consumers are able to incorporate service customisation as an integral part
of their software development environments. Given these advantages, in our approach,
we exploit the messaging paradigm for realising the service customisation function.
Specifically, the service customisation function is explicitly specified as a set of customi-
sation requests and customisation responses.
4.1.2 Exposing service variability at both feature level and technical level in
service variability communication
Variability communication refers to the description and exchange of service variability
information to guide service consumers in using a customisable service. There are two
types of service variability information which is useful to consumers. Firstly, customisa-
tion options (i.e. service variability at the feature level) facilitate service consumers in
comprehending and utilising the service customisation function. Secondly, the description
of common and variant service capabilities (i.e. service variability at the service interface
level) allows consumers to reuse service variability.
In some circumstances, service consumers are not only concerned with the capability
of one particular service variant after customisation, but also interested in variant service
capabilities (i.e. service variability at the service interface level) among multiple service
variants before customisation. For instance, a service consumer might have variable
requirements and the service consumer needs to dynamically associate those require-
ments with those variant service capabilities. Depending on runtime conditions, the
service consumer will switch between different service variants by performing service
customisation on-the-fly. We refer to this usage as the reuse of service variability
14
.
While dynamic service customisation is already supported by the service customisation

14
Service variability reuse will be demonstrated with an example in section 4.2.6.2.
4.2 Web Service Variability description Language (WSVL)
77
function, the reuse of service variability is only possible if variant capabilities are also
exposed as a part of service variability information.
In summary, to broaden the use of customisable services, it is important to expose
service variability information at both the feature level and the service interface level.
This is the exposed variability discussed in Chapter 2.
4.1.3 Customisation contracts and WSVL
Given the requirements of specifying the service customisation function using the
messaging paradigm as well as exposing service variability information at both the
feature level and the service interface level, we propose the use of XML-based customisa-
tion contracts for customisable services. While such description might be informally
specified using natural languages, the use of a formalised customisation contract (i.e.
based on a standardised XML schema) will have the following benefits:
Variability communication is simplified to describing customisation contracts,
while the exchange of customisation contracts can be performed in a similar way
to the exchange of WSDL-based service contracts.
Service variability descriptions and service customisation are consistent among
all service providers.
Service consumers are only bound (aka. coupled) to the standardised customisa-
tion contract not the realisation of the customisable service, thus enabling loose
coupling between service providers and service consumers.
A formalised description facilitates the automation in using the customisable ser-
vice. For instance, it enables the automated generation of elements for modeling
variant service capabilities at the consumer side
15
.
In the subsequent section, we describe WSVL which is our extension of WSDL for
describing customisation contracts.
4.2.1 Overview of WSVL
WSVL is an extension of WSDL (Christensen 2001)
16
for describing customisable
services. Similar to WSDL, WSVL is specified by an XML schema. And a WSVL

15
This automated generation will be discussed in section 7.5.1.
78
document representing a customisation contract is an XML document which contains
XML elements defined by both the WSVL XML schema and the WSDL XML schema. A
WSVL document captures four types of information: customisation options, customisa-
tion endpoint, service capability, and feature mapping (Figure 4.3). In the following
sections, we describe each of these types in detail. All examples are snippets of a WSVL
document for the Swinsure Insurance Web service (cf. section 3.1)
17
. While key concepts
of WSVL are explained here, the full WSVL XML schema is presented in the Appendix
A.
4.2.2 Description of customisation options
Customisation options are important information for service consumers to understand and
customise a service. As defined in Chapter 3, customisation options are represented by a
feature model. Therefore, we define XML notations for representing feature models.
These XML notations capture two pieces of information: feature hierarchy and feature
constraints.

16
While there are two version of WSDL (i.e. WSDL 1.1 and WSDL 2.0), we design WSVL as an
extension of WSDL 1.1 due to its popularity and widespread adoption. However, two versions are
relatively similar and our extension can also be applied to WSDL 2.0 and yield the similar result.
17
A complete WSVL document for the Swinsure Insurance Web service can be found from
Appendix B or our prototype system deployed on Amazon cloud: http://ec2-107-21-175-
19.compute-1.amazonaws.com:8080/swinsureCustomizationFrontend?wsvl.

Figure 4.3 - Components of WSVL
Description of customisation options
Description of customisation endpoint
Description of service capability
Description of feature mapping
Web Service Variability description Language (WSVL)
79
A feature hierarchy description captures the hierarchy of a feature model using XML
elements <<wsvl:feature>> and <<wsvl:featureGroup>>. In addition, we use contain-
ment relationships among XML elements to represent composed-of relationships in
feature models. To represent feature cardinalities and group cardinalities, we define two
properties (i.e. minCardinality and maxCardinality) for corresponding elements (i.e.
<<wsvl:feature>> and <<wsvl:featureGroup>>).
A feature constraint description captures cross-tree constraints among features. We
define elements <<wsvl:requireConstraint>> and <<wsvl:excludeConstraint>> for
describing require and exclude constraints respectively. Feature constraints refer to
feature elements defined in the feature hierarchy part. Example 4.1 is a snippet of the
customisation options description. In this and other examples, our XML notations are
defined in the namespace with the prefix wsvl:, while WSDL notations are used with
the prefix wsdl:.
There are a number of techniques in literature for representing feature models in
XML (e.g. Antkiewicz 2004; Cechticky 2004; Benavides 2005). Our XML notations are
adapted from (Cechticky 2004; Benavides 2005) with the following modifications:
We represent feature cardinalities and group cardinalities as XML attributes ra-
ther than XML elements to improve readability.
Example 4.1 - Description of customisation options

<wsvl:featureHierarchy>
<wsvl:feature name=PolicyQuery" minCardinality=0" maxCardinality="1/>
<wsvl:feature name="PolicyCreation" minCardinality="1" maxCardinality="1">
<wsvl:feature name="Quote" minCardinality="1" maxCardinality="1">
<wsvl:feature name="PolicyType" minCardinality="1" maxCardinality="1">
<wsvl:featureGroup minCardinality="1" maxCardinality="1">
<wsvl:feature name="Residential/>
<wsvl:feature name="Business/>
</wsvl:featureGroup>
</wsvl:feature>
</wsvl:feature>
</wsvl:feature>
</wsvl:featureHierarchy>
<wsvl:featureConstraint>
<wsvl:requireConstraint>
<wsvl:featureRef ref="fd:PolicyUpdate"/>
<wsvl:requiredFeatureRef ref="fd:PolicyQuery"/>
</wsvl:requireConstraint>
<wsvl:excludeConstraint>
<wsvl:featureRef ref="fd:Residential"/>
<wsvl:excludedFeatureRef ref="fd:ExtendedThirdPartyLiability"/>
</wsvl:excludeConstraint>
</wsvl:featureConstraint>
80
We do not use macro elements since in WSVL there is no requirement for the ex-
tension of this representation.
We do not differentiate different types of features (i.e. solitary features or
grouped features) since we do not need to directly support reasoning on this rep-
resentation of feature models.
It should be noted that our XML notations are only one possible solution for the de-
scription of customisation options. Other alternative representations could also be used
within the WSVL for the same purpose. The emphasis is the role of the representation of
feature models within the WSVL, rather than the representation itself.
4.2.2.1 Restrictions on customisation options
While the WSVL XML schema enforces the constraints on the well-formedness and the
validity of a WSVL document, there are still restrictions that cannot be enforced by an
XML schema. These restrictions come from the semantics of customisation options as a
representation of a feature model.
A feature model represents a family of service variants. The number of complete fea-
ture configurations
18
derived from a feature model defines the number of determined
service variants. For a feature model to be meaningful, the number of complete feature
configurations should be greater than one. When the number of complete feature configu-
rations is one, the service in question is not customisable at all. And an invalid feature
model does not have even one complete feature configuration. For instance, Figure 4.4
demonstrates an invalid feature model. The two features f1 and f2 are alternative while
there exists a require constraint between the two.

18
A complete feature configuration has the status of all variant features decided (cf. section 2.1.3).
And service customisation with respect to a complete customisation request, which contains a
complete feature configuration, results in a determined service variant (cf. section 3.4.3.3).

Figure 4.4 - Example of an invalid feature model
Root feature
f1 f2
[1-1]
require
81
Therefore, a feature model (aka. customisation options) should accommodate more
than one complete feature configuration (aka. service variant) to be meaningful. This
restriction cannot be enforced by an XML schema. Instead, it should be validated when
the feature model is developed. We discuss this issue in section 4.3 when we consider the
engineering of WSVL documents.
4.2.3 Description of customisation endpoint
The customisation endpoint description specifies complete information related to the
service customisation function. The description specifies the abstract definition of the
customisation function through the definition of a set of customisation operations and
their customisation messages. With respect to the concrete definition of the customisation
function, the description contains information about mapping such customisation messag-
es to transport and messaging protocols, and information about endpoints where
customisation operations can be invoked.
As described in Chapter 3, for each customisation operation, the customisation re-
quest contains two sets of variant features (i.e. a set of selected variant features and a set
of disabled variant features). A customisation request might be complete or partial
depending on purposes of service consumers. As for a complete customisation request,
the customisation response might contain the WSDL description of a determined service
variant or an URI from which the WSDL description can be retrieved. Similarly, for a
partial customisation request, the customisation response might contain the WSVL
description of a refined customisable service or an URI from which the WSVL descrip-
tion can be retrieved.
In general, a customisation endpoint description defines a service interface for man-
agement purposes. Hence, it is possible to reuse existing WSDL notations to represent
this information. However, we argue that a good design principle is to make explicit
which information is for customisation purposes and which information is for conven-
tional service consumption purpose. This separation of notations will facilitate the
interpretation of the information at the consumer side, especially when tooling support is
used. Therefore, we define new XML notations which inherit WSDL notations for this
specific purpose.
Example 4.2 presents the customisation endpoint description for the Swinsure Insur-
ance Web service. The snippet defines one customisation operation, namely
customisationOperation (line 22-27). The operation accepts a complete customisation
request defined by a set of enabled features and a set of disabled features (line 16-18 and
82
line 1-8). And the operation returns the URL of the service variants WSDL (line 19-21
and line 9-15). This is the abstract definition of the customisation function.
With respect to the concrete definition of the customisation function, the binding el-
ement, <<wsvl:binding>>, specifies that the customisation messages of the operation
customisationOperation will be formatted as SOAP messages and transported using
HTTP protocol (line 28-31). In addition, the element <<wsvl:port>> defines the
endpoint where the customisation operation can be invoked (line 32-36). As can be seen
in this example, the customisation endpoint description provides complete information so
that the service customisation function can be used by service consumers.
Example 4.2 - Description of customisation endpoint

1: <xsd:element name="customisationOperationRequest">
2: <xsd:complexType>
3: <xsd:sequence>
4: <xsd:element name="enabledFeatureList" type="xsd:string/>
5: <xsd:element name="disabledFeatureList" type="xsd:string/>
6: </xsd:sequence>
7: </xsd:complexType>
8: </xsd:element>
9: <xsd:element name="customisationOperationResponse">
10: <xsd:complexType>
11: <xsd:sequence>
12: <xsd:element name="wsdlURI" type="xsd:anyURI"/>
13: </xsd:sequence>
14: </xsd:complexType>
15: </xsd:element>
16: <wsdl:message name="customisationOperationRequest">
17: <wsdl:part element="tns:customisationOperationRequest" name="parameters/>
18: </wsdl:message>
19: <wsdl:message name="customisationOperationResponse">
20: <wsdl:part element="tns:customisationOperationResponse" name="parameters/>
21: </wsdl:message>
22: <wsvl:portType name=customisationPortType">
23: <wsvl:operation name=customisationOperation>
24: <wsdl:input message="tns:customisationOperationRequest"/>
25: <wsdl:output message="tns:customisationOperationResponse"/>
26: </wsvl:operation>
27: </wsvl:portType>
28: <wsvl:binding name="swinsureBinding" type="customisationPortType">
29: <soap:binding style="document transport="http://schemas.xmlsoap.org/soap/http"/>
30: <wsvl:operation name=customisationOperation/>
31: </wsvl:binding>
32: <wsvl:service name="swinsureWebService">
33: <wsvl:port binding="swinsureBinding" name="swinsurePort">
34: <soap:address location="http://ec2-107-21-175-19.compute-1.amazonaws.com:8080/
swinsureCustomizationFrontend"/>
35: </wsvl:port>
36: </wsvl:service>
83
An example of SOAP messages for a customisation request and a customisation re-
sponse based on this customisation endpoint description is illustrated in Example 4.3.
This is extracted from our prototype implementation of the Swinsure Insurance Web
service (as a customisable atomic service) detailed in Chapter 6. The customisation
request is formulated by our consumer tool and is sent to the customisation endpoint (cf.
line 34 in Example 4.2). As a result, the Swinsure Insurance Web service returns the
customisation response.
4.2.4 Description of service capability
The service capability description defines the capability of a customisable service. It
accommodates common and variant capabilities of all service variants following the
template approach as described in Chapter 3. That is, the description is the superset of all
capabilities found in service variants. During the customisation process, only capabilities
matching consumer requirements are retained while other irrelevant capabilities are
purged from this service capability description to produce capabilities of one particular
service variant.
Example 4.3 - An example of customisation messages

<soap:Envelope>
<soap:Body>
<customizationOperationRequest>
<enabledFeatureList>Residential, Extra Cover, Accidental Damage
</enabledFeatureList>
<disabledFeatureList>Policy Query, Policy Update, Extended Third Party
Liability, Fusion Cover, Purchase
</disabledFeatureList>
</customizationOperationRequest>
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Body>
<customizationOperationResponse>
<wsdlURI>http://ec2-107-21-175-19.compute-
1.amazonaws.com:8080/swinsureServiceVariant/3/Quoting?wsdl=3_full
</wsdlURI>
</customizationOperationResponse>
</soap:Body>
</soap:Envelope>
Customisation request
Customisation response
84
As described in section 4.1.2, this service capability description facilitates the com-
munication of service variability. All common and variant capabilities are explicitly
specified so that service consumers know what to expect from a service variant. As a part
of a customisation contract, this information is essential to enable the loose coupling
between service consumers and service providers. Regardless of how service providers
change their internal service implementation, service consumers can expect the same
capability for the resulting service variants. In addition, the service capability description
enables service consumers to model service variability at the technical level without
having to derive a service variant in advance. Consequently, it facilitates dynamic service
customisation and service variability reuse.
It should be noted that service capability is only described at the abstract level by
specifying definitions for portTypes, operations, messages, and data types. It is not
necessary to define concrete information related to the binding of those operations and
service endpoints. This information will be dynamically generated when a service variant
is derived and deployed. Specifying the capability of customisable services in this way
reflects the dynamism of the lifecycle of service variants. We will discuss the details of
service variant lifecycle in the Chapter 5.
Since the service capability description is the definition of the capability of conven-
tional services (i.e. service variants), we utilise WSDL notations for this purpose.
Example 4.4 presents a snippet of the service capability description for the Swinsure
Insurance Web service. The example demonstrates two portTypes, called quotingPort-
Type and purchasingPortType. While the portType quotingPortType is common to
all service variants, the portType purchasingPortType is a variant capability and is
only present in some service variants. In addition, the portType quotingPortType has
five operations which are all variant capabilities.
Example 4.4 - Description of service capability

<wsdl:portType name="quotingPortType">
<wsdl:operation name="getQuote4Residential"/>
<wsdl:operation name="getQuote4ResidentialWithExtra"/>
<wsdl:operation name="getQuote4Business"/>
<wsdl:operation name="getQuote4BusinessWithExtra"/>
<wsdl:operation name=addAccidentalDamage"/>
</wsdl:portType>
<wsdl:portType name="purchasingPortType/>
85
4.2.5 Description of feature mapping
In WSVL, the customisation options description specifies service variability at the feature
level, while the service capability description defines service variability at the service
interface level. As explained in section 2.1.4.1, variability at the service interface level is
the refinement of the variability at the feature level. On other words, variant service
capabilities are refinement of variant features. Therefore, the feature mapping description
in WSVL is used to specify these refinement relationships. The description helps to
indicate what capability is available for a customisation request (i.e. a feature configura-
tion) without the need to actually customise the service.
The availability (aka. presence condition) of a variant capability is specified by a
propositional formula of variant features and is expressed as If the variant features A
1
,
A
2
,, A
n
are selected and the variant features B
1
, B
2
,, B
m
are disabled, this variant
capability is available. That is, the availability of a variant capability is decided by the
conjunction of two sets of features. The first set contains selected variant features, while
the second set contains disabled variant features. When this condition establishes with
respect to one customisation request, the variant capability is available to a service
variant. Otherwise, the variant capability is not available to the service variant.
In WSVL, this relationship is represented by the conjunction of links and one link
specifies one mapping between a variant feature and a variant capability. A link has
additional attributes specifying whether the inclusion or exclusion of the feature decides
the availability and the type of the capability (i.e. portType, operation, or dataType).
Specifying mapping in this way removes the necessity of enforcing the use of a particular
constraint language to describe propositional formulas in XML. Consequently it helps to
loosen the coupling between service providers and service consumers.
Example 4.5 presents a snippet of the feature mapping description for the Swinsure
Insurance Web service. The first two links map two variant features (i.e. Residential
and ExtraCover) with different presence attributes to the same operation
getQuote4Residential. The links collectively define that the operation
getQuote4Residential only exists in a service variant if the feature Residential is
enabled and the feature ExtraCover is disabled. In other words, the propositional
formula representing the presence condition of the variant capability
getQuote4Residential is Residential ExtraCover. In contrast, when both the
feature Residential and ExtraCover are selected, this operation
getQuote4Residential is excluded from service capability of service variants, while the
operation getQuote4ResidentialWithExtra is available. This is defined by the next two
86
links. Similarly, the next link specifies that when the feature AccidentalDamange is
selected, the operation addAccidentalDamage is available. And the last link defines
that the portType purchasingPortType only exists if the feature Purchase is enabled.
4.2.5.1 Restrictions on the feature mapping description
The feature mapping description enables the derivation of the capabilities of a service
variant with respect to one customisation request. There are two restrictions that cannot
be enforced by the WSVL XML schema. These restrictions guarantee the meaningfulness
of WSVL documents as customisation contracts for customisable services.
R1 (Mandatory features should not be specified in the propositional formula):
Mandatory features are always selected and the use of them in specifying the
presence conditions of variant capabilities is meaningless. In other words, all fea-
tures used in a propositional formula should be variant features.
R2 (A propositional formula should not always be false): Due to relationships
among features in a feature model, a propositional formula among variant fea-
tures might always be false. For instance, a propositional formula like If the
feature A
1
and A
2
are selected where A
1
and A
2
are alternative are always
Example 4.5 - Description of feature mapping

<mappingInfo>
<link name="LResidential1">
<featureRef ref="fd:Residential" presence="true"/>
<serviceElementRef ref="tns:getQuote4Residential target="operation" />
</link>
<link name=" LResidential2">
<featureRef ref="fd:ExtraCover" presence=false"/>
</link>
<link name="LResidentialWithExtra1">
<featureRef ref="fd:Residential" presence="true"/>
<serviceElementRef ref="tns:getQuote4ResidentialWithExtra target="operation" />
</link>
<link name=" LResidentialWithExtra2">
<featureRef ref="fd:ExtraCover" presence=true"/>
</link>
<link name=" LAccidentalDamage">
<featureRef ref="fd:AccidentalDamage" presence=true"/>
<serviceElementRef ref="tns:addAccidentalDamage target="operation" />
</link>
<link name="LPurchase">
<featureRef ref="fd:Purchase" presence="true"/>
<serviceElementRef ref="tns:purchasingPortType target="portType" />
</link>
</mappingInfo>
87
false. Another example is a mistakenly specified propositional formula like If
the feature A
1
is selected and the feature A
1
is disabled which is always false.
The use of such propositional formula for marking the presence condition of a
variant capability does not make sense since the variant capability becomes una-
vailable to all service variants.
It should be noted that a propositional formula of the form If the variant features
A
1
, A
2
,, A
n
1
, B
2
,, B
m
are disabled cannot be
always true. Therefore, the restriction a propositional formula should not always be
true, which is opposite to R2, does not need to be considered.
4.2.6 WSVL and variability dependencies
The WSVL supports variability dependencies in two different perspectives. Firstly, the
language enables the capture of variability intra-dependencies when exposing service
variability (i.e. exposed variability). Secondly, the language facilitates the modeling of
variability inter-dependencies between a customisable composite service and its cus-
tomisable partner services. This ability enables the reuse of service variability. We
discuss these two perspectives in the following subsections.
4.2.6.1 Variability intra-dependencies
A WSVL document exposes variant service capabilities in a superimposed form (cf.
Example 4.4). The presence of a variant service capability might require or exclude the
presence of another variant service capability. That is, there are dependencies among
these variant service capabilities that we call variability intra-dependencies (cf. section
2.2.3.2). For instance, with the description of service capabilities in Example 4.4, the
existence of the operation getQuote4Residential excludes the existence of other three
operations getQuote4ResidentialWithExtra, getQuote4Business,
getQuote4BusinessWithExtra because these four operations are alternative operations
for getting an insurance quote. Similarly, the operation addAccidentalDamage is used
to add Accidental Damage extra cover for an existing quote. Its existence requires the
existence of either the operation getQuote4ResidentialWithExtra or the operation
getQuote4BusinessWithExtra.
In WSVL, variability intra-dependencies are not directly specified. Instead, they are
indirectly captured through the mapping between variant service capabilities and variant
features. This is possible because the identification of variant service capabilities is driven
by variant features. And variant service capabilities are only the refinement of variant
88
features at the service interface level. For instance, the exclude relationship between
the two operations getQuote4Residential and getQuote4ResidentialWithExtra exists
because they refine the optional feature Extra Cover in case the feature Residential
is selected. Or the require relationship between the operation addAccidentalDamage
and the operation getQuote4ResidentialWithExtra exists because they both represent
the case when Extra Cover and Accidential Damage are selected.
Therefore, the description of feature mapping in WSVL enables the capturing of var-
iability intra-dependencies between variant service capabilities (i.e. service variability at
the service interface level). Note that WSVL also exposes service variability at the feature
level. And variability intra-dependencies at the feature level are captured by restrictions
specified in the feature model. In summary, WSVL facilitates the exposure of service
variability as well as the capturing of its variability intra-dependencies.
4.2.6.2 Variability inter-dependencies and service variability reuse
To explain how WSVL helps to support variability inter-dependencies and service
variability reuse, let us consider a scenario in Figure 4.5. Swinbroker is a consumer that
provides an insurance quoting business process. This business process is also customisa-
ble and its users can select one among three process variants for calculating insurance
quotes related to three types of policies: i) residential policy without extra cover, ii)
business policy without extra cover, and iii) business policy with extended third party
liability. In its business process, Swinbroker has a general task, called Quoting, for
calculating the quote. This task is a variation point (or placeholder) where three different
variant tasks need to be bound (or replaced) for three types of insurance policies.

Figure 4.5 - Swinbroker business process
Quoting
getQuote4Residential
Swinbroker Swinsure WS
{Residential=true,
ExtraCover=false}
PostQuoteProcessing
PreQuoteProcessing
getQuote4Business
{Business=true ,
ExtraCover=false}
Sub-process Task
getQuote4BusinessWithExtra
{Business=true ,
ExtraCover=true,
ExtendedThirdParty
Liability=true}
4.3 Engineering and validating WSVL documents
89
Note that all three variant tasks are already provided by the Swinsure Insurance Web
service through three variant capabilities (aka. service operations) as shown in Figure 4.5.
Therefore, the Swinbroker does not have to realise this variability on its own. Instead, the
Swinbroker defines the mapping between the task Quoting and the three operations
provided by the Swinsure Insurance Web service. At runtime, when a user chooses one of
its process variants, the Swinbroker will dynamically customise the Swinsure Insurance
Web service to get a particular service variant with an appropriate service operation to
invoke. For instance, for users who require the process variant providing the first type of
insurance policies, Swinbroker process will utilise the first mapping to: 1) customise the
Swinsure Insurance Web service with the following setting as annotated to the mapping
Residential=true, ExtraCover=false, 2) invoke the operation
getQuote4Residential of the service variant, which is resulted from the customisation,
to realise the Quoting task.
The descriptions of service capability and feature mapping of the Swinsure Insur-
ance Web service allow Swinbroker to capture these dependencies at the process
modeling level (aka. design time) without the need of actually customising the Swinsure
Insurance Web service in advance. In addition, such descriptions enable the reuse of
service variability provided by the Swinsure Insurance Web service in realising variabil-
ity within Swinbrokers business process. In Chapter 7, we will further elaborate the
implication and benefits of capturing variability inter-dependencies when we discuss
customisable composite services.
While a WSVL document for a customisable service can be created manually by using an
XML editor and the WSVL XML schema, this approach is not effective and error-prone.
The reason is twofold. Firstly, it is difficult to verify and enforce additional restrictions
discussed in section 4.2.2.1 and section 4.2.5.1. Secondly, the WSVL document is not
created by following SPL principles of systematic identification and management of
service variability. In this section, we describe an MDE (Model-Driven Engineering)
technique for developing WSVL documents. The technique can be used together with
techniques described in Chapter 6 and Chapter 7 for engineering customisable atomic
services and customisable composite services.

90
4.3.1 Overview
The engineering process of any WSVL document is comprised of two parts. One part is
for engineering artefacts specific to one particular customisable service that we call
service-specific activities. The other part is for engineering artefacts which is specific to
the service platform that supports the customisable service. We refer to this part as
platform-specific activity (Figure 4.6).
Service-specific activities start with the feature modeling activity for modeling ser-
vice variability. The resulting feature model not only facilitates the identification of
service variability at technical levels, but also is used as the input for producing the
description of customisation options in a WSVL document. This is done by transforming
the feature model to the customisation options description based on the WSVL XML
schema.
The next service-specific activity is service capability modeling. Based on the identi-
fied variability in the feature model, developers will design service capabilities, deciding
common and variant service capabilities. These variant service capabilities are refinement
of service variability at the feature level (i.e. variant features). The result of this activity is
a service interface model template which is the superset of service interface models for all
service variants. The service interface model template facilitates the implementation of
the service, as well as is used as the input for producing the description of service
capability. It should be noted that the implementation of customisable services will be
discussed in subsequent chapters. This chapter only focuses on the service interface
description of customisable services in WSVL.
The next service-specific activity is feature mapping. This activity produces a fea-
ture mapping model which captures the correspondence between variability in the feature
model (i.e. variant features) with variability in the service capability (i.e. variant service
capabilities). The feature mapping model enables the verification of restrictions discussed

Figure 4.6 - Overview of engineering WSVL documents
Feature modeling
Service capability
modeling
Feature mapping
Customisation function
modeling
Customisation options
description
Service capability
description
Feature mapping
description
Customisation function
description
Service-specific activities Platform-specific activity
91
in section 4.2.5.1. In addition, it is used to produce the description of feature mapping in a
WSVL document. In subsequent chapters, we also discuss how to utilise this feature
mapping model to enable the realisation of variability within service implementation.
The platform-specific activity encompasses the activity for modeling the customi-
sation function. In this activity, developers model different types of customisation
operations as discussed in section 4.2.3. Since customisation operations are Web service
operations, this activity can be done in the same way as conventional service interface
modeling. The result of this activity is called a customisation model which is used to
produce the description of customisation endpoint. Again, this transformation is similar to
the generation of WSDL document from a service interface model. The main reason why
we call this activity platform-specific is that, the same customisation operations can be
applied to all customisable services provisioned by one service provider. Therefore,
instead of repeating the same activity in the development process of each individual
customisable service, it is more efficient to integrate the activity into the service platform
and have it reused among all customisable services. Next chapter, we discuss an architec-
ture which utilises this approach for provisioning customisable services.
In the following subsections, we describe the details of each activity in the service-
specific activities. As the customisation function modeling is the same as conventional
service interface modeling, we omit its detail here.
4.3.2 Feature modeling and prototype tool
Figure 4.7 presents the feature metamodel which is adapted from (Czarnecki 2005d).

Figure 4.7 - Feature metamodel (adapted from (Czarnecki 2005d))
92
There are three types of features: i) root feature, ii) solitary features which do not belong
to a feature group, and iii) grouped features which are contained in one feature group. A
feature model contains one root feature. Any feature can contain feature groups or
solitary features. And a feature group contains a number of grouped features. A solitary
feature has feature cardinality and a feature group has group cardinality. A grouped
feature does not need feature cardinality since its variability is alternatively decided by
the group cardinality associated with its feature group.
Note that this feature metamodel explicitly differentiate different types of features
(e.g. solitary features or grouped features). This differentiation is important to support the
reasoning on feature models within this tool. However, such differentiation is not im-
portant when representing a feature model in an XML format as discussed in section
4.2.2. There is no need to specify types of features in its XML representation since
feature types can be inferred from such representation.
A feature model is instantiated from this feature metamodel. Cross-tree constraints
are specified as propositional formulas among features of the feature model. Figure 4.8
presents a screenshot of our feature modeling tool. This tool extends an open source tool
for feature modeling (Antkiewicz 2004) by adding new functions related to the pro-

Figure 4.8 - Feature modeling tool
Root feature
Solitary features with
feature cardinality [1-1]
Solitary feature with
feature cardinality [0-1]
Feature group with
group cardinality # [1-1]
Grouped feature
Feature group with
group cardinality [1-1]
Feature constraints
93
cessing and manipulation of WSVL. In later chapters, we also introduce new functions
related to service customisation. As can be seen from the screenshot, in addition to the
model elements introduced in the feature metamodel, constraints among features are
propositional formulas associated with the root feature. This feature modeling tool
facilitates the creation of feature models, feature configurations, and customisation
options descriptions.
4.3.2.1 Validation of restrictions on feature models
The feature modeling tool uses propositional logic for supporting reasoning on feature
models (Antkiewicz 2004). In particular, the tool enables the validation of feature models
as well as the enumeration of complete feature configurations. Therefore, the tool helps to
enforce the restriction discussed in section 4.2.2.1 before generating the description of
customisation options. Another advantage of the feature modeling tool is the automated
support when producing feature configurations. Based on the constraints defined in the
feature model, the tool automatically propagates the selection and/or disabling of features.
This function helps to improve efficiency while maintaining the validity of the resulting
feature configurations (Antkiewicz 2004).
4.3.3 Service capability modeling and prototype tool
Figure 4.9 presents a service interface metamodel which is based on UML notations for
modeling WSDL-based service interfaces (Marcos 2003). A service is comprised of one
or more interfaces which in turn consist of one or more portTypes. Each portType defines
a number of operations. An operation specifies types of messages for input, output and
fault. This metamodel enables the modeling of service interfaces at the abstract level.

Figure 4.9 - Service interface metamodel
94
A service capability model is instantiated from this metamodel. The resulting service
capability model contains both common and variant service capabilities since we use the
template approach for capturing service variability. That is, all common and variant
capabilities are modeled in a super-imposed form (cf. section 3.3.1 for discussion about
the template approach).
Figure 4.10 presents the screenshot of our service capability modeling tool. This tool
is developed using the EMF (Eclipse Modeling Framework) (Eclipse 2012b). The tool is
an Eclipse plugin that provides an interactive interface so that elements of a service

Figure 4.10 - Service capability modeling tool
95
capability model can be instantiated. As can be seen from the figure, both common
capabilities (e.g. the portType quotingPortType) and variant capabilities (e.g. the
portType purchasingPortType or the operations getQuote4Residential) are modeled
in one service capability model.
4.3.4 Feature mapping and prototype tool
Figure 4.11 presents the metamodel for mapping between variant features and variant
capabilities. A MappingModel consists of three types of elements: FeatureModelRef,
ServiceModelRef, and Link. FeatureModelRef and ServiceModelRef are references
pointing to the corresponding feature model and service capability model. Links are used
to relate variant features in the feature model to variant capabilities in the service capabil-
ity model. To this end, a Link consists of a Feature and a number of ServiceElements
which respectively have references to elements within the corresponding feature model
and service capability model. A Feature has an attribute presence to denote whether
the selection or disabling of the feature involves in the relation with ServiceElement. In
addition, a ServiceElement also has an attribute target to denote the type of the service
element (i.e. portType, operation, or data type). The semantic of the attribute presence
and target is similar to their counterparts in WSVL. It should be noted that while
FeatureModelRef and ServiceModelRef are references to models (i.e. feature model and
service capability model), FeatureElementRef and ServiceElementRef are references to
model elements within those models.
Figure 4.12 presents our feature mapping tool which facilitates the instantiation of a

Figure 4.11 - Feature mapping metamodel
96
feature mapping model from the mapping metamodel. This tool is implemented as an
extension of an open source Eclipse plugin, called Atlas Model Weaver (AMW) (Didonet
2006). In the screenshot, the feature model is presented on the left panel, while the
service capability model is presented in the right panel. The middle panel shows the
mapping model. Two links are expanded in the screenshot to demonstrate the mapping
with respect to the operation getQuote4Residential. While the first link references the
feature Residential with the attribute presence set to true, the second link refer-
ences the feature Extra Cover with the attribute presence set to false (as shown
on the bottom of the figure). This mapping captures the same semantic as the description
of feature mapping.
4.3.4.1 Validation of restrictions on feature mapping
To validate the feature mapping against restrictions discussed in section 4.2.5.1, we rely
on the FAMA (FeAture Model Analyser) framework (Benavides 2012). The FAMA
framework supports automated analysis of feature models. In particular, it accepts as the
input a feature model (described in an XML format) and provides such operations as the
validation of a feature model or validation of a feature configuration.
The validation of the feature mapping model is performed for each variant capabil-
ity. In particular, our validation program scans through the mapping model to build up
propositional formulas (i.e. a list of selected features and a list of disabled features) with
respect to each variant capability. Each propositional formula is then validated by
querying the FAMA framework. The validation of R1 restriction (cf. section 4.2.5.1) is
straight-forward. We first get the list of mandatory features from the feature model and
compare features used in a propositional formula against this list.

Figure 4.12 - Feature mapping tool
FEATURE MODEL MAPPING MODEL SERVICE CAPABILITY MODEL
FeatureRef
ServiceElementRef
Link
Presence attribute
97
With regards to R2 restriction, an always-false formula is the one that violates con-
straints specified in the feature model. In other words, an always-false formula implies an
invalid feature configuration. Therefore, we query the FAMA framework to check if a
propositional formula is always false or not.
Example 4.6 presents the Java snippet for validating R2 restriction. First, we load the
feature model (line 1-6). Second, we create a configuration with the set of enabled
features and the set of disabled features (line 8-19). Third, we apply the configuration to
the feature model (line 21-22). Fourth, we make a query about the validity of the resulting
feature model (line 24-26). Fifth, we check the result of the query (line 28-31).
4.3.5 Verifying and using engineering models
To help developers verify the correctness of engineering models (i.e. the feature model,
the service capability model, and the feature mapping model), we have developed a
MDE-based verification framework which simulates the operation of the service customi-
Example 4.6 - Java snippet for validating feature configuration

1: // Instantiate the main class of the FAMA framework
2: mQuestionTrader = new QuestionTrader();
3:
4: // Load a feature model
5: VariabilityModel fm = mQuestionTrader.openFile("models/swinsure.xml");
6: mQuestionTrader.setVariabilityModel(fm);
7:
8: // Create a configuration //
9: Configuration cf = new Configuration();
10:
11: // Enabled features //
12: for (VariabilityElement feature : enabledFeatureList) {
13: cf.addElement(feature, 1);
14: }
15:
16: // Disabled features //
17: for (VariabilityElement feature : disabledFeatureList) {
18: cf.addElement(feature, 0);
19: }
20:
21: // Apply the configuration
22: mQuestionTrader.addStagedConfiguration(cf);
23:
24: // Create ValidQuetion//
25: ValidQuestion vq = (ValidQuestion)mQuestionTrader.createQuestion("Valid");
26: mQuestionTrader.ask(vq);
27:
28: if (vq.isValid())
29: System.out.println("Valid configuration");
30: else
31: System.out.println("Invalid configuration");
98
sation (Figure 4.13). This verification framework accepts all three engineering models as
its inputs. In addition, it accepts a feature configuration model which represents a feature
configuration as an instantiated model of the feature metamodel. The verification frame-
work uses the following model transformation rules to derive a variant service model
corresponding to the given feature configuration:
For each variant capability captured in the feature mapping model, its proposi-
tional formula is composed and evaluated against the feature configuration.
If the evaluation result is true, the variant capability is retained (i.e. it is available
to the corresponding service variant).
If the evaluation result is false, the variant capability is purged from the service
capability model.
The purge of model elements in the service capability model follows the con-
tainment relationships of the metamodel. That is, when a model element is
deleted, all contained elements are also removed from the service capability mod-
el. For instance, the removal of the portType purchasingPorType induces the
removal of two operations purchasePolicyByCreditCard and purchasePoli-
cyByCoverNote as well as their child elements (cf. Figure 4.10).
The verification framework allows developers to see the resulting variant service
models with respect to one feature configuration. Based on this, developers are able to
decide if they need to revise any engineering model. We implemented these model
transformation rules using ATL (Atlas Transformation Language) (Jouault 2008). ATL is
a hybrid model transformation language which combines both declarative and imperative
constructs for specifying transformation. ATL also comes with a complete environment
for editing, debugging, compiling and executing model transformations. Figure 4.14

Figure 4.13 - Model transformation process
Feature mapping
model
<<in>>
<<out>>
<<in>>
Model
transformation
Service capability
model
Feature configuration
model
Feature model
Variant service
model
<<in>>
<<in>>
99
presents screenshots of how the verification framework works. After creating a feature
configuration in the feature modeling tool, developers are able to execute the command
Generate service variant from the context menu (cf. the top right part of the figure).
The command will execute ATL-based model transformation rules (cf. the bottom left
part of the figure) to produce variant service model (cf. the bottom right part of the figure)
from the service capability model (cf. the top left part of the figure).
After verifying the correctness of models produced during the engineering process,
developers are able to automatically generate necessary information for a WSVL docu-
ment. To this end, we have developed a set of XSLT transformations. These
transformations help to generate the description of customisation options, the description
of service capability, and the description of feature mapping from the feature model, the
service capability model, and the feature mapping model respectively (cf. Figure 4.6).
This information is combined with the platform-specific customisation endpoint descrip-
tion to produce a complete WSVL document for a customisable service as described in
section 4.3.1.

Figure 4.14 - Screenshots for verifying correctness of engineering models
Service capability model
Model transformation rules
Feature modeling tool
Variant service model
100
4.4 Analysis of WSVL against service variability characteristics
We analyse WSVL as our solution for an interface description language against charac-
teristics of service variability that we identified in Chapter 2. In particular, WSVL has
addressed the following characteristics (Figure 4.15):
Exposed variability: WSVL captures exposed variability by presenting service
variability information at both the feature level and the service interface level.
Service variability at the feature level enables the realisation of the service cus-
tomisation function using the messaging paradigm, while service variability at the
service interface level facilitates the reuse of service variability. As such, WSVL
sufficiently captures the exposed variability required for the interactions between
service providers and service consumers.
Variability intra-dependencies: WSVL provides mechanisms for capturing vari-
ability intra-dependencies for exposed variability. In particular, the restrictions in
a feature model (e.g. feature constraints) facilitate the capturing of variability in-
tra-dependencies for service variability at the feature level. And the description of
feature mapping supports the capturing of variability intra-dependencies for ser-
vice variability at the service interface level.
Formality: WSVL is formally specified by an XML schema. This formality

Level
(Interface/
Implementation)
Partner
variability
Composition
variability
Implementation Architecture
Variation
points and
variants
Intra-
dependencies
Service variability
Internal
External
Automated Inter-
dependencies
Exposed
variability
Variability
communication
independence
Self-
describing
Staged
instantiation
Who
(Provider/
Consumer)
level
Requirement
Variability
constraints
Customisation enabler
4.4 Analysis of WSVL against service variability characteristics
101
guarantees the interoperability between service providers and service consumers
in communicating customisation contracts. In addition, it enables the consistency
in describing and using customisation contracts across different service providers.
The specification of WSVL in terms of an XML schema also facilitates the auto-
mated usage of service variability information. This feature will be discussed in
section 7.5.1 in the context of composing customisable services.
Technology-independence: WSVL uses XML in a similar way to WSDL to ena-
ble platform-agnostic and programming language-independent representation of
customisation contracts. In addition, the representation of necessary information
(i.e. service capability description, customisation options description, and feature
mapping description) is abstracted away from the way the information is created
(i.e. service capability model, feature model, and feature mapping model). In this
way, WSVL removes the dependencies between the interface description of a
customisable service and the underlying techniques for engineering the customis-
able service. This technology-independence enables the loose coupling between
service providers and service consumers, thus helps to broaden the use of cus-
tomisable services. For comparison, as described in Chapter 2, (Stollberg 2010)
exposes service variability at the service interface level by presenting EMF-based
service variability model to service consumers. This representation is technology-
dependent. It restricts service consumers to use the same framework (i.e. EMF) in
customising services and consequently limits the use of customisable services.
Who (Provider/Consumer): A WSVL document explicitly specifies the customi-
sation options, and the abstract and concrete definitions of the service
customisation function. This information is sufficient to service consumers as the
ones who performs service customisation.
Self-describing: As discussed, a WSVL document captures sufficient information
so that service consumers can comprehend and utilise the service customisation
function. In addition, the document makes explicit common and variant service
capabilities, as well as their presence conditions through the description of ser-
vice capability and the description of feature mapping. This information enables
the consistent view of a customisable service (i.e. what to expect before customi-
sation is consistent with what can achieve after customisation). Altogether, the
WSVL document becomes a self-describing customisation contract which guides
and governs the use of a customisable service.
102
Recursive: WSVL uses the messaging paradigm to realise the service customisa-
tion function. This design enables dynamic customisation of customisable
services. Consequently, it supports recursive service customisation since the cus-
tomisation of a composite service can dynamically trigger the customisation of
partner services.
4.5 Summary
In this chapter, we have described WSVL which is our extension of WSDL for describing
customisable services. The WSVL helps to enable the customisation framework intro-
duced in Chapter 3 by specifying both the customisation options and the service
customisation function in a service-oriented way. In addition, the language captures and
enables the communication of service variability so that service consumers are able to not
only consume a service variant but also reuse the service variability exposed by the
customisable service. The WSVL helps to define customisation contracts which guide,
govern and guarantee the use of customisable services. It enables loose coupling between
service providers and service consumers since service consumers are only bound to this
contract and are not constrained by specific details of the service implementation. In the
next three chapters, we will discuss how to engineer and provision customisable atomic
and composite services which conform to these WSVL descriptions.

103

5. An Architecture for Provisioning Customisable Services
In the last two chapters, we have mainly discussed service customisation from service
consumers point of view (i.e. the external view of service customisation). From this
chapter on, we provide the detail of the internal view (i.e. how service providers internal-
ly enable service customisation). In particular, this chapter discusses specific issues
related to the provisioning of customisable services. We present a service provisioning
architecture that facilitates the deployment and provisioning of customisable services
(Figure 5.1). The service provisioning architecture is generic and applicable to both
customisable atomic services and customisable composite services. In the subsequent
chapters (i.e. Chapter 6 and Chapter 7), we will discuss how to engineer each type of
customisable services for use with this service provisioning architecture.
Section 5.1 motivates the possibility and benefits of extending existing service plat-
forms for accommodating customisable services. We then describe additional functions
which are missing in existing service platforms for the provisioning of customisable
services in section 5.2. Section 5.3 discusses the service provisioning architecture in
detail. Section 5.4 discusses the operation of the service provisioning architecture with
respect to partial customisation requests. In particular, we describe how the service
provisioning architecture processes partial customisation requests in a much similar way
to complete customisation requests.
Similar to other chapters, we analyse our techniques for provisioning customisable
services against service variability characteristics in section 5.5. We then conclude the
chapter in section 5.6.

This chapter
Customisation
framework
Atomic service
realisation
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
language
Composite service
realisation
Provisioning architecture 3
Chapter 5 - An Architecture for Provisioning Customisable Services
104
5.1 Benefits of extending existing service platforms
As discussed in Chapter 3, a customisable service has two distinct operation modes: the
customisation mode and the consumption mode. In contrast, conventional Web services
only operate in the consumption mode. This difference implies that, existing service
platforms
19
cannot be used as-is for provisioning customisable services. On the other
hand, as discussed in Chapter 3, both of these modes exploit the messaging paradigm to
enable the interactions between service providers and service consumers. This similarity
shows that, a customisable service can be generally seen as the combination of two
services which are internally interconnected. These two services realise the two operation
modes respectively, while their internal relationships represents the course of service
customisation. This observation suggests the feasibility of extending existing service
platforms for supporting the provisioning of customisable services. The extension will
introduce additional components for addressing issues specific to customisable services,
while reusing existing service platforms for addressing general concerns (e.g. messages
parsing or processing).
Extending existing service platforms, rather than developing a new service platform
from scratch, has the following benefits:
Low introduction cost: An extended platform will require much less cost than
newly-developed ones.
Higher interoperability: Both customisable services and conventional services
are provisioned in the same platform which consequently support their interoper-
ability in creating a service ecosystem from a service provider.
Higher productivity: Software developers who are already familiar with existing
service platforms can easily switch to support customisable services.
Altogether, such extensions help to lower the barrier for introducing customisable
services. In this chapter, we propose such an extension that we call a service provisioning
architecture. Our extension is not specific to any particular service platform. Instead, it
can be used as a blueprint so that service providers are able to extend their in-house
service platforms for accommodating customisable services.

19
In this thesis, we use two terms service platform and service framework interchangeably to
indicate middleware systems used for supporting the development and provisioning of Web
services. Examples of such middleware systems are Apache CXF (http://cxf.apache.org) or
Apache Axis (http://axis.apache.org).
5.2 Additional functions for provisioning customisable services
105
5.2 Additional functions for provisioning customisable services
In addition to functions required by conventional services, there are three additional
functions which are essential for the provisioning of WSVL-based customisable services
(Nguyen 2012a):
The validation of the customisation requests: A customisation request must be
valid with respect to the feature model representing customisation options. Oth-
erwise, it cannot be used to derive a service variant. While a feature model and a
customisation request are specific to a customisable service, the validation of the
customisation request against the feature model is a common function to all cus-
tomisable services. Such validation relies on automated analysis techniques for
feature models as discussed in section 3.4.3.1. Therefore, it is possible and pref-
erable to have a dedicated component which is built into service platforms for the
realisation of this validation function. In this way, such component can be effi-
ciently reused among all customisable services.
The dynamic derivation and deployment of service variants: Given a valid cus-
tomisation request, a service variant is dynamically derived and deployed. The
capability of the derived service variant is a subset of the service capability de-
scription specified in the WSVL document as discussed in section 4.2.4. Similar
to the validation function, while the implementation of service capabilities is spe-
cific to each customisable service, the component for controlling the derivation
and deployment of service variants should be built into service platforms.
The management of the lifecycle of service variants: There are various usages of
service variants once they are deployed. They might be available permanently or
temporarily depending on contracts between service providers and service con-
sumers. The same service variants might be requested by a number of service
consumers. Therefore, it is essential to manage the lifecycle of service variants
once they are derived and deployed. Again, this common function should also be
built as a service platform component.
5.3 The service provisioning architecture
5.3.1 Overview
Figure 5.2 presents the architecture for deploying and provisioning customisable services
(Nguyen 2012a). The service provisioning architecture comprises of a number of compo-
nents performing different functions of service customisation.
106
Each customisable service exposes two types of endpoint, customisation endpoint
and variant endpoint, where the service customisation function and the variant provision-
ing function are respectively provided. The customisation endpoint is uniquely specified
in the WSVL document for exchanging customisation messages, while variant endpoints
are dynamically created for exchanging messages related to consuming particular service
variants. In general, a new variant endpoint is created each time a new valid customisa-
tion request is received.
5.3.2 Components of the architecture
The functions of components of the service provisioning architecture are described
below:
Customisation frontend: This is a conventional service for providing the service
customisation function. Its capability is specified in the customisation endpoint
description of the WSVL document. The customisation frontend is an intermedi-
ary between service consumers and the customisable service in question.
Feature model manager: This component manages feature models for all cus-
tomisable services and provides a set of operations with respect to feature models.
In particular, the component supports the registration of feature models and the
validation of customisation requests (i.e. feature configurations). In addition, the
component helps to verify whether a customisation request is complete or partial,

Figure 5.2 - Overview of the service provisioning architecture
Service platform
Customisation
frontend
Feature
model
manager
Runtime customisation and
management engine
Configurable
service
implementation
Variant profile
repository
Service variant
Customisation
endpoint
Variant
endpoint
5.3 The service provisioning architecture
107
as well as deriving the optimised customisation request
20
. As well as these
runtime functions, the component can also be used at design time to facilitate the
domain engineering process of customisable services.
Variant profile repository: This component keeps track of deployed service vari-
ants with respect to customisation requests. In particular, it maintains the
correspondence between customisation requests and variant endpoints. It also
contains other endpoint information like the deployment status (e.g. active, ex-
pired), deployment time, and deployment types (e.g. permanently, temporary) to
facilitate the management of service variant lifecycles.
Configurable service implementation: These are configurable artefacts produced
during the domain engineering process. Configurable artefacts contain software
variants in a super-imposed form
21
. These software variants are mapped to variant
features in the feature model so that a feature configuration can be used to resolve
variability in these configurable artefacts. Note that these configurable artefacts
are specific to the types of services (i.e. atomic or composite) in question. We will
elaborate these artefacts in Chapter 6 (for customisable atomic services) and
Chapter 7 (for customisable composite services).
Runtime customisation and management engine (or Runtime engine): This
component plays the central role in deriving, deploying and managing service
variants. Its main function is to resolve variability in the configurable service im-
plementation and produce application artefacts
21
which comprise service
variants. In addition, it supports the dynamic deployment of service variants as
well as monitoring the operation of deployed service variants. Lastly, it facilitates
the management of lifecycles of service variants through interactions with the
component Variant profile repository (e.g. register a new variant endpoint or up-
date the state of existing variant endpoints).
Service variant: This is dynamically derived from the configurable service im-
plementation according to a customisation request. The deployment lifetime of
this component depends on service providers policies and contracts between ser-
vice providers and service consumers. For the multi-tenanted SaaS application

20
See section 3.4.2 for the definition of different types of customisation requests.
21
See section 3.3 for the discussion of the domain engineering process for customisable services,
configurable artefacts, and application artefacts
108
model (Ghaddar 2012), this component is usually deployed temporarily according
to the payment by service consumers.
Among above components, the components Customisation frontend, Configurable
service implementation, and Service variant are specific to one customisable service.
Other components are common to all customisable services. The component Service
variant is only the runtime component produced by the runtime engine. While the
component Customisation frontend needs to be uniquely deployed for each customisable
service, its operations are likely common to all customisable services. In other words,
they can also be shared among customisable services in a similar fashion to other com-
mon components. Therefore, to provide a new customisable service in this service
provisioning architecture, service providers only need to develop the component Config-
urable service implementation and reuse other components.
There is a mapping between information in WSVL documents and this service pro-
visioning architecture. In particular, the description of customisation endpoint in a WSVL
document represents the capability of the component Customisation frontend. The
description of customisation options is managed by the component Feature model
manager. Lastly, the description of service capability and the description of feature
mapping are utilised in developing the component Configurable service implementation.
Note that the description of the function of each component is not comprehensive.
We only describe above the key functions which collectively enable the provisioning of
customisable services. Service providers who wish to exploit this service provisioning
architecture to extend their existing service platforms need to adapt these components by
considering additional functions according to their service provisioning policies and
strategies.
5.3.3 Interaction among components
In this section, we describe the interactions between components of the service provision-
ing architecture to process an incoming customisation request.
i. Upon the arrival of a customisation request, the Customisation frontend queries
the Feature model manager about the validity of the customisation request.
ii. If the customisation request is invalid, the Customisation frontend notifies the
service consumer. Otherwise, the Customisation frontend queries the Feature
model manager to check if the customisation request is complete or partial. In
case of partial customisation request, the Customisation frontend retrieves the
optimised customisation request from the Feature model manager. The opti-
5.4 Handling partial customisation requests
109
mised customisation request will help to resolve variability in the configurable
service implementation to the full extent with respect to the given customisation
request. The final customisation request is passed to the Runtime engine.
iii. The Runtime enginefirst queries the Variant profile repository to check if a ser-
vice variant matching the customisation request is already deployed. If yes, the
Runtime engine updates the existing service variant (e.g. updating its deploy-
ment status), updates the Variant profile repository (e.g. by adding association
between the existing variant endpoint and this service consumer), and returns the
variant endpoint to the Customisation frontend. The Customisation frontend
will formulate and return an appropriate customisation response message to the
service consumer so that the consumer can start consuming the service variant.
iv. In case there does not exist an already deployed service variant matching the cus-
tomisation request, the Runtime engineis going to derive a new service variant.
The derivation of a service variant is performed by referring variability resolution
decisions at the feature level to resolve variability within the Configurable ser-
vice implementation to produce a particular service variant.
v. The Runtime engine will dynamically deploy the resulting service variant to a
new variant endpoint. Information related to the new service variant is updated to
the Variant profile repository before the new variant endpoint is returned to the
service consumer through the Customisation frontend.
5.4.1 Overview
As discussed in Chapter 3, there are two types of customisation requests: complete
customisation requests and partial customisation requests
22
. For complete customisation
requests, variability in the feature model is completely decided. Consequently, variability
in the configurable service implementation is completely resolved to produce a service
variant which is ready to be consumed by end-users. In this case, a service variant, which
is called determined service variant in section 3.4.3.3, is a conventional service
described by a WSDL document. In contrast, the resolution of variability in the feature
model for partial customisation requests is not complete. Consequently, the resulting

22
In all of our discussion related to variability resolution from this section on, we assume that the
customisation request in question is valid. Invalid customisation requests are already rejected by
the Customisation frontend and are not used by the runtime engine to resolve variability.
110
service variant, which is called refined customisable service, is still a customisable
service. A refined customisable service is again described by a new WSVL document.
While the operations of the service provisioning architecture with respect to both
complete and partial customisation requests are similar and have already been described
in section 5.3.3, the only difference between the two relates to the derivation of service
variants. In this section, we assume that the service provisioning architecture is already
capable of deriving determined service variants with respect to complete customisation
requests. This detail which is specific to the type of services will be discussed in Chapter
6 and Chapter 7 respectively. We will describe our solution to handle partial customisa-
tion requests and derive refined customisable services based on that capability.
Figure 5.3 presents components of the service provisioning architecture for pro-
cessing partial customisation requests. There are two main differences compared to the
service provisioning architecture shown in Figure 5.2. Firstly, the runtime-generated
component Service variant is replaced by a Variant customisation frontend, and the
Variant endpoint is replaced by a Variant customisation endpoint. This change of names
not only reflects the change in functions of those entities but also demonstrates how
similar the new entities are with respect to the existing entities Customisation frontend
and Customisation endpoint of the service provisioning architecture.
In the following subsections, we describe the operation of the runtime engine with
respect to the derivation of refined customisable services. In particular, we describe how
the runtime engine derives the WSVL description for a refined customisable service
(section 5.4.2), what will be deployed as the runtime representation of the refined

Figure 5.3 - Handling partial customisation requests
Feature
model
manager
Runtime customisation and
management engine
Configurable
service
implementation
Customisation
endpoint
Service platform
Variant
customisation
endpoint
Variant customisation
frontend
Customisation
frontend
111
customisable service (section 5.4.3), and how the refined customisable service processes
customisation messages destined to it (section 5.4.4).
5.4.2 Deriving WSVL documents for refined customisable services
Variability of a refined customisable service is represented by a feature model resulted
from specialising the original feature model. This specialisation is based on the feature
configuration contained in the partial customisation request to which the refined cus-
tomisable service is generated. Similarly, the WSVL description of the refined
customisable service is also a result of specialising the WSVL description of the original
customisable service. In this section, we describe the process of deriving the WSVL
description of the refined customisable service. In particular, section 5.4.2.1 discusses
how to specialise the original feature model and produce the description of customisation
options. Section 5.4.2.2 describes the specialisation of the service capability description.
Section 5.4.2.3 describes the specialisation of the feature mapping description. And
section 5.4.2.4 discusses the deployment of variant customisation endpoint and the
derivation of the complete WSVL description.
5.4.2.1 Specialising feature model and customisation options description
Upon the reception of a partial customisation request from the component Customisation
frontend, the runtime engine specialises the feature model with the feature configuration
contained in the customisation request. The specialised feature model is a new feature
model in which selected features become mandatory, disabled features are removed, and
undecided variant features remain variant
23
. In addition, other properties of the feature
model (i.e. group cardinalities, cross-tree constraints) are also specialised according to the
feature configuration. The specialisation of feature models is also called staged-
configuration of feature models in literature (Czarnecki 2005d).
For instance, specialising the feature model of the Swinsure Insurance Web service
(cf. section 3.1) with respect to the customisation request CR=({Residential}, {Business,
ExtendedThirdPartyLiability, PolicyUpdate, PolicyQuery}) results in a specialised
feature model shown in Figure 5.4. The following operations have been performed to
produce this specialised feature model:

23
Note that the customisation request is an optimised customisation request. Therefore, there exist
no undecided variant features that can be further inferred from this customisation request.
112
i. The selected feature Residential become mandatory (i.e. its feature cardinality
is [1-1]), while four disabled features Business, ExtendedThirdPartyLiabil-
ity, PolicyUpdate, PolicyQuery are removed.
ii. The group cardinality [1-1] for the parent feature PolicyType is no longer nec-
essary since the feature Residential has already been selected. Besides, the
group cardinality [1-3] for the parent feature ExtraCover is updated to [1-2]
since the feature ExtendedThirdPartyLiability has already been removed.
iii. Both two feature constraints (i.e. PolicyUpdate requires PolicyQuery and
Residential excludes ExtendedThirdPartyLiability) are no longer neces-
sary since either relevant features are removed or these feature constraints
establish with the specialised feature model.
After specialising the feature model, the runtime engine registers the new feature
model to the component Feature model manager. In addition, the description of customi-
sation options in the new WSVL document (which describes the refined customisable
service) is generated from this specialised feature model.
5.4.2.2 Specialising service capability description
Service capability description is specialised by evaluating the propositional formula
associated with each variant service capability. If the evaluation result is true with respect
to the feature configuration, the variant service capability becomes mandatory (or
common capability). If the evaluation result is false, the variant service capability is
purged from the description. Importantly, if the propositional formula is undecided due to

Figure 5.4 - A specialised feature model
Swinsure Insurance Web Service
Policy Creation
Quote Purchase
[1-1]
Policy Type Extra Cover
Residential
[1-1] [0-1]
[1-1] [0-1]
[1-2]
Accidental Damage Fusion Cover
Payment Method
[1-1]
[1-1]
Credit Card Cover Note
[1-1]
113
the existence of undecided variant features, the propositional formula is specialised by
removing all decided variant features. And the variant service capability remains variant
in the new WSVL document. In this case, the specialised propositional formula will be
used to define the presence condition for this variant service capability.
Note that the presence condition of a variant service capability is expressed as If the
variant features A
1
, A
2
,, A
n
1
, B
2
,, B
m
are
disabled, this variant capability is available. Its associated propositional formula is
. Therefore, this propositional formula is true

with respect to one feature configuration if all features A
i
(1 i n) are selected and all
features B
j
(1 j m) are disabled in that feature configuration. In contrast, if at least
one of the features A
i
(1 i n) is disabled or at least one of the features B
j
(1 j m)
is selected in the feature configuration, the propositional formula is evaluated to false.
Otherwise, when a subset of features A
i
(1 i h) are selected and a subset of features
B
j
(1 j k) are disabled, the variant service capability remains variant with the updated
propositional formula as If the variant features A
h+1
,, A
n
features B
k+1
,, B
m
are disabled, this variant capability is available.
Figure 5.5 presents an example of a specialised service capability with respect to the
customisation request CR introduced in the previous section. The original service capabil-
ity has been explained in Example 4.4. From the original service capability, two
operations getQuote4Business and getQuote4BusinessWithExtra are purged. This is
because both operations require the feature Business to be selected while the feature is
disabled in the customisation request CR. The portType purchasingPortType and three
operations getQuote4Residential, getQuote4ResidentialWithExtra, and addAcci-
dentalDamage remain variant service capabilities since their associated propositional
formulas still contain undecided variant features (i.e. the features Purchase, Extra-
Cover, and AccidentalDamage respectively). However, these propositional formulas
are updated as explained above to indicate new presence conditions for those variant
service capabilities.

Figure 5.5 - The description of service capability after specialisation
<wsdl:operation name="getQuote4Residential"/>
<wsdl:operation name="getQuote4ResidentialWithExtra"/>
<wsdl:operation name=addAccidentalDamage"/>
</wsdl:portType>
<wsdl:portType name="purchasingPortType/>
114
5.4.2.3 Specialising feature mapping description
The specialised feature mapping description defines the mapping between variant features
in the specialised feature model and variant service capabilities in the specialised service
capability. In particular, the specialised feature mapping description captures specialised
propositional formulas produced in the previous section. A feature mapping description is
specialised through two steps:
i. For each variant service capability which either becomes mandatory or be re-
moved from the service capability description, all of its mapping links are purged.
ii. For each variant service capability which remains variant, all of its mapping links
which refer decided variant features (i.e. either selected features or disabled fea-
tures) are purged while other mapping links are retained.
For instance, with respect to the customisation request CR, the description of feature
mapping for Swinsure Insurance Web service is specialised as shown in Figure 5.6. Note
that for the original feature mapping description (cf. Example 4.5) the presence condition
of the operation getQuote4Residential is defined by two links. The two links collec-
tively represent the propositional formula Residential ExtraCover. Since the feature
Residential has already been selected, this propositional formula is updated to
ExtraCover. It means that the presence condition of this operation is defined by only
one link as shown in Figure 5.6. Similar specialisation is applied to other variant service
capabilities and links.

Figure 5.6 - The description of feature mapping after specialisation
<mappingInfo>
<link name=" LResidential2">
<featureRef ref="fd:ExtraCover" presence=false"/>
</link>
<link name=" LResidentialWithExtra2">
<featureRef ref="fd:ExtraCover" presence=true"/>
</link>
<link name=" LAccidentalDamage">
<featureRef ref="fd:AccidentalDamage" presence=true"/>
<serviceElementRef ref="tns:addAccidentalDamage target="operation" />
</link>
<link name="LPurchase">
<featureRef ref="fd:Purchase" presence="true"/>
<serviceElementRef ref="tns:purchasingPortType target="portType" />
</link>
</mappingInfo>
115
5.4.2.4 Deploying variant customisation frontend and deriving WSVL
description
The runtime engine deploys a new customisation frontend, called Variant customisation
frontend at Variant customisation endpoint. The Variant customisation frontend has the
similar function to the original Customisation frontend. However, it is associated with
the specialised feature model and only accepts customisation requests conforming to the
specialised feature model through the Variant customisation endpoint.
The capability of this Variant customisation frontend is packaged as the description
of customisation endpoint in the new WSVL document. At this stage, the runtime engine
is able to produce the full WSVL document for the refined customisable service. New
WSVL document is returned to service consumers by the Customisation frontend so that
service consumers are able to start consuming the refined customisable service.
5.4.3 Runtime representation of refined customisable services
The runtime representation of a refined customisable service comprises of a Variant
customisation frontend discussed in section 5.4.2.4 and the original component Configu-
rable service implementation. During the specialisation process, the component
Configurable service implementation remains intact. It is shared by both the original
customisable services and refined customisable services for addressing customisation
messages destined to either Customisation frontend or Variant customisation frontend.
In fact, the component Configurable service implementation might be specialised in
a similar way to the specialisation of the WSVL document. However, the specialised
configurable service implementation then needs to be stored and managed as an inde-
pendent component for serving the refined customisable service. While such approach
has the advantage of clearly separating the refined customisable service and the original
customisable service, the big disadvantage is the duplication of a large part of software
artefacts in the service platform. This is because there are many commonalities between
the original Configurable service implementation and the one resulted from its speciali-
sation. Such duplication becomes more significant if the number of refined customisable
services increases or the service is customised in multiple stages. To avoid such duplica-
tion, we add a subtle change to the operation of the Variant customisation frontend as
described in the next section. The change enables the component Configurable service
implementation to be shared between the original customisable service and any refined
customisable service.
116
5.4.4 Processing customisation requests destined for refined customisable
services
Each Variant customisation frontend keeps the feature configuration by which the
Variant customisation frontend is created. We call this feature configuration first-tier
feature configuration. Upon the arrival of a customisation request through the Variant
customisation endpoint, the Variant customisation frontend validates it against the
specialised feature model. This function is exactly the same as the one performed by the
Customisation frontend. However, for a valid customisation request, the Variant
customisation frontend does not pass it as-is to the runtime engine. Instead, the Variant
customisation frontend combine the valid customisation request with the first-tier feature
configuration. The new feature configuration is passed to the runtime engine as a
customisation request for the original customisable service. And the runtime engine will
process this new customisation request in the same way as the process described in the
section 5.3.3.
For instance, the first-tier feature configuration for the specialised feature model
in Figure 5.4 is CR=({Residential}, {Business, ExtendedThirdPartyLiability, Poli-
cyUpdate, PolicyQuery}). When the Variant customisation frontend receives a
customisation request likes CR
1
=({ExtraCover, AccidentalDamage}, {FusionCover,
Purchase, PaymentMethod, CreditCard, CoverNote}), it produces the new feature
configuration New_CR=({Residential, ExtraCover, AccidentalDamage}, {Business,
ExtendedThirdPartyLiability, FusionCover, PolicyUpdate, PolicyQuery, Purchase,
PaymentMethod, CreditCard, CoverNote). Note that CR
1
is a complete customisation
request with respect to the specialised feature model, while New_CR is a complete
customisation request with respect to the original feature model. The Variant customisa-
tion frontend then pass the New_CR to the runtime engine for service variant derivation.
5.5 Analysis of the service provisioning architecture against
service variability characteristics
We analyse our techniques for provisioning customisable services against characteristics
of service variability identified in Chapter 2. In particular, the following characteristics
have been addressed (Figure 5.7):
Automated: The service provisioning architecture supports the automated deriva-
tion of service variants according to a given feature configuration. This is
generally performed in two steps. Firstly, the component Customisation frontend
validates customisation requests. Secondly, the runtime engine dynamically re-
5.6 Summary
117
solves variability in the configurable service implementation and deploys the de-
rived service variants in case of valid feature configurations.
Staged instantiation: This is performed by the runtime engine which propagates
variability resolution decisions in the feature model (i.e. a feature configuration)
to resolve variability in the configurable service implementation. Typically,
staged instantiation is achievable since we explicitly manage the mapping be-
tween variability at the feature level and variability at the service implementation
level. In subsequent chapters (i.e. Chapter 6 and Chapter 7), we elaborate how
this process is performed with regard to customisable atomic services and cus-
tomisable composite services respectively.
5.6 Summary
In this chapter, we have described an architecture for deploying and provisioning cus-
tomisable services. The architecture provides a blueprint for service providers to extend
their existing service platforms in order to accommodate customisable services. It
consists of a number of components specialized for performing different functions of
service customisation (e.g. validation of customisation requests, service variant lifecycle
management, or runtime variability resolution). With respect to a new customisable

Variation
points and
variants
Intra-
dependencies
Architecture Implementation Composition
variability
Level
(Interface/
Implementation)
Service variability
Internal
Partner
variability
External
Automated Inter-
dependencies
Exposed
variability
Variability
communication
independence
Self-
describing
Staged
instantiation
Who
(Provider/
Consumer)
level
Requirement
Variability
constraints
Service provisioning
118
service, software developers only need to develop the component Configurable service
implementation and reuse other components to have a properly functioning customisable
service. The service provisioning architecture and its mechanism work in the same way
for both customisable atomic services and customisable composite services. While the
components and operations of the service provisioning architecture have been discussed
in this chapter, we will discuss its prototypical implementation and evaluation in the next
chapter when we consider customisable atomic services.

119

6. Enabling Customisable Atomic Services
Last chapter, we discussed an architecture for deploying and provisioning customisable
services. The service provisioning architecture defines a number of components for
performing different functions related to service customisation (e.g. the validation of
customisation requests or the management of service variants). While the functionalities
and operations of generic components (e.g. Customisation frontend or Feature model
manager) have been discussed, the detail for the component Configurable service
implementation was not given. This detail involves techniques for: i) engineering the
configurable service implementation and ii) dynamic resolution of variability in the
configurable service implementation to produce service variants. This chapter discusses
such techniques for supporting customisable atomic services. These techniques collec-
tively enable the realisation of customisable atomic services (Figure 6.1). As discussed in
Chapter 5, we only consider complete customisation requests in this chapter. Concerns
regarding partial customisation requests have already been discussed in section 5.4. Note
that the term customisable services should be interpreted as customisable atomic
services in this chapter unless otherwise stated.
Section 6.1 reviews techniques for engineering conventional Web services. In par-
ticular, we describe two alternative approaches (i.e. top-down and bottom-up) for Web
service development in subsection 6.1.1. Subsection 6.1.2 presents a standard, called
JAX-WS, which defines techniques that enable both approaches.
Section 6.2 discusses our extension of the JAX-WS standard for engineering the
component Configurable service implementation of customisable atomic services. In
particular, we identify two types of variability within the configurable service implemen-
tation: variability in the service skeleton and variability in the business logic. We then
describe solutions for addressing each type of variability respectively. Based on these

Customisation
framework
Atomic service
realisation
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
language
Composite service
realisation
4
This chapter
Chapter 6 - Enabling Customisable Atomic Services
120
solutions, section 6.3 discusses the variability resolution mechanism which will be
utilised by the runtime engine to dynamically derive service variants.
Section 6.4 describes the prototype system and evaluation of its functionalities. In
particular, we discuss the prototypical implementation of the service provisioning
architecture in subsection 6.4.1. The realisation of a motivating customisable service (i.e.
the Swinsure Insurance Web service) within the service provisioning architecture is
described in subsection 6.4.2. Subsection 6.4.3 presents the consumer prototype tool for
interacting with the Swinsure Insurance Web service. We describe the evaluation of
different aspects in operating customisable services in subsection 6.4.4 (e.g. the validation
of customisation requests, lifecycle management of service variants, or runtime resolution
of variability).
Similar to other chapters, we analyse our techniques for enabling customisable atom-
ic services against service variability characteristics in section 6.5. We then conclude the
chapter in section 6.6.
6.1 Reviewing engineering techniques for conventional Web
services
6.1.1 Top-down approach versus bottom-up approach
There are two alternative ways for developing conventional atomic services: Top-down
and bottom-up (Balani 2009). The top-down approach
24
starts with the development of a
service interface description (i.e. WSDL). The service interface description is then used to
automatically generate service skeleton which is the template implementation of the
service-to-be. Software developers need to add business logics to the service skeleton in
order to have an executable service implementation. For the top-down approach, the
service interface is first designed to match business objectives of the service provider
before the service is implemented. Consequently, the approach supports a better align-
ment between business and IT, as well as the interoperability between service providers
and service consumers (Provost 2003). This approach is appropriate for developing new
services.
In contrast, the bottom-up approach
25
starts with the implementation of the business
logic. The service interface description is typically generated from the service implemen-
tation with the support of service platforms. Since the service implementation is done

24
In some cases, this approach is referred to as contract-first or WSDL-first
25
In some cases, this approach is referred to as implementation-first or code-first
6.1 Reviewing engineering techniques for conventional Web services
121
first, the generated service interface description tends to depend on the programming
language in use which makes this approach less interoperable (Provost 2003). In general,
this approach is appropriate when there is a need for wrapping existing software compo-
nents as Web services.
6.1.2 The JAX-WS standard
Regardless of which approach is used, both approaches rely on a mapping between
WSDL elements for describing the service interface and programming constructs for
realising the service implementation. This mapping enables the automated generation of
the service skeleton from a WSDL document or the automated generation of a WSDL
document from the service implementation. While there are different alternatives for
engineering Web services, we use JAX-WS (Java API for XML-based Web services)
(Kotamraju 2009) to illustrate our approach. JAX-WS is a widely-used standard that
defines the following mapping between WSDL elements and Java constructs:
i. A portType element in a WSDL document is mapped to a Java interface.
ii. An operation element is mapped to a Java method within the corresponding inter-
face.
iii. XML schema types for message definitions are mapped to Java objects.
Figure 6.2 presents an example of JAX-WS. The upper part of the figure presents a
WSDL document, while the lower part shows the corresponding service skeleton. The
WSDL document has one portType quotingPortType (line 1) which contains two
operations getQuote4Residential (line 2) and getQuote4ResidentialWithExtra (line
6). Accordingly, the service skeleton has one interface (line 12) and two methods (line 14
and line 18 respectively). The @WebService annotation (line 11) is used with a Java
interface to define that the interface is mapped to a portType. The optional property
name of the annotation specifies the name of the mapped portType. Similarly the
@WebMethod annotation (cf. line 13 or line 17) is used with a Java method to define
that the method is mapped to an operation. As can be seen from the example, JAX-WS
mapping rules and annotations enable the automated transformation from WSDL to
service skeleton and vice versus. In addition, the annotations (i.e. @WebService and
@WebMethod) also help to differentiate Java constructs mapped to service interface
elements with normal Java constructs for implementation purposes. This enables service
platforms to properly deploy a service implementation (i.e. service skeleton added with
business logics).
122
6.2 Engineering the configurable service implementation
In this section, we discuss our solution for engineering the configurable service imple-
mentation of a customisable atomic service which is described by a WSVL document.
The configurable service implementation is the implementation of the full service capabil-
ity with configuration points. The full service capability is specified in the service
capability description of the WSVL document. And configuration points allow the
runtime engine to dynamically resolve variability in the configurable service implementa-
tion with respect to a feature configuration. Such variability resolution needs to conform
to the mapping specified in the feature mapping description of the WSVL document. This
requirement guarantees the correct use of the WSVL document as a customisation
contract. In other words, service consumers are able to achieve a service variant with
capabilities as promised in the WSVL document.
The implementation of the full service capability is supported by the JAX-WS stand-
ard. In particular, the service capability description in WSVL is based on WSDL XML
notations and represents the superset of capabilities of all service variants. Therefore,
software developers are able to generate service skeleton from the service capability
description and add business logics to the generated service skeleton in the same way as

Figure 6.2 - A JAX-WS example
01: <wsdl:portType name="quotingPortType">
02: <wsdl:operation name="getQuote4Residential">
03: <wsdl:input message="tns:getQuote4Residential/>
04: <wsdl:output message="tns:getQuote4ResidentialResponse/>
05: </wsdl:operation>
06: <wsdl:operation name="getQuote4ResidentialWithExtra">
07: <wsdl:input message="tns:getQuote4ResidentialWithExtra/>
08: <wsdl:output message="tns:getQuote4ResidentialWithExtraResponse/>
09: </wsdl:operation>
10: </wsdl:portType>
11: @WebService(name = "quotingPortType")
12: public interface QuotingPortType {
13: @WebMethod(name = getQuote4Residential)
14: public GetQuote4ResidentialResponse getQuote4Residential(
15: GetQuote4Residential request);
16:
17: @WebMethod(name = getQuote4ResidentialWithExtra)
18: public GetQuote4ResidentialWithExtraResponse getQuote4ResidentialWithExtra(
19: GetQuote4ResidentialWithExtra request);
20: }
WSDL description
Service skeleton
123
developing conventional services. To enable the definition and the introduction of
configuration points in the implementation of the full service capability, we identify two
types of service variability at the implementation level and extend the JAX-WS standard
to support them (Nguyen 2012a). The two types are variability in the service skeleton and
variability in the business logic.
6.2.1 Variability in the service skeleton
Variability in the service skeleton directly reflects service variability specified in a
WSVL document. In particular, there are alternative Java interfaces for realising alterna-
tive portTypes or optional Java methods for implementing optional operations. Due to the
one-to-one mapping between Java constructs and service interface elements, the presence
condition of these variant Java constructs is the same as the presence condition of the
corresponding service interface elements. As described in Chapter 4, this presence
condition is specified by a set of enabled features and a set of disabled features.
To support configuration points related to this type of service variability, we define a
new JAX-WS annotation type, called FeatureMapping. Figure 6.3 presents the definition
of this new JAX-WS annotation type based on Java annotation syntax (Oracle 2012).
Each FeatureMapping annotation has two properties, enabledFeatureList and disa-
bledFeatureList, which are defined in line 6 and line 7 respectively. While the
enabledFeatureList property is defined as an array of String for capturing a set of enabled
features, the disabledFeatureList property is an array for storing a set of disabled features.
The @Target annotation (line 2-4) defines that FeatureMapping annotations are
applicable to the declarations of fields (line 2), methods (line 3), and interfaces (line 4). In
addition, the @Retention annotation (line 1) specifies that FeatureMapping annota-
tions are available to be examined at runtime. This property is important to enable the
runtime engine to resolve variability dynamically.

Figure 6.3 - New JAX-WS annotation type
01: @Retention(RetentionPolicy.RUNTIME)
02: @Target({ElementType.TYPE,
03: ElementType.METHOD,
04: ElementType.INTERFACE})
05: public @interface FeatureMapping {
06: public String[] enabledFeatureList();
07: public String[] disabledFeatureList();
08: }
124
Figure 6.4 presents examples of the new annotation type. These examples are ex-
tracted from the service skeleton for implementing the Swinsure Insurance Web service.
The upper part of the figure shows the application of the new annotation type to the
service skeleton already presented in Figure 6.2. A FeatureMapping annotation is used on
line 4 to indicate that the method getQuote4Residential is only available when the
feature Residential is selected (cf. the property enabledFeatureList) and the feature
Extra Cover is disabled (cf. the property disabledFeatureList). In contrast, the
FeatureMapping annotation on line 8 defines that when the two features are selected, the
method getQuote4ResidentialWithExtra is available. It is also clear from the example
that the interface QuotingPortType is always available since it is not marked as a
variant using a FeatureMapping annotation. In contrast, the FeatureMapping annotation
on line 13 specifies that the interface PurchasingPortType is only available when the
feature Purchase is selected. As discussed, these FeatureMapping annotations repre-
sent the exact information specified in the feature mapping description of the WSVL
document (cf. Example 4.5). Note also that the upper part of the figure demonstrates the
use of FeatureMapping annotations with respect to methods, while the lower part
illustrates the use of FeatureMapping annotations with a Java interface.
6.2.2 Variability in the business logic
Variability in the business logic occurs when the business logic is added to the service
skeleton to have a complete service implementation. It represents variability in the
implementation logic of each variant capability. Remember that a variant capability is
associated with a set of selected features and a set of disabled features (i.e. a feature
configuration). Such feature configuration is generally not complete and there are

Figure 6.4 - Example of the new JAX-WS annotation
01: @WebService(name = "quotingPortType")
02: public interface QuotingPortType {
03: @WebMethod(name = getQuote4Residential)
04: @FeatureMapping(enabledFeatureList={"Residential"}, disabledFeatureList={"Extra Cover"})
05: public GetQuote4ResidentialResponse getQuote4Residential(getQuote4Residential request);
06:
07: @WebMethod(name = getQuote4ResidentialWithExtra)
08: @FeatureMapping(enabledFeatureList={"Residential","Extra Cover"}, disabledFeatureList={})
09: public GetQuote4ResidentialWithExtraResponse getQuote4ResidentialWithExtra(
10: GetQuote4ResidentialWithExtra request);
11: }
12: @WebService(name = purchasingPortType")
13: @FeatureMapping(enabledFeatureList={Purchase"}, disabledFeatureList={})
14: public interface PurchasingPortType {
15: }
125
undecided variant features. It means the business logic of the variant capability needs to
cater for all those undecided variant features. Variability in the business logic rises when
there is a need for having different processing logics specific to state of those undecided
variant features. For instance, the method getQuote4ResidentialWithExtra demonstrat-
ed in Figure 6.4 is used to produce a quote for a residential insurance policy with extras.
The method is available in service variants providing different types of extras (i.e. any
combination of three extras Accidental Damage, Fusion Cover or Extended Third
Party Liability). The business logic of this method exposes variability regarding which
extra combinations are provided in one particular service variant.
Variability in the business logic needs to be resolved at runtime by the runtime en-
gine. There are a number of techniques for this purpose (Svahnberg 2005). For instance,
alternative behaviors are collected into separate classes/methods and a Design Pattern
(e.g. Strategy, Template Method, or Abstract Factory) is used to select between these
classes (Gamma 1995). Or alternative behaviors are dynamically injected at runtime
using reflection and aspect-oriented techniques (Bosch 1999). In general, the use of
runtime approaches requires the ability to dynamically switch between different pro-
cessing logics. Therefore, we exploit the concept of Web Service Context in JAX-WS for
supporting this category. Web Service Context is a resource injected at runtime by service
engine and can be used in the implementation logic of Web services. Thus, we use this
property to initialise the service context (i.e. which features are enabled/disabled) for a
particular service variant at the time the variant is deployed. In the business logic of the
service implementation, such information can be referred to in order to realise variability.
Figure 6.5 presents an example of this extended use of Web Service Context. This
example simulates the business logic of the method getQuote4ResidentialWithExtra.
The annotation @Resource (line 1) is used to denote that the variable context (or the

Figure 6.5 - Example of JAX-WS Web Service Context
01: @Resource
02: private WebServiceContext context;
03:
04: Double extraCoverRatio = 1.0;
05:
06: if (((Boolean)context.getMessageContext().get(Accidental Damage")) == Boolean.TRUE) {
07: extraCoverRatio *= accidentalDamageRatio;
08: }
09: if (((Boolean)context.getMessageContext().get(Fusion Cover")) == Boolean.TRUE) {
10: extraCoverRatio *= fusionCoverRatio;
11: }
12: if (((Boolean)context.getMessageContext().get(Extended Third Party Liability")) == Boolean.TRUE) {
13: extraCoverRatio *= ExtendedThirdPartyLiabilityRatio;
14: }
126
resource context) (line 2) is a Web Service Context which will be injected by the runtime
engine. The resource context contains the initialised feature set for one service variant.
Consequently, the first code block (line 7) is only executed if the feature Accidental
Damage is enabled. Similarly, the second and third code blocks (line 10 and line 13) are
controlled by the features Fusion Cover and Extended Third Party Liability respec-
tively.
With the extended use of Web Service Context, developers are free to use any exist-
ing technique for realising variability in business logics while relying on our extension to
trigger the dynamic switching among alternative behaviors according to a customisation
request (i.e. a feature configuration).
6.3 Runtime variability resolution
The runtime engine performs two functions for resolving variability with respect to a
feature configuration. Firstly, it uses reflection techniques (Dawson 2008) to examine the
configurable service implementation. For each service capability (e.g. interface/method
for realising portType/operation), the runtime engine evaluates the associated Feature-
Mapping annotation against the requested feature configuration. If the annotation is true,
the service capability is retained in the resulting service variant. Otherwise, the service
capability is purged from the capability of the service variant. The use of reflection
techniques helps to resolve variability in the service skeleton. Note that we only consider
complete customisation requests in this chapter. For complete customisation requests,
there exist no undecided variant features. Therefore, all FeatureMapping annotations
must be evaluated to TRUE or FALSE.
Secondly, the runtime engine initialises the Web Service Context for the resulting
service variant. Based on the feature configuration, the runtime engine assigns the
corresponding TRUE/FALSE value to selected/disabled features and stores those values
in the Web Service Context. The runtime engine then deploys the resulting service
variant. The initialisation of the service context when a service variant is deployed
enables the service variant to execute its business logic properly according to the feature
configuration to which it is associated. It means variability in the business logic is
properly resolved at the runtime when processing service consumption requests from
service consumers. Note that the mechanism for the runtime injection of the Web Service
Context is not specified in JAX-WS. Instead, it is specific to service platforms imple-
menting JAX-WS. Therefore, we do not detail it here. In the prototype implementation
6.4 Prototype implementation and evaluation
127
section, we discuss our implementation on one open source service platform, called
Apache CXF.
As discussed in Chapter 5, the realisation of components of the service provisioning
architecture is specific to service platforms. In section 6.4.1 we present a prototype
system implementing the service provisioning architecture on Apache CXF (Apache
2012). The Apache CXF is an open source Web service framework for supporting atomic
services. The prototype system enables the deployment of any WSVL-based customisable
atomic services. In section 6.4.2, we describe the implementation of the Swinsure
Insurance Web service which has been deployed to the prototype system. Both the
prototype system and the example service are running on Amazon cloud for evaluation.
To evaluate the operations of the prototype system and the example service, we have
extended our consumer prototype tool (cf. section 4.3.2) so that it is able to interact with
the example service for requesting service customisation. Section 6.4.3 discusses the
consumer prototype tool. And section 6.4.4 presents various evaluations that we have
been performed with these prototype tools.
6.4.1 Implementing the service provisioning architecture
The implementation of the component Feature model manager is based on the FAMA
(FeAture Model Analyser) framework (Benavides 2012). The FAMA framework utilises
several solvers (e.g. SAT or JaCoP) for enabling the automated analysis of feature
models. In our prototype system, we exploit the FAMA framework for validating feature
configurations (i.e. validating customisation requests), enumerating the number of
products with respect to a feature configuration (i.e. checking if a customisation request is
complete or partial), and inferring further features from a feature configuration (i.e.
generating optimised customisation requests). The use of the FAMA framework for
validating feature configurations has been demonstrated in Example 4.6 - Java snippet
for validating feature configuration of Section 4.3.4.1.
The component Customisation frontend is implemented as a Web service which has
one customisation operation. The operation accepts a customisation request and returns
the URI from which the WSDL of a service variant can be retrieved (cf. Example 4.2 for
the detail of this operation). The Customisation frontend service also provides a REST
interface for exposing the WSVL document of the associated customisable service.
128
The component Variant profile repository in our prototype system enables the regis-
tration and management of variant endpoints for deployed service variants. For each
variant endpoint, the component stores the feature configuration for which the service
variant is deployed, deployment types (i.e. permanent or temporary), deployment status
(i.e. active or expired), and deployment time (i.e. start time and end time).
The component Runtime customisation and management engine is a server com-
ponent which uses Java reflection to examine and resolve variability in the configurable
service implementation as described in section 6.3. Figure 6.6 demonstrates the operation
of this component using the Swinsure Insurance Web service. The left hand side of the
figure is the in-memory representation of the service model (i.e. runtime service model)
for a customisable service. The runtime engine builds up this service model based on the
service skeleton. The runtime service model has similar structure to a service interface
model as discussed in Chapter 4. In particular, it has service components, portType
components, and operation components. Some components are not annotated with the
FeatureMapping annotations (e.g. ServiceInfo(Swinsure) or InterfaceIn-
fo(quotingPortType)). These components are mandatory service capabilities. In
contrast, other components representing variant service capability are annotated with the
FeatureMapping annotations (e.g. InterfaceInfo(purchasingPortType), Operation-
Info(purchasePolicyByCreditCard)). FeatureMapping annotations are represented
above the corresponding components with a set of selected features followed by a set of
disabled features. The runtime engine is able to construct this runtime service model on
account of our new annotation type, i.e. FeatureMapping, which is available to be

Figure 6.6 - Runtime representation of customisable services and service variants
ServiceInfo(Swinsure)
InterfaceInfo(quotingPortType)
({Residential},{Extra Cover})
OperationInfo(getQuote4Residential)
({Residential, Extra Cover},{})
OperationInfo(getQuote4ResidentialWithExtra)
({Business},{Extra Cover})
OperationInfo(getQuote4Business)
({Business, Extra Cover },{})
OperationInfo(getQuote4BusinessWithExtra)
({Accidental Damage},{})
OperationInfo(addAccidentalDamage)
({Purchase},{})
InterfaceInfo(purchasingPortType)
({Credit Card},{})
OperationInfo(purchasePolicyByCreditCard)
({Cover Note},{})
OperationInfo(purchasePolicyByCoverNote)
ServiceInfo(Swinsure)
InterfaceInfo(quotingPortType)
OperationInfo(getQuote4ResidentialWithExtra)
OperationInfo(addAccidentalDamage)
customisable service representation
service variant representation
Selected:
Residential,
Extra Cover,
Accidental Damage
Disabled:
Business,
Purchase,
Credit Card,
Cover Note
service component
portType component
operation component
FeatureMapping annotation
feature configuration
129
examined at runtime. The runtime engine then evaluates these annotations against a given
feature configuration which is shown around the arrow in the middle of the figure. Based
on the evaluation results, the runtime engine produces the runtime service model for a
service variant which is shown on the right hand side of the figure.
For instance, the evaluation of the FeatureMapping annotation associated with the
portType component InterfaceInfo(purchasingPortType) results in its removal since
the feature Purchase is disabled. Similarly, the other components like OperationIn-
fo(getQuote4Residential) or OperationInfo(getQuote4Business) are also removed
from the original runtime service model, while the components OperationIn-
fo(getQuote4ResidentialWithExtra) or OperationInfo(addAccidentalDamage) are
retained. In summary, the use of FeatureMapping annotations and reflection techniques
enable runtime resolution of variability in the service skeleton.
In addition, the runtime engine uses Interceptor, which is Apache CXF specific mes-
sage processing mechanism, to initialise the Web Service Context before deploying a
service variant. Figure 6.7 demonstrates this operation. In Apache CXF, any incoming
message for a Web service is processed through a chain of Interceptors before being
passed to the business logic of the Web service. This chain is called the Inbound intercep-
tor chain. Similarly, there is one Outbound interceptor chain for outgoing messages.
Various Interceptors are defined in Apache CXF for parsing XML messages, logging, or
enforcing security policies. What Interceptors to be used in the chains is specific to a
service. That is, according to the business logic, each Web service is configured with
particular Interceptors for its inbound and outbound interceptor chains.

Figure 6.7 - Initialise Web Service Context
Inserting feature
configuration
Logging
Policy
enforcement
Business
logic
Logging
Header
filter
Inbound interceptor chain
Outbound interceptor chain
Variant
endpoint
ServiceContextInterceptor Interceptor
130
We extend Apache CXF with a new Interceptor, called ServiceContextInterceptor,
which inserts a feature configuration into the message context of incoming messages. The
message context is a part of Web Service Context. The runtime engine adds the new
ServiceContextInterceptor to the beginning of the inbound interceptor chain before
deploying a service variant. Consequently, the deployed service variant has the feature
configuration stored in its service context. Based on this information, dynamic resolution
of variability in the business logic can be achieved.
6.4.2 Implementing the Swinsure Insurance Web service
The Swinsure Insurance Web service is developed following the top-down approach. In
particular, we follow the engineering process discussed in Chapter 4 to produce the
WSVL description of this customisable service. We then use this WSVL document to
implement the service.
Note that the description of service capability in the WSVL document is specified
using WSDL notations. From this description, we use WSDL2Java tool, which is an
implementation of JAX-WS in Apache CXF, to generate the service skeleton for the
customisable service. Based on the description of feature mapping, we annotate each
variant service capability with corresponding selected and disabled features using our
defined FeatureMapping annotation type. We then add the business logic of the cus-
tomisable service to the service skeleton (cf. Figure 6.4). During this process, wherever
there is variability in the business logic, we use the extended Web Service Context as
discussed in section 6.2.2. The result of this process is a configurable service implementa-
tion which is then deployed to our prototype system of the service provisioning
architecture.
Both the prototype system and the Swinsure Insurance Web service were successful-
ly deployed on the Amazon cloud (Nguyen 2011a) and are globally accessible. In the
evaluation section, we will provide the evaluation results with respect to this prototype.
6.4.3 Extending consumer prototype tool
To evaluate the operations of the prototype system and the Swinsure Insurance Web
service, we extend our feature modeling tool discussed in Chapter 4 to have a consumer
prototype tool. The consumer prototype tool works as a Web service client with respect to
the component Customisation frontend of our prototype system on the Amazon cloud for
exchanging customisation messages. In addition, the consumer prototype tool works as a
Web service client with regard to the resulting service variants for service consumption.
131
The consumer prototype tool comes in two versions. One version is an Eclipse plugin,
while the other version is a console program. Both versions are available from our project
website (Nguyen 2011a).
Figure 6.8 presents screenshots of our prototype system and consumer prototype
tool. The WSVL document
26
is exposed by the component Customisation frontend in a
similar format to what a WSDL document for a Web service is exposed (i.e. ser-
viceEndpointURI?wsdl) (Kotamraju 2009). From the Eclipse plugin version of the
consumer prototype tool, we are able to create a feature configuration, send a customisa-
tion request to the Customisation frontend and receive a customisation response which is
the URI for the WSDL document of a dynamically deployed service variant
27
.

26
Swinsure WSVL: http://ec2-107-21-175-19.compute-1.amazonaws.com:8080/swinsure-
CustomizationFrontend?wsvl. The offline version of this document can be found on Appendix B.
27
Service variants WSDL: http://ec2-107-21-175-19.compute-1.amazonaws.com:8080/swinsure-
ServiceVariant/1/Quoting?wsdl=1_full

Figure 6.8 - The prototype system on Amazon cloud and consumer prototype tool
Request
Response
WSVL document
exposed by
Customisation
frontend
132
6.4.4 Evaluating the operations of the service provisioning architecture and
the example customisable service
In this section, we describe various evaluations of the prototype system and the example
customisable service. The evaluations illustrate the applicability and the feasibility of our
technique in supporting the development, provisioning and consumption of customisable
atomic services. In particular, we use the consumer prototype tool to invoke both the
service customisation function and the variant provisioning function provided by the
example customisable service (cf. section 4.1 for the explanation of these functions).
These tests help to answer the following questions:
i. Does the prototype system accurately validate customisation requests? (section
6.4.4.1)
ii. Is the lifecycle of service variants properly managed? (section 6.4.4.2)
iii. Does the dynamic derivation of service variants work as expected? This question
is investigated in two aspects: a) is variability in service skeleton properly re-
solved (section 6.4.4.3)? and b) is variability in the business logic properly
resolved (section 6.4.4.4)?
Note that the variability communication function provided by customisable services
has already been confirmed in Figure 6.8 by checking the publication of the WSVL
document by the Customisation frontend. Given this published WSVL document, service
consumers are able to comprehend the service variability and customise the service.
6.4.4.1 Validity of customisation requests
To test the capability of our prototype system in validating customisation requests, we
need to produce invalid feature configurations and use them as customisation requests.
The Eclipse plugin version of the consumer prototype tool provides the capability to
dynamically verify the validity of a feature configuration during the customisation

Figure 6.9 - Validation of customisation requests
First
request
Second
request
133
process. It means all feature configurations produced by this version are valid with
respect to the original feature model. Therefore, for the purpose of this test we need to use
the console program version. Figure 6.9 presents the screenshot of sending two invalid
customisation requests to the component Customisation frontend. The first customisation
request is invalid since the feature Extra Cover is selected while all of its child features
are disabled. This violates its group cardinality [1-3] (cf. the feature model for the
Swinsure Insurance Web service in Figure 3.2). In contrast, the second customisation
request is invalid since both features Residential and Extended Third Party Liability
are selected while they are mutually excluded. The execution results show the correct-
ness of our prototype system in validating customisation requests.
6.4.4.2 Lifecycle management of dynamically deployed service variants
The first function for the service variant lifecycle management is the reuse of existing
service variants. Figure 6.10 demonstrates the use of three valid customisation requests in
which the first and the third ones contain the same feature configuration. As can be seen
from the execution result, the first and the third service variants are deployed at the same
variant endpoint, while the second service variant is deployed at a different variant
endpoint (cf. the last line for each section). Checking the WSDL documents and invoking
corresponding service variants also confirmed that the first and the third service variants
are the same and are different from the second service variant.
Figure 6.11 shows the management page which exposes information for deployed
service variants
28
. The Deployment type of a service variant might be permanent or
temporary. Temporarily deployed service variants only exist for 1 hour in our prototype

28
Management page: http://ec2-107-21-175-19.compute-1.amazonaws.com/admin/variantList.jsp

Figure 6.10 - Reuse of service variants
First
request
Second
request
Third
request
134
system. The Start time and End time represents the time a service variant is activated and
deactivated respectively. Note that the End time is only applicable to temporarily de-
ployed service variants. The Status shows the current state of a service variant which
might be active or expired. Lastly, the Endpoint is the variant endpoint, while the Feature
configuration represents customisation requests. Using the consumer prototype tool, we
also confirm the correctness of this information from consumers perspective. In particu-
lar, we confirm that:
An expired service variant is not invoke-able.
Temporary service variants expire after 1 hour.
6.4.4.3 Runtime resolution of variability in service skeleton
Figure 6.12 presents screenshots of the consumer prototype tool when consuming two
service variants. The top left area of the figure shows the result of retrieving WSDL
documents for the two service variants. The first service variant
29
has only one portType
and two operations. Note that the original customisable service has two portTypes and 11

29
CustomisationRequestResidentialExtra CoverAccidental DamageFusion
CoverExtended Third Party LiabilityPurchasePolicy QueryPolicy Update

Figure 6.11 - Management page for deployed service variants
135
operations. In contrast, the second service variant
30
has two portTypes and four opera-
tions. The service capabilities of two service variants follow exactly the feature mapping
description in the WSVL document. In other words, variability in the service skeleton is
properly resolved.
6.4.4.4 Runtime resolution of variability in the business logic
Both service variants in Figure 6.12 allow service consumers to get a quote for residential
policy (i.e. has the same operation getQuote4ResidentialWithExtra) but with different
extra covers. In particular, the first service variant supports only Accidental Damage
while the second service variant additionally supports Fusion Cover. Note that the
business logic of this operation requires the runtime resolution of variability using the
Web Service Context (cf. Figure 6.5). Therefore, we invoke the operation of the two
service variants with exactly the same policy details (cf. the top right area). The quotes
returned by the two service variants are shown on the bottom right and the bottom left
respectively. The increase in the quote from the first service variant to the second service
variant demonstrates that variability in the business logic is properly resolved at runtime.

30
CustomisationRequestResidentialExtra CoverAccidental Damage Fusion Cover
PurchaseCredit CardExtended Third Party LiabilityPolicy QueryPolicy Update

Figure 6.12 - Verifying service capability of service variants
Service
Variant 1
PortType
Operation
Service
Variant 2
PortType
Operation
Service request
Response by variant 1
Response by variant 2
136
6.5 Analysis of techniques for enabling customisable atomic
services against service variability characteristics
We analyse our techniques for supporting customisable atomic services against character-
istics of service variability identified in Chapter 2. In particular, the following
characteristics have been addressed (Figure 5.7):
Exposed variability: Exposed variability is defined as variability in the service
interface of customisable services (cf. section 2.2.1). For a customisable atomic
service, exposed variability is captured in its WSVL description. A WSVL de-
scription specifies both variability at the feature level and variability at the
service capability level as discussed in Chapter 4. This WSVL description can be
developed in either top-down or bottom-up ways owing to our JAX-WS exten-
sion. Specifically, the JAX-WS extension specifies the mapping between
variability in the WSVL description and variability in the service implementation
of a customisable atomic service. This mapping guarantees the consistency be-
tween exposed variability and composition variability (discussed below) in
capturing variability of customisable atomic services.
Composition variability: Composition variability is defined as variability in the
implementation of customisable services (cf. section 2.2.1). Our engineering

Variation
points and
variants
Intra-
dependencies
Architecture Implementation Composition
variability
Level
(Interface/
Implementation)
Service variability
Internal
Partner
variability
External
Automated Inter-
dependencies
Exposed
variability
Variability
communication
independence
Self-
describing
Staged
instantiation
Who
(Provider/
Consumer)
level
Requirement
Variability
constraints
Atomic service realisation
6.5 Analysis of techniques for enabling customisable atomic services against
137
techniques support the consideration of composition variability by extending the
JAX-WS standard. In particular, we have identified two types of such variability:
variability in the service skeleton and variability in the business logic. We define
a new JAX-WS annotation type and extend Web Service Context for addressing
these two types of variability respectively. These extensions enable the explicit
representation of composition variability and facilitate the automated derivation
of service variants.
Variability intra-dependencies: Variability intra-dependencies represent the re-
quire/exclude restrictions between software variants within a service (cf. section
2.2.3.2). In a similar way to capturing variability intra-dependencies for exposed
variability (cf. Chapter 4), we capture variability intra-dependencies for composi-
tion variability through the mapping between variability in the service
implementation and variability in the architecture and requirement levels. In par-
ticular, there is a one-to-one mapping between variability in the service skeleton
and variability in the architecture level (i.e. service interface level) as specified by
our FeatureMapping annotations. In addition, variability in the business logic is
also mapped to variability in the feature level through the extended use of Web
Service Context. Consequently, our solution enables the capturing of variability
intra-dependencies for composition variability.
Requirement, Architecture, and Implementation abstraction levels: Variability
of a customisable service is considered at all levels of abstraction: requirement,
architecture, and implementation. With respect to the requirement level, service
variability is captured by a feature model. With respect to the architecture level,
service variability is captured by a WSVL document. Lastly, service variability at
the implementation level has been discussed in the previous paragraph. With re-
spect to the refinement relationships among variability at different levels of
abstraction, the feature mapping description in the WSVL document captures the
mapping between variant features and variant service variabilities. The descrip-
tion represents the refinement relationships between variability at the requirement
level and the architecture level. Similarly, the JAX-WS extensions capture the
mapping between variant service capabilities and variability in the service im-
plementation. The extensions represent the refinement relationships between
variability at the architecture level and the implementation level. Therefore, our
approach comprehensively captures and supports variability in customisable ser-
vices.
138
Automated: In our approach, variability in both the service skeleton and the busi-
ness logic is identified and explicitly captured. Service implementation is
developed as configurable domain artefacts which support runtime variability
resolution by the runtime engine. Consequently, service variants are dynamically
derived according to runtime requests from service consumers.
Staged instantiation: The explicit mapping between variability in the service im-
plementation and variability in the feature model allows the runtime engine to
propagate variability resolution decisions at the feature level to resolve variability
at the implementation level. Consequently, our approach supports staged instanti-
ation and makes the customisation process less complex from service consumers
point of view.
Level (I nterface/Implementation): Runtime variability resolution is performed
against both variability in the service skeleton and variability in the business log-
ic. This resolution enables the variability instantiation at the implementation
level. In addition, due to the one-to-one mapping between variability in the ser-
vice skeleton and variability in the service interface description, this resolution
also enables the variability instantiation at the service interface level. The one-to-
one mapping guarantees not only the consistency in variability resolution at both
levels but also the correctness of the customisation contract. In particular, the ca-
pability of resulting service variants is exactly equivalent to what has been
promised in the service contract.
It should be noted that the concepts of Partner variability and Variability inter-
dependencies are not applicable to atomic services but composite services. We will
discuss these characteristics in the context of customisable composite services in the next
chapter.
6.6 Summary
In this chapter, we have proposed techniques for engineering customisable atomic
services which can be deployed on the service provisioning architecture and be exposed
by WSVL documents. Our techniques extend the JAX-WS standard which is a widely-
used technique for developing conventional Web services. The extension enables the
alignment between the development of customisable Web services and the development
of conventional Web services. We have implemented a prototype system of the service
provisioning architecture by extending the Apache CXF which is an open source Web
service framework, as well as developing and deploying the Swinsure Insurance Web
6.6 Summary
139
service in the prototype system. The prototype system and the example Web service have
been successfully deployed on the Amazon cloud and enable us to evaluate various
aspects of our proposed techniques. Lastly, we have analysed our solution in the context
of service variability characteristics that we identified in Chapter 2. The analysis demon-
strates that our solution delivers necessary characteristics for enabling customisable
atomic services. While the focus of this chapter is on customisable atomic services, we
discuss issues specific to customisable composite services in the next chapter.

141

7. Composing Customisable Composite Services
Last chapter, we have described techniques for developing customisable atomic services
which can be deployed on our service provisioning architecture. This chapter discusses
such techniques in the case of customisable composite services. To recap, the service
provisioning architecture comprises of a number of components for performing different
functions related to service customisation. The functionalities and operations of generic
components have been discussed in Chapter 5. To support customisable composite
services, the following techniques for the component Configurable service implementa-
tion are required: i) how to develop the configurable service implementation and ii) how
to dynamically resolve variability in the configurable service implementation to produce
service variants. This chapter proposes such techniques to realise customisable composite
services (Figure 7.1).
Section 7.1 discusses our research scope as well as requirements in supporting cus-
tomisable composite services. We explain why this research focuses on supporting the
modeling and the instantiation of variability in BPMN process models. In addition, we
elaborate two requirements that drive our extension of BPMN: i) modeling three types of
service variability (i.e. exposed variability, composition variability, and partner variabil-
ity), and ii) capturing variability inter-dependencies between a customisable composite
service and its customisable partner services.
Section 7.2 presents a motivating example of an insurance claim handing process. In
addition, we provide examples of variability inter-dependencies between the claim
handling process and one of its partner services. Section 7.3 examines the implications of
capturing variability inter-dependencies with respect to runtime variability resolution, as
well as benefits of modeling such dependencies.

Customisation
framework
Atomic service
realisation
I
m
p
l
e
m
e
n
t
a
t
i
o
n
I
n
t
e
r
f
a
c
e
language
Composite service
realisation
5
This chapter
Chapter 7 - Composing Customisable Composite Services
142
Section 7.4 discusses VBPMN (Variability-enabled BPMN) which is our extension
of BPMN for introducing variation points and variants related to all three aspects of
service compositions: control flow, data flow, and message flow. In addition, we describe
model-driven techniques for capturing both variability intra-dependencies and variability
inter-dependencies.
Section 7.5 describes the development and the resolution of variability in process-
based service compositions. In particular, we discuss a process development methodology
which enables the systematic reuse of service variability provided by partner services. In
addition, we explain how to derive a WSVL description for a customisable composite
service. Such description facilitates service consumers in consuming composite services
(e.g. requesting the customisation of composite services). We also describe how variabil-
ity in composite services is dynamically resolved to produce executable process variants
given a feature configuration.
Section 7.6 discusses the conformity and the applicability of our approach. In addi-
tion, we present a prototype system for modeling and managing variability in process-
based service compositions. We will describe different components of the prototype
system, the underlying metamodels for their implementation and explain how they are
used to support the motivating example. The successful application of the prototype
system to support the claim handling process demonstrates the feasibility of our tech-
niques for composing customisable composite services.
In a similar fashion to previous chapters, section 7.7 discusses characteristics of ser-
vice variability that have been addressed in this chapter. We then summarise the chapter
in section 7.8.
7.1 Research scope and requirements in supporting customisable
composite services
7.1.1 Research scope
To develop the configurable service implementation of composite services, it is essential
that variability is explicitly modeled and managed. In a similar fashion to customisable
atomic services, we follow the SPL paradigm for engineering customisable composite
services. As such, service variability is captured at the requirement level by a feature
model. Variability at the requirement level is further refined to variability at the architec-
ture level and the implementation level for facilitating the implementation of services.
Since feature models have been discussed in previous chapters, this chapter considers
variability at the architecture level and the implementation level of composite services.
7.1 Research scope and requirements in supporting customisable composite
services
143
While there are different ways for composing services (e.g. Hans Weigand 2008;
Nancy 2008), we focus on process-based service composition techniques in this thesis
due to their widespread adoption and support. In particular, we assume the use of BPMN
(OMG 2011a) at the architecture level and the use of BPEL (Jordan 2007) at the imple-
mentation level. BPMN enables the modeling of the architecture of a service composition
as a business process model (or process model in short), while BPEL facilitates the
specification of service implementation as a business process definition (or process
definition in short).
In addition to the definition of modeling constructs, BPMN specification also defines
the mapping between BPMN constructs and BPEL elements (OMG 2011b). When a
BPMN process model is fully specified (i.e. contains full description of control flow, data
flow, and message flow), this mapping enables the automated generation of a BPEL
process definition from the BPMN process model. In our approach, we exploit this
capability to free ourselves from considering variability at both the architecture and the
implementation level. Instead, we only focus on variability at the architecture level (i.e.
in BPMN models). Variability resolution at this level results in a variant process model
which will be automatically transformed to a variant process definition to be executed in
a process engine. While this approach helps to reduce the overhead of considering
variability at the implementation level, the challenge is that all variability at the architec-
ture level needs to be considered. We are going to achieve this by considering variability
in all three aspects of a process model: control flow, data flow, and message flow.
7.1.2 Requirements
There are two requirements with respect to the modeling and instantiation of variability in
customisable composite services. Firstly, it is essential to model all three types of service
variability (i.e. exposed variability, composition variability, partner variability). Second-
ly, variability inter-dependencies between a composite service and its customisable
partner services need to be considered and addressed.
As discussed in Chapter 2, exposed variability and partner variability represent vari-
abilities at the service interface level of a customisable composite service and its
customisable partner services respectively. In our research, these are captured by WSVL
descriptions of the composite service and partner services. In contrast, composition
variability refers to variability in BPMN models of the composite service. The first
requirement states that the modeling and instantiation of variability within BPMN models
need to align with WSVL in the interactions with both service consumers and customisa-
144
ble partner services. Such alignment brings about several benefits. Firstly, service
consumers are able to customise composite services in the same way as customising
atomic services (through the use of WSVL). As discussed in Chapter 4, this implies loose
coupling between service consumers and service providers since WSVL provides an
appropriate abstract description of customisable services. Secondly, WSVL is recursively
used to enable variability modeling and instantiation. WSVL descriptions of customisable
partner services contribute to the modeling and instantiation of variability in a customisa-
ble composite service. This composite service in turn exhibits its variability to other
service compositions through WSVL. The recursive use of WSVL for capturing service
variability enables recursive service customisation when variability inter-dependencies
(discussed in the next paragraph) are properly captured.
With respect to the second requirement, we identified in Chapter 2 that a major
shortcoming of related works in supporting customisable composite services is that
variability inter-dependencies are not considered. Variability dependencies represent
require/exclude restrictions when binding variants. There are two types of variability
dependencies: variability intra-dependencies and variability inter-dependencies. The
former captures variability dependencies within a customisable composite service, while
the latter captures variability dependencies between a customisable composite service and
customisable partner services. Related works assume that partner services are not cus-
tomisable and do not exhibit variability. Consequently, they consider only variability
intra-dependencies and are not able to address the situation when a customisable compo-
site service is composed from customisable partner services.
7.2 The Swinsure claim handling process and variability inter-
dependencies
7.2.1 Swinsure claim handling process
To demonstrate the concept and techniques for supporting customisable composite
services, we consider another Web service provided by the Swinsure Insurance. This Web
service, called Swinsure claim handling process
31
, allows end-users to make insurance

31
This motivating example was developed based on real-world insurance claim handling processes
from a number of insurance providers in Australia: AAMI (http://www.aami.com.au/home-
insurance/policy-documents), RACV (http://www.racv.com.au/wps/wcm/connect/Internet/Pri-
mary/insurance/home+insurance/buildings), and Allianz (http://www.allianz.com.au/home-
insurance/products/)
7.2 The Swinsure claim handling process and variability inter-dependencies
145
claims when their residential properties are damaged. Again, the Swinsure Insurance sells
its insurance business indirectly through insurance brokers and these insurance brokers
are able to customise the Web service to suit their requirements. In addition, the Web
service is a composite service which is realised internally as a business process. That is,
the Swinsure claim handling process is a customisable process-based service composition
and each broker will customise and use one process variant.
Figure 7.2 presents the feature model capturing variability in broker requirements
supported by the Swinsure claim handling process. The variability is explained below:
With respect to types of insurance cover (i.e. feature Cover type), all brokers
support repairing (i.e. mandatory feature Repair) while only some brokers also
support rebuilding the damaged property (i.e. optional feature Rebuild). For
repairing the property, brokers might choose to specify a repairer (i.e. feature
Broker specified) or allow end-users to nominate a repairer (i.e. feature End-
user specified).
With regard to the entity who pays bills to repairers (i.e. feature Bill payer),
some brokers wish to be responsible for the payment (i.e. feature Broker)
while others allow end-users to do the payment temporarily and reimburse the
cost (i.e. feature End-user). However, when brokers specify repairers, end-

Figure 7.2 - Swinsure claim handling process
[1-1]
Swinsure claim handling process
Excess
Unoccupied excess
[1-1]
Cover type
[1-1]
Constraints
Broker specified excludes End-user , Deducted requires End-user
[1-1]
Pay in advance
Credit card BPAY
[1-1] [0-1]
[1-1]
Deducted
Bank transfer
Extra cover
[0-1]
Repair
End-user specified Broker specified
Rebuild
End-user Broker
[1-1]
[1-1]
Bill payer
Temporary accommodation
[0-1] [0-1] [1-1]
Payment time
146
users are not allowed to pay bills (cf. first constraint in the constraint box).
Brokers are able to add an extra cover (i.e. optional feature Temporary accom-
modation) for arranging a temporary property while the insured one is being
repaired.
Relating to the excess fee for each insurance claim (i.e. feature Excess), since
an insured property is at greater risk of damage if it is not occupied for a lengthy
period, some brokers want to enforce an additional unoccupied excess (i.e. fea-
ture Unoccupied excess).
For payment time of excess fee (i.e. feature Payment time), some brokers ask
end-users to pay the fee in advance (i.e. feature Pay in advance) which might
be through the use of credit card, BPAY (i.e. a bill payment service in Australia)
or bank transfer. In contrast, others allow the deduction of the fee from bills paid
by end-users (feature Deducted). However, this deduction option is only avail-
able if end-users pay bills (i.e. feature End-user) (cf. second constraint in the
constraint box)
7.2.2 Swinpay Web service and variability inter-dependencies
7.2.2.1 Swinpay Web service
There are many services available that the Swinsure Insurance may reuse in implement-
ing its process. In this example, the Swinsure Insurance utilises a customisable partner
service, called Swinpay Web service, for dealing with end-user payments. Figure 7.3

Figure 7.3 - Swinpay feature model
Constraints
Execution requires User notification
Payment type
Execution
Credit card
[1-1]
BPAY Bank transfer
[1-1]
[1-1]
Confirmation
Cheque
User notification
Swinpay Web Service
[0-1] [1-1]
7.2 The Swinsure claim handling process and variability inter-dependencies
147
presents the feature model capturing variability of the Swinpay Web service. In particu-
lar, the Swinpay Web service supports four alternative payment types. Service consumers
are able to use the Swinpay Web service to confirm payment transactions for bank
transfer or BPAY. Alternatively, service consumers can rely on the Swinpay Web service
to execute payment transactions through credit card or bank cheque. In any case, service
consumers can optionally ask for notification of transaction completion from the Swinpay
Web service. However, this feature is required for all payment execution (cf. the con-
straint box).
The Swinpay Web service is described by its WSVL description (Figure 7.4). To fa-
cilitate the readability, we only show a part of the descriptions of service capability and
feature mapping while omitting the detail of the descriptions of customisation options and
customisation endpoint. The example demonstrates two variant service capabilities: the
operations confirmBankPayment and confirmBankPaymentWithNotification. The
former operation is available when feature Bank transfer is selected and feature User
notification is disabled. This is specified by the first two links. In contrast, the next two
links specify that the latter operation is available when those two features are selected.
Table 7.1 presents all variant service capabilities and their presence conditions speci-
fied as propositional formulas for the Swinpay Web service.

Figure 7.4 - Swinpay WSVL
<wsdl:definition name=Swinpay>
<wsdl:portType name="swinpayPortType">
<wsdl:operation name="confirmBankPayment/>
<wsdl:operation name="confirmBankPaymentWithNotification/>
</wsdl:portType>
<wsvl:mappingInfo >
<wsvl:link name="BankTransfer1">
<wsvl:featureRef ref="fd:BankTransfer" presence="true"/>
<wsvl:serviceElementRef ref="tns:confirmBankPayment" target="operation"/>
</wsvl:link>
<wsvl:featureRef ref="fd:UserNotification" presence=false"/>
<wsvl:serviceElementRef ref="tns:confirmBankPayment" target="operation"/>
</wsvl:link>
<wsvl:link name="BankTransferWithNotification1">
<wsvl:serviceElementRef ref="tns:confirmBankPaymentWithNotification" target="operation"/>
</wsvl:link>
<wsvl:link name="BankTransferWithNotification2">
<wsvl:featureRef ref="fd:UserNotification" presence="true"/>
<wsvl:serviceElementRef ref="tns:confirmBankPaymentWithNotification" target="operation"/>
</wsvl:link>
</wsvl:mappingInfo>
</wsdl:definition>
Service
Capability
Feature
Mapping
148
7.2.2.2 Variability inter-dependencies
To implement variability in its own process (i.e. realising different options for Pay in
advance), the Swinsure Insurance uses three different service variants from the Swinpay
Web service. Two service variants provide services for confirming payment transactions
made by bank transfer or BPAY without notifying end-users about the transactions. These
two service variants provide the operations confirmBankPayment() and confirmBPAY-
Payment() respectively (cf. Table 7.1). The third service variant executes payment
transactions using Credit card and notifies end-users. This service variant provides two
operations executeCreditCardPayment() and notifyPaymentResult(). Reusing service
variability provided by the Swinpay Web service frees the Swinsure Insurance from the
overhead of implementing variability in its own process. Instead, Swinsure Insurance
delegates (or outsources) a specific part of its variability (i.e. performing payment
transaction) to this partner service. However, variability in the claim handling process
will depend on the variability in the Swinpay Web service. In this case, depending on the
type of payment a broker prefers for its own process variant, Swinsure Insurance needs to
invoke an appropriate service variant of the Swinpay Web service in that process variant.
7.3 Benefits of modeling variability inter-dependencies
In this section, we discuss the importance and benefits of capturing variability inter-
dependencies. We start with the overview of how variability inter-dependencies work and
then describe the benefits of considering variability inter-dependencies.
Table 7.1 - Variant service capabilities and presence conditions for Swinpay Web service
Presence condition
Variant service capabilities
(service operation)
BankTransfer && !UserNotification confirmBankPayment()
BankTransfer && UserNotification confirmBankPaymentWithNotification()
BPAY && !UserNotification confirmBPAYPayment()
BPAY && UserNotification confirmBPAYPaymentWithNotification()
CreditCard executeCreditCardPayment()
Cheque executeChequePayment()
UserNotification notifyPaymentResult()

7.3 Benefits of modeling variability inter-dependencies
149
7.3.1 Variability inter-dependencies and runtime variability resolution
Figure 7.5 presents two alternative approaches for modeling and instantiating variability
in a customisable composite service with respect to variability inter-dependencies. The
approach on the left does not consider variability inter-dependencies, while the approach
on the right explicitly captures and manages variability inter-dependencies. To simplify
the explanation without losing generality, we assume that the composite has three
variants, called Process variant 1-3, which respectively consume three variants of the
partner service, called Partner variant 1-3. The top row entitled Software artefact
demonstrates this situation. All variants (i.e. process variants and partner variants) are
represented with dashed lines to imply that these variants are not instantiated yet. In
contrast, variants represented with solid lines indicate ones after variability resolution.
When variability inter-dependencies are not considered, the composite service pro-
vider customises the partner service at design time
32
to derive three partner variants.
These partner variants are instantiated at design time. The composite service provider

32
In this section, the concepts of design time, runtime are considered in the context of the
composite service provider. The partner service is already up, running and ready to be customised.

Figure 7.5 - Variability inter-dependencies
Partner variant 1
Partner variant 2
Partner variant 3
Process variant 2
Partner variant 2 Process variant 2
Process variant 3
Process variant 1
Partner variant 1
Process variant 1
Partner variant 1
Partner variant 2
Partner variant 3
Process variant 2
Process variant 3
Process variant 1
Partner variant 1
Process variant 1
R
u
n
t
i
m
e
D
e
s
i
g
n

t
i
m
e
S
o
f
t
w
a
r
e

a
r
t
e
f
a
c
t
No variability inter-dependencies Variability inter-dependencies
Composite Partner Composite Partner
Partner
customisation
Service
customisation
Partner
customisation
Service
customisation
Static binding
Dynamic binding
150
then models the variability within its business process with respect to these three partner
variants. However, these partner variants are considered as independent partner services
from the composite service providers perspective. The solid lines representing the
binding between process variants and partner variants imply static binding (i.e. binding to
a concrete service). At runtime, when the business process of the composite service
provider is customised (i.e. its variability is resolved), the resulting process variant will be
integrated with the corresponding partner variant. Note that all partner variants are
already up and running from the design phase regardless of whether it is actually used by
a process variant or not. For No variability inter-dependencies approach, the service
customisation (of the composite service) is performed at runtime while the partner
customisation is performed at design time.
In contrast, the approach which explicitly models and manages variability inter-
dependencies does not perform partner customisation at design time. In this case, the
composite service provider models the variability within its business process with respect
to variability exposed by the partner service. In particular, the composite service provider
captures dependencies between its variability and partner variability. The binding
between process variants and partner variants is dynamic binding and is represented by
dotted lines. At the runtime, when the business process is customised, the partner service
is customised accordingly based on the captured variability inter-dependencies. The
resulting process variant will be integrated with the dynamically derived partner variant.
The binding type changes from dynamic to static at runtime. For Variability inter-
dependencies approach, both the service customisation and the partner customisation are
performed at runtime. The service customisation triggers the partner customisation to
derive the exact partner variant that the composite service provider requires.
7.3.2 Benefits of modeling variability inter-dependencies
From software developers perspective, the No variability inter-dependencies approach
might have less overhead compared to the Variability inter-dependencies approach.
This is because all partner variants are treated as usual partner services and software
developers do not have to consider variability inter-dependencies with respect to partner
services. However, the Variability inter-dependencies approach has a number of
benefits when taking into account runtime execution and operation costs:
Dynamic binding (or late binding) results in efficient resource usage: The bind-
ing between process variants and partner variants in the No variability inter-
dependencies approach remains static from the design phase. All partner vari-
7.4 Variability-enabled BPMN (VBPMN)
151
ants are already instantiated regardless of whether they are required by consumers
of the composite service provider or not. In contrast, in the Variability inter-
dependencies approach binding decisions are delayed to runtime. Consequently,
this approach makes efficient use of resources since only partner variants which
are required by service consumers are instantiated. This benefit becomes more
significant when considering the dynamism of SOA and the needs of on-demand
service provisioning from emerging paradigms like SaaS ( Software-as-a-Service)
(van der Aalst 2011).
Dynamic binding enables recursive service customisation: In the Variability
inter-dependencies approach, the customisation of a composite service triggers
the customisation of partner services at runtime. As service composition is recur-
sive, the customisation of partner services might further enact the customisation
of their partner services, and so on. The Variability inter-dependencies ap-
proach facilitates the chaining of service customisation to support the recursive
nature of service composition.
Explicit capturing of variability inter-dependencies facilitates efficient variabil-
ity modeling: In the No variability inter-dependencies approach, variability of
partner services is disregarded and variability inter-dependencies are implicitly
captured through the relation between the composite service and instantiated
partner variants. As a principle in SPL, to efficiently address variability in soft-
ware systems, variability needs to be explicitly captured and managed (Pohl
2005). Therefore, software developers need to be aware of variability of partner
services and variability inter-dependencies with respect to those services. To this
end, it is essential to model and manage variability inter-dependencies.
In this section, we describe our approach for modeling variability in BPMN models
(Nguyen 2011c). As discussed in Chapter 2, two key concerns in variability modeling are
variability representation (i.e. introduction of variation points and variants into domain
artefacts) and dependency description (i.e. capturing dependencies among those variants).
Therefore, the first subsection 7.4.1 describes VBPMN (Variability-enabled BPMN)
metamodel which is our extension of BPMN 2.0 metamodel for representing variation
points and variants within process models. Subsection 7.4.2 and 7.4.3 discuss the mod-
eling of variability intra-dependencies and variability inter-dependencies respectively.
152
7.4.1 Extending BPMN for representing variation points and variants
Figure 7.6 presents the variability metamodel which captures the general concepts of
variability in process models. A VariationPoint represents any place in a process model
where variability can occur. Each VariationPoint is associated with a set of Variants from
which one or several will be bound to the VariationPoint when variability is resolved.
The attributes minCardinality and maxCardinality define how many Variants should be
bound to one VariationPoint. These attributes have the same semantics as the cardinality
concept in the feature modeling technique adopted.
Note that in the variability metamodel, we do not specify when a variant is bound to
the variation point. In our approach, such conditions (aka. presence condition) are
managed in separate models capturing the mapping between variability at the feature
level and variability at the process modeling level (detailed in sections 7.4.2 and 7.4.3).
In the following sub-sections, we explain the specialisation of this metamodel to rep-
resent variability in control flow, data flow, and message flow respectively.
7.4.1.1 Modeling variability in control flow
Figure 7.7 presents our metamodel extension for modeling variability in control flow. In
this metamodel, BPMN elements are written in italic bold font, while extended elements
are written in regular bold font. We also use this convention when describing BPMN
elements and extended elements throughout this chapter.
In BPMN, a control flow (represented by element Process) is a FlowElementsCon-
tainer which is composed of FlowElement. A FlowElement can be either a FlowNodeor
a SequenceFlow connecting two FlowNodes. There are three types of FlowNode in
BPMN: Activity, Gateway, and Event. An Activity can be further specialised to a Task or
a Sub-Process. While a Task represents an atomic activity, a Sub-Process denotes a
composite activity typed FlowElementsContainer. That is, a Sub-Process is also mod-
eled using Activities, Gateways, Events and SequenceFlows like a Process.

Figure 7.6 - Variability metamodel
153
To model variability in control flow, we need to consider how to represent control
flow variation points and control flow variants. To this end, we observe that variability in
control flow can be interpreted as a location in the process model at which different
process fragments can be used. Therefore, we define two new elements, namely Con-
trolFlowVPStart and ControlFlowVPEnd, as a pair for representing the starting point
and the ending point of a control flow variation point. Both elements inherit FlowNode
(through ControlFlowVariant) so that they can be used within a BPMN model as a
FlowNode. A control flow variant might be a FlowNode, or a process fragment which
begins and ends with FlowNodes. Therefore, we make all existing FlowNodes (i.e.
Activity, Gateway, Event) inherit ControlFlowVariant so that those elements can be
used as control flow variants. Note that control flow variation points (i.e. ControlFlow-
VPStart and ControlFlowVPEnd) and control flow variants (i.e. ControlFlowVariant)
are respectively specialised from the general variability elements VariationPoint and
Variant represented in Figure 7.6. This means that the relation between control flow
variation points and control flow variants conforms to the general relation between
variation points and variants.
Example 7.1 presents a fragment of the main claim handling process which is creat-
ed in our process modeling tool (detailed in section 7.6). The process fragment
demonstrates how our extended elements are used together with BPMN elements to
model variability in control flow. VPS1 and VPE1 are ControlFlowVPStart and Con-
trolFlowVPEnd respectively. They represent a control flow variation point which has

Figure 7.7 - Metamodel extension for modeling variability in control flow
154
two variants. In our process modeling tool, dashed lines are used to connect Variation-
Points to Variants. By this, the first control flow variant is the sub-process rebuild,
while the second control flow variant is the task Notify payment. The first variant is
selected when a broker selects feature Rebuild, while the second variant is used when
feature Rebuild is disabled. In the diagram, we use annotation to denote this infor-
mation. However, this is not the way we manage the correspondence between variant
features and control flow variants. This management is described in section 7.4.2.
Another consideration is related to the modeling situation when one control flow
variation point is nested within another. In this regard, it is required that we are able to
use the elements ControlFlowVPStart and ControlFlowVPEnd as control flow vari-
ants. To this end, we make these two elements inherit ControlFlowVariant in the
metamodel extension (cf. Figure 7.7). Example 7.2 demonstrates nesting control flow
variability. The control flow variation points VPS6 and VPE6 have two control flow
variants. While one control flow variant is the task Collect and audit bills from repair-
er, another control flow variant is one process fragment consisting of the task Collect
and audit bills from customers and control flow variation points VPS7 and VPE7. This is
an optional control flow variation point and the control flow variant is only present when
the feature Deducted is selected. Note that the nesting of control flow variability is
only possible due to the specialisation relationship between ControlFlowVPStart,
ControlFlowVPEnd and ControlFlowVariant in our metamodel. The specialisation
relationship enables control flow variation points to play the role of both variation point
and variant.
Example 7.1 - Variability in control flow (a fragment of the main claim handling process)

Task Gateway Sub-process Event
SequenceFlow ControlFlowVPStart ControlFlowVariant
ControlFlowVPEnd
155

7.4.1.2 Modeling variability in data flow
Figure 7.8 presents our metamodel extension for modeling variability in data flow. Data
flow in BPMN is concerned with the modeling of information items that are created,
manipulated, and consumed during the execution of a process. In general, it refers to the
use of the element DataObject for storing data and the element DataAssociation for
moving data from one or many source elements I temElement to one target element
I temElement. This element I temElement is inherited by both the element DataObject
and the element Activity. In this way, data can be instantiated and moved between
Example 7.2 - Nesting control flow variability (a fragment of the sub-process for calculating
repairing cost)

variation point
wrt this variability
variant wrt
this variability

Figure 7.8 - Metamodel extension for modeling variability in data flow
156
different Activities (i.e. Task, SubProcess), between different DataObjects, or between
Activities and DataObjects.
Variability in data flow can be considered as different information (i.e. DataObject)
to be stored or different ways for moving data around (i.e. DataAssociation). In addition,
variants in data flow are usually alternatives. Therefore, we model both data flow varia-
tion points and data flow variants as elements inherited from the same element type. That
is, for variability of DataObject, we define both variation points, i.e. DataObjectVP, and
variants, i.e. DataObjectVariant, as elements inherited from DataObject. A similar
approach applies to DataAssociation, DataAssociationVP, and DataAssociationVari-
ant.
Example 7.3 presents an example of modeling variability in data flow. It specifies
that there is variability in the data flow between the two activities, Get end-user payment
detail and Confirm payment. In addition, the process fragment demonstrates the
abstract view of variability in data flow where only data flow variation points are
captured. In contrast, Example 7.4 presents the expanded view and the detailed view of
variability. The expanded view models data flow variants, while the detailed view
Example 7.3 - Variability in data flow (abstract view) (a fragment of the sub-process for
collecting excess fee from end-users)

DataObjectVP
DataAssociationVP
Example 7.4 - Variability in data flow (expanded and detailed views)

DataObjectVariant
DataAssociationVariant
Expanded view Detailed view
157
captures both data flow variation points and data flow variants. In our process modeling
tool, the use of these three views is applicable to not only variability in data flow, but also
variability in control flow and message flow. These different views help to improve
readability of a process model when a particular variability is not the main focus. This is
similar to the use of sub-processes in BPMN.
Example 7.5 illustrates an optional data flow variant which represents data depend-
ency between an optional control flow variant (i.e. sub-process Calculate occupied
excess) and the task Calculate excess. For optional data flow variant, it is not neces-
sary to use data flow variation points so that the process model can be simplified. The
example also demonstrates how variability in data flow can be modeled together with
variability in control flow. Note that, both the optional control flow variant and optional
data flow variant must be included or excluded together to have a valid process model.
We will discuss this dependency in sections 7.4.2.
7.4.1.3 Modeling variability in message flow
Figure 7.9 presents the metamodel extension for modeling variability in message flow. In
BPMN, message flow is used to capture interactions between a process and partner
services/consumers. Each interaction is modeled as a Conversation which is composed of
either one or two MessageFlows depending on whether the interaction is one- or two-
way. Each MessageFlow carries a Message from one I nteractionNode to another
I nteractionNode. An I nteractionNodemight be a Task performed by either the process
or partner services/consumers.
Variability in message flow can be seen as alternative Conversations between two
parties, i.e. a business process and a partner service (or consumers). Therefore, in a
similar fashion to modeling variability in data flow, we model both variation points, i.e.
Example 7.5 - Optional data flow variant (a fragment of the sub-process for collecting excess
fee from end-users)

158
ConversationVP, and variants, i.e. ConversationVariant, as elements inherited from
Conversation. In addition, we introduce new elements called ConsumerTask and
AbstractConsumerTask to facilitate the modeling of message flow between a business
process and consumers. A ConsumerTask models a task performed by service consum-
ers. It defines a service operation which will be contained in the service interface
description of this business process. A ConsumerTask represents either a common
capability (i.e. a service operation which is common to all process variants) or variant
capability (i.e. a service operation which is only available in a number of process vari-
ants). This is analogous to the concept of common and variant service capability in
WSVL. An AbstractConsumerTask is a variation point associated with a set of alterna-
tive ConsumerTasks. An AbstractConsumerTask represents a set of alternative variant
capabilities provided by a business process. The use of ConsumerTask and Ab-
stractConsumerTask facilitate the generation of the service variability description (i.e.
WSVL description) for this service composition as described later in section 7.5.2
Example 7.6 is an example of modeling ConsumerTasks. It shows a Conversa-
tionVP, namely CVP2, which associates three ConversationVariants, namely CV2_1,
CV2_2, CV2_3 respectively. Each CoversationVariant represents an interaction between
the same task Get end-user payment detail with a ConsumerTask. These alternative
ConsumerTasks correspond to three alternative features (Bank transfer, BPAY and
Credit Card) and collectively describe variability in message flow between the process
and service consumers. In other words, depending on the selected feature, the composite

Figure 7.9 - Metamodel extension for modeling variability in message flow
159
service will interact with service consumers through a particular ConsumerTask with the
corresponding ConversationVariant and Message.
Similar to ConsumerTask and AbstractConsumerTask, we also introduce new el-
ements, called PartnerTask and AbstractPartnerTask, to facilitate the modeling of
message flow between a process and partner services. A PartnerTask models a task
performed by a partner service. An AbstractPartnerTask is a variation point associated
with a set of alternative PartnerTasks from the same partner service. AbstractPart-
nerTask represents a variable capability provided by a partner service. The introduction
of PartnerTask and AbstractPartnerTask facilitates the modeling of variability inter-
dependencies as described later in section 7.4.3.
Example 7.7 shows an example of modeling PartnerTasks. It defines one Conver-
sationVP, called CVP3, which associates the task Confirm payment with three
alternative PartnerTasks. Each PartnerTask represents one type of payment (Bank
transfer, BPAY or Credit Card) and is performed by one service variant of the
Swinpay Web service as discussed in section 7.2.2. This variation point captures variabil-
ity in message flow between the process and the partner service Swinpay Web service.
Note that software modelers are also able to use different views (i.e. abstract, expanded,
and detailed view) to model variability in message flow.
Example 7.6 - ConsumerTasks and variability in message flow (a fragment of the sub-
process for collecting excess fee from end-users)

ConversationVP
AbstractConsumerTask ConsumerTask
MessageFlow
ConversationVariant
Message
160
7.4.2 Modeling variability intra-dependencies
Variability intra-dependencies represent dependencies among variants within a process
model. Those variants might be associated with the same variation points or different
variation points. In the former case, the selection of one variant might exclude the
selection of other variants with respect to the same variation point. This is dependent on
the properties minCardinality and maxCardinality associated with the variation point (cf.
Figure 7.6). For instance, with respect to the control flow variation points VPS1 and
VPE1 in Example 7.1, when the first control flow variant (i.e. the sub-process rebuild)
is selected for one process variant, the second control flow variant (i.e. the task Notify
payment) should be excluded. In the latter case, the selection of a variant at one varia-
tion point might require/exclude the selection of variants at other variation points. For
instance, in Example 7.5, when the sub-process Calculate unoccupied excess is not
included in one process variant, the data object variant unoccupied excess should also
be excluded.
The modeling of these variability intra-dependencies is similar to the modeling of
variability intra-dependencies in the service interface description (cf. Chapter 4) or in the
service implementation of customisable atomic services (cf. Chapter 6). That is, the
identification and modeling of variation points and variants in a process model are driven
Example 7.7 - PartnerTask and variability in message flow (a fragment of the sub-process
for collecting excess fee from end-users)

AbstractPartnerTask
PartnerTask
161
by variant features in the feature model. All variabilities in the process model are the
refinement of variability in the feature model of the service composition. And variability
intra-dependencies among different variants exist due to constraints among variant
features.
Therefore, each variant within the process model is also associated with a set of se-
lected features and a set of disabled features. These features collectively signify the
presence of the variant within a process variant with respect to a feature configuration.
And we also exploit the model mapping technique to capture the correspondence between
variability in a feature model and variability in a process model. Figure 7.10 shows the
mapping metamodel for this purpose. This mapping metamodel is similar to the feature
mapping metamodel described in Chapter 4. A MappingModel relates variant features in
a feature model, referenced by FeatureModelRef, with variants in a process model,
referenced by ProcessModelRef. It is composed of Links and each Link consists of a
Feature and at least one ProcessElement. Feature and ProcessElement reference
elements in the feature model and the process model respectively. In addition, a Feature
has a boolean property presence to define whether the selection or un-selection of the
Featureis associated with a ProcessElement. Each Link enables a feature to be mapped
to one or several variant process elements in the process model. In addition, by defining
multiple links associating multiple features with the same process element, we are able to
specify the presence condition of the process element as a propositional formula of
variant features.
Figure 7.11 depicts a mapping model capturing variability intra-dependencies within
the sub-process for collecting excess fee. This is a screenshot of our model mapping tool.

Figure 7.10 - Mapping metamodel for variability intra-dependencies
162
The left panel shows the feature model, while the process model with variability is
presented on the right panel and the middle panel presents the mapping model. There are
four links in this mapping model. The first link associates feature Unoccupied excess
with two variants (one control flow variant and one data object variant) shown in Exam-
ple 7.5. As the result, the link captures the require dependency between the two
variants. In addition, the other three links of the mapping model associate each alternative
child feature of the feature group Pay in advance with one PartnerTask. Consequent-
ly, the links represent mutually exclusive dependencies among the three PartnerTasks.
This mapping model represents refinement relationships between variability at the
feature level and variability at the architecture level. We call this mapping model a
FeatureTask mapping model to differentiate it from other mapping models introduced
later in this chapter.
7.4.3 Modeling variability inter-dependencies
Variability inter-dependencies represent dependencies between variability in the process
model and variability in partner services. For instance, in Example 7.7, each Part-
nerTask associated with the AbstractPartnerTask Payment service is performed by
one service variant of the Swinpay Web service. Since the variability of partner services
is described by their feature models, in a similar fashion to modeling variability intra-
dependencies, we exploit the model mapping technique to model variability inter-
dependencies. In particular, we use a mapping model to capture the correspondence
between variants within the process model (i.e. PartnerTasks) and variant features of
partner services (aka. partner variant features). We refer to this mapping model as
PartnerTaskFeature mapping model.

Figure 7.11 - Capturing variability intra-dependencies
163

Figure 7.12 presents the mapping metamodel for capturing variability inter-
dependencies. This mapping metamodel is similar to the mapping metamodel shown in
Figure 7.10. Figure 7.13 presents an example of this mapping model in which the Part-
nerTask Bank payment confirmation in Example 7.7 is mapped to two partner features
of the Swinpay Web service using two links. The first link refers to the partner feature
Bank transfer with presence=true, while the second link refers to the partner feature
User notification with presence=false (shown in the Properties view at the bottom
of the figure). Consequently, this PartnerTask is performed by the variant of the
Swinpay Web service for which the partner feature Bank transfer is selected and the
partner feature User notification is disabled. Comparing to the WSVL description of
Swinpay Web service in Figure 7.4, it means that the PartnerTask Bank payment

Figure 7.13 - Capturing variability inter-dependencies

Figure 7.12 - Mapping metamodel for variability inter-dependencies
164
confirmation is equivalent to the operation confirmBankPayment provided by the
Swinpay Web service.
While mapping models are used to capture both variability intra-dependencies and
variability inter-dependencies, the main difference between these two mapping models
comes from the origin of variant features. In particular, variability intra-dependencies are
modeled with respect to variant features in the feature model of the service composition
(cf. Figure 7.10). In contrast, variability inter-dependencies are modeled with respect to
variant partner features (cf. Figure 7.12).
Note that the positions of the feature model and the process model are swapped in
the mapping tool for variability inter-dependencies (cf. Figure 7.13) compared to the one
for variability intra-dependencies (cf. Figure 7.11). This swapping reflects the difference
in the origin of features as discussed above. In addition, when reading from the left to the
right, one is able to recognise the refinement relationships (i.e. variability at the feature
level is further refined to variability at the process model level) in the mapping tool for
variability intra-dependencies. Similarly, when reading from the left to the right in the
mapping tool for variability inter-dependencies, one is able to see the common arrange-
ment between a service composition and a partner service.
It should be noted that between PartnerTasks and variant partner features, there
does not exist a natural refinement relationship as the ones for variability intra-
dependencies. If the identification and modeling of PartnerTasks and AbstractPart-
nerTasks are driven by the variant partner features, such refinement relationships exist.
Otherwise, refinement relationships may not exist and variability inter-dependencies exist
by chance. Therefore, the higher the inter-dependency between a composition and partner
services is, the better the reuse of service variability from partner services toward the
composition will be. In section 7.5.1, we describe a process development methodology
that systematically increases the reusability of service variability.
7.5 Developing and resolving variability in process-based service
compositions
In this section, we describe a methodology for developing service compositions with
systematic management and reuse of variability (Nguyen 2011c). The methodology
explicitly utilizes variability information from partner services in driving the identifica-
tion and modeling of variability within business processes. Consequently, it facilitates the
reuse of service variability provided by partner services. In addition, we elaborate how
WSVL descriptions for customisable composite services are generated from process
7.5 Developing and resolving variability in process-based service compositions
165
modeling elements. The description facilitates service consumers in customising compo-
site services. We also describe how to resolve variability in composite services to derive
process variants as the result of service customisation.
7.5.1 Developing process-based service compositions
Figure 7.14 presents the overview of our development methodology. In the first activity,
variability of the service composition is modeled using the feature modeling technique.
The result of this activity is a feature model capturing commonalities and variabilities in
consumer requirements of the composite service to be. Given a model of desired features,
the next activity will be the selection of partner services that can be used for the service
composition. For instance, the Swinsure Insurance selects the Swinpay Web service for
processing end-user payments. There are two types of partner services: (conventional)
non-customisable partner services and customisable partner services. The explicit
selection of customisable partner services helps to reduce overhead of addressing varia-
bility within the service composition. Customisable partner services come with WSVL-
based service descriptions.
During the second activity, both non-customisable partner services and customisable
partner services are transformed into a set of partner tasks that will be selectable for
modeling the process. As explained, a partner task is an operation provided by a partner
service that is responsible for an atomic message flow between the partner service and
the service composition. While non-customisable partner services are transformed to a set
of non-customisable partner tasks, results of transforming customisable partner services
are sets of alternative partner tasks. For each set of alternative partner tasks, we also
generate an abstract partner task representing all partner tasks in the set. Since the
variability of customisable partner services are expressed as feature models with mapping
to variant capabilities, we also derive mapping models that represent the correspondence
between alternative partner tasks and variant partner features, i.e. PartnerTaskFeature

Figure 7.14 - Overview of developing process-based service compositions
Feature
Modeling
Service
Selection
Process
Modeling
Dependency
Modeling
Variant
Derivation
Variability
Description
Generation
Feature
Model
PartnerTask
Repository
PartnerTask
Feature
Mapping Model
VBPMN
Process
Models
FeatureTask
Mapping
Model
Process
Variant
Service
Variability
Description
Activity Sequence Flow Data Flow Artifact
166
mapping models. Consequently, results of the service selection activity are a repository of
(alternative) partner tasks, abstract partner tasks and PartnerTaskFeature mapping
models. It should be noted that in this methodology, the PartnerTaskFeature mapping
models are intentionally generated before modeling the process.
In the third activity, the business process for the service composition is modeled us-
ing the extended metamodel. The identification of variation points and variants are based
on the feature model identified in the first activity. Tasks from the partner task repository
will be used to model the message flow between the service composition and partner
services. The selection of (alternative) partner tasks and abstract partner tasks from the
partner task repository will not only facilitate the reuse of variability provided by partner
services in the process modeling, but also enable the use of already generated Part-
nerTaskFeature mapping model in capturing variability inter-dependencies. In addition,
variability in the message flow between the service composition and consumers is
captured by means of consumer tasks. The result of this activity is VBPMN process
models (i.e. process models with variability).
In the next activity, the model mapping technique is exploited to model variability
intra-dependencies. That is, all variation points and variants in a process model are
mapped to variant features in the feature model of the business process. The result is a
FeatureTask mapping model.
The resulting software artifacts of the first four activities will be used in two differ-
ent ways. Firstly, they are used to generate the variability description of the resulting
service composition (i.e. Variability Description Generation activity). The result of this
activity is a WSVL description capturing the interaction between the service composition
and service consumers. Secondly, those software artifacts are used for the derivation of
process variants given a particular feature configuration (i.e. Variant Derivation activity).
This activity is required as part of service customisation. We elaborate the details of these
two activities in the next two sections.
Note that the prescribed process development methodology is based on a bottom-up
approach. In particular, (customisable) partner services are selected in advance before
modeling the process. Service compositions are modeled according to these partner
services, as well as their variability (or partner tasks). An alternative way of developing
VBPMN process models is by following a top-down approach. In this way, VBPMN
process models are created prior to the selection of partner services. The top-down
approach swaps the second activity (i.e. Service Selection) and the third activity (i.e.
Process Modeling) in the methodology while maintaining other activities in the same
167
order. For top-down approach, the Dependency Modeling activity needs also to capture
the mapping between partner tasks defined in the VBPMN models and variant partner
features in order to produce PartnerTaskFeature mapping model.
Typically, top-down approach requires adaptation of partner services (Nezhad 2007).
The top-down approach is business-driven and provides better alignment between
executable processes and business. In contrast, the bottom-up approach is IT-driven and
enables the reuse of existing software assets. In this case, the top-down approach has less
chance of reusing variability from partner services compared to the bottom-up approach.
To take advantages of both approaches, a hybrid approach (or iterative approach) which
uses a feedback flow between the third and second activities might be used. In any case,
VBPMN provides the necessary notations to model variability.
7.5.2 Deriving WSVL description
As explained in Chapter 4, the WSVL description of a business process facilitates brokers
in customising the process. To derive the WSVL description from process modeling
elements, we define the following derivation rules (Nguyen 2012b):
The description of customisation options is XML representation of the feature
model for the business process following the WSVL XML schema.
The description of service capability is generated from ConsumerTasks. As dis-
cussed in section 7.4.1.3, a ConsumerTask represents a service operation
invoked by service consumers. Therefore, the description of service capability
contains all ConsumerTasks as service capability. ConsumerTasks associated
with AbstractConsumerTasks become variant capabilities, while other Con-
sumerTasks are common capabilities among all variants.
The description of feature mapping is XML representation of all links associating
variant features with ConsumerTasks in the FeatureTask mapping model.
The description of customisation endpoint is specific to process engines and ser-
vice platforms that composite service providers use. Therefore, it is outside the
scope of these derivation rules. However its general semantics is accepting a set
of selected variant features, a set of disabled variant features and returning
WSDL/WSVL descriptions of one customised process (cf. Chapter 4).
Figure 7.15 presents an excerpt of the WSVL description for the claim handling pro-
cess which is generated from VBPMN process modeling elements. The service capability
description contains four variant operations. The feature mapping description defines that
the first two operations are available when the feature Bank transfer is selected while
168
the next two operations depends on the feature BPAY. This description is based on
modeled ConsumerTasks in VBPMN process models (cf. Example 7.6), as well as links
between these ConsumerTasks and variant features in the FeatureTask mapping model.
7.5.3 Deriving executable process variants
While the modeling of variability and variability dependencies is a design time process,
the derivation of an executable process variant happens at either design time or runtime.
This is triggered when the service composition is customised by brokers or the provider
itself. As explained, the customisation is performed using the feature model of the service
composition and generally requires the runtime customisation of respective partner
services. For instance, Figure 7.16 presents a possible feature configuration which is the
result of a broker's customisation.
Given a feature configuration, we exploit model transformation techniques as fol-
lows to derive a particular executable process variant (Nguyen 2012b):
The FeatureTask mapping model is referenced for specialising the process model.
The process model is actually a model template which is the superset of all pro-
cess variants. Each variant process element is associated with a presence
condition which is a propositional formula of variant features. These proposition-
al formulas are built from links in the FeatureTask mapping model. For each
variant process element, its presence condition is evaluated against the given fea-
ture configuration. If the evaluation result is true, the process element is retained.
Otherwise, the process element is purged from the process model. The result of
this task is an abstract process variant which does not have variability but still

Figure 7.15 - An excerpt of the WSVL description for Swinsure claim handling process
<wsdl:definition name=SwinsureClaimHandling>
<wsdl:portType name="swinsurePortType">
<wsdl:operation name="sendBankPaymentDetail/>
<wsdl:operation name="submitBankTransactionDetail/>
<wsdl:operation name="sendBPAYPaymentDetail/>
<wsdl:operation name="submitBPAYTransactionDetail/>
</wsdl:portType>
<wsvl:mappingInfo >
<wsvl:serviceElementRef ref="tns:sendBankPaymentDetail" target="operation"/>
</wsvl:link>
<wsvl:serviceElementRef ref="tns:submitBankTransactionDetail" target="operation"/>
</wsvl:link>
<wsvl:link name="BPAY1/>
<wsvl:link name="BPAY2/>
</wsvl:mappingInfo>
</wsdl:definition>
Service
Capability
Feature
Mapping
169
contains partner tasks and consumer tasks. Figure 7.17 presents a process variant
of the sub-process for collecting excess fee which corresponds to the feature con-
figuration in Figure 7.16.
The PartnerTaskFeature mapping model is referenced for generating a feature
configuration for each customisable partner service. In particular, each partner
task specifies a set of partner variant features to be selected and a set of partner
variant features to be disabled according to the PartnerTaskFeature mapping
model. From the set of selected partner tasks in the process variant, we build up a
feature configuration by combining the state of all partner variant features speci-
fied by these partner tasks. These feature configurations are used to customise
partner services and produce particular partner service variants. For instance, giv-
en the process variant in Figure 7.17, the partner task Bank payment
confirmation is selected among three possible partner tasks (cf. Example 7.7).
This partner task is mapped to the partner feature Bank transfer with pres-
ence=true and the partner feature User notification with presence=false
(cf. Figure 7.13). Since there is only one selected partner task with respect to the

Figure 7.16 - A feature configuration for Swinsure claim handling process
170
Swinpay Web service, the resulting feature configuration is CR=({Bank trans-
fer}, {User notification}). Consequently, the Swinpay Web service will be
customised with this a customisation request containing this feature configura-
tion
33
. The result of this customisation is a partner service variant which will be
invoked by this process variant.
From the abstract process variant and partner service variants, an executable pro-
cess variant is generated. We presume the use of BPEL for the executable
process. It is important to note that the abstract process variant is a conventional
BPMN 2.0 process model since all variabilities have been resolved
34
. Therefore,
the generation of the BPEL definition from the abstract process variant follows
the exact mapping between BPMN elements and BPEL elements defined in the
BPMN 2.0 specification. Another important remark is that the existence of part-
ner tasks in the abstract process variant helps to create partner links and accurate
service invocation between the process variant and partner service variants.

33
Due to restrictions in the feature model of the Swinpay Web service, the optimised customisa-
tion request derived from this customisation request is CR=({Bank transfer, Confirmation},
{User notification, BPAY, Execution, Credit card, Cheque}). CR (and therefore the
original CR) are complete customisation requests (cf. Chapter 3)
34
Strictly speaking, abstract process variants still contain new modeling elements such as
DataObjectVariant, ConversationVariant, or PartnerTask. However, these elements are
inherited from BPMN elements without additional properties. They are regarded as BPMN
elements in generating BPEL definition

Figure 7.17 - A process variant of the sub-process for collecting excess fee
7.6 Prototype system and evaluation
171
Finally, based on the information of consumer tasks in the abstract process vari-
ant, a WSDL description of this process variant is generated.
At the end of this activity, a fully executable process variant that matches the given
feature configuration is generated along with a service interface description. The process
variant will invoke a set of automatically customised partner service variants. Note that
the essence of this derivation process is the association of relevant variants (i.e. control
flow variants, data flow variants, and message flow variants) to form one process variant
based on the concepts of feature and feature mapping. In this regard, the concepts of
feature and feature mapping are analogous to the concept of Correlation Set in
BPMN/BPEL which provides a mechanism for associating relevant artefacts (i.e. Mes-
sage, Conversation, Process) to produce a complete business process with respect to one
particular service consumer.
This section discusses the conformity, applicability, and feasibility of our approach in
supporting customisable composite services. In addition, we present a prototype system
that helps to illustrate the feasibility of our approach.
7.6.1 Conformity
VBPMN extends BPMN by adding new modeling elements for representing different
types of variation points and variants in process models. The extension does not modify
existing BPMN elements. Nor does it change relationships or constraints among those
elements (cf. metamodel extensions in Figure 7.7, Figure 7.8, and Figure 7.9). The only
exception is the insertion of the element ControlFlowVariant between the element
FlowNode and other BPMN elements like Gateway, Event (cf. Figure 7.7). However, the
insertion does not change the relationships between FlowNode and other BPMN ele-
ments. We argue that VBPMN conforms to BPMN and enables the modeling of both
extended BPMN models and conventional BPMN models. This conformity is further
illustrated in section 7.6.4 when we model the motivating example using our process
modeling tool.
In addition, process variants, which are resulted from resolving variability in
VBPMN models, also conform to BPMN. For variability in data flow, variability resolu-
tion results in the use of either DataObjectVariant or DataAssociationVariant within a
process variant. Note that DataObjectVariant (DataAssociationVariant) inherits
DataObject (DataAssociation) without adding new properties. Therefore, both DataOb-
172
jectVariant and DataAssociationVariant are regarded as BPMN elements when
considering process variants. As for the resolution of variability in message flow, process
variants will contain ConversationVariant, ConsumerTask, and PartnerTask. Similar to
DataObjectVariant and DataAssociationVariant, ConversationVariant is regarded as
Conversation in BPMN. In addition, ConsumerTask and PartnerTask are only used as
supporting information for generating WSVL description and integrating process variants
with partner service variants. The use of these two elements does not violate the conform-
ity of process variants with respect to BPMN.
In case of variability in control flow, a control flow variant is a process fragment
which contains BPMN elements (i.e. Activity, Gateway, Event) and possibly other nested
control flow variation points. When variability in control flow is resolved, the part of a
process variant between ControlFlowVPStart and ControlFlowVPEnd is replaced by
one control flow variant. Since we only allow nested control flow variability, such
variability is recursively resolved so that the final process variants do not contain any
control flow variation point. In other words, process variants only contain BPMN
elements with respect to resolving variability in control flow. In summary, resolving
variability in VBPMN process models results in process variants which can be regarded
as BPMN models. This indicates the conformity of process variants (i.e. VBPMN models
after variability resolution) with respect to BPMN. This conformity enables the use of the
mapping between BPMN elements and BPEL elements defined in BPMN 2.0 specifica-
tion to automatically generate executable process variants as discussed in section 7.5.3.
7.6.2 Applicability
With respect to representing variation points and variants, VBPMN enables the modeling
of variability with respect to all three aspects of service compositions: control flow, data
flow, and message flow. As for control flow, VBPMN models are able to capture different
process fragments as control flow variants, as well as nesting a control flow variation
point within another. For data flow, VBPMN models enable the modeling of alternative
and optional data objects and/or data associations. As for message flow, VBPMN models
are able to capture alternative and optional conversations between a process and partner
services (or service consumers). Note that while VBPMN is defined at the meta-modeling
level, the use of VBPMN in modeling customisable processes is performed at the model-
ing level. Therefore, it is essential to have a process modeling tool based on VBPMN to
evaluate prescribed usages. As demonstrated later in our prototype system, VBPMN is
173
able to capture all possible variabilities encountered in our motivating example which is
based on a number of industrial business processes (cf. section 7.2).
With respect to variability dependencies, our approach relies on MDE (Model-
Driven Engineering) techniques for capturing such dependencies. In particular, we define
metamodels to model both variability intra-dependencies and variability inter-
dependencies. The actual models for representing variability intra-dependencies and
variability inter-dependencies are instantiated from these metamodels. As discussed in
section 7.4.2, the techniques enable the capturing of all variability intra-dependencies in
VBPMN models that are resulted from refining variability at the feature level. In addition,
the techniques are applicable to model variability inter-dependencies between VBPMN
models and customisable partner services as long as the partner services are described by
WSVL (cf. section 7.4.3). Similar to VBPMN for capturing variation points and variants,
it is also essential to have a tool based on these metamodels to evaluate their application
and usage.
7.6.3 Feasibility and prototype system
To evaluate the feasibility of our approach, we have developed a prototype system which
supports:
modeling customisable services and different types of variability,
modeling variability intra-dependencies and variability inter-dependencies,
and enabling service customisation that
conforms to our feature-based service customisation framework,
conforms to WSVL-based service interface description,
and supports recursive service customisation.
Tools in the prototype system have been used throughout the chapter to demonstrate
our approach. In the next section, we summarize and provide additional information
about the tools.
7.6.4 The prototype system
7.6.4.1 Overview
Our prototype system is a toolset that comprises of the following components: 1) a
process modeling tool that implements VBPMN, 2) model mapping tools for capturing
variability dependencies, 3) a set of model transformation tools for deriving WSVL
descriptions and process variants, 4) a feature modeling tool for controlling service
customisation. We describe these tools in detail in following subsections.
174
7.6.4.2 The process modeling tool
7.6.4.2.1 Overview
Eclipse GMF (Graphical Modeling Framework) (Eclipse 2012a) is a framework for
developing graphical modeling tools based on EMF Ecore metamodels (Eclipse 2012b).
We use this framework to develop our process modeling tool based on VBPMN meta-
model. An overview of the complete VBPMN metamodel can be found on Appendix C.
Figure 7.18 is a screenshot of the process modeling tool. The left area is the graph-
ical editor area where processes are modeled, while the right area is the tooling area.
Developers are able to select existing and new process elements from the tooling area
while modeling processes. In particular, the section Variation Points and Variants
contains extended elements for modeling variation points and variants, while the section
Connections contains link elements for connecting variation points and variants. Other
sections in the tooling area contain BPMN elements.
The screenshot shows the sub-process for collecting excess fee. Some excerpts of
this sub-process have been shown in Example 7.3, Example 7.6, and Example 7.7. The
sub-process demonstrates two control flow variation points, namely VPS4/VPE4 and
VPS5/VPE5, one data flow variation point, namely Unoccupied excess, and three
message flow variation points, namely CVP1, CVP2, and CVP3. CVP1 and CVP2 model
the message flow between the process and end-users, while CVP3 models the message
flow between the process and the partner service Swinpay Web service. The Part-
nerTasks Bank payment confirmation, BPAY payment confirmation, Credit card
payment, AbstractPartnerTask Payment service, as well as the PartnerTaskFeature
mapping model for CVP3 are derived from the Swinpay WSVL as explained in section
7.5.1. Modeling variability in this way enables the capturing of variability inter-

Figure 7.18 - A screenshot of the process modeling tool
175
dependencies between the process and the Swinpay Web service.
The process modeling tool also supports the generation of the WSVL description
from the context menu. This function is developed as an Atlas Tranformation Language
(ATL) model transformation that implements derivation rules presented in the section
7.5.2).
7.6.4.2.2 Evaluation
We have used our process modeling tool to model the claim handling process. In its
simplest form, the claim handling process comprises of 1 main process and 12 sub-
processes. Almost all sub-processes contain variability, such as the one shown in Figure
7.18. There are only 3 sub-processes which are conventional BPMN models without
variability (e.g. the sub-process for arranging temporary accommodation). There are more
than 100 variation points within the whole claim handling process corresponding to the
variability at the feature level (cf. Figure 7.2). Note that the number of sub-processes and
variation points is only relative since the more detail we model the claim handling
process, the more number of sub-processes and variation points is required.
The modeling of the case study demonstrates the applicability of VBPMN in sup-
porting customisable composite services. Different types of variation points and variants
encountered in our case study have been successfully captured by our process modeling
tool. In addition, the tool also enables the modeling of conventional BPMN processes.
This illustrates the conformity of our approach with respect to BPMN.
7.6.4.3 The variability dependencies modeling tools
7.6.4.3.1 Overview
The variability intra-dependencies modeling tool (cf. Figure 7.11) is implemented as an
extension to Atlas Model Weaver (AMW) (Didonet 2006). The tool is developed based
on three metamodels: the feature metamodel, VBPMN metamodel, and the mapping
metamodel. It provides a graphical editor for mapping a feature model conforming to the
feature metamodel with a process model conforming to VBPMN metamodel. The
resulting mapping model is an instance of the mapping metamodel and represents
variability intra-dependencies. Note that the tool is not specific to one case study. It
accepts a feature model and a process model as inputs and enables to create the mapping
between the two models.
Similarly, the variability inter-dependencies modeling tool is based on three meta-
models: VBPMN metamodel, the feature metamodel and the mapping metamodel. Note
176
that the process mapping metamodel (cf. Figure 7.12) is similar to the feature mapping
metamodel in WSVL (cf. Figure 4.11). In particular, the element processElement in the
process mapping metamodel and the element serviceElement in the feature mapping
metamodel are interchangeable when they both represent a PartnerTask (or an opera-
tion). This similarity implies that the PartnerTaskFeature mapping model will remain the
same regardless of whether it is developed in the variability inter-dependencies modeling
tool or it is generated from the WSVL description of the partner services.
The variability dependencies modeling tools have been used to successfully capture
variability intra-dependencies and variability inter-dependencies in our case study. In
particular, each variation point and its variants identified in the process modeling tool is
successfully mapped to relevant variant features to form the FeatureTask mapping model.
In addition, PartnerTasks in process models are mapped to variant features of the
Swinpay Web service to form the PartnerTaskFeature mapping model.
The successful use of the tools in capturing both variability intra-dependencies and
variability inter-dependencies in our case study demonstrates the applicability and the
feasibility of our metamodels with respect to modeling variability dependencies. In the
next section, we consider the use of these models in facilitating process customisation.
7.6.4.4 The process customisation tool
7.6.4.4.1 Overview
We have implemented a model transformation tool for deriving process variants. The tool
implements the transformation rules specified in section 7.5.3. It accepts three types of
input models: the extended process model as a result of the process modeling tool, the
variability dependencies models as a result of variability dependencies modeling tools,
and a feature configuration model. The tool then generates an abstract process variant, as
well as recursively customise the Swinpay Web service according to the variability inter-
dependencies models. Note that the Swinpay Web service is implemented and deployed
on a local server according to our techniques for supporting customisable atomic services
(cf. Chapter 6).
The model transformation tool is integrated with our feature modeling tool presented
in Chapter 6 so that a process variant can be automatically generated as the result of
configuring the feature model (cf. Figure 7.16 and Figure 7.17). For this feasibility test,
7.7 Analysis of techniques for enabling customisable composite services against
177
we do not implement the part for generating executable BPEL definition. However, this
task is technically achievable (White 2005; Ouyang 2008).
The process customisation tool has been used to successfully derive different process
variants according to different feature configurations instantiated from the feature model
for the claim handling process. Note that there is no difference between the variability
resolution mechanism for customisable composite services and the one for customisable
atomic services described in Chapter 6. In either case, they follow the feature-based
service customisation framework which is described in Chapter 3 and is realised in our
service provisioning architecture. It means, our extended process model is also suitable
for the component Configurable service implementation in our service provisioning
architecture (for supporting customisable composite services). In addition, the automated
customisation of the Swinpay Web service as a result of customising the claim handling
process demonstrates the usefulness of capturing variability inter-dependencies to support
recursive service customisation. Last but not least, both the WSVL description and
variability resolution are based on VBPMN models and mapping models that associate
feature models with VBPMN models. Therefore, they are consistent with each other in
enabling service customisation.
7.7 Analysis of techniques for enabling customisable composite
services against service variability characteristics
We analyse our techniques for supporting customisable composite services against
characteristics of service variability identified in Chapter 2. In particular, the techniques
address the following characteristics (cf. Figure 7.19):
Exposed variability: For customisable composite services, exposed variability is
also captured in WSVL in a similar way to customisable atomic services. As dis-
cussed in section 7.5.2, a WSVL description is generated from modeling elements
in VBPMN models as well as mapping models that associate feature models with
VBPMN models. This automated generation guarantees the consistency between
exposed variability described in a WSVL description and composition variability
captured in VBPMN models.
Composition variability: We address the variability in the implementation of cus-
tomisable composite services by extending BPMN 2.0 with new modeling
elements. These elements enable the explicit representation of variation points
178
and variants in process models with respect to all three aspects of service compo-
sitions: control flow, data flow, and message flow. In addition, they facilitate the
generation of executable process definitions as a result of a service customisation
since variability is comprehensively modeled and managed.
Partner variability: Our process modeling technique supports the variability of
partner services by means of PartnerTask, AbstractPartnerTask, as well as
ConversationVP and ConversationVariant. In addition, our process develop-
ment methodology explicitly utilizes variability information from partner services
in driving the identification and modeling of variability within business process-
es. Consequently, partner variability is systematically reused in addressing
variability of customisable composite services.
Variability intra-dependencies and variability inter-dependencies: We have de-
fined process mapping metamodels (cf. Figure 7.10 and Figure 7.12) which
enables the modeling of variability intra-dependencies and variability inter-
dependencies. Variability intra-dependencies are captured by means of a Fea-
tureTask mapping model, while variability inter-dependencies are captured by
means of a PartnerTaskFeature mapping model.
Requirement, Architecture abstraction levels: Variability of customisable com-
posite services is considered at the requirement level by means of a feature model

Level
(Interface/
Implementation)
Composition
variability
Implementation Architecture
Intra-
dependencies
Variation
points and
variants
Service variability
Internal
Partner
variability
External
Automated Inter-
dependencies
Exposed
variability
Variability
communication
independence
Self-
describing
Staged
instantiation
Who
(Provider/
Consumer)
level
Requirement
Variability
constraints
Composite service realisation
7.8 Summary
179
and at the architecture level by means of a VBPMN process model. As discussed
in section 7.1.1, we do not explicitly model variability at the implementation level
(e.g. in BPEL definition). Instead, we comprehensively model variability at the
architecture level and exploit the mapping between BPMN elements and BPEL
elements defined in the BPMN specification for achieving variability at the im-
plementation level.
Automated and Staged instantiation: The comprehensive modeling of variability
at the architecture level enables the derivation of executable process variants as a
result of process customisation. In addition, owing to the mapping between varia-
bility at the feature level and variability at the architecture level, it is possible to
propagate variability resolution decisions at the feature level to resolve variability
at the architecture level. In other words, our techniques also support staged in-
stantiation in customising composite services.
Level (I nterface/Implementation): In our techniques, variability in the extended
process model is first resolved to result in an abstract process variant. The ab-
stract process variant is then transformed to an executable process definition. In
addition, a WSDL description specific to the executable process definition is also
generated for describing its service interface. Consequently, variability resolution
is performed at both the service implementation and the service interface levels.
Recursive: Owing to the explicit modeling of variability inter-dependencies,
partner services are dynamically customised as a result of service customisation.
And both the service customisation and the customisation of partner services are
based on our feature-based service customisation framework. These properties
demonstrate how variability instantiation of customisable services is recursively
performed according to the recursive nature of service compositions.
7.8 Summary
In this chapter, we have described the techniques for supporting customisable composite
services. In particular, we focused on process-based service compositions and proposed
VBPMN, which is our extension of BPMN 2.0, for the comprehensive modeling and
management of variability in composite services. The techniques take into account
variability inter-dependencies between a composite service and partner services and bring
out two benefits. Firstly, variability of partner services is reused to reduce overhead of
addressing variability in the composite service. Secondly, services can be recursively
customised according to the recursive nature of service composition. We have also
180
specified the use of WSVL for describing customisable composite services, as well as
feature-based customisation of composite services. These usages are similar to the way
that customisable atomic services are supported. Consequently, the techniques introduced
in this chapter contribute to our overall framework for supporting customisable services.

181

8. Case Study and Evaluation
In this chapter, we present the case study of a real-world complex service interface from
cloud computing domain and use the case study to demonstrate our complete solution for
supporting the development, provisioning and consumption of customisable Web ser-
vices. In addition, we identify three metrics and use them to evaluate the efficiency
improvement brought about by our service customisation approach.
Section 8.1 discusses the case study of Amazon Web Service (aka. AWS). The AWS
(Amazon 2013) is a cloud computing service that allows businesses to obtain and manage
computing resources. It is designed as a super service that contains a lot of service
operations for various purposes (e.g. machine image management, machine instance
management, security configuration, or subnet management) required by all of its
customers.
In section 8.2, we apply our techniques to redesign the AWS as a customisable ser-
vice. In particular, section 8.2.2 describes the use of our variability modeling techniques
discussed in Chapter 4 for capturing variability at both the feature level and the service
capability level, as well as representing the mapping between these two levels. Section
8.2.3 discusses service implementation that conforms to the identified service variability.
In this section, we utilize our techniques presented in Chapter 6 for developing the
configurable service implementation. Section 8.2.4 describes the deployment of that
configurable service implementation using our service provisioning architecture dis-
cussed in Chapter 5. The result of this service deployment is a fully functioning
customisable AWS that can be used in our evaluation experiment.
Section 8.3 discusses our evaluation. In particular, section 8.3.1 presents three evalu-
ation metrics. They are the number of service operations, the number of loaded classes,
and memory consumption of the deployed services. Section 8.3.2 elaborates settings for
the experimental procedure and describes how a representative sample of service variants
was selected. Section 8.3.3 presents the experiment results and our discussion.
Section 8.4 discusses the limitations of our evaluation. We then summarize the chap-
ter in section 8.5.
8.1 Case study
We have selected the AWS WSDL interface as the case study for demonstrating and
evaluating our solution because it presents a complex interface with many operations and
a vast array of potential configurations. The AWS is a cloud computing service that
allows businesses to obtain and manage computing resources (i.e. hardware instances
Chapter 8 - Case Study and Evaluation
182
with pre-installed software such as Microsoft Windows server machines or Linux
machines), as well as scaling up and down such resources based on their needs. It follows
the IaaS (Infrastructure-as-a-Service) service model. The AWS provides a Web-based
management console from which businesses are able to manage their hardware instances
in Amazon cloud environment. Alternatively, there exists a Web service interface that
allows businesses to programmatically manage such instances. This Web service interface
is the main focus of our case study. While the term AWS is generally used to refer to
both this Web service interface and Amazons cloud business, we mainly use this term to
refer to the Web service interface in this thesis. In addition, we use the term AWS WSDL
to technically refer to the WSDL description of such interface.
The AWS WSDL defines a complete set of service operations for the following pur-
poses:
Managing machine images: Machine images are software template that contains
a software configuration (operating system, application server, and applica-
tions). Machine images facilitate the instantiation of (hardware) instances. The
AWS WSDL provides a set of service operations for creating, registering and
de-registering machine images as well as their attributes.
Managing (machine) instances: Machine instances (or instances in short) are
virtual servers instantiated from machine images. These instances are requested
and operated by businesses in the cloud environment. The AWS WSDL defines
service operations for manipulating attributes and status of machine instances as
well as starting/rebooting/terminating such instances. In addition, businesses are
able to manipulate external storages, snapshots and network interfaces that are
associated with those instances.
Security configuration: Businesses are also able to control security configura-
tion. In particular, they are able to manage access control, VPN connections, or
security credentials.
Subnet management: Some businesses need not only individual instances in the
cloud computing environment but also a network of machines. For these busi-
nesses, the AWS WSDL defines service operations for manipulating different
aspects of their subnets, such as DHCP settings, routing tables, gateways, or se-
curity group.
The AWS WSDL has totally 149 service operations which utilize a large number of
data types and spans 7253 lines of code. There is only one unique WSDL for all business-
es regardless of their varying needs and demands. As such, the AWS is designed by
8.1 Case study
183
following the super service approach as described in Chapter 1. This approach inherently
includes redundancy in service provisioning and complexity in service consumption
which consequently lead to performance penalty when serving a large number of busi-
nesses as discussed below.
8.1.1 Revisiting the inefficiency of the super-service approach
From service provisioning perspective, a super service usually has a big program foot-
print which is larger than what is necessary to serve each customer with particular
requirements. A big program footprint results in high memory consumption which has
two negative impacts on the overall system performance. Firstly, less memory is available
for other tasks in the system, and more frequent paging and garbage collections will
happen. As the result, more CPU time is spent on this extra overhead. Secondly, high
memory consumption will also require longer garbage collection time for the program
itself and incur more CPU resources. Therefore, either cases will require extra unneces-
sary CPU time, resulting in longer response time and lower throughput for business
customers (Juse 2003).
In the context of AWS, it has been reported that the AWS manages around 500.000
instances which implies a very large number of business customers (Liu 2012). To be
able to serve this large number of businesses with satisfied quality of service (e.g.
availability, throughput, response time), the AWS needs to be replicated on a number of
servers (Cardellini 1999). For the super service approach, all servers will run the same
version of the AWS which all contain redundancy. If each version is adapted to remove
such redundancy according to businesses it serves, it becomes possible to serve more
businesses and increase the QoS.
From service consumption perspective, each business usually only requires a subset
of the available service operations and data types. Therefore, the one-size-fit-all service
interface of the AWS is more complex than what is required by each customer. This
complexity makes it harder for customer developers to comprehend and process the
service interface. Especially in the context of Web service development, client programs
of a Web service are usually automatically generated by a development framework. The
frameworks create a lot of boilerplate code. Having a lot of unused
ports/operations/message types in the WSDL will generate a lot of useless boilerplate.
This makes the client code heavy-weight and hard to navigate by developers.
For example, in the AWS context, it is possible to exclude 10 service operations and
their various related data types from the AWS service interface description if a business
184
does not need a feature to manage external storages of its instances. Similarly, if a
business does not require advanced feature for manipulating snapshots, the AWS service
interface description can be further simplified by removing other 7 service operations and
their data types. Detailed discussion of this can be found later in section 8.2.2.3. As such,
simplifying the service interface based on businesses specific requirements will help to
increase efficiency in service consumption.
In the next section, we describe how we re-design the AWS as a customisable ser-
vice using our approach.
8.2 Redesign the AWS as a customisable service
To develop the customisable version of the AWS, we identify the variability associated
with the AWS and realize such variability in a way that it can be deployed in our service
provisioning architecture. The first subsection outlines the overview of such process
while remaining subsections elaborate the details of each step within the process.
8.2.1 Overview
Figure 8.1 presents the overview of the process for redesigning the AWS. The process
comprises of three main steps as follows:
Variability modeling: The techniques for this step have been discussed in Chap-
ter 4. In particular, service variability will be captured at two levels of
abstraction: feature level and service capability level. At the feature level, the fea-
ture modeling technique is utilized to produce a feature model that represents
variability in businesses requirements with respect to the AWS. For the service
capability level, common and variant service capabilities need to be identified ac-
cording to the variability captured in the feature model. In addition, variability at
both levels need to be associated by means of our feature mapping technique. As
discussed in Chapter 4, this feature mapping model reflects the refinement rela-
tionships between variability at the two levels of abstraction.
Service implementation: The information of variability at the modeling level fa-
cilitates the realization of such variability in service implementation. As
discussed in Chapter 6, there are two types of variability that needs to be imple-
mented: variability in the service skeleton and variability in the business logic.
This step will utilize techniques described in Chapter 6 to implement these two
types of variability for the AWS. The outcome of this process is the component
185
Configurable service implementation (cf. section 5.3) that can be deployed on
our service provisioning architecture.
Service deployment: As discussed in Chapter 5, the deployment of a newly creat-
ed customisable service involves the generation of a customisation frontend and
the registration of the service and its feature model in our service middleware that
implements our service provisioning architecture. The customisation frontend is
responsible for exchanging customisation messages. In addition, the registration
of the service and its feature model is important so that other components of the
service middleware, such as Feature model manager, Runtime customisation
and management engine, and Variant profile repository, are able to facilitate the
derivation of new service variants, as well as managing such variants if requested
by the customisation frontend (cf. Figure 5.2).
8.2.2 Variability modeling
8.2.2.1 AWS feature model
We utilise our feature modeling tool to develop the AWS feature model. To this end, we
analyse the AWS WSDL and identify features which are common to all businesses and
features which are only specific to a subset of businesses. Common features will become
mandatory features, while businesses specific features become variant features in this
feature model. In addition, features are organized into the feature hierarchy according to
their functional relationships. Dependencies among features are also extracted from their

Figure 8.1 - Overview of redesigning the AWS

Feature modeling
Service capability
modeling
Feature mapping
Variability
modeling
Code generation Variability annotation
Service
implementation
Customisation frontend
generation
Feature model &
service registration
Service
deployment
186
functional relationships and are captured by means of feature constraints. Figure 8.2
presents the resulted feature model which is detailed below:
The whole service is captured as the root feature PaaS Management Web Ser-
vice.
Feature Machine image management is for managing machine images. This is
an optional feature. Once it is selected, feature Attribute manipulation which
allows businesses to manipulate machine image attributes (e.g. launch permis-

Figure 8.2 - AWS feature model
Legend
Root feature
Mandatory feature wrt parent feature
Variant feature
Feature group
Grouped feature
187
sions) becomes mandatory. Feature Image manipulation is optional. This fea-
ture allows image manipulation functions like creating or copying images.
Instance management is a mandatory feature. It comprises of an optional fea-
ture Instance description, and two mandatory features Instance
manipulation and Instance usage type.
Feature Instance description allows businesses to retrieve information related
to their instances. This information is related to either instance attributes (i.e. fea-
ture Attribute description) or instance status (i.e. feature Status
description). Consequently, these two child features, Attribute description
and Status description, are organized into a feature group with group cardinali-
ty [1-2].
Feature Instance manipulation allows businesses to control various aspects of
their instances, including booting functions (i.e. feature Booting), external
storage management (i.e. feature External storage), and network interface con-
figuration (i.e. feature Network interface). For booting, feature Basic
represents fundamental booting functions like starting, rebooting, or stopping in-
stances, while feature Advance captures advanced control, such as launching a
number of instances from a machine image (i.e. feature Run) and terminating a
running instance (i.e. feature Terminate). For external storage, feature Vol-
ume manipulation represents functions related to instance volumes, while
feature Snapshot manipulation captures functions that utilizing those volumes
for storing instance snapshots. Similarly, for network interface configuration,
businesses are able to select either elastic IP addresses or private IP addresses, as
well as manipulating network interface cards associated with their instances (i.e.
feature NIC card manipulation).
Feature Instance usage type defines different types of instances that can be
requested by businesses. While all businesses require standard instances (i.e. fea-
ture On demand) which are hourly charged with constant cost, some
businesses might prefer to use reserved or spot instances which offer different us-
age and billing models. Reserved instances (i.e. feature Reserved) are charged
per month and are cheaper than standard instances which can be cancelled at any
time. And spot instances (i.e. feature Spot) provide businesses who have flexi-
bility on when to run their instances the ability to bid for instances at
significantly lower price.
188
Feature Security controls different aspects of security configuration including
security credentials (i.e. feature Key pairs), network access control (i.e. feature
Network ACL), and secure connections (i.e. feature VPN connections).
Feature Monitoring allows business to enable or disable monitoring capabili-
ties for their instances.
Feature Subnet management allows businesses to control their subnet(s) in the
cloud environment such as creating or deleting subnets. Its child features provide
finer-grained control over such subnets. In particular, businesses are able to spec-
ify DHCP options (i.e. feature DHCP options), define gateway (i.e. feature
Customer gateway), manipulate routing tables (i.e. feature Route tables),
and manipulate security groups (i.e. feature Security group). All of these fea-
tures are optional and specific to businesses who have high demand on the cloud
environment and require advanced control.
As can be seen from Figure 8.2, many features of the AWS feature model are variant
features. This reflects the fact that many service capabilities defined in the AWS WSDL
are only oriented to a subset of businesses. In other words, each business only requires a
small portion of the full service capabilities provided in the AWS WSDL in order to
operate properly. As such, being able to remove redundant service operations and data
types based on businesses specific requirements (aka. specific feature configurations)
will help to simplify the service interface and improve the efficiency of service consump-
tion as discussed in section 8.1.1.
In addition to the feature hierarchy as shown in Figure 8.2, there are also re-
quire/exclude constraints among variant features. Figure 8.3 presents feature constraints
captured in our feature modeling tool in association with the AWS feature model. There

Figure 8.3 - AWS feature constraints
Exclude
constraints
Require
constraints
189
are totally 10 constraints of which 8 constraints define require relationships. Note that
there are 75096 complete feature configurations that can be produced from the AWS
feature model. As the result, businesses are able to customise and request to use one
among 75096 possible service variants. This large number of service variants shows the
scale of variation that our feature-based customisation approach can provide in order to
match businesses varying demands, and illustrates the fact that in this scenario all-
service-variant approach is infeasible (i.e. deploying all 75096 pre-defined service
variants as independent services) . The viable solution using traditional technologies is
the super service approach as exploited by the AWS.
8.2.2.2 AWS service capability model
The AWS service capability model is developed using our service capability modeling
tool discussed in section 4.3.3. Figure 8.4 presents an excerpt of the AWS service
capability model as the result of this activity. As discussed in Chapter 4, this service

Figure 8.4 - AWS service capability model
190
capability model captures all service capabilities required by any service variant. As such,
the model contains the full set of service capabilities as described in the AWS WSDL,
including both common service capabilities and variant service capabilities.
The grounds for classifying a service operation as common or variant are defined by
the AWS feature model. In particular, if a service operation realizes mandatory features,
it becomes service capability common to all services. On the other hand, when a service
operation realizes one or more variant features, it is classified as variant service capabil-
ity. For instance, the top 5 service operations represented in Figure 8.4 (i.e. operations
CopyImage, CreateImage, DescribeImages, RegisterImage, DeregisterImage) are needed
to realize the variant feature Image manipulation. Consequently, they all become
variant service capability. This rule of classifying common and variant service capabili-
ties reflects refinement relationships between variability at the service interface level and
variability at the feature level as discussed in Chapter 4. In particular, variability at the
service interface level is only the refinement of variability at the feature level.
Among 149 service operations captured in the AWS service capability model, we
identify 13 service operations to be common service capabilities, while the other 136
service operations are variant service capabilities. The existence of this large number of
variant service capabilities compared to the number of common service capabilities is
consistent with the fact that most features in the AWS feature model are variant features.
8.2.2.3 AWS feature mapping model
We use the feature mapping technique to denote which service capabilities in the service
capability model are variant. To this end, we use our feature mapping tool introduced in

Figure 8.5 - AWS feature mapping model
191
section 4.3.4. Figure 8.5 presents an excerpt of the resulted feature mapping model. It
shows the mapping of two variant features External storage and Snapshot. Variant
feature External storage is associated with 10 service operations related to managing
storage volumes, such as operations DescribeVolumes() or AttachVolume(). Similarly,
variant feature Snapshot manipulation is associated with 7 service operations related to
manipulating snapshots such as operations CopySnapshot() or CreateSnapshot().
There are a number of things that are worth noting about this mapping model:
Each link captures the mapping between one variant feature and a number of ser-
vice operations. This number of service operations is as few as 1 (e.g. feature
Run is mapped to only one service operation RunInstances) and is as many
as 13 (e.g. feature Customer gateway is mapped to 13 service operations for
managing different aspects related to customer gateways). This varying number
reflects the one-to-many relationships between variability in the feature model
and variability in the service capability model.
In this particular case study, there is no service operation which is mapped to
more than one feature. In other words, the presence of any variant service capa-
bility in one service variant is only decided by one variant feature. As the result,
each link in the mapping model associates only one variant feature. Note that this
property does not have any implication on how our techniques are applied to real-
ise the customisable AWS. Because our mapping technique supports more
generic cases in which one link can accommodate multiple variant features. Nor
does it affect the evaluation result that we demonstrate in section 8.3.
Not all variant features need to be represented in the mapping model. For in-
stance, variant feature Basic is always selected when the feature Booting is
selected. (cf. Figure 8.2). Therefore, in the mapping model, it is possible to use
either feature Booting or feature Basic to specify a link without changing
the implication of the mapping model. In other words, it is possible to ignore us-
ing one of these two features in the mapping model. Similar situations can also be
observed with respect to two features Machine image management and At-
tribute manipulation, or two features External storage and Volume
manipulation.
8.2.3 Skeleton service implementation
Given the service variability identified in section 8.2.2, the next step is implementing a
customisable service which conforms to that variability. As discussed in Chapter 6, this
192
refers to the realization of the component Configurable service implementation in our
service provisioning architecture. This phase consists of two main activities. Firstly, the
implementation code is generated from the engineering models produced in section 8.2.2.
Secondly, we apply our variability realization techniques to make this implementation
code configurable.
8.2.3.1 Code generation
As discussed in section 4.3.5, we use XSLT to transform the AWS service capability
model (cf. section 8.2.2.2) to the description of service capability which is a part of the
WSVL document for the customisable AWS. Note that the description of service capabil-
ity is identical to the abstract service description in the AWS WSDL. From the
description of service capability, we use WSDL2Java tool, which is an implementation of
JAX-WS in Apache CXF, to generate the implementation code for the customisable
AWS. The generated code contains not only the service skeleton but also the dummy
implementation of the service. That is, we automatically generate the business logic by
randomly producing the return results. By this, the generated code is executable and
produces the simplest form of service implementation that conforms to the service
interface.
Generated code
Figure 8.6 shows an excerpt of the screenshot of the generated code. As defined by JAX-
WS specification, the generated code contains a Service Endpoint Interface (SEI) (i.e.

Figure 8.6 - An excerpt of the generated code
Generated
code Service Endpoint
Interface (SEI)
Service
implementation class
Data type
classes
Data type
classes
193
class AmazonEC2PortType.java), a service implementation class (i.e. class Ama-
zonEC2PortTypeImpl.java), and a number of data type classes for representing XML data
types specified in the description of service capability. Specifically, a SEI is a Java
interface that represents the portType in the service interface description, while each
method within the SEI corresponds to a service operation. The service implementation
class implements the SEI and captures the business logic of a service. Also data type
classes facilitate the handling of XML data types used in input/output messages of the
service. The mapping between data type Java classes and XML data types is specified by
JAXB data binding as discussed in Chapter 6. For instance, the first 6 data type classes in
Figure 8.6 (i.e. from AccountAttributeNameSetItemType.java to AccountAttributeVal-
ueSetType.java) represents different XML data types that are all used in the definition of
input/output messages for service operation DescribeAccountAttribute().
Generated SEI
Figure 8.7 presents an excerpt of the generated SEI. The figure shows two methods,
describeVolumeAttribute() and modifyVolumeAttribute(), which represent two service
operations in the AWS WSDL. These service operations use data type classes (e.g.
DescribeVolumeAttributeType or DescribeVolumeAttributeResponseType) to define their
input and output parameters. Annotations demonstrated in Figure 8.7, such as
@WebMethod or @WebResult, are JAX-WS annotations for capturing mapping between
Java constructs and WSDL elements. This SEI class has 149 methods that represent 149
service operations defined in the AWS WSDL.

Figure 8.7 - An excerpt of the generated SEI
@WebService(name = "AmazonEC2PortType")
@XmlSeeAlso({ObjectFactory.class})
public interface AmazonEC2PortType {
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@WebResult(name = "DescribeVolumeAttributeResponse")
@WebMethod(operationName = "DescribeVolumeAttribute")
public DescribeVolumeAttributeResponseType describeVolumeAttribute(
DescribeVolumeAttributeType describeVolumeAttributeRequestMsgReq
);
@WebResult(name = "ModifyVolumeAttributeResponse")
@WebMethod(operationName = "ModifyVolumeAttribute")
public ModifyVolumeAttributeResponseType modifyVolumeAttribute(
ModifyVolumeAttributeType modifyVolumeAttributeRequestMsgReq
);
}
194
Generated service interface implementation
Figure 8.8 presents an excerpt of the generated service implementation class that imple-
ments the SEI interface. The figure presents the automatically generated code for two
service operations whose signatures are defined in Figure 8.7. As can be seen from Figure
8.8, the business logic for each service operation is very simple. It does not perform any
complex computation. Instead, the automatically generated business logic only returns
empty result in the required format. Despite this simplicity, the generated business logic
satisfies two objectives. Firstly, it makes the generated code executable and ready to be
deployed as a functioning service. Secondly, it enables the measurement of runtime
resources required by service deployment.
8.2.3.2 Variability annotation
Similar to the service capability model, the description of service capability contains both
common and variant service capability. So as the generated code. To create customisable
AWS, we need to make this generated code configurable and its configuration conforms
to our feature-based service customisation framework. As such, the generated code forms

Figure 8.8 - An excerpt of the generated service implementation class
public class AmazonEC2PortTypeImpl implements AmazonEC2PortType {
DescribeVolumeAttributeType describeVolumeAttributeRequestMsgReq) {
LOG.info("Executing operation describeVolumeAttribute");
System.out.println(describeVolumeAttributeRequestMsgReq);
try {
DescribeVolumeAttributeResponseType _return = null;
return _return;
} catch (java.lang.Exception ex) {
ex.printStackTrace();
throw new RuntimeException(ex);
}
}
ModifyVolumeAttributeType modifyVolumeAttributeRequestMsgReq) {
LOG.info("Executing operation modifyVolumeAttribute");
System.out.println(modifyVolumeAttributeRequestMsgReq);
try {
ModifyVolumeAttributeResponseType _return = null;
return _return;
} catch (java.lang.Exception ex) {
ex.printStackTrace();
throw new RuntimeException(ex);
}
}
}
195
the component Configurable service implementation which can then be used with other
components in our service middleware.
As discussed in Chapter 6, there are generally two types of variability in the imple-
mentation of a service: variability in the service skeleton and variability in the business
logic. In the case of our customisable AWS, no business logic is implemented and as such
does not contain variability. Consequently, we only need to take into account variability
in the service skeleton.
To this end, we utilize our FeatureMapping annotation type discussed in section
6.4.2. In particular, from the feature mapping model, we identify the presence condition
associated with each variant service capability. Each presence condition generally
contains a list of selected features and a list of disabled features that collectively enable
the presence of a variant service capability in a service variant (cf. section 6.2.1).
FeatureMapping annotation type is then used to annotate such information for the
corresponding variant service capability in the generated SEI.
As discussed in section 8.2.2.3, in the case of customisable AWS each variant ser-
vice operation is mapped to only one feature while one feature is mapped to multiple
variant service operations. As such, the FeatureMapping annotation of each variant
service operation only contains one feature in the property enabledFeatureList, while the
property disabledFeatureList is empty.
Figure 8.9 demonstrates how we use FeatureMapping annotation to annotate variant
service capability in the SEI. The two variant service capabilities (i.e. service operations)
correspond to the service operations shown in Figure 8.7. They are annotated with only
feature External storage as a selected feature. As such, only when this feature is
selected, these two service operations will be available in service variants. In the com-

Figure 8.9 - An excerpt of the annotated SEI
@WebService(name = "AmazonEC2PortType")
@XmlSeeAlso({ObjectFactory.class})
public interface AmazonEC2PortType {
@WebResult(name = "DescribeVolumeAttributeResponse ")
@WebMethod(operationName = "DescribeVolumeAttribute")
@FeatureMapping(enabledFeatureList = {"External storage"}, disabledFeatureList = {""})
DescribeVolumeAttributeType describeVolumeAttributeRequestMsgReq
);
@WebResult(name = "ModifyVolumeAttributeResponse")
@WebMethod(operationName = "ModifyVolumeAttribute")
@FeatureMapping(enabledFeatureList = {"External storage"}, disabledFeatureList = {""})
ModifyVolumeAttributeType modifyVolumeAttributeRequestMsgReq
);
}
FeatureMapping annotations
196
plete SEI, the selection of feature External storage enables the presence of 10 service
operations. This correspond to the feature mapping model demonstrated in Figure 8.5.
Note that this annotated SEI provides sufficient information so that the component
Runtime customisation and management enginein our service provisioning architecture
is able to dynamically build a service model for a service variant-to-be with respect to one
feature configuration (cf. section 6.4.1). As the result, the runtime engine can produce
service variants on the fly to serve particular customers.
8.2.4 Service deployment
The process of deploying the customisable AWS in our service provisioning architecture
consists of two main steps. Firstly, a customisation frontend which is specific to the
customisable AWS is generated. Secondly, different components of the customisable
AWS (i.e. Customisation frontend, Configurable service implementation, Feature
model manager, Variant profile repository, and Runtime customisation and manage-
ment engine) are inter-connected to produce a fully functioning customisable service.
The following subsections discuss these two steps in details.
8.2.4.1 Customisation frontend generation
As discussed in section 5.3, the business logic for the customisation frontend of customis-

Figure 8.10 - Screenshot for the generated AWS customisation frontend
Generated
customisation
frontend
AWS feature
model
AWS customisation endpoint
197
able services is common for all customisable services. In particular, it interacts with other
components of the service provisioning architecture (i.e. Feature model manager and
Runtime customisation and management engine) to coordinate the validation of
customisation requests and dynamic deployment of service variants. However, there are
two features of the Customisation frontend that are specific to each customisable service.
Firstly, one Customisation frontend is uniquely defined for one customisable service.
That is the Customisation frontend is invoke-able by customer programs at a uniquely
defined customisation endpoint. Secondly, the Customisation frontend of a customisable
service is associated with the feature model of that service.
For this reason, we generate the customisation frontend code for the customisable
AWS from the one we developed in Chapter 6 (cf. section 6.4.1) and take into account
above mentioned two features in the generation. Figure 8.10 presents the screenshot for
the generated customisation frontend. On the left hand side of the figure is a set of Java
classes for the AWS customisation frontend while the right hand side shows how business
logic of the generated code is associated with the AWS feature model and an uniquely
defined customisation endpoint for the customisable AWS.
WSVL document generation
The WSVL document that describes the customisable AWS is managed by the AWS
customisation frontend. In particular, our service middleware allows customers to access
the WSVL document by querying the following URL customisation_endpoint?wsvl
(i.e. the URL is associated with the customisation endpoint of the customisation
frontend). Therefore, The URL for the customisable AWS in this case is
http://localhost:8080/ec2CustomisationFrontend?wsvl (cf. Figure 8.10).
As discussed in Chapter 4, a WSVL document consists of 4 pieces of information: i)
description of customisation options, ii) description of service capability, iii) description
of feature mapping, and iv) description of customisation function. As discussed in section
4.3.5, the first three are generated from engineering models (i.e. feature model, service
capability model, and feature mapping model) by means of XSLT transformations. In
particular, feature model is transformed to the description of customisation options,
service capability model facilitates the generation of the description of service capability,
and feature mapping model is used to produce the description of feature mapping. On the
other hand, the description of customisation function is actually the WSDL description of
the component Customisation frontend. Therefore, once the AWS Customisation
frontend is generated, we produce the AWS WSVL description by combining the AWS
Customisation frontend WSDL with descriptions transformed from engineering models.
198
The resulted WSVL document is exposed by the component AWS Customisation
frontend as described above.
8.2.4.2 Feature model and service registration
The other components (i.e. Feature model manager, Runtime customisation and
management engine, and Variant profile repository) are already provided by our service
middleware that implements the service provisioning architecture. As such it is not
necessary to create and make these components specific to the customisable AWS.
However, these components need to be aware of the newly deployed customisable AWS.
To this end, we only need to register the customisable AWS and the AWS feature model
to these components in our prototype implementation.

Figure 8.11 - Feature model registration with Feature model manager
// Create new QuestionTrader object
mQuestionTrader = new QuestionTrader();
VariabilityModel fm = mQuestionTrader.openFile("models/ec2.xml");
mQuestionTrader.setVariabilityModel(fm);
// Register new QuestionTrader object with feature model manager
FeatureModelManager mFMManager = FeatureModelManager.getInstances();
mFMManager.register(mQuestionTrader);
<?xml version="1.0" encoding="UTF-8"?>
<feature-model>
<feature name="PaaS-Management-Web-Service">
<binaryRelation>
<cardinality max="1" min="0"/>
<solitaryFeature name="Machine-image-management">
<binaryRelation>
<solitaryFeature name="Image-manipulation/>
</binaryRelation>
<binaryRelation>
<solitaryFeature name="Attribute-manipulation/>
</binaryRelation>
</solitaryFeature>
</binaryRelation>
</feature>
<requires feature="Advance" requires="Monitoring"/>
<excludes feature="Private-IP-address" excludes="DHCP-options"/>
</feature-model>
b) Registering AWS feature model with Feature model manager
a) XML representation of AWS feature model (ec2.xml)
199
Figure 8.11 demonstrates how the AWS feature model is registered to the Feature
model manager in our prototype system. As discussed in section 6.4.1, the implementa-
tion of the component Feature model manager is based on the FAMA framework.
Therefore, the AWS feature model is first represented in XML notations defined by the
FAMA framework (cf. the top part of the figure). The XML representation is then used to
instantiate a QuestionTrader object which is used by the Feature model manager to
manage each and every feature model for all customisable services (cf. the bottom part of
the figure).
Figure 8.12 demonstrates how to register the customisable AWS with the Variant
profile repository. The top part of the figure shows the skeleton for the implementation
class of the Variant profile repository, called VariantManager in our prototype imple-
mentation. As can be seen from the skeleton, there are methods for retrieving or updating
existing service variants, and registering new service variants. In addition, there is a
dedicated thread for managing service variant lifecycle, such as un-deploying expired
service variants (cf. Chapter 5). The bottom part of the figure demonstrates how a new
customisable service (i.e. the customisable AWS in this case) registers itself to the
Variant profile repository before deployment. This is actually performed by the compo-
nent Customisation frontend.
Figure 8.13 presents an excerpt of the component Runtime customisation and man-

Figure 8.12 - Service registration with Variant profile repository
public class CustomizationPortTypeServer {
private VariantManager mVariantManager;
protected CustomizationPortTypeServer() throws Exception {
// Initialize a variant manager
mVariantManager = VariantManager.getInstances();
CustomizationPortType implementor =
new CustomizationPortTypeImpl(mVariantManager);
EndpointImpl endpoint = (EndpointImpl)Endpoint.publish(
"http://localhost:8080/ec2CustomizationFrontend",
implementor);
// Log incoming and outgoing messages
ep.getServer().getEndpoint().getInInterceptors().add(new LoggingInInterceptor());
ep.getServer().getEndpoint().getOutInterceptors().add(new LoggingOutInterceptor());
public class VariantManager implements VariantManagerInterface {
public int lookupVariantIndex(HashMap<String, Boolean> featureConfiguration) {}
public void updateVariant(int variantIndex) {}
public void registerNewVariant(HashMap<String, Boolean> featureConfiguration,
int variantIndex) {}
public void registerEndpoint(EndpointImpl endpoint) {}
private class VariantLifeCycle implements Runnable {}
}
b) Register the customisable AWS before deploying Customisation frontend
a) Variant profile repository implementation class
200
agement engine. As can be seen from the excerpt, the runtime engine searches for an
existing service variant with respect to a feature configuration. If such service variant
exists, the engine updates the service variant and returns a customisation response without
deploying new service variant. Otherwise, the engine dynamically derive and deploy a
new service variant with a new variant endpoint which is then returned to customers.
After this step, the customisable AWS is fully deployed in our service middleware
and fully functioning with the following functionalities:
The AWS customisation frontend mediates all incoming customisation requests
to other components of the service provisioning architecture (i.e. Feature model
manager and Runtime customisation and management engine) and returns ap-
propriate customisation responses as the result of service customisation.
To customise the service, customer programs send a complete feature configura-
tion to the AWS customisation frontend. The feature configuration will be
validated by the Feature model manager. Invalid feature configurations will be
rejected. For a valid feature configuration, the Variant profile repository is con-
sulted to check if the corresponding service variant has already been deployed
and is still active. Otherwise, the Runtime customisation and management en-
ginewill dynamically derive and deploy a new service variant.
8.3 Evaluation
In this section, we study the performance of service variants which are dynamically
generated and deployed by the redesigned customisable AWS interface. The comparison

Figure 8.13 - An excerpt of the Runtime customisation and management engine
implementation
/* Active variant already exists */
if ((variantIndex = mVariantManager.lookupVariantIndex(mFeatureConfiguration)) != -1) {
// Update variant state
mVariantManager.updateVariant(variantIndex);
// Return the existing endpoint
response.setWsdlURI(variantIndex);
return response;
}
/* Create new variant index */
variantIndex = mVariantManager.getVariantIndex(mFeatureConfiguration);
/* Perform customisation */
performCustomisation();
/* Dynamic deployment */
servicePort = serviceClass.newInstance();
serviceLocation = createVariantEndpoint(variantIndex);
variantEndpoint = (EndpointImpl)Endpoint.publish(serviceLocation, servicePort);
8.3 Evaluation
201
with the performance of the super-service AWS will help to highlight efficiency brought
about by our service customisation approach. In particular, we identify three metrics that
capture the consumption and provisioning perspectives of a running Web service (Section
8.3.1). We then describe automated experiments for collecting the data of these three
metrics in two settings: service variants generated by the customisable AWS and the
super-service AWS (Section 8.3.2). The comparison between two sets of data will be
discussed in Section 8.3.3.
8.3.1 Metrics
We define three metrics that account for the efficiency of provisioning and consuming
services: 1) the number of service operations, 2) the number of loaded classes, and 3) the
memory consumption (i.e. the size of permanent generation memory pool). While the first
metric captures the consumption perspective, the other two metrics represent the provi-
sioning perspective of a service.
The number of service operations: This is the number of service operations in
the service interface description of a service. This number accounts for the size of
a service interface description. The more number of service operations a service
interface description has, the more complex it would be for consumer developers
to comprehend and consume the service.
The number of loaded implementation classes: When a service is deployed, a
number of classes is loaded to make the service ready for being invoked by cus-
tomer programs. These classes comprise of middleware classes and
implementation classes. The former term refers to classes required by the service
middleware for its proper operation, such as classes for processing and exchang-
ing SOAP messages. In contrast, the latter term refers to implementation classes
specific to the business logic of one service. In the context of JAX-WS program-
ming frontend and JAXB data binding, these classes represents the service class
and data types defined in the WSDL document. While the number of middleware
classes is quite similar across services deployed on the same service middleware,
the number of implementation classes is service specific and represents runtime
resources required for that service.
The size of permanent generation memory pool: The memory consumption of a
deployed service is characterized by a number of memory pools used by the Java
Virtual Machine (JVM) (Oracle 2013). Most of these memory pools are dynamic
due to the operation of garbage collection and optimization mechanisms within
202
the JVM. The only exception is the permanent generation memory pool (aka.
PermGen memory) which is rather stable. This memory pool contains reflective
data of classes and method objects required for the execution of a Java program at
runtime. Therefore, the size of the PermGen memory is a good indicator of
memory consumption for a deployed service (Masamitsu 2006).
8.3.2 Experimental settings
8.3.2.1 Variant selection
As discussed in section 8.2.2.1, there are totally 75096 possible service variants. Our
experiments shown that for each service variant, the experiment time is 23 minutes.
This experiment time is mainly comprised of the following 3 periods:
The time for producing a complete feature configuration and sending a customi-
sation request to the customisable AWS
The time for deriving a corresponding service variant, and
The time for deploying the service variant and waiting the two metrics (i.e. the
number of loaded classes and the PermGen size) to be stable
Among these three components, the last takes the most experiment time. Given the
experiment time for one service variant, running experiment against all possible service
variants is impractical. Therefore, we identify three typical types of service variants to
which the experiment will be performed. Each service variant type involves around 300
service variants (i.e. correspond to 1015 hour experiment) and produces representative
data for our analysis. For each service variant type, all service variants belonging to the
type will be requested resulting in the dynamic derivation and deployment of these
service variants. Service variants of each type will be analysed to determine the average
and spread of their creation time. The three service variant types are as follow:
Light-weight service variants: Service variants belonging to this type do not re-
quire advanced functions for managing subnets, instances, machine images, and
external storages. In addition, they only support the standard instances (i.e. re-
served and spot instances are not required). For these service variants, a number
of variant features in the AWS feature model that represent those functions are
not required and are disabled. Figure 8.14 shows the feature configuration tem-
plate for these service variants. The selection or disabling of a number of features
have already been decided and are common to all service variants of this type.
Service variants of this type are different with respect to customisation decisions
related to open variant features (i.e. ones with empty boxes). Also, as can be seen
8.3 Evaluation
203
from the top of the figure, there are totally 288 service variants belonging to this
type.
Medium-weight service variants: Similar to light-weight service variants, these
service variants do not require advanced functions for managing subnets or in-
stances. Also, they do not support reserved instances. However, service variants
of this type are able to include advanced functions for managing machine images
and external storages, as well as supporting spot instances if necessary. In addi-

Figure 8.14 - Light-weight service variants
Legend
Service variant type
Variant (selectable) feature
Disabled feature
Feature group
204
tion, all of these service variants provide functions for retrieving instance descrip-
tions as well as supporting basic booting of instances (i.e. the corresponding
features are selected). Figure 8.15 shows the feature configuration template for
this type of service variants. A number of variant features has already been se-

Figure 8.15 - Medium-weight service variants
Legend
Disabled feature
Feature group
Selected grouped feature
8.3 Evaluation
205
lected or disabled according to the description above. Note that, there are 315
service variants of this type.
Heavy-weight service variants: For this type, nearly all variant features are se-
lectable. The only exception is feature VPN connections which is disabled due
to the selection of feature Security group and the exclude constraint between

Figure 8.16 - Heavy-weight service variants
Legend
Disabled feature
Feature group
Selected grouped feature
206
them (cf. Figure 8.3). These service variants are similar to medium-weight ser-
vice variants in the sense that they all include functions for retrieving instance
descriptions and supporting basic booting of instances. Also, all heavy-weight
service variants provide capability for managing machine images, external stor-
ages, and monitoring. In addition, advanced features for subnet management and
security can be added if necessary. Figure 8.16 shows the feature configuration
template for this type of service variants. As can be seen from the figure, there
are 384 service variants of this type.
8.3.2.2 Experiment procedure
Figure 8.17 presents the overview of the experiment. In this experiment, we extend the
console version of our consumer prototype tool (cf. section 6.4.3) to work as a client
program. When the experiment starts (Step 1), the client program is configured with the
corresponding type of service variants (Step 2). Specifically, the AWS feature model is
configured with the partial feature configuration representing the type of service variants
to be experimented (cf. Figure 8.14, Figure 8.15, and Figure 8.16). The client program
then iterates through all possible complete feature configurations that can be produced
from this partially configured feature model (Step 3, 4, 15, 16). These complete feature
configurations represent all service variants belonging to this particular type. For each
feature configuration, the client program sends a customisation request to the customisa-
ble AWS service (Step 4) and asynchronously waits for a customisation response (Step
15). On the server side, when a customisation request is received though the Customisa-
tion frontend of the customisable AWS (Step 5), the Runtime customisation and
management engine dynamically derives and deploys a service variant matching the
request (Step 6).
Note that in this experiment, all requested (complete) feature configurations are val-
id. The ability of our service middleware for validating requested feature configuration
has already been verified in Chapter 6 (cf. section 6.4.4.1) and is not the focus of this
experiment. In addition, each service variant is un-deployed once all necessary metrics
are collected to avoid its impact on collected data for subsequent service variants. As
such, the Runtime customisation and management engine needs to derive and deploy a
new service variant every time there is an incoming customisation request. Also, each
service variant is deployed in one dedicated JVM so that the collected data is not influ-
enced by other programs (e.g. the runtime engine). Again, the ability of our service
8.3 Evaluation
207
middleware for managing lifecycle of service variants has already been tested in Chapter
6 (cf. section 6.4.4.2) and is not repeated in this experiment.
In this experiment, we instrument our runtime engine so that it enables the collection
of three metrics explained in the previous section 8.3.1. Specifically, once the service
variant is fully deployed (Step 6), the runtime engine collects the first metric (i.e. the
number of service operations exposed by the service variant) (Step 7). The runtime
engine then continues to collect the other two metrics by querying the Java Virtual
Machine (JVM) on which the service variant is deployed (Step 8, 9, 10, 11, 12). Since the
Experiment overview
Customisable AWS Client
Experiment start
Partial feature
configuration
Has more feature
configuration
Finish experiment
No
Send customisation
request
Yes
Dynamic derivation and deployment
of a new service variant
Calculate number of
service operations
Initialize number of loaded
classes and PermGen size
Sleep 30s
Query JVM for number of loaded
classes and PermGen size
Have the metrics
increased?
Yes
Store all metrics
No
Un-deploy service
variant
Return customisation
response
Receive customisation
response
Receive customisation
request
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Set up service
variant type
Collect metric
Collect metric

Figure 8.17 - Overview of the experiment
208
number of loaded classes and the size of PermGen memory keeps increasing during the
course of service deployment, we wait until the deployment reaches the saturated state to
collect these two metrics (cf. execution loop comprised of step 9, 10, 11). Once all
metrics are collected, the service variant is un-deployed as explained above (Step 13). A
customisation response is then sent to the client program (Step 14) so that it can continue
with another feature configuration or terminate when all feature configurations have
already been experimented.
8.3.3 Experiment results
8.3.3.1 Data normalization
As discussed in section 8.3.1, there are two types of classed being loaded in JVM:
middleware classes and implementation classes. The main interest in our experiment is
implementation classes which are specific to the business logic of a service. However, we
are only able to query JVM for the total number of classes being loaded. Since the
number of middleware classes is similar across all services deployed on the same service
middleware with the same settings (e.g. data binding techniques, logging configuration ),
we also collect the number of loaded classes for a very basic Web service. This basic
Web service has only one service operation which uses one primitive data type (i.e.
String) for its input and output messages. The collected data for this basic Web service
will be used as the offset for finding out the number of loaded implementation classes in
our experiment.
A similar adjustment is performed with respect to the PermGen size. Specifically, we
also retrieve the PermGen size for the basic Web service described above and use the
number as the offset for calculating the actual PermGen size specific to each service
variant in our experiment.
8.3.3.2 The number of service operations
Figure 8.18 presents the experiment results with respect to the number of service opera-
tions. As discussed in section 8.3.2, there are 288 service variants belonging to the
identified light-weight type. The corresponding numbers for the medium-weight and
heavy-weight types are 315 and 384 respectively. Figure 8.18 shows the average, maxi-
mum and minimum numbers of service operations for each type. Note that the original
AWS WSDL has totally 149 service operations. The experiment results show that our
service customisation approach helps to reduce the number of redundant service opera-
tions based on consumers specific requirements. While the reduction might not be
8.3 Evaluation
209
considerable for heavy-weight type, it is significant with respect to light-weight and
medium-weight service variants.
The reduction of the number of service operations helps to simplify the service inter-
face that needs to be comprehended and processed by customer developers. Note that
client programs of Web services are usually automatically generated by a development
framework. The frameworks create a lot of boilerplate code. The removal of unused
ports/operations/message types in the WSDL will prevent the generation of useless
boilerplate. This makes the client code lighter-weight and easier to navigate by develop-
ers. In other words, our service customisation approach helps to improve the efficiency in
service consumption.
8.3.3.3 The number of loaded classes
Figure 8.19 shows the experiment results with respect to the number of implementation
classes being loaded. In this figure, we show the data for service variants as the propor-
tion of the one for super service. Similar to the number of service operations, this figure
also displays the average, maximum and minimum of the data collected. The experiment
results show that the deployment of service variants requires fewer classes than the
deployment of the super service. Also similar to the number of service operations,
medium-weight and light-weight service variants consume much less runtime resources
compared to the deployment of super service.

Figure 8.18 - Number of service operations
54
90
142
40
62
116
25
35
87
0
20
40
60
80
100
120
140
160
Light-weight Medium-weight Heavy-weight
#
s
e
r
v
i
c
e

o
p
e
r
a
t
i
o
n
s
Max
Average
Min
149 Super-service
210
8.3.3.4 Memory consumption (PermGen size)
Figure 8.20 demonstrates the proportion of the memory consumption (i.e. PermGen size)
of service variants with respect to the memory consumption of the super service. Similar
to the number of loaded classes, the deployment of service variants requires less memory
usage than the deployment of the super service. In addition, that reduction is much more
significant in the case of light-weight and medium-weight service variants. The experi-
ment results with respect to the number of loaded classes and the memory consumption

Figure 8.19 - Loaded classes (%)
0
10
20
30
40
50
60
70
80
90
100
#

L
o
a
d
e
d

c
l
a
s
s
e
s

(
%
)
Max
Average
Min

Figure 8.20 - Memory consumption (%)
0
10
20
30
40
50
60
70
80
90
100
P
e
r
m
G
e
n

s
i
z
e

(
%
)
Max
Average
Min
8.4 Limitations of the evaluation
211
demonstrates that our service customisation helps to improve efficiency in service
provisioning.
8.4 Limitations of the evaluation
Lacking of internal business logic implementation: In this evaluation, we cannot obtain
the internal implementation of the AWS. Therefore, we have to use the service skeleton
with a dummy business logic implementation that does not perform complex computation
(e.g. user authorization or session management) or interact with database systems. While
the service skeleton is similar to what is required by the real implementation of the AWS,
the dummy business logic is much simpler than the real business logic. We are aware that
the results that we obtained through our automated expriments might not be the same if
we also take into account implementation classes for the real business logic. However, a
level of efficiency improvement could be expected with our approach even when the real
business logic implementation is incorporated. Because a smaller service skeleton yields
smaller program blueprint and consequently results in more efficient service provisioning.
Also, due to the lacking of internal business logic implementation, we cannot demonstrate
the application of our techniques for supporting variability in business logic.
The actual efficiency improvement depends on the mapping definition between the
feature model and the service capability model: In this case study, the relationship
between variant features and variant service capabilities is one-to-many. As the result, the
exclusion of a variant feature exclusively removes all variant service capabilities mapped
to the variant feature from the service capability model. In contrast, when the relationship
is many-to-many, state of a number of variant features needs to be taken into account
when deciding to retain or exclude a variant service capability. Therefore, when the
relationship changes, the number of service operations for each service variant might not
be the same as the experiment result demonstrated in the thesis. Similarly, due to the
dependence on the mapping definition, the level of efficiency improvement achieved in
this case study is not automatically transferable to other Web services.
The overall efficiency improvement depends on the proportion of the number of
businesses per service variant: In the evaluation, we compare the performace of each
individual service variant against the super-service. We then analyse the average perfor-
mace of a set of service variants belonging to each service variant type. We are aware that
this comparison assumes that the number of businesses requesting one service variant is
equal across all service variants of the same type. When there is fluctuation in the number
of businesses per service variant, a weighted mean may provide more precise analysis.
212
The consequences of efficiency improvement are not evaluated: Our evaluation has
shown that a significant efficiency improvement can be achieved using our service
customisation approach, especially with light-weight and medium-weight service vari-
ants. However, we do not provide the quantitative analysis of the consequences of such
efficiency improvement. For instance, as the result of reducing runtime resource usage,
how faster the response time is and how higher the throughput will be? This is mainly due
to the lacking of the internal business logic implementation.
While our evaluation with respect to the AWS provides quantitative insights on the
extent of efficiency improvement brought about by our service customisation approach, it
still has limitations as discussed above. A further enhancement of the evaluation taking
into account those limitations will be addressed as part of our future work.
8.5 Summary
In this chapter, we have presented the case study of Amazon Web Service (AWS). The
original AWS is designed as a super service. To evaluate how our service customisation
approach helps to improve the efficiency in service provisioning and consumption, we
have redesigned the AWS as a customisable AWS. This chapter describes the whole
process of applying our techniques to achieve that goal. In particular, we have elaborated
how to model service variability at both the feature level and the service capability level.
Also, we have demonstrated how to implement the customisable AWS that conforms to
the identified service variability. In addition, we have presented how to deploy such a
service in our prototype implementation of the service provisioning architecture. At the
end of this process, we successfully deploy and run the customisable AWS in our proto-
type system. To evaluate our approach, we have identified three metrics that represent
efficiency in service consumption and provisioning . These are the number of service
operations, the number of loaded classes, and the memory consumption. While the first
metric captures the service consumption perspective, the latter two captures the service
provisioning perspective. The experiment results collected with respect to the case study
show that our service customisation approach helps to significantly reduce redundancy
and improve efficiency in many circumstances (e.g. when customers require only light-
weight or medium-weight service variants).

213

9. Conclusion and Future Work
This chapter concludes the thesis by summarising what service variability characteristics
have been addressed. We then discuss the contribution of the thesis to the field of service
computing. Lastly, we describe the future work that could be done to further facilitate the
use of customisable services in service ecosystems.
9.1 Service variability characteristics addressed in this thesis
Figure 9.1 summarises what service variability characteristics have been addressed in this
thesis. This is the summary of our analyses presented at the end of each chapter from
Chapter 3 to Chapter 7. The figure demonstrates how each service variability characteris-
tic is related to research gaps and is addressed in the corresponding chapters for the
research gaps. Note that each research gap is individually addressed in one chapter from
Chapter 3 to Chapter 7. For the detail of how each service variability characteristic has
been addressed, readers are referred to the corresponding chapter and the analysis at the
end of the chapter.
As can be seen from the figure, one service variability characteristic might involve in
more than one research gap. This implies that the solutions for those research gaps
collectively address the service variability characteristic. For instance, Exposed variabil-

Figure 9.1 - Service variability characteristics addressed in this thesis
Implementation
Recursive
Intra-
dependencies
Architecture Composition
variability
Service variability
Internal
Partner
variability
External
Automated Inter-
dependencies
Exposed
variability
Variability
communication
independence
Self-
describing
Staged
instantiation
Who
(Provider/
Consumer)
Abstraction
level
Requirement
Variability
constraints
Customisation mechanism
Customisation enabler
Atomic service realisation
Composite service realisation
Level
(Interface/
Implementation)
Service provisioning
Chapter 9 - Conclusion and Future Work
214
ity of customisable services is considered from three aspects. The first aspect is how
exposed variability is captured at the service interface level by WSVL. The second aspect
is how such WSVL descriptions are supported internally by customisable atomic services
(i.e. the consistency between the exposed variability and the implementation of customis-
able atomic services). And the third aspect is related to how customisable composite
services support WSVL descriptions.
Figure 9.1 also demonstrates how the approach presented in this thesis comprehen-
sively address service variability characteristics. The solution for each research gap
contributes to our complete approach for enabling the composition and delivery of
customisable services. This is consistent to the summary of our work described in Table
2.2. In the next section, we discuss the contribution of this approach in detail.
9.2 Contribution
The major contribution of this thesis is to show how to enable the use of customisable
services. Customisable services effectively address issues related to service variability in
service ecosystems. Support for customisable services has been addressed in the follow-
ing aspects:
An efficient service customisation framework. By exploiting the concept of fea-
ture models to enable service customisation, we allow service consumers to
customise services at the requirement level. In this way, service consumers are
able to focus on what a service variant can achieve at a high level of abstraction,
rather than differences in low level technical details of each service variant. In
addition, there are fewer customisation options that need to be considered by ser-
vice consumers. This consequently helps to simplify the customisation. Another
advantage of using feature model is the ability to capture dependencies among
customisation options and support automated reasoning. Such reasoning can en-
sure the validity of service customisation.
A comprehensive customisation contract. The interface of a customisable service
is described by WSVL which is an extension of WSDL. WSVL has additional in-
formation for specifying how the service can be customised and the capability of
any service variant-to-be. The use of WSVL enables customisable services to be
self-describing in a similar fashion to conventional services. In addition, it ena-
bles loose coupling between service providers and service consumers with
respect to the consumption of customisable services. Last but not least, WSVL
9.2 Contribution
215
enables not only the customisation of services, but also the reuse of service varia-
bility.
Efficiency in deploying runtime service instances. A customisable service has a
configurable service implementation which enables the derivation of the business
logics specific to service variants. This capability removes the redundancy in the
business logic of service variants before deployment and helps to increase effi-
ciency in resource usage by runtime service (variant) instances.
Consistency in supporting both customisable atomic services and customisable
composite services. The two types of customisable services are consistently sup-
ported through the use of WSVL for specifying the service interface with service
consumers and the feature-based variability resolution mechanism for deriving
service variants. This enables service consumers to customise services in one
consistent manner specified in WSVL descriptions regardless of whether these
services are internally implemented as an atomic service or a business process.
Supporting variability inter-dependencies between a customisable composite ser-
vice and its customisable partner services. Our approach explicitly captures
variability inter-dependencies, and enables customisable composite services to
dynamically customise partner services and invoke partner service variants only
when such partner service variants are necessary. This enables the efficient re-
source usage required by partner service providers. In addition, services can be
recursively customised in line with the recursive nature of service composition.
We also demonstrated how to capture such variability inter-dependencies through
the use of WSVL for describing customisable partner services and VBPMN for
modeling customisable composite services.
Facilitating software reuse and software evolution in service development. We
show how to extend techniques from the SPL to develop customisable services.
Specifically, our approach systematically models and manages variability as well
as variability dependencies at both the service interface and service implementa-
tion level. In this way, the approach helps to address concerns related to software
reuse and software evolution with respect to the development of services.
As well as developing the concepts and key techniques for supporting customisable
services, a number of additional contributions have been made to software engineering
both at conceptual and technical levels. These are listed below.
A service provisioning architecture. This thesis shows how to deploy and provi-
sion customisable services. We present an architecture that comprises of a
216
number of components performing different functions related to service customi-
sation. The architecture provides a blueprint so that service providers can extend
their existing service platforms to accommodate customisable services. It is ge-
neric and applicable to the deployment and provisioning of both customisable
atomic services and customisable composite services.
Extension of the JAX-WS standard for engineering customisable atomic services.
We identify two types of variability in the implementation of atomic services: i)
variability in service skeleton, and ii) variability in business logic. And we de-
scribe how to extend the JAX-WS standard for capturing these two types. The
extension enables the development of the configurable service implementation for
a customisable atomic service. This configurable service implementation can be
deployed with our service provisioning architecture to produce a properly func-
tioning customisable atomic service.
Extension of the BPMN standard for engineering customisable composite ser-
vices. We present VBPMN which is an extension of BPMN 2.0 to enable the
introduction of variation points and variants in all three aspects of process-based
service compositions: control flow, data flow, message flow. We also devise and
demonstrate novel MDE techniques for capturing variability dependencies and
enabling process customisation. Process customisation results in BPMN process
variants which can be automatically transformed to executable BPEL process def-
initions according to the mapping between BPMN elements and BPEL elements
defined in BPMN specification. VBPMN process models constitute the configu-
rable service implementation which can be deployed with our service
provisioning architecture to produce a properly functioning customisable compo-
site service.
Prototype tools for supporting our service customisation approach. This thesis
presents a number of new prototype tools for supporting proposed techniques.
The tools have been used in a research setting for engineering, deploying and
provisioning a number of motivating examples (i.e. Swinsure Insurance Web ser-
vice, Swinpay Web service, and Swinsure claim handling process). All of the
motivating examples have been developed based on industrial case studies. Also,
the tools have been applied to address variability issues with respect to a real-
world case study (i.e. AWS). The successful application of our approach to these
examples and case study demonstrates not only the feasibility but also the ap-
plicability of the approach. Based on the motivating examples, we are able to
9.3 Future work
217
verify different aspects of service customisation (e.g. the operation of the service
provisioning architecture with respect to the validation of customisation requests
and service variant lifecycle managements, the dynamic derivation of service var-
iants for both atomic services and composite services). Also, based on the real-
world case study, we have quantitatively evaluated the efficiency brought about
by using our service customisation approach.
9.3 Future work
This thesis encompasses a complete range of concepts and techniques for enabling the
composition and delivery of customisable services. Customisable services are addressed
at both the service interface level and the service implementation level. In addition,
support for both atomic services and composite services, as well as their interaction are
taken into account. However, SOA techniques have been adopted in an increasing
number of application domains (e.g. context-aware software systems, mobile applica-
tions). In addition, apart from BPMN/BPEL, there are a variety of techniques for service
(process) engineering which have been introduced in the field of service computing.
Given these conditions, there remains much work to be done in order to enhance our
service customisation approach, as well as apply our concepts to a wider range of tech-
niques, before such an approach becomes a widely accepted engineering reality. The key
future work is listed below.
Feature interaction issues when modeling variability in non-functional requirements
(NFRs). To provide complete support for customisable services, an important extension
of this work is to incorporate support for variability in NFRs (e.g. performance or
security). However, modeling variability in NFRs is challenging due to the interactions
among functional features. In particular, a functional feature has impact on a number of
NFRs, while an NFR is associated with a number of functional features. For instance, in
the context of the Swinsure Insurance Web service, a service variant which provides
service capabilities for purchasing insurance policies by credit cards often requires higher
security, higher cost and longer processing time. Feature interaction issues become more
challenging when modeling variability in the architecture and implementation of services.
Variability modeling challenges for feature models with complex feature cardinali-
ties and feature constraints. This thesis deals with feature models which use simple
feature cardinalities (i.e. (0,1) or (1,1)) and simple feature constraints (i.e. require or
exclude relationships between two variant features). While this setting is applicable to
variability in all service-based systems which have been discussed so far in literature,
218
emerging application domains of SOA might require the use of complex feature cardinali-
ties (i.e. the upper bound of feature cardinalities is greater than 1) and/or complex feature
constraints (i.e. propositional relationships among multiple variant features). In such
cases, variability modeling in the architecture and implementation of services is very
challenging. Presence conditions of software variants in domain artefacts cannot be
simply expressed as If the variant features A
1
, A
2
,, A
n
features B
1
, B
2
,, B
m
are disabled, this software variant is available. Instead, much
more complex presence conditions that take into account how many time variant features
are selected or disabled are required. An example of such complex presence conditions in
the context of the Swinsure Insurance Web service is If at least two Extra Covers are
selected, this software variant is available. For customisable services captured as feature
models with complex feature cardinalities and feature constraints, not only is variability
modeling challenging, but also are new techniques required for variability resolution.
Extension of the approach to declarative processes (e.g. EPC). Chapter 7 of this the-
sis discusses our concepts of customisable composite services in the context of imperative
processes (i.e. BPMN, BPEL). However, the identified challenges in supporting cus-
tomisable composite services persist with respect to declarative processes as well. These
challenges include: i) how to capture variability inter-dependencies between a customisa-
ble service and its customisable partner services, ii) how to dynamically derive and
deploy service variants according to the feature-based service customisation framework,
and iii) how to describe the service interface of customisable composite services in order
to enable loose coupling between service providers and service consumers.
Empirical evaluation of the approach with respect to customisable composite ser-
vices. Chapter 7 of this thesis mainly focuses on supporting customisable composite
services at the architecture level. In the future work, we plan to extend an existing BPEL
process engine to support the deployment of customisable composite services. We also
develop the transformation for the automated generation of BPEL process definitions
from VBPMN process variants. These tools will be integrated with our existing prototype
system to evaluate different aspects of customising composite services in a similar way to
the evaluation described in Chapter 6.
9.4 Final words
We began this thesis by presenting the emergence of service ecosystems and a new
challenge with respect to the use of services in such service ecosystems that we call
service variability. Addressing service variability using existing service technologies is
9.4 Final words
219
inefficient with respect to service description, publication and consumption. In addition,
the presence of service variability necessitates the explicit and systematic modeling and
management of variability during service engineering to achieve a better level of software
reuse and software evolution. Our feature-based approach for the composition and
delivery of customisable services enables the introduction of customisable services as
first-class entities in SOA. A customisable service plays a similar role to a conventional
service with respect to the development of business applications. In addition, a customis-
able service effectively addresses issues related to service variability. An extended SOA
which supports customisable services will enable the emergence of more fruitful, dynam-
ic and valuable service ecosystems. Consequently, it helps service providers to build their
business applications with better quality and less cost in a more agile and flexible way.

221

Appendix A: XML Schema for WSVL
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://www.swin.edu.au/scf/wsvl"
elementFormDefault="qualified"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.swin.edu.au/scf/wsvl"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<import schemaLocation="http://schemas.xmlsoap.org/wsdl/"
namespace="http://schemas.xmlsoap.org/wsdl/"/>

<complexType name="tFeature">
<sequence>
<element name="feature" type="tns:tFeature" minOccurs="0"
maxOccurs="unbounded"/>
<element name="featureGroup" type="tns:tFeatureGroup"
minOccurs="0" maxOccurs="1"/>
</sequence>
<attribute name="name" type="NCName"/>
<attribute name="minCardinality" type="int"/>
<attribute name="maxCardinality" type="int"/>
</complexType>

<complexType name="tFeatureGroup">
<sequence>
</sequence>
<attribute name="minCardinality" type="int"/>
<attribute name="maxCardinality" type="int"/>
</complexType>

<complexType name="tFeatureHierarchy">
<sequence>
</sequence>
</complexType>

<complexType name="tRequireConstraint">
<sequence>
<element name="featureRef" type="tns:tFeatureRef"/>
<element name="requiredFeatureRef" type="tns:tFeatureRef"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>

<complexType name="tFeatureConstraint">
<sequence>
<element name="requireConstraint"
type="tns:tRequireConstraint" minOccurs="0" maxOccurs="unbounded"/>
<element name="excludeConstraint"
type="tns:tExcludeConstraint" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
222

<complexType name="tFeatureDescription">
<sequence>
<element name="featureHierarchy"
type="tns:tFeatureHierarchy" minOccurs="1" maxOccurs="1"/>
<element name="featureConstraint"
type="tns:tFeatureConstraint" minOccurs="0" maxOccurs="1"/>
</sequence>
<attribute name="targetNamespace" type="anyURI"
use="optional"/>
</complexType>

<element name="featureDescription"
type="tns:tFeatureDescription"/>

<complexType name="tMappingInfo">
<sequence>
<element name="link" type="tns:tLink" minOccurs="0"
</sequence>
<attribute name="targetNamespace" type="anyURI"
use="optional"/>
</complexType>

<complexType name="tLink">
<sequence>
<element name="featureRef" type="tns:tFeatureRef" minOc-
curs="1" maxOccurs="1"/>
<element name="serviceElementRef"
type="tns:tServiceElementRef" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>

<complexType name="tFeatureRef">
<attribute name="ref" type="QName"/>
<attribute name="presence" type="boolean" use="optional"
default="true"/>
</complexType>

<complexType name="tServiceElementRef">
<attribute name="ref" type="QName"/>
<attribute name="target" type="tns:tTarget"/>
</complexType>

<simpleType name="tTarget">
<restriction base="string">
<enumeration value="portType"/>
<enumeration value="operation"/>
</restriction>
</simpleType>

<element name="mappingInfo" type="tns:tMappingInfo"/>

<complexType name="tPort">
<complexContent>
<extension base="wsdl:tPort"/>
223
</complexContent>
</complexType>

<element name="port" type="tns:tPort"/>

<element name="portType" type="tns:tPortType"/>

<complexType name="tBinding">
<complexContent>
<extension base="wsdl:tBinding"/>
</complexContent>
</complexType>

<complexType name="tOperation">
<complexContent>
<extension base="wsdl:tOperation"/>
</complexContent>
</complexType>

<element name="binding" type="tns:tBinding"/>

<complexType name="tPortType">
<sequence>
<element name="operation" type="tns:tOperation" minOc-
curs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required" />
</complexType>

<complexType name="tExcludeConstraint">
<sequence>
<element name="featureRef" type="tns:tFeatureRef"/>
<element name="excludedFeatureRef"
type="tns:tFeatureRef"/>
</sequence>
</complexType>
</schema>

225

Appendix B: The WSVL Description of the Swinsure Insurance
Web service
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions name="swinsure"
targetNamespace="http://swinsure.scf.swin.edu.au/"
xmlns:tns="http://swinsure.scf.swin.edu.au/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsvl="http://www.swin.edu.au/scf/wsvl"
xmlns:fd="http://www.swin.edu.au/scf/swinsure/fd"
xmlns:md="http://www.swin.edu.au/scf/swinsure/md"
xsi:schemaLocation="http://schemas.xmlsoap.org/wsdl/ wsdl.xsd
http://schemas.xmlsoap.org/wsdl/soap/ soap.xsd
http://www.swin.edu.au/scf/wsvl wsvl.xsd">

<wsvl:featureDescription targetNamespace="http://www.swin.ed-
u.au/scf/swinsure/fd">
<wsvl:featureHierarchy>
<wsvl:feature name="SwinsureInsuranceWebService">
<wsvl:feature name="PolicyQuery" maxCardinality="1"
minCardinality="0"/>
<wsvl:feature name="PolicyCreation" minCardinality="1"
maxCardinality="1">
<wsvl:feature name="Quote" minCardinality="1" maxCar-
dinality="1">
<wsvl:feature name="PolicyType" minCardinality="1"
maxCardinality="1">
<wsvl:featureGroup minCardinality="1" maxCardinal-
ity="1">
<wsvl:feature name="Residential"/>
<wsvl:feature name="Business"/>
</wsvl:feature>
<wsvl:feature name="ExtraCover" minCardinality="0"
maxCardinality="1">
ity="3">
<wsvl:feature name="AccidentalDamage"/>
<wsvl:feature name="ExtendedThirdPartyLia-
bility"/>
<wsvl:feature name="FusionCover"/>
</wsvl:feature>
</wsvl:feature>
<wsvl:feature name="Purchase" minCardinality="0"
maxCardinality="1">
<wsvl:feature name="PaymentMethod" minCardinali-
ty="1" maxCardinality="1">
ity="1">
<wsvl:feature name="CreditCard"/>
<wsvl:feature name="CoverNote"/>
</wsvl:feature>
</wsvl:feature>
Appendix B: The WSVL Description of the Swinsure Insurance Web service
226
</wsvl:feature>
<wsvl:feature name="PolicyUpdate" minCardinality="0"
maxCardinality="1"/>
</wsvl:feature>
</wsvl:featureHierarchy>
<wsvl:featureConstraint>
<wsvl:requireConstraint>
<wsvl:featureRef ref="fd:PolicyUpdate"/>
<wsvl:requiredFeatureRef ref="fd:PolicyQuery"/>
</wsvl:requireConstraint>
<wsvl:excludeConstraint>
<wsvl:featureRef ref="fd:Residential"/>
<wsvl:excludedFeatureRef ref="fd:ExtendedThirdPartyLia-
bility"/>
</wsvl:excludeConstraint>
</wsvl:featureConstraint>
</wsvl:featureDescription>

<wsvl:mappingInfo targetNamespace="http://www.swin.edu.au/s-
cf/swinsure/md">
<wsvl:link name="LPolicyQuery">
<wsvl:featureRef ref="fd:PolicyQuery" presence="true" />
<wsvl:serviceElementRef ref="tns:viewPolicy" target="op-
eration" />
</wsvl:link>
<wsvl:link name="LPolicyUpdate">
<wsvl:featureRef ref="fd:PolicyUpdate" presence="true" />
<wsvl:serviceElementRef ref="tns:updatePolicy" target="op-
eration" />
</wsvl:link>
<wsvl:link name="LResidential1">
<wsvl:featureRef ref="fd:Residential" presence="true" />
<wsvl:serviceElementRef ref="tns:getQuote4Residential"
target="operation" />
</wsvl:link>
<wsvl:link name="LResidential2">
<wsvl:featureRef ref="fd:ExtraCover" presence="false" />
<wsvl:serviceElementRef ref="tns:getQuote4Residential"
</wsvl:link>
<wsvl:link name="LResidentialWithExtra1">
<wsvl:featureRef ref="fd:Residential" presence="true" />
<wsvl:serviceElementRef ref="tns:getQuote4Residential-
WithExtra" target="operation" />
</wsvl:link>
<wsvl:link name="LResidentialWithExtra2">
<wsvl:featureRef ref="fd:ExtraCover" presence="true" />
<wsvl:serviceElementRef ref="tns:getQuote4Residential-
</wsvl:link>
<wsvl:link name="LBusiness1">
<wsvl:featureRef ref="fd:Business" presence="true" />
<wsvl:serviceElementRef ref="tns:getQuote4Business" tar-
get="operation" />
</wsvl:link>
<wsvl:link name="LBusiness2">
<wsvl:featureRef ref="fd:ExtraCover" presence="false" />
<wsvl:serviceElementRef ref="tns:getQuote4Business" tar-
get="operation" />
227
</wsvl:link>
<wsvl:link name="LBusinessWithExtra1">
<wsvl:featureRef ref="fd:Business" presence="true" />
<wsvl:serviceElementRef ref="tns:getQuote4Business-
</wsvl:link>
<wsvl:link name="LBusinessWithExtra2">
<wsvl:featureRef ref="fd:ExtraCover" presence="true" />
<wsvl:serviceElementRef ref="tns:getQuote4Business-
</wsvl:link>
<wsvl:link name="LAccidentalDamage">
<wsvl:featureRef ref="fd:AccidentalDamage" presence="true"
/>
<wsvl:serviceElementRef ref="tns:addAccidentalDamage"
</wsvl:link>
<wsvl:link name="LExtendedThirdPartyLiability">
<wsvl:featureRef ref="fd:ExtendedThirdPartyLiability"
presence="true" />
<wsvl:serviceElementRef ref="tns:addExtendedThirdParty-
Liability" target="operation" />
</wsvl:link>
<wsvl:link name="LFusionCover">
<wsvl:featureRef ref="fd:FusionCover" presence="true" />
<wsvl:serviceElementRef ref="tns:addFusionCover" tar-
get="operation" />
</wsvl:link>
<wsvl:link name="LPurchase">
<wsvl:featureRef ref="fd:Purchase" presence="true" />
<wsvl:serviceElementRef ref="tns:purchasingPortType"
target="portType" />
</wsvl:link>
<wsvl:link name="LCreditCard">
<wsvl:featureRef ref="fd:CreditCard" presence="true" />
<wsvl:serviceElementRef ref="tns:purchasePolicyBy-
CreditCard" target="operation" />
</wsvl:link>
<wsvl:link name="LCoverNote">
<wsvl:featureRef ref="fd:CoverNote" presence="true" />
<wsvl:serviceElementRef ref="tns:purchasePolicyBy-
CoverNote" target="operation" />
</wsvl:link>
</wsvl:mappingInfo>

<wsvl:portType name="customisationPortType">
<wsvl:operation name="customisationOperation">
<wsdl:input message="tns:customisationOperationRequest"/>
<wsdl:output message="tns:customisationOperation-
Response"/>
<wsdl:fault name="customisationOperationFault" message="-
tns:customisationOperationFault"/>
</wsvl:operation>
</wsvl:portType>

<wsvl:binding name="swinsureBinding" type="tns:customisation-
PortType">
<soap:binding style="document" transport="http://schemas.x-
mlsoap.org/soap/http" />
228
<wsvl:operation name="customisationOperation">
<soap:operation soapAction="http://www.swin.edu/au/s-
cf/swinsure/customisationOperation" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
<wsdl:fault>
<soap:fault name="fault" use="literal" />
</wsdl:fault>
</wsvl:operation>
</wsvl:binding>

<wsdl:types>
<xsd:schema targetNamespace="http://swinsure.scf.swin.e-
du.au/">
<xsd:element name="customisationOperationRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="enabledFeatureList"
type="xsd:string">
</xsd:element>
<xsd:element name="disabledFeatureList"
type="xsd:string">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="customisationOperationResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="wsdlURI" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="customisationOperationFault">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="errorCode" type="xsd:int"/>
<xsd:element name="errorMessage" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="viewPolicy">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="referenceNumber"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="viewPolicyResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="policyDetail" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
229
</xsd:element>
<xsd:element name="updatePolicy">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
<xsd:element name="newPolicyDetail"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="updatePolicyResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="policyDetail" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4Residential">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="dateOfBirth" type="xsd:date"/>
<xsd:element name="claimHistory" type="xsd:int"/>
<xsd:element name="address" type="xsd:string"/>
<xsd:element name="buildingType"
type="tns:BuildingType"/>
<xsd:element name="exteriorWall"
type="tns:ExteriorWallType"/>
<xsd:element name="occupancyType"
type="tns:OccupancyType"/>
<xsd:element name="replacementValue"
type="xsd:long"/>
<xsd:element name="excess" type="tns:ExcessValue"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4ResidentialResponse">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
<xsd:element name="annualAmount" type="xsd:double"/>
<xsd:element name="monthlyInstallment"
type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4ResidentialWithExtra">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="dateOfBirth" type="xsd:date"/>
230
type="xsd:long"/>
<xsd:element name="excess"
type="tns:ExcessValue4ExtraCover"/>
<xsd:element name="extraCover" type="xsd:boolean"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4ResidentialWithExtraResponse">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4Business">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="businessName" type="xsd:string"/>
<xsd:element name="customerVisit"
type="xsd:boolean"/>
type="xsd:long"/>
<xsd:element name="excess" type="tns:ExcessValue"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4BusinessResponse">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4BusinessWithExtra">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="businessName" type="xsd:string"/>
<xsd:element name="customerVisit"
type="xsd:boolean"/>
231
type="xsd:long"/>
<xsd:element name="extraCover" type="xsd:boolean"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getQuote4BusinessWithExtraResponse">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="addAccidentalDamage">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="addAccidentalDamageResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="info" type="xsd:string"/>
type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="addFusionCover">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="addFusionCoverResponse">
<xsd:complexType>
<xsd:sequence>
232
type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="addExtendedThirdPartyLiability">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="addExtendedThirdPartyLiability-
Response">
<xsd:complexType>
<xsd:sequence>
type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="purchasePolicyByCreditCard">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
<xsd:element name="creditCardName"
type="xsd:string"/>
<xsd:element name="creditCardNumber"
type="xsd:string"/>
<xsd:element name="expireDate" type="xsd:date"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="purchasePolicyByCreditCardResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="purchasePolicyByCoverNote">
<xsd:complexType>
<xsd:sequence>
type="xsd:string"/>
<xsd:element name="postalAddress"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="purchasePolicyByCoverNoteResponse">
233
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:simpleType name="BuildingType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="House"/>
<xsd:enumeration value="Unit"/>
<xsd:enumeration value="Other"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="ExteriorWallType">
<xsd:enumeration value="SolidMasonry"/>
<xsd:enumeration value="BrickVeneer"/>
<xsd:enumeration value="Timber"/>
<xsd:enumeration value="Other"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="OccupancyType">
<xsd:enumeration value="Owner"/>
<xsd:enumeration value="Tenant"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="ExcessValue">
<xsd:restriction base="xsd:int">
<xsd:enumeration value="200"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="ExcessValue4ExtraCover">
<xsd:restriction base="xsd:int">
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>

<wsdl:message name="CustomisationOperationFault">
<wsdl:part element="tns:customisationOperationFault"
name="parameters"/>
</wsdl:message>
<wsdl:message name="customisationOperationResponse">
<wsdl:part element="tns:customisationOperationResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="customisationOperationRequest">
234
<wsdl:part element="tns:customisationOperationRequest"
name="parameters"/>
</wsdl:message>
<wsdl:message name="viewPolicyRequest">
<wsdl:part element="tns:viewPolicy" name="parameters"/>
</wsdl:message>
<wsdl:message name="viewPolicyResponse">
<wsdl:part element="tns:viewPolicyResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="updatePolicyRequest">
<wsdl:part name="parameters" element="tns:updatePolicy"/>
</wsdl:message>
<wsdl:message name="updatePolicyResponse">
<wsdl:part name="parameters" element="tns:updatePolicy-
Response"/>
</wsdl:message>
<wsdl:message name="getQuote4ResidentialRequest">
<wsdl:part name="parameters" element="tns:getQuote4-
Residential"/>
</wsdl:message>
<wsdl:message name="getQuote4ResidentialResponse">
ResidentialResponse"/>
</wsdl:message>
<wsdl:message name="getQuote4ResidentialWithExtraRequest">
ResidentialWithExtra"/>
</wsdl:message>
<wsdl:message name="getQuote4ResidentialWithExtraResponse">
ResidentialWithExtraResponse"/>
</wsdl:message>
<wsdl:message name="getQuote4BusinessRequest">
Business"/>
</wsdl:message>
<wsdl:message name="getQuote4BusinessResponse">
BusinessResponse"/>
</wsdl:message>
<wsdl:message name="getQuote4BusinessWithExtraRequest">
BusinessWithExtra"/>
</wsdl:message>
<wsdl:message name="getQuote4BusinessWithExtraResponse">
BusinessWithExtraResponse"/>
</wsdl:message>
<wsdl:message name="addAccidentalDamageRequest">
<wsdl:part name="parameters" element="tns:addAccidental-
Damage"/>
</wsdl:message>
<wsdl:message name="addAccidentalDamageResponse">
<wsdl:part name="parameters" element="tns:addAccidental-
DamageResponse"/>
</wsdl:message>
<wsdl:message name="addFusionCoverRequest">
<wsdl:part name="parameters" element="tns:addFusionCover"/>
235
</wsdl:message>
<wsdl:message name="addFusionCoverResponse">
<wsdl:part name="parameters" element="tns:addFusionCover-
Response"/>
</wsdl:message>
<wsdl:message name="addExtendedThirdPartyLiabilityRequest">
<wsdl:part name="parameters" element="tns:addExtendedThird-
PartyLiability"/>
</wsdl:message>
<wsdl:message name="addExtendedThirdPartyLiabilityResponse">
<wsdl:part name="parameters" element="tns:addExtendedThird-
PartyLiabilityResponse"/>
</wsdl:message>
<wsdl:message name="purchasePolicyByCreditCardRequest">
<wsdl:part name="parameters" element="tns:purchasePolicy-
ByCreditCard"/>
</wsdl:message>
<wsdl:message name="purchasePolicyByCreditCardResponse">
ByCreditCardResponse"/>
</wsdl:message>
<wsdl:message name="purchasePolicyByCoverNoteRequest">
ByCoverNote"/>
</wsdl:message>
<wsdl:message name="purchasePolicyByCoverNoteResponse">
ByCoverNoteResponse"/>
</wsdl:message>

<wsdl:operation name="viewPolicy">
<wsdl:input message="tns:viewPolicyRequest"/>
<wsdl:output message="tns:viewPolicyResponse"/>
</wsdl:operation>
<wsdl:operation name="updatePolicy">
<wsdl:input message="tns:updatePolicyRequest"/>
<wsdl:output message="tns:updatePolicyResponse"/>
</wsdl:operation>
<wsdl:operation name="getQuote4Residential">
<wsdl:input message="tns:getQuote4ResidentialRequest"/>
<wsdl:output message="tns:getQuote4ResidentialResponse"/>
</wsdl:operation>
<wsdl:operation name="getQuote4ResidentialWithExtra">
<wsdl:input message="tns:getQuote4ResidentialWith-
ExtraRequest"/>
<wsdl:output message="tns:getQuote4ResidentialWith-
ExtraResponse"/>
</wsdl:operation>
<wsdl:operation name="getQuote4Business">
<wsdl:input message="tns:getQuote4BusinessRequest"/>
<wsdl:output message="tns:getQuote4BusinessResponse"/>
</wsdl:operation>
<wsdl:operation name="getQuote4BusinessWithExtra">
<wsdl:input message="tns:getQuote4BusinessWith-
ExtraRequest"/>
<wsdl:output message="tns:getQuote4BusinessWith-
ExtraResponse"/>
</wsdl:operation>
236
<wsdl:operation name="addAccidentalDamage">
<wsdl:input message="tns:addAccidentalDamageRequest"/>
<wsdl:output message="tns:addAccidentalDamageResponse"/>
</wsdl:operation>
<wsdl:operation name="addFusionCover">
<wsdl:input message="tns:addFusionCoverRequest"/>
<wsdl:output message="tns:addFusionCoverResponse"/>
</wsdl:operation>
<wsdl:operation name="addExtendedThirdPartyLiability">
<wsdl:input message="tns:addExtendedThirdParty-
LiabilityRequest"/>
<wsdl:output message="tns:addExtendedThirdParty-
LiabilityResponse"/>
</wsdl:operation>
</wsdl:portType>

<wsdl:portType name="purchasingPortType">
<wsdl:operation name="purchasePolicyByCreditCard">
<wsdl:input message="tns:purchasePolicyBy-
CreditCardRequest"/>
<wsdl:output message="tns:purchasePolicyBy-
CreditCardResponse"/>
</wsdl:operation>
<wsdl:operation name="purchasePolicyByCoverNote">
<wsdl:input message="tns:purchasePolicyBy-
CoverNoteRequest"/>
<wsdl:output message="tns:purchasePolicyBy-
CoverNoteResponse"/>
</wsdl:operation>
</wsdl:portType>

<wsdl:service name="swinsureWebService">
<wsvl:port binding="tns:swinsureBinding"
name="swinsurePort">
<soap:address location="http://ec2-107-21-175-19.compute-
1.amazonaws.com:8080/swinsureCustomizationFrontend" />
</wsvl:port>
</wsdl:service>

</wsdl:definitions>

237

Appendix C: VBPMN Metamodel

239

Appendix D: Glossary

A

Application artefact Software artefacts which is specific to one product and is
produced during the application engineering process. In SPL,
application artefacts are resulted from resolving variability in
domain artefacts with or without further product specific
development
Application engineer-
ing process
One of two processes for software development in SPL. The
application engineering process focuses on the derivation and
development of particular products from reusable assets of
SPL. The other process is Domain engineering process
Atomic service A Web service which does not invoke other Web services
Automated analysis A set of operations for analysing and reasoning over a feature
model (e.g. whether a feature model is valid, or whether a
feature configuration is valid with respect to a feature model)
Automated variability
instantiation
The use of techniques such as model transformations to
automatically derive particular products from reusable assets
in a SPL
C

CBFM Cardinality-Based Feature Modeling
Composite service A Web service which invokes other Web services
Composition variabil-
ity
Variability in the service implementation
Configurable artefact Configurable domain artefact
Configurable service
implementation
Refers to either a component of the service provisioning
architecture or software artefacts used for the component
Consumption message A message, which is generally a SOAP message, exchanged
in the consumption mode
Consumption mode One of two operation modes of a customisable service.
During this mode, a service consumer has access to one
service variant and is able to consume the service variant. The
other mode is customisation mode

A service that incorporates mechanisms for service consumers
to customise service capabilities and derive particular service
variants
240
Customisation contract a WSVL description of a customisable service
Customisation end-
point description
WSVL description customisation endpoint
Customisation message A message, which is generally a SOAP message, exchanged
in the customisation mode
Customisation mode One of two operation modes of customisable services. During
this mode, service consumers comprehend customisation
options and perform service customisation. The other mode is
consumption mode
Customisation opera-
tion
A service operation that accepts a customisation request and
returns a customisation response
Customisation opera-
tions description
WSVL description customisation operations
(Valid) Customisation
request
A customisation message which is created by a service
consumer and contains a set of selected features and a set of
disabled features (i.e. a feature configuration)
Complete ~ A customisation request which contains a complete feature
configuration
Inferred ~ A customisation request which is inferred from an original
customisation request by analysing restrictions defined in a
feature model to add more feature(s) to either the selected
feature set or the disabled feature set or both
Normalised ~ A customisation request resulted from an original customisa-
tion request by removing all mandatory features from the
selected feature set
Optimised ~ The most complete and most compact form of a customisa-
tion request which is both semantically equivalent to the
original customisation request and cannot be further inferred
or normalised
Partial ~ A customisation request which contains a partial feature
configuration
Customisation re-
sponse
A customisation message produced by a service provider as
the result of service customisation. A customisation response
generally contain information about the WSDL description of
a determined service variant or the WSVL description of a
refined customisable service

D

241
Dependencies descrip-
tion
The capturing of variability dependencies
Determined service
variant
A service variant resulted from customising a service with a
complete customisation request
Domain artefact Reusable software artefacts created during the domain
engineering process
Domain engineering
process
One of two processes for software development in SPL. The
domain engineering process focuses on the development of
reusable assets for a SPL. The other process is Application
engineering process.
Dynamic service
customisation
The customisation of a service and the derivation of a service
variant at runtime
E

Exposed variability Variability in the service interface
External variability Variability in a SPL that is visible to consumers
F

Feature cardinality The lower bound and the upper bound for a feature to appear
in one feature configuration
Feature configuration A set of selected variant features and a set of disabled variant
features. Feature configurations completely or partially
resolve variability within a feature model
Complete ~ A feature configuration which is resulted from a complete
resolution of variability in a feature model
Partial ~ A feature configuration which is resulted from a partial
resolution of variability in a feature model
Feature constraint An exclude/require relationship between two features across
the feature tree
Feature group A group of features (aka. grouped features) which are
associated with one parent feature and a group cardinality
FeatureMapping
annotation
Our extension of JAX-WS for addressing variability in the
service skeleton
Feature mapping
description
WSVL description - feature mapping
Feature model A hierarchical structure of features with cross-tree constraints
for capturing variability at the requirement level
242
Full service capability
(description)
See service capability description
G

Group cardinality The lower bound and the upper bound of the number of child
features to be included in one feature configuration when the
parent feature is selected.
Grouped feature A variant feature which belongs to one feature group
I

Internal variability Variability in a SPL that is the concern for only the SPL
provider
M

Mandatory feature A feature which appears in all feature configurations
O

Optional feature A variant feature whose feature cardinality is [0-1]
P

Partner exposed
variability
Exposed variability of a partner service
Partner variability Variability in the interaction between a composite service and
partner services.
Partner variant feature Variant features in the feature model of a partner service
Presence condition A propositional formula of variant features to specify the
availability of a a software variant in a service variant. It is
expressed as If the variant features A1, A2,, An are
selected and the variant features B1, B2,, Bm are disabled,
this variant capability is available.
Product derivation The resolution of variability in reusable assets of a SPL to
produce software artefacts specific to one product
R

Recursive service
customisation
A situation when the customisation of a composite service
requires the customisation of partner services, recursively
243
Refinement relation-
ship
The relationship between variability at a level of abstraction
and variability at a lower level of abstraction. In any software
system, variability is step-wise expanded from the require-
ment level, through the architectural level, to the
implementation level
Refined customisable
service
The result of customising a service with a partial customisa-
tion request
Runtime customisation
and management
engine
A component of the service provisioning architecture which is
responsible for the dynamic derivation and deployment of
service variants
Runtime engine A short expression for runtime customisation and manage-
ment engine
S

Service capability
description
WSVL description - service capability
Service customisation
function
One of three functions performed by a customisable service.
This function allows service consumers to customise the
service and derive service variants. The other two functions
are variability communication function and variant provision-
ing function
Service variability The ability of a service to incorporate multiple service
variants in its capability
Service variability
reuse
The use of the service variability provided by a partner
service in modeling variability in a composite service
Service variant A variation of a service that contains specific service capabili-
ties matching requirements of a particular service consumer
Service variant deriva-
tion
The generation of service variants by resolving variability in
the implementation of a service
Software variability The ability of a software system to be efficiently extended,
changed, customized or configured for use in a particular
context
Software variant Variant in domain artefacts
Staged instantiation Variability is resolved at the highest level of abstraction and
is automatically propagated to the resolve variability at the
lower levels of abstraction by exploiting the refinement
relationships
V

244
Variability
~ capturing see variability modeling
~ communication A mechanism for describing and exchanging variability
information between service providers and service consumers
in order to facilitate the modeling and instantiation of varia-
bility at the service consumer side, as well as propagating the
consequence of variability instantiation toward the service
provider
~ constraint See variability dependencies
~ dependencies exclude or require relations when binding variants to varia-
tion points
~ information Information related to variability such as information about
variation points, variants and variability dependencies
~ instantiation See variability resolution
~ instantiation
decisions
See variability resolution decisions
~ inter-dependencies Variability dependencies between composition variability and
partner variability
~ intra-dependencies Variability dependencies within composition variability
~ mechanism See variability realisation
~ management A set of activities for explicitly representing variability in
software artifacts throughout the lifecycle, managing depend-
ences among different variabilities, and supporting the
instantiation of the variabilities
~ modeling The introduction of variability (or variation points and
variants) and the capturing of variability dependencies
~ propagation The propagation of variability resolution decisions from a
level of abstraction to lower levels of abstraction based on
refinement relationships
~ realisation The introduction of variation points and variants in imple-
mentation artefacts (e.g. source code)
~ realisation tech-
nique
A technique for variability realisation
~ representation The identification and introduction of variation points and
variants
245
~ resolution The binding of appropriate software variants to variation
points in software artefacts
~ resolution decision A specific way of binding software variants to variation
points
Variability communi-
cation function
This function enables the specification and exchange of
service variability information (i.e. a WSVL description). The
other two functions are service customisation function and
variant provisioning function
Variant A generic term used to refer to a variation which can be
bound to a variation point when variability is resolved
Variant provisioning
function
This function allows a service consumer to access to and
consume a particular service variant as the result of service
customisation. The other two functions are variability
communication function and service customisation function
Variant feature A feature which might be included in or excluded from a
feature configuration depending on service consumers
selection
Variant service capa-
bility
A service capability (i.e. portType, operation, data types)
which only exists in a number of service variants
Variation point A generic term used to refer to a location in software artefacts
where variation might occur
VBPMN Variability-enabled BPMN is our extension of BPMN
metamodel for introducing variation points and variants in
BPMN process models
VBPMN model See VBPMN process model
VBPMN process model A process model instantiated from VBPMN metamodel
W

Web Service Context A concept in JAX-WS for representing runtime service
context
WSVL Web Service Variability description Language is our exten-
sion of WSDL for describing the service interface of
customisable services
WSVL description The WSVL-based service interface description of a customis-
able service
246
~ customisation
endpoint
One part of a WSVL description that stores abstract and
concrete definitions of customisation operations
~ customisation
options
One part of a WSVL description that stores information about
a feature model
~ feature mapping One part of a WSVL description that describes the mapping
between variant features and variant service capabilities
~ service capability One part of a WSVL description that defines the superset of
abstract service capability for all service variants

247

References
Adam, S. and Doerr, J. (2008). The Role of Service Abstraction and Service Variability
and Its Impact on Requirements Engineering for Service-Oriented Systems. 32nd
Annual IEEE International on Computer Software and Applications
(COMPSAC).
Amazon. (2013). "Amazon Web Service (AWS)." Retrieved 19 May 2013, from
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html.
Antkiewicz, M. and Czarnecki, K. (2004). FeaturePlugin: feature modeling plug-in for
Eclipse. The 2004 OOPSLA Workshop on Eclipse Technology eXchange,
Vancouver, British Columbia, Canada, ACM.
Apache. (2012). "Apache CXF." Retrieved 19 May 2013, from http://cxf.apache.org/.
Asikainen, T., Soininen, T. and Mnnist, T. (2004). A Koala-Based Approach for
Modelling and Deploying Configurable Software Product Families. Software
Product-Family Engineering: 225-249.
Babar, M. A., Chen, L. and Shull, F. (2010). "Managing Variability in Software Product
Lines." IEEE Software 27(3): 89-91, 94.
Bachmann, F., Goedicke, M., Leite, J., et al. (2004). A Meta-model for Representing
Variability in Product Family Development. Software Product Family
Engineering: 66-80.
Balani, N. and Hathi, R. (2009). Apache CXF Web Service Development, Packt
Publishing.
Baresi, L. and Guinea, S. (2007). Dynamo and Self-Healing BPEL Compositions. 29th
International Conference on Software Engineering (ICSE) - Companion
Baresi, L. and Guinea, S. (2011). "Self-Supervising BPEL Processes." IEEE Transactions
on Software Engineering 37(2): 247-263.
Baresi, L., Guinea, S. and Pasquale, L. (2012). "Service-Oriented Dynamic Software
Product Lines with DyBPEL." Computer 45(10): 42-48.
Barros, A., Decker, G. and Grosskopf, A. (2007). Complex Events in Business Processes.
Business Information Systems. W. Abramowicz, Springer Berlin / Heidelberg.
4439: 29-40.
Barros, A., Allgaier, M., Charfi, A., et al. (2011). Diversified Service Provisioning in
Global Business Networks. Annual SRII Global Conference.
Barros, A. P. and Dumas, M. (2006). "The Rise of Web Service Ecosystems." IT
Professional 8(5): 31-37.
Batory, D. (2005). Feature Models, Grammars, and Propositional Formulas. Software
Product Lines. H. Obbink and K. Pohl, Springer / Heidelberg. 3714: 7-20.
Batory, D., Benavides, D. and Ruiz-Cortes, A. (2006). "Automated analysis of feature
models: challenges ahead." Communications of the ACM 49(12): 45-47.
Bayer, J., Gerard, S., Haugen, ., et al. (2006). Consolidated Product Line Variability
Modeling. Software Product Lines: 195-241.
Becker, M. (2003). Towards a General Model of Variability in Product Families.
Proceedings of the 1st Workshop on Software Variability Management,
Groningen, Netherlands.
Benavides, D., Trujillo, S. and Trinidad, P. (2005). On the Modularization of Feature
Models. 1st European Workshop on Model Transformation.
Benavides, D., Segura, S., Trinidad, P., et al. (2006). "A first step towards a framework
for the automated analysis of feature models."
Benavides, D., Segura, S. and Ruiz-Corts, A. (2010). "Automated analysis of feature
models 20 years later: A literature review." Information Systems 35(6): 615-636.
Benavides, D., Duarte, J. A. G., Galn, J. G., et al. (2012). "FeAture Model Analyser
(FAMA) framework." Retrieved 19 May 2013, from http://www.isa.us.es/fama/.
References
248
Berre, D. L. (2013). "Sat4j." Retrieved 19 May 2013, from http://www.sat4j.org/.
Bosch, J. (1999). "Superimposition: a component adaptation technique." Information and
Software Technology 41(5): 257-273.
Bosch, J. (2009). From software product lines to software ecosystems. Proceedings of the
13th International Software Product Line Conference. San Francisco, California,
Carnegie Mellon University.
Bosch, J. and Capilla, R. (2012). "Dynamic Variability in Software-Intensive Embedded
System Families." Computer 45(10): 28-35.
Bosch, J. and Capilla, R. (2012). "From Static to Dynamic and Extensible Variability in
Software-Intensive Embedded System Families." Computer PP(99): 1-1.
Capilla, R. and Bosch, J. (2011). "The Promise and Challenge of Runtime Variability."
Computer 44(12): 93-95.
Cardellini, V., Colajanni, M. and Yu, P. S. (1999). "Dynamic load balancing on Web-
server systems." Internet Computing, IEEE 3(3): 28-39.
Cechticky, V., Pasetti, A., Rohlik, O., et al. (2004). XML-Based Feature Modelling.
Software Reuse: Methods, Techniques and Tools: 101-114.
Cetina, C., Giner, P., Fons, J., et al. (2009). "Autonomic Computing through Reuse of
Variability Models at Runtime: The Case of Smart Homes." Computer 42(10):
37-43.
Chang, S. H. and Kim, S. D. (2007). A Variability Modeling Method for Adaptable
Services in Service-Oriented Computing. International Software Product Line
Conference, IEEE Computer Society.
Chappell, D. (2004). Enterprise Service Bus, O'Reilly Media, Inc.
Charfi, A. and Mezini, M. (2004). Hybrid web service composition: business processes
meet business rules. Proceedings of the 2nd International Conference on Service
Oriented Computing (ICSOC). New York, NY, USA, ACM.
Charfi, A. and Mezini, M. (2007). "AO4BPEL: An Aspect-oriented Extension to BPEL."
World Wide Web 10(3): 309-344.
Charfi, A., Mller, H. and Mezini, M. (2010). Aspect-Oriented Business Process
Modeling with AO4BPMN. Modelling Foundations and Applications. T. Khne,
B. Selic, M.-P. Gervais and F. Terrier, Springer Berlin / Heidelberg. 6138: 48-61.
Chastek, G., Ferber, S., Haag, J., et al. (2002). Feature Interaction and Dependencies:
Modeling Features for Reengineering a Legacy Product Line. Software Product
Lines, Springer Berlin / Heidelberg. 2379: 37-60.
Chen, L., Babar, M. A. and Ali, N. (2009). Variability management in software product
lines: a systematic review. Proceedings of the 13th International Software
Product Line Conference. San Francisco, California, Carnegie Mellon University.
Chen, L., Triantafillou, P., Suel, T., et al. (2010). Model-Driven Development of Adaptive
Service-Based Systems with Aspects and Rules. Web Information Systems
Engineering (WISE), Springer Berlin / Heidelberg. 6488: 548-563.
Christensen, E., Curbera, F., Meredith, G., et al. (2001). "Web Services Description
Language (WSDL) Version 1.1." Retrieved 19 May 2013, from
http://www.w3.org/TR/wsdl.
Cohen, S. and Krut, R. (2010). Managing Variation in Services in a Software Product
Line Context. Technical Report, CMU/SEI-2010-TN-007, Software Engineering
Institute, Carnegie Mellon University.
Czarnecki, K. (2005a). Overview of Generative Software Development. Unconventional
Programming Paradigms. J.-P. Banatre, P. Fradet, J.-L. Giavitto and O. Michel,
Springer. 3566: 313-328.
Czarnecki, K. and Antkiewicz, M. (2005b). Mapping Features to Models: A Template
Approach Based on Superimposed Variants. Generative Programming and
Component Engineering. R. Gluck and M. Lowry. 3676: 422-437.
References
249
Czarnecki, K., Helsen, S. and Eisenecker, U. (2005c). "Formalizing cardinality-based
feature models and their specialization." Software Process: Improvement and
Practice 10(1): 7-29.
Czarnecki, K., Helsen, S. and Eisenecker, U. (2005d). "Staged configuration through
specialization and multi-level configuration of feature models." Software Process
Improvement and Practice 10(2): 143-169.
Czarnecki, K. and Kim, C. H. P. (2005e). Cardinality-based feature modeling and
constraints - a progress report. Proceedings of International Workshop on
Software Factories, OOPSLA, San Diego, USA.
Dawson, D., Desmarais, R., Kienle, H. M., et al. (2008). Monitoring in adaptive systems
using reflection. International Workshop on Software Enginerring for Adaptive
and Self-Managing Systems (SEAMS), Leipzig, Germany, ACM.
Didonet, M., Fabro, D., Bzivin, J., et al. (2006). Weaving Models with the Eclipse AMW
plugin. Eclipse Modeling Symposium, Eclipse Summit Europe.
Eclipse. (2012a). "Eclipse Graphical Modeling Framework (GMF)." Retrieved 19 May
2013, from http://www.eclipse.org/modeling/gmp/.
Eclipse. (2012b). "Eclipse Modeling Framework (EMF)." Retrieved 19 May 2013, from
http://eclipse.org/modeling/emf/.
En, N. and Srensson, N. (2004). An Extensible SAT-solver. Theory and Applications of
Satisfiability Testing. E. Giunchiglia and A. Tacchella, Springer Berlin /
Heidelberg. 2919: 333-336.
Fan, S. and Zhang, N. (2006). Feature model based on description logics. Knowledge-
Based Intelligent Information and Engineering Systems, Springer.
Galster, M. and Eberlein, A. (2011). Identifying Potential Core Assets in Service-Based
Systems to Support the Transition to Service-Oriented Product Lines. 18th IEEE
International Conference and Workshops on Engineering of Computer Based
Systems (ECBS).
Gamma, E., Helm, R., Johnson, R., et al. (1995). Design patterns: elements of reusable
object-oriented software, Addison-Wesley Longman Publishing Co., Inc.
Ghaddar, A., Tamzalit, D., Assaf, A., et al. (2012). Variability as a Service: Outsourcing
Variability Management in Multi-tenant SaaS Applications. Advanced
Information Systems Engineering. J. Ralyt, X. Franch, S. Brinkkemper and S.
Wrycza, Springer Berlin / Heidelberg. 7328: 175-189.
Gottschalk, F., van der Aalst, W., Jansen-Vullers, M., et al. (2008). "Configurable
Workflow Models." International Journal of Cooperative Information Systems
17(02): 177.
Griss, M. L., Favaro, J. and Alessandro, M. d. (1998). Integrating Feature Modeling with
the RSEB. International Conference on Software Reuse, IEEE Computer Society.
Groefsema, H., Bulanov, P. and Aiello, M. (2011). Declarative Enhancement Framework
for Business Processes. Service-Oriented Computing. G. Kappel, Z. Maamar and
H. Motahari-Nezhad, Springer Berlin / Heidelberg. 7084: 495-504.
Gurp, J. V., Bosch, J. and Svahnberg, M. (2001). On the Notion of Variability in Software
Product Lines. Proceedings of the Working IEEE/IFIP Conference on Software
Architecture, IEEE Computer Society.
Hadaytullah, Koskimies, K. and Systa, T. (2009). Using Model Customization for
Variability Management in Service Compositions. IEEE International Conference
on Web Services (ICWS).
Hallerbach, A., Bauer, T. and Reichert, M. (2009). Guaranteeing Soundness of
Configurable Process Variants in Provop. IEEE Conference on Commerce and
Enterprise Computing (CEC).
Hallerbach, A., Bauer, T. and Reichert, M. (2010). "Capturing variability in business
process models: the Provop approach." Software Maintenance and Evolution:
Research and Practice 22(6-7): 519-546.
References
250
Halmans, G. and Pohl, K. (2003). "Communicating the variability of a software-product
family to customers." Software and Systems Modeling 2(1): 15-36.
Hans Weigand, W.-J. v. d. H., Marcel Hiel (2008). Rule-Based Service Composition and
Service-Oriented Business Rule Management. Interdisciplinary Workshop on
Regulations Modelling and Deployment, Montpellier, France.
Hermosillo, G., Seinturier, L. and Duchien, L. (2010). Creating Context-Adaptive
Business Processes. Service-Oriented Computing. P. Maglio, M. Weske, J. Yang
and M. Fantinato, Springer Berlin, Heidelberg. 6470: 228-242.
Jaejoon Lee, D. M., Matthias Naab, Minseong Kim, Sooyong Park (2007). Identifying
and Specifying Reusable Services of Service Centric Systems Through Product
Line Technology. Proceedings of the first Workshop on Service Oriented
Architecture and Product Lines (SOAPL).
Jaroucheh, Z., Liu, X. and Smith, S. (2010). Apto: A MDD-Based Generic Framework for
Context-Aware Deeply Adaptive Service-Based Processes. IEEE International
Conference on Web Services (ICWS).
Jarzabek, S. and Zhang, H. (2001). XML-Based Method and Tool for Handling Variant
Requirements in Domain Models. Proceedings of the Fifth IEEE International
Symposium on Requirements Engineering, IEEE Computer Society: 166.
Jiang, J., Ruokonen, A. and Systa, T. (2005). Pattern-based Variability Management in
Web Service Development. Proceedings of the Third European Conference on
Web Services, IEEE Computer Society.
Jing, S., Hongyu, Z., Yuan, F., et al. (2005). Formal semantics and verification for
feature modeling. Engineering of Complex Computer Systems, 2005. ICECCS
2005. Proceedings. 10th IEEE International Conference on.
Jordan, D. and Evdemon, J. (2007). "Web Services Business Process Execution Language
(WS-BPEL) Version 2.0." Retrieved 19 May 2013, from http://docs.oasis-
open.org/wsbpel/2.0/wsbpel-v2.0.html.
Jouault, F., Allilaire, F., Bzivin, J., et al. (2008). "ATL: A model transformation tool."
Science of Computer Programming 72(1-2): 31-39.
Juse, K. S., Kounev, S., Buchmann, A., et al. (2003). PetStore-WS: Measuring the
Performance Implications of Web Services. Proceedings of the International
Conference of the Computer measurement Group.
Kang, K. C., Cohen, S. G., Hess, J. A., et al. (1990). Feature-Oriented Domain Analysis
(FODA) Feasibility Study. Technical Report. Pennsylvania, Software
Engineering Institute, CMU: 161.
Kang, K. C., Kim, S., Lee, J., et al. (1998). "FORM: A feature-oriented reuse method
with domain-specific reference architectures." Annals of Software Engineering
5(1): 143-168.
Kang, K. C., Jaejoon, L. and Donohoe, P. (2002). "Feature-oriented product line
engineering." Software 19(4): 58-65.
Kapuruge, M., Han, J. and Colman, A. (2010). Support for Business Process Flexibility in
Service Compositions: An Evaluative Survey. 21st Australian Software
Engineering Conference (ASWEC).
Koning, M., Sun, C.-a., Sinnema, M., et al. (2009). "VxBPEL: Supporting variability for
Web services in BPEL." Information and Software Technology 51(2): 258-269.
Kotamraju, J. (2009). "The Java API for XML-Based Web Services (JAX-WS) 2.2."
Retrieved 19 May 2013, from http://jcp.org/jsr/detail/224.jsp.
La Rosa, M., Dumas, M., ter Hofstede, A. H. M., et al. (2011). "Configurable multi-
perspective business process models." Information Systems 36(2): 313-340.
Lee, J. and Muthig, D. (2006). "Feature-oriented variability management in product line
engineering." Communication of the ACM 49(12): 55-59.
References
251
Lee, K., Kang, K. and Lee, J. (2002). Concepts and Guidelines of Feature Modeling for
Product Line Software Engineering. Software Reuse: Methods, Techniques, and
Tools: 62-77.
Liang, H., Sun, W., Zhang, X., et al. (2006). A Policy Framework for Collaborative Web
Service Customization. IEEE International Symposium on Service-Oriented
System Engineering, IEEE Computer Society.
Liu, H. (2012). "Amazon data center size." Retrieved 19 May 2013, from
http://huanliu.wordpress.com/2012/03/13/amazon-data-center-size/.
Lnn, C.-M., Uppstrm, E., Wohed, P., et al. (2012). Configurable Process Models for
the Swedish Public Sector. Advanced Information Systems Engineering. J.
Ralyt, X. Franch, S. Brinkkemper and S. Wrycza, Springer Berlin / Heidelberg.
7328: 190-205.
Machado, I., Bonifacio, R., Alves, V., et al. (2011). Managing variability in business
processes: an aspect-oriented approach. International Workshop on Early
Aspects, Porto de Galinhas, Brazil, ACM.
Mahdavi-Hezavehi, S., Galster, M. and Avgeriou, P. (2012). "Variability in quality
attributes of service-based software systems: a systematic literature review."
Information and Software Technology(0).
Marcos, E., Castro, V. d. and Vela, B. (2003). Representing Web Services with UML: A
Case Study. Service Oriented Computing. M. E. Orlowska, S. Weerawarana, M.
P. Papazoglou and J. Yang, Springer. 2910: 17-27.
Mari, F. (2009). "Formalization and Implementation of Modern SAT Solvers." Journal of
Automated Reasoning 43(1): 81-119.
Masamitsu, J. (2006). "Presenting the permanent generation." Retrieved 19 May 2013,
from
https://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generat
ion.
McGregor, J. D., Northrop, L. M., Jarrad, S., et al. (2002). "Initiating software product
lines." IEEE Software 19(4): 24-27.
Mendona, M., Cowan, D., Malyk, W., et al. (2008). "Collaborative Product
Configuration: Formalization and Efficient Algorithms for Dependency
Analysis." Journal of Software 3(2): 69-82.
Mietzner, R. (2008a). Using Variability Descriptors to Describe Customizable SaaS
Application Templates. Technical Report 2008/01, University of Stuttgart.
Mietzner, R. and Leymann, F. (2008b). Generation of BPEL Customization Processes for
SaaS Applications from Variability Descriptors. IEEE International Conference
on Services Computing (SCC).
Mietzner, R., Metzger, A., Leymann, F., et al. (2009). Variability modeling to support
customization and deployment of multi-tenant-aware Software as a Service
applications. Proceedings of the 2009 ICSE Workshop on Principles of
Engineering Service Oriented Systems, IEEE Computer Society.
Mohabbati, B., Gaevi, D., Hatala, M., et al. (2011). A Quality Aggregation Model for
Service-Oriented Software Product Lines Based on Variability and Composition
Patterns. Service-Oriented Computing. G. Kappel, Z. Maamar and H. Motahari-
Nezhad, Springer Berlin / Heidelberg. 7084: 436-451.
Montangero, C., Reiff-Marganiec, S. and Semini, L. (2011). Model-Driven Development
of Adaptable Service-Oriented Business Processes. Rigorous Software
Engineering for Service-Oriented Systems. M. Wirsing and M. Hlzl, Springer
Berlin / Heidelberg. 6582: 115-132.
Moustafa, A. and Zhang, M. (2012). Towards Proactive Web Service Adaptation.
Advanced Information Systems Engineering. J. Ralyt, X. Franch, S.
Brinkkemper and S. Wrycza, Springer Berlin / Heidelberg. 7328: 473-485.
References
252
Nancy, A. (2008). Enabling On-the-Fly Business Process Composition through an Event-
Based Approach. Proceedings of the 41st Annual Hawaii International
Conference on System Sciences.
Nezhad, H. R. M., Benatallah, B., Martens, A., et al. (2007). Semi-automated adaptation
of service interactions. Proceedings of the 16th International Conference on
World Wide Web. Banff, Alberta, Canada, ACM.
Nguyen, T. and Colman, A. (2010). A Feature-Oriented Approach for Web Service
Customization. International Conference on Web Services (ICWS), Los
Alamitos, CA, USA, IEEE Computer Society.
Nguyen, T. (2011a). "WSVL Homepage." Retrieved 19 May 2013, from
https://sites.google.com/site/swinwsvl/.
Nguyen, T., Colman, A. and Han, J. (2011b). A Web Services Variability Description
Language (WSVL) for Business Users Oriented Service Customization. Web
Information System Engineering - International Workshop on User-Focused
Service Engineering, Consumption and Aggregation (USECA).
Nguyen, T., Colman, A. and Han, J. (2011c). Modeling and Managing Variability in
Process-Based Service Compositions. Service-Oriented Computing. G. Kappel,
Z. Maamar and H. Motahari-Nezhad, Springer. 7084: 404-420.
Nguyen, T., Colman, A., Talib, M. A., et al. (2011d). Managing service variability: state
of the art and open issues. International Workshop on Variability Modeling of
Software-Intensive Systems (VaMoS), Namur, Belgium, ACM.
Nguyen, T., Colman, A. and Han, J. (2012a). Enabling the Delivery of Customizable Web
Services. IEEE 19th International Conference on Web Services (ICWS),
Honolulu, Hawaii.
Nguyen, T., Colman, A. and Han, J. (2012b). Comprehensive Variability Modeling and
Management for Customizable Process-Based Service Compositions. Handbook
on Web Services. A. Bouguettaya, Q. Z. Sheng and F. Daniel, Springer.
Ognjanovic, I., Mohabbati, B., Gaevic, D., et al. (2012). A Metaheuristic Approach for
the Configuration of Business Process Families. International Conference on
Services Computing (SCC).
OMG. (2011a). "Business Process Model and Notation (BPMN) Version 2.0." Retrieved
19 May 2013, from http://www.omg.org/spec/BPMN/2.0/.
OMG. (2011b). "Business Process Model and Notation (BPMN) Version 2.0.": Mapping
BPMN models to WS-BPEL Retrieved 19 May 2013, from
http://www.omg.org/spec/BPMN/2.0/.
Oracle. (2012). "The Java tutorial - Annotations." Retrieved 19 May 2013, from
http://docs.oracle.com/javase/tutorial/java/javaOO/annotations.html.
Oracle. (2013). "JConsole." Retrieved 19 May 2013, from
http://docs.oracle.com/javase/6/docs/technotes/guides/management/mxbeans.html
.
Ouyang, C., Dumas, M., H.M, A., et al. (2008). Pattern-Based Translation of BPMN
Process Models to BPEL Web Services, IGI Global: 42-62.
Papazoglou, M. P. and Heuvel, W.-J. (2007). "Service oriented architectures:
approaches, technologies and research issues." The VLDB Journal 16(3): 389-
415.
Perrouin, G., Klein, J., Guelfi, N., et al. (2008). Reconciling Automation and Flexibility in
Product Derivation. International Software Product Line Conference (SPLC).
Pohl, K., Bockle, G. and Linden, F. J. v. d. (2005). Software Product Line Engineering:
Foundations, Principles and Techniques, Springer-Verlag New York, Inc.
Provost, W. (2003). "WSDL First." Retrieved 19 May 2013, from
http://webservices.xml.com/pub/a/ws/2003/07/22/wsdlfirst.html.
References
253
Razavian, M. and Khosravi, R. (2008). Modeling Variability in Business Process Models
Using UML. International Conference on Information Technology: New
Generations.
Riebisch, M., Bllert, K., Streitferdt, D., et al. (2002). Extending Feature Diagrams With
Uml Multiplicities. the 6th World Conference on Integrated Design and Process
Technology (IDPT2002).
Schmid, K. and John, I. (2004). "A customizable approach to full lifecycle variability
management." Science of Computer Programming 53(3): 259-284.
Schnieders, A. and Puhlmann, F. (2006). Variability Mechanisms in E-Business Process
Families. International Conference on Business Information Systems.
Schnieders, A. and Puhlmann, F. (2007). Variability Modeling and Product Derivation in
E-Business Process Families. Technologies for Business Information Systems.
W. Abramowicz and H. C. Mayr, Springer Netherlands: 63-74.
Segura, S. (2008). Automated analysis of feature models using atomic sets. Proceedings
of the International Software Product Line Conference (SPLC), Lero Int. Science
Centre, University of Limerick, Ireland.
Sinnema, M., Deelstra, S., Nijhuis, J., et al. (2004). COVAMOF: A Framework for
Modeling Variability in Software Product Families. Software Product Lines: 25-
27.
Sinnema, M., Deelstra, S. and Hoekstra, P. (2006a). The COVAMOF Derivation Process.
Reuse of Off-the-Shelf Components, Springer Berlin / Heidelberg. 4039: 101-
114.
Sinnema, M., Deelstra, S., Nijhuis, J., et al. (2006b). Modeling Dependencies in Product
Families with COVAMOF. Proceedings of the 13th Annual IEEE International
Symposium and Workshop on Engineering of Computer Based Systems, IEEE
Computer Society.
Sinnema, M. and Deelstra, S. (2007). "Classifying variability modeling techniques."
Information and Software Technology 49(7): 717-739.
Stollberg, M. and Muth, M. (2009). Service Customization by Variability Modeling.
Service Oriented Computing (ICSOC) Workshops - International Workshop on
Engineering Service-Oriented Applications.
Stollberg, M. and Muth, M. (2010). "Efficient Business Service Consumption by
Customization with Variability Modelling." System Integration 1(3): 17-32.
Sun, C.-a. and Aiello, M. (2008). Towards Variable Service Compositions Using
VxBPEL. High Confidence Software Reuse in Large Systems: 257-261.
Sun, C.-a., Rossing, R., Sinnema, M., et al. (2009). "Modeling and managing the
variability of Web service-based systems." System and Software 83(3): 502-516.
Svahnberg, M., Gurp, J. v. and Bosch, J. (2005). "A taxonomy of variability realization
techniques." Software Practice and Experience 35(8): 705-754.
Thum, T., Batory, D. and Kastner, C. (2009). Reasoning about edits to feature models.
Software Engineering, 2009. ICSE 2009. IEEE 31st International Conference on.
Tosic, V., Patel, K. and Pagurek, B. (2002). WSOL - Web Service Offerings Language.
Web Services, E-Business, and the Semantic Web. C. Bussler, R. Hull, S.
McIlraithet al. 2512: 57-67.
Tosic, V., Pagurek, B., Patel, K., et al. (2003). Management Applications of the Web
Service Offerings Language (WSOL). Advanced Information Systems
Engineering. J. Eder and M. Missikoff, Springer Berlin / Heidelberg. 2681: 1029-
1029.
Tsang, E. (1993). Foundations of constraint satisfaction, Academic press London.
van der Aalst, W. M. P. (1999). "Formalization and verification of event-driven process
chains." Information and Software Technology 41(10): 639-650.
van der Aalst, W. M. P. and ter Hofstede, A. H. M. (2005). "YAWL: yet another workflow
language." Information Systems 30(4): 245-275.
References
254
van der Aalst, W. M. P. (2011). Business Process Configuration in the Cloud: How to
Support and Analyze Multi-tenant Processes? IEEE European Conference on
Web Services (ECOWS).
Wang, H., Li, Y. F., Sun, J., et al. (2005). A semantic web approach to feature modeling
and verification. Workshop on Semantic Web Enabled Software Engineering
(SWESE05).
Wang, H. H., Li, Y. F., Sun, J., et al. (2007). "Verifying feature models using OWL." Web
Semantics: Science, Services and Agents on the World Wide Web 5(2): 117-129.
Weidmann, M., Koetter, F., Kintz, M., et al. (2011). Adaptive Business Process Modeling
in the Internet of Services (ABIS). International Conference on Internet and Web
Applications and Services.
Whaley, J. (2007). "JavaBDD." Retrieved 19 May 2013, from
http://javabdd.sourceforge.net/.
White, J., Schmidt, D. C., Benavides, D., et al. (2008). Automated diagnosis of product-
line configuration errors in feature models. Software Product Line Conference,
2008. SPLC'08. 12th International, IEEE.
White, J., Dougherty, B., Schmidt, D. C., et al. (2009). Automated reasoning for multi-
step feature model configuration problems. Proceedings of the 13th International
Software Product Line Conference, Carnegie Mellon University.
White, S. A. (2005). "Using BPMN to Model a BPEL Process." Retrieved 19 May 2013,
from http://www.bptrends.com/publicationfiles/03-
05%20wp%20mapping%20bpmn%20to%20bpel-%20white.pdf.
Yukyong, K. and Kyung-Goo, D. (2008). Adaptable Web Services Modeling Using
Variability Analysis. International Conference on Convergence and Hybrid
Information Technology.
Zaid, L. A., Kleinermann, F. and De Troyer, O. (2009). Applying semantic web
technology to feature modeling. Proceedings of the 2009 ACM symposium on
Applied Computing, ACM.
Zhang, H. and Jarzabek, S. (2004). "XVCL: a mechanism for handling variants in
software product lines." Science of Computer Programming 53(3): 381-407.

Minh Tuan Nguyen Thesis

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Minh Tuan Nguyen Thesis

Hochgeladen von

Copyright:

Verfügbare Formate

Feature-based Composition and Delivery

of Customisable Web Services

is a function which maps each feature to its feature

is a function which maps a parent feature of a feature

and exclude constraints

is a new customisation request that is inferred from by analysing

: Given a feature group with the upper bound of its group

(Example 3.6) is the maximally inferred customisation

from the original customisation request . Since

is an inferred customisation request, from Definition 3.4 we have

. Therefore, if we analyse restrictions to

in the same ordering that we can

from , we are able to add

to the respective sets of selected

. In other words, we have a new customisation

) which is possibly an inferred customisa-

. However, as stated in Definition 3.5,

is the normalised customisation request of the maximally inferred customisa-

is the result of pruning mandatory features from such that

(Example 3.7) is a partial

(Example 3.8) is a complete customisation requests.

has all variant features decided, i.e.

. Therefore, this propositional formula is true

Das könnte Ihnen auch gefallen