1 / 40

12-10-01 SEFM Keynote

12-10-01 SEFM Keynote . Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt- Universität zu Berlin. Theory of Programming. My background. currently : A PhD school on service-oriented Architectures for the Integration of Software-based Processes,

prue
Download Presentation

12-10-01 SEFM Keynote

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. 12-10-01 SEFM Keynote Service Oriented Computing: Forthcoming challenges Wolfgang Reisig Humboldt-Universitätzu 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 B.E.S.T.

  3. My background • generally: • Theoretical Computer Science • Theoryof Programming • Modeling • Distributed Algorithms • Petri Nets

  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.

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

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

  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.

  9. Recent Gartner’s report • on the hype curve for emerging technologies: • SOA is at the midpoint of the “slope of enlightenment” , • close to mainstream adoption.

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

  11. Forthcoming challenges • The basics of SOC  • SOC governancein thecloud • Challenges for SaaSin the cloud • Actual Challenges for SOC • Models • Let’s start • Summing up

  12. 2. SOC Governance in the cloud • • 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

  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?

  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)

  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 ?

  16. 3. Challenges for SaaSin 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.

  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?

  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)

  19. SaaSis 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?

  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. 4. Actual Challenges for SOC • 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) . … can hardly be achieved in terms of specification languages. Better: Use models

  22. 5. Models • 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

  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. GradyBooch: Models as a product „ … to elevate models as to a first class citizenship ... a peer of traditional text languages (and potentially a master)“

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

  26. 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. What is a good model?

  27. Example Implementation Analysis Petri Nets (including variants) became fundamental for BP semantics BPEL BPMN

  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. Let’s start 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. 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. 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 bS. • In most cases, b is weak termination.

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

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

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

  35. Quests at the partners of a service, S • Does S have partners at all ? • Is R a partner of S ? • How construct a canonicalpartner of S ? • How characterize allpartners of S ? Controllability Composability “most liberal” Operating Guideline

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

  37. Rule basede adapters Construct an adapter thatrespectsrequirements asgivenby a domain expert. Typicalrequirements (businessrules): “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.”

  38. 7. Summing up: Problem dimensions: compatibilitynotion shape of partner deadlockfreedom weaktermination strong termination boundedcommunication acyclic centralized decentralized autonomus behavioralconstraints transactions, policies, ... synchronous asynchronous queued other requirements messaging

  39. service-technology.org • 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 2004 • 9 Cooperations Uni Rostock, TU Eindhoven, Uni Stuttgart, … • 6 tools LoLA, Fiona, BPEL2OWFN, OWFN2BPEL, RACHEL, SEDA, • For details:http://service-technology.org/

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

More Related