Ex-ML - JAXenter
Die flinke Feder

Ex-ML

Bernd Fondermann

Technologien sind wie Prominente: Wenn man sie noch gar nicht richtig kennt, werden sie hochgejubelt. Sind sie dann etabliert und haben den Gipfel der höchsten Relevanz vermeintlich überschritten, wird der Gülleeimer rausgeholt und über ihnen ausgeschüttet. Und da der Schreiber dieser Kolumne keinesfalls in den Ruf kommen will, alles immer nur gut zu finden, hat er sich das beste Opfer für einen Verriss ausgesucht, das es im Java-Umfeld gibt. Eine Technologie, die nicht so beliebt ist, dass er damit auf pure Ablehnung stieße. Die nicht am Boden liegt, sodass es pietätlos wäre darüber herzuziehen. Eine Technologie, für die jeder ein gesundes Maß an Grundverachtung hegt, und über die man sich auch mal wieder richtig ärgern möchte.

Ich rede vom zweitbekanntesten Kind aus einer wilden Ehe zwischen SGML und dem W3C-Konsortium. Dem Bruder der erfolgreichen und umtriebigen, aber etwas leichten Schwester HTML. Ich rede von XML [1].

Ja, es muss raus: XML ist auf dem absteigenden Ast. Auch die Bestrahlung mit heftigen Dosen von WS-* und das tägliche Reinigen mit SOAP können das nicht verbergen.

Zu den Fakten. Seien wir gnädig und lassen einmal die delikate Tatsache beiseite, dass XML ein Kind mit seiner eigenen Schwester gezeugt hat (XHTML). Vergessen wir die Unmengen an einsam zurückgelassenen DTDs; das kann man XML wirklich nicht anlasten. Es ist etwas anderes.

Auf der vergangenen JAX-Konferenz im Mai verkündete Jürgen Höller, der Chefentwickler des Spring Frameworks, dass sich eine Spring-Anwendung in der kommenden Version fast ohne XML konfigurieren lässt. (Die Ausnahme ist JPA.) Alle Einstellungen lassen sich über Annotationen durchführen, insbesondere die Angaben, die klassischerweise in der web.xml landen.

Im Build-Prozess spielt XML seit wir die Makefiles hinter uns gelassen haben eine dominierende Rolle, sei es traditionell bei Ant oder jüngst bei Maven. Doch auch hier gibt es mittlerweile Alternativen, z. B. Rake [2] oder Gradle [3]. Aber lassen Sie uns nicht auf das Thema Groovy kommen, das hebe ich mir für den nächsten Verriss auf.

Am stärksten ist der Verdrängungsprozess bei den Web-Frameworks zu merken. Hier tritt immer öfter JSON [4] auf den Plan. JSON ist eine Untermenge von JavaScript, in der alle Ablauflogik rausgenommen wurde. Es bleibt nur die Objektnotation, daher auch der Name JSON als Kurzform für „JavaScript Object Notation“. Ein JSON-Konstrukt sieht ganz schlank und rank zum Beispiel so aus:

{ 
  id: 323299, 
  groups: ["admin", "user", 42], 
  props: { 
    name: "first last", 
    birthday: null,
    female: true 
  }
} 

Geschweifte Klammern deklarieren Objekte, die gleichzeitig Maps sind. Arrays sowie die einfachen Datentypen String, Boolean, Number und die Abwesenheit eines Wertes (Null) werden ebenfalls unterstützt. Einige dieser Features müssen mit XML mühsam nachbebaut werden.

Für JSON spricht ein weiteres Argument: Wird es auf dem Application Server generiert und als Ergebnis im Rahmen eines AJAX-Calls zurückgeliefert, kann es nahtlos von der Browser-JavaScript-Engine weiterverwendet werden. D. h., in diesem Fall müsste es eigentlich AJAJ Call heißen, für Asynchronous JavaScript And JSON. Das X steht nämlich für – richtig! – XML. Im Browser und auf dem Server wird also dieselbe Datenbeschreibungssprache gesprochen. Meine Erfahrung zeigt, dass sich Java-Objektstrukturen sehr organisch als JSON darstellen lassen, insbesondere unter Verwendung des einzigartigen Jackson Frameworks [5]. Bei XML klappt das nicht so kanonisch.

Ein interessanter Fall ist auch Apache CouchDB [6]. CouchDB ist eine dokumentenorientierte Datenbank, die semistatische serverseitige Views bietet. Semistatisch heißt, dass bei Änderungen an einem Dokument neu entschieden wird, wie die von diesem abhängige Views sich ändern – und nicht etwa zur Abfragezeit. Der CouchDB-Server nutzt zur Definition dieser Views JavaScript. Und so ist es gar nicht weiter verwunderlich, dass das CouchDB-Projekt schon in seiner Anfangsphase von XML zu JSON gewechselt ist. Das bedeutet: Die CouchDB-Schnittstelle, eine HTTP-Server, spricht JSON.

In dem Maße wie JavaScript auf dem Server beliebter wird (node.js [7] als Stichwort), wird auch JSON als Datenformat im Aufwind bleiben.

Doch nur weil ein neues Kind auf dem Spielplatz aufgetaucht ist, heißt es nicht, dass der bisherige Liebling keine starken Freunde mehr hat. Jedoch gibt es noch andere Anzeichen, die man zumindest als Indiz für einen Bedeutungsverlust deuten kann: Der XML-Poweruser hat ein ganz besonderes Werkzeug in seiner Kiste: XSLT. Dies ist eine Transformationssprache, die – selber in XML formuliert – XML-Dokumente in neue XML-Dokumente (oder jedes andere Format) überführen kann. Nun, ich weiß nicht, ob Sie XSLT schon einmal eingesetzt haben. Ich leider schon. Gott sei Dank aber nicht allzu lang. Der Grund ist: Zu kompliziert, zu komplex, die Syntax ist grauenvoll (XML ist für die Darstellung von Algorithmen nur sehr eingeschränkt geeignet).

Apache Xalan [8] ist eine bekannte XSLT-Implementation. Und diesem Projekt ist die Community abhanden gegangen. Braindead. Für die Innovationskraft von XML spricht das nicht, und für XSLT schon gar nicht. Wenn Sie möchten, dass Xalan weiterlebt, wäre mein Hinweis: Engagieren Sie sich im Projekt.

Für die meisten Anwendungsfälle braucht man von XML nur die Kernfunktionalität. Wo alle XML-Register gezogen werden, ist jedoch im Bereich SOAP. SOAP ist der Albatros unter den XML-Spezifikationen: Man wundert sich jedes Mal, dass eine SOAP-Anwendung sich überhaupt in die Luft erhebt [9]. Web Services leiden unter Featuritis und dem Überspezifizierungssyndrom.

Dan Diephouse (früher Entwickler von Apache ServiceMix und im Apache WS-Projekt [10] engagiert) entschuldigt sich in seinem Blog [11] für das Propagieren von Web Services: „Web services – do people use those any more? We’ve doing a ton of stuff with JAX-RS and our customers seem to have made the switch for the most part too. I apologize for helping propogate WSDL and SOAP in the past :-)“.

So viel zu XML. Natürlich darf man Berichte über das Ableben von XML nicht zu ernst nehmen. Und schalten Sie auch demnächst wieder ein, wenn es dann an dieser Stelle JSON an den Kragen geht.

Bernd Fondermann (bernd[at]zillion-one.com) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt a. M. und Member der Apache Software Foundation. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop oder Lucene und bietet unter zillion-one.com einen Big Data Hosting Service an.
Geschrieben von
Bernd Fondermann
Kommentare

Schreibe einen Kommentar

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