From Workflow and Use Case Scenarios to Protocols for Distributed Applications

1. 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) University of Ottawa Canada http://www.site.uottawa.ca/~bochmann Gregor v. Bochmann, University of Ottawa

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

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

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

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

6. Example Activity Diagram Gregor v. Bochmann, University of Ottawa

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 Gregor v. Bochmann, University of Ottawa

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

9. The Core Scenario Model (CSM) Gregor v. Bochmann, University of Ottawa

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 Gregor v. Bochmann, University of Ottawa

11. Gregor v. Bochmann, University of Ottawa

12. Gregor v. Bochmann, University of Ottawa

13. Functional extensions Gregor v. Bochmann, University of Ottawa

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

15. Translation of CSMs into Petri nets Gregor v. Bochmann, University of Ottawa

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

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

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

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

20. Transactions (ACID properties) Example: Travel reservation Gregor v. Bochmann, University of Ottawa

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

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 Gregor v. Bochmann, University of Ottawa

23. Protocol derivation from service specification Gregor v. Bochmann, University of Ottawa

24. c b c a 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 Gregor v. Bochmann, University of Ottawa

25. c c 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 b, c a b, c S1 S2 E1 E2 A Gregor v. Bochmann, University of Ottawa

26. e d 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 Gregor v. Bochmann, University of Ottawa

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

28. c 1 a b 2 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) Gregor v. Bochmann, University of Ottawa

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

30. c Example 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 A 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] ) Gregor v. Bochmann, University of Ottawa

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 semantics for distributed execution Gregor v. Bochmann, University of Ottawa

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

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 Gregor v. Bochmann, University of Ottawa

34. Example of protocol derivation Service Protocol specification Gregor v. Bochmann, University of Ottawa

35. Example of protocol derivation Service Protocol specification Gregor v. Bochmann, University of Ottawa

36. Impact of register locations An example Gregor v. Bochmann, University of Ottawa

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

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

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

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). Gregor v. Bochmann, University of Ottawa