Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 12-10-01 SEFM Keynote Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt-Universität zu Berlin Theory of Programming.

Similar presentations

Presentation on theme: "1 12-10-01 SEFM Keynote Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt-Universität zu Berlin Theory of Programming."— Presentation transcript:

1 SEFM Keynote Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt-Universität zu Berlin Theory of Programming

2 My background currently: A PhD school on service-oriented Architectures for the Integration of Software-based Processes, exemplified by Health Care Systems and Medical Technology Berlin - Eindhoven - Rostock Service Technology Program … to offer SOC a tool supported foundation 2 B.E.S.T.

3 My background generally: Theoretical Computer Science Theory of Programming Modeling Distributed Algorithms Petri Nets 3

4 1. The basics of SOC The SOC Paradigm: a core paradigm of modern software architectures. loosely coupled components (services), interface based service descriptions. Intended to make software construction more flexible. 4

5 Services are intended to cooperate … start goal You can't kiss by yourself. … start goal Example: goal: to reach goal. 5

6 Services cooperate … start goal Example: goal: to reach goal. … start goal Jointly they may reach their goal. … dependent on their internal behavior. 6

7 7 Voices on SOC 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

8 A recent Software AG user survey 90 percent of the respondents claimed to have made some commitment to SOA adoption. 8

9 Recent Gartners report on the hype curve for emerging technologies: SOA is at the midpoint of the slope of enlightenment, close to mainstream adoption. 9

10 SOC vs. SOA providers requesters broker (registry) bind p. offers a description b. returns providers address r. sends a request 10 The SOA triangle

11 11 Forthcoming challenges 1.The basics of SOC 2.SOC governance in the cloud 3.Challenges for SaaS in the cloud 4.Actual Challenges for SOC 5.Models 6.Lets start 7.Summing up

12 Who is responsible for a provided service? Legal department? Technical proxy? Reliability of a service also depends on the reliability of the cloud provider Resilience guaranteed by the service provider or the cloud provider? How transparent is the cloud location to the requesters? Open for everyone? Elasticity Latency for users SOC Governance in the cloud

13 Requesting services from a cloud How can a requestor be sure the provided service meets his quality standards? Who is responsible for privacy protection? provider, broker, requester? How can the broker (registry) ensure a predictable uptime of a service? Who is allowed to design a service or bring it to production? What happens if a service is retired or changed? Will potential requestors even know? Regulated by contract? 13

14 Requesting services from a public cloud State of the art: manual selection Contract if the service is business critical Consuming a cloud service takes considerable ramp-up time Local service registration is independent of service deployment e.g. on first consumption Who owns the service? Cost of service and other metadata known to registry ? New compliance challenges (data location etc.) might require new rules for consumption (forbid e.g. for person data) 14

15 Brokering services in a cloud The broker: -Which services do I have? -How are they related? -How do I find services from given requester requirements? -May I offer a composed service, extended by an adapter? -Which details about the services description, semantics, constraints, capabilities must I store ? -How do I cope with non-functional properties such as SLA/QoS ? -How do I cope with security information ? -How can I guarantee availability ? 15

16 3. Challenges for SaaS in the cloud SOC vs. SAAS Service Oriented Architecture (SOA) is a means of designing and building software. It is a manufacturing model. Software as a Service (SaaS) is a means of providing / receiving software through an external party to your business; similar to telephone or power utilities. It is a sales and distribution model. 16

17 The business model of SaaS Registry / Market place in the cloud? Replication of relevant metadata Automated requester admittance or licensing? Liability Billing How to provide extended information? Contractual information Just as text? if not, in which format? 17

18 Offering SaaS to the public Short term vs. long term usage Case-to-case usage? How finds a requester a service? Market place? Just Google? Standard description format? No contract = no liability? How much liability does a user need? Brokerage services (cheapest flight) Business model (pay after delivery, paypal-like guarantees) 18

19 SaaS is dangerous for companies How to effectively integrate the outsourced applications with the internally hosted ones? Typically web service interfaces might not fit company design patterns. No direct call Performance, security and reliability (of business critical data) are not guaranteed. Consumption policies are unknown. SaaS applications live outside the corporate firewall. How to handle changes / updates of a services? 19

20 20 4. Actual Challenges for SOC How cope with instantiation refinement (horizontally, hierarchically) correctness substitution equivalence design methodology orchestration choreography brokering fault handling compensation handling

21 21 Decide whether two services may - run into a deadlock - properly terminate (weakly, strongly) - keep a bound of pending messages Construct adapters automatically Test compliance to law (e.g. Basel II) and repair automatically Apply SOA in contexts other than web services and business processes, e.g. wireless networks, embedded systems, physical services (pizza delivery). 4. Actual Challenges for SOC … can hardly be achieved in terms of specification languages. Better: Use models

22 22 What is a model? … a precise (formal) representation of some aspects of a system, on a freely chosen level of abstraction … not necessarily implementable … not even necessarily intended to be implemented 5. Models

23 23 … and what is a model for? A model clarifies meaning and logical structure of constructs, supports design, facilitates analysis, discriminates conceptual features from language- and implementation dependent ones, provides measures for the expressivity of languages. Modeling means concentration onto the essentials!

24 24 Grady Booch: Models as a product … to elevate models as to a first class citizenship... a peer of traditional text languages (and potentially a master)

25 25 … from IBM-Lab Zürich (2007) Business Driven Development code only code model code model code model code model code visuali- zation Round trip Engin- eering model centric the model is the code time

26 26 What is a good model? expressive enough to cover aspects that you consider relevant simple enough to offer analysis techniques. The perfect model: intuitive, abstract, as well as precise and analyzable.

27 27 Example ImplementationAnalysis BPELBPMN Petri Nets (including variants) became fundamental for BP semantics

28 28 Modeling alleviates analysis We should do it in analogy to programming languages: The semantics of a service is a mathematical object! The composition of services is a (simple!) mathematical (or logical!) operation. True, this is presently not the case. BUT WE SHOULD spend effort into this! … and this requires modeling.

29 6. Lets start 29 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 understand the environment? ! It is an open system, too! open system component reactive system service

30 30 Services can be composed Let S denote the set of all services (of interest). 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

31 31 Some services are beautiful Beauty: deadlock free weakly terminating strongly terminating finite state ticket machine client: client gets either ticket or money back deadlock: ticket machine crashes formally: a "beauty" predicate, i.e. a subset S. In most cases, is weak termination.

32 32 A simple structure structure ( S ;, ) set of services, S, composition : S S S beauty S. This yields an amazing wealth of canonical constructs!

33 33 The semantics of services structure ( S ;, ) Def. Let R, S S. R is a partner of S iff S R sem(S) = def the set of all partners of S. Observation: S is ordered: For Q, R S : Q < R iff sem(Q) sem(R). Def. Two services R,S are equivalent, R S, iff R < S and S < R. Intuitively: Two systems are equivalent whenever their environment can not distinguish them.

34 34 The semantics of services structure ( S ;, ) Def. Let R, S S. R is a partner of S iff S R sem(S) = def the set of all partners of S. Observation: S is ordered: For Q, R S : Q < R iff sem(Q) sem(R). Observation: sem(S) has canoncal elements most liberal partners of sem(S) They yield a finite characterization of sem(S)

35 35 Quests at the partners of a service, S Does S have partners at all ? Is R a partner of S ? How construct a canonical partner of S ? How characterize all partners of S ? Controllability Composability most liberal Operating Guideline

36 36 Quests at the substitution of S for S Can S substitute S ? Given R and S : Construct T such that R is a partner of S T Substitution adapter generation … on the fly

37 Rule basede adapters Construct an adapter that respects requirements as given by a domain expert. Typical requirements (business rules): Dollar may be changed to Euro. An arm chair may be put into a box. A request may be copied. Foreign Spam may be deleted. I may produce an order. 37

38 7. Summing up: shape of partner acyclic centralized decentralized autonomus compatibility notion deadlock freedom weak termination strong termination bounded communication messaging synchronous asynchronous queued other requirements behavioral constraints transactions, policies, Problem dimensions:

39 17 problems in various settings 3 powerful technologies state space, partner synthesis, operating guidelines Hype independent through formal modeling (8 Jou, 30 Conf) publications, (8 PhD, 30 Stud/Master) theses,... since about Cooperations Uni Rostock, TU Eindhoven, Uni Stuttgart, … 6 tools LoLA, Fiona, BPEL2OWFN, OWFN2BPEL, RACHEL, SEDA, For details: 39

40 SEFM Keynote Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt-Universität zu Berlin Theory of Programming Challenges are many and are not trivial worth to be attacked need research into fundamental modeling techniques

Download ppt "1 12-10-01 SEFM Keynote Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt-Universität zu Berlin Theory of Programming."

Similar presentations

Ads by Google