Upload
malinda-kapuruge
View
533
Download
1
Tags:
Embed Size (px)
DESCRIPTION
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
Citation preview
1
CAiSE 2013 - Valencia, Spain
2
User
Business Process Definition
Business Process Engine
Process Instances
2 1
2
1 Modelling
Enactment
3
User
Business Process Definition
Business Process Engine
Process Instances
2 1
2
1 Modelling
Enactment
Evolutionary Ad-hoc
[van der Aalst, 2001]
4
Tow Trucks Call Center Garages Paramedics Taxis
A Motorist
RoSAS
• RoSAS : Roadside Assistance as a Service.
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.
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]
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.
8
• Be explicit about the dependencies in the specification.
• Tasks need to be decoupled by localizing the dependencies.
• Event-driven task-decoupling.
tRequestTow tTow
Post-conditions Pre-conditions
Task tRequestTow {
preEP "eComplaintRcvd AND eWithinTowZone";
postEP "eTowReqd";
}
Task tTow {
preEP "eTowReqd";
postEP "eTowSuccess XOR eTowFailed";
}
An Event Pattern
Loose-coupling
Event-driven task decoupling
AND eTaxiProvided";
Task tSendSpecialNotification{
preEP “eTowSuccess";
postEP “SpecialNotifcationSent";
}
9
T1 T1
T1 T1
T1 T1
T1 T1
T1 T1
T1 T1
T1
Event X
Event Y
Process Instance id=p0123
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)";}
11
Behavior Unit Task
RoleOrganisation Event Pattern Pre/Post
Conditions
Process Definition Refer Refer
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
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]
Model Provider Factory
p002p003p004
p001Ru
ntim
e
Mod
els
PiM
TiM
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.
s1
e
ee
e
ee
e
s2
p001
s3
The Event Cloud
e
Publish
Publisher
e.g., TiM
Notify
Subscriber
e.g., TiM, PiM
Subscribe
e
e
ee
...
Event
Repo
Subscriber List
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{
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.
Process instance id
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 7 8 9 10 11 12 13
PP 1 2 3 4
CF 1.a 1.b 1.c 2 3 4 5 6
X = Not Supported
18
• Evaluated against Apache ODE (Both SOR and ODE uses Axis2 as the
framework).
• Slightly slower than Apache ODE.
ODE SOR
Avg Response Time
(σ = Std. Dev)
Δt1 = 181.71 ms
(σ = 0.30)
Δt2 = 191.61 ms
(σ = 0.12)
Percentage Performance Lost (PPL) = Δ𝑡2
− Δ𝑡1
Δ𝑡1 x 100 % = 5.448%
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 Process-
Aware Information Systems. Advanced Information Sys. Eng., pp. 574-588 (2007)
20