Christian Schneider über Möglichkeiten und Zukunft von Apache Camel

Willkommen zur Apache-Enterprise-Integration-Woche!

Enterprise-Integrationsprojekte gehören zu den komplexesten in der IT-Welt, schreibt Alberto Mijares im Java-Magazin Leitartikel „Agile Enterprise-Integration„. Doch glücklicherweise gibt es in der Java-Welt hochwertige Open-Source-Middleware, die dafür sorgt, dass verschiedene Anwendungen effizient miteinander zusammenarbeiten.

Namentlich hält die Apache-Community ein reichhaltiges Projektangebot bereit, um diese Integrationsaufgaben zuverlässig zu erfüllen: Zu nennen ist das Integrationsframework Apache Camel, die Web Services Suite Apache CXF, der ESB & JBI Container Apache ServiceMix, der Message Broker Apache ActiveMQ oder auch das OSGi-Projekt Apache Karaf.


src=“http://entwickler.com/develop/zonen/magazine/onlineartikel/pspic/picture_file/46/Apache4e92aaf66425a.png?1318236181″ hspace=“15″ vspace=“10″ alt=““>

Eben diesen Integrationstechnologien widmet sich der Apache Integration Day auf der kommenden W-JAX 2011 in München. Zu Gast haben wir zahlreiche Treiber der Projekte, die aus erster Hand berichten, wie man erfolgreich Enterprise-Integrationen mit Apache herstelllt, in welchen Szenarien welche Technologien geeignet sind und welche Erfahrung sie im Umgang mit den Projekten und der Community gemacht haben.

Ein spannendes Thema, auf das wir in den nächsten Tagen auch auf JAXenter den Fokus legen wollen: Läuten wir die Apache-Enterprise-Integration-Woche ein! Was Sie erwartet sind zahlreiche Praxisartikel, Tutorials und Interviews rund um das Thema Apache Integration. Den Anfang machen wir mit Apache Camel und einem Übersichtsartikel über die verschiedenen Open Source Enterprise Service Buses.

In Ergänzung zum Camel-Praxisartikel plaudert an dieser Stelle Camel-Committer Christian Schneider aus dem Apache-Nähkästchen und gibt einen Ausblick auf das kommende Camel 3.0.

Viel Spaß bei der Apache-Enterprise-Integration-Woche auf JAXenter und dem Apache Integration Day auf der W-JAX!


src=“http://entwickler.com/develop/zonen/magazine/onlineartikel/pspic/picture_file/96/Christian_4e92acc8caecd.jpg?1318236028″ hspace=“19″ vspace=“10″ alt=““>

JAXenter: Hallo Herr Schneider! Mit welchen Eckpunkten lässt sich die Camel-Architektur beschreiben?

Christian Schneider: Die Camel-Architektur besteht aus verschiedenen Teilen:

  • Messaging Core: Besteht aus Exchange und Message und Processor. Eine Route ist quasi eine Kette von Processors. Für jeden Durchlauf dieser Route wird ein Exchange durch die Processors geleitet. In jedem Schritt der Route wird ein Processor auf den Exchange angewendet. Der Processor verarbeitet eine „In“ Message und kann eine „Out“ Message erzeugen. Kern der Message ist der Body. Im Gegensatz zu JBI, wo immer mit XML gearbeitet wird, kann der Body einer Message bei Camel ein beliebiges Java-Objekt sein.
  • Routing DSL : Ermöglicht es, Integrationen in sehr kurzer und prägnanter Weise darzustellen. Grundlage für die Java DSL ist das Fluent Builder Pattern. Verfügbare Sprachen sind Java, XML und Scala.
  • Expression language: In der Routing DSL werden oft Ausdrücke benötigt, z.B. xpath(„//secret“). Ein Ausdruck wird gegen einen Exchange ausgewertet. Camel unterstützt eine große Anzahl von Expression Languages.
  • Component, Endpoint: Komponenten sind die Basis für Erweiterungen von Camel. Eine Komponente implementiert spezielle Verarbeitungsschritte oder Integrationen mit der Außenwelt. Camel unterstützt mehr als 50 Komponenten (z.B. jms, http, xslt, jdbc, cxf). Endpunkte werden als URI geschrieben und dienen zur Konfiguration von Komponenten. Der Ausdruck to(„http://server.my.org/myservice„) verwendet die HttpComponent und instanziiert einen Endpunkt zur Kommunikation mit „server.my.org“. In Verbindung mit dem DSL Element „to“ wird ein http client instanziiert, der eine Message an den Server sendet und die Antwort in der Route weitergibt.
  • Interceptors: Interceptors implementieren Cross cutting concerns wie Error Handling, Tracing, Transaktionen. Sie werden ebenfalls über die DSL konfiguriert, können aber potenziell auf alle Knoten der Route wirken.

JAXenter: Können Sie an einem Beispiel illustrieren, wie sich mit Camel klassische Integrationsprobleme lösen lassen?

Christian Schneider: Ein typisches Integrationsbeispiel ist die Anbindung eines Legacysystems an einen Messagebroker. Das Legacysystem exportiert regelmäßig alle Kundendaten als XML-Datei. Die Kundendaten sollen in ein Unternehmensformat übersetzt werden. Jeder Kundeneintrag soll dann einzeln als XML-Nachricht an eine Queue gesendet werden:

from(„file://var/crm/exports“).split(xpath(„//customer“)).to(„xslt:transform_customer.xsl“).to(„jms://queue.customer“)

Die obige Route überwacht ein Verzeichnis und verarbeitet jede neue Datei. Die XML-Daten werden am Element customer in einzelne messages aufgeteilt. Diese werden dann per XSLT in das Unternehmensformat für Kunden übersetzt und abschließend an eine jms queue gesendet. Zusätzlich zu dieser Route wird nur noch die jms Konfiguration, eine Starterklasse und die XSL-Datei benötigt. Ich kenne keine andere Integrationslösung, die dieses Problem mit weniger Aufwand löst.

JAXenter: Enterprise Integration Patterns bilden die Grundlage von Apache Camel. Wie schlagen sich die Patterns in dem Framework nieder?

Christian Schneider: Die Integration Patterns finden sich in der Domain Specific Language (DSL) von Apache Camel. Meines Wissens ist Camel damit das einzige Framework, das die Enterprise Integration Patterns direkt ausführbar macht.

Ein Beispiel ist die folgende Route:

from(„jms:queue1“).delay(1000).filter(xpath(„//secret“)).to(„http://server.my.org/myservice„)

Diese einfache Route enthält gleich mehrere Integration Patterns. „from(„jms:queue1″)“ definiert einen Messaging Endpoint und Event Driven Consumer, der auf der Qeueue „queue1“ lauscht. Die gesamte Route bildet eine Pipeline. Dies kann auch in der DSL explizit geschrieben werden, ist aber nicht notwendig. „.delay(10000)“ definiert einen Delayer, der jede Message um 1s verzögert. „.filter(…)“ definiert einen Filter, der alle Messages aussortiert, die dem Filterkriterium genügen.
Die Camel DSL ist so kurz und prägnant, dass eine Camel Route sehr gut lesbar ist und den Kern der Integrationsaufgabe optimal dokumentiert. EIP-Diagramme lassen sich meistens 1:1 in Camel DSL schreiben.

Die komplette Liste der unterstützten Integration Patterns ist auf der Camel Website verfügbar: http://camel.apache.org/enterprise-integration-patterns.html

JAXenter: Was hat es mit dem Talend Route Builder auf sich?

Christian Schneider: Der Route Builder ermöglicht, Camel Routes grafisch zu erstellen und zu dokumentieren. Die erstellten Routen können dann direkt als OSGi Bundle exportiert und in der Talend ESB Runtime ausgeführt werden. Ein weiteres interessantes Feature ist die visuelle Darstellung von Ablaufstatistiken. So kann eine Route im Route Builder getestet werden, und die durchlaufenden Nachrichten aktualisieren live die Statistiken der einzelnen Elemente der Route. Ziel des Route Builders ist es, die Funktionalität von Camel für Anwender nutzbar zu machen, die weder Java- noch Camel-Experten sind. Man kann sich die Route „zusammenklicken“ und innerhalb weniger Minuten eine ablauffähige Integration schreiben und deployen.

JAXenter: In Ihrer Session „Integration ganz einfach mit Apache Camel“ vom Apache Integration Day geben Sie auch einen Ausblick auf Camel 3.0. Was können wir in Camel 3.0 erwarten?

Christian Schneider: Die Planung der Camel 3.0 Features ist noch nicht abgeschlossen. Daher können sich einige Ziele noch verändern. Einige Eckpunkte sind:

  • Einführung einer Routing Engine: Momentan enthalten die Elemente einer Route ihre eigene Ausführungslogik. Tracing oder Exception handling muss daher beim Erstellen der Route über Wrapper zwischen die Elemente der Route eingebaut werden. In Zukunft soll die Engine diese cross cutting concerns übernehmen. Damit wird es wesentlich einfacher, Interceptorlogik zur Laufzeit zu verändern, und die Laufzeitansicht der Route wird stärker der DSL gleichen.
  • Einführung einer Komponenten-API: Momentan muss der Entwickler einer Komponente immer gegen den gesamten camel-core kompilieren. Die Einführung der API wird die Komponenten stärker von der Camel Runtime entkoppeln. So wird es in Zukunft einfacher, das Innenleben von Camel zu optimieren, ohne dass Rückwirkungen auf existierende Komponenten zu befürchten sind.
  • Erweiterbare DSL: Die Camel DSL ist momentan nicht durch den Nutzer veränderbar. In Zukunft sollen die Nutzer eigene DSL-Elemente zu Camel hinzufügen können, um die DSL stärker an ihre Bedürfnisse anzupassen.
  • Tooling-Schnittstellen: Camel 3.0 wird offene Schnittstellen für Tooling bieten. So arbeite ich momentan zum Besipiel an einer Tracing Schnittstelle für JMX. Eine Schnittstelle für Debugger wird folgen. Talend wird sein eigenes Camel Tooling auf diesen Schnittstellen aufbauen. Durch die Offenheit können andere Anbieter dann auch sehr einfach eigene Toolings anbieten.

JAXenter: Vielen Dank für dieses Gespräch!

Apache Integration Day

W-JAX 2011, Donnerstag, 10. November 2011

Apache-Integrationstechnologien wie CXF, Camel, ActiveMQ oder Karaf haben sich im Middlewarebereich fest etabliert. Sie sind robust, ausgereift und bieten eine beeindruckende Menge an Funktionalität.

Der Apache Integration Day liefert einen Einblick in diese Projekte, direkt von deren Treibern. Dabei werden in einzelnen Sessions technische Details sowie Informationen zu den Roadmaps der Projekte geliefert. Zusätzlich werden Anwender über den konkreten Einsatz der Apache-Integrationstechnologien sprechen und hier die Erfahrung im Umgang mit dem Projekten und der Community schildern.

Die Sessions:
  • Flexibles Service Enabling mit Apache CXF
  • Apache CXF Transporte: Architektur, Design und Customizierung
  • OSGi auf dem Server. Mit Apache Karaf noch besser
  • Integration ganz einfach mit Apache Camel
  • How to build a Integration Application using Talend ESB based on Apache Projects
  • Integrationsprojekte auf dem Weg zur Continuous Delivery

Alle Infos zu den Sessions auf dem W-JAX-Session-Planer!

Christian Schneider ist Open Source Softwarearchitekt bei Talend. Er arbeitet Vollzeit an den Apache-Projekten, welche die Basis des Talend ESB bilden (Camel, CXF, Karaf). In seinen mehr als 15 Jahren Entwicklungserfahrung war er unter anderem für die SOA-Technologie des Stromhandels eines der größten deutschen Entergiekonzerne verantwortlich.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.