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 –  soa@karalus-it.de

!  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