Nachrichtenfluss in einer SOA

Die Routing-Regel wird innerhalb der Klasse über normalen Java-Code definiert. In Apache Camel spricht man hier von einer „Java Domain Specific Language“ (DSL). Dies stellt für Java-Entwickler sicher einen charmanten Weg der Definition dar und hat den Vorteil, dass man die Vorzüge der IDE, wie die Code-Komplettierung ausnutzen kann. Dank des Compilers muss man sich auch keine Sorgen bezüglich Tippfehler bei den Routingfunktionsaufrufen machen. Einzig problematisch ist die Address-URI-Syntax zu den einzelnen Komponenten, in der man sich noch vertippen kann.

In Listing 3 wird eine Route vom Endpoint einer ‚file‘-Komponente zu einem zweiten Endpoint der ‚file‘-Komponente definiert. Der angegebene Name setzt sich aus mehreren Bestandteilen zusammen. Der erste Teil beschreibt die zu verwendende Komponente, der zweite Teil ist komponentenabhängig und bezeichnet hier das zu verwendende Verzeichnis. Parameter können über ein Fragezeichen angehängt werden. Sie konfigurieren die Komponente weitergehend.

Die vorliegende Konfiguration führt dazu, dass das Verzeichnis target/test-folder (relativ zum Ausführungsverzeichnis) alle 500 Millisekunden auf neue Dateien geprüft wird. Neue Dateien werden in das Verzeichnis target/test-folder2 verschoben und erhalten dort einen neuen, eindeutigen Namen. Die Datei im Ausgangsverzeichnis wird gelöscht.

package de.dmc.camel;

import org.apache.camel.builder.RouteBuilder;

public class SimpleRouteBuilder extends RouteBuilder {

	@Override
	public void configure() throws Exception {
	
		from("file:target/test-folder?delete=true").
		to("file:target/test-folder2");
		
	}
	
}

Gestartet werden kann die Anwendung über eine einfache main-Methode, die den Spring ApplicationContext initialisiert (Listing 4).

public static void main(String[] args) throws Exception {
	ApplicationContext context = 
	   new ClassPathXmlApplicationContext("application-context.xml");
}

Mit der Java DSL lassen sich aber nicht nur einfache Punkt-zu-Punkt-Verbindungen realisieren, sondern auch komplexere Anforderungen abdecken. Einige Enterprise Integration Patterns unterstützt die „Sprache“ direkt und über eigenen Code  kann die Logik zusätzlich erweitert werden. Über Ausdrücke (Expression) oder Aussagen (Predicate) lassen sich so Java-basiert umfangreiche Regeln definieren (Listing 5).

public void configure() {
	from("seda:a").choice().when(header("foo").isEqualTo("bar")).
	  to("seda:b").when(header("foo").isEqualTo("cheese")).
	  to("seda:c").otherwise().to("seda:d");
}

Die Einbindung von eigenem Code geschieht über Implementierungen des Processor Interfaces von Camel. Diese Processors dargestellt den Nachrichteninhalt verändern und dadurch die Aufgabe einer Mediation zwischen mehreren Diensten übernehmen (Listing 6). Die ausgetauschten Nachrichten sind hierbei an die von JBI bekannten MessageExchange-Objekte angelehnt.

from("seda:start").process(new Processor() {
    public void process(Exchange exchange) {
        Message in = exchange.getIn();
        in.setBody(in.getBody(String.class) + " World!");
    }
}).to("mock:result");

Möchte man die Transformation der Nachrichten nicht direkt über Java-Code steuern, lassen sich diese auch über XSLT, Velocity oder String Templates definieren. Camel bietet hierzu bereits fertige Komponenten an, die über die URI-Adress-Syntax angesprochen werden können. Die XSLT-Komponente lässt sich über folgende Syntax einbinden: xslt:com/acme/mytransform.xsl. Die Angabe ‚com/acme/mytransform.xsl‘ bezieht sich auf ein Stylesheet, das sich im Classpath an der angegebenen Stelle befindet.

Kommentare

Schreibe einen Kommentar

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