Process as a Service - Distributed Multi-tenant Policy-based Process Runtime
Governance
MingXue Wang, Kosala Yapa Bandara and Claus Pahl
School of Computing
Dublin City University
Dublin 9, Ireland
[mwang|kyapa|cpahl]@computing.dcu.ie
Abstract—With the emergence of Business Process Outsourc-
ing and Cloud Computing, enterprises are looking for available
business processes outside of their organizations to quickly
adopt to new business requirements and also reduce process de-
velopment and maintenance costs. The process execution needs
to be governed as policy enforcement might differ between
different clients. Since a process is deployed outside of the
organizations and serves multiple process clients, distribution
and multi-tenancy have become two requirements for runtime
governance of service processes.
We address this problem by introducing a policy-oriented
aspectual business process framework. The runtime governance
constraints from process clients are integrated as aspects
through dynamic weaving into rpcess execution.
Keywords-business process; runtime policy; runtime gover-
nance; cloud.
I. INTRODUCTION
Service-oriented architecture (SOA) has become the stan-
dard for enterprise application development and integration.
Service processes based on WS-BPEL orchestrate service-
based business components as workflows to accomplishing
complex goals. On the business side, policies are created
throughout the enterprise to establish ’best practices’ or
standards, meet environmental or regulatory requirements, to
increase efficiency and to help streamline business processes
[1]. SOA governance defines and enforces the policies that
are needed to manage a SOA accordingly [2]. Based on the
service development lifecycle, business process governance
can be broken into design-time and runtime governance [2].
We aim at adopting existing processes, thus focussing on
runtime policies and governance.
With the emergence of Business Process Outsourcing and
Cloud Computing, enterprises are looking to adopt existing
processes to quickly take on new business opportunities and
tp save costa on process development and maintenance [3].
Process level collaboration has been becoming a necessity
for enterprises - c.f. the process as a service notion from
the cloud. However, simple service request/response ap-
proaches in conventional SOA [4] do not work for process-
level collaboration. A business process as an automation
of an organization’s workflow is obligatorily enforced by
organizations through the process clients’ policies. As a
consequence, we note the following as a need for process
services:
process request = (service) request + runtime governance
While SOA governance is only starting to become main-
stream practice, the advent of the cloud could reimpose the
governance challenge. ”Once we start using services from
the cloud or putting services out on the cloud, it’s going to
add another complicated layer to what we’re dealing with.
We’re not even starting to be ready to deal with it” [5]. To
take this challenge, we first analyse the problem: identifying
the unique governance requirements and features for pro-
cesses in new cloud environments compared to conventional
SOA:
1) The process is deployed outside the organization/pro-
cess client; it is executed by a process provider in the
cloud.
2) The process is decoupled from the organization; it
serves multiple process clients.
With above, two new requirements for runtime governance
can be identified:
1) Distributed – the process allows itself to be governed
by process clients remotely.
2) Multi-tenant – the process allows each client to gov-
erns its own process request instance without interfer-
ing with other clients.
We address above problems by introducing a policy-
oriented aspectual business processes concept. We apply the
AOP paradigm for distributed multi-tenant process runtime
governance. We develop abstract policy function compo-
nents in a business process as crosscuts, where the policy-
based governance as a crosscutting concern can be applied
as aspects. We outline our concept design in section 2. In
sections 3 and 4, we introduce policy categories for runtime
governance and provide abstract policy component designs
for each policy category. We show an aspects and weaving
design in section 4. The prototype and evaluation results are
presented in section 5. At the end, we compare our approach
with related work and give conclusions.
II. A
N AOP FRAMEWORK FOR POLICY-BASED RUNTIME
GOVERNANCE
A. AOP background
Aspect-oriented programming (AOP) is a programming
paradigm that increases modularity by allowing the separa-
tion of crosscutting concerns. An aspect is a modularization
of a concern that cuts across multiple objects. Join point,
Pointcut and Advice are key concepts introduced by AOP.
Join points are well-defined points during execution where
crosscutting code can be applied, e.g. calling a method
or reading a field. A pointcut is a collection of related
join points. An advice is the implementing crosscutting
code, applied to a declared pointcut. The type of advice
(such as before/after) indicates when to apply it. Central to
AOP is weaving, which introduces the advice code at the
captured join points of the target program. Regarding BPEL
processes, AOP concept has be adopted for BPEL to support
dynamic changes of business processes [6], [7].
B. Policy oriented aspects
We apply the AOP concept for policy-based runtime
governance of business processes. The process development
and runtime governance module development is separated
for process provider and clients (Figure 1). The provider
focuses on capturing a set of business tasks that model the
functional behavior of the process workflow. The policy-
based runtime governance as non-functional requirements
are applied to the business process as aspects. In this case,
the non-functional requirements are not limited to quality
concerns, but also the functional behavior configuration (e.g.
options of the post method), compliance, and recovery –
which are all concerned with the policies – can be included.
• Policy (function) components are Web services of busi-
ness processes, as connectors between processes and
policy engines as implementations. They allow a busi-
ness process, given an input, to provide an output based
on the policy to govern the process execution.
• Crosscuts Once a policy function component of a
business process has been identified, it needs to be
developed and instrumented in a process before deploy-
ment. These integrated policy components are abstract
policy services as crosscuts of the process workflow.
These crosscuts are where the possible concrete policy
function implementations can be executed in the pro-
cess. This transforms the business process to a policy-
oriented aspectual BPEL process where the policy-
based runtime governance is considered as a crosscut-
ting concern of process execution.
• Join points The business workflow can be broken into
three types of policy-related process elements (business
activity, data/business object, business fault) to model
the join points. All crosscuts are associated with join
points, which give identities to crosscuts.
• Pointcuts These are predicates that match join points.
They allow any crosscut of a business process to be
queried to apply concerted policy implementations.
Table I shows the basic pointcut declarations.
• Advices are implementations of the abstract policy
components. They are implemented by process clients
and provide concrete policy functions by executing the
code.
• Aspects are packages coupling specified abstract policy
components (pointcuts) with the concrete policy imple-
mentations (advices). For each client, the valid range of
its aspects are only process instances that are created
for its own requests.
• Weaving is matching of aspects with integrated abstract
policy components of a process during process execu-
tion. Once the pointcut of an aspect is matched with the
identity (weavingRequest) of an abstract policy com-
ponent, the advice of the aspect will be executed. The
responses of all executed advices (weavingResponse)
will be returned by the abstract policy component.
Pointcut Description
Invoke (Web service
operation signature)
Select join points whenever the spec-
ified business activity is executed.
Process (message ele-
ment signature)
Select join points whenever the speci-
fied business/data object is processed.
Handle (fault signa-
ture)
Select join points whenever the spec-
ified business fault occurs.
Table I
B
ASIC POINTCUT DECLARATIONS
In following section, we first identify different categories
of business policy, then define abstract policy components
for these policies, i.e. determining all crosscuts of a business
process.
III. A
CLASSIFICATION OF BUSINESS POLICY
Business policies are widely implemented in business
process in industry, especially in finance and insurance
sectors. However, business policies change frequently and
policies that apply to multiple services and processes can
introduce redundancy and inconsistency within service logic
and contracts [8]. Hence, runtime polices have be separated
from processes in development, formalized as business rules.
These express the policies as business decisions and are
centralized in a rule management system. Rule or policy
components are integrated in the processes as runtime
governance for policy enforcement. All processes can be
automatically updated by changing business rules in one
central location without redeveloping and redeploying the
processes.
Runtime governance
(process client 2)
Monitor + controller
Weaver
Business policy
Runtime governance
(process client 1)
BPEL engine
Policy oriented aspectual BPEL process
Business
process
Process
instrumentation
r
o
c
e
s
s
e
n
g
i
n
e
e
r
(
b
u
s
i
n
e
s
s
t
a
s
k
s
)
Process engineer
(business tasks)
Monitor + controller
Weaver
Business policy
r
o
c
e
s
s
e
n
g
i
n
e
e
r
(
b
u
s
i
n
e
s
s
p
o
l
i
c
i
e
s
)
Process engineer
(business policies)
Business policy
layer
Process governor
layer
Service process
layer
Web service
layer
Multi-tenant
Distributed
r
o
c
e
s
s
e
n
g
i
n
e
e
r
(
b
u
s
i
n
e
s
s
p
o
l
i
c
i
e
s
)
Process engineer
(business policies)
WWW
Ignorable abstract policy components
Figure 1. Distributed multi-tenant service process runtime governance
In recent research, business rules have been categorised
into three types [9]: integration rule, derivation rule and
reaction rule. While this shows different types of formal
expression of the business policies, it does not give any
concrete meaning to a business process. It is hard to establish
a common connection between policies and the process.
Based on the action areas of the process execution, we
categorise the policies for runtime governance in three
different categories:
1) Within the safe boundary – this business policy cate-
gory expresses the business decisions within the safe
boundary of the process execution. The business steps
continue after the decisions are made. It is used to
specify variable business decision logic for various
expected business scenarios such as different customer
types, different types of post method use or frequently
changing agreements (e.g. different discount rate over
times). The business dynamics is the driving force.
2) On the safe boundary – this business policy category
defines the safe boundary of the process execution to
restrict business behavior. Policies are expressed as
integration or constraint rules to specify assertions that
must be satisfied in all states of the process execution
such as ServicesLevel Agreements (SLA). This rules
make sure the business complies with regulations.
3) Outside the safe boundary – this type of business
policy defines the business reaction when the process
crosses the safe boundary, i.e., the constraints are
violated. The business needs to decide what remedial
strategy is required to avoid potential subsequential
failure of the business goal. Since the constraint vio-
lations are viewed as ’faults’ of process executions,
this policy category is also known as fault policy.
Examples are Oracle’s fault policy management [10].
Policy components for different policy categories are used
for different governing actions. Based on [11], [12], [13],
[14], [15], we can correlate process governing actions – see
table II. Policy components have different interface and can
be integrated at different locations of the process workflow.
These interfaces and locations will be identified in next
section.
Policy category Correlated governing actions
Within the safe boundary Business flow and data control
On the safe boundary Constraint validation
Outside the safe boundary Remedy determination
Table II
C
ONNECTIONS BETWEEN BUSINESS POLICY AND PROCESS
IV. INTEGRATING ABSTRACT POLICY COMPONENTS
INTO BUSINESS PROCESSES
With the process as a service notion, the provider expects
the process to be available serviceable for more process
clients. Hence, the maximum governability is an important
goal in process design. More policies can be applied to the
process to meet the various requirements of clients – for
example, adding a policy component (getPostage) rather than
assuming the postage is fixed by the courier as a client may
offer free postage for its customers. While we are not going
to discuss process design here, we identify different types
of policy component and integration in our approach. We
discuss how and where they can be integrated in a business
process for different policy categories.
A. Ignorable abstract policy components
All policy components integrated in a business process
are ’ignorable’ and ’abstract’. Ignorable means the policy
component has a default output. It will not halt the process
execution, if the client does not have a concrete imple-
mentation for it. Abstract means the real output is based
on the policies, which are implemented and executed by
the client. These integrated abstract components are key to
enable client-side runtime governance. The following shows
the basic structure inside the abstract policy component.
During process execution, each encountered abstract policy
component sends the current crosscut information weaving
(Request) to the weaver of the client and waits for output in
(weavingResponse).
Output = default value;
//try to get the result from the client
weavingResponse = call weaving(weavingRequest);
if weavingResponse != empty then
output = weavingResponse;
return output
The ’weavingRequest’ is a complexType, which consists
of following information: processReference - current pro-
cess identity (includes a unique process instance id created
for each process request). serviceReference - identity of
the associated business activity service. dataObject - input
SOAP message of the business service. adviceType - advice
type (before/after/replace/none). violationData - details of
constraint violations. The ’weavingResponse’ consists of
following: dataObject - output SOAP message of the busi-
ness service. violationData - details of constraint violations.
remdialStrategy - selected remedial strategy to be applied to
current process.
However, not all the above information has be provided
and be the same in each weaving call. Depending on the
governing actions used for different policy categories, we
have identified three types of abstract policy components
(see Table III).
B. Policies within the safe boundary
The policy within the safe boundary is able to control
both business flow and data of the process. Flow control is
made by branch selection, the different business actions as
different branches are developed in process workflows for
possible results of the business decision. The policy compo-
nent as decisions point (e.g. getPostMethod in Figure 2) is
integrated into the workflow before a control flow structure,
such as BPEL-if or switch structures. The corresponding
branch is selected after is decision is made based on the
policy – for example if the item value is less than 20 euro,
then delivery as normal post, else delivery as registered post.
This type of policy component is designed and integrated in
the process by the process developer. The default value is
also provided by the developer. Still, the default value must
be careful chosen for loop structures, as infinite loops can
be caused.
getPostMethod
<
p
r
o
c
e
s
s
R
e
f
e
r
e
n
c
e
>
.
.
.
<
/
p
r
o
c
e
s
s
R
e
f
e
r
e
n
c
e
>
B
u
s
i
n
e
s
s
a
c
t
i
v
i
t
y
:
<
s
e
r
v
i
c
e
R
e
f
e
r
e
n
c
e
>
.
.
g
e
t
P
o
s
t
M
e
t
h
o
d
.
.
<
/
s
e
r
v
i
c
e
R
e
f
e
r
e
n
c
e
>
D
a
t
a
o
b
j
e
c
t
:
<
d
a
t
a
O
b
j
e
c
t
>
.
.
.
g
e
t
P
o
s
t
M
e
t
h
o
d
i
n
p
u
t
.
.
.
<
/
d
a
t
a
O
b
j
e
c
t
>
A
d
v
i
c
e
t
y
p
e
:
<
a
d
v
i
c
e
T
y
p
e
>
r
e
p
l
a
c
e
<
/
a
d
vi
c
e
T
y
p
e
>
<processReference>...</processReference>
Business activity:
<serviceReference>..getPostMethod ..</
serviceReference>
Data object:
<dataObject>...getPostMethod input ...</
dataObject>
Advice type:
<adviceType>replace</adviceType>
<
w
e
a
v
i
n
g
R
e
s
p
o
n
s
e
>
D
a
t
a
o
b
j
e
c
t
:
<
d
a
t
a
O
b
j
e
c
t
>
n
o
r
m
a
l
<
/
d
a
t
a
O
b
j
e
c
t
>
<
/
w
e
a
v
i
n
g
R
e
s
p
o
n
s
e
>
<weavingResponse>
Data object:
<dataObject>normal</dataObject>
</weavingResponse>
Weaving component
interface
Aspect
<getPostMethodOperation>
… input...
</getPostMethodOperation>
Business service
(normalPost)
Business service
(registeredPost)
Figure 2. Policy component as business activity
There are two different scenarios with data control. The
first scenario is the same as flow control. The policy com-
ponents (e.g. getPostage) are designed and integrated by the
process developer, e.g., if the item value is more than 100
euro, then the postage is free. The default value is also
provided by the developer. In this example, it might be the
standard postage from courier.
There are two types of abstract policy component inte-
gration for a business process. The above two examples
(getPostMethod and getPostage) are of the first type, where
the policy component itself is a business activity, which is
designed and integrated by the developer (first row of Table
III). The serviceReference.operation of weavingRequest is
getPostMethod. The AdviceType is replace, since it is itself
is a business activity. The expected information of weav-
ingReponse is a dataObject – a decided post method or a
postage fee. The default value of this type policy component
is assigned by the developer.
The second category of policy components are instru-
mented in the business process for other business activities.
In the second scenario with data control, the policy compo-
nent could be applied at any point of the process data flow
(i.e., before and after each business service) to modify the
business data object passing through the component. This
Integration Governing actions weavingRequest Expected weav-
ingResponse
Associated join points
By process developer
(e.g. getPostMethod ser-
vice)
Business flow and data
control
processReference
serviceReference
dataObject
adviceType=replace
dataObject business activity
data object
Instrumentation
(before/after service)
Business data control and
constraint validation
processReference
serviceReference
dataObject
adviceType=before/after
dataObject
violationData
business activity
data object
Instrumentation
(handler service)
Remedy determination violationData
adviceType=none
remedialStrategy business fault
Table III
T
HREE TYPES OF ABSTRACT POLICY COMPONENT
could be used to apply the policy which was not considered
during the process development. For example, with a policy
made for a business promotion: if the payment amount is
more than 200 euro, then give 5% discount on the payment.
The process client could apply this policy by modifying
the amount value before the payment business service is
executed. In this case, the serviceReference.operation of
weavingRequest is the payment. The dataObject is the input
message of the payment service, which is also the default
value of the output. The adviceType is before. The expected
weavingReponse is a dataObject – the modified payment
amount.
C. Policies on the safe boundary
Policies on the business safe boundary can be divided
as two types of constraints for each business activity of
the process – pre-condition and post-condition constraints.
The pre-condition validation is inserted before each business
service (adviceType=before); the post-condition is inserted
after each business service (adviceType=after). Constraints
can be made for the business data which the business activity
processes, e.g., (if the total payment > 5000, then violation
of syntax constraint.), but also as properties of business
activity profiles, e.g., (if the trust of the payment service
< 3, then violation of trust constraint.). In this case, the
expected weavingResponse is a violationData, which might
contain a set of violation types or is empty. If it is empty,
then the payment service will be executed; otherwise the
policy component should throw the violation as a business
fault. The default value is an empty violation variable.
Since we can see two types of abstract policy compo-
nents appearing twice in same location (second scenario of
data control and constraint validation) before each business
activity. We could merge two components as one before-
crosscut service (see second row of Table III and Figure 3)
to reduce the number of abstract policy components in a
process. The idea is that the violations (violationData) will
not been thrown by the policy component itself. A following
BPEL Iif structure checks if the violationData is empty. If
it is not empty, the violation data is copied into a defined
BPEL Exception (constraintViolation) and is thrown by a
BPEL Throw activity.
Before crosscut
service
Business service
(payment)
<paymentOperation>
… input...
</paymentOperation>
Assign
Copy
beforeResponse/dataObject
to
<paymentOperation>
...
</paymentOperation>
beforeResponse/violationData/... == empty
Throw
(constraintViolation
- business fault)
!= empty
p
r
o
c
e
s
s
R
e
f
e
r
e
n
c
e
>
.
.
.
<
/
p
r
o
c
e
s
s
R
e
f
e
r
e
n
c
e
>
B
u
s
i
n
e
s
s
a
c
t
i
v
i
t
y
:
<
s
e
r
v
i
c
e
R
e
f
e
r
e
n
c
e
>
.
.
.
p
a
y
m
e
n
t
.
.
.
<
/
s
e
r
v
i
c
e
R
e
f
e
r
e
n
c
e
>
D
a
t
a
o
b
j
e
c
t
:
<
d
a
t
a
O
b
j
e
c
t
>
.
.
.
p
a
y
m
e
n
t
s
e
r
v
i
c
e
i
n
p
u
t
.
.
.
<
/
/
d
d
d
a
t
a
O
b
j
e
c
t
>
A
d
v
i
c
e
t
y
p
e
:
<
a
d
v
i
c
e
T
y
p
e
>
b
e
f
o
r
e
<
/
a
d
v
i
c
e
T
y
p
e
>
<processReference>...</processReference>
Business activity:
<serviceReference>...payment...</serviceReference>
Data object:
<dataObject>...payment service input ...</dataObject>
Advice type:
<adviceType>before</adviceType>
D
a
t
a
o
b
j
e
c
t
:
<
d
a
t
a
O
b
j
e
c
t
>
.
.
.
<
/
d
a
t
a
O
b
j
e
c
t
>
C
o
n
s
t
r
a
i
n
t
v
i
o
l
a
t
i
o
n
:
<
v
i
o
l
a
t
i
o
n
D
a
t
a
>
p
r
o
c
e
s
s
d
a
t
a
:
.
.
.
B
u
s
i
n
e
s
s
a
c
t
i
v
i
t
y
d
a
t
a
:
…
C
o
n
d
i
t
i
o
n
t
y
p
e
:
<
c
o
n
d
i
t
i
o
n
T
y
p
e
>
p
r
e
<
/
c
o
n
d
i
t
i
o
n
T
y
p
e
>
C
o
n
s
t
r
a
i
n
t
v
i
o
l
a
t
i
o
n
s
:
<
v
i
o
l
a
t
i
o
n
T
y
p
e
s
>
…
<
/
v
i
o
l
a
t
i
o
n
T
y
p
e
s
>
<
/
v
i
o
l
a
t
i
o
n
D
a
t
a
>
Data object:
<dataObject>...</dataObject>
Constraint violation:
<violationData>
process data:...
Business activity data: …
Condition type:
<conditionType>pre</conditionType>
Constraint violations :
<violationTypes>
…
</violationTypes>
</violationData>
Weaving component
interface
Aspect
Assign
Copy
beforeResponse/
violationData
to
constraintViolation
Figure 3. Policy component before business activity
A corresponding after-crosscut service is also instru-
mented after each business activity. It is almost the same as
the before-crosscut service, except it has an after-advice type
in the weaverRequest. It is used for business service output
modification and post-condition validation. Both before/after
services can also be used to capture the temporary data
required for the working memory of the rule engine.
D. Policies outside the safe boundary
When the constraintViolaton exception is thrown, it indi-
cates that process execution has crossed the safe business
boundary. In this case, the fault policy is in charge of the
process governance. ”A critical dimension of your SOA
Governance model is how you will anticipate and deal
