Seite 5: ADB & JiBX

Inhaltsverzeichnis

ADB (Axis Data Binding)

Insbesondere durch den großen Erfolg der Webservice-Techniken und die damit einhergehende Verbreitung von XML-Kommunikationsprotokollen entstand eine Vielzahl recht neuer XML-Data-Binding-Lösungen. Manche, aber nicht alle dieser Entwicklungen sind eng mit einem Webservice-Framework verbunden. Hier ist ADB (Axis Data Binding) zu nennen, das Bestandteil von Apache Axis2, aber auch davon unabhängig einzusetzen ist.

ADB basiert auf einem ebenfalls ursprünglich für Axis2 entwickelten Objektmodell namens AXIOM. Eines der Hauptziele bei der Entwicklung von AXIOM war das Erreichen einer guten Performanz. Gleichzeitig sollte es möglich sein, die Verarbeitung von SOAP-Nachrichten sofort abzubrechen, falls eine Nachricht aufgrund des Inhalts ihres Headers abzulehnen ist. Aus diesen Gründen wurde ein StAX-Parser ausgewählt. Gleichzeitig wollte man das Problem lösen, dass mit Stream-Parsern keine so komfortable Navigation möglich ist wie mit DOM. AXIOM löst das mit einer cleveren Idee: Es bietet eine DOM-basierte API als Schale um den StaX-Parser. So können Entwickler zwar wie in einem Baum navigieren, der Baum baut sich jedoch nicht automatisch und im Voraus im Speicher auf, sondern nur nach Bedarf – je nachdem wann und auf welchen Knoten der Entwickler zur Laufzeit navigiert. Will man beispielsweise einen Kindknoten besuchen, weist das Framework den Parser an, den Datenstrom so weit zu parsen, bis die notwendigen Informationen vorliegen. Dieses Vorgehen nennt man "deferred parsing". AXIOM bringt gute Performanz mit einfacher Navigation in Einklang und stellte sich als vielseitig einsetzbar heraus, sodass es inzwischen ein eigenständiges Apache-Projekt ist.

Die von ADB aus einem Schema generierten AXIOM-Klassen enthalten frameworkspezifischen Code für das (Un)Marshalling. Mit einem Schalter des Code-Generators ist dieser Code jedoch in eine externe Hilfsklasse auszulagern, sodass reine POJOs entstehen. ADB arbeitet auch mit Java 1.4.x. Die XML-Schema-Unterstützung ist nicht vollständig, die Entwickler haben sie in der Vergangenheit aber stetig verbessert und sie sollte in der Praxis für die meisten Schemata inzwischen ausreichend sein.

JiBX

Zu guter Letzt ist das bislang noch relativ unbekannte JiBX zu erwähnen. Das Framework unterscheidet sich in einigen Punkten erheblich von den bislang vorgestellten Lösungen. So definiert es die Abbildungsregeln zwischen XML und Java-Klassen mit einer Mapping-Datei, ähnlich wie Hibernate. Hierdurch ist JiBX flexibel: Während andere Frameworks in aller Regel jedes in einem Schema definierte Element oder jeden Typ auf genau eine Klasse abbilden, lassen sich mit Mapping-Regeln beliebige Abbildungen definieren. Zum Beispiel lässt sich der Inhalt eines Elements beim Unmarshalling auf unterschiedliche Objekte verteilen und umgekehrt. Eine weitere Besonderheit von JiBX ist das Umsetzen der eigentlichen (Un)Marshalling-Funktionen per Bytecode-Enhancement. Das bedeutet, dass der Sourcecode vollkommen davon unberührt bleibt. Nach der Kompilierung mit dem Java-Compiler erfolgt jedoch ein zweiter Kompilierschritt. Dabei reichert der JiBX-Compiler die vom Java-Compiler erstellten Bytecode-Dateien um die notwendigen Funktionen an. Die genauen Anweisungen hierfür werden aus der Mapping-Datei entnommen. Moderne IDEs erlauben es, diesen zusätzlichen automatisierten Build-Schritt einmalig für ein Projekt einzurichten. Zur Laufzeit arbeitet der angereicherte Code mit einer JiBX-Runtime-Komponente zusammen, die das Framework in Form einer JAR-Datei bereitstellt.

Ursprünglich brachte JiBX keinen Code-Generator mit, der fachliche Klassen aus einem XML Schema erstellt. Stattdessen waren diese Klassen selbst zu implementieren und eine zugehörige Mapping-Datei zu erstellen. Während das bei Neuentwicklungen hier und da als lästige Fleißarbeit empfunden werden könnte, sind andere Entwicklerteams froh, dass sie bestehende Klassen ohne Änderung wiederverwenden können. So entsteht auch nicht das bekannte Phänomen, "doppelte" Klassen für die gleichen Konzepte zu haben: die selbst implementierten Klassen und jene, die man aus einem Schema generiert. Ebenso können beliebige Vererbungshierarchien implementiert sein, all dies spielt für den Einsatz von JiBX keine Rolle.

Inzwischen gibt es einige neue Tools für JiBX, die es erlauben, von einem XML Schema aus sowohl Java-Code als auch eine zugehörige Mapping-Datei automatisch zu generieren. Alternativ lässt sich anders herum arbeiten und eine Mapping-Datei und ein XML Schema aus bestehendem Code erzeugen.

JiBX punktet bei vielen Kriterien. Es vereint maximale Binding-Flexibilität mit der Möglichkeit, bestehende fachliche Klassen ohne Änderung wiederzuverwenden, und das ohne Code-Abhängigkeiten zum Framework und ohne Probleme mit komplizierten Schema-Features. Das Framework erfordert keine Java-5-Sprachfeatures, und zu alledem schlägt es in puncto Performanz den Großteil seiner Konkurrenz recht deutlich. Aufgrund dieser Stärken erfreut sich JiBX zunehmender Beliebtheit. Als Nachteil sieht man hier und dort, dass das Framework (noch) nicht verbreitet ist und ein vergleichsweise kleines Entwicklerteam es vorantreibt.