A Graphical Notation for
Business Process Modeling
(BPMN+): Proposition
Ang Chen
SMV Seminar Vercorin
19.09.2008

Goals of the Language

Goals of the Language
• Graphical, easy to use, with formal
semantics

Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable

Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable
• Expressive

Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable
• Expressive
• Can be used for distributed programming

Goals of the Language
• Graphical, easy to use, with formal
semantics
• Operational, executable
• Expressive
• Can be used for distributed programming
• BPMN compatible, executable BPMN

Service Component
Model (SCM)

Service Component
Model (SCM)
Properties
Provided
Services
Required
Services
SCM (References)
Component has
Services and
Properties

Service Component
Model (SCM)
Properties
Provided
Services
Required
Services
SCM (References)
SCM
SCM
Component has
Services and SCM
Properties

Service Component
Model (SCM)

Service Component
Model (SCM)
• Service: required/provided, synchronous/
asynchronous

Service Component
Model (SCM)
• Service: required/provided, synchronous/
asynchronous
• Property: concurrent data objects which hold
shared values between the process
instances, representing the observable
states of SCM

Service Signature

Service Signature
Method with 3
parameters
m(ParaType1, ParaType2, ParaType3)

Service Signature
Method with 3
parameters
m(ParaType1, ParaType2, ParaType3)
Output Event with
g(ParaType1, ParaType2, ParaType3)
3 parameters

Service Signature
Method with 3
parameters
m(ParaType1, ParaType2, ParaType3)
Output Event with
g(ParaType1, ParaType2, ParaType3)
3 parameters
Method with return
values (NEW!!)
m(?ReturnType1, ParaType2, ParaType3)

Component Services

Component Services
provided Service required
service Component service

Component Services
provided Service required
service Component service
provided Service required
service Component service

Component Services
provided Service required
service Component service
provided Service required
service Component service
Open
provided required
Service service
service
Component

Concurrent Data Objects
(example)

Concurrent Data Objects
(example)
atomic register
return(ret)
write(val)
read
read arc

Concurrent Data Objects
(example)
atomic register atomic register
read(?ret) write(val)
return(ret)
write(val)
read
read arc

Concurrent Data Objects
(example)
atomic register atomic register
read(?ret) write(val)
return(ret)
write(val)
read
read arc
compare and swap (CAS) atomic register
operation on register read write(val)
ret==old::CAS(old, new) with
read(?ret)..write(new) ..

Synchronizations

Synchronizations
simultaneous
//
//

Synchronizations
simultaneous
sequence
// ..
// ..

Synchronizations
simultaneous
sequence alternative
// .. +
// .. +

Synchronizations
simultaneous
sequence alternative
// .. +
// .. +
// and + are commutative

Synchronizations

Synchronizations
• T1//T2=T2//T1

Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1

Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1
• T1//T2//T3=T1//(T2//T3)=(T1//T2)//T3

Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1
• T1//T2//T3=T1//(T2//T3)=(T1//T2)//T3
• T1⊕T2⊕T3=T1⊕(T2⊕T3)=(T1⊕T2)⊕T3

Synchronizations
• T1//T2=T2//T1
• T1⊕T2=T2⊕T1
• T1//T2//T3=T1//(T2//T3)=(T1//T2)//T3
• T1⊕T2⊕T3=T1⊕(T2⊕T3)=(T1⊕T2)⊕T3
• T1..T2..T3=T1..(T2..T3)=(T1..T2)..T3

DataFlow Modeling
with Synchronization

DataFlow Modeling
with Synchronization
modeling synchronous calls between methods/functions

DataFlow Modeling
with Synchronization
m2(y) m2(?x)
m1(?x,y) // m1(?x,y) ..
m3(?x) m3(x, y)
m2(?x) m2(?x)
m1(?x,y) + m1(?x+y) //
m3(?x, y) m3(?y)
modeling synchronous calls between methods/functions

Functional Computing

Functional Computing
f(0)=0
f(1)=1
f(x)=f(x-1)+f(x-2)

Functional Computing
x-1 x>1
?r,x f(?r,x)=f(x-1)+f(x-2)
f(0)=0
f(?r,x) ?r,x
f(1)=1 +
f(x)=f(x-1)+f(x-2) x x==0
x-2 f(0)=0
x
x==1
f(x)=1

Functional Computing
x-1 x>1
?r,x f(?r,x)=f(x-1)+f(x-2)
f(0)=0
f(?r,x) ?r,x
f(1)=1 +
f(x)=f(x-1)+f(x-2) x x==0
x-2 f(0)=0
x
x==1
f(x)=1
Each transition can have:
1. signature (mandatory)
2. conditions on input parameters (contract?)
3. a function defined on input/output parameters

Functional Computing
x-1 x>1
?r,x f(?r,x)=f(x-1)+f(x-2)
f(0)=0
f(?r,x) ?r,x
f(1)=1 +
f(x)=f(x-1)+f(x-2) x x==0
x-2 f(0)=0
x
x==1
f(x)=1
Each transition can have:
1. signature (mandatory)
2. conditions on input parameters (contract?)
3. a function defined on input/output parameters
Transitions can use/produce values from/to places (side-effect)

Transition which
returns value
m1(?x) atomic register
0 Read arc is used

Transition which
returns value
m1(?x) atomic register
0 Read arc is used
after transition m1(?x), x=0

Enabling & Execution
Rules

Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)

Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user

Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly

Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly
• Side-effects of transaction are found in the places, if there are

Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly
• Side-effects of transaction are found in the places, if there are
In general activity is asynchronous, i.e. output is not synchronized with input
synchronous activities can be abstracted as functions

Enabling & Execution
Rules
• Transitions are enabled when necessary resources are ready
(conditions satisfied)
• Transitions are executed when it is called explicitly, e.g.
synchronized with other transitions, or triggered by user
• Transactions (synchronized transitions) are atomic and run
instantly
• Side-effects of transaction are found in the places, if there are
trigger event
Simple Activity
In general activity is asynchronous, i.e. output is not synchronized with input
synchronous activities can be abstracted as functions

Basic BPEL Patterns
Simple Activity JOIN XOR
T
T +
// + F
F WHILE
SPLIT IF ELSE

Example: Credit
Variables
Approval
RequestT: request
RiskT: risk
ApprovalT: approval
Partners: customer, assessor, approver

Example: Credit
Variables
Approval
RequestT: request RequestT RiskT ApprovalT
String firstname String level String message
RiskT: risk String name
ApprovalT: approval int: amount
Partners: customer, assessor, approver

Example: Credit
Variables
Approval
RequestT: request RequestT RiskT ApprovalT
String firstname String level String message
RiskT: risk String name
ApprovalT: approval int: amount
Partners: customer, assessor, approver Receive
customer->request(request)
request>=1000
request.amount <1000
Approval
Assess
risk.level!="low" approval=approver->approve(request)
risk=assessor->check(request)
risk.level=="low"
SetMessage
approval.accept="yes"
Reply
customer->request(approval)

request(request)
Receive
Abstract
Flow
amount<1000 amount>=1000
Assess
risk not low
risk low
SetMessage Approval
Reply
request(approval)

request(request)
Receive
+
request.amount<1000 request.amount>=1000
request
Concretized Assess request
..
Flow check(?risk, request)
+
risk.level==low risk.level!=low
Approval
SetMessage
..
..
approve(?approval, request)
approval.accept="yes"
approval
approval
Reply
request(approval)

Summary

Summary
• Service Component Model (SCM): building
blocks for (business) process modeling
• Transition with return values
• Concurrent data objects for distributed
information management
• Synchronized transitions for functional
computing and Data-Flow modeling

Next Steps
• Complete formalized semantics of the
synchronizations on model-composition
• Relation with ID-Net, e.g. variable->ID
• Find a way to manage distributed relational
data with concurrent data objects, i.e. find
good atomic primitives

Wait-free
synchronization
• Maurice Herlihy, Digital Equipment Corporation. “Wait-Free
Synchronization”, ACM Transactions on Programming Languages
and Systems,Vol. 13, Issue 1, 1991. Won the Edsger W. Dijkstra
Prize in Distributed Computing 2003
• Maurice Herlihy. “Impossibility and universality results for wait-
free synchronization”. Annual ACM Symposium on Principles of
Distributed Computing, 1988
• They have significant impacts on the theory and practices of
distributed computing

Wait-free Hierarchy
Processes Concurrent Data Object & atomic primitives
1 read/write registers
2 test-and-set, swap, fetch-and-add, queue, stack
...
2n-2 n-register assignment
...
memory-to-memory move and swap, compare-
Unbounded
and-swap
an object is universal iff. it can solve consensus

Universal Objects
(Atomic Primitives)
• Most implemented in hardwares
(microprocessors)
• Compare and Swap
• Load-Link / Store-Conditional