α BPaaS - A Customizable BPaaS on the Cloud
∗
Yehia Taher
1,3
, Rafiqul Haque
2
, Willem-Jan van den Heuvel
3
and Beatrice Finance
1
1
Laboratoire PRiSM, Universit´e Versailles ST Quentin-En-Yvelines, Versailles, France
2
Lero - The Irish Software Engineering Research Centre, University of Limerick, Limerick, Ireland
3
ERISS, Tilburg University, Tilburg, The Netherlands
Keywords:
Business Process as a Service, Cloud Computing, Customization.
Abstract:
With the emergence of the Internet technologies - notably, SOA and Cloud Computing - enterprises are in-
creasingly delivering their business services through on-line service offerings called Business Process as a
Service (BPaaS). However, current BPaaS offerings can be perceived as monolithic cloud solutions that are
constrained by the capabilities that are made available by the provider at their delivery level and do not allow
for easy extensibility or customization options. In this paper, we propose a novel BPaaS engineering tech-
niques which cater for the tailoring of services to specific business needs using a mixture of SaaS, PaaS and
IaaS solutions - possibly from various providers. It is the prime goal of our proposal to simplify the engineer-
ing of BPaaS applications by hiding the complexity of their development and deployment. This is achieved
by providing a customization solution to manage all configuration of functional and non functional aspects
related to a BPaaS offering.
1 INTRODUCTION
Recently, Business Process as a Service (BPaaS) has
drawn enormous attention from the software vendors,
IT professional, and researchers alike. Gartner is pre-
dicting that Business Process as a Service will grow
from $ 84.1B in 2012 to $ 144B in 2016, generating a
global compound annual growth rate of 15% (Colum-
bus, 2012). Forecasts from industry pundits such as
Gartner about BPaaS have catalyzed investments of
software vendors in developing the innovative BPaaS
solutions. Indeed, today virtually all software vendors
such as IBM market their own BPaaS offerings.
Business Process as a Service may be informally
defined as any type of horizontal (generic) or vertical
(domain-specific) business process that is delivered
on the cloud services model (J. Hurwitz and Kirch,
2012). Currently, a BPaaS is delivered as a com-
prehensive integrated suite comprising not only Busi-
ness Process services but also the Software Services
(SaaSs), Platform Services (PaaSs), and Infrastruc-
ture Services (IaaSs) that enact them. In this way, the
BPaaS suites aim at provisioning a highly standard-
ized, comprehensive and cost-effective solution.
The central notion of a BPaaS suite is a business
process. A business process is composed of a set of
activities that serve the specific purposes of an orga-
∗
This research has been partially funded by the 4CaaSt
project.
nization (Leymann and Roller, 2000). The activities
perform operations that must produce outcomes de-
sired by an organization. Since a business process is
specific to a enterprise context, it should thus meet the
local functional requirements of a organization. Fur-
thermore, a business process should be operated un-
der the constraint of Quality of Services (QoSs) con-
ditions and business policies. The QoSs and busi-
ness policies promote the context specificity of the
businessprocesses because the quality parameters and
their values, and the policies heavily depend on the
preference of an organization or individual.
McCue(McCue, 2012) emphasizes the critical
need for customizing the business processes in a
BPaaS suite. Enterprise-specific requirements cannot
be met unless the standard business process services
in BPaaS solutions are tuned accordingly. Customiza-
tion is not restricted to business process services only,
but in fact propagates to the underlying SaaS, PaaS
and IaaS services. For example, adding an activity in
the business process may incur the need of a novel
software service to realize that activity and new IaaS
services to ascertain persistency.
The above considerations highlight the need for
customization facilities. Currently, the BPaaS suites
do not offer customization service. The BPaaS suite
providers may offer the customization as an addi-
tional service to their clients, however, it is not cost
effective from time and economic perspective. More-
290
Taher Y., Haque R., Heuvel W. and Finance B..
α BPaaS - A Customizable BPaaS on the Cloud.
DOI: 10.5220/0004379602900296
In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CLOSER-2013), pages 290-296
ISBN: 978-989-8565-52-5
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
over, offshore customization is difficult to manage;
and how a business process can be customized by
adapting the internal business policies that are con-
fidential for an organization - is a major challenge
for the offshore customization approach. The on-
premises customization approach is more efficient
than the offshore customization in terms of security,
manageability and cost. Therefore, an on-premises
customization service is a strong requirement but
missing in the state of the art. This research is aimed
to address this requirement.
The goal of the research presented in this pa-
per is to propose an advanced Business Process as
a Service (αBPaaS) suite containing a customiza-
tion service that will enable tailoring the functional,
non-functional aspects of business processes to meet
the enterprise-specific requirements. The customiza-
tion service will also assist in systematically tuning
the software-, platform-, and infrastructure services
that realize a particular business process. The pro-
posed customization component is integrated with the
αBPaaS suite which is more customer-faced or user-
centric than the existing BPaaS suites.
The remainder of this paper is organized as fol-
lows. A brief overview of αBPaaS is presented in
Section 2. Then, the customization mechanisms are
described in Section 3. Section 4 explores and par-
tially validates the customization mechanisms with an
usage scenario. Section 5 presents the conclusion and
future works.
2 αBPaaS - IN A NUTSHELL
Traditionaly a cloud service provider offers a BPaaS
suite that incorporates business processes, the soft-
ware services that contain methods for performing
operations, the platform services, and the physical
resources. These standard services are packaged as
a monolithic service stack as shown in the figure 1.
However a service client may need to customize it
for satisfying some specific needs. Today, the cus-
tomization service is absent, a BPaaS suite is not a
customization-capable solution.
To address this problem, the αBPaaS, a
customization-capable solution, is proposed. “α”
stands for “advanced” and indicates the advancement
of the BPaaS suites which is aimed in this paper. The
αBPaaS suite is depicted in the figure 2. Its role is to
assist the users in customizing the quality parameters,
policies, and functional properties of the services in
the bundle. The key idea behind is to cloudify the
notion of customization and to deliver it as a service.
Different approaches has been proposed for pro-
Figure 1: BPaaS Suite.
Figure 2: A Service (αBPaaS) suite.
ducing outcomes through customization (Zhu and
Zheng, 2005), (Stollberg and Muth, 2009). A Muli-
Layered Approach (Taher et al., 2011) - which pro-
duces multi-level solutions - is adopted in αBPaaS.
In such an approach, at each layer, the customization
produces a solution. αBPaaS offers a set of operators
that assist in performing multi-level customization for
localizing or personalizing the services or processes.
In this way, it caters for customizing services or pro-
cesses by fine-tuning the policies and quality param-
eters. The customization of policies and parameters
produces an end-solution that fits to specific func-
tional areas of a context. This aspect will be demon-
strated in Section 3.
2.1 αBPaaS Architecture
The αBPaaS solution architecture is introduced in fig-
ure 3. Typically, a BPaaS suite is a bundle of BPaaS,
SaaS, PaaS, and IaaS where BPaaS resides on the top
of all other services. In our architecture, these ser-
vices are decoupled and offered as different packages
through APIs. This separation of services facilitates
the customization of services efficiently and correctly.
A customization front-end is integrated in the archi-
tecture. This front-end provides the customization in-
αBPaaS-ACustomizableBPaaSontheCloud
291
Figure 3: αBPaaS Solution Architecture.
terface. In the next section, the customization com-
ponent, which is the main contribution of the paper is
detailed.
3 CUSTOMIZATION
COMPONENT
The customization component offers a list of
operators to assist the users in performing their
customization tasks. It underpins the specification of
the data properties and the behavioural properties
of the services. Its formal defintion is defined in the
following. First an intuitive definition of αBPaaS is
given:
Definition 1. The αBPaaS can be defined as
αBPaaS = (NF
p
, F
p
, B
P
, S
s
, R
P
, λ, C
I
) such that,
• NF
p
denotes the non-functional aspects of the ser-
vices or processes; NF
p
= (Ψ, ρ) where, Ψ and
ρ represent the policies and the quality parame-
ters of the relevant services or process activities
respectively.
• F
p
denotes the functional aspects in particular, the
functional properties of services or processes.
• B
P
is the business process. The business process
is defined as B
P
= (A, P
C
, P
I
, E) where,
– A is the business process activity.
– P
C
represents the control flow patterns such as
Parallel, Sequence.
– P
I
represents the interaction pattern such as
synchronous, asynchronous interaction pat-
terns.
– E is the events such as a messaging event.
• S
s
represents software services (also called soft-
ware components).
• R
P
is the physical resource services such as virtual
machine, storage.
• λ is the platform service.
• C
I
is the customization instructions.
3.1 Data Property Specification
The αBPaaS suite introduces a hard/soft and a
vital/non-vital types that are very different from the
classical data types. They allow the definition of con-
straints. They are briefly described here.
• Hard: Hard denotes the strict constraint that can-
not be violated under any circumstance. For in-
stance, authentication checking is a security pol-
icy that can be characterised as a strict constraint
by specifying its ‘type’ ‘hard’. Consequently, at
runtime, each instance accessing a data storage
must pass the authentication check.
• Soft: Soft denotes a weaker constraint. Its viola-
tion does not bring severe consequence for a run-
ning instance. For instance, a violation of a soft
constraint does not influence the complete failure
of a running instance.
Theses two constraints influence the policies and
quality parameters. Their constraints definition
is given below. Note that F
C
and F
P
represent
respectively the complete and partial failure, and
‘V’ denotes violation.
– ∀(ψ
i
∈ Ψ), IF (ψ
i
.Type = “Hard”) THEN
V(ψ
i
) → F
C
ELSE IF (ψ
i
.Type = “Soft”)
THEN V(ψ
i
) → F
P
.
– ∀(ρ
i
∈ ρ), IF (ρ
i
.Type = “Hard”) THEN V(ρ
i
)
→ F
C
. ELSE IF (ρ
i
.Type = “Soft”) THEN
V(ρ
i
) → F
P
.
• Vital: Vital denotes the strict constraint of a busi-
ness process activity. It is used for characterising
the activities in a business process. If an activity
is ‘vital’ then the failure of that activity affects all
other activities contained in the business process.
As an example, if process payment is of a vital
type and if this activity fails, then all completed
activities such as process delivery will be forced
to fail.
• Non-Vital: Non-Vital denotes the weaker con-
straint of a business process activity. The failure
of a ‘non-vital’ activity may not affect other ac-
tivities contained in the business process. For in-
stance, in a travel management business process,
if hiring car is of non-vital type then the failure of
this activity will not affect other activities such as
reserve hotel room and book flight.
CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience
292
The predicates below show a vital and non-vital
type activity with their respective complete or par-
tial failure.
– ∀(A
i
∈ B
P
), IF (A
i
.Type = “Vital”) THEN
∀(A
i
∈ B
P
) F(A
i
) → F
C
ELSE IF (A
i
.Type =
“Non− Vital”) THEN F(A
i
) → F
P
.
3.2 Behavioural Property Specification
For specifying the flexible behavior of the business
process activities, a list of primitives is offered in
αBPaaS. They are described in the following.
• repair: Repair prevents the complete failure of a
business process. If an activity is vital and if an
operation is performed by that activity has failed
then, the repair operation is performed and healed
the failed activity. The logical condition for re-
pairing a failed activity is stated below:
– ∀(A
i
∈ B
P
), IF ((A
i
.Type = “Vital”) ∧ (∃(O
i
∈ A
i
) → Failed))) THEN repair (O
i
) →
repaired(O
i
), where, O
i
denotes an operation.
In principle, it is not always true that the failed op-
eration will be successfully repaired always how-
ever, in this condition, we have considered what
should happen in all ideal cases. Note that, Re-
pair can be a composite operation in some cases.
For instance, if a software service is permanently
unavailable, the repair operation is performed by
combining the substitute and invoke operations:
(substitute ◦ invoke) =⇒ repair. The substitute
operation is defined later in this section. Invoke
denotes activating a process activity. The invoca-
tion operation occurs after finishing the substitute
operation.
• ignore: Ignore forces the system to ignore the fail-
ure of an activity in the business process. In ad-
dition, this primitive allows the system to ignore
the violation of soft constraints. The logical con-
ditions for ignoring the failure of activity and soft
constraint violation are given below:
– ∀ (A
i
∈ B
P
), IF (A
i
.Type = “Vital”) THEN
F(A
i
) → ignored(V).
– ∀(ψ
i
∈ Ψ), IF (ψ
i
.Type = “So ft”) THEN
V(ψ
i
) → ignored(V).
• retry: Retry forces the system to retry the failed
operation upon failure of that operation. The op-
eration is retried until it is successfully completed
or it reaches the maximum-limit for retrying. The
logical condition is defined below:
– ∀(O
i
∈ A
i
), IF (O
i
→ Failed) THEN
retry
N
(O
i
), where ‘N’ denotes the retry limit.
• wait: Wait is used for specifying the waiting
time between the business process activities. The
primitive forces a business process activity to
wait for another activity to be completed until the
waiting time elapsed.
3.3 Operators
A list of operators are offered for assisting the users in
customizing services and in producingdifferent levels
of solutions. These operators are the basic building
blocks of the customization component. They are de-
scribed below.
• decompose: The parameters, business process
activities can be decomposed into ‘n’ (must be
greater than 1) number of parameters, process ac-
tivities using decompose operator. The followings
show the decomposition operations.
– decompose (ρ) → ρ
1
∧ ρ
2
....∧ ρ
n
. Decompo-
sition of a parameter produces ‘n’ number of
parameters.
– decompose (A) → a
1
∧ a
2
..... ∧ a
n
. Decom-
position of an activity generates ‘n’ number of
activities.
It is worth noting that, the value of ‘n’ means, the
number of decomposed elements in particular, the
parameters or activities essentially depends on the
requirements of the users.
• add and remove: The add and remove operators
used for performing respectively addition and re-
moval operations on process activities and events,
resources, add-ons, quality parameters, etc. These
operations performed on BPaaS suite are not lim-
ited to the ones shown below.
– add or remove (A ∨ P
C
∨ P
I
∨ E ∨ ψ ∨ ρ)
→ B
P
n
. In this operation, a business process is
customized by adding or deleting an element,
quality parameters, or policies. B
P
n
denotes the
new version of the business process.
– add or remove (M ∨ param ∨ (O ∧ param) ∨
ψ ∨ ρ) → S
s
n
. ‘M’ denotes method that real-
izes the process activities. A software service
is customized by adding or deleting operations
(methods) or parameters or both. For software
services, a user may customize the quality pa-
rameters or policies in particular, the security
policy ‘authentication’. S
s
n
denotes the new ver-
sion of the software service produced after per-
forming the add operation.
– add or remove (V
M
∨ M
m
∨ S
t
∨ Nw) → R
P
n
.
Where V
M
, M
m
, S
t
, and Nw represent virtual
αBPaaS-ACustomizableBPaaSontheCloud
293
machine, memory, storage, and virtual local
area network respectively. R
P
n
denotes the new
version of the resource services.
– add or remove (W
S
∨ D ∨ (Plgn ∨ L
C
)) →
λ
n
. Where W
S
and D represent Web Server and
Database and Plgn and L
C
denotes plug-in and
class library that are added or deleted in the de-
velopment tool of the platform services. λ
n
de-
notes the new version of the platform service.
• substitute: Substitute operator used to replace the
process activities, software services, platform ser-
vices, and resource services. The substitute oper-
ation is a composite operation: (remove ◦ find ◦
add) → substitute. Add and remove operations
have already been defined and the Find operation
denotes performing search on a service repository
to find a service which is functionally equivalent
to the service that is to be replaced. The following
examples show the substitute operations:
– substitute (A ∨ E) → B
P
n
. The substitute oper-
ation replaces an activity or event in a business
process.
– substitute (s) → S
s
n
. Here, the substitute opera-
tion replaces a service by a new service.
– substitute ((Plgn ∨ L
C
)∨ W
S
∨ D) → λ
n
. An
element can be substitute in the platform ser-
vices using this operator.
– substitute (V
M
∨ M
m
∨ S
t
∨ Nw) → R
P
n
. A
virtual machine or storage or other service ele-
ments can be replaced by the substitute opera-
tion.
• Create: Create is a special operator used for per-
forming operations on data storage service. Cre-
ate operator is used to create instances such as
buckets(containers) in a storage service. The cre-
ate operation is shown below.
– Create(bucket ∨ object) → λ
n
. Note that, stor-
age service is a type of PaaS.
• rename:Rename is a simple operation that is per-
formed for modifying the name of a business pro-
cess activity or event.
– rename(A ∨ E) → B
P
n
.
• refine: The refinement operations is performed
on a BPaaS suite to fine-tune the BPaaS suite.
The refine operator is used for performing refine-
ment operation. It is used for adding and remov-
ing business process activities, parameters, events
etc. Software services, resource services can be
refined using this operator.
Furthermore, the αBPaaS customization compo-
nent contains instructions that assist in selecting the
operators for customizing the BPaaS suite. The cus-
tomization wizard of the αBPaaS suite provides the
step-by-step instructions for customizing the services.
They are presented on the screen based on the context
specific or function specific inputs keyed by the users.
4 USE CASE SCENARIO
This section illustrates a concrete scenario how the
αBPaaS suite supports the user in customizing of a
cloud based BPaaS suite. Figure 4 depicts the use of
αBPaaS on a scenario and shows the different solu-
tions produced at the different levels.
The customization starts with customizing the
business process service. The meta solution is the
most generic business process offered in the BPaaS
suite. The generic business process contains the basic
activities, events and control flows such as create and
send PO (PO stands for Purchase Order), Process PO,
etc.
The generic business process is customized ac-
cording to the requirements of a domain in order to
produce the domain specific solution. In our scenario,
we have picked automotive business domain. The
customization begins with decomposing create and
send PO into create PO and send PO activities. The
approve PO is a new activity added between these ac-
tivities. The control flow between these activities is
customized as well. A messaging event Receive PO is
added in the domain specific process and the activity
Process PO is decomposed into check inventory and
Register PO. Considering the check inventory activ-
ity, only the ideal case is considered in this example.
The decomposition of this activity can produce more
activities such as replenish product.
A company “ABS Inc.” is considered the context
in this example. The domain specific solution needs
to be customized to produced the context specific so-
lution of the company. At this phase, two swimlanes
are introduced to separate the business processes that
represent buying and selling business processes. The
message flows (dotted arrow lines) are added in the
process; the buyer and seller interacts through the
messages. The messaging events send approval no-
tification and send invoice are added in the seller’s
process. The control flows between these events are
added. The activity Deliver PO is renamed Process
Delivery. On the other hand, Receive PO approval
notification, Receive Delivery, and Receive Invoice
messaging events are added in buying process. The
flows are added for connecting these events. This cus-
tomization produces a business process that meets the
requirements of the ABS Inc.
CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience
294
Figure 4: A Usage Scenario for the αBPaaS.
αBPaaS-ACustomizableBPaaSontheCloud
295
In order to make sure the business process meets
the requirements of a specific functional area or mod-
ule, yet another customization is performed. The pay-
ment area is extended by adding Calculate Price ac-
tivity. Moreover, the process delivery activity is de-
composed into send delivery information and receive
shipment detail. A swimlane is added for capturing
the shipment activities. This swimlane represents a
shipment process that is executed and managed by a
shipper. A list of events and activities which include
receive delivery information, process shipment, ship
order, send shipment detail are added in the shipment
process.
Furthermore, at this customization phase, the
properties associating with the business process ac-
tivities are specified. The activity type Vital, NonVital
and the policies and quality parameters related to the
business process activities are defined. Approval no-
tification time is a policy assigned to send approval
notification with a data property “time” associating a
value “24”. The policy is characterised by the data
property “Soft” that denotes if the notification is not
sent within 24 hours, the process execution will not be
interrupted. However, the “hard” type policy would
stop the execution of the process if the policy was not
satisfied. Check Inventory activity is associated by the
“hard” type policy. Moreover, the functional proper-
ties repair, retry, and wait are specified for different
activities in this functional area specific process.
As this is the final phase of customizing BPaaS
suite, the software, platform, and infrastructure ser-
vices are customized in this phase. In the given exam-
ple, customization of these services are shown inside
a block of dotted lines.
For the software components (in SaaS), the qual-
ity parameters are defined. Availability and Reliability
are the parameters defined for software services along
with their values “24” hours and “High”. The type of
these parameters is “hard” denotes that these values
must be satisfied at runtime. It is worth noting that,
the lower level services should be customized when
a user confirms that the functional area specific busi-
ness process contains all the required activities.
Considering the customization of software com-
ponents, the simplest case is considered for this exam-
ple. Considering the customization of PaaS, a Google
Web Server is added in the platform. Additionally, the
SampleDB is substituted by the CouchDB. The BPEL
2.0 plug-in and jcloud library are added in the devel-
opment tool that is integrated in the platform service
as a package. Finally, the infrastructure services are
customized. Two Virtual Machine images provided
by the Amazon Inc. are added in the infrastructure to
increase the computation capability of the system. In
addition, a Cloud Storage provided by the Rackspace
Cloud is added in the infrastructure to enhance the
size of the storage.
After finishing the customization tasks, the busi-
ness process, the software components, the platform,
and the physical resources must be assembled to-
gether. The assemble is not shown in the example,
however, it is the last phase in the customization life
cycle.
5 CONCLUSIONS
This paper introduced a novel approach for customiz-
ing BPaaS following the multi-layered approach that
allows fine tuning the BPaaS solutions to satisfy the
enterprise specific requirements. One of the unique
characteristics of our approach is, it underpins tailor-
ing not only the business process services, but also
the SaaS, PaaS and IaaS that implement the business
process services in a transparent, tractable and struc-
tured manner. The research results in this paper are
core results in nature. Extensions and improvements
are needed to validate the customization life-cycle and
mechanisms. The proposed operators will have to be
formalized in near future.
REFERENCES
Columbus, L. (2012). Forecasing public cloud adoption in
the enterprise.
J. Hurwitz, M. Kaufman, F. H. and Kirch, D. (2012). What
is business process as a service(bpaas) in cloud com-
puting?
Leymann, F. and Roller, D. (2000). Production Workflow:
Concepts and Techniques. Printice Hall, Upper Saddle
River, NJ.
McCue, D. (2012). Business process as a service smbs:
Challenges and opportunities.
Stollberg, M. and Muth, M. (2009). Service customization
by variability modeling. In Proceedings of the 2009
international conference on Service-oriented comput-
ing, ICSOC/ServiceWave’09, pages 425–434, Berlin,
Heidelberg. Springer-Verlag.
Taher, Y., Haque, R., Parkin, M., Heuvel, W.-J., Richardson,
I., and Whelan, E. (2011). A multi-layer approach for
customizing business services. In Huemer, C. and Set-
zer, T., editors, E-Commerce and Web Technologies,
volume 85 of Lecture Notes in Business Information
Processing, pages 64–76. Springer Berlin Heidelberg.
Zhu, X. and Zheng, X. (2005). A template-based approach
for mass customization of service-oriented e-business
applications. In Proceedings of the 7th international
conference on Electronic commerce, ICEC ’05, pages
706–710, New York, NY, USA. ACM.
CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience
296
