Software Engineering

Open-Source Integration mit ServiceMix: How to Ride a Camel

Die Integration unterschiedlicher heterogener Systeme ist häufig eine aufwendige und schwierige Aufgabe. Claus Ibsen vergleicht Integrationsprobleme in seinem sehr zu empfehlenden Buch „Camel in Action“ mit einem Puzzle. Während Puzzleteile aber dazu gemacht sind, sie zu einem großen Ganzen zusammenzufügen, sind zu integrierende Systeme oft nicht so passgenau aufeinander zugeschnitten. Integrationsframeworks wie Apache Camel adressieren dieses Problem und ermöglichen eine einheitliche Integration von Systemen auf unterschiedlichster technologischer Basis.

Mit einer Einführung in Apache Camel führt dieser Post die dreiteilige Serie zum Thema ServiceMix fort. In dem ersten Blogpost wurde die Laufzeitumgebung des ServiceMix auf Basis einer OSGi Plattform beschrieben. Darauf aufbauend gilt Apache Camel als wohl wichtigster Bestandteil des ServiceMix. Nachdem also die grundlegenden Konzepte des Frameworks vorgestellt werden, sollte dem ersten Ritt auf dem Camel nichts mehr im Wege stehen.

Was ist Camel – vier Beine und zwei Höcker?

Für den außergewöhnlichen Namen des Open-Source Projektes gibt es viele verschiedene Erklärungen. Zum einen ist Camel die Abkürzung für „Concise Application Message Exchange Language“, zum anderen sollen die Projektbeteiligten durch den Konsum von Zigaretten der Marke Camel zu diesem Namen verführt worden sein. Woher der Name auch immer kommen mag, sicher ist, dass Camel als fundierte Grundlage zur Lösung von Integrationsproblemen genutzt werden kann. Nachfolgende Abbildung fasst zusammen, wie die einzelnen Konzepte in Camel (Processors, Components und Routes) zusammenhängen. Diese werden im Folgenden erläutert.

Processors, Components und Routes zusammengefasst

Den Kern des Frameworks bildet eine Routing Engine, die es ermöglicht Regeln für das Routing von Nachrichten zu definieren. So kann beispielsweise festgelegt werden, von wo Nachrichten entgegengenommen, wie sie verarbeitet und wohin sie weitergegeben werden. Die Routing Engine reicht Nachrichten nach definierbaren Regeln weiter. In Camels Sprache zur Definition von Routen wird sich stark an sogenannten Enterprise Integration Patterns (EIPs) orientiert. Diese beschreiben allgemeingültige Lösungsmuster für immer wieder auftretende Integrationsprobleme. Eine Liste der von Camel umgesetzten EIPs findet sich hier.

Die sogenannten Camel Components ermöglichen Verbindungen zu anderen Systemen über unterschiedliche Transportprotokolle beziehungsweise Schnittstellen. Camel liefert bereits 200 solcher Components mit, erlaubt darüber hinaus aber auch die Verwendung von Drittkomponenten sowie die Entwicklung eigener Camel Components für individuelle Lösungen. Camel Components stellen also eine Verbindung zu anderen Systemen dar und bieten einheitliche Schnittstellen über einen Endpoint. Sogenannte Processors verarbeiten Nachrichten zwischen Endpoints, einfache Beispiele wären Nachrichtentransformationen, Filter oder das Nachrichtenrouting.

Routing mit Apache Camel

Im vorigen Abschnitt wurde erläutert, dass eine Route den Fluss einer Nachricht beschreibt. Diese hat ihren Ursprung in einem Endpoint, dem Consumer. Anschließend kann die Nachricht durch Processors verarbeitet werden. Camel bietet unter anderem mit den EIPs eine Reihe vorgefertigter Processors, die in einer Route verwendet werden können. Es ist aber auch möglich eigene Processor Klassen zu erstellen. Zu guter Letzt verlässt die Nachricht die Route über einen weiteren Endpoint, den Producer.

Eine Route in ServiceMix

Diese Art des Routing ist stark durch das Pipes and Filters Architekturmuster beeinflusst. Es löst das Problem, Nachrichten zwischen zwei Endpoints verarbeiten zu können. Ein einfaches Beispiel wären eingehende Bestellungen eines Onlineshops, aus denen über das Filter-EIP diejenigen herausgefiltert werden, die keine korrekten Kreditkarteninformationen enthalten, bevor die Bestellung an einen Endpoint weitergeleitet wird. Die einzelnen Verarbeitungsschritte sind nach dem Pipes and Filters Muster über Channels (auch Pipes) miteinander verbunden.

In Camel können auf unterschiedliche Arten Routing-Regeln definiert werden. Die gängigsten beiden Methoden sind die Java-basierte Domain-Specic Language (DSL) und die Verwendung einer Spring XML Konguration (häug auch Spring DSL genannt). Vereinfacht ausgedrückt handelt es sich bei einer DSL um eine Sprache, die ein bestimmtes Problemfeld (engl. Domain) adressiert und nicht darüber hinausgeht. Das Problemfeld, das von Camels DSL behandelt wird, sind offensichtlich Integrationsprobleme.

Camel Components

Die wesentliche Aufgabe einer Camel Component ist das Bereitstellen von Consumern und Producern, um so die Verbindung zu anderen Systemen zu realisieren. Diese werden, wie oben in der Abbildung zu erkennen ist, in den Routen verwendet. Ein Consumer ist die Quelle des Nachrichtenflusses. Dabei gibt es zwei Arten von Consumer, event-driven und polling Consumer.

Während Consumer als Quelle des Nachrichtenflusses zu verstehen sind, kümmern sich Producer darum Nachrichten am Ende einer Route an andere Systeme weiterzugeben. Gelegentlich werden Producer aber auch innerhalb einer Route als Processor verwendet, die zum Beispiel mit Hilfe anderer Systeme eine Nachricht verarbeiten.

Die einfachste Form einer Component besteht aus nur vier Klassen (Component, Endpoint, Consumer und Producer), die in nachfolgender Abbildung dargestellt werden. Wird von dem Camel Context für die Definition einer Route ein bestimmter Consumer oder Producer benötigt, können diese über eine URI ausgewählt und konfiguriert werden. Über die URI wird von dem Camel Context die entsprechende Klasse identiziert, die das Component-Interface implementiert. Die Hauptaufgabe der Component Klasse ist es, neue Endpoints, abhängig von den Parametern in der URI, bereitzustellen. Eine Endpoint Klasse agiert nun als Factory, erstellt also Consumer und Producer. Die Hauptarbeit der Camel Component, die Interoperabilität zu anderen Systemen zu gewährleisten, wird in den Producer und Consumer Klassen implementiert.

Camel Component Übersicht
Sowohl die von Camel bereitgestellten Components als auch die selbst entwickelten folgen immer diesem Muster. Das ermöglicht die einheitliche Integration unterschiedlicher Systeme auf immer gleiche Art und Weise. Gerade diese Wiederverwendbarkeit macht Camel zu einem interessanten Framework. Wie ein Integrationsproblem mit Apache Camel und OSGi in ServiceMix modular gelöst werden kann, wird an einem konkreten Beispielszenario in dem nächsten Eintrag zu dieser Blogserie beschrieben.

Quelle Titelbild: https://picjumbo.com/camel-tour-in-desert-dubai/