Seite 2: Vergleichskriterien 1

Inhaltsverzeichnis

Vergleichskriterien

XML-Schema-Unterstützung: Die meisten Anwendungen verwenden Schemata, um die Struktur gültiger XML-Dokumente zu definieren. Diese sind insbesondere nützlich, wenn empfangene Dokumente oder Nachrichten auf ihre Gültigkeit zu prüfen sind. XML Schema ist nicht nur eine komplexe, sondern auch eine mächtige Spezifikation. Der Standard kann unter anderem Datenstrukturen definieren, die in gängigen Programmiersprachen keine direkte Entsprechung haben. Als Grundregel gilt daher: Je komplizierter man ein Schema definiert beziehungsweise je mehr Funktionen der XML-Schema-Spezifikation man verwendet, desto schwieriger ist es, ein Framework zu finden, das alle diese Features unterstützt.

Code-Generierung: Viele Frameworks arbeiten so, dass ein Code-Generator von einem XML Schema aus Klassen erzeugt, welche die im Schema definierten Typen und Elemente repräsentieren. Wenn entweder ein Framework oder die Zielsprache einzelne im Schema verwendete Konstrukte nicht unterstützt, sind Schwierigkeiten vorprogrammiert. Scheinbar einfache Konstrukte wie choice oder union sind bekannte Problemquellen. Manche Frameworks verfolgen dagegen alternative Ansätze ohne Code-Generierung. In diesen Fällen können oder müssen (das ist Geschmackssache) Entwickler die fachlichen Klassen selbst implementieren.

Code-Abhängigkeiten: Generiert man Code aus einem Schema, lohnt ein genauer Blick auf das Ergebnis. Hier offenbaren sich große Unterschiede zwischen den Frameworks. In manchen Fällen handelt es sich bei den generierten fachlichen Klassen um reine POJOs (Plain Old Java Objects). Das (Un)Marshalling lässt sich "von außen" durchführen, entweder mit dem Framework oder mit ebenfalls generierten Hilfsklassen. Andere Frameworks erzeugen dagegen keine reinen POJOs, sondern fachliche Klassen, die zusätzlich eine Menge frameworkspezifischen Code enthalten. Es kann sich beispielsweise um Factory-Methoden handeln oder eben um Code, der das (Un)Marshalling von Instanzen direkt in den jeweiligen Klassen implementiert. Will man das verwendete Framework eines Tages austauschen, bedeuten solche Code-Abhängigkeiten einen erheblichen Mehraufwand.

Vererbung: Eng verknüpft mit dem vorausgegangenen Punkt ist die Frage, inwieweit ein verwendetes Framework den Entwickler beim objektorientierten Design einschränkt. Generiert man fachliche Klassen aus einem XML Schema, lassen sich Vererbungshierarchien nur bedingt einsetzen. XML Schema erlaubt es zwar, Typen von anderen abzuleiten, auf diesem Weg lassen sich jedoch nur Properties in einer Superklasse unterbringen, allerdings kein fachlicher Code. Zudem sind die generierten Klassen bei manchen Lösungen grundsätzlich von einer Framework-Klasse abgeleitet, was fachlich bedingte Vererbung ausschließt.

Natürlichkeit der API: Wurde ein Framework gewählt, das die fachlichen Klassen generiert, so möchten man diese Klassen dennoch genauso verwenden können wie ganz normale POJOs. Das gilt auch dann, wenn die generierten Klassen frameworkspezifischen Code enthalten. Insbesondere bedeutet dies, dass neue Instanzen mit new-Operatoren zu erstellen und ihre Properties über get/set-Methoden zugänglich sind. Bei manchen Frameworks ist das nicht der Fall. Als Folge muss man sich bei der Anwendungsentwicklung an teilweise recht unnatürlich anmutende APIs gewöhnen.

Java-1.4-Support: Ein weiteres Auswahlkriterium dürfte in vielen Umgebungen sein, ob ein Framework unter Java 1.4.x einzusetzen ist. Noch immer sind ältere Versionen von Applikationsservern recht weit verbreitet, die maximal Java 1.4 unterstützen. Insbesondere solche Frameworks, die Annotationen verwenden, scheiden in diesen Umgebungen daher aus.