Embed Size (px)
DESCRIPTION
Service-Infrastruktur in der DZ BANK: leichtgewichtig und verteiltSOA ist kein rein technisches Thema. Dennoch erfordert die Umsetzung von SOA durchaus eine technische Infrastruktur. Die DZ BANK hat die zukünftigen Anforderungen in diesem Bereich erkannt und nach einer ausführlichen Konzeptphase eine Service-Infrastruktur aufgebaut. Wichtige Merkmale sind leichtgewichtige Integration und flexible Verteilbarkeit.1) Motivation für eine Service-Infrastruktur 2) Gegenüberstellung der Ansätze: verteilt und zentral 3) Herausforderung bei der Verteilung 4) Konkreter Aufbau der Service-Infrastruktur 5) Erfahrungen http://xing.to/cab
Citation preview
SOA-Kongress 2007, 14.-15. November, Mainz
Jens Granseuer, DZ BANK
Christoph Bröcker, Zühlke
Service-Infrastruktur
in der DZ BANK –
leichtgewichtig und verteilt
Version 1.0
© DZ BANK 2
Die DZ BANK im genossenschaftlichen FinanzVerbund
• DZ BANK AG
• VR LEASING
• DVB Bank AG
• Transaktions-
institut
• BSH AG
• DG HYP AG
• Kreditwerk
• R+V Versiche-
rung AG
24.000 Mitarbeiter, Bilanz: 439 Mrd €
Bank Retail Immobilien Versicherung
1.250 Genossenschaftsbanken
30 Mio. Kunden, 16 Mio. Mitglieder, Bilanz 961 Mrd €
• Union Asset
Management
Holding AG
• Teambank AG
• DZ BANK Int.
• DZ PRIVAT-
BANK (Schweiz)
Version 1.0
© DZ BANK 3
Motivation für eine Service-Infrastruktur
Vorgehen im Projekt
Zentrale vs. verteilte Architektur
Aufbau der service-orientierten Plattform
Erfahrungen
1
2
3
4
5
Inhalt
Version 1.0
© DZ BANK 4
Motivation für eine Service-Infrastruktur
Vorgehen im Projekt
Zentrale vs. verteilte Architektur
Aufbau der service-orientierten Plattform
Erfahrungen
1
2
3
4
5
Inhalt
Version 1.0
© DZ BANK 5
Bebauungsplan der DZ BANK
Kunden- betreuung
Research Information Marktdaten
Invest- ment Banking
Zahlungs- verkehr
Kredit
Darlehen und andere
Kreditprodukte
Geld & Devisen
(inkl. OTC- Derivate)
Aktien Aktien- derivate
(inkl. OTC- Derviate)
Renten Zins- u.
Kredit-OTC- Derivate
Förder- kredite
Abwicklung Abwicklung
Risikomgmt/ Collateral mgmt.
Ausführung/ Abschluss
Position- führung/ Bewertung
Auftrag/ Ausführung
Analyse/Ent- scheidung
Geschäfts- anbahnung/ Akquisition
Zahlungsver- arbeitung
Zahlungs- erstellung
Risikomgmt/ Collateral mgmt.
Pricing
Windows
z/OS Unix
Guardian
1 Motivation für eine Service-Infrastruktur
Effektive Integration ist Kernaufgabe der IT.
Version 1.0
© DZ BANK 6
Thema dieses Vortrags
Ausgangspunkt: Integrationsinfrastruktur der DZ BANK
EAI
Verantwortung für IT-Integration ist zentral organisiert
– Standardisierte Architektur für Schnittstellen und Geschäftsprozesse
– Plattformen (BPM und EAI) können einzeln oder kombiniert verwendet werden
Zusätzlich Unterstützung von SOA als strategisches Ziel
– Schwerpunkte: Flexibilität und Wiederverwendung
– Säulen der SOA Einführung: Architektur/IT, Organisation, Geschäftsprozesse
Transformation
Betrieb/Überwachung
Enterprise Application Integration (EAI)
Adapter-Framework
Datentransport
1 Motivation für eine Service-Infrastruktur
Business Process Management (BPM)
Geschäftsprozesse
Workflow
Seit 1998
ca. 200 Anwendungen
ca. 500 Schnittstellen
Seit 2004
3 Geschäftsprozesse
Weitere in Planung
Version 1.0
© DZ BANK 7
Warum ist eine Service-Infrastruktur notwendig?
1. Vereinheitlichung und Lenkung der service-orientierten Entwicklung
Eine flexible SOA mit loser Kopplung benötigt Querschnittsfunktionen wie Komposition, Orchestrierung, Sicherheit, Transaktionsverwaltung, Tracking
Ungeordnete Service-Entwicklung führt schnell in eine stark heterogene Umgebung aus Speziallösungen („WS Spaghetti“).
Direkte Web Service-Verbindungen lassen sich wie alle Punkt-zu-Punkt Verbindungen nur schwer verwalten.
2. Strategische Ausrichtung der DZ BANK IT auf „Reuse, Buy, Make“
Reuse: Wiederverwendung benötigt ein Service-Verzeichnis
Buy: Standardsoftware wird service-orientiert und muss integriert werden
Make: Zunehmend Komposition von Systemen zu Gesamtlösungen
1 Motivation für eine Service-Infrastruktur
Version 1.0
© DZ BANK 8
Ziel der SOP: Aufbau einer einheitlichen Service-Infrastruktur
Unterstützung offener Standards, insbesondere Web Services
Protokollumwandlung und Transformation
Content-based Routing und Publish/Subscribe
1. Lose Kopplung von Servicenehmern und Servicegebern
2. Komposition von einfachen zu höherwertigen Services
4. Unterstützung von Betrieb und Wartung von Services
5. Vereinfachte Wiederverwendung von Services
Orchestrierung
Choreographie
Einbindung in Workflows
Zentrales Logging und Hilfen zur Fehleridentifikation
Service-Updates im Betrieb
SLA Definition und Überwachung
Leichtere Auffindbarkeit von Services
Einheitliche Service-Schnittstellen, leicht aus allen Technologien
heraus verwendbar
3. Nutzung vorhandener EAI-Funktionen in Services
Transformationen
Verwendung des EAI Message-Formates
1 Motivation für eine Service-Infrastruktur
Version 1.0
© DZ BANK 9
Künftiger Aufbau der Integrationsinfrastruktur
EAI
SOA BPM
User Interaction
BPM
Geschäftsprozesse
Manueller und automatisierter Workflow
Business Activity Monitoring (BAM)
User Interaction
Portalanwendungen
Content Management
Eigene Benutzerschnittstellen
SOA
Services (Request/Reply)
Events (Publish/Subscribe)
Komposition
Orchestrierung
EAI
Connectivity
Adapter-Framework
Datentransport (Push)
Transformation
Service-Infrastruktur und Benutzerschnittstelle werden mit einbezogen.
1 Motivation für eine Service-Infrastruktur
Version 1.0
© DZ BANK 10
Motivation für eine Service-Infrastruktur
Vorgehen im Projekt
Zentrale vs. verteilte Architektur
Aufbau der service-orientierten Plattform
Erfahrungen
1
2
3
4
5
Inhalt
Version 1.0
© DZ BANK 11
Vorgehen
Juli März 2006
Konzeption Produkt-
auswahl Realisierung
2 Vorgehen im Projekt
Dezember 2007
Festlegung der
Basiskomponenten
für die SOP
Erstellung der
Konzeptstudie
Erstellung eines
SOP-Prototypen
auf Open Source-
Basis
Hersteller-Evaluierung
– 11 Hersteller wurden
eingeladen, 8
Hersteller haben
teilgenommen
– Proof of Concept
mit 2 Herstellern
durchgeführt
Erstellung des DV-
Konzepts SOP auf
Basis der ausgewählten
Produkte
Aufbau der Infrastruktur auf
Basis von Artix
Entwicklung der
Basiskomponenten
Einführung des Repositories
Unterstützung von
Pilotprojekten
Erste Produktivsetzung eines
SOP-Services im November
06/2006 02/2007
Version 1.0
© DZ BANK 12
Motivation für eine Service-Infrastruktur
Vorgehen im Projekt
Zentrale vs. verteilte Architektur
Aufbau der service-orientierten Plattform
Erfahrungen
1
2
3
4
5
Inhalt
Version 1.0
© DZ BANK 13
Wie wird der Service Bus tatsächlich realisiert?
Zentraler Ansatz
Verteilter Ansatz (Optionen)
Zentrale oder verteilte Plattform
Service Client
Hardware 2 Hardware 1 SOP Hardware SOP
Komponenten
Service Client
Hardware 2 Hardware 1 SOP
Komponenten
Service
Hardware 2 Hardware 1 SOP
Komponenten
+ Einfacher Betrieb
– Performance
– Single point of failure
– Volle QoS nicht bis an
die Endpunkte
– Keine Flexibilität für
Trade-Offs
+ Volle Flexibilität bei
Verteilung
+ Höhere Performance und
Robustheit
+ Lösungsspezifische
Trade-Offs
+ Volle QoS bis zu allen
SOP-Endpunkten
– Komplexer Betrieb?
SOP
Service Client
Hardware 2 Hardware 1 SOP Hardware SOP
Komponenten
SOP
SOP
Client
3 Zentrale vs. verteilte Architektur
Version 1.0
© DZ BANK 14
Ein typischer zentraler Ansatz beruht auf der Nutzung eines Application Servers
mit einem weiteren Web Service Stack (z.B. Apache Axis) an den Endpunkten.
QoS muss durch Service Bus und Web Service Stack sichergestellt werden.
Nutzer können direkt miteinander kommunizieren, umgehen dabei aber die SOP.
Architektur einer SOP mit zentralem Ansatz
Service
Zentraler ESB
App. 1
QoS
Service
Service
Service
Service
App. 3
App. 2 App. 4
3 Zentrale vs. verteilte Architektur
Version 1.0
© DZ BANK 15
Verteilte Architektur der SOP
Service Bus bietet zentrale Funktionen und einen Web Service Stack für die
Endpunkte.
QoS wird durch SOP sichergestellt (End-to-End QoS).
Nutzer können über die Plattform direkt miteinander kommunizieren.
Service
Zentrale
Komponenten
App. 1
QoS
Service
Service
Service
Service
App. 2 App. 4
App. 3
3 Zentrale vs. verteilte Architektur
Version 1.0
© DZ BANK 16
Motivation für eine Service-Infrastruktur
Vorgehen im Projekt
Zentrale vs. verteilte Architektur
Aufbau der service-orientierten Plattform
Erfahrungen
1
2
3
4
5
Inhalt
Version 1.0
© DZ BANK 17
Verteilung in der SOP: Schalenmodell
R1
4 Aufbau der service-orientierten Plattform
Clients / Basis-Services
A
B
D
Erweiterte & Prozess-Services
Relays
R2
C E
F
Satelliten
Relay-Schale
X Y SOP Kern
Funktionen der Schalen
Zentrale Funktionen wie Service-Verzeichnis und
schwergewichtige Dienste wie Orchestrierung
Leichtgewichtige Dienste (Indirektion, Tracking)
Innen: Artix-basierte Serviceteilnehmer
Außen: Standard Web Services Serviceteilnehmer
Version 1.0
© DZ BANK 18
Verteilung in der SOP: Schalenmodell
R1
4 Aufbau der service-orientierten Plattform
A
B
D
Erweiterte & Prozess-Services
Relays
R2
C E
F
X Y Quality of Service
Kern, Relay-Schale und innere Satelliten:
QoS des gewählten Produkts (Artix)
Außen: QoS von Standard Web Services
Satelliten
Relay-Schale
SOP Kern
Clients / Basis-Services
Version 1.0
© DZ BANK 19
Verteilung in der SOP: Schalenmodell
R1
4 Aufbau der service-orientierten Plattform
A
B
D
Erweiterte & Prozess-Services
Relays
R2
C E
F
X Y Verantwortung und Hardware
Applikations- oder Integrationshardware
Satelliten
Relay-Schale
SOP Kern
Integrationshardware
Applikationshardware
Zentrale
Verantwortung
Verteilte
Verantwortung
Clients / Basis-Services
Version 1.0
© DZ BANK 20
Motivation für eine Service-Infrastruktur
Vorgehen im Projekt
Zentrale vs. verteilte Architektur
Aufbau der service-orientierten Plattform
Erfahrungen
1
2
3
4
5
Inhalt
Version 1.0
© DZ BANK 21
GP Service SAP GP
Siebel
EAI WS MQ
HTTP
HTTP
Praktischer Einsatz: CRM-Projekt
5 Erfahrungen
Geschäftspartner (GP) in SAP sollen in Siebel CRM verfügbar gemacht werden.
Siebel stellt mehrere Web Services zur Verfügung, für die ein GP Service als
Fassade entwickelt wird.
Die bestehende Datenanlieferung über die EAI-Plattform wird genutzt.
SOP
Version 1.0
© DZ BANK 22
Erfahrungen – SOA Technologie
Interoperabilität bei Web Services ist noch keine Realität
– Nur einfache SOAP/HTTP-Beispiele sind uneingeschränkt interoperabel
– Unterschiedliche Werkzeuge „sprechen unterschiedliche Dialekte“
– Stolpersteine z.B. WSDL-Modularisierung und die Verwendung von Namespaces
Technisches Service-Design birgt eigene Komplexität
– Automatisch generiertes WSDL (z.B. von Siebel) muss eingebunden werden
– Starke Typisierung (in XSD) bietet Sicherheit, erhöht aber die Kopplung
– Untypisierte Bereiche als Alternative (xsd:any)
Verteilung bedeutet Herausforderung bei Deployment und Versionierung
– Erfahrung mit verteilten Adaptern aus der EAI-Plattform kann genutzt werden
– Versionierung muss Kompatibilität der Schnittstelle berücksichtigen
– Deployment kann durch Service-Verzeichnis unterstützt werden
Komplexität von Orchestrierung mit BPEL ist hoch
– Evaluierung zeigt hohen Zeitbedarf Noch kein Einsatz in Projekten
5 Erfahrungen
Version 1.0
© DZ BANK 23
Erfahrungen – SOA Organisation
Konsistenz entsteht nicht von allein
– Der einheitliche Einsatz der Technologien muss durch ein Kompetenzteam und
durch dokumentierte Richtlinien, Muster und Beispiele unterstützt werden
– Service-Entwicklungsframework ist wichtige Komponente der SOP
Verschiedene Modelle für den Servicebetrieb sind notwendig
– Selbstverantwortlicher Betrieb (z.B. als Teil eines bestehenden Systems)
– Zentrales Service-Hosting
SOA Governance
– Bestehende Integrationskompetenz vereinfacht Zugang zu Projekten
– Mittelfristig wird das SOP-Kompetenzteam in den Projektprozess eingebunden
– Budget für Serviceentwicklung muss geklärt werden
– Organisatorische Nutzung des Service-Verzeichnisses wird Schritt für Schritt
aufgebaut
5 Erfahrungen
Version 1.0
© DZ BANK 24
Zusammenfassung
Eine solide Service-Infrastruktur ist die Basis jeder SOA
Beim Entwurf und bei der späteren Nutzung der Service-Infrastruktur spielen
Verteilungsaspekte eine wichtige Rolle.
Vorteile einer verteilten Infrastruktur sind:
– Bessere Unterstützung von hohen QoS-Anforderungen
– Mehr Flexibilität bei Deployment und Aufteilung der Betriebsverantwortung
Die SOP der DZ BANK realisiert diesen verteilten Ansatz.
– Basis bildet ein Standardprodukt (IONA Artix)
– Hinzu kommen Konzepte, Richtlinien und eigene Komponenten,
die eine einheitliche Nutzung sicherstellen
5 Erfahrungen
Jens Granseuer, [email protected]
Christoph Bröcker, [email protected]
Vielen Dank!
Fragen? Vielen Dank!
Fragen?
Version 1.0
© DZ BANK 26
Logische Komponenten
Service-Bus
Service-Verzeichnis
Werkzeuge
Service-Container
Binding Layer
Konfiguration
Management
Technische Dienste Ro
uter
Registry Repository
Administration Entwicklung
Views/Reporting Test
Tran
sports
chicht
Bus-R
ichtlin
ien
SOP
Version 1.0
© DZ BANK 27
Logische Komponente Service-Bus
Der Service-Bus besteht aus den Komponenten
Service-Container
– Stellt Hosting-Dienste für Services bereit
– Bietet Funktionen für Mediation, Routing,
technische Dienste und flexible Bindings
– Verfügt über Schnittstellen für die Konfiguration und das Management des
Containers und der darin gehosteten Services.
Transportschicht
– Verbindet die Serviceteilnehmer
– Transportiert Daten über Standardprotokolle (wie HTTP)
oder Standardprodukte (wie WMQ)
– Unterstützt verschiedene Kommunikationsmuster
Bus-Richtlinien
– Regelwerk für verschiedene Kommunikationsmuster der Serviceteilnehmer
– Sind im Service-Entwicklungsframework (SEF) definiert.
Service-Bus
Service-Verzeichnis
Werkzeuge
Service-Container Binding Layer
Konfiguration Management
Technische Dienste Ro
uter
Registry Repository
Admin Entwicklung Views/Reports Test
Tran
sports
chicht
Bus-R
ichtlin
ien
SOP
Version 1.0
© DZ BANK 28
Transport
Orientierung an Standards
Ziele der SOP sind Integration heterogener Systeme, Unabhängigkeit von
Betriebsplattformen und Einsatz verbreiteter Technologie, für die am Markt
Know-how verfügbar ist
Die SOP setzt daher stark auf die Nutzung von Web Service Standards.
HTTP(S) JMS …
Nachricht Beschreibung
WSDL XML Schema
Interoperabilität
WS-I
XML SOAP
Orchestrierung
BPEL
Sicherheit
WS-Security
Verzeichnis
UDDI
Zuverlässigkeit
WS-RM
WS-Addressing
