Post on 27-Jun-2020
1
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.deVersion:
Micro-SOA vs.Macro-SOA
Von der Ökonomie zweier Architekturstile
1.0
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
2
2
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
3
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Motivation
4
Quelle: http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
3
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Architektur
5
„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“
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Definitionsversuch einer SOA (1)
• „SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität , die von unterschiedlichen Besitzernverantwortet wird.“
6
OASIS Reference Model for Service Oriented Architecture 1.0,Committee Specification 1, 2 August 2006
4
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Definitionsversuch einer SOA (2)
• “Service Oriented Architecture is an architectural style for building systems based on interacting loosely coupled , coarse grainedautonomous 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.”
7
SOA Patterns, Arnon Rotem-Gal-Oz, Manning eBook, http://www.manning.com/rotem/
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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 1996. 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 ....
8
Service-Oriented Architecture, Gartner IT-Glossary
5
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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 “.
9
Service-Oriented Architecture Scenario, Gartner Research Note AV-19-6751
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
6
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
SOA = Prinzipien
• Leverages open standards
• Software as services
• Services are loosely coupled
• Focus on business function not technology
• Platform independence
• ...
11
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
12
http://soa-manifest.de/
7
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
13
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
2003 Flughafenwerbung (Heatrow )
14
8
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz 1: Datenintegration
16
System A
DatenB
Daten
System B
Daten
• Replikation• Master / Slave• Datenabgleich
• Userdaten• Redundanz• Konflikte
KopieDaten
B
DatenB
9
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz 2: Funktionale Integration
17
System A
Daten
System B
Daten
Just in Time!
DatenB
Anfrage nach Daten
Antwort
Bitte um Änderung
Antwort
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz 2: Transaktionale Integration?
18
System A
Daten
System B
Daten
DatenB
Anfrage nach Daten
Antwort
Bitte um Änderung
Antwort
TransaktionsKoordinator
10
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Probleme von Einzelintegrationen im Unternehmen
19
Eigenes Unternehmen Partner
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
11
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Best Practices Lösungsansätze: EAI Patterns
• Dateiübertragung
• Gemeinsame Datenbank
• Entfernte Methodenaufrufe – Remote Procedure Calls
• Nachrichtendienste
22
http://www.enterpriseintegrationpatterns.com/toc.html
12
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
SOA 1998?
23
Kunde
CRM
Vertrag
CORBA Proxy
Konto Produkt
Finance Produktion
RMI Proxy X Proxy
CORBA RMI Protocol X
Custom Application
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
XML als Wegbegleiter von SOA
24
XML Nachrichten
Dave Winer
XML-RPCDon Box
SOAPFinal
REST
HTTP, URL, URI
SOAP 1.2
Einfluß
1.01.1
13
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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 Web-based . 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
14
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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, ...
28
15
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Web Service Interoperability
29
Common Internet Protocols (HTTP, TCP/IP)
Extensible Markup Language (XML)
Simple Object Access Protocol (SOAP)
Universal Description, Discovery and Integration (U DDI)
Universal Service Interop Protocols(these layers are not defined yet)
InteropStack
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Ü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
16
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Vision 2003: Service Oriented Business Application (SOBA)
31
KundeService
CRM
Vertrag Service
WS Proxy
Konto Service
ProduktService
Finance Produktion
WS Proxy WS Proxy
SOAP
SOBA
Security
SecurityService
SOAP SOAP SOAP
WS Proxy
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
SOA als EAI 2.0?
32
Firew
all
RMI
RMI
WebServer
JAX-RPCServlet Endpoint
Application Server
EIS
EJB
Connector
Firew
all
XML
WebServer
JAX-RPCServlet Endpoint
Application Server
EIS
EJB
Connector
Firew
all
XML
Application Server
EIS
EJB
Connector
Application Server
EIS
EJB
Connector
WebServer
JAX-RPCServlet Endpoint
RMI
WebServer
JAX-RPCServlet Endpoint
Firew
all
XML
Firew
all
XML
XML
17
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Integration Unternehmensübergreifend
33
Eigenes Unternehmen Partner
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziel– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interface
• Synthese
34
18
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
These
35
Macro-SOA
= EAI + XML + WS
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
19
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz Middleware-Plattform
38
MiddlewareStabilität
Zuverlässigkeit
Skalierbarkeit
Fehlertoleranz
Konsistenz
Discovery
Sicherheit
ErweiterbarkeitIntegration proprietärerKomponenten
Ressourcenverbrauch
AdministrationsunterstützungSystemunabhängigkeit
20
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz Standard-Stack
39
WS-TransactionWS-Coordination
WSDL
SOAPAndere Protokolle
XML, Encoding
Transport und Encoding
Quality of Service
Beschreibung
Geschäfts-prozesse
UDDI
WS-Reliable MessagingWS-Security
Choreography WS-CDL
Orchestration WS-BPEL
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
WS*-Spezifikationen
40
WS-Transaction
WS-SecureConversation
WS-Addressing
WS-SecurityWS-Trust
definiert Erweiterungen
definiert Erweiterungen
WS-Policy
WS-Coordination
verwendet
WS-Atomic Transaction WS-BusinessActivity
verwendetverwendet
empfiehlt
verwendet
WS-BPEL
verwendet
21
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Die WS*-Spezifikationen
41
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
These
42
Micro-SOA
= Macro-SOA+ Improvements?
22
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
43
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Ursprung: EAI 2.0 Interorganisationaler Datentransfer mit XML
44
XMLXML
DBMS DBMS
DTD DTD
validieren
validieren
XSLTransformator
XML
validieren
DTD-AustauschXML-Struktur XML-Struktur
23
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Serviceorientierter Datenaustausch zwischen Systemen
45
System ABML
InternesDaten-modell
System BAML
InternesDaten-modell
Austausch
Transformation Transformation
Punkt-zu-Punkt
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
24
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz Kanonisches Modell
47
System AKML
InternesDaten-modell
System BKML
InternesDaten-modell
Austausch kanonisch
Transformation Transformation
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
25
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Wiederverwendung des kanonischen Modells in der Anwendungsentwicklung
49
XSD / Kanonisches Modell
DomainService 2
DomainService 1
ProcessService
Data AccessData AccessService 1
Data AccessData AccessService 2
e.g. findCustomerByUID(..) e.g. findInvoicesByCustomerUID(..)
e.g. findInvoicesByCustomer(..)
DO
JPA-Klasse
Konverter
DO
DO
JAXB-Klasse
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA Support in Java Plattform?
50
JavaKlasse
XMLSchema
JAXB
1 1
*
*
Objekte Dokumente Dokumente
*
Objekte
1
1 1
1
JavaObjekte
XMLDokumente
26
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA: Contract-First, Adaption der Implementierung
52
Applikation
BusinessObjekte
Web Service Adapter
XML
Kanonisches Modell
27
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Implementation-to-Contract
53
Applikation
BusinessObjekte
Web Service
XML
„Kanonisches Modell“
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
28
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA: Kanonisches Datenmodell in XML Schema
55
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
56
XSD
Entity type
D attribute (ERM)
D attribute (ERM)
D attribute (ERM)
D attribute (ERM)
ERM domain
ERM domain
ERM domain
ERM domain
29
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Modellgetriebene SOA
57
Kanonisches Modell
DomainService 2
DomainService 1
ProcessService
Data AccessData AccessService 1
Data AccessData AccessService 2
e.g. findCustomerByUID(..) e.g. findInvoicesByCustomerUID(..)
e.g. findInvoicesByCustomer(..)
DO
XSD
JPA-Klasse
Konverter
DO
DO
JAXB-Klasse
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
30
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
59
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA Vorgehen: Geschäftslogik als Business Services exponieren
60
Service A Service B Service C Service D
Funktionalität
31
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz: Schnittstellendefinition durch WSDL
61
Servicemodell
DomainService 2
DomainService 1
ProcessService
Data AccessData AccessObject
Data AccessData AccessObject
e.g. Invoice service
e.g. Order process
WSDL
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA: Business Services technisch mit WSDL spezifizieren
62
WSDL A WSDL B WSDL C WSDL D
Funktionalität
32
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
WSDL Elemente
• Elemente in WSDL Dokumenten:– Types
Ein Container für Datentypdefinitionen wie XSD
– MessagesÜbertragene Daten
– Port TypeEin Satz von Operationen die von einem oder mehreren Endpunkten unterstützt werden
– BindingKonkretes Protokoll und Datenformat Spezifikation für einen Port Type
– ServiceSammlung von verwandten Endpunkten
– PortEndpunkt bestehend aus Binding und Netzwerkadresse
– OperationOperation die vom Service unterstützt wird
63
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Perspektivwechsel: Anwendung als Summe von Business Services
64
Service A Service B
Service C Service D
Anwendung X
33
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Anwendung als Summe von Web Services (WSDL basiert)
65
WSDL A WSDL B
WSDL C WSDL D
Anwendung X
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
34
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Problem: Service Lifecycle vs. Application Life Cycle
67
Planned
In Development
In Test
Deployed
Depreciated
Out of Service
Planned
In Development
In Test
Deployed
End of Life
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
35
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Private Services exponieren
69
Servicemodell
DomainService 2
DomainService 1
Data AccessData AccessService
Data AccessData AccessService
e.g. Invoice Service
WSDL
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
36
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Applikationsinterne Abhängigkeiten
71
Service A Service B Service C Service D
a b c g h i
d e j k
l
f
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Neuer Service exponiert
72
Service A Service B Service C Service H
a b c g h i
d e j k
l
f
Service D
37
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Interne Abhängigkeit exponiert
73
Service A Service B Service C Service H
a b c g h i
d e j k
l
f
Service D
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
38
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Service D
h
Micro-SOA: Getrenntes Service-Deployment
75
Service A Service B Service C
Service H
a b c gi
d e j k
l
f
x Komponente
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
39
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
77
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Integration mittels einer SOA
78
Eigenes Unternehmen Partner
40
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz: Integration über ESB
80
Eigenes Unternehmen Partner
41
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: „Abteilungs-ESB“
81
Eigenes Unternehmen Partner
Adapter Adapter
Adapter
ProtocolAdapter(SOAP,FTP)
Partner
ESB
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: „Multi-ESB Szenario“
82
Eigenes Unternehmen Partner
Adapter Adapter Adapter Adapter Adapter Adapter Adapter
Partner
ESB ESB ESB ESB
42
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
84
JBI Umgebung
Normalized Message Router
SE Weitere SEs
BCWeitere
BCs
Installation
Deployment
Control
Monitoring
External Service Provider
External Service Consumer
43
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz: Standardisierung eines ESB
• SCA 1.0 released 2007 (SCA 1.1 Draft 03, Juni 2011)
85
Service
Service Referenz
Property
Component
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz: SCA
86
Eigenes Unternehmen Partner
44
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Multilayer ESB innerhalb einer Applikation
87
System A
Prozesse
ESB
Geschäftsobjekte
ESB
Lebenszyklus
Sys
tem
B
Sys
tem
C
ESB
DB
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Probleme
• Performance
• Wartung– Konfiguration– Deployment– Monitoring
• Testbarkeit
88
45
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz: WS-BPEL
90
46
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA Plattform: Oracle SOA Suite 11g
91
Oracle 11g Application Server
SCA Runtime
ServiceMediator
BPELEngine
BPELProcess
Notifications
WorklistApplication
Oracle Service Bus
JEE Web EJB 3
ADF EJBService
Rules Engine
Messaging JAX WS
JTA JPA
JDBCJNDI
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Entity-Update mit BPEL
92
47
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Entity-Update mit BPEL – Detail 1
93
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Entity-Update mit BPEL – Detail 2
94
48
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Entity-Update mit BPEL – Detail 3
95
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Probleme
• Benutzung solcher Dienste aus dem UI– Asynchronität
• Eigentlich klassische Applikationsentwicklung
• Performance?
• Transaktionsgrenzen?
96
49
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
BPEL als Compound-Service
97
Activity
WSDL
Web Service
Activity
WSDL
Web Service
Activity
WSDL
Web Service
WSDL
Zustand(Variablen)
Web Service
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA: Integrationsszenario, Orchestrierung mit BPEL
98
PipeFile
Poller
JMXFile
SenderXSLT
/order/position //price[.< 2] //quantity[@unit=‚piece‘]
Router
50
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Analyse
Analyse von Integrationsprojekten
Daten / Services
WSDL Kanonisches Modell
Prozesse
Workflow Routing
Userinterfaces
Design Navigation
99
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: BPEL in der fein-granularen Anwendungsentwicklung
100
Eigenes Unternehmen Partner
BPEL Prozesslogik
51
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
ImplementierungAnalyse
Vorgehen bei Implementierung eines SOA-Projekts
Daten / Services
WSDL Kanonisches Modell
Prozesse
Workflow Routing
Userinterfaces
Design Navigation
Userinterfaces
Java C#
Prozesse
BPEL
Daten / Services
WSDL XSD
102
52
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: „Potemkinsche Dörfer“
103
Eigenes Unternehmen
Adapter Adapter Adapter Adapter Adapter
ESB
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
104
53
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
105
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA: UI initiiert einen Prozess
• UI sammelt Daten und initiiert damit einen Prozess
• Angezeigt wird evtl. eine Ergebnisseite
• Prozess läuft asynchron
106
UI
Prozess
54
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Macro-SOA: Menschliche Interaktion mit langlaufenden Prozessen
107
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Lösungsansatz: Interaktion über Taskliste
108
JEE
Worklist Services
PM
Task complete
BPEL Process
Assign task
HumanTasks
UI
ServicesDomainServices
Webframework
APIAPI
Browser
APIAPI
DomainWorklist
55
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
110
56
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Human Task bildet fein-granulare Entscheidung ab
111
Abfrage in UI
Ja
Nein
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
112
57
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle
113
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle
114
58
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Micro-SOA: Hotspot Detail
115
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
116
59
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Gliederung
• Einleitung– Definitionsversuch– Ursprung und Ziele– These
• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces
• Synthese
117
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
118
60
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
120
61
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
122
62
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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
124
63
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
„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
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
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“
126
64
Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH
Mehr von OIO zum Thema...
• Schulung: SOA – Service orientierte Architekturen– http://www.oio.de/seminar/entscheider/soa-schulung.htm
• Artikel: Modellgetriebene Software-Entwicklung mit BPMN und SOA– http://www.oio.de/m/konf/doag2010/SOA-BPM-Modellgetriebene-
Software-Entwicklung.pdf
• Beratung zu SOA & WebServices– http://www.oio.de/beratung-consulting/software-integration/soa-web-
services/
127
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.de
??
? ?
????
Fragen ?
65
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
www.oio.deinfo@oio.de
Vielen Dank für ihre Aufmerksamkeit !