Andre Karalus, Carsten Sensler SOA und der Schmelztiegel der...
Transcript of Andre Karalus, Carsten Sensler SOA und der Schmelztiegel der...
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