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.1 - Focus of this chapter ........................................................................ 119

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.1 - Focus of this chapter ........................................................................ 141

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. 5th 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 3rd

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 implementation

Variant implementation

Variant

interface

Variant

interface

a) Super-service approach b) All-service-variant approach

Chapter 1 - Introduction

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 MDE–based 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

Chapter 1 - Introduction

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 implementationVariant

interface

Customisable service

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 consumer’s 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.

Chapter 1 - Introduction

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 JAX-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

Chapter 1 - Introduction

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

Imp

lem

enta

tion

Inte

rfa

ce

Consumer PartnerInterface 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

Chapter 1 - Introduction

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. Application’s 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.

2.1 Software variability

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 TestsDo

main

En

gin

eeri

ng

Application

Requirements

Engineering

Application

Design

Application

Realisation

Application

Testing

Application 1 - Artefacts & Variability model

Requirements Architecture Components TestsAp

plica

tio

n E

ng

ineeri

ng

Application N - Artefacts & Variability model

Chapter 2 - Background, Analytical Framework and Literature Review

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 model’s

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-userBroker

[1-1]

[1-1]

Bill payer

Temporary accommodation

[0-1] [0-1][1-1]

Payment time

[a-b]

Group

Cardinality

2.1 Software variability

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

Chapter 2 - Background, Analytical Framework and Literature Review

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.

2.1 Software variability

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

Chapter 2 - Background, Analytical Framework and Literature Review

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.

2.2 An analytical framework for analysing service variability

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

Chapter 2 - Background, Analytical Framework and Literature Review

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

2.2 An analytical framework for analysing service variability

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.

Chapter 2 - Background, Analytical Framework and Literature Review

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.

2.2 An analytical framework for analysing service variability

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 (Interface/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

Chapter 2 - Background, Analytical Framework and Literature Review

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 modeling

Variability instantiation

Internal

Composition

variability

Partner

variability

External

AutomatedInter-

dependencies

Exposed

variability

Variability

communication

Formality Technology

independence

Self-

describing

Staged

instantiation

Who

(Provider/

Consumer)

Level

(Interface/

Implementation)

RecursiveAbstraction

level

Requirement

Architecture Implementation

Variation

points and

variants

Variability

constraints

Intra-

dependencies

Feature

nameDistinct

characteristics

Feature

nameInherited

characteristics

2.2 An analytical framework for analysing service variability

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

Chapter 2 - Background, Analytical Framework and Literature Review

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.

2.3 Reviewing literature on service variability

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 instantiation1 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.

Chapter 2 - Background, Analytical Framework and Literature Review

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.

2.3 Reviewing literature on service variability

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

Chapter 2 - Background, Analytical Framework and Literature Review

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-

2.3 Reviewing literature on service variability

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 developers2, 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.

Chapter 2 - Background, Analytical Framework and Literature Review

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-

2.3 Reviewing literature on service variability

37

mentation level3. 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.

Chapter 2 - Background, Analytical Framework and Literature Review

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-

2.3 Reviewing literature on service variability

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; Lönn 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.

Chapter 2 - Background, Analytical Framework and Literature Review

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.

2.3 Reviewing literature on service variability

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.

Intr

a-d

epen

den

cies

Inte

r-d

epen

den

cies

Req

uir

emen

t

Arc

hit

ectu

re

Imp

lem

enta

tion

Exp

ose

d v

aria

bil

ity

Co

mpo

siti

on

var

iabil

ity

Par

tner

var

iabil

ity

Fo

rmal

ity

Tec

hnolo

gy

ind

epen

den

ce

Sel

f-d

escr

ibin

g

Au

tom

ated

Sta

ged

in

stan

tiat

ion

Wh

o (

Pro

vid

er/

Con

sum

er)

Lev

el (

Inte

rfac

e /

Imp

lem

enta

tion

Rec

urs

ive

Ato

mic

Jiang 2005 N/A4 N/A P5 N/A

Stollberg et al. N/A N/A C5 Inf6 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

BP

EL

VxBPEL P Imp6

Variability descriptor P Both

Events P Imp

Aspects P Imp

Rules or policies P Imp

BP

MN

Hallerbach 2010 P

Schnieders 2006 P Imp

Machado 2011 P

Weidmann 2011 P

Charfi 2010 P

UM

L

Razavian 2008 P Imp

Hadaytullah 2009 P

Sun 2010 P Imp

Jaroucheh 2010 P Imp

Oth

ers C-EPC P Imp

C-YAWL P Imp

Our work 7

C Both

Chapter 2 - Background, Analytical Framework and Literature Review

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

Imple

menta

tion

Inte

rface

Consumer PartnerInterface description

language

Composite service

realisation

Provisioning architecture

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

platform’s viewpoints.

Chapter 2 - Background, Analytical Framework and Literature Review

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

Imp

lem

enta

tion

Inte

rface

Consumer PartnerInterface description

language

Composite service

realisation

Provisioning architecture

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-

vider’s 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 CreationPolicy 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

Chapter 3 - Feature-based Service Customisation Framework

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

Imp

lem

enta

tion

Inte

rfa

ce

Consumer

Customisation Request

Customisation Response

Consumption Request

Consumption Response

Customisation mode

Consumption mode

Customisation

engine

Service

variant

Payment type

Execution

Credit card

[1-1]

BPAYBank 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.

3.3 Customisable service as a product family

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

Chapter 3 - Feature-based Service Customisation Framework

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 service8 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

3.3 Customisable service as a product family

53

engineering techniques which are shared by both atomic and composite services: i) a

template approach for representing software variants9 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

engineeringApplication

engineering

Chapter 3 - Feature-based Service Customisation Framework

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

engineeringConfigurable

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 A1, A2,…, An are selected and the variant

features B1, B2,…, Bm 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.

3.4 Service customisation mode

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

Chapter 3 - Feature-based Service Customisation Framework

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 .

3.4 Service customisation mode

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

Chapter 3 - Feature-based Service Customisation Framework

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

3.4 Service customisation mode

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 requests10

.

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

Given customisation options 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.

Chapter 3 - Feature-based Service Customisation Framework

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; Mendonça 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

Given customisation options 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

3.4 Service customisation mode

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

Chapter 3 - Feature-based Service Customisation Framework

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

Given customisation options 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

.

3.4 Service customisation mode

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

Given customisation options , a

maximise function F M A X : is a function which maps a customisation

request to its maximally inferred customisation request.

Chapter 3 - Feature-based Service Customisation Framework

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

Given customisation options 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

Given customisation options , 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

Given customisation options and a

customisation request , a normalised customisation request

is the result of pruning mandatory features from such that

and .

3.4 Service customisation mode

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

Given customisation options , a

customisation request is valid if its optimised customisation request

is well-formed.

Chapter 3 - Feature-based Service Customisation Framework

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

Given customisation options , 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

3.4 Service customisation mode

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 (Eén 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

instantiationConfigurable

artefacts

Service

variant

Configurable

service

interfaceConfigurable

service

implementation

Variant

service

interface Variant

service

implementation

Feature

model

mapped

input

input

output

contain contain

Chapter 3 - Feature-based Service Customisation Framework

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

Customisable service

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

3.4 Service customisation mode

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

Chapter 3 - Feature-based Service Customisation Framework

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 don’t 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

Variability modeling

Variability instantiation

Internal

Composition

variability

Partner

variability

External

AutomatedInter-

dependencies

Exposed

variability

Variability

communication

Formality Technology

independence

Self-

describing

Staged

instantiation

Who

(Provider/

Consumer)

Level

(Interface/

Implementation)

RecursiveAbstraction

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 (Interface/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 (Interface/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.

Chapter 3 - Feature-based Service Customisation Framework

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

Figure 4.1 - Focus of this chapter

Customisation

framework

Atomic service

realisationIm

ple

menta

tion

Inte

rfa

ce

Consumer PartnerInterface description

language

Composite service

realisation

Provisioning architecture

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

Imp

lem

enta

tion

Inte

rfa

ce

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 paradigm12

(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-

dependencies13

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.

Chapter 4 - Web Service Variability Description Language (WSVL)

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 variability14

.

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 side15

.

In the subsequent section, we describe WSVL which is our extension of WSDL for

describing customisation contracts.

4.2 Web Service Variability description Language (WSVL)

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.

Chapter 4 - Web Service Variability Description Language (WSVL)

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)

4.2 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>

Chapter 4 - Web Service Variability Description Language (WSVL)

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 configurations18

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

4.2 Web Service Variability description Language (WSVL)

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

Chapter 4 - Web Service Variability Description Language (WSVL)

82

line 1-8). And the operation returns the URL of the service variant’s 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>

4.2 Web Service Variability description Language (WSVL)

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

Chapter 4 - Web Service Variability Description Language (WSVL)

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“/>

4.2 Web Service Variability description Language (WSVL)

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 A1,

A2,…, An are selected and the variant features B1, B2,…, Bm 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

Chapter 4 - Web Service Variability Description Language (WSVL)

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 A1 and A2 are selected” where “A1 and A2 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"/>

<serviceElementRef ref="tns:getQuote4Residential” target="operation" />

</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"/>

<serviceElementRef ref="tns:getQuote4ResidentialWithExtra” target="operation" />

</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>

4.2 Web Service Variability description Language (WSVL)

87

false. Another example is a mistakenly specified propositional formula like “If

the feature A1 is selected and the feature A1 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

A1, A2,…, An are selected and the variant features B1, B2,…, Bm 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

Chapter 4 - Web Service Variability Description Language (WSVL)

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 Swinbroker’s business process. In Chapter 7, we will further elaborate the

implication and benefits of capturing variability inter-dependencies when we discuss

customisable composite services.

4.3 Engineering and validating WSVL documents

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.

Chapter 4 - Web Service Variability Description Language (WSVL)

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 modelingService capability

modelingFeature mapping

Customisation function

modeling

Customisation options

description

Service capability

description

Feature mapping

description

Customisation function

description

Service-specific activities Platform-specific activity

4.3 Engineering and validating WSVL documents

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))

Chapter 4 - Web Service Variability Description Language (WSVL)

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

4.3 Engineering and validating WSVL documents

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

Chapter 4 - Web Service Variability Description Language (WSVL)

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

4.3 Engineering and validating WSVL documents

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

Chapter 4 - Web Service Variability Description Language (WSVL)

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

4.3 Engineering and validating WSVL documents

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");

Chapter 4 - Web Service Variability Description Language (WSVL)

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>>

4.3 Engineering and validating WSVL documents

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

Chapter 4 - Web Service Variability Description Language (WSVL)

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

Figure 4.15 - Service variability characteristics addressed in this chapter

Level

(Interface/

Implementation)

Partner

variability

Composition

variability

ImplementationArchitecture

Variation

points and

variants

Intra-

dependencies

Service variability

Variability modeling

Variability instantiation

Internal

External

AutomatedInter-

dependencies

Exposed

variability

Variability

communication

Formality Technology

independence

Self-

describing

Staged

instantiation

Who

(Provider/

Consumer)

RecursiveAbstraction

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.

Chapter 4 - Web Service Variability Description Language (WSVL)

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.

Figure 5.1 - Focus of this chapter

This chapter

Customisation

framework

Atomic service

realisation

Imp

lem

enta

tion

Inte

rfa

ce

Consumer PartnerInterface description

language

Composite service

realisation

Provisioning architecture3

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

platforms19

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.

Chapter 5 - An Architecture for Provisioning Customisable Services

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

implementationVariant profile

repository

Service variant

Customisation

endpoint

Variant

endpoint

5.3 The service provisioning architecture

107

as well as deriving the optimised customisation request20

. 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 form21

. 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 artefacts21

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

Chapter 5 - An Architecture for Provisioning Customisable Services

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 engine first 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 engine is 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 Handling partial customisation requests

5.4.1 Overview

As discussed in Chapter 3, there are two types of customisation requests: complete

customisation requests and partial customisation requests22

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

Chapter 5 - An Architecture for Provisioning Customisable Services

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

5.4 Handling partial customisation requests

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 variant23

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

Chapter 5 - An Architecture for Provisioning Customisable Services

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]

5.4 Handling partial customisation requests

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 A1, A2,…, An are selected and the variant features B1, B2,…, Bm 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 Ai (1 i n) are selected and all

features Bj (1 j m) are disabled in that feature configuration. In contrast, if at least

one of the features Ai (1 i n) is disabled or at least one of the features Bj (1 j m)

is selected in the feature configuration, the propositional formula is evaluated to false.

Otherwise, when a subset of features Ai (1 i h) are selected and a subset of features

Bj (1 j k) are disabled, the variant service capability remains variant with the updated

propositional formula as “If the variant features Ah+1,…, An are selected and the variant

features Bk+1,…, Bm 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:portType name="quotingPortType">

<wsdl:operation name="getQuote4Residential"/>

<wsdl:operation name="getQuote4ResidentialWithExtra"/>

<wsdl:operation name=“addAccidentalDamage"/>

</wsdl:portType>

<wsdl:portType name="purchasingPortType“/>

Chapter 5 - An Architecture for Provisioning Customisable Services

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"/>

<serviceElementRef ref="tns:getQuote4Residential” target="operation" />

</link>

<link name=" LResidentialWithExtra2">

<featureRef ref="fd:ExtraCover" presence=“true"/>

<serviceElementRef ref="tns:getQuote4ResidentialWithExtra” target="operation" />

</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>

5.4 Handling partial customisation requests

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.

Chapter 5 - An Architecture for Provisioning Customisable Services

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 CR1=({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 CR1 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

Figure 5.7 - Service variability characteristics addressed in this chapter

Variation

points and

variants

Intra-

dependencies

Architecture Implementation Composition

variability

Level

(Interface/

Implementation)

Service variability

Variability modeling

Variability instantiation

Internal

Partner

variability

External

AutomatedInter-

dependencies

Exposed

variability

Variability

communication

Formality Technology

independence

Self-

describing

Staged

instantiation

Who

(Provider/

Consumer)

RecursiveAbstraction

level

Requirement

Variability

constraints

Service provisioning

Chapter 5 - An Architecture for Provisioning Customisable Services

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

Figure 6.1 - Focus of this chapter

Customisation

framework

Atomic service

realisation

Imp

lem

enta

tion

Inte

rfa

ce

Consumer PartnerInterface description

language

Composite service

realisation

Provisioning architecture

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 approach24

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 approach25

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).

Chapter 6 - Enabling Customisable Atomic Services

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

6.2 Engineering the configurable service implementation

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: }

Chapter 6 - Enabling Customisable Atomic Services

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: }

6.2 Engineering the configurable service implementation

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: }

Chapter 6 - Enabling Customisable Atomic Services

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.

6.4 Prototype implementation and evaluation

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.

Chapter 6 - Enabling Customisable Atomic Services

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 representationSelected:

“Residential”,

“Extra Cover”,

“Accidental Damage”

Disabled:

“Business”,

“Purchase”,

“Credit Card”,

“Cover Note”

service component

portType component

operation component

FeatureMapping annotation

feature configuration

6.4 Prototype implementation and evaluation

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

configurationLogging

Policy

enforcement

Business

logic

LoggingHeader

filter

Inbound interceptor chain

Outbound interceptor chain

Variant

endpoint

ServiceContextInterceptor Interceptor

Chapter 6 - Enabling Customisable Atomic Services

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.

6.4 Prototype implementation and evaluation

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 document26

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 variant27

.

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 variant’s 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

Chapter 6 - Enabling Customisable Atomic Services

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

6.4 Prototype implementation and evaluation

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 variants28

. 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

Chapter 6 - Enabling Customisable Atomic Services

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 consumer’s 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 variant29

has only one portType

and two operations. Note that the original customisable service has two portTypes and 11

29 CustomisationRequest “Residential” ”Extra Cover” ”Accidental Damage” “Fusion

Cover” ”Extended Third Party Liability” ”Purchase” ”Policy Query” ”Policy Update”

Figure 6.11 - Management page for deployed service variants

6.4 Prototype implementation and evaluation

135

operations. In contrast, the second service variant30

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 CustomisationRequest “Residential” ”Extra Cover” ”Accidental Damage” “Fusion Cover”

”Purchase” ”Credit Card” ”Extended Third Party Liability” ”Policy Query” ”Policy 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 1Response by variant 2

Chapter 6 - Enabling Customisable Atomic Services

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

Figure 6.13 - Service variability characteristics addressed in this chapter

Variation

points and

variants

Intra-

dependencies

Architecture Implementation Composition

variability

Level

(Interface/

Implementation)

Service variability

Variability modeling

Variability instantiation

Internal

Partner

variability

External

AutomatedInter-

dependencies

Exposed

variability

Variability

communication

Formality Technology

independence

Self-

describing

Staged

instantiation

Who

(Provider/

Consumer)

RecursiveAbstraction

level

Requirement

Variability

constraints

Atomic service realisation

6.5 Analysis of techniques for enabling customisable atomic services against

service variability characteristics

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.

Chapter 6 - Enabling Customisable Atomic Services

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 (Interface/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.

Figure 7.1 - Focus of this chapter

Customisation

framework

Atomic service

realisation

Imp

lem

enta

tion

Inte

rfa

ce

Consumer PartnerInterface description

language

Composite service

realisation

Provisioning architecture

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-

Chapter 7 - Composing Customisable Composite Services

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 process31

, 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-userBroker

[1-1]

[1-1]

Bill payer

Temporary accommodation

[0-1] [0-1][1-1]

Payment time

Chapter 7 - Composing Customisable Composite Services

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]

BPAYBank 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:link name="BankTransfer2">

<wsvl:featureRef ref="fd:UserNotification" presence=“false"/>

<wsvl:serviceElementRef ref="tns:confirmBankPayment" target="operation"/>

</wsvl:link>

<wsvl:link name="BankTransferWithNotification1">

<wsvl:featureRef ref="fd:BankTransfer" presence="true"/>

<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

Chapter 7 - Composing Customisable Composite Services

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 time32

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 2Process variant 2

Partner variant 2Process variant 2

Process variant 3

Process variant 1

Partner variant 1

Partner variant 3Process variant 3

Process variant 1

Partner variant 1

Partner variant 2

Partner variant 3

Process variant 2

Partner variant 2Process variant 2

Partner variant 2Process variant 2

Process variant 3

Process variant 1

Partner variant 1

Partner variant 3Process variant 3

Process variant 1

Ru

nti

me

Des

ign

tim

eS

oft

wa

re a

rte

fac

t

No variability inter-dependencies Variability inter-dependencies

Composite Partner Composite Partner

Partner

customisation

Service

customisation

Partner

customisation

Service

customisation

Static binding

Dynamic binding

Chapter 7 - Composing Customisable Composite Services

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 provider’s 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.

7.4 Variability-enabled BPMN (VBPMN)

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.

Chapter 7 - Composing Customisable Composite Services

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 FlowNode or

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

7.4 Variability-enabled BPMN (VBPMN)

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

Chapter 7 - Composing Customisable Composite Services

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

7.4 Variability-enabled BPMN (VBPMN)

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 ItemElement to one target element

ItemElement. This element ItemElement 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

Chapter 7 - Composing Customisable Composite Services

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

7.4 Variability-enabled BPMN (VBPMN)

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 InteractionNode to another

InteractionNode. An InteractionNode might 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)

Chapter 7 - Composing Customisable Composite Services

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

7.4 Variability-enabled BPMN (VBPMN)

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

AbstractConsumerTaskConsumerTask

MessageFlow

ConversationVariant

Message

Chapter 7 - Composing Customisable Composite Services

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

7.4 Variability-enabled BPMN (VBPMN)

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

Feature is 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

Chapter 7 - Composing Customisable Composite Services

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

7.4 Variability-enabled BPMN (VBPMN)

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

Chapter 7 - Composing Customisable Composite Services

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

Chapter 7 - Composing Customisable Composite Services

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

7.5 Developing and resolving variability in process-based service compositions

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

Chapter 7 - Composing Customisable Composite Services

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:link name="BankTransfer1">

<wsvl:featureRef ref="fd:BankTransfer" presence="true"/>

<wsvl:serviceElementRef ref="tns:sendBankPaymentDetail" target="operation"/>

</wsvl:link>

<wsvl:link name="BankTransfer2">

<wsvl:featureRef ref="fd:BankTransfer" presence="true"/>

<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

7.5 Developing and resolving variability in process-based service compositions

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

Chapter 7 - Composing Customisable Composite Services

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-

tion33. 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 resolved34

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

7.6 Prototype system and evaluation

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-

Chapter 7 - Composing Customisable Composite Services

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

7.6 Prototype system and evaluation

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.

Chapter 7 - Composing Customisable Composite Services

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

7.6 Prototype system and evaluation

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

Chapter 7 - Composing Customisable Composite Services

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.

7.6.4.3.2 Evaluation

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

service variability characteristics

177

we do not implement the part for generating executable BPEL definition. However, this

task is technically achievable (White 2005; Ouyang 2008).

7.6.4.4.2 Evaluation

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

Chapter 7 - Composing Customisable Composite Services

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

Figure 7.19 - Service variability characteristics addressed in this chapter

Level

(Interface/

Implementation)

Composition

variability

ImplementationArchitecture

Intra-

dependencies

Variation

points and

variants

Service variability

Variability modeling

Variability instantiation

Internal

Partner

variability

External

AutomatedInter-

dependencies

Exposed

variability

Variability

communication

Formality Technology

independence

Self-

describing

Staged

instantiation

Who

(Provider/

Consumer)

RecursiveAbstraction

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 (Interface/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

Chapter 7 - Composing Customisable Composite Services

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 Amazon’s 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

Chapter 8 - Case Study and Evaluation

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

8.2 Redesign the AWS as a customisable service

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 modelingService capability

modelingFeature mapping

Variability

modeling

Code generation Variability annotationService

implementation

Customisation frontend

generation

Feature model &

service registration

Service

deployment

Chapter 8 - Case Study and Evaluation

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

8.2 Redesign the AWS as a customisable service

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.

Chapter 8 - Case Study and Evaluation

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

8.2 Redesign the AWS as a customisable service

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

Chapter 8 - Case Study and Evaluation

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

8.2 Redesign the AWS as a customisable service

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

Chapter 8 - Case Study and Evaluation

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

codeService Endpoint

Interface (SEI)

Service

implementation class

Data type

classes

Data type

classes

8.2 Redesign the AWS as a customisable service

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

);

@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)

@WebResult(name = "ModifyVolumeAttributeResponse")

@WebMethod(operationName = "ModifyVolumeAttribute")

public ModifyVolumeAttributeResponseType modifyVolumeAttribute(

ModifyVolumeAttributeType modifyVolumeAttributeRequestMsgReq

);

}

Chapter 8 - Case Study and Evaluation

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 {

public DescribeVolumeAttributeResponseType describeVolumeAttribute(

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);

}

}

public ModifyVolumeAttributeResponseType modifyVolumeAttribute(

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);

}

}

}

8.2 Redesign the AWS as a customisable service

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 {

@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)

@WebResult(name = "DescribeVolumeAttributeResponse ")

@WebMethod(operationName = "DescribeVolumeAttribute")

@FeatureMapping(enabledFeatureList = {"External storage"}, disabledFeatureList = {""})

public DescribeVolumeAttributeResponseType describeVolumeAttribute(

DescribeVolumeAttributeType describeVolumeAttributeRequestMsgReq

);

@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)

@WebResult(name = "ModifyVolumeAttributeResponse")

@WebMethod(operationName = "ModifyVolumeAttribute")

@FeatureMapping(enabledFeatureList = {"External storage"}, disabledFeatureList = {""})

public ModifyVolumeAttributeResponseType modifyVolumeAttribute(

ModifyVolumeAttributeType modifyVolumeAttributeRequestMsgReq

);

}

FeatureMapping annotations

Chapter 8 - Case Study and Evaluation

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 engine in 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

8.2 Redesign the AWS as a customisable service

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.

Chapter 8 - Case Study and Evaluation

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>

<cardinality max="1" min="0"/>

<solitaryFeature name="Image-manipulation“/>

</binaryRelation>

<binaryRelation>

<cardinality max="1" min="1"/>

<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)

8.2 Redesign the AWS as a customisable service

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

Chapter 8 - Case Study and Evaluation

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-

gine will 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

Chapter 8 - Case Study and Evaluation

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 2→3 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 10→15 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

Mandatory feature wrt parent feature

Feature group

Chapter 8 - Case Study and Evaluation

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

Service variant type

Variant (selectable) feature

Disabled feature

Mandatory feature wrt parent 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

Service variant type

Variant (selectable) feature

Disabled feature

Mandatory feature wrt parent feature

Feature group

Selected grouped feature

Chapter 8 - Case Study and Evaluation

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 AWSClient

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 customisationresponse

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

Chapter 8 - Case Study and Evaluation

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

2535

87

0

20

40

60

80

100

120

140

160

Light-weight Medium-weight Heavy-weight

#serv

ice o

pera

tio

ns

Max

Average

Min

149 Super-service

Chapter 8 - Case Study and Evaluation

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

Light-weight Medium-weight Heavy-weight

# Lo

ade

d c

lass

es

(%)

Max

Average

Min

Figure 8.20 - Memory consumption (%)

0

10

20

30

40

50

60

70

80

90

100

Light-weight Medium-weight Heavy-weight

Pe

rmG

en

siz

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.

Chapter 8 - Case Study and Evaluation

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

Variability modeling

Variability instantiation

Internal

Partner

variability

External

AutomatedInter-

dependencies

Exposed

variability

Variability

communication

Formality Technology

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

Chapter 9 - Conclusion and Future Work

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,

Chapter 9 - Conclusion and Future Work

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 A1, A2,…, An are selected and the variant

features B1, B2,…, Bm 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> <element name="feature" type="tns:tFeature" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="minCardinality" type="int"/> <attribute name="maxCardinality" type="int"/> </complexType> <complexType name="tFeatureHierarchy"> <sequence> <element name="feature" type="tns:tFeature" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="tRequireConstraint"> <sequence> <element name="featureRef" type="tns:tFeatureRef"/> <element name="requiredFeatureRef" type="tns:tFeatureRef" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="name" type="NCName"/> </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>

Appendix A: XML Schema for WSVL

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" maxOccurs="unbounded"/> </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> <attribute name="name" type="NCName"/> </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"/>

Appendix A: XML Schema for WSVL

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> <attribute name="name" type="NCName"/> </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:featureGroup>

</wsvl:feature>

<wsvl:feature name="ExtraCover" minCardinality="0"

maxCardinality="1">

<wsvl:featureGroup minCardinality="1" maxCardinal-

ity="3">

<wsvl:feature name="AccidentalDamage"/>

<wsvl:feature name="ExtendedThirdPartyLia-

bility"/>

<wsvl:feature name="FusionCover"/>

</wsvl:featureGroup>

</wsvl:feature>

</wsvl:feature>

<wsvl:feature name="Purchase" minCardinality="0"

maxCardinality="1">

<wsvl:feature name="PaymentMethod" minCardinali-

ty="1" maxCardinality="1">

<wsvl:featureGroup minCardinality="1" maxCardinal-

ity="1">

<wsvl:feature name="CreditCard"/>

<wsvl:feature name="CoverNote"/>

</wsvl:featureGroup>

</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"

target="operation" />

</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-

WithExtra" target="operation" />

</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" />

Appendix B: The WSVL Description of the Swinsure Insurance Web service

227

</wsvl:link>

<wsvl:link name="LBusinessWithExtra1">

<wsvl:featureRef ref="fd:Business" presence="true" />

<wsvl:serviceElementRef ref="tns:getQuote4Business-

WithExtra" target="operation" />

</wsvl:link>

<wsvl:link name="LBusinessWithExtra2">

<wsvl:featureRef ref="fd:ExtraCover" presence="true" />

<wsvl:serviceElementRef ref="tns:getQuote4Business-

WithExtra" target="operation" />

</wsvl:link>

<wsvl:link name="LAccidentalDamage">

<wsvl:featureRef ref="fd:AccidentalDamage" presence="true"

/>

<wsvl:serviceElementRef ref="tns:addAccidentalDamage"

target="operation" />

</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" />

Appendix B: The WSVL Description of the Swinsure Insurance Web service

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>

Appendix B: The WSVL Description of the Swinsure Insurance Web service

229

</xsd:element>

<xsd:element name="updatePolicy">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

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>

<xsd:element name="referenceNumber"

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"/>

<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"/>

Appendix B: The WSVL Description of the Swinsure Insurance Web service

230

<xsd:element name="occupancyType"

type="tns:OccupancyType"/>

<xsd:element name="replacementValue"

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>

<xsd:element name="referenceNumber"

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="getQuote4Business">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="businessName" type="xsd:string"/>

<xsd:element name="customerVisit"

type="xsd:boolean"/>

<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="getQuote4BusinessResponse">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

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="getQuote4BusinessWithExtra">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="businessName" type="xsd:string"/>

<xsd:element name="customerVisit"

type="xsd:boolean"/>

<xsd:element name="claimHistory" type="xsd:int"/>

Appendix B: The WSVL Description of the Swinsure Insurance Web service

231

<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:ExcessValue4ExtraCover"/>

<xsd:element name="extraCover" type="xsd:boolean"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="getQuote4BusinessWithExtraResponse">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

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="addAccidentalDamage">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

type="xsd:string"/>

<xsd:element name="excess"

type="tns:ExcessValue4ExtraCover"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="addAccidentalDamageResponse">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="info" 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="addFusionCover">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

type="xsd:string"/>

<xsd:element name="excess"

type="tns:ExcessValue4ExtraCover"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="addFusionCoverResponse">

<xsd:complexType>

<xsd:sequence>

Appendix B: The WSVL Description of the Swinsure Insurance Web service

232

<xsd:element name="info" 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="addExtendedThirdPartyLiability">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

type="xsd:string"/>

<xsd:element name="excess"

type="tns:ExcessValue4ExtraCover"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="addExtendedThirdPartyLiability-

Response">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="info" 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="purchasePolicyByCreditCard">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

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:element name="info" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="purchasePolicyByCoverNote">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="referenceNumber"

type="xsd:string"/>

<xsd:element name="postalAddress"

type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="purchasePolicyByCoverNoteResponse">

Appendix B: The WSVL Description of the Swinsure Insurance Web service

233

<xsd:complexType>

<xsd:sequence>

<xsd:element name="info" type="xsd:string"/>

</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:restriction base="xsd:string">

<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:restriction base="xsd:string">

<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:enumeration value="500"/>

<xsd:enumeration value="1000"/>

<xsd:enumeration value="2000"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="ExcessValue4ExtraCover">

<xsd:restriction base="xsd:int">

<xsd:enumeration value="500"/>

<xsd:enumeration value="1000"/>

<xsd:enumeration value="2000"/>

</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">

Appendix B: The WSVL Description of the Swinsure Insurance Web service

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">

<wsdl:part name="parameters" element="tns:getQuote4-

ResidentialResponse"/>

</wsdl:message>

<wsdl:message name="getQuote4ResidentialWithExtraRequest">

<wsdl:part name="parameters" element="tns:getQuote4-

ResidentialWithExtra"/>

</wsdl:message>

<wsdl:message name="getQuote4ResidentialWithExtraResponse">

<wsdl:part name="parameters" element="tns:getQuote4-

ResidentialWithExtraResponse"/>

</wsdl:message>

<wsdl:message name="getQuote4BusinessRequest">

<wsdl:part name="parameters" element="tns:getQuote4-

Business"/>

</wsdl:message>

<wsdl:message name="getQuote4BusinessResponse">

<wsdl:part name="parameters" element="tns:getQuote4-

BusinessResponse"/>

</wsdl:message>

<wsdl:message name="getQuote4BusinessWithExtraRequest">

<wsdl:part name="parameters" element="tns:getQuote4-

BusinessWithExtra"/>

</wsdl:message>

<wsdl:message name="getQuote4BusinessWithExtraResponse">

<wsdl:part name="parameters" element="tns:getQuote4-

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"/>

Appendix B: The WSVL Description of the Swinsure Insurance Web service

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">

<wsdl:part name="parameters" element="tns:purchasePolicy-

ByCreditCardResponse"/>

</wsdl:message>

<wsdl:message name="purchasePolicyByCoverNoteRequest">

<wsdl:part name="parameters" element="tns:purchasePolicy-

ByCoverNote"/>

</wsdl:message>

<wsdl:message name="purchasePolicyByCoverNoteResponse">

<wsdl:part name="parameters" element="tns:purchasePolicy-

ByCoverNoteResponse"/>

</wsdl:message>

<wsdl:portType name="quotingPortType">

<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>

Appendix B: The WSVL Description of the Swinsure Insurance Web service

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

Customisable service

A service that incorporates mechanisms for service consumers

to customise service capabilities and derive particular service

variants

Appendix D: Glossary

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

Appendix D: Glossary

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

Appendix D: Glossary

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

Appendix D: Glossary

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

Appendix D: Glossary

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

Appendix D: Glossary

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

One of three functions performed by a customisable service.

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

One of three functions performed by a customisable service.

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

Appendix D: Glossary

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 Männistö, 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-Cortés, 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., Galán, 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., Müller, H. and Mezini, M. (2010). Aspect-Oriented Business Process

Modeling with AO4BPMN. Modelling Foundations and Applications. T. Kühne,

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., Bézivin, 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/.

Eén, N. and Sörensson, 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., Bézivin, 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/.

Lönn, C.-M., Uppström, 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.

Mendonça, 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., Gašević, 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. Hölzl, 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., Böllert, 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

(SWESE’05).

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.