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

Slides:



Advertisements
Similar presentations
SOA Masterclass - Fundamentals of SOA |11 February 2009 | Page 1 Fundamentals of SOA.
Advertisements

1 Senn, Information Technology, 3 rd Edition © 2004 Pearson Prentice Hall James A. Senns Information Technology, 3 rd Edition Chapter 7 Enterprise Databases.
University of Paderborn Software Engineering Group E. Kindler Handout for the talk given in the eJustice Dialogues at Saarland University. June 6, 2005.
Logical Model and Specification of Usage Control Xinwen Zhang, Jaehong Park Francesco Parisi-Presicce, Ravi Sandhu George Mason University.
Distributed Systems Architectures
Chapter 7 System Models.
Requirements Engineering Process
© 2008 Pearson Addison Wesley. All rights reserved Chapter Seven Costs.
Copyright © 2003 Pearson Education, Inc. Slide 1 Computer Systems Organization & Architecture Chapters 8-12 John D. Carpinelli.
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 4 Computing Platforms.
Processes and Operating Systems
Copyright © 2011, Elsevier Inc. All rights reserved. Chapter 6 Author: Julia Richards and R. Scott Hawley.
Author: Julia Richards and R. Scott Hawley
Properties Use, share, or modify this drill on mathematic properties. There is too much material for a single class, so you’ll have to select for your.
RXQ Customer Enrollment Using a Registration Agent (RA) Process Flow Diagram (Move-In) Customer Supplier Customer authorizes Enrollment ( )
1 Hyades Command Routing Message flow and data translation.
Jeff Mischkinsky Nickolas Kavantzas Goran Olsson Web Services Choreography.
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination. Introduction to the Business.
18 Copyright © 2005, Oracle. All rights reserved. Distributing Modular Applications: Introduction to Web Services.
Language Specification using Metamodelling Joachim Fischer Humboldt University Berlin LAB Workshop Geneva
Properties of Real Numbers CommutativeAssociativeDistributive Identity + × Inverse + ×
Chapter 5 Input/Output 5.1 Principles of I/O hardware
Chapter 1 Introduction Copyright © Operating Systems, by Dhananjay Dhamdhere Copyright © Introduction Abstract Views of an Operating System.
1 Click here to End Presentation Software: Installation and Updates Internet Download CD release NACIS Updates.
Alexey Miroshnikov InfoStroy Ltd. Locatioin: St.Petersburg, Russia Established: 1990 APL: since 1979 First APL conference: 1990, Copenhagen People: 42+
1 The Impact of Buy-Down on Sell Up, Unconstraining, and Spiral-Down Edward Kambour, Senior Scientist E. Andrew Boyd, SVP and Senior Scientist Joseph Tama,
Database Systems: Design, Implementation, and Management
Site Safety Plans PFN ME 35B.
Auto-scaling Axis2 Web Services on Amazon EC2 By Afkham Azeez.
Week 2 The Object-Oriented Approach to Requirements
Computer Literacy BASICS
Configuration management
Software Engineering - Specifications 1 Specifications Specification document must be clear, complete and correct.
Software testing.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering.
© 2011 TIBCO Software Inc. All Rights Reserved. Confidential and Proprietary. Towards a Model-Based Characterization of Data and Services Integration Paul.
Chapter 4 Gates and Circuits.
Measuring the Economy’s Performance
CS 6143 COMPUTER ARCHITECTURE II SPRING 2014 ACM Principles and Practice of Parallel Programming, PPoPP, 2006 Panel Presentations Parallel Processing is.
IP Multicast Information management 2 Groep T Leuven – Information department 2/14 Agenda •Why IP Multicast ? •Multicast fundamentals •Intradomain.
25 July, 2014 Hailiang Mei, TU/e Computer Science, System Architecture and Networking 1 Hailiang Mei Remote Terminal Management.
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
Basel-ICU-Journal Challenge18/20/ Basel-ICU-Journal Challenge8/20/2014.
1..
31242/32549 Advanced Internet Programming Advanced Java Programming
CONTROL VISION Set-up. Step 1 Step 2 Step 3 Step 5 Step 4.
© 2012 National Heart Foundation of Australia. Slide 2.
Lecture 6: Software Design (Part I)
Chapter 10 Software Testing
1 © 2004, Cisco Systems, Inc. All rights reserved. CCNA 1 v3.1 Module 2 Networking Fundamentals.
Science as a Process Chapter 1 Section 2.
Executional Architecture
Global Analysis and Distributed Systems Software Architecture Lecture # 5-6.
Presentation 7 part 2: SOAP & WSDL.
Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques
Chapter 10: The Traditional Approach to Design
Analyzing Genes and Genomes
Systems Analysis and Design in a Changing World, Fifth Edition
Essential Cell Biology
Database Administration
PSSA Preparation.
Essential Cell Biology
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering 1.
Chapter 13 The Data Warehouse
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 13 Slide 1 Application architectures.
Energy Generation in Mitochondria and Chlorplasts
Modeling Main issues: What do we want to build How do we write this down.
From Model-based to Model-driven Design of User Interfaces.
1 FLACOS Malta October 2008 Service Oriented Architectures: The new Software Paradigm W. Reisig Humboldt-Universität zu Berlin Theory of Programming.
Inventory of Distributed Computing Concepts and Web services
Presentation transcript:

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, 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.

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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 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 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 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 … 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 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 … 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 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 Example ImplementationAnalysis BPELBPMN Petri Nets (including variants) became fundamental for BP semantics

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.

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 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 S. In most cases, is weak termination.

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 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 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 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 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

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

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:

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: service-technology.org 39

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