Micro-SOA vs. Macro-SOA

Transkript

1 Micro-SOA vs. Macro-SOA Von der Ökonomie zweier Architekturstile Version: 1.0 Orientation in Objects GmbH Weinheimer Str Mannheim Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Micro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 2 1

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

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

4 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, 7 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 8 4

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

6 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

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

8 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 15 Lösungsansatz 1: Datenintegration System A System B Daten B Daten Kopie Daten B Daten Daten B Replikation Master / Slave Datenabgleich Userdaten Redundanz Konflikte 16 8

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

10 Probleme von Einzelintegrationen im Unternehmen Eigenes Unternehmen Partner 19 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? 20 10

11 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 21 Best Practices Lösungsansätze: EAI Patterns Dateiübertragung Gemeinsame Datenbank Entfernte Methodenaufrufe Remote Procedure Calls Nachrichtendienste

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

13 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) 25 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) 26 13

14 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 27 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,

15 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) 29 Ü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 30 15

16 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 31 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 32 16

17 Integration Unternehmensübergreifend Eigenes Unternehmen Partner 33 Gliederung Einleitung Definitionsversuch Ursprung und Ziel These Panoptikum der Micro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interface Synthese 34 17

18 These Macro-SOA = EAI + XML + WS 35 Weitergehende Überlegungen zur Macro-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 36 18

19 Weitergehende Überlegungen zur Macro-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? 37 Lösungsansatz Middleware-Plattform Systemunabhängigkeit Administrationsunterstützung Discovery Zuverlässigkeit Ressourcenverbrauch Stabilität Middleware Skalierbarkeit Fehlertoleranz Sicherheit Konsistenz Integration proprietärer Komponenten Erweiterbarkeit 38 19

20 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 39 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 40 20

21 Die WS*-Spezifikationen 41 These Micro-SOA = Macro-SOA + Improvements? 42 21

22 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Micro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 43 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 44 22

23 Serviceorientierter Datenaustausch zwischen Systemen Austausch System A Transformation BML Punkt-zu-Punkt AML Transformation System B Internes Datenmodell Internes Datenmodell 45 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 46 23

24 Lösungsansatz Kanonisches Modell Austausch kanonisch System A Transformation KML KML Transformation System B Internes Datenmodell Internes Datenmodell 47 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 48 24

25 Micro-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 49 Micro-SOA Support in Java Plattform? Java Klasse 1 1 XML Schema 1 * Java Objekte Objekte Objekte JAXB * * XML Dokumente Dokumente Dokumente 50 25

26 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 51 Macro-SOA: Contract-First, Adaption der Implementierung Web Service Adapter Applikation XML Business Objekte Kanonisches Modell 52 26

27 Micro-SOA: Implementation-to-Contract Web Service Applikation Business Objekte XML Kanonisches Modell 53 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 54 27

28 Macro-SOA: Kanonisches Datenmodell in XML Schema 55 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 56 28

29 Micro-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 57 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 58 29

30 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Micro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 59 Macro-SOA Vorgehen: Geschäftslogik als Business Services exponieren Service A Service B Service C Service D Funktionalität 60 30

31 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 61 Macro-SOA: Business Services technisch mit WSDL spezifizieren WSDL A WSDL B WSDL C WSDL D Funktionalität 62 31

32 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 63 Perspektivwechsel: Anwendung als Summe von Business Services Anwendung X Service A Service B Service C Service D 64 32

33 Micro-SOA: Anwendung als Summe von Web Services (WSDL basiert) Anwendung X WSDL A WSDL B WSDL C WSDL D 65 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 Macro-SOA Infrastruktur kann nur bedingt genutzt werden 66 33

34 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 67 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 68 34

35 Micro-SOA: Private Services exponieren Servicemodell Domain Service 1 Domain Service 2 e.g. Invoice Service WSDL Data Access Service Data Access Service 69 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 70 35

36 Applikationsinterne Abhängigkeiten Service A Service B Service C Service D a b c g h i d e f j k l 71 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 72 36

37 Micro-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 73 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 Macro-SOA? 74 37

38 Micro-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 75 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? 76 38

39 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Micro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 77 Integration mittels einer SOA Eigenes Unternehmen Partner 78 39

40 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 79 Lösungsansatz: Integration über ESB Eigenes Unternehmen Partner 80 40

41 Micro-SOA: Abteilungs-ESB ESB Adapter Adapter Protocol Adapter (SOAP, FTP) Adapter Eigenes Unternehmen Partner Partner 81 Micro-SOA: Multi-ESB Szenario ESB ESB ESB ESB Adapter Adapter Adapter Adapter Adapter Adapter Adapter Eigenes Unternehmen Partner Partner 82 41

42 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 83 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 84 42

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

44 Micro-SOA: Multilayer ESB innerhalb einer Applikation Prozesse ESB Geschäftsobjekte ESB Lebenszyklus ESB System A DB System B System C 87 Probleme Performance Wartung Konfiguration Deployment Monitoring Testbarkeit 88 44

45 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 89 Lösungsansatz: WS-BPEL 90 45

46 Macro-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 91 Micro-SOA: Entity-Update mit BPEL 92 46

47 Micro-SOA: Entity-Update mit BPEL Detail 1 93 Micro-SOA: Entity-Update mit BPEL Detail

48 Micro-SOA: Entity-Update mit BPEL Detail 3 95 Probleme Benutzung solcher Dienste aus dem UI Asynchronität Eigentlich klassische Applikationsentwicklung Performance? Transaktionsgrenzen? 96 48

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

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

51 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 101 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#

52 Micro-SOA: Potemkinsche Dörfer ESB Adapter Adapter Adapter Adapter Adapter Eigenes Unternehmen 103 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

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

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

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

56 Micro-SOA: Human Task bildet fein-granulare Entscheidung ab Abfrage in UI Ja Nein 111 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

57 Micro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle 113 Micro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle

58 Micro-SOA: Hotspot Detail 115 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

59 Gliederung Einleitung Definitionsversuch Ursprung und Ziele These Panoptikum der Micro-SOA Kanonisches Datenmodell Domänenservices Integration, Prozesse und Applikationen User Interfaces Synthese 117 Probleme einer Micro-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

60 Probleme einer modellgetriebenen Micro-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 119 Probleme mit Services einer Micro-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 Macro-SOA Infrastruktur können nur unzureichend genutzt werden Lastverteilung Skalierung Ausfallsicherheit

61 Probleme mit Services einer Micro-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 121 Probleme mit Shared Services einer Micro-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

62 Probleme mit (Sparten-)ESB einer Micro-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) 123 Probleme mit Compound-Services einer Micro- 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

63 Green Field Probleme einer Micro-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 125 Probleme der UI in einer Micro-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

64 Mehr von OIO zum Thema... Schulung: SOA Service orientierte Architekturen Artikel: Modellgetriebene Software-Entwicklung mit BPMN und SOA Software-Entwicklung.pdf Beratung zu SOA & WebServices 127?? Fragen??? Orientation Objects GmbH Weinheimer Str Mannheim 64

65 Vielen Dank für ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim 65