Spring und der Spring Day auf der JAX
Im Rahmen der JAX findet auch dieses Jahr ein Spring Day statt. Einige der Vorträge drehen sich dabei auch um Architekturfragen wie:
- Technologien sind keine Architektur (Papick Garcia Taboada - pgt/ adminSight)
- Domain-driven Design mit Spring (Christian Dupuis - Accenture)
Weitere Themen sind:
- Spring & OSGi (Bernd Kolb - kolbware, Martin Lippert - akquinet agile GmbH, Gerd Wütherich - comdirect Bank AG)
- Spring und Java EE 5 (Christian Dupuis - Accenture)
- Spring and MDA (Peter Friese, Gentleware, Jürgen Höller, Interface21)
- Acegi (Mike Wiesner - Interface21)
Spring Lead Developer Jürgen Höller (Interface21) gibt außerdem einen Überblick über die neuen Features in Spring 2.1. Weitere Infos gibt es
hier.
In der Hauptkonferenz gibt es noch mehr Vorträge im Bereich Spring:
- Message orientierte Architecturen mit Spring (Jürgen Höller - Interface21)
- Architecture Management am Beispiel Spring (Jürgen Höller - Interface21)
- Spring 2.0 and Beyond (Rod Johnson - Interface21)
- Simplifying Enterprise Applications with AOP and Spring 2.0 (Rod Johnson - Interface21)
- Acegi without Spring (Mike Wiesner - Interface21)
- Persistenz mitSpring (Eberhard Wolff - Interface21)
- Spring Power Workshop (Eberhard Wolff - Interface21)
- Objektorientiertes Enterprise Java mit Spring und AspectJ (Eberhard Wolff - Interface21)
Interface21 wird auch einen Stand haben, wo man sicher auch Jürgen oder Rod treffen kann! Mehr Informationen gibt es auf der JAX Web Site:
http://jax.de/ .
Vielleicht trifft man sich!
Refactoring-Episode bei SE-Radio
Hier gibt es die neue Folge von SE-Radio - in dieser reden Martin Lippert und ich über Refactoring. Viel Spaß beim Zuhören!
Mac OS X: Betriebssystem der Wahl...
Als Betriebssystem mit Unix-Kernel bietet Mac OS X natürlich hervorragende Qualitäten. Letztes Wochenende verabschiedete es sich so, dass mir nur die Wahl blieb, den Rechner auszuschalten. Na ja, Rechner wieder eingeschaltet und - Computer fährt nicht wieder hoch. Hm. Rechner in Verbose-Mode hochgefahren - irgendwas von wegen "Filesystem is read-only". Schön. Also: Single-User Mode. Dankenswerterweise gibt es da auch gleich eine Anleitung, wie man das File-System mit read-write nach einem
fsck mounten kann. Gesagt - getan. Ergebnis "invalid sibling link" und nichts von wegen, dass das Filesystem jetzt wieder read-write wäre. Hm. In diesem Zusammenhang ist die Manual-Page von fsck_hfs auch nicht sehr ermutigend:
BUGS
fsck_hfs is not able to fix some inconsistencies that it detects.
Das bedeutet in letzter Konsequenz: "Hey, Dein Filesystem ist halt hin. Ich kann aber nix machen. Sorry." Anscheinend ist beim Runterfallen des Betriebssystems irgendetwas in den Verzeichnis-Strukturen verloren gegangen. Ein
fsck -r, dass die Verzeichnisse wieder neu anlegt, brachte auch nicht. OK, also ein echtes Problem. Und, nein, ich kann meinen Laptop nicht ernsthaft am Sonntag abend neu installieren, wenn ich am Montag beim Kunden sein will - trotz Backup. Dauert einfach zu lange.
Lösung war dann, das MacBook an meinen G4 im Firewire-Target-Mode zu hängen, so dass er sich wie eine Firewire-Festplatte verhält und von dort aus mit
DiskWarrior 4 reparieren zu lassen. Verluste: Bookmarks und ein VMWare PC-Image, aber keine Arbeit. Ufff. Wie man sieht, Mac OS X bietet die höchste Sicherheit für die Daten.
Labels: Mac OS X
Globalisierung
Woran merkt man, dass man in einer internationalen Firma arbeitet?
- Man arbeitet in Deutschland.
- Bestellt die Visitenkarten in den Niederlanden
- Von dort aus wird man nach Kanada verwiesen
- Dort werden sie gedruckt
- Und man bekommt sie in Miami
JDBC Innovation in JDK 6
Wie man
hier nachlesen kann, wird uns JDK 6 einige neue SQLExceptions geben. Das ist erstmal gut. Leider sind die SQLRuntimeExceptions, die mal geplant waren, inzwischen wieder aus der Spezifikation verloren gegangen. Das ist auch nicht wirklich verwunderlich, weil man durch diese Exceptions das Problem hatte, dass auf der einen Seite die checked SQLException steht, die man fangen muss, und auf der anderen Seite die unchecked SQLRuntimeException, die man nicht unbedingt fangen muss - das macht das Leben nur bedingt einfacher. Grundsätzlich sollten technische Exceptions aber RuntimeExceptions sein, weil man sonst die Anwendung dazu zwingt, auf technische Fehler zu reagieren, was sie nur in Ausnahmefällen kann. RuntimeExceptions sind besser geeignet, weil man sie auch in einen generischen Exception-Handler behandeln lassen kann, der z.B. wegen NullPointExceptions sowieso da sein sollte.
Dafür sind die Exceptions bei JDBC jetzt also genauer ausdifferenziert - wenn die Treiber denn mitmachen. Leider betriffft das nur JDBC, wenn man also mit Hibernate auf die Datenbank zugreift, bekommt man für dieselbe Fehler-Situation eine andere Exception.
Letztendlich kommt auch der zitierte Artikel zu dem Schluß, dass man dennoch Spring nutzen sollte. Warum? Weil
- Die Exceptions RuntimeExceptions sind
- Sie bei jeder Persistenz-API (Hibernate, JDBC...) gleich sind
- Außerdem eine Integration verschiedener Persistenz-APIs in einer Transaktion möglich sind
Und dann gibt es noch Dinge wie
NamedParameterJdbcTemplate die das Leben weiter vereinfachen.
JDBC ohne Spring ist einfach keine gute Idee. Die interessante Frage ist nun, was das für JDBC heißt. Meiner Ansicht nach kann im JDBC-Standard selbst kaum noch sinnvolle Arbeit geleistet werden. Wenn man sowieso nicht mit JDBC direkt arbeiten kann, sondern eine Abstraktion wie Spring JdcbTemplate verwendet, macht eine Verbesserung der APIs keinen Sinn. Die neuen Features von JDBC 4 zur automatischen Umwandlung von Anfrage-Ergebnissen in Objekte, die eher in die Richtung von iBATIS gehen, sehe ich daher eher kritisch. Bei den Exceptions kann man wegen der Abwärtkompatibilität nicht viel machen, RuntimeExceptions zusätzlich einzubauen ist kaum sinnvoll. Der große Erfolg von JDBC ist, dass es JDBC-Treiber für praktisch alle Datenbanken gibt und JDBC daher eine gute Basis für all die anderen Java-Persistenzlösungen bieten kann.
Interface21 ist auf dem Radarschirm der Analysten
Hier gibt es auf Seite 9 einen interessanten Artikel von Michael Goulde, Senior Analyst bei Forrester. Er sagt, dass Interface21 das Open Source Business Modell hervorragend versteht - danke für die Blumen! Interessant ist vor allem, dass der Artikel sich nicht auf die technischen Qualität von Spring bezieht, die schon häufig von verschiedenen Blickwinkel heraus betrachtet worden ist, sondern es geht um das Geschäftsmodell. Das Produkt ist aus seiner Sicht nur ein Punkt. Die beiden anderen sind die Community und schließlich Customer Engagement. Der Autor empfiehlt sogar, dass Modell zu studieren und gegebenenfalls auf andere Open Source Projekte und Firmen übertragen kann.
Labels: Business Model, Interface21, Open Source, Spring
AOP ist zu kompliziert!
AOP geht leider immer noch der Ruf voraus, zu kompliziert zu sein. Das Thema hatte ich
schon mal am Rande aufgegriffen.
Es ist zunächst schlicht so, dass AOP eine Basis für Enterprise-Anwendungen bildet. Schon in EJB gab es Unterstützung für Security und Transaktionen und der notwendige Code wurde zwischen den Interfaces des EJBs und der Implementierung eingebaut. Das Problem bei diesem Ansatz war, dass es keine Möglichkeit gab, eigene Dinge analog zu Security und Transaktionen einzubauen. EJB 3 bietet hier zwar einen Interceptor-Mechanismus, aber der führt dazu, dass man an jeder Bean eine Konfiguration für den Interceptor vornehmen muss oder aber der Interceptor bei jeder Bean zuschlägt - dann muss man selber zum Beispiel abfragen, ob die Bean eine passende Annotation trägt.
Es geht hier also zunächst darum, eine vernünftige und allgemeingültige Basis für die Implementierung technischer Aspekte zu schaffen. Und in AOP / AspectJ sind mittlerweile 10 Jahre Forschung und Entwwicklung geflossen - was könnte also besser geeignet sein? Bei Spring ist es durch den
DebugInterceptor, den
PerformanceMonitoringInterceptor oder dem
JamonPerformanceMonitorInterceptor hat Spring auch gleich eine Palette an anderen interessante Interceptoren.
Nun kann man natürlich argumentieren, dass das alles viel zu komplizier ist. Eine Möglichkeit damit umzugehen, ist es, dass man das Wissen auf einige Leute beschränkt. Es muss schließlich nicht jeder technische Aspekte wie Security oder Tranaktione implementieren - dann kann man das Wissen über AOP auch auf jene beschränken, die solche Aspekte implementieren wollen bzw. müssen - die anderen können einfach die richtigen Annotationen im Code setzen und sich dann darauf verlassen, dass das richtige passiert - wie es eben auch schon bei EJB war.
Der andere interessante Effekt ist, dass AOP der Ruf voraus geht, dass es kompliziert ist - und zwar bis dahin, dass Adrian Colyer zum Teil die Strategie hat "Don't tell them it's AOP". Das ist nachvollziehbar - zumal die AspectJ Pointcuts den normalen Methodendefinitionen in Java sehr ähnlich sind.
Man sehe sich folgende Beispiel an:
@Aspect
public class MeinDebugAspekt {
@Before("execution(void tuEs())")
public void meinBeforeAdvice() {
System.out.println("Before Advice");
}
}
Hier gibt es nicht viel zu verstehen, außer dass vor Ausführung (execution) jeder Methode, die die Methodendefinition
void tuEs() hat, noch der zusätzliche Code aus meinBeforeAdvice ausgeführt wird. Wenn man dann noch Wildcards einführt wie
@Aspect
public class MeinDebugAspekt {
@Before("execution(* tuEs(..))")
public void meinBeforeAdvice() {
System.out.println("Before Advice");
}
}
dann kann man schon mal definieren, dass beliebige Rückgabewerte (*) und Parameter (*) für die Methode erlaubt sind - das ist dann schon ausreichend, um zum Beispiel für die
create()-Methoden der DAOs einen Aspekt zu definieren.
Also: AOP ist nicht so kompliziert wie es scheint. Und selbst wenn - nicht jeder muss es verstehen - schließlich versteht auch nicht jeder die internen Abläufe in einem Application Server. Dennoch benötigt man die Technologie, um Aspekte wie Security, Transaktionen usw. zu implementieren. Und statt einer ad-hoc-Lösung ist dann AOP als etablierte Basis sicher besser.
