Können bestehende, ausführbare Mediationen auf eine SOA Platform portiert werden? Wann wäre dieser Übergang sinnvoll? Was tragen OSGi und JBI zu einer SOA bei?
Übergang von der Ausführung einzelner Mediationen zum ESB als Laufzeitumgebung für Mediationen
Durch die Implementierung einer unmittelbaren Mediationslösung wird Konnektivität zwischen Anwendungen ermöglicht. Bei geringer Anzahl an zu integrierenden Anwendungen mag die noch sinnvoll sein. Mit zunehmender Zahl der Anwendungen wird der Realisierungsaufwand allerdings rasant steigen.
Ebenso wird es immer schwerer den Überblick über die bestehende Integrationslandschaft zu wahren. Zusätzlich müssen häufig alle Verarbeitungsschritte innerhalb einer Route in einem transaktionalem Kontext gesehen werden. Ebenso soll gewährleistet sein, dass Sicherheitsaspekte (wie zum Beispiel Authentifizierung und Autorisierung) bei dem Aufruf der Services erfüllt sind. Apache Camel stößt hier schnell an seine Grenzen. Um solche Aspekte lösen zu können, empfiehlt sich der Einsatz eines sogenannten ESB’s (Enterprise Service Bus). Neben Apache Servicemix, existieren im Open Source Bereich noch Mule ESB, JBoss ESB, Sun Open ESB und WSO2 ESB. Eine Sonderrolle nimmt hier Eclipse Swordfish ein, welcher sich selbst als verteilten ESB sieht und damit im Gegensatz zu herkömmlichen ESB’s steht.
Im kommerziellen Bereich stehen den IBM Produkten (WebSphere Message Broker, WebSphere Datapower XI-50 und WebSphere ESB), Oracle Service Bus von Oracle, NetWeaver von SAP sowie ActiveMatrix Service Bus und ActieMatrix Business Works von TIBCO gegenüber. Ich möchte nun Apache Servicemix als Stellvertreter für Open Source ESB’s dem IBM WebSphere Message Broker gegenüberstellen.
Apache Camel stellt prinzipiell 2 Klassen zum Management des Deployments von Integrationslösungen zur Verfügung. Eine Route bildet ein konkretes Integrationsszenario ab. Innerhalb eines
Java Programmes wird eine Instanz der Klasse DefaultCamelContext erstellt. Nun kann man dieser mittels der Methode addRoutes() Routen hinzufügen. Diese werden aktiv, sobald die Methode start() des Context-Objektes aufgerufen wird.
Apache Servicemix basiert auf zwei Standards – OSGi und JBI
OSGi
OSGi ermöglicht neue Routen, die in OSGi Bundles zusammengefasst werden zur Laufzeit von Apache Servicemix hinzuzufügen. Die OSGi Bundles können separat voneinander gestartet und gestoppt werden. Jedem Bundle ist ein eigener Classloader zugewiesen. Zugleich werden die einzelnen Komponenten, die Apache Camel zur Anbindung von Anwendungen bereitstellt (z.B. Active MQ-Komponente) einmalig als Bundle installiert. Sie können nun von allen implementierten Routen genutzt werden.
JBI
JBI steht für Java Business Integration und ist ein Standard, der SOA ermöglichen soll. JBI bietetet mit den JBI Binding Components eine Alternative zu den Apache Camel Adaptern an, um Anwendungen anzubinden. Im Gegensatz zu Camel, wird eine mittels Binding Component angebundene Anwendung allerdings an einer zentralen Stelle registriert.
An dieser zentralen Stelle kann später nachgefragt werden ob die gewünschte Anwendung über eine JBI Binding Component ansprechbar ist. Die Binding Components überführen die Ein- beziehungsweise Ausgabedaten einer Anwendung in eine einheitliche Normalized Message Diese Messages weisen zwar alle dasselbe physische Format auf, hinsichtlich der logischen Struktur existieren allerdings immer noch große Unterschiede, Somit ist eine direkte Integration zwischen Anwendungen auf Basis von JBI vorerst nicht möglich. Das bedeutet, dass eine Mediation zwischen den verschiedenen Normalized Messages nötig wird um die Anwendungen miteinander integrieren zu können.
In ihrem Buch Open-Source ESB in Action merken Tijs-Rademakers und Jos Dirksen folgerichtig im Kapitel Routing and Transformation an, dass die zwei wesentlichen Konzepte von Servicemix (OSGi und JBI) keine Vorgaben zu Transformationen und Routing liefern. Dazu wird die Zwischenschaltung einer sogenannten Apache Servicemix Service Engine nötig oder der Einsatz von Apache Camel. Da die Apache Servicemix Service Engine lediglich XSL basierte Transformationen beherrscht, muss häufig auf Apache Camel zurückgegriffen werden. Apache Camel übernimmt somit die Mediation zwischen den beiden Anwendungen. Dazu bilden die über die Binding Components angebundenen Anwendungen jeweils den Start- und Endpunkt einer Mediation. Sie können über den JBI Adapter in Apache Camel direkt angesprochen werden.
Im Gegensatz zur Apache Servicemix Service Engine stellt Apache Camel theoretisch die benötigte Funktionalität bereit um Flatfile Formate in XML beziehungsweise andere Flatfile Formate zu überführen. Allerdings müssen diese Transformationen vollständig ausprogrammiert werden.
Fazit: Für die Anwendungsintegration auf Basis von Open Source existieren gute Ansätze, aber keine Komplettlösungen im Sinne eines kommerziellen ESB
Abschließend möchte ich noch auf ein paar Erfahrungen eingehen, welche ich bei der Recherche für diesen Artikel sammelte. Diese gestaltete sich nämlich als außerordentlich schwer. Der Einstieg in Servicemix war schnell über ein kostenloses progress FUSE ESB/ Apache Servicemix Webinar gefunden. Mit dem Resultat, dass ich nun um noch mehr Fragen reicher war als an Antworten. Für Verwirrung und Frust statt Erleuchtung sorgte besonders die Livedemo.
Der dabei aufgezeigte Entwicklungsprozess schien wenig sinnvoll. Bei dem Versuch das Szenario selbst zu implementieren traten dann diverse Fehler und Probleme auf, die nicht einmal ansatzweise in der Livedemo geschildert wurden. Die Anforderungen bezüglich der Kenntnisse zu Maven, Spring, OSGi und JBI wurden kaum herausgestellt. Also informierte ich mich näher zu den einzelnen Bereichen. Dabei gestaltete sich nicht primär die Einarbeitung in diese Tools als Problem, sondern die Verknüpfung zwischen den Techniken. Sobald mehrere Tools miteinander kombiniert wurden, traten Fehler auf, zu denen kaum Informationen aufzufinden waren. Nach einer weiteren ausführlichen Recherche stieß ich dann auf eine Videoreihe von progress, die zumindest ansatzweise den Entwicklungsprozess darstellte, aber immer noch viele kleinere Probleme ausblendete.
Hier wurde klar, wie aufwändig die Entwicklung von Integrationslösungen mittels der Apache Produkte gegenüber der Realisierung mit dem WebSphere Message Broker ist. Zudem zeigten die Videos natürlich nur auf Servicemix zugeschnittene Szenarien. Eine dritte ausführliche Recherche zum Thema Transformation, dass immer wieder auftauchte und aus meiner Sicht eine bedeutende Rolle spielt ergab dann, das aktuell kein kostenloses Open Source Tooling existiert um schnell komplexe Transformationen zu realisieren. Es existieren lediglich Ansätze wie Smooks, die aufzeigen, dass sich Open Source Anbieter generell dieses Sachverhaltes bewusst sind. So bietet Camel zum Beispiel eine Einbindung von Smooks in bestehende Routen an. Die zweite große Frage die aufkam war, inwiefern ein grafisches Tooling existiert um Flows abzubilden und die Verständlichkeit von Mediationen zu erhöhen. Auch dieser Schwäche sind sich die Open Source Anbieter bewusst.
Vielleicht gelingt es dem Eclipse SOA Tools Platform Project diesen so offensichtlichen Mangel zu beseitigen.
Autor
Wolfgang Schmidt