1. 1 FLACOS Malta October 2008 Service Oriented Architectures: The new Software Paradigm W. Reisig Humboldt-Universität zu Berlin Theory of Programming

2. 2 Service Oriented Architectures: The new Software Paradigm I Some General Remarks II Some First Assumptions for a Formal Framework III A Modelling Technique for Services IV A small Case Study

3. 3 Service Oriented Architectures: The new Software Paradigm I Some General Remarks II Some First Assumptions for a Formal Framework III A Modelling Technique for Services IV A small Case Study

4. 4 Voices on SOA from the software industry “THE most relevant emerging paradigm” “A substantial change of view as it happens at most once each decade” “The next fundamental software revolution after OO” “Much more than just an other type of software!” “The foundational layer for tomorrow's information systems”

5. 5 The paradigm of SOA -is intended to couple encapsulated software components ("services"), - supports flexibility and convenience of interaction. - has very pragmatic sources and backgrounds: - Business process technology, - Web service technology.

6. 6 Current Practice of SOA -equips business processes with web-based communication facilities. -is influencing -Enterprise Application Integration, -Software Engineering, -Systems Management, -Data provisioning, -BPI, -B2B.

7. 7 Languages and Modelling Techniques WS- BPEL, Business Process Modelling Notation (BPMN), YAWL, ADEPT, UML -ACT, Petri Nets, …

8. 8 The future of SOA pursues more ambitious goals: -modularization, proper interfaces, standardization for enterprise computing and enterprise application integration. -applies SOA in contexts other than web services and business processes. e.g. wireless networks -spawn SOA as a new paradigm of computing. -requires a theoretical basis for SOA, independent from implementations. i.e. mathematical models

9. 9 What is so fundamentally new? classical theory: A computing system computes functions.  925 moderate interest in the environment 35not terminating

10. 10 the idea of “service” a new kind of system: fundamentally new aspects: -infinite runs are sensible -environment is not trivial, deserves its own attention, should be described formally. How? ! Just as the system itself !

11. 11 problems to be addressed by models - Service Composition, orchestrations and choreographies: ! disambiguate these notions ! - Semantics of services: … specified in a given modelling language ! A service may not be intended to be implemented ! - Expressive power of modelling languages: Idea: … relative to the bare minimum of expressive power needed to specify services.

12. 12 problems to be addressed by models -Substitutability of services: Replace S by T … also during execution of S. -Brokering: Which information about processes should the broker know? -Reliability and Correctness: Verification, at varying levels of rigour. -Design Methodology: Methods and principles of Software Engineering must be adapted to SOA.

13. 13 Service Oriented Architectures: The new Software Paradigm I Some General Remarks II Some First Assumptions for a Formal Framework III A Modelling Technique for Services IV A small Case Study

14. 14 Service Composition Let S denote the set of all services. Services are made to be composed. a ticket machine and a client Two composed services behave like one service purchase = def ticket machine and client formally:  : S  S  S purchase = def ticket machine  client

15. 15 Semantics of a service A (composed) service may regularly terminate. ticket or money back irregular: ticket machine crashes formally: a "beauty" predicate, i.e. a subset   S. In most cases,  is weak termination. Def. Let R, S  S. R is a partner of S iff R  S   sem(S) = def the set of all partners of S.

16. 16 Equivalence of services R is at most as comprehensive as S (written R<S) iff each partner of R is a partner of S. formally: R < S iff sem(R)  sem(S). Consequently, two services are equivalent, R  S, iff R < S and R < S. Apparently: Two systems are equivalent whenever their environment can not distinguish them.

17. 17 Quests at the partners of a service, S Is R a partner of S ? Does S have partners at all ? Is there a canonical partner of S ? How characterize all partners of S ? Controllability Composability “most liberal” Operating Guideline we offer implemented analysis techniques for all of them

18. 18 Quests at the substitution of S’ for S Can S’ substitute S ? Is there a public view of S ? Given R and S : Construct T such that R is a partner of S  T Substitution Normal form adapter generation that‘s what we are doing right now

19. 19 Service Oriented Architectures: The new Software Paradigm I Some General Remarks II Some First Assumptions for a Formal Framework III A Modelling Technique for Services IV A small Case Study

20. 20 coin tea! coffee! beverage coin coffee! beverage Toy example: a vending machine the coffee partner:

21. 21 Beauty predicate: Proper termination coin beverage with no tokens left on the interface coin tea! coffee! beverage

22. 22 coin tea! beverage Another partner the tea partner: coin tea! coffee! beverage

23. 23 coin tea! coffee! beverage coin tea! coffee! beverage Are there more partners? the coffee-or-tea partner:

24. 24 coin tea! coffee! beverage First coffee! then coin coin coffee! beverage Swap the order

25. 25 coin tea! coffee! beverage coin tea! coffee! beverage Three independent threads of control This is the most permissive partner: Each other partner can be derived from this one. no sequential control

26. 26 coin tea! coffee! beverage coin tea! coffee! beverage characterize the set of all partners by help of this one This is the most permissive partner: Each other partner can be derived from this one. operating guideline

27. 27 Petri Nets … the mst generic modelling technique for services offers the bare minimum to express yourself good to verify properties and for canonical constructs ! translate your pet language into Petri nets

28. 28 Service Oriented Architectures: The new Software Paradigm I Some General Remarks II Some First Assumptions for a Formal Framework III A Modelling Technique for Services IV A small Case Study

29. 29 Case Study: BPEL Online Shop yesno

30. 30 open net, generated by BPEL 2 oWFN

31. 31 automatically generated partner

32. 32 the operating guideline one more interleaving inscriptions

33. 33 Modified Shop yes no decision not communicated! has no partners at all

34. 34 FLACOS Malta October 2008 Service Oriented Architectures: The new Software Paradigm W. Reisig Humboldt-Universität zu Berlin Theory of Programming the end