From Workflow and Use Case Scenarios
to Protocols
for Distributed Applications
Gregor v. Bochmann
School of Information Technology and Engineering (SITE)
University of Ottawa
Canada
http://www.site.uottawa.ca/~bochmann
Summary of work done in collaboration with D. Amyot,
H. Yamaguchi, T. Higashino, K. El-Fakih and others
June, 2006
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
1
Abstract
„
UML Use Case Diagrams are a first step towards the definition of system
requirements, however, they do not provide enough information for many
purposes. UML Activity Diagrams (AD) and Use Case Maps (UCM) provide such
information in a quite comprehensive manner. The first part of my talk deals
with a "Core Scenario Model" (CSM) which was developed to capture the
common semantics of AD and UCM, as well as performance-related
information. The CSM can be easily translated into Petri nets, and it is also
related to the BPEL notation of Web Services, which could be taken as an
implementation environment. In the second part of my talk, I will discuss how
one can derive an application protocol from system requirements given in the
form of such notations together with a distributed system architecture that
identifies a certain number of system components. The resulting protocol will
define the behavior of all the system components in such a manner as to
ensure the given requirements. This problem is relatively easy to solve if each
choice between alternative actions in the requirements can be performed by
one of the components alone, however, it becomes quite complex if
information from several components must be considered for doing such
choices. We also discuss how the concept of (distributed) transactions, in the
sense of databases, can be integrated into the description of requirements.
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
2
Background:
Abstract system specifications
„
Trend in software engineering: automate
code generation from specifications
„
„
„
„
„
„
From assembler to machine code
From HLL (e.g. C or Java) to assembler or
interpreted code
From design languages (e.g. SDL) to HLL
From requirements ?? . . . to ??
Also need for V&V of specifications
Automation of V&V and code generation
requires formalized specification languages
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
3
How to describe requirements ?
„
SDL and MSC are too low level
„
„
„
„
Based on exchange of individual messages
Actions at the requirements level often involve
the exchange of several messages. E.g. login
Activity Diagrams and Use Case Maps
appear to be at the right level of abstraction
Questions:
„
„
How can they be used in the software
development process ?
How can one build tools for their use ?
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
4
Overview
„
Part I
„
„
„
„
„
Aspects of requirement specifications
Semantics: The Core Scenario Model (CSM)
Relation to Petri nets – translation
Discussion – WS – transactions
Part II
„
„
„
„
(Activity Diagrams and Use Case Maps)
(from requirements to distributed designs)
Protocol derivation from service specifications
Assumptions – language generality
Petri nets (extended) as specification langage
Conclusions
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
5
Example Activity Diagram
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
6
Example Use Case Map
Warehouse
Ship
Order
Office
[ Order
rejected ]
Receive
Order
[ Order
accepted ]
Close
Order
Fill
Order
Send
Invoice
Acccept
Payment
Client
Make
Payment
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
7
Concepts for requirements
„
Each Use Case is a scenario
„
Actions done by actors in some given order
„ Action: Activity / Responsibility
„ Actor: Swimlane / Component
„ Order: sequence, alternatives, concurrency, arbitrary control
flows (similar to Petri nets)
„
„
Abstraction: refinement of activity / Plug-in
Data-Flow: Object flow / not in UCMs. Question: what
type of data is exchanged (an extension of control flow)
„ Input assertions for input data flow
„ Output assertions for output data flow
„ Conditions for alternatives (also in UCMs)
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
8
The Core Scenario Model (CSM)
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
9
Meta-Model of the CSM
1.
2.
3.
Meta-model of the core functional aspects
Performance extensions
Functional extensions
For more details, see Master thesis by Shabaz Maqbool
Note: Our corresponding XML schema definitions do not
follow the MOF-XMI standard
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
10
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
11
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
12
Functional extensions
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
13
Overview
„
Part I
„
„
„
„
„
Aspects of requirement specifications
Semantics: The Core Scenario Model (CSM)
Relation to Petri nets – translation
Discussion – WS – transactions
Part II
„
„
„
„
(Activity Diagrams and Use Case Maps)
(from requirements to distributed designs)
Protocol derivation from service specifications
Assumptions – language generality
Petri nets (extended) as specification langage
Conclusions
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
14
Translation of CSMs into Petri nets
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
15
Translation tool
CSM (XML) Æ Colored Petri Nets (CPN) (XML)
Special considerations:
„ In Petri nets, transitions must alternate with places
„
„
„
„
Introduce dummy place between Action, Fork or Join nodes
Introduce dummy transition between Decision, Merge, Object, Start
and Stop nodes
Components (Swim Lanes) can be modeled by a place
with input and output arcs to all actions within that
component (see my earlier work on DMR’s method and
comparison with UML, 2000, “Activity nets”, [Boch 80])
Alternate sets of input or output pins for a given
activity can be modeled by several (alternate) transitions
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
16
Limitations
„
Certain concepts of Activity Diagrams
are difficult to model with Petri nets, in
particular
„
The semantics of interrupting the
processing of an activity. Used in UML for
the activity final node,
„ interruptible activity region, and
„ exception handling
„
„
AC require FIFO token queues:
so-called
FIFO-nets have similar properties to Petri nets
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
17
Tools for different purposes
„
Validating requirement specifications
„
„
Defining system components and their
behavior
„
„
e.g. Petri net execution environments for system
simulation and testing
Protocol derivation (see next part of this talk)
Tools for system implementation
„
„
e.g. code generation from SDL
BPEL (Business Process Execution Language)
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
18
Web Services
„
Original scope of Web Services (WS)
„
„
„
„
SOAP, a remote procedure call (RPC) mechanism (like CORBA and
Java RMI) using XML message encoding
Interface definition (written in WSDL in the form of an XML
Schema), comparable to a Java ”interface”
UDDI: a WS directory for finding WS instances (not much used)
WS ”choreography”: defining ways how different WS can cooperate
„
BPEL: langage for defining the dynamic behavior of a WS in terms
of actions that invoke operations on other Web Services
(comparable to the body of a Java method).
„
„
„
Control flow operators similar to AC: sequence, alternatives,
concurrency
Language syntax based on XML (not very readable)
Execution of BPEL WS definitions: usually by an interpreter
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
19
Transactions (ACID properties)
Example:
LongDurationTransaction
T TravelReservation
Travel reservation
P: CustomerInfo, in/out
Outcome: OutcomeOfTransaction, out
Cancel T
A
Open
Account
SimpleTransaction
T1: FlightReservation
[New customer]
SimplTransaction
Undo T
[T1 Not Done]
[T1 Done]
abort
[abort]
[commit]
[Return Customer]
Outcome
A
[T3 Not Done]
P
B
[T2 Not Done]
B
SimpleTransaction
T2: HotelReservation
SimpleTransaction
T3: CarReservation
[commit]
A
[abort]
<<datastore>>
AccountInfo
B
[Bill has generated]
[Bill has not generated yet]
Generate Bill
A
Gregor v. Bochmann, University of Ottawa
Commit
From Workflow to Protocols, 2006
Figure 3
TravelReversition
20
Transaction as an ”activity”
A transaction either commits or aborts:
interruptible region
„ Long-term transactions (each subtransaction may commit/abort individually):
need for un-do operations in case of abort
of global transation
„ Protocols for transaction management in a
distributed context
(PhD topic of Jinzhi Xia, University of Ottawa)
„
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
21
PART II
„
„
Question: How to go from the definition of
the requirements to a distributed system
design ?
Basic steps:
1.
2.
Identify system components and their physical
distribution (i.e. the basic system architecture)
Derive the required interfaces and the dynamic
behavior of the components from the requirements
Can this step be automated ?
3.
Evaluate the performance of the system design, and if
necessary, go back to step 1
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
22
Protocol derivation
from service specification
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
23
An example
service A (as above)
behavior
architecture
1
a
a
A
a
S1
b, c
b
b, c
A
service access points
at two different sites:
S1, S2
S2
a
2
architecture
with protocol entities:
c
E1
b, c
E2
View of service A as an activity diagram
Question:
(with two swim lanes):
What should be
the behavior of E1 and E2 ?
c
a
S1
b
S2
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
24
Solution for the example
Protocol
Service
A
1
a
E2
E1
1
1
a
1’
b
2
Receive
(2,y)
Send(2,x)
Receive
(1,x)
2
2’
c
b, c
S1
A
b
2
c
a
Send(1,y)
S2
Gregor v. Bochmann, University of Ottawa
a
E1
b, c
E2
From Workflow to Protocols, 2006
25
Protocol derivation principles
General procedure
„
„
„
Copy states of service into each protocol
entity
For each transition s1 Æ s2
„
1
If s1 and s2 are associated with same place i
„
„
Copy transition to entity i; join the two states in
other entities
Else copy transition to entity of s1, but to an
intermediate state which is followed by sending a
coordination message to the entity of s2
„
Include an identifier in each coordination
message in order to distinguish the service
transition that triggered the sending of the
message
Gregor v. Bochmann, University of Ottawa
b a
3
2
c
c
5
4
d
e
From Workflow to Protocols, 2006
26
Overview
„
Part I
„
„
„
„
„
Aspects of requirement specifications
Semantics: The Core Scenario Model (CSM)
Relation to Petri nets – translation
Discussion – WS – transactions
Part II
„
„
„
„
(Activity Diagrams and Use Case Maps)
(from requirements to distributed designs)
Protocol derivation from service specifications
Assumptions – language generality
Petri nets (extended) as specification langage
Conclusions
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
27
Important Assumption
„
Only local choices
„
If there are alternative transitions from a given state
in the service specification, then the choice among
these alternatives can be done at one given site
„ This means: for each state, all outgoing transitions
are associated with the same site
Otherwise: Protocol for distributed choice required (or
„
compensation actions, à la [Gouda 84] )
„
e.g. logical token ring among all sites involved
Example:
1
a
b
c
a, b
S1
A
S2
Who makes the decision between c and b ?
2
c
Gregor v. Bochmann, University of Ottawa
(when b and c are input, or when c is output)
From Workflow to Protocols, 2006
28
Distinction of input and output
Specialization of labeled transition systems
(LTS):
„ Input/Output Automata (IOA) -
simultaneous transition in IOA and its
environment, but not rendezvous
„
„
„
Output: time and parameters of an interaction are determined by the
system component producing the output
Input: The component receiving the interaction cannot influence the
time nor parameter values
Specification of component behavior
„
„
Output: The specification gives guarantees about timing and
parameter values
Input: The specification may make assumptions about timing of
inputs and the received parameter values
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
29
Example
A
The meaning of A depends on whether
a, b, and c are input or output
1
a
b
2
„
„
c
An output may be performed in a state only if such a
transition starts in that state
If an input arrives in some state and no transition is
specified for this input in that state, then the
assumption is not satisfied (this situation is called
unspecified reception, probably a design error)
-- there is no blocking as in the case of LTS
Note: Some authors only consider completely specified machines.
A non-trivial assumption implies
a partially specified state machine
(see for instance [Boch 02] )
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
30
More powerful languages
. . . for specifying services and protocols
„ Concurrent sub-behaviors
„
„
See first paper on protocol derivation from service
specification (Bochmann and Gotzhein, 1986)
LOTOS
„
„
(see Kant 1996)
recursive process call: >>
Disruption operator: [>
Difficulty of LOTOS semantics
for distributed execution
Example:
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
31
Petri nets (PN) as specification
language
„
A Petri net is a generalization of an LTS
„
„
„
PN place Æ LTS state
PN transition Æ LTS transition
Restriction: free-choice PN and “local choice”
Æ the same protocol derivation approach works
„
The general case
„
„
(see Yamaguchi 2006)
It is quite complex (distributed choice of transition to be executed,
depending on tokens in places associated with different sites)
Methods can be easily extended to Colored
Petri nets (or Predicate Transition nets):
exchanged messages now contain tokens with data parameters
„ Petri nets with registers (see Yamaguchi 2003, and next slides)
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
32
Petri net with registers
A Petri net has
„ Places and
transitions
„ Local registers
A transition has
„ Petri net input and
output places
„ External input or
output interaction
„ Enabling predicate
„ Concurrent update
operations
onof Ottawa
Gregor
v. Bochmann, University
i t
From Workflow to Protocols, 2006
33
Example of protocol derivation
Service
Gregor v. Bochmann, University of Ottawa
Protocol specification
From Workflow to Protocols, 2006
34
Example of protocol derivation
Service
Gregor v. Bochmann, University of Ottawa
Protocol specification
From Workflow to Protocols, 2006
35
Impact of register locations
An example
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
36
Further issues
„
To optimize the register allocations
ILP problem formulation
„ Heuristic solution using genetic algorithms
„
„
Incremental construction
„
e.g. adding features to a given service
specification
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
37
Conclusions
„
„
„
Practical applications often have only local choice: the protocol
derivation approach can be applied for obtaining distributed system
designs
Suggestion: use AC notation for describing workflows (there are a
number of similar graphical notations provided by different tools,
including BPEL tools)
Tools for validating the requirements and architectural design
decisions:
„
„
„
„
„
„
Checking desirability of possible execution sequences (Petri net
simulations)
Checking general properties of dynamic behavior
Performance evaluation based on (additional) performance-related
information (load, execution delays of basic actions)
Code generation from AC (in Java or BPEL), including message
exchanges for the coordination between different system components
ACs need an improved notation for talking about responsibility of
components (e.g. see UCMs)
Integration of transactions into this general framework needs further
work
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
38
Outlook: AC and collaborations
„
„
„
„
„
„
From a global perspective (ignoring the distribution architecture) an
activity just represents an action to be performed.
Normally, when an architecture of components is introduced, each
activity becomes the responsibility of one of the components.
We may consider a collaboration an “activity”; then its responsibility is
shared among the components that take part in the collaboration.
Therefore, we may use ADs to describe the temporal ordering of
collaborations.
Since different collaborations involve different components, one may
have to introduce coordination messages (as in the case of protocol
derivation where each action was associated with a single component).
Our paper on protocol derivation for Petri nets with registers is an
example of such collaborations: an activity (Petri net transition of the
service specification) is executed in collaboration by those sites that
contain registers used by the transition. These are very specific
collaborations: the purpose is the execution of a single (abstract)
service extended-Petri-net transition.
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
39
References
„
„
„
„
„
„
„
„
„
[Boch 86g] G. v. Bochmann and R. Gotzhein, Deriving protocol specifications from service
specifications, Proc. ACM SIGCOMM Symposium, 1986, pp. 148-156.
[Boch 00d] G. v. Bochmann, Activity Nets: A UML profile for modeling work flow architectures,
Technical Report, University of Ottawa, Oct. 2000.
[Boch 02a] G. v. Bochmann, Submodule construction for specifications with input assumptions and
output guarantees, in Proc. FORTE'02 (22st IFIP WG 6.1 International Conference on Formal
Techniques for Networked and Distributed Systems), Chapman&Hall, 2002, pp.
[Gotz 90a] R. Gotzhein and G. v. Bochmann, Deriving protocol specifications from service
specifications including parameters, ACM Transactions on Computer Systems, Vol.8, No.4, 1990,
pp.255-283.
[Goud 84] M. G. Gouda and Y.-T. Yu, Synthesis of communicating Finite State Machines with
guaranteed progress, IEEE Trans on Communications, vol. Com-32, No. 7, July 1984, pp. 779-788.
[Kant 96a] C. Kant, T. Higashino and G. v. Bochmann, Deriving protocol specifications from service
specifications written in LOTOS, Distributed Computing, Vol. 10, No. 1, 1996, pp.29-47.
[Prob 91a] R. Probert and K. Saleh, Synthesis of communication protocols: survey and assessment,
IEEE Tr. on Computers, Vol. 40, 4 (April 1991), pp. 468-476.
[Yama 03a] H. Yamaguchi, K. El-Fakih, G. v. Bochmann and T. Higashino, Protocol synthesis and resynthesis with optimal allocation of resources based on extended Petri nets., Distributed Computing,
Vol. 16, 1 (March 2003), pp. 21-36.
[Yama 06a] H. Yamaguchi, K. El-Fakih, G. v. Bochmann and T. Higashino, Deriving protocol
specifications from service specifications written as Predicate/Transition-Nets, Computer Networks (to
be published).
Gregor v. Bochmann, University of Ottawa
From Workflow to Protocols, 2006
40