S-CUBE LP: Runtime Process Migration: Flexible Execution of Distributed Business Processes

S-Cube Learning Package

Runtime Process Migration:
Flexible Execution of
Distributed Business Processes

University of Hamburg (UniHH)

Kristof Hamann & Sonja Zaplata, UniHH

www.s-cube-network.eu

Learning Package Categorization

S-Cube

Service composition and coordination

Models and Mechanisms for
Coordinated Service Compositions

Runtime Process Migration: Flexible Execution
of Distributed Business Processes
© UniHH, S-Cube – 2

Learning Package Overview

 Problem Description
 Runtime Process Migration
 Discussion
 Conclusions


Motivation (1)

 Distributed business processes:
Increasing need for dynamism and flexibility
– E.g. cross-organisational business processes, outsourcing
– Distribution/decentralisation of resources
Employees, machines, services, … (e.g. WS-BPEL)

book book
payment
flight hotel

Booking Booking Banking
Service 1 Service 2 Service

– Decentralisation of process execution
Autonomy of business partners, relevance of location, technological
differences, large data transfers, security policy, non-functional
aspects, …


Motivation (2)

– Decentralisation of process execution (cont’d)

buy configure test ok
accoun- write
software software software X ting
payment
report

not
ok

ok
receive make
update X complaint
not
ok
consider ok
assert
legal
claim
action

Since requirements may change even during execution, there is
a need for a flexible distribution of process execution


Motivation (2)


accoun- write
payment
report

not
ok
Consulting Administration
ok
company receive
X make
update complaint
not
ok
consider ok
assert
legal
claim
action
Legal office



Motivation (2)


accoun- write
payment
report

not
ok
Consulting Administration
ok
company receive
X make
update complaint
not
ok
Mobile user consider ok
assert
legal
claim
action
Legal office




 Discussion
 Conclusions


Basic Idea of this S-Cube approach

Context-based Cooperation in Mobile Business Environments

Background:
Context-based Cooperation

Context-based Cooperation in Mobile Business Environments
– Resources are available only in specific situations on specific devices
– Process execution can profit from
a context-based cooperation:
• The running process instance is
migrated to another process engine
• Continuation of the execution on
the other engine
• Benefit of newly available resources
– Not only mobile environments exhibit dynamically available resources

Sonja Zaplata, Christian P. Kunze, Winfried Lamersdorf. Context-based Cooperation in Mobile
Business Environments: Managing the Distributed Execution of Mobile Processes. In: Business &
Information Systems Engineering (BISE), Volume 1, Number 4, pp. 301-314


Goal and Requirements

Goal:
– Select most appropriate process
participant dynamically in
dependence of context such as
location, workload, variables, …

Requirements:
– Share and integrate available business process management systems
– Non-intrusiveness for business processes and support for ad-hoc
processes
– Security mechanisms in order to restrict access to private process parts
– User-defined guidelines for execution, monitoring and management


Migration Metadata (1): Introduction

 Challenge: How to migrate process instances?
– Current process modeling standards (e.g. WS-BPEL, BPMN) do not
define how to save process instance data such as the states of
activities, current values of variables, etc.
– However, this information is needed in order to migrate a running
process instance to another process engine

 Solution: Migration metadata model
– Generic: suitable for current process modeling standards
– Lifecycle state models and Undefined Fixed Participant or Role Variable Algorithm QoS and Context

current variable values Selection
Type
1 0,1 0,1 ID
Process 1

– Selection of participants
1 1
State 1
1..n 1
1 1 Activity
Process 1 1 Activity 1
State
1
1
1 1
StartActivity
1..n Log

– Security issues
global variable

local variable
Structured Atomic
1
Name Activity Activity

0,1 0,1
* *

(see next slides for details)
1
1
Initial 0,1 1
Variable
1 0,1 Security *
Value 1
Encrypted Session Key
Policy

Current 1
Value


Migration Metadata (2): Overview

Undefined Fixed Participant or Role Variable Algorithm QoS and Context

Selection
Type
1 0,1 0,1 ID
Process 1
1 1
State 1
1..n 1
1 1 Activity
State
1
1
1 1
StartActivity
1..n Log
global variable

local variable

Structured Atomic
1

0,1 0,1
1 * *
1
Initial 0,1 1
Variable
1 0,1 Security *
Value 1
Policy

Current 1 Elements of the general
Value process meta model
Elements of the migration
data meta model


Migration Metadata (3): Lifecycle Models


Selection
Type
1 0,1 0,1 ID
Process 1
1 1
State 1
1..n 1
1 1 Activity
State
1
1
1 1
StartActivity
1..n Log

global variable

local variable
Structured Atomic
1

0,1 0,1
1 * *
1
Initial *
Migratable Process Lifecycle State Model
0,1 1 1 0,1 Security
Variable Encrypted Session Key
Value 1 Policy

Current 1
Value
Activity Lifecycle State Model
InError

inactive ready executing executed
Created Option Running Finished Deleted

Trans- Suspen- Termin- Termin- skipped expired inError finished
ferring ded ating ated

• Each activity and the whole process have a state which is to be migrated
• Model based on the established lifecycle model Frank Leymann, Dieter Roller:
Production Workflow: Concepts and
presented by Leymann and Roller Techniques. PTR Prentice Hall, 2000

• New states for migration
Option (migration is possible), Transferring (process is currently migrated)

Migration Metadata (4) Undefined Fixed Participant or Role Variable Algorithm QoS and Context


Selection
Type
1 0,1 0,1 ID
Selection
Process 1
State
1
1
Type 1
1 1..n 1
1 0,1 0,1 Undefined Fixed Participant or Role 1
ID
Variable Activity
Algorithm QoS and Context

 Start activity: Process Process 1 1 Activity 1
1 State
1 1
1 1
State 1 1 1..n 1 1
1
StartActivity 1
Selection Activity
Process
1..n 1 1 Activity 1 Type
State Log
where to continue the 1
1 1 0,1 0,1 ID

global variable
Process 1

local variable
1 State 1 1
1 1
StartActivity 1 1..n 1
1 Activity

process execution after migration
1..n Process 1
Log 1 Activity 1
1 State
1
1
StartActivity Structured Atomic 1

global variable

local variable
1 1..n Log

global variable

local variable
Structured
0,1 0,1 Atomic Structured Atomic
1 1 * * ActivityName
1
Activity
Activity Activity
Name Initial 0,1 1 0,1
1
*
1
Variable Security Encrypted Session
0,1 0,1 Key
Value 1 1 *
*
Policy Initial 0,1 1 1 0,1 Security
1
*
0,1 0,1 Variable Encrypted Session Key
* * Value 1

 Variable – Current value:
Policy
1
1
Initial 0,1 1
Current Variable
1 0,1 Security *
Value 1
1 Current Encrypted Session Key
1

Value Policy Value

the current state of each Current 1

process variable Value

 Selection type: Which process engine should
execute the activity/process? Undefined Fixed Participant or Role Variable Algorithm QoS and Context

– Fixed participant/role name Selection
Type

– Participant is referenced in variable Process
State
1

1
1
0,1 0,1

1
1
ID

1 1..n 1
1 Activity

– Participant can be determined by a certain algorithm Process 1 1 Activity 1
1 State
1
1 1
StartActivity
1..n Log

– Participant will be selected according to its QoS and Context
global variable

local variable
Structured Atomic
1

* * 0,1 © UniHH, S-Cube – 15
0,1

Migration Metadata (5): Security Issues

 Why? Private data must not be readable by everyone!
 How? Encryption of critical parts with symmetric session keys (pk1 and pk2)
 Security policy contains the session keys (pk1 and pk2), which are
encrypted with the public keys of authorized process engines
(one session key can be encrypted multiple times with different public keys)
 Only legitimate receivers are able to read private data and execute critical
process parts
 Integrity is ensured by a MAC
(Message Authentication Code)


Selection
Type
1 0,1 0,1 ID
Process 1
1 1
State 1
1..n 1
1 1 Activity
State
1
1
1 1
StartActivity
1..n Log
global variable

local variable

Structured Atomic
1

0,1 0,1
1 * *
1
Initial 0,1 1
Variable
1 0,1 Security *
Value 1
Policy

Current 1
Value


Methodology (1): Overview


Methodology (2): Steps in Detail

1. Process modeling:
Traditional modeling in an arbitrary language
2. Generation of migration meta data:
Automatic generation of initial process/activity states
Manual configuration of user-defined guidelines
3. Deployment:
Deployment to a process engine, which supports migration
4. Instantiation:
The user is now able to start a new process instance and may define
additional requirements (migration metadata) for this process instance
5. Assignment and process execution:
Flexible execution on (multiple)
process engines using runtime
process migration


Example (Design Time)
1. Process modeling
accoun- write
payment
report

not
ok

ok
receive make
update X complaint
not
ok
consider ok
assert
legal
claim
action

Process variables (initial values):
IBAN (String): "DE68 2105 0172 3456 78"
OK (BOOLEAN): -
…


2. Generation of migration data (automatic)
accoun- write
payment
report

inactive inactive inactive not inactive inactive inactive
ok

ok
receive make
update X complaint
not
inactive ok inactive
consider ok
assert
legal
claim
action
inactive inactive
Process variables (current values):
(initial
Process-Id: 1234567
IBAN (String): "DE68 2105 0172 3456 78"
Startactivity: buy software OK (BOOLEAN): -
ProcessState: created …


2. Generation of migration data (manual)
accoun- write
payment
report

ok

ok
receive make
update X complaint
not
consider ok
assert
legal
claim
action
inactive inactive
Process variables (current values):
(initial
Process-Id: 1234567
XXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"

SelectionTypes:
buy software: Fixed Participant or Role: "XY Consulting"
payment: Fixed Participant or Role: "Administration"

Security policy:
IBAN: Administration: (session key 1) public key of "Administration"
Legal Office: (session key 1) public key of" Legal Office"


Example (Runtime)
4. Instantiation
accoun- write
payment
report

ok

ok
receive make
update X complaint
not
consider ok
assert
legal
claim
action
inactive inactive
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"

SelectionTypes:

Security policy:


Example (Runtime)
5. Assignment and process execution
accoun- write
payment
report

executing inactive inactive not inactive inactive inactive
ok
XY Consulting
ok
receive make
update X complaint
not
consider ok
assert
legal
claim
action
inactive inactive
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"
ProcessState: running …

SelectionTypes:

Security policy:


Example (Runtime)
accoun- write
payment
report

finished inactive inactive not inactive inactive inactive
ok
XY Consulting
ok
receive make
update X complaint
not
consider ok
assert
legal
claim
action
inactive inactive
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"
Startactivity: configure software OK (BOOLEAN): -
ProcessState: option …

SelectionTypes:

Security policy:


Example (Runtime)
Mobile user
accoun- write
payment
report

finished executing inactive not inactive inactive inactive
ok

ok
receive make
update X complaint
not
consider ok
assert
legal
claim
action
inactive inactive
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"
Startactivity: configure software OK (BOOLEAN): -

SelectionTypes:

Security policy:


Example (Runtime)
Mobile user
accoun- write
payment
report

finished executed inactive not inactive inactive inactive
ok

ok
receive make
update X complaint
not
consider ok
assert
legal
claim
action
inactive inactive
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"
Startactivity: test software OK (BOOLEAN): -

SelectionTypes:

Security policy:


Example (Runtime)
Mobile user
accoun- write
payment
report

finished finished finished not inactive inactive inactive
ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"
Startactivity: accounting OK (BOOLEAN): true

SelectionTypes:

Security policy:


Example (Runtime)
Administration
accoun- write
payment
report

finished finished finished not inactive inactive inactive
ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"
Startactivity: accounting OK (BOOLEAN): true

SelectionTypes:

Security policy:


Example (Runtime)
Administration
accoun- write
payment
report

finished finished finished not finished inactive inactive
ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"
Startactivity: payment OK (BOOLEAN): true

SelectionTypes:

Security policy:


Example (Runtime)
Administration
accoun- write
payment
report

finished finished finished not finished executing inactive
ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"

SelectionTypes:

Security policy:


Example (Runtime)
Administration
accoun- write
payment
report

ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
IBAN (String): "DE68 2105 0172 3456 78"

SelectionTypes:

Security policy:


Example (Runtime)
Administration
accoun- write
payment
report

ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
XXXXXXXXXXXXXXXXXXX
IBAN (String): "DE68 2105 0172 3456 78"

SelectionTypes:

Security policy:


Example (Runtime)
Administration
accoun- write
payment
report

finished finished finished not finished finished inactive
ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
IBAN (String): XXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
"DE68 2105 0172 3456 78"
Startactivity: write report OK (BOOLEAN): true

SelectionTypes:

Security policy:


Example (Runtime)
Administration
accoun- write
payment
report

finished finished finished not finished finished finished
ok

ok
receive make
update X complaint
not
skipped ok skipped
consider ok
assert
legal
claim
action
skipped skipped
Process variables:
Process-Id: 1234567
IBAN (String): XXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
"DE68 2105 0172 3456 78"
Startactivity: - OK (BOOLEAN): true
ProcessState: finished …

SelectionTypes:

Security policy:


Ad-hoc management capabilities (1)

 Process execution may leave initiator’s sphere of influence
– due to migration to another process engine
– but also due to subcontracting or fragmentation

 Challenges
– Resources and execution systems are often selected dynamically
– Heterogeneous execution systems without standardized management
capabilities
– Cross-organizational monitoring and controlling can be applied in
advance, but miss instant monitoring and reaction capabilities

 Solution
– process management system as a manageable resource



 Process management system as a manageable resource
 Realized according to the Web Services Distributed
Management (WSDM) standard

management interface
meta services
information modification events

deploy/undeploy context change
context
process model

instantiate
status intrinsic extrinsic
change
context context
process instance event

terminate

process history
process management system



 Interfaces management interface
meta services
information modification events

– Information: request status of processes process model
deploy/undeploy context change
context

instantiate

– Modification: manipulate the process execution
status intrinsic extrinsic
change
context context
process instance event

terminate

process history
process management system

– Events: subscription to specific event types
– Meta services: information about management capabilities

 Common models for processes instance id
1

and process instances
1
1 status
1
1
process instance
1
1 1 1 history
1
1
model id
1 * *
1 1 1
1 1 actual performer activity status
process model 1
1 1
1 1 * from to

* * * * *
predefined 0..1 1
use data type transition
activity
performer
1 1 1 1
* from to
* * * * * 0..1
data field
*
use data type transition condition
use
1 * * 1
1 1
1 0..1
* * * 0..1
data field data value evaluation result
condition
use
* *


Realizing Runtime Process Migration

 Process engine needs to be extended in order to support
migration and/or ad-hoc management capabilities
 Migration metadata model abstracts from concrete process
languages
 Prototypical implementation done for two types of languages
– Graph-based: reference implementation for XPDL in DEMAC
– Block-structured: evaluation of WS-BPEL, realized in Sliver


Background:
DEMAC middleware platform

 Middleware for mobile computing Application Layer Applications

 Transport Service: abstracts from
Process Service
concrete transport protocols,
spans an overlay network
Context Service
 Context Service: collects and Service Layer
maintains all information about the
Event Service
context of the device
 Process Service: integrates Asynchronous Transport Service

process management Transport Protocol
Access Layer
Adapter Adapter
Virtual
Transport Layer Transport
Transport Protocol Transport Protocol

Christian P. Kunze. DEMAC: A Distributed Environment for Mobility-Aware Computing. In:
Adjunct Proceedings of the Third International Conference on Pervasive Computing (2005)

Business Environments: Managing the Distributed Execution of Mobile Processes. In: Business
& Information Systems Engineering (BISE), Volume 1, Number 4, pp. 301-314



 Discussion
 Conclusions


Existing Approaches

 Current approaches for increasing dynamism and flexibility in
distributed business processes

Process fragmentation: Process migration:
– Transformation of service granularity or – Introduced by [Cichocki and Rusinkiewicz, 1997].
insertion of new services, e.g. – OSIRIS [Schuler, Weber, Schuldt and Schek,
[Khalaf and Leymann, 2006], 2004].
[Baresi, Maurino and Modafferi, 2006].
– Pervasive and mobile applications, e.g. [Montagut
– Development of choreography, e.g. CiAN and Molva, 2005], [Kunze, Zaplata and
[Sen, Roman and Gill, 2008]. Lamersdorf, 2006].
– Non-intrusive fragmentation, e.g. – Dynamic partitioning, e.g.
[Martin, Wutke and Leymann, 2008] [Atluri et al., 2007]

Process Migration vs. Process Fragmentation
Evaluation of XPDL
Tested XPDL elements Process migration Process fragmentation

Atomic activities activity possible possible
Structured activities activity set possible possible
branches (XOR) possible possible (transfer of decision)
loops possible coordination required
branches (AND) replication and coordination and synchronization
synchronization required required

Other elements transaction (XPDL 2.0) for undo: to be avoided coordination required
for compensation: possible

Dead path elimination - automatically coordination required
Privacy of process parts - artificial automatically
Splitting atomic activities - forbidden no known approach
Data replication - only for parallel execution always: data fields, data types,
(entire process) applications, participants

Design time distribution - possible (assign all activities in possible
advance)

Runtime distribution - during execution once after invocation


Process Migration vs. Process Fragmentation
Evaluation of WS-BPEL


Advantages/Disadvantages

 Runtime process migration as an
alternative to (physical) process
fragmentation

 Benefits:
– More flexibility: advantageous in a
dynamic context
– Especially suited for dynamic non- Fragmentation
recurrent/ad-hoc process executions
 Limitations:
– Limited flexibility for "receiving"
processes (e.g. messages, events)

 Modification/development overhead
– Once for the process engine(s) or for
each process model/instance?
Migration



 Discussion
 Conclusions


Summary

 There is an increasing need for dynamism and flexibility
in the distributed execution of business processes
 The proposed approach tackles this challenge in providing a
methodology, mechanisms and models for the migration of
process instances at runtime
– Generic migration metadata model
– Consideration of security aspects
– Ad-hoc management capabilities

 Evaluation for XPDL and WS-BPEL
– No change of existing process models required
– Process migration shows more flexibility than process fragmentation
– Especially advantageous in a dynamic context


Further S-Cube Reading

Business Environments: Managing the Distributed Execution of Mobile Processes. In: Business &
Information Systems Engineering (BISE), Volume 1, Number 4, pp. 301-314

Sonja Zaplata, Kristian Kottke, Matthias Meiners, Winfried Lamersdorf. Towards Runtime
Migration of WS-BPEL Processes. In: Service-Oriented Computing. ICSOC/ServiceWave 2009
Workshops (2010)

Sonja Zaplata, Kristof Hamann, Kristian Kottke, Winfried Lamersdorf. Flexible Execution of
Distributed Business Processes based on Process Instance Migration. In: Journal of Systems
Integration (JSI), Volume 1, Number 3, pp. 3-16 (2010)

Sonja Zaplata, Winfried Lamersdorf. Towards Mobile Process as a Service. In: Proceedings of
the 2010 ACM Symposium on Applied Computing (2010)

Sonja Zaplata, Daniel Straßenburg, Benjamin Wunderlich, Dirk Bade, Kristof Hamann, Winfried
Lamersdorf. Ad-hoc Management Capabilities for Distributed Business Processes. In: 3rd
International Conference on Business Process and Services Computing (2010)


Acknowledgements

The research leading to these results has
received funding from the European
Community’s Seventh Framework
Programme [FP7/2007-2013] under grant
agreement 215483 (S-Cube).


S-CUBE LP: Runtime Process Migration: Flexible Execution of Distributed Business Processes

More Related Content

More from virtual-campus (20)

Recently uploaded (20)

S-CUBE LP: Runtime Process Migration: Flexible Execution of Distributed Business Processes