Andre Karalus, Carsten Sensler. SOA und der Schmelztiegel der ESBs

Transkript

1 Andre Karalus, Carsten Sensler SOA und der Schmelztiegel der ESBs

2 Vorstellung! Diplom-Inform. Andre Karalus freier Softwarearchitekt SOA, EAI, Integrationsframeworks, UML & MDSD im Auftrag von T-Mobile Dipl.-Ing. Carsten Sensler T-Mobile, EAI, System & Solution Designer Seit 2005 im SOABP Programm Vorträge unter

3 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

4 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

5 Corporate Structure. Subsidiaries and affiliates. T-Mobile Germany T-Mobile International Deutsche Telekom US UK A NL CZ PL Hungary Macedonia Croatia Slovak Republic Montenegro! 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 SOA Backplane Participant confidential C. Sensler & A. Karalus, SoaConf

6 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

7 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

8 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 confidential

9 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

10 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

11 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

12 Message Exchange Pattern! Asychrones Request/Reply Reliable! Notification Mehrere Empfänger (Broadcast)! Synchrones Request/Reply MEP mapping erforderlich bei MOM!! Oneway

13 Binding Komponenten! Sollten generisch sein Application SOAP/HTTP CAL SOAP/JMS JMS Bus

14 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

15 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

16 Servicespezifische Integration! Ein System benutzt beide ESBs

17 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

18 Generische Integration von ESBs! Mittels Gateway, Services des anderen ESBs transparent verfügbar machen Gateway

19 Gateway! Agiert als generische Binding Komponente aus Sicht des jeweils anderen ESBs Generische Transformierung von Nachrichten Protokolltransformierung! Servicespezifische Konfiguration Adressierung Transformierung von Nachrichten

20 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 Korrelationsinformation(+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

21 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

22 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

23 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

24 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!

25 Der Super-ESB! Ein (Super-)ESB integriert andere ESBs Gateway Gateway Gateway

26 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

27 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

28 Super-ESB / Beispiel! Messageformat WS-Basic Profile! MEPs Async/Sync/OneWay/Notification Duplikatskontrolle! Routing Spezifische Auslegung von WS-Adressing

29 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

30 SOA Backplane overview (simplified) Business System(s) Logs WS/ others e.g. Corba, Tuxedo, JMS, Xplor Config Adapter(s) Common Access Layer (CAL) Logs/ Status Service Repository (CEISeR) Routing SOAP JMS JMS (Messaging, ESB) Msgs. Message- / Log-Store (LMS) Design time Provisioning time Runtime confidential C. Sensler & A. Karalus, SoaCon

31 TMD TMUK TMCZ Service Repository (CEISeR) Central view on BAM, Logs & Monitoring confidential C. Sensler & A. Karalus, CMConf

32 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. confidential C. Sensler & A. Karalus, CMConf

33 SOA Backplane Common Access Layer (CAL) ESB Application Application Application Document Literal Http invoker Socket invoker JMS invoker CAL Tuxedo Plug In RPC Literal PlugIn XSLT PlugIn Binary protocol PlugIn SOAP/JMS JMS Bus

34 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

35 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

36 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

37 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 confidential spezifisch lösbar

38 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 confidential

39 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

40 Zusammenfassung & Ausblick! ESBs werden nicht einfach abgelöst Integrationskonzepte erforderlich MEPs, Addressing, etc. Gateways sind nötig

41 Fragen/Diskussion

42 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