Datum
22.07.2011
Dieser Beitrag wurde verfasst von:
Im Rahmen einer Schulung zu dem Thema „Einführung in die Apache Integrationslösungen“ beschäftigte ich mich intensiv damit, wie Wissen zu den Produkten Apache ActiveMQ, Camel, CXF und ServiceMix möglichst gut aufbereitet und effizient vermittelt werden kann.
Ich entschied mich dafür zu jedem der vier Produkte, mit einem einführenden theoretischen Teil zu beginnen und das Gesagte darauf folgend mit einem praktischen Übungsteil und Live-Demos abzurunden. Aufgrund des hohen Funktionsumfangs der vorgestellten Produkte, lag der Schwerpunkt im praktischen Teil darauf, anhand eines konkreten Beispiels allgemeine Vorgehensweisen beim Umgang mit den Apache Produkten aufzuzeigen.
Praktische Anwendung im Kundenalltag
Neben der Klärung essenzieller Begriffe wie Message Oriented Middleware, Webservices und Pipes-and-Filter Architektur konnte ich bei der Einschätzung von Apache Camel in Kombination mit Apache ServiceMix gegenüber klassischen, kommerziellen ESB’s auch meine Erfahrungen aus dem Umgang mit dem IBM WebSphere Message Broker einbringen, um deutlich die Grenze zwischen Apache basierter und auf kommerzieller Software aufsetzender Integrationslösung zu ziehen. Dabei wurde dem Kunden deutlich, dass Apache Camel als Mediationsframework nicht immer eine ausreichende Abstraktionsgrundlage für den Umgang mit Mediationen bietet, zum Beispiel wenn komplexe Datentransformationen manuell programmiert werden müssen.
Archtitektur – Fragen und Entscheidungen
Hat man sich erst einmal für das Apache Produktportfolio entschieden, müssen unmittelbar darauf wichtige konzeptionelle Entscheidungen getroffen werden, wie zum Beispiel die Wahl des Deploymentmodus.
Hier ist Erfahrungswissen essenziell, denn die Produktdokumentationen treffen nur vage Aussagen die ein manuelles Prüfen erfordern oder liefern sogar Fehlinformationen aufgrund eines veralteten Standes.
Dies zeigte sich exemplarisch bei der im Workshop aufkommenden Frage, ob Camel Routen-Instanzen bei einem Standalone Deployment automatisch skalieren beziehungsweise ob Camel Routen als OSGi Bundle oder JBI Component deployt werden sollen.
Da der Kunde bereits in der Vergangenheit eine auf dem JBI Container Apache ServiceMix basierte Integrationslösung realisiert hatte, war letztere Frage für den weiteren Verlauf des Workshops aber weniger relevant.
Fazit
Zusammengefasst wurde deutlich, dass die Verwendung offener Standards wie OSGi und JBI in Kombination mit einer Domain Specific Language zur Beschreibung von Mediationen als Pipes-and-Filter Architektur nicht Garant für eine hochqualitative und leicht wartbare Integrationslösung ist.
Autor
Wolfgang Schmidt