CAiSE 2013 - Valencia, Spain

1
Process Instances

1

2

User

Business Process Engine
Business Process Definition
1

Modelling

2

Enactment
2
Evolutionary

Ad-hoc
Process Instances

1

2

User

Business Process Engine
Business Process Definition
1

Modelling

2

Enactment

[van der Aalst, 2001]
3
• RoSAS : Roadside Assistance as a Service.

A Motorist

RoSAS

Tow Trucks

Call Center

Garages

Paramedics

Taxis

4
• RoSAS defines the control-flow.
• Providing roadside assistance is a long lived process.
• Unpredictability.
• Example 1: Ms. Swan (a motorist) requests to delay the towing until a
taxi picks her up (its raining now and the car is the only shelter).
• Example 2: Mr. Doe (another motorist) requests a notification once the
towing is complete (he drives an Aston Martin v12).
• Both above scenarios.
• Are not captured by RoSAS in its business process definition because
those are unpredictable or are not commonly occurred.
• Need be supported if possible to enhance RoSAS’s reputation due to
customer oriented nature of the business.

5
• WS-BPEL - the de-facto standard.
• Block structured control-flow (imperative programming).
• Have been criticized for lack of flexibility.
• Proposed improvements
• Template Customization, Aspect-orientation, ...
• Template customization
• A technique used to generate a highly optimized fitting process that suits
the situation in demand from a pre-defined template.
E.g., [Mietzner, 2008], [Ardagna, 2007]
• However, requires re-generating a new process.
• Aspect-Orientation
• A technique used to weave variation points to a core business process
(similar to Aspect oriented programming)
E.g., [Charfi, 2007], [Michiel, 2009]
• However, requires identifying the fixed and volatile parts.
• Other solutions
• Constraint-satisfaction. E.g., DecSerFlow [Pesic, 2006]
• Dynamic Changes. E.g., Skip/Retry [Fang, 2008]
6
• The tight coupling between activities/tasks of a business process as enforced
by the modelling language.
• The over-specification of control-flow. An unnecessary restriction to adapt
process instances.

tRequestTow

tTow

• Above denotes that, the pre-condition of task tTow is the completion of task
tRequetTow.
• What if a new dependency need to be introduced during the runtime?
• Looks like an over-specification of task dependencies.

7
• Be explicit about the dependencies in the specification.
• Tasks need to be decoupled by localizing the dependencies.
• Event-driven task-decoupling.
Loose-coupling
Post-conditions

Pre-conditions
tTow

tRequestTow
An Event Pattern
Task tRequestTow {
preEP "eComplaintRcvd AND eWithinTowZone";
postEP "eTowReqd";
}

Event-driven task decoupling

Task tTow {
preEP "eTowReqd";AND eTaxiProvided";
postEP "eTowSuccess XOR eTowFailed";
}
Task tSendSpecialNotification{
preEP “eTowSuccess";
postEP “SpecialNotifcationSent";
}

8
Event X
Event Y
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
Process Instance id=p0123

9
• Tasks localize their pre- and post-conditions as patterns of events.
• Tasks are declaratively defined in modular units called Behaviour Units.
• A Process Definition is a collection of references to such Behaviour Units.
(Process re-use [Kapuruge, WISE 2011])
• A Process Definition also specifies the Condition of Start (CoS) and Condition
of Termination (CoT)
• Constraints are specified in both Behaviour Units and Process Definitions.
(Controlled-flexibility [Kapuruge, SCC 2011])
Behaviour bTowing{
Task CO.tRequestTow {
preEP "eComplaintRcvd * eWithinTowZone";
postEP "eTowReqd"; }
Task TT.tTow {
preEP "eTowReqd";
postEP "eTowSuccess ^ eTowFailed";
}
Task CO.tPay {
preEP "eTowSuccess";
postEP "eTTPaid"; }
Const c1: "(eTowSuccess>0) -> (eTTPaid>0)";
}

ProcessDefinition pdAssist {
CoS "eComplaintRcvd";
CoT "eMMNotifDone";
BehaviourRef bComplaining;
BehaviourRef bTowing;
BehaviourRef bRepairing;
BehaviourRef bTaxiProviding;
Const c5:"(eComplaintRcvd>0)->
(eComplainAcked>0)";
}

10
Process Definition

Refer

Organisation

Behavior Unit

Role

Refer

Event Pattern

Task

Pre/Post
Conditions

11
• Existing service orchestration runtimes (e.g., Apache ODE, Active VOS) are
designed to execute tightly-coupled control-flows.
• If used to enact Serendip processes, the flexibility at runtime is limited.
• A new service orchestration runtime is required.
• Models@runtime + Pub-sub mechanism.

AMS : Adaptation Management System
FS: Functional System

12
• Individual models corresponding to tasks (TiM) and process instances (PiM)
are maintained in Model-Provider-Factory (MPF).
• These models could be individually adapted (explained later).
• An EPC (Event-driven Process Chain) view is dynamically constructed based
on up-to-date models [Kapuruge, 2012]

Runtime
Models

Model Provider Factory
PiM
TiM

p004
p003
p002
p001

13
•
•
•
•
•
•

Event-cloud, a repository of events.
Publishers e.g., Tasks, can publish events in the event-cloud.
Subscribers e.g., Tasks, Process Instances can subscribe to these events.
Upon completion of subscribed event-pattern, the subscriber is notified.
Subscribers can be dynamically added.
Event-patterns can be subjected to late changes.
Publish
Publisher
e.g., TiM
Subscribe
Subscriber
e.g., TiM, PiM

The Event Cloud
e
e
e e
p001
e e
e
e
e
Event
e
e
Repo
e
s1

Notify

s2

s3

...

Subscriber List

14
• Designed to systematically manage adaptations.
• To ensure process consistency and business integrity.
• Adaptation commands can be issued as a batch (Adaptation Script).
• A Script can contain multiple adaptation commands (steps).
INST: p124{ Process instance id
updateTaskOfProcessInst tId= "tTow" prop="postEP"
value="(eTowSuccess AND (eInMetro XOR eInRegional)) XOR
eTowFailed " ;
addTaskToProcessInst tId= "tSendSpecialNotif" preEP=" eInMetro "
obligRole="CO" ;
}
• Adaptation commands of a single script are
• Carried out in a single transaction (to ensure ACID properties).
• Carried out in safe states (to ensure state-consistency of models).
• Rejected if not possible.
15
16
• Evaluated against Change Patterns [Weber et al., 2007]
• Change Patterns -> Patterns that should be supported by an adaptive
process aware information system.
• All adaptation patterns (AP) and patterns for pre-defined changes (PP) can be
supported. Some change support features (CF) are not supported.

AP 1 2
3 4 5 6
PP 1 2
3 4
CF 1.a 1.b 1.c 2 3 4
X = Not Supported

7

8

5

9

10 11 12 13

6

17
• Evaluated against Apache ODE (Both SOR and ODE uses Axis2 as the
framework).
• Slightly slower than Apache ODE.

ODE

Avg Response Time
(σ = Std. Dev)

SOR

Δt1 = 181.71 ms
(σ = 0.30)

Δt2 = 191.61 ms
(σ = 0.12)

Percentage Performance Lost (PPL) =

Δ𝑡2 Δ𝑡1
−
Δ𝑡1

x 100 % = 5.448%

18
•
•
•
•
•
•
•
•

•
•
•
•

[van der Aalst., 2001] : van der Aalst, W.M.P.: Exterminating the Dynamic Change Bug: A Concrete Approach to
Support Workflow Change. Information Systems Frontiers. Vol. 3,pp. 297-317 (2001)
[Mietzner, 2008]: Mietzner, R., Leymann, F.: Generation of BPEL Customization Processes for SaaS Applications
from Variability Descriptors. In: Services Computing (SCC), pp. 359-366. (2008)
[Ardagna, 2007]: Ardagna, D., Comuzzi, M., Mussi, E., Pernici, B., Plebani, P.: PAWS: A Framework for Executing
Adaptive Web-Service Processes. IEEE Software. Vol. 24,pp. 39-46 (2007)
[Charfi, 2007] : Charfi, A., Aspect-Oriented Workow Languages: AO4BPEL and Applications. Darmstadt University
of Technology, Darmstadt, Germany. (2007)
[Michiel, 2009]: Michiel, K., Chang-ai, S., Marco, S., Paris, A.: VxBPEL: Supporting variability for Web services in
BPEL. Information and Software Technology. Vol. 51,pp. 258-269 (2009)
[Pesic, 2006]: Pesic, M., van der Aalst, W.M.P.: A Declarative Approach for Flexible Business Processes
Management. Business Process Management Workshops, pp. 169-180 (2006)
[Fang, 2008]: Fang, R., Zou, Z.L., Stratan, C., Fong, L., Marston, D., Lam, L., Frank, D.: Dynamic Support for
BPEL Process Instance Adaptation. In: IEEE International Conference on Services Computing, pp. 327-334. IEEE
Computer Society, (2008)
[Dadam, 2007]: Dadam, P., Reichert, M.U., Rinderle, S.B., Jurisch, M., Acker, H., Göser, K., Kreher, U., Lauer, M.:
ADEPT2 - Next Generation Process Management Technology. In: Fourth Heidelberg Innovation Forum. D.punkt
Verlag, (2007)
[Kapuruge, WISE 2011]: Kapuruge, M., Colman, A., Han, J.: Achieving Multi-tenanted Business Processes in SaaS
Applications. In: Web Information System Engineering (WISE), pp. 143-157. Springer Berlin / Heidelberg, (2011)
[Kapuruge, SCC 2011]: Kapuruge, M., Colman, A., Han, J.: Controlled flexibility in business processes defined for
service compositions. In: Services Computing (SCC) pp. 346-353. IEEE Press, (2011)
[Kapuruge, 2012]: Kapuruge, M., Orchestration as Organisation. PhD Thesis, Swinburne University of Technology,
Melbourne. (2012)
[Weber, 2007]:Weber, B., Rinderle, S., Reichert, M.: Change Patterns and Change Support Features in ProcessAware Information Systems. Advanced Information Sys. Eng., pp. 574-588 (2007)

19
20

Enabling Ad-hoc Business Process Adaptations through Event-driven Task Decoupling

  • 1.
    CAiSE 2013 -Valencia, Spain 1
  • 2.
    Process Instances 1 2 User Business ProcessEngine Business Process Definition 1 Modelling 2 Enactment 2
  • 3.
    Evolutionary Ad-hoc Process Instances 1 2 User Business ProcessEngine Business Process Definition 1 Modelling 2 Enactment [van der Aalst, 2001] 3
  • 4.
    • RoSAS :Roadside Assistance as a Service. A Motorist RoSAS Tow Trucks Call Center Garages Paramedics Taxis 4
  • 5.
    • RoSAS definesthe control-flow. • Providing roadside assistance is a long lived process. • Unpredictability. • Example 1: Ms. Swan (a motorist) requests to delay the towing until a taxi picks her up (its raining now and the car is the only shelter). • Example 2: Mr. Doe (another motorist) requests a notification once the towing is complete (he drives an Aston Martin v12). • Both above scenarios. • Are not captured by RoSAS in its business process definition because those are unpredictable or are not commonly occurred. • Need be supported if possible to enhance RoSAS’s reputation due to customer oriented nature of the business. 5
  • 6.
    • WS-BPEL -the de-facto standard. • Block structured control-flow (imperative programming). • Have been criticized for lack of flexibility. • Proposed improvements • Template Customization, Aspect-orientation, ... • Template customization • A technique used to generate a highly optimized fitting process that suits the situation in demand from a pre-defined template. E.g., [Mietzner, 2008], [Ardagna, 2007] • However, requires re-generating a new process. • Aspect-Orientation • A technique used to weave variation points to a core business process (similar to Aspect oriented programming) E.g., [Charfi, 2007], [Michiel, 2009] • However, requires identifying the fixed and volatile parts. • Other solutions • Constraint-satisfaction. E.g., DecSerFlow [Pesic, 2006] • Dynamic Changes. E.g., Skip/Retry [Fang, 2008] 6
  • 7.
    • The tightcoupling between activities/tasks of a business process as enforced by the modelling language. • The over-specification of control-flow. An unnecessary restriction to adapt process instances. tRequestTow tTow • Above denotes that, the pre-condition of task tTow is the completion of task tRequetTow. • What if a new dependency need to be introduced during the runtime? • Looks like an over-specification of task dependencies. 7
  • 8.
    • Be explicitabout the dependencies in the specification. • Tasks need to be decoupled by localizing the dependencies. • Event-driven task-decoupling. Loose-coupling Post-conditions Pre-conditions tTow tRequestTow An Event Pattern Task tRequestTow { preEP "eComplaintRcvd AND eWithinTowZone"; postEP "eTowReqd"; } Event-driven task decoupling Task tTow { preEP "eTowReqd";AND eTaxiProvided"; postEP "eTowSuccess XOR eTowFailed"; } Task tSendSpecialNotification{ preEP “eTowSuccess"; postEP “SpecialNotifcationSent"; } 8
  • 9.
  • 10.
    • Tasks localizetheir pre- and post-conditions as patterns of events. • Tasks are declaratively defined in modular units called Behaviour Units. • A Process Definition is a collection of references to such Behaviour Units. (Process re-use [Kapuruge, WISE 2011]) • A Process Definition also specifies the Condition of Start (CoS) and Condition of Termination (CoT) • Constraints are specified in both Behaviour Units and Process Definitions. (Controlled-flexibility [Kapuruge, SCC 2011]) Behaviour bTowing{ Task CO.tRequestTow { preEP "eComplaintRcvd * eWithinTowZone"; postEP "eTowReqd"; } Task TT.tTow { preEP "eTowReqd"; postEP "eTowSuccess ^ eTowFailed"; } Task CO.tPay { preEP "eTowSuccess"; postEP "eTTPaid"; } Const c1: "(eTowSuccess>0) -> (eTTPaid>0)"; } ProcessDefinition pdAssist { CoS "eComplaintRcvd"; CoT "eMMNotifDone"; BehaviourRef bComplaining; BehaviourRef bTowing; BehaviourRef bRepairing; BehaviourRef bTaxiProviding; Const c5:"(eComplaintRcvd>0)-> (eComplainAcked>0)"; } 10
  • 11.
  • 12.
    • Existing serviceorchestration runtimes (e.g., Apache ODE, Active VOS) are designed to execute tightly-coupled control-flows. • If used to enact Serendip processes, the flexibility at runtime is limited. • A new service orchestration runtime is required. • Models@runtime + Pub-sub mechanism. AMS : Adaptation Management System FS: Functional System 12
  • 13.
    • Individual modelscorresponding to tasks (TiM) and process instances (PiM) are maintained in Model-Provider-Factory (MPF). • These models could be individually adapted (explained later). • An EPC (Event-driven Process Chain) view is dynamically constructed based on up-to-date models [Kapuruge, 2012] Runtime Models Model Provider Factory PiM TiM p004 p003 p002 p001 13
  • 14.
    • • • • • • Event-cloud, a repositoryof events. Publishers e.g., Tasks, can publish events in the event-cloud. Subscribers e.g., Tasks, Process Instances can subscribe to these events. Upon completion of subscribed event-pattern, the subscriber is notified. Subscribers can be dynamically added. Event-patterns can be subjected to late changes. Publish Publisher e.g., TiM Subscribe Subscriber e.g., TiM, PiM The Event Cloud e e e e p001 e e e e e Event e e Repo e s1 Notify s2 s3 ... Subscriber List 14
  • 15.
    • Designed tosystematically manage adaptations. • To ensure process consistency and business integrity. • Adaptation commands can be issued as a batch (Adaptation Script). • A Script can contain multiple adaptation commands (steps). INST: p124{ Process instance id updateTaskOfProcessInst tId= "tTow" prop="postEP" value="(eTowSuccess AND (eInMetro XOR eInRegional)) XOR eTowFailed " ; addTaskToProcessInst tId= "tSendSpecialNotif" preEP=" eInMetro " obligRole="CO" ; } • Adaptation commands of a single script are • Carried out in a single transaction (to ensure ACID properties). • Carried out in safe states (to ensure state-consistency of models). • Rejected if not possible. 15
  • 16.
  • 17.
    • Evaluated againstChange Patterns [Weber et al., 2007] • Change Patterns -> Patterns that should be supported by an adaptive process aware information system. • All adaptation patterns (AP) and patterns for pre-defined changes (PP) can be supported. Some change support features (CF) are not supported. AP 1 2 3 4 5 6 PP 1 2 3 4 CF 1.a 1.b 1.c 2 3 4 X = Not Supported 7 8 5 9 10 11 12 13 6 17
  • 18.
    • Evaluated againstApache ODE (Both SOR and ODE uses Axis2 as the framework). • Slightly slower than Apache ODE. ODE Avg Response Time (σ = Std. Dev) SOR Δt1 = 181.71 ms (σ = 0.30) Δt2 = 191.61 ms (σ = 0.12) Percentage Performance Lost (PPL) = Δ𝑡2 Δ𝑡1 − Δ𝑡1 x 100 % = 5.448% 18
  • 19.
    • • • • • • • • • • • • [van der Aalst.,2001] : van der Aalst, W.M.P.: Exterminating the Dynamic Change Bug: A Concrete Approach to Support Workflow Change. Information Systems Frontiers. Vol. 3,pp. 297-317 (2001) [Mietzner, 2008]: Mietzner, R., Leymann, F.: Generation of BPEL Customization Processes for SaaS Applications from Variability Descriptors. In: Services Computing (SCC), pp. 359-366. (2008) [Ardagna, 2007]: Ardagna, D., Comuzzi, M., Mussi, E., Pernici, B., Plebani, P.: PAWS: A Framework for Executing Adaptive Web-Service Processes. IEEE Software. Vol. 24,pp. 39-46 (2007) [Charfi, 2007] : Charfi, A., Aspect-Oriented Workow Languages: AO4BPEL and Applications. Darmstadt University of Technology, Darmstadt, Germany. (2007) [Michiel, 2009]: Michiel, K., Chang-ai, S., Marco, S., Paris, A.: VxBPEL: Supporting variability for Web services in BPEL. Information and Software Technology. Vol. 51,pp. 258-269 (2009) [Pesic, 2006]: Pesic, M., van der Aalst, W.M.P.: A Declarative Approach for Flexible Business Processes Management. Business Process Management Workshops, pp. 169-180 (2006) [Fang, 2008]: Fang, R., Zou, Z.L., Stratan, C., Fong, L., Marston, D., Lam, L., Frank, D.: Dynamic Support for BPEL Process Instance Adaptation. In: IEEE International Conference on Services Computing, pp. 327-334. IEEE Computer Society, (2008) [Dadam, 2007]: Dadam, P., Reichert, M.U., Rinderle, S.B., Jurisch, M., Acker, H., Göser, K., Kreher, U., Lauer, M.: ADEPT2 - Next Generation Process Management Technology. In: Fourth Heidelberg Innovation Forum. D.punkt Verlag, (2007) [Kapuruge, WISE 2011]: Kapuruge, M., Colman, A., Han, J.: Achieving Multi-tenanted Business Processes in SaaS Applications. In: Web Information System Engineering (WISE), pp. 143-157. Springer Berlin / Heidelberg, (2011) [Kapuruge, SCC 2011]: Kapuruge, M., Colman, A., Han, J.: Controlled flexibility in business processes defined for service compositions. In: Services Computing (SCC) pp. 346-353. IEEE Press, (2011) [Kapuruge, 2012]: Kapuruge, M., Orchestration as Organisation. PhD Thesis, Swinburne University of Technology, Melbourne. (2012) [Weber, 2007]:Weber, B., Rinderle, S., Reichert, M.: Change Patterns and Change Support Features in ProcessAware Information Systems. Advanced Information Sys. Eng., pp. 574-588 (2007) 19
  • 20.