Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
SOA und der Schmelztiegel der ESBs
Andre Karalus, Carsten Sensler
Vorstellung ! Diplom-Inform. Andre Karalus
– freier Softwarearchitekt – SOA, EAI, Integrationsframeworks, UML & MDSD – im Auftrag von T-Mobile – [email protected]
! Dipl.-Ing. Carsten Sensler – T-Mobile, EAI, System & Solution Designer – Seit 2005 im SOABP Programm – Vorträge unter www.sensler.de
Agenda ! Motivation ! Verschmelzen von ESBs
– Konzepte – Superbus – Gateway Technik
! Beispiel SOABP – Internationaler Bus – Kopplung mit WSG/Rendezvous – Kopplung mit Tuxedo – Kopplung mit MQ-Bus
! Zusammenfassung & Ausblick
confidential
Mehrere ESBs
! Akquisitionen und Zusammenschlüsse – Jedes Unternehmen besitzt i.d.R. bereits einen eigenen
ESB ! Migration zu einem einzigen (neuen) ESB
– Services sind bereits an bestehende ESBs angekoppelt – Produktive, geschäftskritische Systeme sind mglws. in
der Wartungsphase ! Investitionsschutz vs. Harmonisierung
– Migrationskosten – „lokale“ ESBs sind produktiv und haben sich bewährt
! Erfahrung und Knowhow in den jeweiligen EAI-Abteilungen
confidential
Corporate Structure. Subsidiaries and affiliates.
! Direct or indirect investments by Telekom Group in companies dealing with mobile communications in twelve countries
! The T-Mobile brand is represented in Germany, Austria, Hungary, Great Britain, the Czech Republic, the Netherlands, the Slovak Republic, Croatia and the USA
! Almost 125 million customers in the majority holdings
Deutsche Telekom
T-Mobile International
Hungary
Mace- donia
Croatia
Slovak Republic
T-Mobile Germany
US
A
UK
NL
PL
CZ
Monte- negro
SOA Backplane Participant
5 C. Sensler & A. Karalus, SoaConf 2009
confidential
Beispiel T-Mobile
! Landesgesellschaften – Unterschiedliche ESBs (z.B. Tuxedo, Rendezvous)
! T-Mobile Deutschland – Aktuell SOABP – Vorgänger ESB (WSG/ Rendezvous)
! Integration und Migration
! Telekom Konzern – One Company (Merger T-Home/T-Mobile)
! SOABP und TIMB – Integration mit T-Systems Business Systemen bzw. ESB
confidential
Agenda
! Motivation ! Verschmelzen von ESBs
– Konzepte – Superbus – Gateway Technik
! Beispiel SOABP – Internationaler Bus – Kopplung mit WSG/Rendezvous – Kopplung mit Tuxedo – Kopplung mit MQ-Bus
! Zusammenfassung & Ausblick
confidential
SOA und ESB
! SOA ist ein Architekturstil für die Gestaltung von Anwendungslandschaften ! Integration von verteilten Diensten ist im Fokus
! Ein ESB ist streng genommen keine Voraussetzung für SOA ! In vielen Unternehmen unterstützt ein ESB die
Einführung einer SOA
ESB-Kernaufgaben/-merkmale ! Routing, Transformation von Nachrichten ! Protokolltransformierung ! Integration mithilfe von Standards ! Hochskalierbare und verteilte
Integrationsplattform ! Unabhängiges/verteiltes Deployment von
Servicekomponenten ! Unterstützung von SOA
ESB – Messaging Bus ! Gemeinhin stellt eine MOM die Basis für
einen ESB bereit – ESB-Suiten stellen zusätzlich zur MOM die sog.
Binding Komponenten bereit ! Intern ein standardisiertes Message Format ! Die Magie steckt in den Binding
Komponenten – Transformation – Protokollkonvertierung – Message Exchange Patterns – Routing
Messageexchange asynchron? ! Asynchrone Kommunikation kann
Entkopplung unterstützen ! Ein Teil der Services ist inhärent synchron!
– Beispiel: Lesen Services – Selbst „Auftrags“-Pattern ist u.U. synchron
! liefert Auftrags-Nummer
Message Exchange Pattern ! Asychrones Request/Reply
– Reliable ! Notification
– Mehrere Empfänger (Broadcast) ! Synchrones Request/Reply
– MEP mapping erforderlich bei MOM! ! Oneway
Binding Komponenten ! Sollten generisch sein
��� ��� �������� ��� ��������� ������ ������������ �
Application
SOAP/HTTP
JMS Bus
SOAP/JMS
CAL
Standardisierung beim ESB ! Messageformat
– WS-I Basic Profile ! MEPs
– Async Request/Reply ! Kleinster gemeinsamer Nenner (MOM)
– Sync Request/Reply ! Wünschenswert - da häufig verwendet ! Natürlich bei HTTP-Binding
! Addressierung – Dynamisches vs. Statisches Routing – WS-Addressing vs. Content base
SOA = SOAP/HTTP? ! SOA an sich trifft keine Festlegung über das
technische Protokoll ! In der Praxis wird SOA (häufig) mit
Webservices(SOAP) realisiert – Kritik
! XML Verarbeitung ! Unzureichende Standardisierung (RPC vs. Document)
– Vorteile in der Praxis ! Keine technologischen Lock-Ins (Client-Stubs bzw. API)
! .NET spricht mit Java ! Keine Binärabhängigkeiten
! „Lesbares“ Nachrichtenformat ! Viele Tools und herstellerspez. Integrationslösungen
Servicespezifische Integration ! Ein System benutzt beide ESBs
Servicespezifische Integration (2) ! Die Komponente hat Zugang zu beiden
ESBs – Z.B. wird der Service auf beiden ESBs angeboten
! Pros – Schnelle, kostengünstige Anbindung des Service
! Cons – Verschiedene ESB-Technologien müssen
beherrscht werden – Keine Transparenz aus EA-Modellierungssicht
! n x m – Problematik! – Steigende Kosten & Komplexität bei mehreren
Komponenten
Generische Integration von ESBs ! Mittels Gateway, Services des anderen ESBs
transparent verfügbar machen
Gateway
Gateway ! Agiert als generische Binding Komponente
aus Sicht des jeweils anderen ESBs – Generische Transformierung von Nachrichten – Protokolltransformierung
! Servicespezifische Konfiguration – Adressierung – Transformierung von Nachrichten
Gateway - Detailprobleme ! MEP mapping
– Unterstützt ein ESB ein MEP nicht, so muss dies ‚gemappt‘ werden, z.B. synchron nach asynchron
! Korrelation von Request/Reply – Das Gateway muss Korrelations-
information(+ggf. Adressinginformation) persistent halten
! Duplikatserkennung – Erfordert ein ESB(MEP) „exactly once delivery“
so muss (persistent) ein geeigneter Messageprint gehalten werden
– Ggf. Transaktionssteuerung ! 2PC, WS-Transaction ! Compensation Pattern
Gateway – Detailprobleme 2 ! Reliability
– Zusicherungen über die Verlässlichkeit der Zustellung müssen eingehalten werden (Retry/persistente Redelivery)
! Timeouts – Definierte timeouts müssen propagiert/
eingehalten werden – Housekeeping von persistenten Message
Exchanges
Gateway – Detailprobleme 3 ! Security
– Die Kommunikation übers Gateway muss sicher sein (ESBs in verschiedenen Netzen) – Transportverschlüsselung – Zertifikate/Keys zur Authentifizierung – Alternative: End2End via WS-Security
! Logging/Monitoring – Der gesamte Message Exchange (ESB-Gateway-
ESB) muss überwachbar bleiben
Routing ! Dynamisches Routing
– Service Lookup zur Runtime (z.B. UDDI) ! Das Gateway muss generischen Lookup implementieren ! Ggfs. Cross-ESB Lookup erforderlich
– Kohärenz von Service Repository und Registry ! Statisches Routing
– Die Konfiguration liegt statisch in den Binding Komponenten vor ! Das Gateway muss ebenfalls konfiguriert werden!
– Das Service Repository (SR) übermittelt die Routinginfo zur Configuration Time ! Das SR, welches das Gateway konfiguriert, ist führend
Service Repository ! Für eine adäquate Modellierung der
Enterprise Architecture (EA) wäre ein globales Service Repository erstrebenswert – Gleiche Problematik
! Migration noch schwieriger, das dies auf semantischer Ebene passieren muss (Impedance Mismatch)
! Neues globales Repository (Sub-/Superset) komplex
! Integration bzw. Synchronisation – Durch Synchronisation lassen sich wichtige
Daten abgleichen – Kann in einem nachgelagerten Projekt betrachtet
werden ! Runtime first!
Der Super-ESB ! Ein (Super-)ESB integriert andere ESBs
Gateway Gateway
Gateway
Der Super-ESB ! Möglichkeit n>2 ESBs zu integrieren ! Pros
– Entkopplung ! Verantwortlichkeit für die Gateways ! Organisatorisch: Beide ESB-Abteilungen können in der
Form bestehen bleiben – Gemeinsamer Standard als Basis zur weiteren
IT-Harmonisierung ! Cons
– Erhöhte Komplexität durch zusätzlichen ESB ! Erstellung und Betrieb ! Mindestens 2 Gateways erforderlich!
– Standardisierung erforderlich ! Gremienarbeit
! Fact 4
Super-ESB Standardisierung ! Gemeinsam getragener Standard der
beteiligten ESB-Teams – Motivation durch paritätische Beteiligung
! Problem: Super-/oder Subset von Features – Subset minimiert die Komplexität der Gateways – Superset erhöht Chance zur IT-Harmonisierung
! Erhöhte Komplexität – Prozesse werden übergreifend
Super-ESB / Beispiel ! Messageformat
– WS-Basic Profile ! MEPs
– Async/Sync/OneWay/Notification – Duplikatskontrolle
! Routing – Spezifische Auslegung von WS-Adressing
Agenda ! Motivation ! Verschmelzen von ESBs
– Konzepte – Superbus – Gateway Technik
! Beispiel SOABP – Internationaler Bus – Kopplung mit WSG/Rendezvous – Kopplung mit Tuxedo – Kopplung mit MQ-Bus
! Zusammenfassung & Ausblick
confidential
SOA Backplane – overview (simplified)
30
Business System(s)
Msgs.
SOAP –
JMS
Logs/ Status
WS/ others
Design time Runtime
Routing
JMS (Messaging, ESB)
Adapter(s) Common Access
Layer (CAL)
Logs
Service Repository (CEISeR)
Config
e.g. Corba, Tuxedo, JMS, …
Message- / Log-Store
(LMS)
Xplor
Provisioning time
C. Sensler & A. Karalus, SoaCon 2009
confidential 31
. . . . . .
TMCZ TMUK
. .
TMD
.
Service Repository (CEISeR)
Central view on
BAM, Logs & Monitoring
C. Sensler & A. Karalus, CMConf 2009
confidential
Intention of the SOA Backplane program
! SOA Backplane will deliver a number of software systems and standards, namely ! a service bus which is the SOA communication infrastructure
! Service repository ! Access layer framework (CAL) ! Basic messaging infrastructure (JMS)
! additional value adding components and functionality including ! logging, monitoring ! service contract management ! business activity monitoring ! transport components for B2B communication
! the Backplane Guide and SOA Governance as a set of guidelines and rules as to how SOA will be implemented within T-Mobile.
32 C. Sensler & A. Karalus, CMConf 2009
SOA Backplane – Common Access Layer (CAL) – ESB
��� ��� �������� ��� ��������� ������ ������������ �
Application
Document Literal
RPC Literal PlugIn
Application
XSLT PlugIn
Application
Binary protocol PlugIn Tuxedo Plug In
JMS invoker
JMS Bus
Socket invoker Http invoker
SOAP/JMS
CAL
confidential
Vorgänger ESB bei T-Mobile
! Basiert auf Rendezvous – Binding Komponenten werden generiert (aus Rose
basiertem Service Repository) – Die Stubs haben Binärabhängigkeiten zu
herstellerspezifischen Bibliotheken ! Compile-/Buildprobleme
! Besonderheiten – Hohe Performanz – Services mit großen (binären) Datenmengen – Existierende generische Webservice BC: WSG
! Vollständige Migration auf SOABP erst in 2010 abgeschlossen – Integration erforderlich!
confidential
Gateway: CAL <-> WSG
! MEP – SOAP/HTTP <-> SOAP/HTTP – Rein synchron -> keine Persistenz erforderlich
! Messagetransformation – RPC/literal nach document literal wrapped – Für die meisten services generische Transformation
möglich (auf Basis der beiden WSDLs)
confidential
Gateway: CAL <-> Tuxedo
! MEP – Rein synchron <-> keine Persitenz erforderlich – Nutzt Tuxedoseitig async request/reply zur Realisierung
des Timeouts ! CEISeR
– Um Tuxedo-Services als WS darzustellen sind XSDs nachzumodellieren (keine formale IDL in Tuxedo)
! Messagetransformation – Tuxedo-Services Data sind „flach“, ein generisches
Plugin mappt diese auf XML (Arrays) ! Technik
– Dank WTC läuft CAL inkl, Gateway auf BEA WL
confidential
Gateway: SOABP <-> TIMB
! TIMB basiert auf MQ-Series – JMS2JMS Bridging
! SOABP/CAL Gateway – Der CAL erhält Gateway-Funktionalität – CEISeR speichert Routinginformation (z.B. die Queue-
Namen in MQ-Series) ! MEP
– Async/sync Mapping erforderlich, da MQ-Bus nur async unterstützt
– Persistierung von Message-Hashes sowie Korrelationsinformation erforderlich
! Timeout – Ist bei TIMB nicht generell vorhanden, u.U. nur service
spezifisch lösbar
confidential
SOABP ein Super-ESB?
! SOABP ist nicht als Super-ESB geplant ! Aus der Definition lässt sich dies abstrahieren:
– Ein ESB, der andere ESBs integriert ! Ja, z.B. kann ein Tuxedo-Client einen WSG/Rendezvous Provider
aufrufen – Ein zentraler Hub ausschließlich für ESBs
! Nein, SOABP dient auch als normaler ESB mit Binding Komponenten für Services
Agenda ! Motivation ! Verschmelzen von ESBs
– Konzepte – Superbus – Gateway Technik
! Beispiel SOABP – Internationaler Bus – Kopplung mit WSG/Rendezvous – Kopplung mit Tuxedo – Kopplung mit MQ-Bus
! Zusammenfassung & Ausblick
Zusammenfassung & Ausblick ! ESBs werden nicht einfach abgelöst
– Integrationskonzepte erforderlich – MEPs, Addressing, etc. – Gateways sind nötig
Fragen/Diskussion
Listing ! Fact 1
– Information 1.1 – Information 1.2 – Information 1.3
! Fact 2 – Information 2.1
! Subitem 2.1.1 ! Subitem 2.1.2
! Fact 3 ! Fact 4