from workflow and use case scenarios to protocols for distributed applications
DESCRIPTION
From Workflow and Use Case Scenarios to Protocols for Distributed Applications. Summary of work done in collaboration with D. Amyot, H. Yamaguchi, T. Higashino, K. El-Fakih and others February, 2007. Gregor v. Bochmann School of Information Technology and Engineering (SITE) - PowerPoint PPT PresentationTRANSCRIPT
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
1
Summary of work done in collaboration with D. Amyot,
H. Yamaguchi, T. Higashino, K. El-Fakih and others
February, 2007
Gregor v. Bochmann
School of Information Technology and Engineering (SITE)University of Ottawa
Canada
http://www.site.uottawa.ca/~bochmann
From Workflow and Use Case Scenarios
to Protocols for Distributed Applications
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
2
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
3
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
4
How to describe requirements ?
UML State Machines (SDL) and Message Sequence Charts (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
5
Overview Part I (Activity Diagrams and Use Case Maps)
Aspects of requirement specifications Semantics: The Core Scenario Model (CSM) Relation to Petri nets – translation Discussion – WS – transactions
Part II (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
6
Example Activity Diagram
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
7
Example Use Case Map
Receive Order Fill
Order SendInvoice
Ship Order
Make Payment
AccceptPayment
CloseOrder
Warehouse
Office
Client
[ Order rejected ]
[ Order accepted ]
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
8
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
9
The Core Scenario Model (CSM)
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
10
Meta-Model of the CSM1. Meta-model of the core functional
aspects2. Performance extensions3. 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
11
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
12
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
13
Functional extensions
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
14
Overview Part I (Activity Diagrams and Use Case Maps)
Aspects of requirement specifications Semantics: The Core Scenario Model (CSM) Relation to Petri nets – translation Discussion – WS – transactions
Part II (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
15
Translation of CSMs into Petri nets
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
16
Translation toolCSM (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
17
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 properties similar to Petri nets
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
18
Tools for different purposes Validating requirement specifications
e.g. Petri net execution environments for system simulation and testing
Defining system components and their behavior 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
19
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), Java JINI is more interesting
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
20
Transactions (ACID properties)
Example:Travel reservation
a b o r t
[N e w c u s to m e r]
C o m m it
O u tc o m e
L o n g D u ra tio n T ran sac tio nT T rav e lR ese rv a tio n
P
S im p le T ra n sa c tio n T 1 : F lig h tR e se rv a tio n
O p e nA c c o u n t
[R e tu rn C u s to m e r]
[a b o r t][c o m m it]
S im p le T ra n sa c tio n T 2 : H o te lR e se rv a tio n
S im p le T ra n sa c tio n T 3 : C a rR e se rv a tio n
[a b o r t]
[c o m m it]
G e n e ra te B ill
< < d a ta s to re > >A c c o u n tIn fo
C a n c e l T
A
A
S im p lT ra n sa c tio nU n d o T
P : C u s to m erIn fo , in /o u tO u tco m e: O u tco m eO fT ran sac tio n , o u t
F ig u re 3 T ra v e lR e v e rs itio n
A
A
[T 1 N o t D o n e ]
[T 1 D o n e ]
[T 2 N o t D o n e ]
[T 3 N o t D o n e ]
B
B
B
[B ill h a s n o t g e n e ra te d y e t][B ill h a s g e n e ra te d ]
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
21
Transaction as an ”activity” A transaction either commits or aborts:
interruptible region Long-term transactions (each sub-
transaction 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
22
PART II Question: How to go from the definition
of the requirements to a distributed system design ?
Basic steps:1. Identify system components and their physical
distribution (i.e. the basic system architecture)2. 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
23
Protocol derivation from service specification
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
24
An example
a
1
2
b
c
service A (as above)
A b, ca
behavior architecture
A
b, ca
architecture with protocol entities:
b, ca
service access pointsat two different sites: S1, S2
View of service A as an activity diagram (with two swim lanes):
a c b
S1 S2
S2S1
E1 E2
Question:What should be the behavior of E1 and E2 ?
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
25
Solution for the example
a
1
2
b
c
A
a
1
1’
E1
1
2c
E2
Send(2,x)2
Receive (2,y)
Receive (1,x) 2’
b
Send(1,y)
b, ca
E1 E2A
b, ca
S1 S2
Service Protocol
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
26
Protocol derivation principles
General procedure Copy states of service into each
protocol entity For each transition s1 s2
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
a
1
3
2
b
5e
4d
c c
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
27
Overview Part I (Activity Diagrams and Use Case Maps)
Aspects of requirement specifications Semantics: The Core Scenario Model (CSM) Relation to Petri nets – translation Discussion – WS – transactions
Part II (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
28
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: A
ca, b
S1 S2
Who makes the decision between c and b ? (when b and c are input, or when c is output)
a
1
2
b
c
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
29
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
30
ExampleThe meaning of A depends on whether a, b, and c are input or output 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
a
1
2
b
c
A
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
31
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: [>
Example:
Difficulty of LOTOS semanticsfor distributed execution
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
32
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
33
Petri net with registersA Petri net has Places and
transitions Local registersA transition has Petri net input and
output places External input or
output interaction Enabling predicate Concurrent update
operations on registers
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
34
Example of protocol derivation
ServiceProtocol specification
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
35
Example of protocol derivation
ServiceProtocol specification
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
36
Impact of register locations An example
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
37
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
38
Conclusions Practical applications often have only local choice: the protocol
derivation approach can be applied for obtaining distributed system designs
Suggestion: use AD 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 AD (in Java or BPEL), including message
exchanges for the coordination between different system components
ADs 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
39
Outlook: AD 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. In distributed systems, a single activity is often performed in
collaboration by several system components. We may consider a UML “collaboration” to be an “activity”.
Then we have to consider that the responsibility for such a collaboration activity is shared among all the components of the collaboration.
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).
What are the synchronization problems that occur when different collaborations (that work fine individually) are combined in a temporal order defined by an AD ? – And how to resolve these difficulties – specification guidelines and automatic generation of coordination messages (Collaboration with Technical University of Trondheim, Norway)
Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006
40
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 re-synthesis 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).