Mikro-SOA vs. Makro-SOA

Transkript

1 Mikro-SOA vs. Makro-SOA Orientation in Objects GmbH Weinheimer Str Mannheim Version: Abstract In den letzten Jahren ist die Idee der Service-orientierten Architektur (SOA ), aus der Forschung kommend, in den Management-Ebenen und IT-Abteilungen großer Unternehmen angekommen und wurde dort teilweise begeistert zum führenden Architekturstil erkoren. Mit der SOA Suite 11g stellt Oracle eine ausgereifte Infrastrukturplattform für diesen Architekturstil bereit. Dabei sind Verständnis und Auffassung einer SOA oft weit von der ursprünglichen Idee entfernt. Wir möchten mit diesem Stream eine grundlegende Unterscheidung zwischen zwei Archtitekturstilen treffen und kritisch diskutieren. Zum Einen ist dies die Mikro-SOA, welche sich in der Realität leider oft wiederfindet und ein Verständnis offenbart, das so wahrscheinlich nie gedacht war und die Leitidee einer SOA in ein Monster verkehrt, welches trotz ausgereiftester Werkzeuge kaum beherrschbar ist und hohe Kosten in der Entwicklung und Wartung generiert. Demgegenüber steht die Makro-SOA, welche als Grundintention auf die Integration von bestehenden und neuen Anwendungen abzielt und gerade deswegen eine heterogene Systemlandschaft erlaubt, deren Integration und Zusammenspiel über Serviceschnittstellen vollzogen wird. Erst darin können Werkzeuge und Infrastrukturen, wie sie in der SOA Suite 11g kombiniert sind, ihren eigentlichen Mehrwert entfalten, ohne dass wartungsintensive Einzelsysteme gebaut werden, die (technisch) kaum komplexer sein könnten. Der Stream kann gerne als Plädoyer für ein "Back to the roots" in Bezug auf den Architekturstil SOA verstanden werden. Er beinhaltet eine Beleuchtung der ursprünglichen Ziele, deren Verkehrung und Missverständnisse, sowie Möglichkeiten und Sprachregelungen um das dunkle Tal einer überzogenen Architekturanwendung zu verlassen. 2 1

2 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 3 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 4 2

3 Motivation Quelle: 5 Architektur A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture. (Thomas Roy Fielding) Die Gliederung in Subsysteme 6 3

4 Definitionsversuch einer SOA (1) SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird. OASIS Reference Model for Service Oriented Architecture 1.0,Committee Specification 1, 2 August Definitionsversuch einer SOA (2) Service Oriented Architecture is an architectural style for building systems based on interacting loosely coupled, coarse grained autonomous components called services. Each service expose processes and behavior through contracts, which are composed of messages at discoverable addresses called endpoints. Services behavior is governed by policies which are externally to the service itself. SOA Patterns, Arnon Rotem-Gal-Oz, Manning ebook, 8 4

5 Definitionsversuch einer SOA (3) Service-oriented architecture (SOA) is the dominant architectural style for agile business applications, and is used when enterprises anticipate application sharing and frequent system changes. SOA helps business managers and analysts develop new business processes, and modify processes more quickly and at a lower cost. Gartner coined the term "SOA" and published the first reports in the industry on it in SOA enables new business models that involve the introduction of new products and services, particularly those that require the online cooperation of multiple business units.... Service-Oriented Architecture, Gartner IT-Glossary 9 Definitionsversuch einer SOA (4) Essentially, SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls. SOA would be better-named "interface-oriented architecture. Service-Oriented Architecture Scenario, Gartner Research Note AV

6 Analogie zu einer SOA im richtigen Leben Geschäftstreibende in einer Stadt Jeder Unternehmer bietet bestimmten Dienst Wird von vielen Verbrauchern in Anspruch genommen Geschäftswelt besteht aus vielen Unternehmen Gemeinesame Konventionen Gemeinsame Währung Gemeinsame Sprache Bauvorschriften, etc 11 Gemeinsamkeiten der Definitionen Architekturstil Keine Aussage über Technologie Lose Kopplung von Diensten Unabhängigkeit der Dienste Soll Flexibilität durch Interoperabilität bieten Neue Dienste können einfach angebunden werden Dienste können zum Abbilden von Prozessen orchestriert werden Mit Hilfe von Business Process Engines Dienste kommunizieren über Nachrichten 12 6

7 SOA = Prinzipien Leverages open standards Software as services Services are loosely coupled Focus on business function not technology Platform independence SOA Manifest Geschäftswert über technische Strategie Strategische Ziele über projektspezifischen Nutzen Immanente Interoperabilität über maßgeschneiderte Integration Gemeinsam verwendete Services über zweckgebundene Implementierungen Flexibilität über Optimierung Evolutionäre Vervollkommnung über Streben nach anfänglicher Perfektion

8 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese Flughafenwerbung (Heatrow ) 16 8

9 2003 Herausforderungen an die IT Integration heterogener, verteilter Systeme Zahlreiche inkompatible Hersteller und Protokolle Keine einheitliche Technologie Java, C#, C++, CORBA, RMI, etc. Bestehende Altsysteme verbinden (lose Kopplung) Firmenzukauf, Migration, etc. Einfache Anbindung neuer Kunden Unterstützung von Webclients, mobilen Clients, etc. Firewalls müssen überwunden werden Meist nur Port 80 (HTTP) geöffnet 17 Lösungsansatz 1: Datenintegration System A System B Daten B Daten Kopie Daten B Daten Daten B Replikation Master / Slave Datenabgleich Userdaten Redundanz Konflikte 18 9

10 Lösungsansatz 2: Funktionale Integration System A Anfrage nach Daten Antwort System B Daten Bitte um Änderung Antwort Daten Daten B Just in Time! 19 Lösungsansatz 2: Transaktionale Integration? System A Anfrage nach Daten Antwort System B Daten Bitte um Änderung Antwort Daten Daten B Transaktions Koordinator 20 10

11 Probleme von Einzelintegrationen im Unternehmen Eigenes Unternehmen Partner 21 Probleme der Einzelintegration (1) Fest gekoppelt, zerbrechlich und unflexibel Jeder Dienst ist fest mit einem anderen Dienst verbunden Aufwendige Schnittstellenpflege Viele Point-to-Point Lösungen Änderung einer Anwendung aufwendig Kann sich auf viele andere Anwendungen auswirken Logik zum Routing steckt in einzelnen Anwendungen Welches Ziel hat eine Nachricht / Methodenaufruf? 22 11

12 Probleme der Einzelintegration (2) Kein einheitliches Kommunikationsprotokoll Jede Anwendung definiert (eigenes) Protokoll Kein einheitliches Sicherheitsmodell Asynchrone Kommunikation schwer einzubauen Eventuell keine zuverlässige Verarbeitung Reliability nicht gewährleistet Keine zentralen Dienste Monitoring, Abrechnungslücke 23 Best Practices Lösungsansätze: EAI Patterns Dateiübertragung Gemeinsame Datenbank Entfernte Methodenaufrufe Remote Procedure Calls Nachrichtendienste

13 SOA 1998? Custom Application CORBA Proxy RMI Proxy X Proxy CORBA RMI Protocol X CRM Finance Produktion Kunde Vertrag Konto Produkt 25 XML als Wegbegleiter von SOA Don Box SOAP XML Nachrichten XML-RPC Final Dave Winer HTTP, URL, URI REST Einfluß SOAP

14 Definition von Services als Web Service (W3C) A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols. (W3C) 27 Definition von Services als Web Service (IBM) Web Services are self-contained, modular applications that can be described, published, located and invoked over a network, generally the Web to create innovative products, processes, and value chains. Web services can be local, distributed or Webbased. They interact with and/or invoke each other, fulfilling specific tasks and requests that, in turn, carry out specific parts of complex transactions or workflows. (IBM) 28 14

15 Vorteile von Services als Web Services Interoperability Mit CORBA, DCOM,... Verbreitung Basiert auf XML Niedrige Einstiegsschwelle Einfache Technik, kostenlose Toolkits, automatische COM und EJB Anbindung Nicht auf eine Plattform oder Technologie beschränkt Passieren von Firewalls bei Nutzung von HTTP als Übertragungsprotokoll Offener HTTP Port 29 Was machen Web Services anders als Vorgänger? Basiert auf echten, weitverbreiteten Standards TCP/IP, HTTP, XML,... Führende Softwarehersteller unterstützen den Standard Oracle, IBM, Microsoft,... Bestehende Infrastruktur läßt sich weiternutzen Internet, Router, Firewalls, Web Server,

16 Web Service Interoperability Interop Stack Universal Service Interop Protocols (these layers are not defined yet) Universal Description, Discovery and Integration (UDDI) Simple Object Access Protocol (SOAP) Extensible Markup Language (XML) Common Internet Protocols (HTTP, TCP/IP) 31 Überlegungen gegen WebServices XML Verarbeitung unter Umständen aufwendig In vielen Anwendungsfällen unkritisch Einheitliche Technologie Keine heterogene Server- und Client-Technologie Keine Internetnutzung gewünscht Intranet: Anwendung muss keine Firewall überwinden 32 16

17 Vision 2003: Service Oriented Business Application (SOBA) SOBA WS Proxy WS Proxy WS Proxy WS Proxy SOAP SOAP SOAP SOAP CRM Finance Produktion Security Kunde Service Vertrag Service Konto Service Produkt Service Security Service 33 SOA als EAI 2.0? Application WebServer WebServer Application Server RMI JAX-RPC Servlet XML XML JAX-RPC Servlet RMI Server Endpoint Endpoint EJB Connector Firewall Firewall EJB Connector EIS EIS Application WebServer WebServer Application Server XML JAX-RPC Servlet XML XML JAX-RPC Servlet RMI Server Endpoint Endpoint EJB Connector Firewall Firewall Firewall EJB Connector EIS EIS 34 17

18 Integration Unternehmensübergreifend Eigenes Unternehmen Partner 35 Gliederung Einleitung Definitionsversuch Ursprung und Ziel These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interface Synthese 36 18

19 These Makro-SOA = EAI + XML + WS 37 Weitergehende Überlegungen zur Makro-SOA Schnittstellen werden auf Dienstebene definiert Klare Trennung zwischen Schnittstelle und Implementierung Ermöglicht die Kombination einzelner Dienste Durch einheitliche Schnittstellenbeschreibung in WSDL erleichtert SOA startet(e) meist nicht auf grüner Wiese Bestehende Systeme müssen integriert werden Fachlicher Dienst muss technisch zur Verfügung gestellt werden Unterstützung einer Vielzahl von technischen Schnittstellen Bestehende Anwendung besitzt eventuell keine Web Service Schnittstelle 38 19

20 Weitergehende Überlegungen zur Makro-SOA Anwendungen immer noch fest gekoppelt Anwendungen sind immer noch Client eines anderen Dienstes Prozesslogik steckt immer noch in Anwendung Keine Trennung von Prozesslogik, Anwendungslogik und Schnittstelle Eigentlich SOA nicht gleich SOAP / Web Services? 39 Lösungsansatz Middleware-Plattform Systemunabhängigkeit Administrationsunterstützung Discovery Zuverlässigkeit Ressourcenverbrauch Stabilität Middleware Skalierbarkeit Fehlertoleranz Sicherheit Konsistenz Integration proprietärer Komponenten Erweiterbarkeit 40 20

21 Lösungsansatz Standard-Stack Choreography WS-CDL Orchestration WS-BPEL Geschäftsprozesse WSDL UDDI Beschreibung WS-Coordination WS-Security SOAP XML, Encoding WS-Transaction WS-Reliable Messaging Andere Protokolle Quality of Service Transport und Encoding 41 WS*-Spezifikationen verwendet WS-BPEL WS-Transaction WS-Atomic Transaction WS-BusinessActivity verwendet verwendet empfiehlt WS-Coordination verwendet verwendet WS-SecureConversation definiert Erweiterungen WS-Addressing WS-Trust definiert Erweiterungen WS-Security WS-Policy 42 21

22 Die WS*-Spezifikationen 43 These Mikro-SOA = Makro-SOA + Improvements? 44 22

23 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 45 Ursprung: EAI 2.0 Interorganisationaler Datentransfer mit XML XML-Struktur DTD DTD-Austausch DTD XML-Struktur DBMS validieren validieren validieren DBMS XML XML XML Transformator XSL 46 23

24 Serviceorientierter Datenaustausch zwischen Systemen Austausch System A Transformation BML Punkt-zu-Punkt AML Transformation System B Internes Datenmodell Internes Datenmodell 47 Lösungsansatz Kanonisches Modell SOA hat Wiederverwendung zum Ziel Schnell neue Funktionen Auf Basis von bestehenden Services Services liefern Dokumente Leichte Austauschbarkeit als Ziel Kanonisches Modell als Austauschformat Transformation in Kanonisches Modell Wiederverwendbares Dokumentenmodell Modellierung z.b. in UML Explizite Darstellung und Dokumentation Möglicher Grad der Wiederverwendung steigt 48 24

25 Lösungsansatz Kanonisches Modell Austausch kanonisch System A Transformation KML KML Transformation System B Internes Datenmodell Internes Datenmodell 49 Vorteile eines kanonischen Modells Lose Kopplung auf Datenebene Systeme kennen nur ihr Format und das kanonische Transformationen sind nur noch in ein Austauschformat notwendig Lohnt sich bei steigender Anzahl von Systemen Einheitliches Verständnis eines Dokuments 50 25

26 Mikro-SOA: Wiederverwendung des kanonischen Modells in der Anwendungsentwicklung DO XSD / Kanonisches Modell Process Service Domain Service 1 Domain Service 2 DO e.g. findinvoicesbycustomer(..) JAXB-Klasse Konverter Data Access Service 1 e.g. findcustomerbyuid(..) Data Access Service 2 DO e.g. findinvoicesbycustomeruid(..) JPA-Klasse 51 Mikro-SOA Support in Java Plattform? Java Klasse 1 1 XML Schema 1 * Java Objekte Objekte Objekte JAXB * * XML Dokumente Dokumente Dokumente 52 26

27 Probleme Kanonisches Datenmodell zieht sich durch alle Schichten eines Service bzw. einer Applikation Aufwände bei Änderungen Interne Repräsentation ist nicht mehr spezifisch für eine Domäne Kontext-abhängige Ausprägung ist nicht mehr möglich 53 Makro-SOA: Contract-First, Adaption der Implementierung Web Service Adapter Applikation XML Business Objekte Kanonisches Modell 54 27

28 Mikro-SOA: Implementation-to-Contract Web Service Applikation Business Objekte XML Kanonisches Modell 55 Probleme Inneres Datenmodell als erster Schritt zu kanonischem Modell Behauptung: Iterative/imkrementelle Vorgehensweise führt langfristig zu echter kanonischer Form Abhängigkeiten entstehen, die dann zum Problem werden (Konsumenten erwarten Stabilität) Implementierung(sdetail) kann nicht ohne weiteres geändert werden Neue externe Anforderungen an kanonisches Modell wirken direkt auf internes Modell 56 28

29 Makro-SOA: Kanonisches Datenmodell in XML Schema 57 Lösungsansatz: Formale Modellierung der kanonischen Form Komplexität von XML Schema soll durch Werkzeugunterstützung beherschbar werden Formale Modellierung z.b. in UML naheliegend Entity type D attribute (ERM) ERM domain D attribute (ERM) D attribute (ERM) ERM domain ERM domain XSD D attribute (ERM) ERM domain 58 29

30 Mikro-SOA: Modellgetriebene SOA Kanonisches Modell DO Process Service XSD Domain Service 1 Domain Service 2 DO e.g. findinvoicesbycustomer(..) JAXB-Klasse Konverter Data Access Service 1 e.g. findcustomerbyuid(..) Data Access Service 2 DO e.g. findinvoicesbycustomeruid(..) JPA-Klasse 59 Probleme einer modellgetriebenen SOA Semantische und syntaktische Mächtigkeit von XSD sollte nicht unterschätzt werden Es ist leichter ein Dokumentformat zu modellieren als es in Schema zu definieren stimmt nicht immer Generierung weiterer Zielartefakte macht Modell noch komplexer Aufwand der Modellwartung, z.b. Mappingmodelle MDSD befördert iterativ-inkrementelles Denken Stabilität vs. Evolution MDSD befördert Verwendung von Elementen des kanonischen Modells innerhalb der Anwendungsentwicklung 60 30

31 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 61 Makro SOA Vorgehen: Geschäftslogik als Business Services exponieren Service A Service B Service C Service D Funktionalität 62 31

32 Lösungsansatz: Schnittstellendefinition durch WSDL Servicemodell Process Service e.g. Order process WSDL Domain Service 1 Domain Service 2 e.g. Invoice service Data Access Object Data Access Object 63 Makro SOA: Business Services technisch mit WSDL spezifizieren WSDL A WSDL B WSDL C WSDL D Funktionalität 64 32

33 WSDL Elemente Elemente in WSDL Dokumenten: Types Ein Container für Datentypdefinitionen wie XSD Messages Übertragene Daten Port Type Ein Satz von Operationen die von einem oder mehreren Endpunkten unterstützt werden Binding Konkretes Protokoll und Datenformat Spezifikation für einen Port Type Service Sammlung von verwandten Endpunkten Port Endpunkt bestehend aus Binding und Netzwerkadresse Operation Operation die vom Service unterstützt wird 65 Perspektivwechsel: Anwendung als Summe von Business Services Anwendung X Service A Service B Service C Service D 66 33

34 Mikro SOA: Anwendung als Summe von Web Services (WSDL basiert) Anwendung X WSDL A WSDL B WSDL C WSDL D 67 Probleme Performanzanforderungen an applikationsinterne Kommunikation sind höher als in typischen Integrationsszenarien Lokale Kommunikation Synchrone Aufrufe Große Datenmengen Verarbeitung von Strömen Nutzung von gemeinsamen Datenkontexten Applikationsarchitekturen besitzen dafür spezialisierte Schnittstellentechnologien (CORBA, DCOM, JNI, JSON..) WSDL erlaubt zwar unterschiedliche Protokolle aber unterstützt eng gekoppelte bzw. binäre Protokolle nur bedingt Makro SOA Infrastruktur kann nur bedingt genutzt werden 68 34

35 Problem: Service Lifecycle vs. Application Life Cycle Planned Planned In Development In Development In Test In Test Deployed Deployed Depreciated End of Life Out of Service 69 Probleme Exponierung interner Schnittstellen verändert deren Lebenszyklus Exponierter Service muss Stabilität bieten Abwärtskompatibilität Deprecation-Mechanismus Exponierter Service unterliegt äußeren Restriktionen Interne Schnittstelle unterliegt kürzeren Änderungszyklen Hat keine Restriktionen, die von außen kommen 70 35

36 Mikro SOA: Private Services exponieren Servicemodell Domain Service 1 Domain Service 2 e.g. Invoice Service WSDL Data Access Service Data Access Service 71 Gefahren Exponierung interner Operationen und ihrer Datenstrukturen Offenlegung der Implementierung Aufwände bei Änderungen Interne Repräsentation ist nicht mehr spezifisch für eine Domäne Kontext-abhängige Ausprägung ist nicht mehr möglich 72 36

37 Applikationsinterne Abhängigkeiten Service A Service B Service C Service D a b c g h i d e f j k l 73 Neuer Service exponiert Service A Service B Service C Service H Service D a b c g h i d e f j k l 74 37

38 Mikro-SOA: Interne Abhängigkeit exponiert Service A Service B Service C Service H Service D a b c g h i d e f j k l 75 Probleme und Gefahren Notwendigkeit der Transformation zwischen Dokumenten der (ehemals) privaten und öffentlichen Serviceschicht Abhängigkeiten von Services Unterschiedliche Lebenszyklen Self-contained? Loose coupling? Support füt Dependancy-Management in Makro-SOA? 76 38

39 Mikro-SOA: Getrenntes Service-Deployment Service A Service B Service C Service D a b c g i d e f j k Service H l h x Komponente 77 Probleme und Gefahren Getrenntes Deployment erhöht die Wartungsaufwände Konfigurationsmanagement Paketierung Verteilung Monitoring Getrenntes Deployment wirft die Frage nach sog. Shared Services auf Paralleler Betrieb von verschiedenen Versionen dieser Services? Ist das Ziel der SOA Wiederverwendung oder Redundanzfreiheit? SOA als Treiber von MDM? SOA als Ersatz für Shared Libraries? 78 39

40 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 79 Integration mittels einer SOA Eigenes Unternehmen Partner 80 40

41 Herausforderung Fest gekoppelt, zerbrechlich und unflexibel Jeder Dienst ist fest mit einem anderen Dienst verbunden Viele Point-to-Point Lösungen Logik zum Routing steckt in einzelnen Anwendungen Asynchrone Kommunikation schwer einzubauen Eventuell keine zuverlässige Verarbeitung Reliability nicht gewährleistet 81 Lösungsansatz: Integration über ESB Eigenes Unternehmen Partner 82 41

42 Mikro-SOA: Abteilungs-ESB ESB Adapter Adapter Protocol Adapter (SOAP, FTP) Adapter Eigenes Unternehmen Partner Partner 83 Mikro-SOA: Multi-ESB Szenario ESB ESB ESB ESB Adapter Adapter Adapter Adapter Adapter Adapter Adapter Eigenes Unternehmen Partner Partner 84 42

43 Probleme und Gefahren Verwendung eines ESB bedeutet zusätzlichen Aufwand Lizenzen Betrieb Know How Features und Kostenersparnis des ESB nur bei angebundenen Services Fehlender Standard für ESBs Föderation von ESBs als eigenes Integrationsprojekt Aufwendige Migration zwischen ESB-Produkten 85 Lösungsansatz: Standardisierung eines ESB JBI 2.0 (JSR 312, 2010 zurückgezogen) IBM: SCA ist die bessere Lösung, doppelter Standard verwirrt Markt BEA: Keine Java-only Lösung JBI Umgebung SE Weitere SEs Installation Normalized Message Router Deployment Control BC Weitere BCs Monitoring External Service Provider External Service Consumer 86 43

44 Lösungsansatz: Standardisierung eines ESB SCA 1.0 released 2007 (SCA 1.1 Draft 03, Juni 2011) Component Service Service Referenz Property 87 Lösungsansatz: SCA Eigenes Unternehmen Partner 88 44

45 Mikro-SOA: Multilayer ESB innerhalb einer Applikation Prozesse ESB Geschäftsobjekte ESB Lebenszyklus ESB System A DB System B System C 89 Probleme Performance Wartung Konfiguration Deployment Monitoring Testbarkeit 90 45

46 SCA: Welche Probleme werden gelöst? Fest gekoppelt, zerbrechlich und unflexibel Jeder Dienst ist fest mit einem anderen Dienst verbunden Viele Point-to-Point Lösungen Logik zum Routing steckt in einzelnen Anwendungen Asynchrone Kommunikation schwer einzubauen Eventuell keine zuverlässige Verarbeitung Reliability nicht gewährleistet 91 Lösungsansatz: WS-BPEL 92 46

47 Makro-SOA Plattform: Oracle SOA Suite 11g Oracle 11g Application Server Oracle Service Bus SCA Runtime JEE Web EJB 3 Rules Engine Service Mediator BPEL Engine Worklist Application ADF EJB Service Messaging JAX WS BPEL Process Notifications JTA JPA JNDI JDBC 93 Mikro-SOA: Entity-Update mit BPEL 94 47

48 Mikro-SOA: Entity-Update mit BPEL Detail 1 95 Mikro-SOA: Entity-Update mit BPEL Detail

49 Mikro-SOA: Entity-Update mit BPEL Detail 3 97 Probleme Benutzung solcher Dienste aus dem UI Asynchronität Eigentlich klassische Applikationsentwicklung Performance? Transaktionsgrenzen? 98 49

50 BPEL als Compound-Service WSDL Web Service WSDL Activity Web Service WSDL Zustand (Variablen) Activity Web Service WSDL Activity Web Service 99 Makro-SOA: Integrationsszenario, Orchestrierung mit BPEL XSLT File Sender JMX File Poller Pipe Router /order/position //price[.< 2] //quantity piece ]

51 Analyse von Integrationsprojekten Analyse Userinterfaces Design Navigation Prozesse Workflow Routing Daten / Services WSDL Kanonisches Modell 101 Mikro-SOA: BPEL in der fein-granularen Anwendungsentwicklung BPEL Prozesslogik Eigenes Unternehmen Partner

52 Probleme und Gefahren Lokale Optimierungen in unteren Schichten werden unmöglich SQL Objekt-relationale Datenbanken Performance Ständige Transformation in und von XML-Repräsentation droht Dokumenten-orientierte Programmierung Analyse folgt oft anderen Paradigmen (strukturiert, OO) Scheitert bei komplexerer Algebra Schwierige Zusammenarbeit mit relationalem Paradigma 103 Vorgehen bei Implementierung eines SOA-Projekts Analyse Userinterfaces Implementierung Daten / Services Design Navigation WSDL XSD Prozesse Prozesse Workflow Routing BPEL Daten / Services WSDL Kanonisches Modell Userinterfaces Java C#

53 Mikro-SOA: Potemkinsche Dörfer ESB Adapter Adapter Adapter Adapter Adapter Eigenes Unternehmen 105 Probleme und Gefahren Entwicklungsgeschwindigkeit Overhead gegenüber klassischer Entwicklung Testbarkeit Mangelnde Analyse von (Implementierungs-)Details Fehlende Anforderungen Akzeptanz durch Geldgeber schwindet während der Implementierung oder der Wartung Widerspruch zwischen Werbeversprechen und Realität wird hier sehr deutlich

54 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 107 Makro-SOA: UI initiiert einen Prozess UI sammelt Daten und initiiert damit einen Prozess Angezeigt wird evtl. eine Ergebnisseite Prozess läuft asynchron UI Prozess

55 Makro-SOA: Menschliche Interaktion mit langlaufenden Prozessen 109 Lösungsansatz: Interaktion über Taskliste Oracle PM BPEL Process JEE Webframe work UI Assign task Task complete Domain Services Domain Worklist Browser API API Human Tasks Worklist Services

56 Lösungsansatz: Interaktion über Taskliste Um lose Kopplung zu erreichen Als Entkopplung von synchroner UI und asynchronem Prozess Abarbeiten von Tasks stellt eine Art Paradigmenwechsel dar Asynchrones Laufzeitverhalten Ungewohnt für Benutzer Kennen meist synchrone UIs mit direkter Rückkopplung Arbeitsabläufe werden automatisiert, Prozesssteuerung wandert in das Backend 111 Konsequenzen Individuelles Prozesswissen wird explizit (Dokumentation) Prozessmonitoring wird möglich und damit Optimierung Prozesse bestimmen den Arbeitsablauf, nicht der Mensch den Prozess Taskliste kann starr und als Korsett wirken

57 Mikro-SOA: Human Task bildet fein-granulare Entscheidung ab Abfrage in UI Ja Nein 113 Gefahr Benutzbarkeit wird von Fachanwendern schnell in Frage gestellt Fein-granulare Entscheidung in Verbindung mit asynchronem Verhalten Aufwand für Anpassungen aufgrund des Stacks oft teurer als bei klassischer Anwendungsentwicklung

58 Mikro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle 115 Mikro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle

59 Mikro-SOA: Hotspot Detail 117 Probleme Lose Kopplung geht verloren Maskenflüsse im Prozess Arbeitsablauf wird fein-granular zerlegt und vorgegeben Mensch-Maschine-Interaktion wird im Geschäftsprozess modelliert Flexibilität und Agilität? Änderungen häufig, Wartung aufwendig Dem Fachanwendern kaum noch vermittelbar Extrem störend für Arbeitsablauf Asynchrones Verhalten sorgt für Wartezeiten Extremform einer Task-basierten Arbeit

60 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Mikro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 119 Probleme einer Mikro-SOA im kanonischen Modell Kanonisches Datenmodell zieht sich durch alle Schichten eines Service bzw. einer Applikation Hohe Aufwände bei Änderungen Interne Repräsentation ist nicht mehr spezifisch für eine Domäne Kontext-abhängige Ausprägung ist nicht mehr möglich Inneres Datenmodell soll iterative/imkrementelle zu kanonischer Form führen Implementierung(sdetail) kann nicht ohne weiteres geändert werden Neue externe Anforderungen an kanonisches Modell wirken direkt auf internes Modell

61 Probleme einer modellgetriebenen Mikro-SOA Semantische und syntaktische Mächtigkeit von XSD wird nicht erreicht Hoher Aufwand der Modellwartung bzw. Erstellung von Mappingmodellen Häufig Versuch einer iterativ-inkrementellen Erstellung des kanonisches Modells Häufig Verwendung von Elementen des kanonischen Modells innerhalb der Anwendungsentwicklung 121 Probleme mit Services einer Mikro-SOA (1) Applikationsinterne Performanzanforderungen werden nicht erreicht. Durch Mangel an Konzepten für Lokale Kommunikation Synchrone Aufrufe Große Datenmengen Verarbeitung von Strömen Nutzung von gemeinsamen Datenkontexten Die Vorteile einer Makro-SOA Infrastruktur können nur unzureichend genutzt werden Lastverteilung Skalierung Ausfallsicherheit

62 Probleme mit Services einer Mikro-SOA (2) Interne Services unterliegen äußeren Restriktionen Interne Services müssen Mechanismen für Abwärtskompatibilität und Deprecation anbieten Service-Konsumenten nutzen Implementierungsdetails Hohe Aufwände bei Änderung der Service-Implementierung Notwendigkeit der Transformation zwischen XML-Dokumenten der privaten und öffentlichen Serviceschicht Steigende Aufwände durch Verwaltung der Abhängigkeiten von Services 123 Probleme mit Shared Services einer Mikro-SOA Erhöhte Wartungsaufwände durch getrenntes Deployment Paralleler Betrieb von verschiedenen Versionen Paralleler Betrieb von verschiedenen Services Zielkonflikte bei der Entwicklung zwischen Wiederverwendung und Redundanzfreiheit

63 Probleme mit (Sparten-)ESB einer Mikro-SOA Zusätzliche Aufwände für Lizenzen, Betrieb und Know How ESB-Föderationsprojekte ESB-Integrationsprojekte Performance Wartung Konfiguration Deployment Monitoring Hohe QM-Aufwände (Testbarkeit) 125 Probleme mit Compound-Services einer Mikro- SOA Performance-Probleme Lokale Performance-Optimierungen in unteren Schichten sind nicht mehr möglich Hohe Transformationsaufwände von und in XML Hohe Implementierungsaufwände Notwendigkeit der Übersetzung zwischen verschiedenen Paradigmen (Strukturiert, Relational, OO) Bei komplexer algebraischen Problemen Fehlerbehandlung Transaktionshandling Höhere Implementierungsaufwände bei Benutzung der Dienste bedingt durch Asynchronität

64 Green Field Probleme einer Mikro-SOA Geringere Entwicklungsgeschwindigkeit als bei bisheriger Anwendungsentwicklung Hohe Aufwände für Change Requests während der Implementierung Sinkende Akzeptanz der Stakeholder während Implementierung und Betrieb Widerspruch zwischen Werbeversprechen und Realität tritt sehr deutlich zu Tage 127 Probleme der UI in einer Mikro-SOA Maskenflüsse im Prozess Mensch-Maschine-Interaktion wird im Geschäftsprozess modelliert Hohe Änderungshäufigkeit Aufwendige Wartung Mangelhafte Usability ist dem Fachanwendern kaum noch vermittelbar Anwendung stört den Arbeitsablauf

65 Fazit SOA ist für uns sinnvoll im Kontext von Systemintegration mit SOA-Techniken Kanonisches Datenmodell zwischen System Externe Schnittstellen Virtualisierung Automatisierung von Geschäftsprozessen In Grenzen für Task-basiertes Arbeiten Driftet sehr leicht in Mikro-SOA SOA ist schwierig bis unmöglich bei Modelliertem Workflow / Maskenfluss Nutzung von SOA-Techniken bis tief in Anwendungen hinein 129 Makro-SOA Anwendung A Anwendung B Anwendung C Anwendung D Enterprise Service Bus Normalized Message Router N

66 Mikro-SOA Service Entität A Service Entität B Enterprise Service Bus Normalized Message Router Service Entität C Anwendung 131 SOA ist für uns vor allem... SOA = EAI + XML + WS

67 7 Rules for Successfully Implementing an SOA Start small and simple. The KISS principle is especially true for Web Services. With regard to the future ubiquity of Web Services, I changed KISS into SSS: Start Small and Simple. Start with low or zero risk projects. A good thing to start with is a "read-only" Web Service which provides information from a backend system. Read-only services don't require sophisticated security and transactions. Later, add a simple service that changes the state of a backend system. At the beginning, keep the number of partners that are using and/or providing services small. Add functions incrementally. Don't start with the wall. Instead, start with some bricks and add more as they are needed. To build the whole wall, a lot of knowledge and endurance is necessary. Building and testing in smaller increments can help to build the necessary knowledge. Learn by doing. A Service Oriented Architecture requires a lot of knowledge and experience. If you get the opportunity, do a pilot project. But even in a pilot project, you should address business needs. Create value. Try to create value from the beginning. The first simple Web Service should bring some benefits like an improved process, more service for customers or cost reductions. Opportunities for beneficial Web Services can easily be found in companies that have yet to use Web Services. Look at the borders between systems and see where tedious tasks are rendered manually. Leverage existing systems. Investments in existing systems can be leveraged by adding a Web Services interface or, by using Web Services to interconnect the systems. Small investments can have a great impact and create essential business value. Publish the services. The more a service is used, the more value it generates. There might be potential "consumers" of your service in different departments inside the company, and outside the company among suppliers and clients. Make it easy to use the service by providing simple interfaces, a good documentation and sample clients in different programming languages. A tutorial or FAQ is also helpful. Don't wait. Don't wait for specifications and a complete Web Services infrastructure. The first Web Services should be simple (see first point), so there isn't much security or transactional infrastructure involved. An SOA can be developed incrementally. You get more benefit from the experience and shortterm effects by an early start than by waiting until a perfect and complete infrastructure is available. 133 Enterprise Service Bus (ESB) Anwendung A Anwendung B Anwendung C Anwendung D N N Enterprise Service Bus Normalized Message Router N Management N BC SOAP BC SAP BC Dateisystem BC Dateisystem

68 Der ESB ist keine Lösung für den Weltfrieden er kann aber Integration Internes Netz ESB/BPEC/OS Externer Partner CRM Finance Stock Procument Siehe auch: Jim Webber Martin Fowler - Does My Bus Look Big In This Mehr von OIO zum Thema... Schulung: SOA - Service orientierte Architekturen Schulung: SOA Governance Beratung: SOA / WebServices

69 ?? Fragen??? Orientation Objects GmbH Weinheimer Str Mannheim Vielen Dank für ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim 69