Oracle SOA Suite 11g Mediator vs. Oracle Service Bus (OSB)

Oracle SOA Suite 11g Mediator vs. Oracle Service Bus (OSB)

Oracle SOA Suite 11g Mediator vs. Oracle Service
Bus (OSB)
Guido Schmutz
Trivadis
Bern, Schweiz
Schlüsselworte:
Oracle SOA Suite 11g, Mediator, BPEL, ESB
Einleitung
Mit der SOA Suite 11g wurde der frühere Oracle ESB in die SCA Mediator Komponente
umgewandelt. Damit existiert nur noch ein "richtiger" Service Bus, der Oracle Service Bus
(OSB), welcher nach der BEA Übernahme aus dem Aqualogic Service Bus entstanden ist.
Der Mediator und der OSB besitzen zum Teil sich überlappende Funktionalitäten wie
Transformation, Filterung und Routing. Es stellt sich damit zwangsläufig die Frage, wann,
welche Komponente eingesetzt werden soll. Dieser Vortrag zeigt, wann der Einsatz welcher
Komponente Sinn macht und wie diese in einer SOA kombiniert werden können.
Geschichte der Oracle SOA Plattform
Die erste Version der Oracle SOA Plattform wurde Mitte 2006 mit der Oracle SOA Suite 10g
veröffentlicht. Diese Version war ein Zusammenstellung (Bundling) von verschiedenen
Komponenten, die Oracle zum Teil selbst entwickelt hat, aber insbesondere auch durch
Hinzukäufe erworben hat, wie dies in Abb. 1 dargestellt ist.
Abb. 1: Geschichte der Oracle SOA Plattform (Quelle Oracle)
Im Wesentlichen bestand und besteht die Oracle SOA Suite 10g aus den Produkten
•
BPEL – für die Orchestrierung von Services
•
ESB – für die Integration und Virtualisierung von Services
•
Web Services Manager – für Security und System Monitoring
•
BAM – für das Business Activity Monitoring (Monitoring für den Fachbereich)
Ein wesentlicher Nachteil der Oracle SOA Suite in der Version 10g ist, dass jedes dieser
einzelnen Produkte für den Entwickler ein bisschen anders zu verwenden ist, was sich sowohl
in der Entwicklung aber auch beim Deployment manifestierte.
Mitte 2008 hat Oracle offiziell BEA übernommen und damit aus Sicht SOA einige
interessante Produkte geerbt, wie z.B. der WebLogic Application Server (WLS), der
Aqualogic Service Bus (ALSB) oder aber das Enterprise Repository.
Bemerkenswert war auch, dass mit dem ALSB und dem Oracle ESB, Oracle plötzlich zwei
Service Bus im Angebot hatte. Die Frage, die sich dabei zwangsläufig stellte, war, wann soll
welcher Service Bus eingesetzt werden?
Bereits vor der Veröffentlichung der neuen Version 11g hat Oracle die einzelnen Produkte
neu benannt und insbesondere auch neu positioniert:
•
•
•
BPEL Process Manager – ist und bleibt die primäre Service Komposition,
Orchestrierung und Process Engine
Oracle Enterprise Service Bus (OESB) – alter „ESB“ – Der OESB war der primäre
ESB vor dem BEA Zukauf. Nach dem Kauf von BEA wurde er zurückgestuft und
seine Aufgabe bleibt einzig das Verfügung stellen von Mediator-Services zwischen
verschiedenen SOA Suite Komponenten. In 11g wird der OESB dabei auch zur
Mediator Komponente umbenannt und stellt eine mögliche Komponente innerhalb
eines SCA Composite dar.
Oracle Service Bus (OSB) – war früher bekannt unter BEA Aqualogic Service Bus
(ALSB). Ist neu Oracle’s primärer Service Bus und die bevorzugte Plattform für die
Virtualisierung von Services und Interaktionen mit Services, die extern zur SOA Suite
sind. Zurzeit ist der Oracle Service Bus nur unter BEA Weblogic verfügbar, in
Zukunft sollen aber auch andere Plattformen unterstützt werden. Der OSB ist Oracle’s
Basis für die Weiterentwicklung der Service Bus Funktionalität und kann auch
losgelöst, ohne SOA Suite Umgebung eingesetzt werden.
Oracle SOA Suite 11g
Abb. 2 zeigt den Übergang von der SOA Suite in der Version 10g zur Version 11g, die seit
Juli 2009 produktiv verfügbar ist.
Abb. 2: Von der Oracle SOA Suite 10gR3 zur Oracle SOA Suite 11g (Quelle Oracle)
Eine wesentliche Neuerung von SOA Suite 11g ist die Einführung einer gemeinsamen
Service-Infrastruktur, die über Service Component Architecture (SCA) Standard verwaltet
wird. Dadurch werden die einzelnen Produkte von 10g zu so genannten Service-Engines
innerhalb von SCA. Dies äussert sich in einer wesentlich besseren Integration, was sich vor
insbesondere für den Entwickler bezahlt macht, da nun alles aus einer Umgebung entwickelt
und deployed werden kann.
Der Oracle Service Bus (ex BEA) ist zurzeit noch nicht in der Version 11g verfügbar, die
Version 3.1 lässt sich aber problemlos mit der SOA Suite 11g kombinieren.
Damit ist aber noch nicht beantwortet, wann welche Komponente eingesetzt werden soll und
wie eine sinnvolle Kombination von Oracle SOA Suite 11g und Oracle Service Bus aussehen
könnte.
Welche Komponente soll wann eingesetzt werden?
Um besser beurteilen zu können, welche Komponente für welche Aufgabenstellung eingesetzt
werden sollte, habe ich versucht, die einzelnen Funktionalitäten den Produkten zu zuordnen,
was in Abb. 3 dargestellt ist. Dabei habe ich mich auf die Komponenten BPEL und Mediator
aus der SOA Suite 11g und den Oracle Service Bus (OSB) 10.3 beschränkt.
Abb. 3: Feature Mapping auf BPEL, Mediator und OSB
Es lässt sich leicht feststellen, dass es einige überlappende Funktionalitäten gibt, die bei allen
drei oder aber bei jeweils zwei Komponenten implementiert sind. Ausserdem gibt es viele
Funktionalitäten, die nur genau einer Komponente zugeordnet werden können, d.h. dies sind
die Kernfunktionalitäten bzw. die Exklusivfunktionalitäten.
Die aufgezeigten Funktionalitäten sind nicht alle auf der gleichen Stufe und auch die
Implementierung durch die Komponenten kann unterschiedlich sein, von der einfachen
deklarativen Einstellung bis zur Umsetzung in Programmcode.
BPEL bietet einige typische Funktionalitäten an, wie Process State/Long Running, Process
Orchestration, Human Workflow, Compensation und Parallel Processing. Es kann zudem
festegestellt werden, dass BPEL auch einige typische ESB-Funktionalitäten wie Message
Filter, Message Validation, Message Transformation, Message Routing und Asynchronous
Messaging abdecken kann. Diese Überlappung von BPEL mit dem Service Bus (Mediator
und OSB) sind historisch entstanden und es stellt sich die Frage, ob und wann diese überhaupt
eingesetzt werden sollen oder ob es nicht besser ist, die Aufgaben zwischen BPEL und
Mediator/OSB strikt zu trennen.
Wenn man die Funktionalitäten zwischen dem Mediator und dem OSB vergleicht, dann fällt
auf, dass der OSB viele Features exklusiv besitzt. Dabei handelt es sich genau um die
Unterscheidung zwischen simpler Mediator-Funktionalität und erweiterter Service Bus
Funktionalität. Der Mediator ist quasi der „little service bus“, während der Oracle Service Bus
(OSB) den mächtigen, „high end“ Service Bus darstellt. Funktionalitäten wie Message
Throttling, Service Pooling, Split-Join Pattern, Reliable Mesaging usw. können in grösseren
SOA-Lösungen sehr hilfreich sein, insbesondere wenn es darum geht, externe Services
einzubinden. Daher werden diese exklusiv nur vom Oracle Service Bus (OSB) implementiert.
Der Mediator hat zurzeit zwei Funktionalitäten, die er exklusiv anbietet. Die Cross Reference
Tables und das Value Mapping. Diese sind notwendig, wenn man mit kanonischen
Datenmodellen bzw. –formaten arbeitet und dabei immer wieder Werte vom einen ins andere
Format umwandeln muss. Die Cross Reference Tables können dabei Mappings auf Primary
Keys für Stammdaten unterstützen, während die Value Maps statische Wertumwandlung wie
Währungscode oder Ländercode unterstützt. Diese beiden wichtigen Funktionalitäten sollen
in einer zukünftigen Version auch auf dem OSB verfügbar gemacht werden.
Abb. 4 zeigt grob die wesentlichen Unterschiede zwischen dem Mediator und dem Oracle
Service Bus (OSB) auf.
Abb. 4: Mediator vs. Oracle Service Bus (OSB)
Wann konkret macht nun aber die Verwendung des Mediator und wann die Verwendung des
Oracle Service Bus Sinn?
Verwendung der Oracle SOA-Plattform in komplexerer Architektur
In einer komplexeren Architektur können Mediator und Oracle Service Bus (OSB) sehr gut
kombiniert eingesetzt werden, wie dies Abb. 5 zeigt.
Abb. 5: Verwendung der Oracle SOA-Plattform in einer komplexeren Architektur
Der Oracle Service Bus (OSB) wird dabei auf Unternehmensebene eingesetzt und sorgt für
die Verbindung der unterschiedlichen Systeme im Grossen über den ESB und bindet externen
Services über den „Exposed ESB“ ein. Dies sind nur logische getrennte Service Busse, sie
können physisch durchaus auf der gleichen Service Bus Instanz betrieben werden.
In einer grossen SOA-Lösung ist es sinnvoll, verschiedene SOA Domänen zu bilden, wie in
Abb. 5 als SOA Domäne 1 und Domäne 2 eingezeichnet. Die Domäne 2 ist hier zum Beispiel
mit der Oracle SOA Suite 11g umgesetzt, während die SOA Domäne 1 über eine andere
Technologie implementiert wird.
Innerhalb der SOA Domäne 2 werden die Features der SOA Suite 11g eingesetzt, d.h. zum
Beispiel BPEL und Mediator. Externe Services werden dabei vom unternehmensweiten OSB
konsumiert. Damit wird eine SOA auf Basis von mehreren, entkoppelten und ebenfalls
service-orientierten Domänen erreicht.
Die Service Bus Instanzen eignen sich primär für die Übertragung von einzelnen Meldungen
in geringer Anzahl und auf keinen Fall um ganze Batches von Datensätzen zu übertragen, wie
man dies in klassischen Integrationen oft vorfindet. Sind Batch-Integrationen weiterhin
notwendig, dann lohnt es sich die Service-Orientierte Architektur durch einen Bulk ESB zu
ergänzen. Im Falle von Oracle kann dazu der Oracle Data Integrator (ODI) eingesetzt werden.
Der Einsatz von verschiedenen Service Bus auf unterschiedlichen Ebenen wird auch
Federated Bus Pattern genannt.
Federated Bus Pattern
Dieses Pattern kombiniert verschiedene logische Busse zu einer so genannten Federated Bus
Infrastruktur, wie dies in Abb. 6 dargestellt ist. Das Pattern sieht vier verschiedene Ebenen
vor, jede dieser besitzt seinen eigenen logischen Bus:
Application Level – ein Service Bus je Applikation, mehrere innerhalb einer Domäne
Domain Level – ein Service Bus pro Domäne
Enterprise Level – ein Service Bus für das gesamte Unternehmen
External Level – ein Gateway für das ganze Unternehmen zu den externen Service
Abb. 6: Federated Bus Infrastruktur
Der Mediator eignet sich dabei primär für den Einsatz als Application Service Bus oder aber
als Domain Service Bus. Der Oracle Service Bus (OSB) kann für den Corporate Service Bus
oder den External Service Bus eingesetzt werden, lässt sich aber natürlich auch für die beiden
anderen Ebenen verwenden.
SOA Domänen über unternehmensweiten ESB verbinden
Die SOA Domänen sind natürlich nicht komplett unabhängig voneinander. Um diese aber
möglichst lose miteinander bzw. untereinander zu koppeln, können sie über Publish/Subscribe
Verfahren verbunden werden. D.h. eine SOA Domäne wird wichtige Ereignisse lediglich an
den übergeordneten Service Bus signalisieren und andere SOA Domänen, die sich für das
Ereignis registriert haben, werden daraufhin asynchron benachrichtig (siehe Abb. 7). Es gibt
damit keine 1:1 Koppelung zwischen den beiden Domänen.
Abb. 7: Mehrere SOA Domänen über unternehmensweiten ESB verbinden
Diese Entkoppelung über Pushlish/Subscribe lässt sich mit dem Mediator sehr gut unter
Nutzung des Event Delivery Networks (EDN) realisieren.
Zusammenfassend kann gesagt werden, dass sowohl der Mediator wie auch der Oracle
Service Bus ESB-Funktionalitäten gut implementieren. Der Entscheid welcher Bus
schlussendlich eingesetzt wird, kann einerseits über die geforderten und unterstützten
Features gefällt werden, oder andererseits ob die SOA Suite 11g mit den weiteren
Komponenten BPEL, Rules Engine, Human Workflow, usw. ebenfalls benötigt wird, oder ob
lediglich ein eigenständiger ESB notwendig ist. In der ersten Situation wird sicher auch der
Mediator eingesetzt werden, währendem man in der zweiten Situation eher auf den Oracle
Service Bus setzen wird.
In einer grösseren und komplexeren SOA ist es jedoch sinnvoll, diese über das Federated Bus
Pattern zu kombinieren und sowohl den Mediator wie auch den Oracle Service Bus
einzusetzen.
Kontaktadresse:
Guido Schmutz
Trivadis
Papiermühlestrasse 73
CH-3014 Bern
Telefon:
Fax:
E-Mail
Internet:
+41(0)79-4120539
+41(0)31-9280964
guido.schmutz@trivadis.com
http://www.trivadis.comi