Enterprise Software und Stabilität Eigentlich sollten Enterprise-Produkte stabil sein. Man will ja nicht bei jedem Versionssprung gleich die ganze Anwendung ändern. Ein Beispiel: Man kann eine existierende Spring 1.0 Anwendung durch Austausch der Bibliothek mit Spring 2.0 laufen lassen, siehe hier. Anderes Beispiel: Man kann in Ruby in 1.8.5. keine Breakpoints mehr setzen, siehe hier oder auch bei InfoQ. Interessanterweise war das Ziel von 1.8.5 höhere Stabilität...

Nun ja, kommt wahrscheinlich überall mal vor und die Implementierung von Breakpoints zu testen ist ja auch nicht vollkommen trivial.  ¶ 13:45 0 comments

  Wie organisiert man Vertrieb? Warum nicht von IBM lernen? Hier die drei geheimen Training-Videos:
eins

zwei

drei  ¶ 10:04 0 comments

  SOA beim Software Engineering Radio In der aktuellen Folge beim Software Engineering Radio sprechen Markus Völter und ich über das SOA. Die Folge gibt es hier mit einem recht schönen Kommentar und das Java Magazin hat es auch schon hier angekündigt.  ¶ 14:02 0 comments

  Spring Trainings Ich werden vom 26.-29.9. ein Spring Training in Hamburg geben und dann vom 21.-24.11. eines in München. Registrieren kann man sich online, noch gibt es Plätze und vor allem auch die Frühbucher-Rabatt...  ¶ 14:28 0 comments

  Hibernate, Spring, Persistenz Auf InfoQ gibt es einen Artikel über die richtige Abstraktion in der Persistenz-Schicht. Leider werden dort mehrere Dinge vermischt.


Zunächst gibt es die Kritik, dass man keine Abstraktion über eine Lösung wie Hibernate bauen sollte, weil man sowieso irgendwann proprietäre Features nutzen muss. Dem stimme ich zu, für Performance-Tuning sind solche Sachen unablässig. Warum allerdings Spring's HibernateTemplate dort als eine schlechte Abstraktion aufgeführt wird, ist mir unklar: Es bietet vollen Zugriff auf die gesamte Mächtigkeit von Hibernate, nur eben eleganter. Und die mangelnde Definition der Semantik des HibernateTemplates ist ebenfalls komisch: Es gibt Dokumentation und im Zweifelsfall auch Code, den man anschauen kann. Übrigens schreitet der Artikel dann fort und behauptet, JPA sei die einzig sinnvolle Abstraktion. Schade nur, dass JPA nicht - wie im Artikel auch angesprochen - alle Features aller Implementierungen standardisiert (was ein Standard nie tut) - hier wird Spring in Zukunft als "Vereinheitlicher" dienen.

Dieser Artikel weißt der Spring Unterstützung für Hibernate immerhin einen Sinn zu, sieht aber auch das HibernateTemplate als nicht sinnvoll, leider ohne Begründung. Es bietet eben einheitliche Exceptions für JDBC und Hibernate, meistens sehr kompakten Code und außerdem ein automatisches Aufräumen der Ressourcen. Warum man das nicht haben wollen würde, ist mir unklar, aber dann kann man immer noch Transaktionen von Spring steuern lassen und sich die Session holen, wie in den Artikeln ausgeführt. Spring zwingt niemanden zu seinem Glück.

Viel interessanter und hier leider nur in Ansätzen ausgehführt, ist jedoch die Frage, wie man überhaupt mit der Persistenz umgehen will. Heutzutage ist Hibernate meistens das Werkzeug der Wahl. Hibernate ist jedoch kein triviales Stück Technologie, d.h. es vereinfachte Dinge nicht bedingt. Wenn man komplexe OO-Logik hat, wird man sich ohne Hibernate schwer tun, sie zu implementieren. Dennoch hat man oft Schwierigkeiten, Hibernate dazu zu überreden, die "richtigen" SQL Statements abzusetzen. Warum dann nicht das SQL selber schreiben? Auch Argumente wie Caching ziehen hier nur bedingt, da man mit iBATIS oder einer AOP-Cache-Lösung auch dies leicht nachbauen kann. Das einzige Argument gegen ein solches Vorgehen ist, wenn man komplexe Logik hat, so dass man von dem transparenten Nachladen von Daten (Lazy Loading) profitiert.

Die eigentliche Frage sollte also sein, ob O/R-Mapper wie Hibernate im Moment nicht überbewertet werden. In vielen Situationen sind andere Lösungen wie Springs JdbcTemplates oder iBATIS einfacher und effizienter. Man muss ja O/R Mapper nicht gleich als ein Vietnam bezeichnen.  ¶ 09:02 1 comments

  29 Jahre PC Auch in den "normalen" Tageszeitungen ist das Thema "25 Jahre PC", was aber genauer eigentlich 25 Jahre IBM PC heißen müsste, denn den Apple II, Commodore PET, Tandy TRS-80 usw. als persöniche Compueter gab es schon länger. Lesenswert auf jeden Fall heise: Hätten wir dich so vermisst? Der PC wird 25 mit einem Hinweis darauf, dass es zum Erscheinen des IBM PC von Xerox schon Rechner mit grafischer Benutzeroberfläche gab. Wenn man 1977 (Commodore PET, Apple II, TRS 80) ansetzt, haben wir mittlerweile 29 Jahre PC ...  ¶ 21:15 0 comments

  Objektorientiert auf Englisch? Und? Wie lautet die Übersetzung für "objektorientiert". Richtig, asset-related. Nachzulesen hier.

PS: Wie schon in einem Kommentar zu lesen, kommt die richtige Übersetzung (object-oriented) aber auch zurück. Eigentlich fand ich es nur lustig, dass selbst dieser Begriff mehrdeutig ist.  ¶ 15:04 2 comments

  Neues auf InfoQ Auf InfoQ gibt einen Artikel, der recht gut zu dem AOP-Thema der letzten Postings passt, was auch kein Wunder ist, weil er von Adrian Colyer kommt, der ja bei uns dieses Thema verantwortet.

Bei O'Reilly gibt es dann noch ein Blog-Eintrag, der sich mit Spring-Vorurteilen beschäftgt...

Viel Spaß beim Lesen!  ¶ 11:06 0 comments

  Neues von Apple... Tja, VMWare für den Mac war nicht die einzige Neuheit. Außerdem wird es Virtual PC von Microsoft nicht mehr für den Mac geben....

Dafür gibt es als Nachfolger für den G5 jetzt den Mac Pro. Mac OS X 10.5 hat jetzt eine Time Machine, eine Art globales Undo, das dazu auch noch cool aussieht und bei dem es mir unklar ist, wie es überhaupt technisch funktioniert. Und virutelle Desktops namens Spaces gibt es auch - ein Feature, dass ich eigentlich schon unter X11 nicht genutzt habe, aber lassen wir uns mal überraschen. Gesehen haben muss man die Demo zu Core Animation, sehr coole Sache.

Oh, und neben Tomcat und JBoss wird die Server Version auch Ruby on Rails enthalten.

Also: Kleinere Verbesserungen, aber nichts wirklich dramatisches. Und ich habe anscheinend die Chance verpasst, mir zum Abschied von den PowerPC Prozessoren noch einen G5 zu kaufen.  ¶ 14:44 0 comments

  VMware für den Mac Jetzt ist es klar: VMware kommt auf den Mac, wie man hier nachlesen kann. Ein weiterer Grund für einen Intel Mac....  ¶ 13:07 0 comments

  Nochmal: AOP Ein Kommentar zum letzten AOP-Posting (Danke für das Feedback!) kritisiert, dass es noch keine Best Practices zu Thema AOP gibt. Dem muss ich natürlich widersprechen...

Dabei könnte ich erstmal auf unser AOP-Training hinweisen, das diese Themen behandelt, aber solche billige Werbung erspare ich mir lieber...

Mein Kollege Adrian Colyer, der sich mittlerweile schon eine Ewigkeit mit AOP beschäftigt und zuvor z.B. an der Einführung von AOP bei IBM u.a. in den Middleware Bereich gearbeitetet hat, schägt ein Verfahren vor, wie man AOP einführen kann. Durch das Verfahren wird auch das Design-Thema klar: Er schlägt vor, als ersten Schritt Aspekte zu definieren, die bei z.B. aus Layering Gesichtspunkten heraus verbotene Operationen (siehe hier) als Compiler-Error klassifizieren. Als nächsten Schritt sieht er dann die klassischen technischen Aspekte wie Tracing, Profiling usw, die bei AspectJ auch in Development und Production Aspekte eingeteilt werden. Erst dann kommt Aspekt-orientierte Analyse und fachliche Aspekte. Zu diesem Thema hat Ivar Jacobson auch schon ein Buch geschrieben (immerhin der Erfinder der Use Cases...) und es gibt auch noch ein zweites Buch in diesem Bereich (siehe unten). Also gibt es sogar im Bereich AOP Analyse bereits publizierte Best Practices.

Diese Diskussion bezieht aber noch nicht Spring ein und durch Spring ändert sich hier nochmal einiges. Ohne AOP kann man nämlich keine nicht-triviale Spring-Applikation bauen. Security, Transactions usw. bauen alle darauf auf und es gibt auch eine breite Vielfalt an vorbereiteteten technischen Aspekten (Tracing, Performance Monitoring), die man nutzen kann. Daher ist durch Spring der erste Schritt zur Adaption von AOP die Benutzung von Spring, bei der man ohne AOP eh nicht auskommt. Das Schreiben eines eigenen Aspekts ist ebenfalls recht einfach und auch in der Online-Doku nachzulesen. Daher gibt es hier eigentlich auch keine Barriere: Spring ohne AOP macht keinen Sinn und selber Aspekte schreiben ist recht einfach. Man muss es nur tun...

Das interessante ist nun, dass man bereits mit diesen technischen Aspekten zum Teile ganze Layer einsparen kann, weil man eben Security, Transactions und auch Exception-Handling nicht mehr in jeder Klasse ausprogrammieren muss, sondern es zentral irgendwo als Aspekt macht. So gibt es Beispiele, in denen es ganze Layer gibt, die nur für die Remote Aufrufe die Themen Security, Transactions und Konvertierung der Exceptions behandeln und dabei einen signifikanten Anteil des Gesamtcodes darstellt, weil man eben für jede Remote zugreifbare Funktion nochmal dasselbe hinschreibt. Nur mit AOP oder ähnlichen Hilfsmitteln kann man das zentralisiert implementieren und das ist wirklich kein Hexenwerk. Deswegen glaube ich, dass man nur mit AOP den Don't-Repeat-Yourself-Imperativ in statisch typisierten Programmiersprachen umsetzten kann und halte AOP für eine wesentliche Basis-Technologie.

Zweifel habe ich im Bereich aspekt-orientierter Analyse. Meine Erfahrung ist, dass auch objekt-orientierte Analyse noch nicht flächendeckend eingeführt ist, so dass es fraglich ist, ob man hier schon in den Bereich Aspekt-Orientierung vorstoßen will, wenn man Objekt-Orientierung noch nicht vollständig umgesetzt hat.

Meiner Meinung nach hat man schon bei der Beschränkung von AOP auf technische Aspekte ein großes Produktivitätspotential. Diesen Bereich hat die Software-Entwicklungs-Community auch gut verstanden und setzt es spätestens seit EJB 1.0 auch so um - schließlich sind Transaktionen und Security dort als eine Art Aspekt implementiert, auch wenn niemand es damals so genannt hat und vollwertige AOP-Lösungen auch mitttlerweile wesentlich mächtiger sind.

Also schauen wir mal - immerhin bietet Spring 2.0 einen einfacher Einstieg in AspectJ, so dass Spring 2.0 die Einstiegsbarriere für AspectJ eliminiert. Bei der Popularität von Spring kann es sehr gut sein, dass dadurch auch AspectJ sich einer deutlich breiteren Benutzer-Basis erschließt.



  ¶ 11:51 2 comments

  JPA Anomalie? Bisher ist die Java Persistence API JPA als ein sehr sinnvoller Teil von JSR 220 wahrgenommen worden. Erstaunlich, dass es dennoch komische Effekte gibt. Beispiel: Man hat einen Employee, der AnnualReviews hat. Die AnnualReviews haben keine Referenz zurück auf den Employee (was ja auch OK ist). Auf DB-Ebene würde ich persönlich es so bauen, dass man eine AnnualReview-Tabelle hat, die einen Fremdschlüssel auf den Employee hat. Ich halte die Modellierung für recht offensichtlich. JPA sagt dazu im Standard, dass ein JoinTable entsteht, der die Beziehung abbildet, also Fremdschlüsselbezeihungen zu beiden Tabellen hat. Dadurch hat man eine Tabelle mehr und beim Navigieren eine Tabelle mehr im Join. Wäre das ganze in beide Richtungen navigierbar, würde JPA das ohne Join Table auf der Datenbank implementieren. Komische Sache.  ¶ 16:06 0 comments