From Workflow and Use Case Scenarios to Protocols

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 Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006 1

Abstract n 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 n Trend in software engineering: automate code generation from specifications n n n 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 ? n UML State Machines (SDL) and Message Sequence Charts (MSC) are too low level n n 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: n n 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 n Part I n n n Aspects of requirement specifications Semantics: The Core Scenario Model (CSM) Relation to Petri nets – translation Discussion – WS – transactions Part II n n (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 n Each Use Case is a scenario n Actions done by actors in some given order n Action: Activity / Responsibility n Actor: Swimlane / Component n Order: sequence, alternatives, concurrency, arbitrary control flows (similar to Petri nets) n n 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) n Input assertions for input data flow n Output assertions for output data flow n 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 n Part I n n n Aspects of requirement specifications Semantics: The Core Scenario Model (CSM) Relation to Petri nets – translation Discussion – WS – transactions Part II n n (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: n In Petri nets, transitions must alternate with places n n 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 n Certain concepts of Activity Diagrams are difficult to model with Petri nets, in particular n The semantics of interrupting the processing of an activity. Used in UML for the activity final node, n interruptible activity region, and n exception handling n n AC require FIFO token queues: -nets have properties similar to Petri nets Gregor v. Bochmann, University of Ottawa so-called FIFO From Workflow to Protocols, 2006 17

Tools for different purposes n Validating requirement specifications n n Defining system components and their behavior n n e. g. Petri net execution environments for system simulation and testing Protocol derivation (see next part of this talk) Tools for system implementation n n 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 n Original scope of Web Services (WS) n n 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 n 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). n n n 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: Travel reservation Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006 20

Transaction as an ”activity” A transaction either commits or aborts: interruptible region n Long-term transactions (each subtransaction may commit/abort individually): need for un-do operations in case of abort of global transation n Protocols for transaction management in a distributed context (Ph. D topic of Jinzhi Xia, University of Ottawa) n Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006 21

PART II n n 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 S 1 b, c b b, c A service access points at two different sites: S 1, S 2 a 2 architecture with protocol entities: c E 2 Question: View of service A as an activity diagram (with two swim lanes): What should be the behavior of E 1 and E 2 ? c a S 1 E 1 b, c b S 2 Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006 24

Solution for the example Service A E 1 1 a a 1’ 2 Receive (2, y) Send(1, y) Receive (1, x) 2 2’ b 2 c b, c A 1 Send(2, x) c S 1 E 2 1 b a Protocol S 2 Gregor v. Bochmann, University of Ottawa a E 1 b, c E 2 From Workflow to Protocols, 2006 25

Protocol derivation principles General procedure n n n Copy states of service into each protocol entity For each transition s 1 s 2 n 1 If s 1 and s 2 are associated with same place i n n Copy transition to entity i; join the two states in other entities Else copy transition to entity of s 1, but to an intermediate state which is followed by sending a coordination message to the entity of s 2 n 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 n Part I n n n Aspects of requirement specifications Semantics: The Core Scenario Model (CSM) Relation to Petri nets – translation Discussion – WS – transactions Part II n n (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 n Only local choices n If there alternative transitions from a given state in the service specification, then the choice among these alternatives can be done at one given site n This means: for each state, all outgoing transitions are associated with the same site Otherwise: Protocol for distributed choice required (or n compensation actions, à la [Gouda 84] ) n e. g. logical token ring among all sites involved Example: 1 a b c a, b S 1 A S 2 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): n Input/Output Automata (IOA) - simultaneous transition in IOA and its environment, but not rendezvous n n n 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 n n 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 1 a b 2 The meaning of A depends on whether a, b, and c are input or output n n 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 n Concurrent sub-behaviors n n See first paper on protocol derivation from service specification (Bochmann and Gotzhein, 1986) LOTOS n n (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 n A Petri net is a generalization of an LTS n n n PN place LTS state PN transition LTS transition Restriction: free-choice PN and “local choice” the same protocol derivation approach works n The general case n n (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 n 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 n Places and transitions n Local registers A transition has n Petri net input and output places n External input or output interaction n Enabling predicate n Concurrent update operations on registers Gregor v. Bochmann, University of Ottawa 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 n To optimize the register allocations ILP problem formulation n Heuristic solution using genetic algorithms n n Incremental construction n e. g. adding features to a given service specification Gregor v. Bochmann, University of Ottawa From Workflow to Protocols, 2006 37

Conclusions n n n 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 a number of similar graphical notations provided by different tools, including BPEL tools) Tools for validating the requirements and architectural design decisions: n n n 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 38

Outlook: AD and collaborations n n n n 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 39

References n n n n n [Boch 86 g] G. v. Bochmann and R. Gotzhein, Deriving protocol specifications from service specifications, Proc. ACM SIGCOMM Symposium, 1986, pp. 148 -156. [Boch 00 d] G. v. Bochmann, Activity Nets: A UML profile for modeling work flow architectures, Technical Report, University of Ottawa, Oct. 2000. [Boch 02 a] G. v. Bochmann, Submodule construction for specifications with input assumptions and output guarantees, in Proc. FORTE'02 (22 st IFIP WG 6. 1 International Conference on Formal Techniques for Networked and Distributed Systems), Chapman&Hall, 2002, pp. [Gotz 90 a] 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 96 a] 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 91 a] 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 03 a] 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 06 a] 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