Nachrichtenfluss in einer SOA - JAXenter

Nachrichtenfluss in einer SOA

Prozesse mit einer Business Process Management Engine

Eine Alternative zur Prozessumsetzung besteht natürlich in der Verwendung einer so genannten Business Process Management Engine (BPME). Mit speziellen Sprachen werden Prozessabläufe beschrieben und in einer Laufzeitumgebung ausgeführt. Neben proprietären Beschreibungssprachen wie die jPDL von JBoss besteht ein möglicher Einsatz der Business Process Execution Language (BPEL) von OASIS. Der BPEL-Standard wird von einigen kommerziellen Produkten (z.B. IBM WebSphere Process Server, Oracle BPEL Process Manager) aber auch von Open-Source-Alternativen (z.B. Apache ODE, ActiveBPEL) unterstützt und vorangetrieben. Der große Vorteil dieser Beschreibungssprachen liegt sicherlich darin, dass grafische Entwicklungstools angeboten werden, mit denen die Prozesse modelliert und getestet werden können.

Abb. 2: Grafische Darstellung eines Beispiel-BPEL-Prozesses

BPM Engines bieten zusätzlich weit mehr als nur grafische Editoren. Durch die Verwaltung eines Status für die einzelnen Prozesse, können z.B. lang laufende Prozesse und menschliche Interaktionen abgebildet werden. Auch die Überwachung laufender Prozesse gehört zum Standardumfang einer solchen Engine. Mit dem finalen Erscheinen der „WS-BPEL Extension for People“ und der „WS-Human-Task-„Erweiterungen für BPEL im Juni 2007 stehen nun endlich auch Standards für „Human-Workflows“ zur Verfügung. Diese Funktionalität müsste bei einer statischen Message-Routen-Definition aufwändig nachgebaut werden.

Trotz den Vorteilen setzen sich die BPM Engines nur sehr langsam durch und finden noch keine weite Verbreitung. Dies mag sicher auch an der hohen Komplexität der angebotenen Lösungen liegen, die für kleine und mittlere Szenarien überzogen wirkt.

Integration Framework Apache Camel

Unter dem Namen Apache Camel wird bei der Apache Software Foundation ein „Spring-based Integration Framework“ entwickelt, mit dem über XML oder Java-Syntax-Routing- und Mediation-Regeln definiert werden können. Camel ist ein Subprojekt von Apache ActiveMQ und bietet ebenfalls einige Enterprise Integration Patterns zur Umsetzung von einfachen Prozessen an. Zusätzlich zur reinen Routing- und Mediation-Funktionalität besitzt Camel einige Komponenten, mit denen ein Datenaustausch mit Fremdsystemen durchgeführt werden kann.

Mit Camel lassen sich recht elegant übersichtliche Routing- und Mediation-Regeln definieren, mit denen man einen Nachrichtenfluss steuern kann. Dies soll an einem Beispiel deutlich werden. Zentraler Punkt in der Camel-Architektur ist der so genannten CamelContext, bei dem sämtliche Komponenten registriert sind und eine eindeutige Adresse in Form eines URI erhalten ist. Anhand dieser URI können Routingregeln die Komponenten bzw. ihre ansprechbaren Endpoints adressieren. Für einen Einsatz sind wenige Schritte notwendig:

  • CamelContext anlegen und eventuell konfigurieren,
  • Routing-Regeln anmelden und
  • CamelContext starten.

Die Erstellung und Konfiguration des CamelContextes gestaltet sich dank der Spring-2.0-Unterstützung recht einfach. Über das Camel-eigene Element camelContext wird der Context in die Spring Konfiguration eingebunden und kann konfiguriert werden. Die mitgelieferten Komponenten erfordern keine spezielle Anmeldung. Sie werden über einen automatischen Lookup-Mechanismus registriert und können, sofern das entsprechende Archiv im Classpath liegt, sofort verwendet werden.

Die Routingregeln können entweder als XML-Fragment direkt in der Spring-Konfiguration integriert oder über Java-Klassen definiert werden. Eigene Java-Klassen müssen die Basisklasse org.apache.camel.builder.RouteBuilder erweitern und die entsprechende Routinglogik in der configure-Methode bereitstellen. Innerhalb der Spring-Konfiguration muss mit dem Element package das Java Package angegeben werden, in welchem sich die Routing Regeln befinden (Listing 2).

de.dmc.camel
Kommentare

Schreibe einen Kommentar

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