Standards von Opensource ESB's

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?

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.

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.

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.