Es gibt viele Informationsquellen über Enterprise Service (ESB) Bus Design, Architektur und Infrastruktur.

Genauso gibt es zahlreiche Implementations-möglichkeiten von Herstellern, Systemintegratoren oder unabhängigen Lieferquellen. Der nachfolgende Beitrag bespricht die unterschiedlichen Auffassungen des Konzepts Enterprise Service Bus. Der Beitrag berücksichtigt übergeordnete Zusammenhänge und liefert umfang-reiche Quellenangaben zum Eigenstudium. Die Konzentration auf Microsofts Sichtweise zeigt auf, dass der Softwarehersteller den Anschluss an die (bisherigen) Marktführer herstellte, sich nun aber selbst anschickt, eine führende Rolle zu übernehmen. Die Vorstellung des Microsoft Verständnisses von ESB auf Basis des „BizTalk Servers 2006“ erfolgte bereits vor Jahresfrist auf der Microsoft SOA und BPM Konferenz in Redmond im Oktober 2006. Zurzeit ist die CTP3 (Community Technical Preview 3) allgemein verfügbar, dazu gab es eine einge-schränkt verfügbare Betaversion für ausgewählte BizTalk Server Partner. Die Veröffentlichung des ESB erfolgt laut Hersteller lizenzkostenfrei im erweiterten Lieferumfang von BizTalk Server 2006 R2. Es gibt zahlreiche Informationen zu ESB. Hier die interessantesten Fünf:

Wikipedia
Wikipedia beschreibt den ESB als „…eine Softwarearchitekturkonstruktion, implementiert durch Technologien, die sich in der Kategorie der „Middleware“ Infrastrukturprodukte befinden. Sie gründen sich gewöhnlich auf Standards, die grundlegende Services oder Dienste für komplexere Architekturen durch eine ereignisgesteuerte oder auf Standards basierende „Message Engine“ (der Bus) bereitstellen. [1]

IBM
IBM definiert ESB als ein System das „… einemUnternehmen erlaubt, einen umfassenden, flexiblen und konsistenten Zugang zur Integration bei gleichzeitiger Verringerung der Komplexität der zu integrierenden Anwendungen zu besitzen. Wegen der komplexen und unterschiedlichen Natur der Geschäftsbedürfnisse stellt der Enterprise Service Bus eine evolutionäre Vorgehensweise dar, die Nach-richtenorientierung, Ereignissteuerung und Serviceorientierung als Vorgehensweise vereint, um Anwendungen und Dienste zu integrieren“. Das Unternehmen beschreibt die Vorteile folgendermaßen: „… höhere Wiederverwendung von IT-Lösungsbausteinen durch Trennung von Anwendungslogik und Integrations-aufgaben, um die Anzahl, Größe und Komplexität von Integrationsschnittstellen zu verringern“ und die daraus entstehende Möglichkeit „… Dienste hinzuzufügen oder zu ändern, bei einer minimalen Unterbrechung der existierenden im Betrieb befindlichen Softwarelösung; dabei anfallende Kosten zu verringern und einge-schlossenes Risiko zu mindern, wenn sich das Geschäftsmodell ändert und neue Möglichkeiten sich ergeben.“ [2]

Sonic Solutions
Sonic Solutions geben eine umfassende Untersuchung des ESB, indem sie die hauptsächlichen Gesichtspunkte, sowohl den IT- als auch geschäftsbezogenen Nutzen diskutieren. Die Beschreibung der Voraussetzung für den Enterprise Service Bus lautet: „Um Altes und Neues zu integrieren, benötigt eine Service Orientierte Architektur (SOA) eine Infrastruktur, die sich an jede IT-Ressource anbindet, unerheblich ob deren Technologie(-herkunft) und wo immer sie sich befindet“. [3]

TIBCO
TIBCO Software definiert ESB als „… eine standardbasierte Kommunikationsschicht in einer Service Orientierten Architektur (SOA), die es ermöglicht, Dienste über mehrere Kommunikationsprotokolle zu benutzen, um die Verbreitung und das Verwalten von Diensten zu vereinfachen und die Wiederverwendung dieser in heterogenen (EDV-) Umgebungen zu fördern“. Der Hersteller schlägt vor „… um diese Fähigkeiten bereitzustellen, sollten ESBs beides unterstützen, zum einen offene Standards und zum anderen proprietäre Technologien: Dazu gehören Web Dienste und UDD-basierte Verzeichnisse, um Dienste zu erkennen und zu ver-öffentlichen, Java Message Service (JMS) und andere, weit verbreitete Nach-richtenprotokolle, standardbasierte (XML) Transformationen und einfache Dokumentenweiterleitung“. [4]

David Chappel
In den Ausführungen seines Buchs „Enterprise Service Bus”, hält der Autor David Chappel fest, dass, „statt mit den traditionellen Nabe und Speiche („Hub and Spoke”; siehe Bild 1) Architekturen von unternehmensweiten Anwendungsinte-grationsprodukten konform zu gehen, liefert der Enterprise Service Bus einen sehr breit verteilten Ansatz für Integration“. Er fügt hinzu, dass, „… [er] ausgestattet [ist] mit einzigartigen Fähigkeiten, die es einzelnen (Arbeits-) Bereichenoder Geschäftseinheiten erlauben, ihre Integrationsprojekte schrittweise, in kleinen Häppchen, auszubauen. Dabei erhalten die Abteilungen ihre Kontrolle vor Ort und Unabhängigkeit. Trotzdem sind sie in der Lage, jedes (Integrations-) Projekt in ein größeres, umfassenderes Integrationsgefüge oder Netz(werk) einzubinden.“ [5]

Was ist ein ESB – Microsofts Betrachtungsweise

Der Begriff Enterprise Service Bus fällt oft im Zusammenhang der Implementation einer auf Service Orientierte Architektur ausgelegten Infrastruktur. Jedoch zeigen gemachte Erfahrungen zur Verbreitung und Einsatz von SOAs, dass ein ESB nur einen der vielen Bausteine darstellt, die eine umfassende Service-Orientierte Infrastruktur (SOI) ausmachen. Der Begriff ESB formte sich in zahlreichen, unter-schiedlichen Richtungen aus. Seine Definition hängt von der Auslegung einzelner ESB- und Integrationsplattform-Anbieter und von den Anforderungen besonderer SOA Initiativen ab. Auf der Grundlage der Erfahrungen, die Microsoft durch viele erfolgreiche, sich im bewährten Einsatz, befindliche SOI Implementationen sammelte, trifft nachfolgende Aussage zu: Ein Enterprise Service Bus lässt sich als Ansammlung von IT-Architekturbausteinen beschreiben, die sich auf herkömmliche EAI, nachrichten-orientierte Middleware, WebDienste, .NET und Java Interoperabilität, (Groß-/Host-) Rechnerintegration und Interoperabilität mit Dienstverzeichnissen und zentral verwalteten IT-Bausteinen gründet. Anwendungen dieser Muster liefern eine Infrastruktur, die flexible und sichere Wiederverwendung von Diensten ermöglicht und die Fähigkeit, Dienste schnell zusammen in neue vollständige Geschäftsprozesse zu überführen (siehe Bild 2).

* Dokumentenverteilung ("Message Routing")

* Dokumentenvalidierung ("Message Validation")

* Dokumententransformation ("Message Transformation")

* zentrales Ausnahmemanagement ("Centralized Exception Management")

* Erweiterbares Adaptersystemsgefüge ("Extensible Adapter Framework")

* Dienste-Ablauflogik/Aggregation ("Service Orchestration")

* Geschäftsregelsystem ("Business Rule Engine")

* Fachliche Analyse ("Business Activity Monitoring")

Was genau ist die „Microsoft ESB Guidance“?

Microsoft ESB Guidance (Anleitung) enthält einen Architekturleitfaden, Muster- und Erfahrungsbeispiele aus der Praxis, sowie BizTalk Server und .NET Komponenten, die es Microsoft Partnern erlauben, große und kleine ESB Lösungen auf der Microsoft Plattform aufzubauen. Ebenso besteht die Anleitung aus einer Anzahl von BizTalk Server Anwendungen. Die Anleitung liefert Softwarearchitekten und -entwicklern eine Menge häufig anzutreffender ESB Anwendungsfälle und Beispiel-szenarien. Diese sind innerhalb einer ESB Client Beispielanwendung zugänglich und durch eine Vielzahl veränderbarer Parameter auszuführen, um die Funktio-nalität der „ESB Core Engine“, der „Core Services“, des „ESB Management Portal“ und den dazugehörigen „Pipeline Komponenten“ (Nachrichtennach/-vorverar-beitung) aufzuzeigen. Aufgebaut auf einer modularen Architektur, finden viele der Microsoft ESB Guidance Komponenten als einzeln stehende Bausteine Verwendung. Somit erhalten ESB Softwarearchitekten und ‑entwickler die Flexibilität, Anpass-ungen und Erweiterungen an den als Standard referenzierten Implementationen vorzunehmen, damit diese den besonderen SOI Anforderungen genügen.

Wie ist die Architektur zusammengeführt?

Die meisten heutigen Entwickler besitzen einen Hintergrund in code-orientierter, prozeduraler oder objektorientierter Programmierung. Deshalb übersehen sie bei der Entwicklung von BizTalk Lösungen leicht die BizTalk Server dokumenten-orientierten Fähigkeiten. Der BizTalkServer 2006 R2 besitzt einen mächtigen „Publish/ Subscribe” Mechanismus. Dieser Mechanismus arbeitet durch das Erschaffen und Befüllen von „Subscriptions“ (Abonnement auf Eigen-schaften/Metadaten von Nachrichten). Wenn ein neues Dokument in der „MessageBox-Datenbank“ (Hauptaufgaben: Persistenz von Nachrichten und Ablauflogiken) ankommt (siehe auch Bild 3), hält der Dokumentenagent nach Empfängern Ausschau und sendet das Dokument an jeden Endpunkt, für den ein Abonnement besteht. Diese lassen sich in vielfältiger Art und Weise aufstellen, einschliesslich des Anbindens einer Ablauflogik („Orchestration“) an einem Empfangspunkt („Receive Port“). Insgesamt gesehen bedeutet dies eine leistungsfähigere und skalierbarere Vorgehensweise. So lassen sich eine Reihe diskreter Unterprozesse schaffen und die Dokumenttypen definieren, die die Prozesse aufrufen ohne weitere Gedanken an die Folgeprozesse zu vergeben. Ein Prozess mag durch das Auftauchen eines Dokuments aktiviert sein, verrichtet seine Arbeit, um dann vielleicht ein weiteres Dokument zurück in die „MessageBox-Datenbank“ zu legen. Letzteres kann wiederum einen oder mehrere weitere Unterprozesse auslösen. Einige der Schlüsselmerkmale dieser Vorgehensweise lauten:

* Skalierbarkeit („Scalability“): Diese Art von Lösung nimmt im vollen Umfang die Vorteile des BizTalk Servers 2006 R2 durch seine im Lieferumfang enthaltenen Steigerungsmöglichkeiten wahr.

* Erweiterbarkeit („Extensibility“): Zusätzliche Prozesse können in das System aufgenommen werden, ohne dass die bereits installierte Lösung geändert oder nochmals zu installieren ist.

* Elastizität/Leistungsspitzenverwaltung („Resilience/Surge-Handling“): Sollte eine plötzliche und unerwartete Leistungsspitze von eingehenden Dokumenten auftauchen, reihen sie sich in der MessageBox ein und werden anschließend, wie es möglich ist, abgearbeitet – optional werden weitere verarbeitende Server hinzugeschaltet.

Alles innerhalb der Microsoft ESB Guidance Anwendungen ist, in dem die BizTalk  „MessageBoxDatenbank“ als Annahme- und Ablieferpunkt dient, lose miteinander verknüpft. Die ESB Anleitung wurde mit dieser Architektur im Hintergrund entwickelt und benutzt sie ausführlich in ihrer Implementation. Die Dienste und Komponenten fallen in sechs Kategorien:

* Web Dienste („Web Services“), die interne Dienste darstellen, wie zum Beispiel die Bestimmung/Auflösung von Endpunkten und die Übermittlungsweisen von Dokumenteninhalten.

* Schlüsseldienste („Core Services“), wie die von Software(„Agents“), die Übermittlungsweisen und Dokumentenablieferung darstellen.

* Empfangspunkte („On-Ramps“), die Dokumente in einer Reihe von Formaten und Protokollen wie SOAP; WSE, JMS (MQ Series) von außen empfangen; oder spezielle Formate und Protokolle benutzen.

* Versandpunkte („Off-Ramps“), die „Send Ports“ für die Auslieferung von Dokumenten, dabei Formate und Protokolle wie SOAP, WSE, JMS, (MQ Series) oder spezielle Formate und Protokolle benutzen.

* Verwaltung von Ausnahmen („Exception Management“), der Ausnahme Web Dienst („Exception Web Service“), der Ausnahmemanagement Mechanismus („Exception Management Mechanism“) und omponenten, die Einzelheiten von Ausnahmen zum ESB Management Portal weiterleiten.

* Das Management Portal, welches „Provisioning“, Ausnahmebehandlung und B2B Dienste als auch nformationen über Prozessverlauf und andere operative (Maß-) Analysen darstellt.

Wie der Enterprise Service Bus arbeitet

Der ESB nimmt eingehende Dokumente an und arbeitet mit ihnen. Die ausgeführten Maßnahmen önnen Übermittlung, Transformation, Ablauflogik, Zustellung und anderes einschließen, müssen es aber nicht unbedingt. Damit das ESB System funktioniert, benötigt es verschiedene mit dem vorgegebenen Dokument verbundene Anweisungen, die besagen, was geschehen soll. Es gelingt, indem man Metadaten zu den Dokumenten fügt, die eine Standardmenge von im Zusammenhang stehenden nutzbaren Eigenschaften liefern. Ein typischer Lebensablauf eines Dokuments, das ausserhalb des ESBs entsteht und durch den Microsoft BizTalk 2006 R2 ESB läuft, ist (siehe auch Bild 3):

* Dokument ist bei einer „On-Ramp“ angenommen.

* Eine Pipeline Komponente legt in den Nachrichtenmetadaten („Kontext“) stehende Eigenschaften fest (basierend auf entweder einer Komponenteneigenschaft oder einer SOAP Kopfzeile im übermittelten Dokument).

* Dokument ist der BizTalk „MessageBox-Datenbank“ zugestellt.

* Basierend auf den Dokumentenmetadaten/Kontexteigenschaften erhält ein Abonnent („Subscriber“) ein Dokument.

Abonnenten können sein:

* „Intermediaries”, beispielsweise Ablauflogik („Orchestrations”).

* „Off-Ramps“, beispielweise ein beliebiger Zustelldienst („Delivery Agent“), der mit einer Guidance ausgestattet ist oder ein eigens ausgewählter Zustelldienst („Custom Delivery Agent“).

Als Alternative zu den „On-Ramps“ mögen Dokumente von BizTalk Anwendungen entstanden sein und in die MessageBox durch folgenden Prozess gelangen:

* Dokument entsteht in einer Ablauflogik („Orchestration“).

* ESB Metadaten Eigenschaften werden angefüllt.

* Dokument wird durchgereicht zur MessageBox.

* Weitere Verarbeitungsschritte entsprechend der Dokumentenmetadaten.

Die erzeugten Dokumente in die MessageBox einzulegen und dass Abonnenten („Subscriber“) sie gemäß den Verarbeitungsregeln („Processing Instruction“) aufnehmen, ist genau genommen ein „StateMachine“ Muster. Diese locker verbundene Vorgehensweise, um die Architektur von BizTalk Lösungen zu errichten, ergibt hochskalierbare Lösungen und gilt als von der Industrie angenommener Weg im Sinne einer beispielhaften Mustervorgehensweise.

SOA Governance Integration

(Groß-)unternehmensbezogene Anwendungen haben robuste und verlässliche Management Merkmale zu unterstützen um mit Geschäftsanforderungen, Gesetzesvorgaben, Service Level Agreements (SLAs) und Kunden- und Handelspartner-Erwartungshaltungen im Einklang zu sein. Das vom Dritt-anbieter „SOA Software Inc.“ (siehe http://www.soa.com) verfügbare SOA-Softwaremanagementprodukt „SOA Software Management Point“ ist eine konzeptuelle Erweiterung zum „SOA Software Web Services Management Point“, die besonders auf die BizTalk Server 2006 R2 Umgebung anzuwenden ist und während der Ausführung die Kontrolle für Webdienstanwendungen garantiert. Der „SOA Software Management Point“ integriert sich vollständig (nativ) in den „SOA Software Service Manager“ und die „Workbench“ Produkte. Ungleich einem typischen Web Services Management Point steht diese Implementation mit Diensten durch die BizTalk Umgebung im Zusammenhang; ausgedrückt durch die BizTalk Server „Receive Locations“ und „Send Ports“. Gemäß der konfigurierbaren Natur der Receive und Send Ports (gegenüber einer Anzahl von BizTalk Adaptern konfiguriert), sind diese Dienste nicht notwendigerweise mit Web Diensten verbun-den. Aber sie lassen sich als solche behandeln, und zwar im Sinne des „SOA Service Managers“ und der „SOA Workbench“.

Installation

Die in Bild 3 ersichtlichen Lösungsbausteine liegen im Quellcode aber auch als Installationsmedium vor. Installationsvoraussetzungen sind Microsoft Windows Server 2003 (Service Pack 2), .NET 3.0 und BizTalk Server 2006 R2. Die ESB Guidance ist selbst eine BizTalk Server 2006 R2 Anwendung, deren Installation dem Standardablauf einer BizTalk Anwendung folgt.

Fazit

Schlüsselfunktionalität gibt die ESB Guidance in ihrer Ausprägung als Basis einer Serviceorientierten Infrastruktur vor. Zusätzlich wird diese Funktionalität, neben ihrer Verfügbarkeit durch die Komponenten in der ESB Guidance, ebenso für externe Anwendungen durch eine Anzahl von Schlüsselwebdiensten („Core Web Services“) verfügbar gemacht (beispielsweise der Transformationsdienst oder dynamische Endpunktermittlung). Somit erhalten ESB Entwickler die Flexibilität, Anpassungen und Erweiterungen an den als Standard referenzierten Implementationen vorzunehmen, damit diese den besonderen SOI Anforderungen genügen. Die endgültige Veröffentlichung der ESB Guidance wird der Hersteller voraussichtlich unmittelbar nach Verfügbarkeit von BizTalk Server 2006 R2 (September 07) ankündigen.

Andreas W. Niegel Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können

Marcus J. Armbruster Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können

Diesen Artikel finden Sie auch in der Ausgabe September/Oktober 2007 des it fokus.