JEE 5 Architektur

Seminar mit Adam Bien bei OOSE.DE

Gute Architekten zeichnen sich dadurch aus, dass sie - auf Grund eigener Erfahrungen oder einer guten Schulung, wenn es darum geht aus einer Vielzahl von augenscheinlich gleichwertigen Alternativen eine auszuwählen, meistens die richtige treffen.

Verantwortungsvolle Architekten sorgen dafür, dass bei geringsten Zweifeln in einem Versuchsaufbau sichergestellt wird, dass die Auswahl der Zusammenstellung von Alternativen korrekt funktioniert. Das sind dann wohl meistens Architekten, für die kotzende Pferde vor Apotheken kein ungewöhnlicher Anblick sind und sich deshalb lieber selbst davon überzeugen, ob die vielen vollmundigen Versprechungen der Marketing Abteilungen führender auch tatsächlich greifen.

Mit JEE 5 kann man heute höchstens 1 1/2 Jahre Erfahrung haben (wenn man damit begonnen hat, bevor einigermassen robuste Entwickler-Werkzeuge zur Verfügung standen). Meine Erfahrungen erstrecken sich jetzt über ca. 6 Monate und sind durch praktisches Probieren untermauert. Wenn ich so weitermachen, kann es leicht noch einmal 6 Monate dauern, bis ich mir hinsichtlich aller Ecken und Kanten des neuen Systems einigermassen sicher sein kann.

Das ist das Problem, wenn man sich die Aufgabe gestellt hat, ein seit 17 Jahren funktionierendes, auf 20 Jahre alter Software-Technologie basierendes Anwendungssystem aus hunderten von Tabellen und Programmen auf eine neue Plattform zu stellen.

Darum habe ich mir Hilfe geholt und Adam Bien für drei Tage in mein Projekt geholt! Hört sich nicht übel an, nicht wahr? Neee also wirklich, vermutlich würde das mein Budget sprengen!

Aber: Adam Bien hat bei OOSE.DE in Hamburg in der vergangenen Woche ein Seminar abgehalten, welches viele der Probleme in meinem Projekt streifte. Da dieses Seminar in Hamburg nur sehr wenige Teilnehmer hatte, konnten viele individuelle Fragen geklärt werden und es war zeitweise wirklich so, als hätte man Adam persönlich gebucht.

Unterm Strich hat sich bestätigt, dass die Auswahl EJB3 auf JEE5 mit Netbeans und Glassfish absolut optimal ist. Ich möchte nicht versäumen, mich bei dieser Gelegenheit versäumen, Thomas Schütt dafür zu danken, dass er mich in diese Richtung geschubst hat.

Die Informix typischen Probleme lassen sich leider nur durch Work-Arounds beheben. Ansonsten geht es jetzt mit neuem Elan und vielen wichtigen Erkenntnissen weiter.

Informix Toplink Hibernate & Co

Die Informix Adaption in Toplink wirft mit NullPointerExceptions um sich. Ursache ist die Implementierung der - alten - Informix spezifischen Methode, Outer Joins in der Where Clause des Select Statements anzugeben. Genau diese Implementierung ist bei Toplink aber nicht (so gut) getestet, weil dieses Datenbank-Produkt von Oracle für Toplink nicht zertifiziert ist.

Siehe https://glassfish.dev.java.net/issues/show_bug.cgi?id=3574

Verwendet man Hibernate als Persistence Manager, gibt es mit den Outer Joins keine Probleme, weil Hibernate die von Informix schon seit einigen Jahren unterstützte ANSI Syntax für die Generierung der Select-Anweisungen generiert.

Leider habe ich aber mit Hibernate bisher keine Freundschaft schliessen können, weil es damit an anderen Stellen sehr unschöne Exceptions und wenig informativen Text dazu gibt. Wir reden hier - wie gesagt - von Java Code, der ansonsten mit Toplink als Persistence Manager einwandfrei funktioniert.

Richtig Spass macht es, wenn man statt Informix mit Derby arbeitet - da funktioniert alles so wie es soll. Vermutlich würde auch alles mit Oracle sehr gut klappen - leider wird es noch sehr lange dauern, bis die Anwendung soweit portiert ist, dass die Datenbank kurzerhand ausgetauscht werden kann. Vielleicht ist Informix bis dahin auch wieder so gut im Geschäft, dass diese Datenbank zu den für Toplink zertifizierten gehört? (Ich persönlich rechne nicht mehr damit).