Microsoft ESB – erstes 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.

Microsoft ESB – 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 Drittanbieter „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 verbunden. Aber sie lassen sich als solche behandeln, und zwar im Sinne des „SOA Service Managers“ und der „SOA Workbench“.

Microsoft ESB – Funktionsweise

Der ESB nimmt eingehende Dokumente an und arbeitet mit ihnen. Die ausgeführten Maßnahmen kö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 Abbildung):

1. Dokument ist bei einer „On-Ramp“ angenommen.
2. Eine Pipeline Komponente legt in den Nachrichtenmetadaten („Kontext“) stehende Eigenschaften fest (basierend auf entweder einer Komponenteneigenschaft oder einer SOAP Kopfzeile im übermittelten Dokument.
3. Dokument ist der BizTalk „MessageBox- Datenbank“ zugestellt.Basierend auf den Dokumentenmetadaten/ Kontexteigenschaften erhält ein Abonnent („Subscriber“) ein Dokument. Abonnenten können sein:

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

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

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

1. Dokument entsteht in einer Ablauflogik („Orchestration“).
2. ESB Metadaten Eigenschaften werden angefüllt.
3. Dokument wird durchgereicht zur MessageBox.
4. 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.

Microsoft ESB – Installation

Die ESB 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.

Microsoft ESB – Architektur

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 dokumentenorientierten 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 Eigenschaften/Metadaten von Nachrichten). Wenn ein neues Dokument in der „MessageBox-Datenbank“ (Hauptaufgaben: Persistenz von Nachrichten und Ablauflogiken) ankommt (siehe Abbildung unten), 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 „MessageBox-Datenbank“ 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 Komponenten, die Einzelheiten von Ausnahmen zum ESB Management Portal weiterleiten.
• Das Management Portal, welches „Provisioning“, Ausnahmebehandlung und B2B Dienste als auch Informationen über Prozessverlauf und andere operative (Maß-) Analysen darstellt.

Microsoft ESB - Bausteine

Microsoft liefert viele der benötigten Bausteine für den Ausbau einer umfassenden Service-Orientierten Infrastruktur durch seine Anwendungs- und Integrationsplattform, die Windows Server 2003 (R2), das .NET Framework 3.x und BizTalk Server 2006R2 einschliesst. Der Microsofts ESB bringt die Fähigkeiten mit:

• Dokumentenverteilung („Message Routing”)
• Dokumentenvalidierung („Message Validation”)
• Dokumententransformation („Message Transformation”)
• zentrales Ausnahmemanagement („Centralized Exception Management“)
• Erweiterbares Adaptersystemgefüge („Extensible Adapter Framework”)
• Dienste-Ablauflogik/Aggregation („Service Orchestration”)
• Geschäftsregelsystem („Business Rule Engine”)
• Fachliche Analyse („Business Activity Monitoring”)

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 Beispielszenarien. Diese sind innerhalb einer ESB Client Beispielanwendung zugänglich und durch eine Vielzahl veränderbarer Parameter auszuführen, um die Funktionalität der „ESB Core Engine“, der „Core Services“, des „ESB Management Portal“ und den dazugehörigen „Pipeline Komponenten“ (Nachrichtennach/-vorverarbeitung) 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, Anpassungen und Erweiterungen an den als Standard referenzierten Implementationen vorzunehmen, damit diese den besonderen SOI Anforderungen genügen.

Microsoft 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, unterschiedlichen 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, Web Dienste, .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 Abbildung unten).

Microsoft ESB - Definitionen und Begriffserläuterungen

Als Einstieg die verschieden Definitionen und Begriffserläuterungen zu ESB:

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

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 Nachrichtenorientierung, 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 Integrationsaufgaben, 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 eingeschlossenes Risiko zu mindern, wenn sich das Geschäftsmodell ändert und neue Möglichkeiten sich ergeben.“

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“.

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 UDDI-basierteVerzeichnisse, um Dienste zu erkennen und zu veröffentlichen, Java Message Service (JMS) und andere, weit verbreitete Nachrichtenprotokolle, standardbasierte (XML) Transformationen und einfache Dokumentenweiterleitung“.

David Chappel

In den Ausführungen seines Buchs „Enterprise Service Bus” (ISBN: 0596006756), hält der Autor David Chappel fest, dass, „statt mit den traditionellen Nabe und Speiche („Hub and Spoke”; siehe auch Abbildung unten) Architekturen von unternehmensweiten Anwendungsintegrationsprodukten 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-) Bereichen oder 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.“

Microsoft ESB – angekündigte Roadmap

Der Softwarehersteller Microsoft hat den Anschluss an die bisherigen Enterprise Service Bus (ESB) Marktführer hergestellt, schickt sich nun aber selbst an, eine führende Rolle zu übernehmen.

Die Vorstellung des Microsoft 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 eingeschrä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.

In folgenden Posts lesen Sie relevante Aspekte zum geplanten Microsoft ESB: ausgehend von allgemeinen Grundlagen zu ESB, über den geplanten Funktionsumfang, bis zum Anwendungsszenarien.