The Service Revolution software engineering without programming languages

Transcription

1 The Service Revolution software engineering without programming languages Gustavo Alonso Institute for Pervasive Computing Department of Computer Science Swiss Federal Institute of Technology (ETH Zurich) ECOWS 06 - Zurich

2 The two sides of SOA Gustavo Alonso Dept. of Computer Science, ETH Zurich 2

3 The beautiful garden = Semantic Web Fully transparent integration at the semantic level Semantic matchmaking Automatic composition through pre- and post- conditions Theorem proven driven QoS Automatic, world wide service search This will not work any time soon: It is not a real problem Ignores that the service matching is not interface based AI mistakes revisited = it is not the logic but the underlying data Ignores the power of vertical standards in this area Gustavo Alonso Dept. of Computer Science, ETH Zurich 3

4 he Holy Grail: Automatic Software Generation Programmer domain High Level Declarative Programming Extension, compilation, resolution, monitoring System domain Enactment, enforcement adaptation, failure handling, notification Gustavo Alonso Dept. of Computer Science, ETH Zurich 4

5 The ugly city = System Integration SOA is not an abstract idea, it is a response to Very well defined needs in enterprise computing Changes in technology (cluster, networking, distribution) The Internet Business-to-Business integration Enterprise Computing coming of age Large scale distributed information systems To understand SOA, the key is to understand the underlying problems, not just the technology involved in solving them Gustavo Alonso Dept. of Computer Science, ETH Zurich 5

6 Automatic Plumbing Generation The promise of SOA is to facilitate integration by Letting the system automatically decide on integration decisions - protocols to use - intermediate processing needed - routing and distribution - data transformations Enforcing standards for defining and operating with services Enforcing the use of service interfaces Related to this, there are many additional opportunities: Languages for orchestration and composition Reasoning about compositions Integration by non-experts (IBM s situational integration) Gustavo Alonso Dept. of Computer Science, ETH Zurich 6

7 Facilitate integration In the medium term, service Programmer domain orientation will solve the problem of connectivity at the syntax level extensions extensions Model Driven Architectures Business Processes Orchestration protocols data map protocols data map mode System Domain mode Gustavo Alonso Dept. of Computer Science, ETH Zurich 7

8 Example of easier integration WS Invocation Framework Use WSDL to describe a service Use WSIF to let the system decide what to do when the service is invoked: - If the call is to a local EJB then do nothing - If the call is to a remote EJB then use RMI - If the call is to a queue then use JMS - If the call is to a remote Web service then use SOAP and XML There is a single interface description, the system decides on the binding This type of functionality is at the core of the notion of Service Oriented Architecture Gustavo Alonso Dept. of Computer Science, ETH Zurich 8

9 SOA and web services are there because of the need to solve the system integration problem not because of any immediate need for the semantic services web Gustavo Alonso Dept. of Computer Science, ETH Zurich 9

10 Service Revolution: integration not programming The key issue in enterprise computing today is integration: Enterprise Application Integration Transactional and Message Oriented Middleware Enterprise Software Bus Data integration Enterprise-wide Architectures Programming is to integration what laying bricks is to architectural design Gustavo Alonso Dept. of Computer Science, ETH Zurich 10

11 What SOA is about SOA Conventional is about: software engineering cannot address: Non-functional properties: performance, reliability, security, Large scale composition Document and message based interaction Distributed systems architecture Run time properties and contracts Protocols, data formats SOA and web services bring to the fore the dependencies of existing programming languages on (single CPU) hardware concepts Gustavo Alonso Dept. of Computer Science, ETH Zurich 11

12 Two contemporary examples XML Programming language variables Semi-structured Documents Asynchronous Data Streams Procedural control flow Event based control flow Procedural interfaces Document based interfaces Behavioral interfaces Language based distribution Platform based distribution Behavioral interfaces Variable assignment Declarative queries Sequential programs Highly parallel and concurrent Impedance mismatch Model mismatch Gustavo Alonso Dept. of Computer Science, ETH Zurich 12

13 Objects Components - Services Object orientation Component systems Service platforms Compiler Compiler based based Object/method Object/method interfaces interfaces Behavior Behavior explicit explicit in in object object Program Program is is closed closed world world Programming Programming language language Middleware Middleware based based Component Component interfaces interfaces Behavior Behavior in in composition composition Program Program is is open open world world Middleware Middleware + + plumbing plumbing Container Container + + middleware middleware Service Service interfaces interfaces Behavior Behavior in in code, code, container container and and composition composition Autonomic, Autonomic, large large scale scale Service oriented architectures Component Models - Middleware Programming languages Gustavo Alonso Dept. of Computer Science, ETH Zurich 13

14 Services not components The two sides: Integration is based on services Programming is based on objects and components There are similarities in theory, in practice they are very different Services are not object oriented Services have document based interfaces Services have a behavioral contract with their consumers Services are reusable by definition Services are (should be) loosely coupled Services are autonomous Services have (very) explicit boundaries Gustavo Alonso Dept. of Computer Science, ETH Zurich 14

15 The post-modern programmer: there is no perfect OO language, there is no universal solution to all software development problems Steve Cook: Object Technology A Grand Narrative? ECOOP 06 Gustavo Alonso Dept. of Computer Science, ETH Zurich 15

16 SOA is HAD HAD is an old concept in distributed information systems H = Heterogeneous A = Autonomous D = Distributed HAD is The essence of and the reason for SOA The problem SOA tries to solve HAD is where the OO paradigm has failed CORBA Object Oriented Databases Reuse Gustavo Alonso Dept. of Computer Science, ETH Zurich 16

17 No HAD in OO: OO Detours (based on Steve Cook, ECOOP 06) Reuse Problem: Objects ignore the environment where they live Real objects in different systems are autonomous Real objects in different systems are heterogeneous Distribution Problem: Abstracting away the problem s essence Tight coupling (language, interaction, development, operation) Database Problem: impedance mismatch Still present with XML, messages, and events Modeling Problem: from OO models to software systems Objects are too low level to model real HAD systems Gustavo Alonso Dept. of Computer Science, ETH Zurich 17

18 The new Software Engineering for SOA Gustavo Alonso Dept. of Computer Science, ETH Zurich 18

19 From: roadmap.cbdiforum.com/reports/protocols/ WS standards Gustavo Alonso Dept. of Computer Science, ETH Zurich 19

20 From: Separation of concerns Gustavo Alonso Dept. of Computer Science, ETH Zurich 20

21 The value of new technology There is no problem in system design that cannot be solved by adding a level of indirection. There is no performance problem that cannot be solved by removing a level of indirection. Gustavo Alonso Dept. of Computer Science, ETH Zurich 21

22 Services = run time Software Engineering A Service contract involves the interface, the Service Level agreement and QoS Contracts are key to be able to develop, debug, optimize and maintain systems developed as a Service contracts are are not not the the static, static, compile time time preanand post-conditions of of pre- conventional programming languages They They are are an an additional software layer layer in in charge charge of of the the dynamic aspects of of using using services combination of services Gustavo Alonso Dept. of Computer Science, ETH Zurich 22

23 Crash course on dynamic AOP An aspect has A join-point: where in the code the advice has to be executed An advice: the code that needs to be executed when the join-point is reached Adaptation is achieved by weaving an aspect at run time that will execute the advice when a particular event in the Example, replace all methods Data_Transfer, with a new method Data_Transfer2. The join-point identifies the method (Data_Transfer) The advice contains the new method (Data_Transfer2). When Data_Transfer method is called, Data_Transfer2 is executed instead execution occurs Gustavo Alonso Dept. of Computer Science, ETH Zurich 23

24 Sorry, I do not encrypt calls Popovici et al., ECOOP 2003 Make app state persistent Make all calls transactional Trap Trap all all calls calls to to me me and and encrypt encrypt using using this this module module Encrypted Encrypted calls calls Trap Trap any any state state change change Run Time Service Container Add Add a a TPmonitor TPmonitor I only accept encrypted calls Gustavo Alonso Dept. of Computer Science, ETH Zurich 24

25 PROSE: a platform for run time adaptation PROSE allows designers to modify any aspect of a running Java: At run time Without stopping or reloading Using Java to express the changes Using a rich collection of interception points PROSE is a real system widely used: Prose 2002: adaptation through run time debugger Prose 2004: adaptation through labeling and JIT Prose 2006: around advice through JIT manipulation Download and more info from Gustavo Alonso Dept. of Computer Science, ETH Zurich 25

26 More run time: Service composition Gustavo Alonso Dept. of Computer Science, ETH Zurich 26

27 JOpera Distributed Kernel Kernel Dispatcher Navigator Process Template Plugin Process Template Plugin UNIX SOAP JAVA... Event Queues State Information Storage Task Execution Scheduler Dispatcher UNIX SOAP JAVA... Navigator Process Template Plugin Process Template Plugin Dispatcher UNIX SOAP JAVA... Download and more information: Gustavo Alonso Dept. of Computer Science, ETH Zurich 27

28 Where we all miss the point JOpera (like most similar systems, including BPEL): Can compose services but cannot really compose processes - Modularity of composition is not well understood The problem is not the control flow but the data flow - Impedance mismatch still there Too dependent of graphic representation - Certain complex operations will never be graphical A process is software - Version control, documentation, comments Cannot really support large scale design - The workflow is only one aspect - Garbage collection, exceptions, concurrency, Missing a SE discipline and languages for processes Gustavo Alonso Dept. of Computer Science, ETH Zurich 28

29 Conclusions SOA and web services could be a passing fashion The problems they try to tackle will remain Cost of application integration Lack of models, languages, and tools Non-functional properties of large scale systems Composition Services The first step to address these problems is to recognize them as fundamental problems and not just things that cannot be done within the current paradigms Gustavo Alonso Dept. of Computer Science, ETH Zurich 29