Artikel

 
Januar 2009 | Artikel

Open-Source-Framework Smooks: Transformers

(Link zum Artikel: http://www.it-republik.de/jaxenter/artikel/2098)

Optimus Prime & Co transformieren in einer SOA

Text: 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.
Teil 1   Teil 2   Teil 3   

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.

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
  1. <smooks-resource-list
  2. xmlns="http://www.milyn.org/xsd/smooks-1.1.xsd"
  3. xmlns:csv="http://www.milyn.org/xsd/smooks/csv-1.1.xsd">
  4. <csv:reader fields="firstname,lastname,address, group"
  5. separator=";"
  6. skipLines="1"/>
  7. </smooks-resource-list>

Teil 1   Teil 2   Teil 3   

Anzeige

Kommentare

Gravatar Tom Fennelly 29.01.2009
um 10:52 Uhr
Hi Markus. Excuse me for not being able to respond in German, but thank you for writing an article on Smooks.

If I could, I'd like to point out a small, but very important, inaccuracy. It's in the following statement:

"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."

This is not 100% accurate and may lead people to believe that Smooks can only work by holding the complete message in memory. This was the case with earlier versions of Smooks (earlier versions only supported DOM internally), but is not the case since v1.0.

Smooks v1.0 added a SAX based filter (we will probably be adding StAX in the future). From a pure usability perspective, this typically makes no difference (just a simple config parameter) to the end user/developer because all Smooks components support working under both the DOM and SAX filters e.g. Java Binding, Templating, Scripting etc work exactly the same under both filters. What it does mean is however that Smooks can process a message (of many different types) as a stream of events (i.e. not a big internal document), allowing you to use Smooks to process huge gigabyte sized message - transforming, splitting, routing etc.

Once again, thanks for taking the time to write a very interesting article on Smooks :)
#zitieren
Gravatar Markus Demolsky 29.01.2009
um 11:49 Uhr
Hi Tom,

I am appreciate to get positive response about the article and thank your for the clarification. If Smooks holds the hole object graph in memory the processing of gigabyte sized messages will not be working with that performance as Smooks does it yet.

Thank you again for your response
#zitieren
Gravatar Maurice Zeijen 29.01.2009
um 12:04 Uhr
Hallo Markus,

Vielleicht verstehst du Tom verkehrt. Er meint das den Objektbaum NICHT ganz im Speicher gehalten wird. Wenn SAX in Smooks benutzt wird, in Kombination mit der Javabean Cartridge dann wird nur ein klein teil der Objektbaum im speicher gehalten. Beispielweise wenn du ein Dokument hast mit ein Liste von Bestellungen und du möchtest jeder Bestellung separat nach einen Endpoint routen dann wird nur die Objektbaum von ein Bestellung im Speicher gehalten. Wenn Smooks anfangt mit der nächst Bestellung dann wird der vorherige Bestellung ersetzt.

Mit freundliche grüße,
Maurice Zeijen
#zitieren
Gravatar Markus Demolsky 29.01.2009
um 12:44 Uhr
Hi,

dass war mir nach Toms Erklärung klar, dass nur ein Teil im Speicher gehalten wird und nicht der ganze. Aber dank deinen Beispiel ist jetzt alles 100%ig klar.

Danke & Schönen Tag
Markus
#zitieren
Gravatar Steff 12.04.2009
um 20:09 Uhr
Hallo,
was mich interessieren würde:
Was macht Smooks "besser" als Apache Cocoon? Beide verwenden doch eine ähnliche interne Logik? Oder anders gesagt, warum sollte man anstatt Cocoon, welches doch schon ziemlich ausgereift ist, das "Risiko" eingehen und Smooks verwenden?

Danke für die Antwort.

Gruß
Steff
#zitieren

Anzeige

zurück zum Seitenanfang