Im ersten Teil spreche ich dann über Patterns wie Component, Component Interface, Virtual Instance, usw und erläutere dadurch, dass Spring eben ein Komponent-Modell hat, bei dem die Komponenten nicht mehr als Klassen sind. Das Component Interface ist dann nur noch ein Java Interface. Virtual Instance, in EJB durch Pooling von Stateless Session Beans und Entity Beans implementiert, ist zum einen nicht mehr so wichtig, weil neuere JMVs wesentlich weniger Problem mit Objekt-Allokation und -Zerstörung haben und außerdem ist es in Spring generalisiert: Man kann eben jedes Spring-Bean poolen oder in einen ThreadLocal unterbringen. Naming (=JNDI) und Component Home werden durch Dependency Injection abgelöst.
Interessant ist für mich vor allem, dass Component Home ein echter Fehler war: Für Stateless Session Beans und Stateful Session Beans macht es wenig Sinn, man hätte im JNDI auch gleich eine Instanz registrieren lassen können. Für Entity Beans ist es zwar sinnvoll, aber Entity Beans selber sind problematisch. Wenn man nun eine Stateless Session Bean hätte, die dasselber Interface hat wie ein Entity Home, kommt man zu dem typischen DTO-Strukturen von EJBs bzw. DAOs in moderneren Anwendungen.
Spring bringt dann die Exporter und Proxies, mit denen man Spring-Beans in andere Infrastrukturen exportieren kann oder ein Objekt aus einer Infrastruktur transparent ansprechen kann. Beispiele sind verteilte Infrastrukturen wie RMI, SOAP etc., aber eben auch JMX oder OSGi. Diese Patterns sind als Adapter bzw. Proxy im ursprünglichen Desing Patterns Buch bereits beschrieben, können in Spring aber oft durch eine reine Deklaration implementiert werden.
Zum Abschluss habe ich dann noch Spring Patterns für API-Abstraktionen wie den Exception-Übersetzer vorgestellt. Der ist übrigens in EJB in Ansätzen auch vorhanden (durch das Wrappen technischer Exceptions in EJBExceptions) und auch mit AspectJ durch das Soften von Exceptions möglich - in Spring ist es allerdings mehr: Die Exceptions werden nicht nur einfach in eine generische Exception eingepackt, sondern es gibt eine detailierte Exception-Hierarchie, die z.B. Exceptions aus den verschiedenen Persistenz-Technologien vereinheitlicht.
Das andere Pattern ist dann das Template, dem man auszuführenden Code übergibt, und das sich dann um die Ressourcen kümmert. Hier habe ich darauf hingewiesen, dass es mit Closures noch einmal deutlich einfacher wird.
Das Feedback war rech gut - es gab sogar eine Einladung auf eine andere Konferenz... ¶ 12:25
