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

Transkript

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

2 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:

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

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

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

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

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

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

9 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

10 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: +41(0) Fax: +41(0) Internet: