1 / 34

FLACOS Malta October 2008

FLACOS Malta October 2008. Service Oriented Architectures: The new Software Paradigm W. Reisig Humboldt-Universität zu Berlin. Theory of Programming. Service Oriented Architectures: The new Software Paradigm. I Some General Remarks II Some First Assumptions for a Formal Framework

ajay
Download Presentation

FLACOS Malta October 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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. 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. 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. 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. Languages and Modelling Techniques WS- BPEL, Business Process Modelling Notation (BPMN), YAWL, ADEPT, UML -ACT, Petri Nets, …

  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. What is so fundamentally new? classical theory: A computing system computes functions. 9 25 -1  3 5 not terminating moderate interest in the environment

  10. the idea of “service” 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 ! a new kind of system:

  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. 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. 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. 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. 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 bS. In most cases, b is weak termination. Def. Let R, S S. R is a partner of S iff R  S b. sem(S) =def the set of all partners of S.

  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. Quests at the partners of a service, S • Is R a partner of S ? • Does S have partners at all ? • Is there a canonicalpartner of S ? • How characterize allpartners of S ? Composability Controllability “most liberal” Operating Guideline we offer implemented analysis techniques for all of them

  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. 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. coin coin coffee! tea! coffee! beverage beverage Toy example: a vending machine the coffee partner:

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

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

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

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

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

  26. coin tea! coffee! beverage operating guideline 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. coin tea! coffee! beverage

  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. 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. Case Study: BPELOnline Shop yes no

  30. open net,generated by BPEL2oWFN

  31. automatically generated partner

  32. one moreinterleaving the operating guideline inscriptions

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

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

More Related