Der Enterprise Service Bus (ESB) von Oracle stellt technische Weiterleitungsmöglichkeiten und Aufbereitungfunktionalitäten für die Datenübertragung zur Verfügung. Zur Vermeidung von redundanten Funktionen unterstützt er die Trennung von Zuständigkeiten (separation of concern). Für den Datentransport werden Standardprotokolle genutzt.

Abb. 1: Datenübertragung mit dem ESB. Abb. 2: Oracle Service Bus (OSB) Überblick.

Bedeutung

Der ESB ist als Framework zu verstehen, das die Basis für die Abbildung der Infrastruktur einer SOA darstellt. Der ESB bildet die Service-Schicht, mit der sich die verschiedenen Services eines Unternehmens verbinden lassen (siehe Abbildung 1).

Seine Funktionen sind:

• Transformation von Nachrichten
• Konvertierung von Nachrichten
• Routing von Nachrichten zwischen verschiedenen Services
• Bildung eines Standards für Nachrichten mit verschiedenen Netzwerkprotokollen
• Trennung von Empfänger- und Lieferservices

Architektur

Die Architektur innerhalb eines ESB-Projektes basiert auf den ESB-Systemen, die sich wiederum aus den ESB-Services zusammensetzen. Mehrere ESB-Services lassen sich zu einer Service-Gruppe zusammenfassen, die zusammengehörige Services beinhaltet. Auch ein Cluster für Hochverfügbarkeit und das Load Balancing sind innerhalb eines ESB-Systems möglich. Zusätzlich werden als Schnittstellen so genannte Adapter genutzt. Sie ermöglichen die Integration unterschiedlicher Anwendungen im ESB-System. Dadurch ist es dann möglich, einen Geschäftsprozess abzubilden, der auf heterogenen Applikationen basiert.

Implementierung

Es existieren drei Arten der ESB-Implementierung:

• Point-to-Point-Modell (Übertragung zwischen zwei Endpunkten)
  Das Point-to-Point-Modell ist die einfachste Form der Nachrichtenübertragung. Sie ist nicht skalierbar und sollte somit auch nicht verwendet werden, da sie bei steigenden Anforderungen nicht mehr ausreichend ist.
• Kanonisches Modell (Übertragung zu mehreren Endpunkten mit Regeln)
  Als Lösung der unzureichenden Skalierbarkeit ist das Kanonische Modell zu empfehlen. Hierbei können auch Nachrichtenfilter für die einzelnen Empfängersysteme definiert werden. Diese sind über das Einrichten so genannter Routing-Regeln im Routing-Service definierbar (s. u.).
• Routing-Service-Modell (Übertragung zu mehreren dynamisch konfigurierbaren Endpunkten mit Regeln)
  Das Routing-Service-Modell geht noch einen Schritt weiter und ermöglicht die dynamische Änderung der Services.

Datenübertragung

Die Übertragung der Daten erfolgt mittels verschiedener Protokolle:

• HTTP
• SOAP
• JMS
• JCA
• WSIF
• Java

Diese Protokolle nutzen den so genannten Routing-Service, der als eigentlicher „Datenträger“ anzusehen ist. Mit diesen Routing-Services lassen sich auch Filterregeln definieren und Transformationen der Daten innerhalb des ESB durchführen.

Tools und Services

Zum Erstellen eines ESB-Service wird im JDeveloper der ESB-Designer genutzt. Er ist ein Bestandteil der Oracle SOA Suite. Der ESB-Service unterteilt sich in den Routing bzw. SOAP-Service. Der Routing-Service leitet die Nachrichten über ESB weiter, wobei der SOAP-Service die Übergabe der Nachrichten an einen externen Service ermöglicht.

Der Routing-Service setzt voraus, dass die folgenden Routing-Regeln definiert sind:

• Wer erhält die Nachricht? (Ziel-Service)
• Sind XML- Änderungen notwendig? (Transformation)
• Sind bestimmte Bedingungen zu beachten? (Filterfunktion)
• Wie soll die Übertragungsart sein? (Synchron oder Asynchron)

Durch die Nutzung des SOAP-Service besteht die Möglichkeit, entweder einen BPELProzess oder einen anderen Webservice aufzurufen.

Transformation

Bei der Transformation werden XML-Dokumente von einem Format in ein anderes konvertiert. Hierzu wird der XSLT-Prozessor genutzt. Dies ist immer dann notwendig, wenn das im ESB übertragene Format sich von dem Request-Format des nutzenden Services unterscheidet.

Der klassische Fall ist die Transformation von Adressfeldern zu einem einzigen String. Als Beispiel seien hier die Felder „Vorname“ und „Nachname“ in der Ausgangsnachricht und das Feld „Name“ in der Empfängernachricht genannt. Dabei wird im ESB die Verknüpfung von „Vorname“ und „Nachname“ durch die Transformation vorgenommen.

Das Resultat dieses Vorgangs ist eine XSLDatei. Die Transformation wird mit dem XSLTMapper durchgeführt. Dieser besitzt eine große Anzahl von Built-in-Funktionen, mit deren Hilfe Konvertierungen, mathematische Berechnungen, Logik, Zeichenfolgentransformationen, Formatänderungen und benutzerspezifische Anpassungen vorgenommen werden können.

Eine Besonderheit stellt hierbei die Domain Value Map dar. Diese ist vergleichbar mit einer Lookup-Tabelle. In ihr können die unterschiedlichen Ausprägungen servicespezifischer Werte hinterlegt und zueinander geordnet werden.

Filterfunktion

Die Filterregeln basieren auf dem Dateninhalt (PAYLOAD) der Nachricht. Hierzu werden entsprechende XPATH-Ausdrücke geprüft. Ist das Ergebnis positiv, werden die Daten an den entsprechenden Ziel-Service übertragen. Die einzelnen Funktionen entsprechen denen der Transformationsregeln.

Übertragungsarten

Für die Ausführung steht die synchrone und asynchrone Übertragung zur Verfügung. Auch diese Bedingung wird als Routing-Regel implementiert. Der Unterschied besteht in der Behandlung der Antwort auf die entsprechende Anfrage und der Fehlerbehandlung.

Synchrone Übertragung

Bei der synchronen Vorgehensweise wird sofort eine Antwort geliefert und im Fehlerfall der gesamte Nachrichteninhalt zurückgerollt. Sind mehrere Services beteiligt, werden diese nicht ausgeführt, auch wenn sie positiv beendet werden könnten.

Asynchrone Übertragung

Bei der asynchronen Übertragung gibt es keine sofortige Rückmeldung und der Nachrichteninhalt wird nicht zurückgerollt. Sobald der Fehler behoben ist, kann die Nachricht wieder erneut übertragen werden. Die Nutzung der asynchronen Übertragung ist immer dann sinnvoll, wenn es mehr als einen Empfangsservice gibt. Alle Services die nicht vom Fehlerfall betroffen sind, werden erfolgreich ausgeführt. Somit ist das Zurückrollen der Nachricht innerhalb des ESB verhindert worden.

Fehlerbehandlung

Zur erfolgreichen Ausführung des zuvor fehlerhaften Services ist es notwendig, die Ursache zu beheben und die Nachricht durch ein „Resubmit“ nochmals nur für diesen zu senden. Dies ermöglicht die Kapselung innerhalb des ESB.

Fazit

Für den Einsatz als Service-Schicht zur Datenübertragung innerhalb einer SOA, ist der ESB aus der Oracle SOA Suite 10g ausreichend.

In der neuen Version 11g ist er als Mediator integriert und nur noch ein Bestandteil der SOA, der sich des neuen OSB (Oracle Service Bus) bedient (siehe Abbildung 2). Dieser besteht im Wesentlichen aus dem Aqua Logic Service Bus in der Version 3.x. Hiermit wird nun ein neues Konzept verfolgt, das in einer der nächsten Ausgaben betrachtet wird.

Klaus Günther (info@ordix.de).