Nachrichtenfluss in einer SOA

Nicht nur XML-Daten

Wie im Einstiegsbeispiel erkennbar, ist Camel nicht auf XML-Datenströme begrenzt. Zwischen den Komponenten werden eigene Camel Messages ausgetauscht, die wiederum die Möglichkeit besitzen, normale Java-Objekte zu enthalten. Im obigen Fall wird so ein eingebettetes java.io.File-Objekt zwischen den einzelnen beteiligten Komponenten ausgetauscht und kann weiterverarbeitet werden. Die Bean-Komponente bietet hierzu die Möglichkeit, im Spring-Context angemeldete POJOs direkt aufzurufen bzw. die Nachricht dorthin weiterzuleiten. Das richtige Object-Binding übernimmt hierbei Camel über TypeConverter.

bean:beanName[?methodName=meineMethode]

Die eingetroffenen Nachrichten werden normalerweise direkt von Camel an die Komponenten weitergeleitet und dort verarbeitet. Möchte man die Nachrichten über eine Queue verarbeiten lassen, sodass diese nicht parallel verarbeitet werden, stehen zwei Ansätze bereit. Entweder nutzt man die JMS-Unterstützung des „Elternprojekts“ ActiveMQ oder man setzt die mitgelieferte SEDA-Komponente ein, die eine BlockingQueue darstellt und die Nachrichten über einen Thread Pool an die eigentlichen Consumer weiterleitet. Zwei Komponenten innerhalb eines CamelContextes können so über eine Queue zusammengeschlossen werden.

from("seda:a").to("seda:d");
from("seda:d").to(...);

Integrationslösung?

Mit der Java DSL lassen sich in Apache Camel sehr flexibel Routen und Mediationen definieren, die über Spring leicht in eine eigene Anwendung aufgenommen werden können. Allerdings besitzt Camel keine eigene vordefinierte Laufzeitumgebung, in die die erstellten Routen installiert werden und eventuell zur Laufzeit ausgetauscht werden können. Camel bietet aber Integrationen zu verschiedenen anderen Umgebungen an und es besteht die Möglichkeit, Camel in den Projekten Apache MQ, Apache CXF, Apache MINA und Apache ServiceMix als Routing Engine zu verwenden. Auf diese Weise kann man z.B. von der Laufzeitumgebung eines ESBs wie ServiceMix profitieren, verliert aber nicht die Routingfähigkeiten von Camel.

Fazit

Der Einsatz von Apache Camel als Routing Engine innerhalb des JBI-basierten ESB ServiceMix erscheint auf den ersten Blick als unnötig und übertrieben, da ServiceMix bereits eine eigene Routing Engine mitbringt. Diese bietet allerdings nicht die Flexibilität, die Apache Camel anbietet. ServiceMix kennt noch keine Java-DSL-Unterstützung für die Defintion von Routen und die Mediation muss umständlich pro Route eingebaut werden. ServiceMix stellt auf der anderen Seite einen kompletten JBI Container dar, in dem JBI-Standardkomponenten installiert und ausgeführt werden können. Mit der ServiceMix Camel JBI Service Engine lassen sich über Camel definierte Routen direkt in ServiceMix intsallieren und nutzen. Diese werden wie jede andere JBI-Komponente, die innerhalb des ServiceMix installiert ist, verwaltet und können somit ebenfalls zur Laufzeit ausgetauscht werden. Für aufwendigere Prozesse, die nicht mehr über reine Nachrichtenrouten abgebildet werden können, besteht in solch einer Umgebung die Möglichkeit der Einbindung einer Business Process Engine. Ein entsprechendes JBI-Paket wird z.B. von Apache ODE angeboten und kann in ServiceMix integriert werden.

Das bei Sourceforge gehostete Open-Source-Projekt GASwerk bietet einen solchen SOA Stack an, der die oben genannten Komponenten Apache ServiceMix, Apache Camel und Apache ODE über den Apache Application Server Geronimo zu einer Distibution bündelt. Verfügbar ist ebenfalls ein Beispiel, das einen kompletten Prozess, bestehend aus Camel Route, BPEL Prozess und Web-Service-Anbindung, implementiert.