Enterprise Service Bus

Transformatoren

Die Transformierung von Nachrichten (z.B. mithilfe von XSLT) zählt zu einer wichtigen Eigenschaft des ESB. Das Datenformat unterscheidet sich maßgeblich von den einzelnen Applikationen, obwohl die Semantik der Daten oft dieselbe ist. Ein Transformer stellt sicher, dass die erhaltene Nachricht vom Bus von der Anwendung verarbeitet werden kann. Gerade das Mapping der auszutauschenden Daten stellt in vielen Anwendungsfällen einen hohen Aufwand dar. Daher ist die Einführung eines generischen Datenformats sinnvoll. Gerade hier ist der Integrationsarchitekt gefragt. Seine Aufgabe ist es mit den Inhabern der einzelnen Applikationen zu diskutieren, welche Formate welche Applikation benötigen. Aufbauend auf diesen Informationen kann ein generisches Datenformat (sofern es möglich ist) erstellt werden.

Neben der eigentlichen Datentransformation, welche in den meisten Fällen vom Anwendungsentwickler gemacht werden muss, ist die Protokolltransformation ein entscheidender Aspekt bei einem ESB. Betrachten wir beispielsweise den Zugriff auf Mail-/File-Systeme oder Web Services. Durch die Protokolltransformation wird das Format des Fremdsystems in das Standardformat des ESB konvertiert. Anwendungsentwickler müssen sich daher nur mehr in Spezialfällen mit dem Protokoll des Fremdsystems auseinandersetzen. Wenn man die Produkte der ESB-Hersteller betrachtet, haben viele Anbieter bereits ein breites Angebot an vorhandenen Protokolltransformatoren.

Router

Zum Transport zählt auch das zuvor erwähnte Routing (bspw. Content-Based-Routing). Auch für das Routing können Standards wie XPath oder XQuery zum Einsatz kommen. In der Ausgabe 2.08 des Java Magazins wurde das Content-Based Routing anhand einer Rule Engine erläutert. Eine Rule Engine kann natürlich auch in den ESB integriert werden (wie es beispielsweise Service Mix macht).

Einige ESB-Hersteller bieten für das intelligente Routing mächtige Hilfswerkzeuge an. Dabei können Entwickler komplexe Regeln erstellen und diese Regel auf das Routing anwenden. Dieses intelligente Routing kann so komplex werden, dass Prozessabläufe abgebildet werden können. Hier stellt sich jedoch die Frage, in welchem Detaillierungsgrad der Prozess im ESB abgebildet wird. Denn für die Abbildung von Geschäftsprozessen können Workflow-Systeme bzw. BPEL Engines an den ESB angekoppelt werden, welche ausschließlich für den Geschäftsprozess ausgelegt sind.

Integration von Anwendungen

Anwendungen können mit unterschiedlichsten Systemen kommunizieren: Messaging-Systeme, SAP, Mail, Content Repository etc. Man könnte nun für jedes dieser Systeme einen proprietären Konnektor entwickeln und endet mit einer Vielzahl an Konnektoren. Diese Punkt-zu-Punkt-Kommunikationen werden sehr schnell unübersichtlich und sind nach einiger Zeit kaum noch wartbar. Wird beispielsweise ein neues System eingebunden, so muss wieder ein neuer Konnektor geschrieben werden. Wäre es nicht eleganter nur einen Konnektor zu haben, und zwar jenen zum ESB?

Neue Komponenten sollen einfach und über standardisierten Weg in den ESB integriert werden können. Ich möchte hier nochmals betonen, dass Standards in Zusammenhang mit dem ESB essenziell sind. Standards (JCA, JMS, WS-*) sind technischer Natur und spezifizieren die Schnittstellen und die Grundarchitektur. Jeder ESB-Anbieter implementiert diese Standards auf seine Art und Weise. Daher unterscheiden sich die Produkte in ihrer Funktionalität und Handhabbarkeit enorm.
Werden bestehende Anwendungen in einen ESB integriert, sollten diese von deren Integration nichts mitbekommen. Der Anwendung ist nur bekannt, dass diese Nachrichten senden und empfangen können. Für die Einbindung von Komponenten werden so genannte Endpoints verwendet. Der ESB muss dafür eine API zur Verfügung stellen und durch diese die Komplexität des ESB abstrahieren.

Was ist mit JBI (Java Business Integration)?

Wie zuvor erwähnt, unterscheiden sich die ESB-Produkte maßgeblich in ihrer Funktionalität, Administration und dem Einbinden eigener Komponenten. Dies führt oft dazu, dass Komponenten zwischen ESBs nicht einfach ausgetauscht werden können. Genau für diese Zwecke helfen Standards wie Java Business Integration (JBI) von Sun Microsystems. Der Standard definiert, wie Businesskomponenten basierend auf einem Bus miteinander verbunden werden können. Weiteres stellt der JBI, eine Art Plug-in Framework bereit, um ein einfaches Hinzufügen von Komponenten zu ermöglichen. Das Management bei JBI erfolgt über den JMX-Standard. JBI definiert also viele oben genannte Konzepte, welche ein ESB erfüllen sollte.

ESB und SOA

Bei SOA möchte man durch die Komposition von Services neue Applikationen erstellen. Die Komposition von Services wird oft in Form eines Geschäftsprozesse (z.B. BPEL) abgebildet. Ein BPEL-Prozess kann wiederum ein Service sein, was eine stufenweise Servicekomposition mit sich bringt. Dieser Prozess verwendet im Prozessverlauf eine Menge von Web Services (Orchestrierung). Einer der grundlegendsten Aktivitäten in einer SOA ist der Find-Bind-Invoke-Vorgang (Abb. 3, 4). Dabei sucht eine Anwendung (Requestor) in einem Service Registry nach einem passenden Service. Das Registry verfügt über die notwendigen Informationen, um mit dem Service Provider in Verbindung zu treten. Mit diesen Informationen kann die Verbindung (Binding) zwischen Requestor und Provider hergestellt und das Service in Anspruch genommen werden (Invoke).

Abb. 3: Find-Bind-Invoke-Vorgang in SOA

Abb. 4: ESB unterstützt Find-Bind-Invoke

Durch den Einsatz des ESB kommunizieren die Services nicht nur über standardisierten Weg, sondern es können auch Funktionen wie das Routing, Transformer, sichere Nachrichtenzustellung etc. vom ESB genutzt werden. Der ESB bietet eine solide Basis für die Servicekommunikation.

Fazit und Ausblick

Der ESB bringt neue Visionen der Integration mit sich und trägt auch zum Aufbau (technischer Natur) serviceorientierter Architekturen bei. Softwarearchitekten und Entwickler müssen sich jedoch über die Komplexität eines ESB bewusst sein und mit erhöhter Einarbeitungszeit rechnen. Es muss nicht immer ein ESB sein, es gibt durchaus Projekte, bei denen ein ESB das System unnötig aufbläst. Eine Generalaussage kann man an dieser Stelle nicht treffen.

Markus Demolskyist selbstständiger Software-Engineer und Consultant bei Indoqa. Seine Schwerpunkte liegen bei Softwarearchitektur, Workflow Management Systemen und Open Source Technologien im Java EE Umfeld. Aktuell arbeitet er mit Dr. Alexander Schatten an einem Buch zum Thema „Software Engineering – Best Practices“. Sein Dank geht an Werner Guttmann und Alexander Schatten für das ausführliche Feedback zu diesem Artikel.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.