Mikro-SOA vs. Makro-SOA

Transcription

Mikro-SOA vs.
Makro-SOA
Orientation in Objects GmbH
Weinheimer Str. 68
68309 Mannheim
Version: 1.0
www.oio.de
[email protected]
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.
© 2011 Orientation in Objects GmbH
2
1
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
– These
•
–
–
–
–
•
Domänenservices
User Interfaces
Synthese
4
2
Motivation
Quelle: http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
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
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 2006
7
•
“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, http://www.manning.com/rotem/
8
4
•
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.
...
Service-Oriented Architecture, Gartner IT-Glossary
9
•
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-19-6751
10
5
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
SOA = Prinzipien
•
Leverages open standards
•
Software as services
•
Services are loosely coupled
•
Focus on business function not technology
•
Platform independence
•
...
13
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
http://soa-manifest.de/
14
7
Gliederung
•
Einleitung
– These
•
–
–
–
–
•
Domänenservices
User Interfaces
Synthese
15
2003 Flughafenwerbung (Heatrow )
16
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
17
Lösungsansatz 1: Datenintegration
System B
System A
Daten
B
Daten
Daten
Kopie
Daten
B
Daten
B
• Replikation
• Master / Slave
• Datenabgleich
• Userdaten
• Redundanz
• Konflikte
18
9
Lösungsansatz 2: Funktionale Integration
System B
System A
Anfrage nach Daten
Antwort
Daten
Daten
Bitte um Änderung
Antwort
Daten
B
Just in Time!
19
Lösungsansatz 2: Transaktionale Integration?
System B
System A
Anfrage nach Daten
Antwort
Daten
Bitte um Änderung
Antwort
Daten
Daten
B
Transaktions
Koordinator
20
10
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
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
http://www.enterpriseintegrationpatterns.com/toc.html
24
12
SOA 1998?
Custom Application
CORBA Proxy
RMI Proxy
CORBA
CRM
X Proxy
RMI
Protocol X
Finance
Produktion
Kunde
Konto
Vertrag
Produkt
25
XML als Wegbegleiter von SOA
Dave Winer
HTTP, URL, URI
XML Nachrichten
Don Box
REST
XML-RPC
SOAP
Final
1.0
1.1
Einfluß
SOAP 1.2
26
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)
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
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, ...
30
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)
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
Vision 2003: Service Oriented Business
Application (SOBA)
SOBA
WS Proxy
SOAP
WS Proxy
SOAP
CRM
WS Proxy
SOAP
Finance
Kunde
Service
WS Proxy
SOAP
Produktion
Konto
Service
Security
Produkt
Service
Security
Service
Vertrag
Service
33
SOA als EAI 2.0?
Application
Server
WebServer
RMI
JAX-RPC
Servlet
Endpoint
XML
JAX-RPC
Servlet
Endpoint
Application
Server
RMI
EJB
Firewall
Firewall
EJB
WebServer
XML
Connector
Connector
EIS
EIS
Application
Server
WebServer
XML
WebServer
XML
XML
Firewall
Firewall
Firewall
EJB
Connector
JAX-RPC
Servlet
Endpoint
Application
Server
RMI
EJB
Connector
EIS
JAX-RPC
Servlet
Endpoint
EIS
34
17
Integration Unternehmensübergreifend
Eigenes Unternehmen
Partner
35
Gliederung
•
Einleitung
– Ursprung und Ziel
– These
•
–
–
–
–
•
Domänenservices
User Interface
Synthese
36
18
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
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
Zuverlässigkeit
Stabilität
Ressourcenverbrauch
Middleware
Fehlertoleranz
Konsistenz
Discovery
Skalierbarkeit
Sicherheit
Integration proprietärer
Komponenten
Erweiterbarkeit
40
20
Lösungsansatz Standard-Stack
Choreography WS-CDL
Geschäftsprozesse
Orchestration WS-BPEL
WSDL
UDDI
Beschreibung
WS-Coordination
WS-Transaction
WS-Security
WS-Reliable
Messaging
Quality
of Service
SOAP
Transport
und Encoding
Andere Protokolle
XML, Encoding
41
WS*-Spezifikationen
WS-BPEL
verwendet
WS-Transaction
WS-Atomic Transaction
WS-BusinessActivity
verwendet
verwendet
empfiehlt
WS-Coordination
verwendet
verwendet
WS-SecureConversation
definiert Erweiterungen
WS-Trust
definiert
Erweiterungen
WS-Addressing
WS-Security
WS-Policy
42
21
Die WS*-Spezifikationen
43
These
Mikro-SOA
= Makro-SOA
+ Improvements?
44
22
Gliederung
•
Einleitung
– These
•
–
–
–
–
•
Domänenservices
User Interfaces
Synthese
45
Ursprung: EAI 2.0 Interorganisationaler
Datentransfer mit XML
DTD-Austausch
XML-Struktur
DTD
validieren
validieren
validieren
DBMS
XML-Struktur
DTD
XML
XML
Transformator
XML
DBMS
XSL
46
23
Serviceorientierter Datenaustausch zwischen
Systemen
Austausch
BML
System A
Punkt-zu-Punkt
AML
Transformation
System B
Transformation
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
Lösungsansatz Kanonisches Modell
Austausch kanonisch
KML
System A
KML
Transformation
System B
Transformation
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
Mikro-SOA: Wiederverwendung des kanonischen
Modells in der Anwendungsentwicklung
XSD / Kanonisches Modell
DO
Process
Service
Domain
Service 1
Domain
Service 2
e.g. findInvoicesByCustomer(..)
Data Access
Service 1
Data Access
Service 2
e.g. findCustomerByUID(..)
Konverter
DO
JAXB-Klasse
DO
JPA-Klasse
e.g. findInvoicesByCustomerUID(..)
51
Mikro-SOA Support in Java Plattform?
Java
Klasse
1
1
XML
Schema
1
1
JAXB
*
*
*
Objekte
Objekte
1
1
XML
Dokumente
Dokumente
Dokumente
Java
Objekte
52
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
53
Makro-SOA: Contract-First, Adaption der
Implementierung
Web Service Adapter
Applikation
XML
Business
Objekte
Kanonisches Modell
54
27
Mikro-SOA: Implementation-to-Contract
Web Service
Applikation
XML
Business
Objekte
„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
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)
ERM domain
XSD
D attribute (ERM)
D attribute (ERM)
ERM domain
ERM domain
58
29
Mikro-SOA: Modellgetriebene SOA
Kanonisches Modell
DO
XSD
Process
Service
Domain
Service 1
Domain
Service 2
e.g. findInvoicesByCustomer(..)
Data Access
Service 1
Data Access
Service 2
e.g. findCustomerByUID(..)
Konverter
DO
JAXB-Klasse
DO
JPA-Klasse
e.g. findInvoicesByCustomerUID(..)
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
Gliederung
•
Einleitung
– These
•
–
–
–
–
•
Domänenservices
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
Lösungsansatz: Schnittstellendefinition durch
WSDL
Servicemodell
Process
Service
WSDL
e.g. Order process
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
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
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
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
Mikro SOA: Private Services exponieren
Servicemodell
Domain
Service 1
Domain
Service 2
WSDL
e.g. Invoice Service
Data Access
Service
Data Access
Service
71
Gefahren
•
Exponierung interner Operationen und ihrer Datenstrukturen
–
–
–
–
Offenlegung der Implementierung
Aufwände bei Änderungen
Kontext-abhängige Ausprägung ist nicht mehr möglich
72
36
Applikationsinterne Abhängigkeiten
Service A
a
Service B
b
Service C
c
d
g
e
f
Service D
h
i
j
k
l
73
Neuer Service exponiert
Service A
a
Service B
b
Service C
c
d
g
e
f
Service H
h
j
Service D
i
k
l
74
37
Mikro-SOA: Interne Abhängigkeit exponiert
Service A
a
Service B
b
Service C
c
d
g
e
f
Service H
h
j
Service D
i
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
Mikro-SOA: Getrenntes Service-Deployment
Service A
a
Service B
b
Service C
c
Service D
g
i
d
e
f
j
k
Service H
l
x
h
Komponente
77
•
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
Gliederung
•
Einleitung
– These
•
–
–
–
–
•
Domänenservices
User Interfaces
Synthese
79
Integration mittels einer SOA
Eigenes Unternehmen
Partner
80
40
Herausforderung
•
•
•
•
81
Lösungsansatz: Integration über ESB
Eigenes Unternehmen
Partner
82
41
Mikro-SOA: „Abteilungs-ESB“
ESB
Adapter
Adapter
Protocol
Adapter
(SOAP,
FTP)
Adapter
Eigenes Unternehmen
Partner
Partner
83
Mikro-SOA: „Multi-ESB Szenario“
ESB
Adapter
Adapter
ESB
Adapter
Eigenes Unternehmen
Adapter
ESB
Adapter
Adapter
Partner
ESB
Adapter
Partner
84
42
•
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
Deployment
Normalized Message Router
Control
BC
External
Service Provider
Monitoring
Weitere
BCs
External Service
Consumer
86
43
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
Mikro-SOA: Multilayer ESB innerhalb einer
Applikation
System A
Prozesse
ESB
Geschäftsobjekte
ESB
Lebenszyklus
System C
DB
System B
ESB
89
90
Probleme
•
Performance
•
Wartung
– Konfiguration
– Deployment
– Monitoring
•
Testbarkeit
45
SCA: Welche Probleme werden gelöst?
•
•
•
•
91
92
Lösungsansatz: WS-BPEL
46
Makro-SOA Plattform: Oracle SOA Suite 11g
Oracle 11g Application Server
Oracle Service Bus
SCA Runtime
JEE Web
Rules Engine
Service
Mediator
Worklist
Application
ADF
EJB
Service
BPEL
Engine
BPEL
Process
EJB 3
Notifications
Messaging
JAX WS
JTA
JPA
JNDI
JDBC
93
Mikro-SOA: Entity-Update mit BPEL
94
47
Mikro-SOA: Entity-Update mit BPEL – Detail 1
95
96
48
97
Probleme
•
Benutzung solcher Dienste aus dem UI
– Asynchronität
•
Eigentlich klassische Applikationsentwicklung
•
Performance?
•
Transaktionsgrenzen?
98
49
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
File
Sender
XSLT
File
Poller
Pipe
Router
/order/position
JMX
//price[.< 2]
//quantity
[@unit=‚piece‘]
100
50
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
102
51
•
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
Implementierung
Userinterfaces
Daten / Services
Design
Navigation
WSDL
Prozesse
Workflow
WSDL
Prozesse
Routing
Daten / Services
Kanonisches
Modell
XSD
BPEL
Userinterfaces
Java
C#
104
52
Mikro-SOA: „Potemkinsche Dörfer“
ESB
Adapter
Adapter
Adapter
Adapter
Adapter
Eigenes Unternehmen
105
•
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
106
53
Gliederung
•
Einleitung
– These
•
–
–
–
–
•
Domänenservices
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
Prozess
UI
108
54
Makro-SOA: Menschliche Interaktion mit
langlaufenden Prozessen
109
Lösungsansatz: Interaktion über Taskliste
Oracle PM
JEE
BPEL
Process
Task
complete
Assign task
Webframe
work
UI
Domain
Services
Browser
Domain
Worklist
API
API
Human
Tasks
Worklist Services
110
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“
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
112
56
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
114
57
Mikro-SOA: Mehrere Human Tasks hintereinander
innerhalb einer Rolle
115
Mikro-SOA: Mehrere Human Tasks hintereinander
innerhalb einer Rolle
116
58
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
118
59
Gliederung
•
Einleitung
– These
•
–
–
–
–
•
Domänenservices
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
•
– 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
120
60
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
122
61
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
124
62
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 MikroSOA
•
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
126
63
„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“
128
64
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
Enterprise Service Bus
Anwendung
B
Anwendung
C
Anwendung
D
N
130
65
Mikro-SOA
Service Entität A
Service Entität B
Service Entität C
Anwendung
131
SOA ist für uns vor allem ...
SOA = EAI + XML + WS
132
66
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
N
N
Anwendung
D
N
Management
N
BC
SOAP
BC
SAP
BC
Dateisystem
BC
Email
Dateisystem
134
67
Der ESB ist keine Lösung für den Weltfrieden…
… er kann aber Integration
Internes Netz
Externer
Partner
ESB/BPEC/OS
CRM
Finance
Stock
Procument
Siehe auch: Jim Webber Martin Fowler - Does My Bus Look Big In This
http://www.slideshare.net/deimos/jim-webber-martin-fowler-does-my-bus-look-big-in-this
135
Mehr von OIO zum Thema...
•
Schulung: SOA - Service orientierte Architekturen
– http://www.oio.de/seminar/entscheider/soa-schulung.htm
•
Schulung: SOA Governance
– http://www.oio.de/seminar/entscheider/soa-governance-schulung.htm
•
Beratung: SOA / WebServices
– http://www.oio.de/beratung-consulting/software-integration/soa-webservices/
136
68
? ?
?
? ?
? ?
?
Fragen ?
Weinheimer Str. 68
68309 Mannheim
www.oio.de
[email protected]
Vielen Dank für ihre
Aufmerksamkeit !
Weinheimer Str. 68
68309 Mannheim
www.oio.de
[email protected]
69

Mikro-SOA vs. Makro-SOA

Transcription

Similar documents

Magazin - Wolfgang Timpe Hamburg

X-Rotation Blades = Koaxialrotor

Modellgetriebene Software-Entwicklung mit BPMN und SOA

PDF - 128 kb - BVF Landesverband Nordrhein

Leitlinien zur inklusiven Beschulung

- Oliver Wyman

Trend Wohnen Büro Fotowettbewerb Selected

Oracle Forms Migration Framework

Babylon Familie

Die Macht des Nichtwissens

Endbericht

Dr-Odin i2fm Produktentwicklung FMWinterforum Vortrag (880,84 KiB)

ITIL / ITSM – SOA – BPM – BI

Automobilindustrie

Geschäftsinnovationen durch BPM-Technologien und SOA

Schulinternes Curriculum Englisch Sek - Clara

Claus Fintzen - Bundeskongress Öffentliche Infrastruktur