From Workflow to Protocols, 2006 1 Gregor v. Bochmann, University of Ottawa Summary of work done in...

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


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 V&V of specifications Automation of V&V 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

Receive Order Fill

Order SendInvoice

Ship Order

Make Payment

AccceptPayment

CloseOrder

Warehouse

Office

Client

[ Order rejected ]

[ Order accepted ]


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


11


12


13

Functional extensions


14





Conclusions


15

Translation of CSMs into Petri nets


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


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

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 ]



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 ]


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


23

Protocol derivation from service specification


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 ?


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


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


27





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


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

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


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


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


34

Example of protocol derivation

ServiceProtocol specification


35

Example of protocol derivation

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

From Workflow to Protocols, 2006 1 Gregor v. Bochmann, University of Ottawa Summary of work done in...

Documents

Transcript of From Workflow to Protocols, 2006 1 Gregor v. Bochmann, University of Ottawa Summary of work done in...