The ability to adapt running process instances is a key requirement to handle exceptions in service orchestrations. The design of the orchestration middleware and its underlying meta-model plays an important role to fulfill this requirement. However, current service orchestration middleware such as BPEL engines suffer from their imperative and tightly coupled task execution mechanisms making it difficult to adapt running process instances. In this paper we present a novel service orchestration middleware and its underlying meta-model to overcome this limitation. To achieve this, we combine the benefits of the models@runtime concept with the event-driven publish-subscribe mechanism. We evaluate our approach for its support to process instance adaptation and compare its performance to an existing orchestration runtime. http://link.springer.com/chapter/10.1007%2F978-3-642-38709-8_25

1. CAiSE 2013 - Valencia, Spain
1

2. Process Instances
1
2
User
Business Process Engine
Business Process Definition
1
Modelling
2
Enactment
2

3. Evolutionary
Ad-hoc
Process Instances
1
2
User
Business Process Engine
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 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

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

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

9. Event X
Event Y
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
Process Instance id=p0123
9

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

11. Process Definition
Refer
Organisation
Behavior Unit
Role
Refer
Event Pattern
Task
Pre/Post
Conditions
11

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

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

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

15. • 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. 16

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

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

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