Summary of work done in collaboration with D. Amyot,

1
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
• February, 2007

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.

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 VV of specifications
• Automation of VV and code generation requires
  formalized specification languages

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 ?

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

6
Example Activity Diagram

7
Example Use Case Map
Warehouse
Ship Order

Office
Order rejected
Close Order
Order accepted
Receive Order
Fill Order
Send Invoice
Acccept Payment
Client
Make Payment
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)

9
The Core Scenario Model (CSM)

10
Meta-Model of the CSM

• 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

11

12
(No Transcript)
13
Functional extensions

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

15
Translation of CSMs into Petri nets

16
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 DMRs
  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

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

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)

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

20
Transactions (ACID properties)

• Example
• Travel reservation

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)

22
PART II

• Question How to go from the definition of the
  requirements to a distributed system design ?
• Basic steps
• 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 ?
• Evaluate the performance of the system design,
  and if necessary, go back to step 1

23
Protocol derivation from service specification

24
An example

service A (as above)
service access points at two different sites
S1, S2
behavior
architecture
a
b, c
1
A
S1
b, c
S2
a
A
a
b
a
b, c
2
architecture with protocol entities
E1
E2
Question What should be the behavior of E1 and
E2 ?
View of service A as an activity diagram (with
two swim lanes)
S1
S2
25
Solution for the example

Protocol
Service
E2
E1
A
1
1
1
Send(1,y)
Receive (1,x)
Receive (2,y)
a
a
b
2
1
b
2
2
2
Send(2,x)
a
a
b, c
b, c
S1
S2
E1
E2
A
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

1
b
a
3
2
c
c
5
4
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

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

c
a, b
A
S1
S2
Who makes the decision between c and b ? (when
b and c are input, or when c is output)
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

30
Example
A

• The 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

1
a
b
2
Note Some authors only consider completely
specified machines. A non-trivial assumption
implies
a partially specified state machine
(see for instance Boch 02 )
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 gtgt
• Disruption operator gt
• Example

Difficulty of LOTOS semantics for distributed
execution
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)

33
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 on registers

34
Example of protocol derivation

Service
Protocol specification
35
Example of protocol derivation

Service
Protocol specification
36
Impact of register locations

• An example

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

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

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)

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), ChapmanHall, 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).