Heutige Firmen-IT-Services sind nur noch in den seltensten Fällen «monolythische» Applikationen, die mehr oder weniger alleine und ohne Interaktion mit anderen Systemen ihre Aufgaben erfüllen. Viel wahrscheinlicher ist es, dass jeder IT-Service mit einer Vielzahl an anderen IT-Systemen interagieren muss. Sei es, dass der Webshop mit der Datenbank und dem ERP, dem Lagerhaltungssystem und dem Mailserver Daten austauschen muss oder dass das CRM- mit dem ERP-System, der Knowledge Base und der Dokumentenverwaltung interagieren können soll.
Grundsätzlich gibt es historisch gesehen verschiedene Strategien, wie man solche heterogenen Anwendungsszenarien integrieren kann. Typischerweise wird man in der Praxis eine dieser vier Varianten finden:
- Integration über gemeinsame Dateien – eine Anwendung schreibt eine Datei, eine andere liest sie.
- Verwendung einer gemeinsamen (relationalen) Datenbank.
- Integration über Remote Procedure Calls, also Aufruf von Methoden der anderen Anwendung.
- Integration über nachrichtenorientierte Middleware (MOM), wie beispielsweise über das JMS-Protokoll.
Die ersten drei Varianten haben zum Teil erhebliche Nachteile. Die Integration über Dateien ist ein Anachronismus. Sie skaliert beispielsweise schlecht, muss von einer Seite gepollt und über geteilte Dateisysteme abgewickelt werden, was sicherlich keine Strategie für eine moderne Architektur ist. Auch die Integration über gemeinsame Datenbanken hat oft erhebliche Nachteile. Wie schon im letzten Artikel über ActiveMQ und JMS (InfoWeek 14/2007) erwähnt, versucht man heute, eher «in Komponenten» zu denken und Systeme so weit wie möglich voneinander zu entkoppeln. Kommuniziert wird dann über plattformunabhängige Protokolle. Dies erleichtert die Wiederverwendbarkeit der Komponenten, verbessert die Ausfallsicherheit und erleichtert auch Fail-over- und Load-Balancing-Szenarien. Nicht zuletzt ermöglicht eine Entkopplung über nachrichtenorientierte Middleware auch ein Monitoring des Gesamtsystemverhaltens und die Integration von Services, die «ausser Haus» angeboten werden, beispielsweise bei Zulieferern.
Die dritte Option, RPCs, sind oft ebenfalls noch eine vernünftige Strategie. Sie kommen vor allem dann zum Einsatz, wenn Komponenten ohnehin auf derselben Plattform wie Java entwickelt wurden und sie prinzipbedingt eher eng gekoppelt sind. RPCs, die über Web Services abgewickelt werden, können zudem auch über MOM abgewickelt werden. Damit kann man den Vorteil des «einfacheren» RPC-Musters mit der stabilen Grundlage eines Message Broker kombinieren. Dies hat noch einen weiteren Vorteil: Kommunikation über Netzwerke ist immer fehleranfällig (Nachrichten können beispielsweise verlorengehen), und auch andere Aspekte wie beispielsweise Authorisierung und Authentifizierung will man nicht manuell implementieren. Genau in diesem Bereich können Message Broker einige Arbeit abnehmen.
Abstraktion und Patterns
Der Trend in der Enterprise-Architektur geht also klar den Weg hin zu lose gekoppelten, Service-orientierten Architekturen, die oft über MOM abgewickelt werden.
In den letzten Jahrzehnten haben sich hier bestimmte Integrationsmuster (Patterns) herauskristallisiert. Eines der bekanntesten Bücher in diesem Umfeld ist «Enterprise Integration Patterns» von Gregor Hohpe (ISBN 978-0-32-120068-6), der Architekt bei Google ist. In diesem Buch fokussiert er sich vor allem auf asynchrones Messaging und beschreibt eine Reihe von «Mustern», die in derartigen Anwendungen häufig zu finden sind.
Zunächst definiert er einige grundsätzliche Begrifflichkeiten: Eine «Message» ist ein «atomares» Datenpaket, das über einen «Channel» von einem Sender zu einem oder mehreren Empfängern gesendet wird. Dieser «Zustellprozess» kann nun über mehrere Schritte ablaufen, und dabei können verschiedene Dinge mit der Nachricht geschehen:
- Sie kann gefiltert werden.
- Es kann spezifisches Routing der Nachricht in der Middleware stattfinden.
- Es können Transformationen durchgeführt werden. Die Nachricht könnte also von einem Format in ein anderes konvertiert oder mit Daten angereichert werden.
In jedem dieser Bereiche wurden nun eine Vielzahl an häufig vorkommenden Muster identifiziert und beschrieben. Als Beispiel sei das sehr wichtige Routing herausgegriffen. Dabei können unter anderem folgende Muster auftreten:
- Content-based Routing: Je nach Inhalt der Nachricht wird sie an bestimmte Empfänger weitergeleitet (siehe Beispiel im Kasten).
- Filter: Es können Nachrichten nach bestimmten Kriterien gefiltert werden und Empfänger damit genauer selektieren, woran sie konkret interessiert sind.
- Nachrichten können gesplittet werden. Eine Bestellnachricht könnte beispielsweise in Einzelnachrichten pro bestellten Posten, Lieferadresse und Rechnungsinformation aufgeteilt werden.
- Nachrichten, die zusammengehören, können wieder aggregiert werden.
Weiter existieren Transformations-Patterns, sogenannte «Channel Decisions», mit denen sich festlegen lässt, ob es sich beispielsweise um eine Punkt-zu-Punkt-Verbindung handelt oder um ein Publish-Subscribe-Modell mit mehreren Empfängern. Die Endpoints können verschiedenste Eigenschaften haben, und zuletzt gibt es häufig Aspekte des Systemmanagements zu bedenken: Man möchte vielleicht aus Wartungsgründen oder zur Fehlersuche Kanäle «abhören» (Wiretap Pattern) oder Proxies verwenden.
Camel-Architektur
Implementierungsfragen
Die Kenntnis von Pattern und den oben genannten Prinzipien ist bereits eine gute Voraussetzung für die Erstellung einer leistungsfähigen und flexiblen Architektur. Dennoch: Von der Architektur zur Implementierung ist es oft noch ein steiniger Weg. Speziell in diesem Kontext, wo eine Vielzahl an Technologien und Protokollen zum Einsatz kommen kann.
Nun gibt es verschiedene Frameworks und Tools, die die Implementierung der Enterprise Integration Patterns (oder jedenfalls einiger dieser Patterns) deutlich erleichtern sollen. Der Enterprise Service Bus Codehaus Mule implementiert beispielsweise einige der von Hohpe beschriebenen Patterns.
Ein sehr interessantes neues Projekt ist auch Apache Camel, das ein Subprojekt von ActiveMQ ist. Camel bietet eine Vielzahl an Komponenten an, mit denen der Entwickler auf abstraktem Niveau interagieren kann (siehe Kasten «Eine Auswahl wichtiger Camel-Komponenten»), wodurch man sich beispielsweise nicht mit den «Untiefen» von JMS auseinandersetzen muss.
Diese Komponenten werden über Endpoints angesprochen und können dann innerhalb des Camel-Frameworks mit verschiedenen Prozessoren «verdrahtet» werden (siehe Abbildung «Camel-Architektur»). Camel kann also Daten von verschiedensten Quellen beziehen, entsprechende Patterns anwenden, diese beispielsweise transformieren, ändern und mit verschiedensten Prozessoren Routing und Filtering definieren und dann an bestimmte Empfänger senden.
Camel verspricht damit, dem Entwickler bei der Implementierung von vielen der Enterprise Integration Patterns unter die Arme zu greifen. Es definiert dabei eine domainspezifische Sprache, mit der unter anderem Routings und Filter von einem Endpoint zum anderen beschrieben werden können. Da Camel auf dem Spring-Framework aufbaut, können einerseits Komponenten über Dependency Injection konfiguriert werden. Andererseits steht alternativ zur Java-Syntax auch eine Spring-XML-Syntax zur Verfügung.
Camel kann grundsätzlich «stand-alone» in beliebigen Java-Umgebungen eingesetzt werden. Da Rollen-basierte Mediation und Routing sicherlich eine Kern-Kompetenz von Camel sind und Camel weiter als JBI-Komponente eingesetzt werden kann (JBI ist ein Standard für ESB-Komponeten und wird im nächsten Artikel dieser Serie näher beleuchtet), ist Camel aber auch eine ideale Komponente im Apache ServiceMix Enterprise Service Bus.
Insofern kann Apache Camel, auch wenn es noch recht jung ist, insbesondere als JBI-Komponente im freien Enterprise Service Bus Apache ServiceMix in Zukunft eine wichtige Rolle spielen und die Entwicklung von Anwendungen im Enterprise-Integration-Umfeld spürbar einfacher machen.
Der Autor
Alexander Schatten (alexander@schatten.info) ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien.
