Modelling (and Analyzing) Interorganizational Communication. Jan Martijn van der Werf

Transcription

1 Modelling (and Analyzing) Interorganizational Communication Jan Martijn van der Werf 1

2 2 Interaction

3 Interaction in networks Bob Charley Alice Dave 3

4 Bob Can you Charley, you do Interaction in networks Live organize music a Bob, here s the drinks, Alice, of Uh, I don t party course! for Of course! your party! can you take know! me? care of the Bob, live Alice, live music? music, DJ music or it is! CDs? Charley Settled! Here are the drinks! Dave, can Live Music music, is you get me a DJ, done! or just some CDs? musicians? Alice Dave 4

5 Network of systems Communication! 5

6 This lecture: Service Oriented Architectures Modeling interactions Protocols: communication between systems 6

7 7 Service Oriented Architectures

8 Two approaches: design time vs. runtime Service Oriented Computing! Design time: all systems known 8

9 Two approaches: design time vs. runtime What if you do not know the systems during design time? 9

10 Service Oriented Architecture: find your partners! Registry 2. Query 1. Register Client 3. Contact details 4. Exchange Provider Provider Provider 10

11 Service Oriented Architecture, step 1: registration Registry What if you do not know the systems during design time? 11

12 I need someone who can organize a party according Service to my Oriented servicearchitecture, step 2: communicate! Can you organize my party? I need a musician! Registry Try Dave. These are his contact details! What if you do not know the systems during design time? 12 Try JM. These are his contact details!

13 How do systems communicate? messages: SOAP Simple Object Access Protocol Service: WSDL 13 Web Service Description Language

14 How do systems communicate? messages: SOAP Simple Object Access Protocol Order of messages: WS-BPEL Service: WSDL Web Service Business Process Execution Language 14 Web Service Description Language

15 How do systems communicate? Order of messages: - Orchestration - Choreography 15

16 Orchestration vs. Choreography Orchestration Local component that coordinates the service interactions Choreography Global view on the interactions of services S1 S2 S1 S2 Orchestrator 16 S3 S3

17 Aanbiedings brief Start Slecteren gegevens kandidaat huurder Selecteren woning Afspraak maken Huur contract Bijwerken gegevens Versturen Corresponden tie Afspraak huurder Contract Gegevens wijzigen Definitief contract Einde Business Processes WSDL WSDL WSDL Enterprise Service Bus e*gate TM Adapter Adapter Comm. Adapter Integration Web CRM Housing B2B Backend systems (COTS) Services 17

18 Sender Choreography languages Message between two parties Receiver 18

19 Every choreography possible? Does an implementation exist that exactly follows this choreography? 19

20 20 Make a Petri net of it!

21 21 Intermezzo: Petri nets

22 Behavioral modeling: Petri nets State Place Token Transition Rules of the Token game : ( interleaving semantics ) State: all places with the number of tokens in each place Transition is enabled All input places contain at least 1 token Transition fires From all input places one token is consumed In all output places one token is produced 22

23 Petri nets & state diagrams p1 p1 a p2 a p3 b p2, p3 c b c p4, p3 p2, p5 d c b e p4 p5 p6, p3 p4, p5 p2, p7 d e c d e p6, p5 p4, p7 b p6 f p7 e p6, p7 f d 23 p8 p8

24 Firing of transitions All input places always have a token (empty set, so always true!) p1 t Always enabled! p1 p2 t 2p1, p2 t 3p1,2p2 t Infinite sequence Infinite Automata! 24

25 25 Back to our choreographies!

26 Every choreography possible? Does an implementation exist that exactly follows this choreography? 26

27 Make a Petri net of it! Realizable? 27

28 Improved version! Realizable? 28

29 29 How about verification of those models?

30 30 How about verification?

31 How about verification? Suppose each system has 2 5 states. How large is the composed state space? O(2 5 * 2 5 * 2 5 * 2 5 * 2 5 * 2 5 ) = O ( )=O(2 30 ) 31

32 Communication between systems 32 Correct: back to initial marking, and all other places empty

33 Let s start simple: consider two systems Correct? No! Correct? Yes! 33

34 34 How about three systems?

35 35 How about three systems?

36 36 How about three systems?

37 37 How about three systems?

38 Criteria for asynchronous communication between systems A A B C Behavior of A is not known by B+C A does not know whether it communicates with B or some network Hence: any sequence A could follow, B+C should not destroy 38

39 Criteria for asynchronous communication between systems A A B C Behavior of A is not known by B+C A does not know whether it communicates with B or some network Hence: any sequence A could follow, B+C should not destroy 39

40 40 Safety not sufficient

41 Verification is hard and expensive! How do you ensure correctness? Design rules! 41

42 Verification vs. Design rules Verification: Go and do as you like, checking is only afterwards Correctness by design: Follow my commands, and I ensure you it will be correct! vs. 42

43 Designing protocols: Communication between systems 43

44 System Visualize communication Service Internal Dependency External Dependency 44

45 Internal dependencies: feature nets Types of dependencies Exclusion / Choice Parallellism Loops State Diagrams? No parallellism! Petri nets? Service is initially modelled as a transition Places denote dependencies We did not model any service yet! Only dependencies! 45

46 When is an internal specification correct? 46 Every service should always eventually be enabled?

47 Internal dependencies as a Petri net What is the initial state? Recurring? One timer? Transitions Internal ( silent ) step Service 47

48 Modeling guidelines: ensuring correctness Subclasses of Petri nets only! State-machines All transitions exactly 1 input and 1 output place Same expressive power as State Diagrams No parallellism, only choices 48

49 Modeling guidelines: allowing for conccurrency Jackson nets Refinement rules Start with a net that is known to be correct Refine with strict rules Extended Jackson nets Jackson rules One additional rule, the workflow extension rule 49

50 Jackson nets (1/2) Rule 1: duplicate places Rule 2: duplicate transitions 50

51 Jackson nets (2) Rule 3: extending a place with a transition Rule 4: extending a transition with a place Rule 5: extending a place with a loop 51

52 Extended Jackson nets Suppose we have a correct workflow (e.g. created by Jackson): Correct: 1-bounded (each place always at most 1 token) weak termination Suppose we have another workflow that is correct Then we may replace the old workflow subnet with the new one 52

53 How about the interactions? Protocols! 53

54 Petri nets: how to design a protocol? 1. Start with a single side: what messages sent and received? In which order? 54

55 Petri nets: how to design a protocol? A B A 1. Start with a single side: what messages sent and received? In which order? 2. Who sends which message? Asign sides to transitions B A B B A A A 55

56 Petri nets: how to design a protocol? A B 1. Start with a single side: A B A B A what messages sent and received? In which order? 2. Who sends which message? Asign sides to transitions 3. Copy the net B B A A A 56

57 Petri nets: how to design a protocol? A A B A B B A B B 1. Start with a single side: what messages sent and received? In which order? 2. Who sends which message? Asign sides to transitions 3. Copy the net 4. Connect the transitions via a message place: sender produces, receiver consumes A A A Design rules: 1. Each choice by one side only! 2. In loops, both sides should sent at least one message 57

58 Putting the pieces together Internal specifications Protocols 58

59 59 Putting the pieces together

60 60 Let s do an example: a simple webshop

61 61 Let s do an example: a simple webshop

62 Ensure correctness? Currently very restrictive: Two systems only interact via one service Acyclic high level picture! Rephrased: Current research!!! 62

63 63 Connection to software architecture: modeling

64 Connection to software architecture: architecture mining Software artefacts Intended architecture Realization 0 Quality Attributes Deployment 0 Component Runtime Analyzer Metrics Architecture Improvement Recommender Software Operation Data Architecture Conformance Deviations Runtime environment Evolution Analyzer Changes Architecture Reconstruction 0 Realized architecture Quality Attributes 64

65 How to connect? Current research! Werf, J.M.E.M. van der (2014). Compositional Verification of Asynchonously Communicating Systems. In: Formal Aspects of Component Software (LNCS, Vol. 8997, pp ), Berlin: Springer Werf, J.M.E.M. van der & Kaats, E. (2015). Discovery of Functional Architectures From Event Logs. In: International Workshop on Petri Nets and Software Engineering (WS-CEUR, Vol: 1372, pp ) Hee, K.M. van, Sidorova, N. and Werf, J.M.E.M. van der (2013). When can we trust a third party?. In: Transactions on Petri Nets and Other Models of Concurrency VIII (pp ). Berlin: Springer. Hee, K.M. van, Sidorova, N. and Werf, J.M.E.M. van der (2013). Refinement of synchronizable places with multi-workflow nets. Fundamenta Informaticae, 122(1-2), D. Bera, K.M. van Hee, and J.M.E.M. van der Werf (2012). Designing weakly terminating ROS systems. In: Applications and Theory of Petri Nets (LNCS, Vol. 7347, pp ), Berlin: Springer. 65