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