Optimus Prime & Co transformieren in einer SOA

Open-Source-Framework Smooks: Transformers

Markus Demolsky

Ein Sattelzug, der plötzlich die Gestalt eines menschlichen Roboters annimmt. Ja, wir reden hier von Optimus Prime, dem Anführer der Autobots. Genauso wie bei den niedlichen Automobil-Transformern aus dem Weltall können auch in der Datenverarbeitung unerwartete Transformationsaktionen nötig werden, wenn z.B. aus einem Java-Objekt plötzlich ein XML- Dokument entstehen soll. Im Zeitalter Service-orientierter Architekturen werden eine Menge unterschiedlicher Systeme miteinander verbunden. Und da die einzelnen Systeme jeweils ihre eigene Sprache sprechen, wird ein Dolmetscher als Vermittler zwischen den Systemen immer dringender gebraucht. In vielen SOA-Landschaften finden wir bereits einen Enterprise Service Bus, der die Integration der einzelnen Systeme steuert und zentral verwaltet – und dabei oft die Hilfe von Transformern in Anspruch nimmt.

Bei Integrationsprojekten werden die Beteiligten sehr schnell mit der Frage des zu verwendenden Datenaustauschformats konfrontiert. Als erste Antwort fällt meist der Begriff XML. Warum ist das eigentlich so? Ist es, weil XML von jedem gelesen werden kann oder weil es rund um XML eine Menge an Tools und Standards (XSD, XSLT, XPath, .) gibt? XML ist in der Tat eines der beliebtesten Formate für den Austausch von Nachrichten. Es gibt jedoch Branchen, bei denen die Formate für bestimmte Daten gesetzlich geregelt sind, beispielsweise im Transport- oder Speditionsbetriebsektor. Hier haben sich die branchenspezifischen Subsets (z.B.: EDITRANS, EDIFOR,.) von EDIFACT durchgesetzt. Was soll man aber mit einem EDIFACT-Dokument anfangen, wenn man XML benötigt? Schnell ist ein kleines Transformierungsprogramm geschrieben, das das EDIFACT-Dokument für die spezielle Anwendung ins XML-Format bringt. Allerdings wird ein solches Transformierungsprogramm meist nur für diesen einen Anwendungsfall anwendbar sein. An zukünftige Änderungen oder die Wartung wird in den meisten Fällen nicht gedacht.

Unter Transformation versteht man das Überführen von Daten eines Formats X in ein Format Y. Zum Beispiel muss eine CSV- oder eine EDIFACT-Datei nach XML transformiert oder ein XML-Dokument auf einen Java-Objektbaum abgebildet werden. Sehr häufig werden für Transformierungen unterschiedliche Mapping-Verfahren angewandt. Bei solchen Mapping- Verfahren wird versucht, die Abbildung der Überführung von X nach Y in eine Konfigurationsdatei auszulagern, vergleichbar mit dem O/R Mapping, welches das Mapping von der Objektwelt auf die relationale Welt übernimmt. Dabei wird definiert, welche Tabelle auf welches Objekt und welche Spalten in der Tabelle auf welche Attribute im Objekt gemapped werden. Das gleiche Prinzip lässt sich auch auf die Transformierung von Daten anwenden. Eigentlich wäre es ideal, wenn Transformer auch die Möglichkeit böten, mit Mapping-Konfigurationen die Datentransformierung zu steuern.

Dieser Artikel stellt zunächst das Open Source Framework Smooks vor, welches für das Arbeiten mit unterschiedlichen Datenformaten verwendet werden kann (Abbildung 1). Der Aspekt der Transformierung zählt zu den wichtigsten Merkmalen eines Enterprise Service Bus (ESB). Wäre es nicht interessant, ein Framework wie Smooks in einen ESB als „Transformations-Engine“ zu integrieren? Das hat sich auch die Entwickler-Gemeinde von JBoss ESB gedacht und verwendet Smooks als Standard Transformation Engine in ihrem ESB. Auch für den Open-Source-ESB Mule gibt es eine Smooks Extension, die es Mule-Usern ermöglicht, auf die unzähligen Funktionen von Smooks zurückzugreifen. Nach der Vorstellung des Smooks-Frameworks geht dieser Artikel deshalb noch näher auf das Smooks-Modul für Mule ein.

Abb. 1: Smooks Überblick
Was ist Smooks?

Zum Zeitpunkt der Erstellung des Artikels stand Smooks in der Version 1.1 zur Verfügung und auch die verwendeten Beispiele in diesem Artikel beziehen sich auf diese Version. Smooks wird sehr oft als Transformationstechnologie gesehen, doch eigentlich kann Smooks weit mehr als nur Daten transformieren, zum Beispiel beherrscht es auch das Routing von Nachrichten. Smooks beschreibt sich selbst als „Structured Data Event Stream Processor“. Es werden also Daten aus einer beliebigen Quelle, die in einem beliebigen Format vorliegen, eingelesen, durch eine Visitor-Logik geschleust, um dann ein Ergebnis zu erzeugen:

Source –> Strukturierter Event Stream durch die Visitor-Logik –> Ergebnis

Andere Lösungen wie DOM oder SAX kommen zwar zu ähnlichen Ergebnissen, doch geht Smooks noch einen Schritt weiter und ermöglicht diesen Prozess auf unterschiedliche Datenformate anzuwenden, wobei das System der Einstellung bzw. der Konfiguration immer das gleiche ist. Zudem kann der Transformer per XML konfiguriert werden. Wird eine XML-Datei mit SAX verarbeitet, hat man als Entwickler die Möglichkeit, auf spezielle SAX-Events zu reagieren, wie etwa startTag, endTag, startDocument etc. Die Entwicklung von speziellen SAX-Event- Handlern kann teilweise ganz schön mühsam sein. Deshalb hat man sich überlegt, wie man solche Verarbeitungen vereinfachen kann. Im Grunde setzt Smooks bei der Idee von SAX/DOM an und erweitert diese um eine umfangreiche Visitor-API, die es ermöglicht, nicht nur XML- Dokumente, sondern auch EDI, JSON, CSV, Java oder andere von Smooks bereits unterstützte Formate leichter zu verarbeiten. Hier ist aber zu erwähnen, dass Smooks jedes Format intern in ein XML-Dokument transformiert und auf dieser Basis dann fortfährt. Wenn also EDIFACT auf Java- Objekte abgebildet werden soll, dann wird auch EDIFACT zuerst in ein XML-Dokument transformiert und dieses dann in Java-Objekte überführt.

Wird ein Format noch nicht unterstützt, muss eine benutzerdefinierte Visitor-Logik benutzt werden. Dies erfordert die Implementierung von einigen Smooks Schnittstellen. In diesem Artikel werden wir den CSV und EDI Prozessor genauer unter die Lupe nehmen. Smooks unterstützt bereits mehrere Datenformate, welche Out-Of-The-Box verwendet werden können, wie beispielsweise XML-To-XML, XML-To-Java, Java-To-XML, EDI-to-Java, CSV-to-XML, und einige mehr.

Transformierung von Daten

Die Verarbeitung von CSV-Dateien wird von Smooks bereits unterstützt und verlangt nur die passende Konfiguration, wie Listing 1 zeigt. Um den CSV-Handler zu verwenden, muss der Namespace des CSV-Moduls eingebunden werden. Zunächst definieren wir die Felder, welche wir von der CSV-Datei einlesen möchten (firstname, lastname, address, group). Der Separator gibt an, mit welchen Zeichen die einzelnen Felder voneinander getrennt sind. Hier wird sehr häufig der Strichpunkt als Trennzeichen gewählt. Mit dem skipLines-Attribut kann angegeben werden, wie viele Zeilen zu Beginn ignoriert werden sollen. Es kann ja vorkommen, dass die CSV-Datei mit einer Kopfzeile ausgestattet ist, welche wir aber als Daten nicht benötigen.

Listing 1: CSV-Reader in Smooks
Geschrieben von
Markus Demolsky
Kommentare

Schreibe einen Kommentar

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