Was ist Serialisierung in Java?

Serialisierung (Serialization) verwendet man in Java, um einen Datenfluss (data stream) so umzuwandeln, dass es in eine Datei geschrieben und über das Netzwerk transportiert werden kann. Oder man speichert die Daten in einer Datenbank, wobei dann niemand den Inhalt lesen kann. De-Serialisierung ist dann das umgekehrte, man nimmt den Datenfluss und baut damit wieder die ursprünglichen Java Objekte.

Dabei muss der ganze Prozess nicht auf der gleichen Maschine stattfinden. Man kann durchaus ein Objekt auf dem Rechner A serialisieren und auf Rechner B de-serialisieren.

Wie markiere ich eine Klasse als serialisierbar?

Eine Klasse muss das Interface java.io.Serializable implementieren, um anzuzeigen, dass die Klasse bzw. die darin enthaltenen Attribute serialisiert werden können. Will man gewisse Attribute von der Serialisierung ausschliessen, verwendet man transient, also etwa:

private transient String name;

Und wie mache ich die eigentliche Serialisierung?

Ich schreibe bewusst von Streams, damit meine ich alle möglichen Java-Streams wie etwa der „FileOutputStream“ oder „ObjectOutputStream“. Jeder Daten-Stream wird nämlich vor dem Schreiben automatisch serialisiert.

Beispiel: Hat man eine serialisierbare Klasse, etwa „Kartoffel.java“ und schreibt dann eine Instanz einer Kartoffel in ein File, werden die Daten automatisch serialisiert (die Namenskonvention sagt übrigens, man soll eine *.ser Datei erstellen).

Dasselbe ist der Fall beim Einlesen der Daten und mappen auf die Kartoffelklasse. Man muss dann aber bedenken, dass Attribute, die als „transient“ deklariert wurden, ja nicht serialisiert wurden und somit keinen Wert erhalten können. Diese Attribute haben dann entweder 0 oder null als Inhalt.

Welche Formate werden in der Realität verwendet?

Meistens ist das Format der Serialisierung entweder JSON oder XML. Das bedeutet nicht, dass JSON Daten in irgendwas wie ABSDFJLKHSDKFJHKJSHDF serialisiert werden und dann wieder zurück – das ist zwar auch möglich, aber in diesem Beispiel mit JSON ist JSON die Serialisierung selber. Das bedeutet, wenn ich ein Java Objekt etwa über das Netzwerk schicke und irgendwo in den Optionen „JSON“ angebe, dann wird dieses Java Objekt vor dem Senden in das JSON Format serialisiert und beim Empfänger wieder zurück-serialisiert.

Hat das was zu tun mit dieser komischen serialVersionUID?

Genau, Eclipse will in einigen Fällen, dass man seiner Klasse eine serialVersionUID vergibt:

/** serialVersionUID. */
private static final long serialVersionUID = 1L;

Diese ist dazu da, damit Java verifizieren kann, dass beim Serialisieren oder De-serialisieren auch wirklich die gleiche Version einer Klasse verwendet wird. Falls dem nicht so ist, wird eine InvalidClassException geworfen. Das bedeutet aber auch, dass man die serialVersionUID jeweils anpassen müsste, wenn man signifikante Änderungen der Klasse vornimmt.

Normalerweise empfiehlt einem Eclipse, eine serialVersionUID zu erstellen, wenn man eine Exception verwendet – Exception implementiert Serializable und braucht daher vorzugsweise eine serialVersionUID.

Am einfachsten wäre es, wenn man bei der serialVersionUID bei 0 startet und immer +1 macht, wenn man etwas ändert, was die Serialisierung beeinflusst – Etwa wenn man ein Attribut hinzufügt oder entfernt.

Tomcat oder Websphere?

Wie viele andere Firmen mussten wir uns an einem Punkt entscheiden, ob wir unsere Infrastruktur von IBM Websphere Applikationsserver auf Apache Tomcat wechseln sollten.

Beide Produkte sind zum Ende des letzten Jahrhunderts entstanden, haben sich aber in verschiedene Richtungen entwickelt. Während Tomcat ein Leichtgewicht geblieben ist und als Open-Source Produkt verwendet werden kann, wurde aus Websphere ein grosses Produkt einer ganzen Gruppe von IBM Produkten, die miteinander zusammenarbeiten.

Websphere ist ein Applikationsserver

Was man oftmals als technischen Unterschied liest ist, dass Websphere ein Applikationserver ist, während Tomcat nur als Servlet Container fungiert.

Ein Java Applikationsserver unterstützt alle Java EE Funktionalitäten. Diese Funktionalitäten erweitern die Standard-Java-Plattform für die Durchführung von internetbasierten Businesstransaktionen. Dazu gehören etwa JTA, EBJs oder JMS.

Bis Java Version 6 musste dabei ein Java EE Applikationsserver all diese Aspekte berücksichtigen. Dies ist heute nicht mehr so, dank dem Konzept von „profiles“ in Java 6. Applikationen werden in Java Applikationsservern im EAR (Enterprise Archive) Fromat ausgeliefert, wobei ein EAR mehrere WAR Dateien beinhalten kann (Eine WAR Datei ist quasi eine Webapplikatikon).

Und Tomcat ist ein Servlet Container

Ein Servlet Container muss nur die Java Servlet und JSP Spezifikation implementieren, welche die Installation von Webapplikationen definiert. Ein Servlet Container kann also genauso eine WAR Datei laufen lassen.

Heutzutage ist es so, dass die Servlet Spezifikation soviele Aspekte von Webtechnologien abdeckt, dass viele kommerzielle Firmen Tomcat als Applikationsserver verwenden.

Enterprise Java Beans sind kein Grund mehr

Lange Zeit war einer der Vorteile von Websphere die volle Unterstützung von Enterprise Java Beans (EJB). Diese Beans stellen einen Weg zur Verfügung, wie Businesslogik in ein einzelnes Objekt gekapselt werden kann. Dies hat sich allerdings mit dem kostenlosen OpenEJB plugin geändert.

EJBs wurden etwa eingesetzt, wenn die Applikation verteilt war, also Zugriff auf Ressourcen auf anderen Maschinen benötigte. Dies ist aber in Zeiten von Webservices oder REST Services kein Pluspunkt für EBJ mehr.

Skalierbarkeit war ebenfalls ein Thema bei EJBs, inklusive Load Balancing oder fail-over Szenarien. Hierfür gibt es aber mittlerweile eine ganze Reihe von Open Source Programmen, die man einsetzen könnte.

Man sieht: Viele der genannten Vorteile wie JMS, JTA, JPA etc. sprechen heute nicht mehr für EJB, wenn man Tomcat und Websphere vergleicht.

Die Framework Landschaft ist gewachsen

Ein weiterer Unterschied ist das Auftauchen von Frameworks wie Spirng, Seam, Hibernate, Grails, Guice oder JRuby on Rails. Mit diesen Frameworks kann man heutzutage die gleichen Ergebnisse erzielen wie mit Java EE. Diese Frameworks wurden oftmals aus dem Grund entwickelt, weil Entwickler unzufrieden waren mit der EJB oder Java EE Implementation und die Weiterentwicklung zu langsam voranschritt.

Ein Anbieter, Performanz und Unterstützung

Der technische Unterschied zwischen Tomcat und Websphere ist mit voranschreitender Zeit geringer und geringer geworden. Mit den richtigen Erweiterungen und Tools steht Tomcat dem Websphere praktisch in nichts mehr nach.

Bei Websphere muss man sich im Klaren sein, dass man auf einen einzigen Anbieter setzt, und dessen Launen vollends ausgesetzt ist. Dadurch, dass Websphere Teil eines grossen Gesamtsystems ist, kann durchaus auch die Performanz darunter leiden. Auch in meiner Erfahrung war besonders die Entwicklungsarbeit mit Tomcat enorm schneller als mit Websphere.

Was man aber nicht übersehen darf: Setzt man auf Websphere, kann man mit der Unterstützung von IBM rechnen sowie auch deren administrative Tools für den Umgang des Servers verwenden. Bei Tomcat muss man sich eher auf die Internet Community verlassen. Zudem gelten vorallem die Websphere Server als sehr stabil – Wobei ich noch nie gehört habe, dass Tomcats instabil sind.

Tomcat mit vielen Vorteilen

Warum setzen bereits über sechzig Prozent der Webentwickler auf Tomcat? Meistens hört oder liest man die gleichen Gründe: Bei Tomcat kann man seine eigene IDE wählen, dass die prorietäre IDE von Websphere zu verwenden. Ein Tomcat Server startet unglaublich schnell, was natürlich der generellen Entwicklungszeit zugute kommt.

Ein Punkt, bei dem Websphere die Nase vorn hat, sind die Möglichkeiten der grafischen Analyse und Verwaltung des Servers. Die Popularität von Tomcat hat aber dazu geführt, dass etwa Produkte wie Tcat diese Lücke füllen.

Natürlich wichtig: Der Preis

Websphere verursacht astronomische Kosten während Tomcat kostenlos und Open Source ist. Das ist der Grund, den ich jeweils am häufigsten gehört habe, um eine Migration zu rechtfertigen. Wenn man zwei Produkte hat, die ähnliche Funktionen anbieten beziehungsweise ein Prjekt zum Ziel führen könnten, ist es schwer, sich für eine sehr teure Lösung zu entscheiden – teuer beim initialen Aufwand sowie jährlichen Lizenzkosten.

Bei Tomcat benötigt es gerade mal die Hardware, auf der der ganze Spass laufen kann und die Kosten für das Einrichten und den Betrieb des Servers.

Der Apple Effekt

Was dazukommt ist ein ähnliche Effekt wie bei Apple: Hat man erst einmal ein Produkt von IBM gekauft, wird man an diesen Anbieter gebunden und kauft bei weiteren Anwendungsfällen höchst wahrscheinlich auch wieder Software von demselben Anbieter – Etwa weil die verschiedenen Programme von IBM gut miteinander harmonieren.

Bei Tomcat hat man schon eine höhere Flexibilität und die Freiheit, die Tools zu nehmen, die man selber für richtig hält. Dann wiederum kann man auch argumentieren, dass die Suche und Einarbeit in neue Tools ebenfalls Aufwand erzeugt, während man bei IBM auf eine eingelebte Produktgruppe zugreifen kann und von IBM sogar noch bei der Einrichtung unterstützt wird.

Mein Fazit: Tomcat = Flexibilität

Wie ich bereits geschrieben habe machte ich sehr gute Erfahrungen bei der Entwicklung mit Tomcat im Vergleich zu Websphere – Besonders beim Punkt Schnelligkeit. Bei einem Websphere Server musste ich jeweils 1-2 Minuten warten, bis er oben war, während es bei Tomcat vielleicht 10-20 Sekunden waren.

Was mich persönlich ebenfalls beeindruckt, ist der eingebettete Tomcat in Produkten, etwa in Spring Boot. Einer Spring Boot Webapplikation kann als einfache JAR Datei erstellt werden und Spring Boot kann diese JAR Datei automatisch auf einer (magischen?) Tomcat Instanz laufen lassen – Ohne dass ich irgendetwas konfigurieren muss (ich bin ein heimlicher Spring Fanboy).

Für Tomcat spricht sicherlich auch die Flexibilität, wenn jemals ein weiteres Produkt auf den Markt kommen würde. Die Hürde, auf das neue Produkt zu wechseln, wäre viel geringer als bei der eingefleischten IBM Familie.