Standards von Opensource ESB's

    Wissensbeitrag

    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.

    Schlösser für optimales IAG

    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

    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
    GeschäftsführerX-INTEGRATE Software & Consulting GmbHKontakt