Wer sich die Beta von Windows Vista installieren will, wird wohl kaum damit sein altes Betriebssystem überbügeln wollen. Nun gibt es unter Windows bekanntermaßen Virtual PC als Virutalisierungslösung. Kommt direkt von dem großen Software-Konzern aus Redmond. Also: Windows Vista in Virtual PC installiert. Ergebnis: Installation dauert eine Nacht (und zwar das Kopieren der Dateien). Die Performance ist anschließend so, dass man damit nicht arbeiten will.

Also: Nächster Versuch mit VMWare Player. Ergebnis: VGA Grafik mit lustigen 4 Farben und dadurch einer ziemlich lustigen GUI, die man nicht wirklich benutzen will. Nächster Versuch: Diesmal VMWare Workstation. Virtuellen PC angelegt, Windows Vista als Betriebssystem ausgewählt, VMWare Tools installiert - funktioniert. Und zwar durchaus mit benutzbarer Geschwindigkeit.

Gibt es einen Grund, warum Vista auf der hauseigenen Virtualisierung nicht vernünftig läuft? Na ja, wahrscheinlich kann ich nur wieder den großen Plan nicht richtig erkennen.

Die Spring One war mit Sicherheit eine sehr interessant Konferenz. Hervorzuheben ist dabei vor allem, dass die Leute von Interface21 sehr viele interessante Ideen haben und in diesem Kontext eine Menge interessanter Projekte existieren. Dies geht über die "bekannten" Sachen wie Spring, Acegi, Spring Web Flow und Spring Web Services hinaus und man kann sich sicher sein, dass auch in Zukunft hier noch viele interessante Sachen passieren. Es geht bei weitem nicht nur um Spring, sondern um gute Konzepte für Software-Entwicklung allgemein. Und wir stellen immer noch eine Menge interessanter Leute ein, wie zum Beispiel Ramnivas Laddad oder Costin Leau. Es ist auch sehr bemerkenswert, dass wir beispielsweise als Technologie-Lieferant für BEA fungieren oder bei solchen extremen Projekten wie jenem vom Voca mitspielen. Technologisch ist sicher "Spring & JPA" eine wichtige Sache und gleichzeitig wagte die Konferenz mit dem Fokus auf Domain Driven Design den Blick über den reinen Technik-Tellerand.

Also: Es ist und bleibt spannend und ich denke, dass wir Enterprise Java oder sogar Software-Entwicklung im allgemein deutlich weiterbringen können!

In dieser Session stellen Michael Chen von BEA und Rod Johnson vor, wie die Integration von Spring in Web Logic und vor allem auch die Implementierung von EJB 3 auf der Basis von Spring. Michael Chen began damit, dass er die Motivation von BEA für diesen Schritt vorstellte. Dabei hatte er auch eine Folie, auf der folgendes Zitat enthalten war: "EJB 3 ist Dependency Injection und AOP von 2003". Er stellten dann dar, dass er gerne Technologien bauen will, die den Leuten wirklich hilft und die sie gerne benutzen, was eben zu der Integration von Spring geführt hat. BEA will auch weiterhin den besten EJB Container anbieten. Dabei soll Weblogic weiterhin die bekannte Stabilität und Quality of Service bieten und auf der anderen Seite soll auf die bekannten WLS-Technologien wie EJB 2, Clustering, Fail Over , Transaktionen und Sicherheit zugegriffen werden können. Auf der anderen Seite soll von Spring die Einfachheit in der Nutzung übernommen werden.

Dependency Injection und AOP in Spring sind eine Obermenge von dem, was EJB 3 anbietet. Daher kann man auf dieser Basis die Features von EJB 3 recht einfach implementieren. Da Spring sehr flexibel ist, kann man die Features auch ohne größere Umstände implementieren.

Besonders interessant war dann, dass EJBs mit WLS auch Spring Beans sind. Daher kann man Spring Beans in EJB injekten und umgekehrt und zwar ohne, dass JNDI irgendwo benötigt würde. Dafür wird eine Datei im EJB-Jar verwendet (/META-INF/spring-ejb-jar.xml). Der Name der Spring-Bean ist dabei der EJB-Name was per default der kurze Klassenname ist.

Auch hier zeigte Rod wieder, dass selbst in den EJB 3 Samples aus der Spezifikation versteckte Probleme sind (z.B. Array-Zugriffe, die ArrayIndexOutOfBounds werden können) und dass die typsicheren Advices von Spring ein echter Vorteil sind, der dieses Problem beseitigt.

Also wird in Zukunft bei BEA WebLogic ohne weiteres ein hybrider Programmieransatz mit Spring und EJB möglich sein, so dass die Grenzen zunehmend verschwimmen. Gleichzeitig können die Features durch Pitchfork auch außerhalb eines EJB-Containers genutzt werden.

Wer ist noch nicht weiß: Steven Schuurmann ist der COO von Interface21 und leitet daher die operative Seite der Firma. Er fing an mit dem Thema, dass Enterprise Software Entwicklung langsam erwachsen wird und dass vor allem die Erfolgsrate hochgehen muss. Interface21 hat vor allem gute Produkte, wertvolle Services und gute Leute (das ist sogar zentral), um diese Services zu erbringen.

Die Firma wurde im Juli 2004 gegründet und hat in 2005 ein Wachstum von 300% erzielt. Sie hat mittlerweile ca. 30 Angestellte. Ziel ist es, ein Technologie-Partner mit hoher Qualität zu werden. Dies wird durch Training, Professional Services und Support erreicht. Außerdem werden weitere Programme aufgesetzt werden, so zum Beispiel in Q4/2006 ein Zertifizierungsprogramm.

Ingesamt konnte man deutlich erkennen, dass wir noch recht viele interessante Sachen vor haben und noch einiges bewegen werden. Schauen wir mal, wo die Reise noch hingeht!

Anschließend gab Rod Johnson noch eine Keynote, in der es darum geht, wie man die Vision von Spring und Interface21 umsetzten kann.

Zur Zeit wird an einer Roadmap für die nächsten 18 Monate gearbeitet. Schon jetzt ist Spring deutlich besser als das traditionelle Java EE Modell. Aber es muss weitergehen: Hin zu einem echten objektorientierten Programmiermodell. Middleware muss intelligenter und einfacher werden. Eine wesentliche Triebkraft ist dabei Domain Driven Design.

Die Spring Entwickler-Community bringt viel interessanten Input und Spring bietet auch schon eine sehr mächtige Basis, die man ohne größere Probleme zum Beispiel für die Implementierung des EJB 3 Containers von BEA nutzen kann und man muss dabei nicht das halbe System umschreiben.

Weitere ging es mit dem Thema "Open Source in the Enterprise". Hier räumte Rod mit einigen falschen Vorstellungen auf, die es bezüglich Open Source gibt. Die erste ist, dass Open Source eine Commodiziation ist: Produkte sind erst nur gegen Geld zu bekommen und später gibt es dann Open Source Lösungen, die preiswerter sind. Dies ist offensichtlich nicht der Fall bei AspectJ und bei Spring. Es gibt eben keine anderen Lösungen in diesem Bereich und die Lösungen sind auch von sehr guter Qualität.

Die zweite falsche Wahrnehmung ist, dass Open Source irgendwie auf magische Art und Weise von einer Ansammlung von Entwicklern geschrieben wird. Dies ist natürlich nicht so, auch bei Open Source benötigt man eine Vision und Führung. Interessanterweise sind es auch bei Spring nur einige wenige Leute, denen die Entwicklung im wesentlichen zu verdanken ist. Man benötigt auch eine Organisation, Engagement und Ausdauer. Viele Sachen sind dabei nicht spannend wie zum Beispiel die Features dann später auch bei Kunden zu unterstützen, sie zu warten und zu dokumentieren. Übrigens ist es auch bei anderen Open Source Projekten wie z.B. Linux inzwischen so, dass die Entwicklung im wesentlichen von Firmen finanziert wird.

Eine weitere falsche Wahrnehmung ist, dass Open Source nur aus Spaß geschrieben wird (obwohl zum Beispiel der Titel des Buches von Linux Thorvalds schon in diese Richtung weißt). Zumindest bei Spring ist das ganze jedoch weit mehr als ein Hobby. Inzwischen umfasst Spring 600.000 Zeilen Code, es gibt ein echtes Ökosystem rund um Spring und Integration in verschiedene Enterprise-Produkte wie Application Server oder Datenbanken. Gerade die Integration lässt sich nicht so eben mal zwischendurch testen, weil dazu schon nicht triviale Umgebungen notwendig sind. Das kann man nicht als Nach-Job machen, vor allem, wenn man nebenbei dann noch eine Familie oder Hobbies haben will...

Dann das Thema, dass Open Source nichts kostet. Das ist nicht wirklich richtig, denn die Lizenzkosten sind nur ein Teil der Total Cost of Ownership. Dazu kommt auch Training, Support und Skills, die man aufbauen muss. Allerdings konkurriert Spring hier meiner Ansicht nach oft mit In-House-Entwicklungen, bei denen gerade diese Themen deutlich teuerer werden, da man sie selber leisten muss und nicht am Markt kaufen kann.

Rod unterbrach dann die Keynote für Steven Schuurmann (dem widme ich einen eigenen Post). Am Ende kam er noch auf das Thema zu sprechen, dass durch die Spring-Community auch die Möglichkeit besteht, interessante und gute Leute anzustellen. Dazu gehören natürlich Adrian Colyer, der das Aspect-Projekt leitet und 13 Jahre lang bei IBM im Bereich Middleware gearbeitet hat. Dann noch Costin Leau, der auch schon in Pitchfork deutliche Spuren hinterlassen hat und im Spring Community Forum extrem aktiv ist. Außerdem leitet er das Spring Modules Projekt. Eine weitere Neueinstellung ist Ramnivas Laddad, der "AspectJ in Action" geschrieben hat und außerdem an einem Aspect Refactoring Buch arbeitet.

Ziel von Interface21 ist also, eine kritische Masse an außergewöhnlichen Leuten zu haben und so ein großes ganzes zu erzeugen. Man kann also sicher sein, dass hier noch viele spannende Dinge passieren...

Diese Keynote wurde von Gregor Hophe bestritten, der bei Google arbeitet. Sie stand unter dem Motto "Where did all my beautiful code go?". Er berichtete aus seinem Alltag bei Google und ich werde hier einige Gedanken-Fetzen wiedergeben. Eine Metrik, die er benutzt, um Probleme zu finden, ist, dass er scheinbar einfache Fragen stellt und diese dann so lange stellt, bis er eine eindeutige Antwort bekommt. Seiner Meinung nach ist das Problem nicht, dass es nicht die richtigen Werkzeuge gibt. Mittlerweile gibt es eine sehr breite Auswahl, so dass es wohl kaum das Thema sein kann. Das andere Problem ist, dass niemand absichtlich schlechten Code schreibt, sondern das passiert einfach.

Seiner Meinung nach ist es wichtig, die richtigen Modelle für ein Problem zu nutzen und auch die richtige Sprache. Diese sollten vor allem für die Kommunikation verwendet werden und als passende fachliche Abstraktionen. Dabei ist es nicht so wichtig, dass man Roundtrip-Engineering oder andere fortgeschrittene Konzepte unterstützt. Ein wichtiger Maßstab sind für ihn Tests. Er nutzt Fit und die Fit Library. Wenn man die richtigen Abstraktionen hat, kann man die Tests auch einem Anwender vorlegen und von ihm sinnvolles Feedback bekommen.

Die Präsentation ging dann weiter auf das Thema ein, wie man einen Workflow sinnvoll abbilden kann, weil in diesem Bereich zum Beispiel mit OSWorkflow und jBPM mehere Tools zur Verfügung stehen. Weiterhin streifte er die CalendarDate-Klassen von Eric Evans, dem Autor von Domain Driven Design. Durch solche Abstraktionen wird im Code klarer erkennbar, worum es eigentlich geht und schließlich sollen seiner Meinung nach auch die Product Manager den Code verstehen können.

Eine sehr interessante Präsentation, die viele Interessante Sachen erwähnt hat. Wirklich empfehlenswert!

Rod Johnson selbst sprach dann über die JPA / Spring Integration. Daran kann man die Bedeutung dieses Features für Spring ableiten. Außerdem kam von ihm die Aussage, dass JPA der Fokus für die Unterstützung von O/R Mappern in Spring sein wird. Natürlich bleibt die Unterstützung für die anderen O/R Mapper erhalten, aber neue Entwicklungen finden vor allem auf JPA statt.

Die technischen Details sind dann teilweise etwas - wie soll man sagen - interessant. So muss JPA für die Unterstützung von Lazy Loading Classes nachbearbeiten. Dafür wird normalerweise ein Java Agent verwendet, der dann aber für jede Klasse aufgerufen wird. Dadurch gibt es dann Performance-Issues, was gerade bei Tests ein Problem ist. Mit Spring 2.0 gibt es einen LoadTimeWeaver, der auf ClassLoader-Ebene die Modifikation der Klassen erlaubt. So kann man die Performance verbessern. Dazu muss man allerdings in den Application Server eingreifen und im Moment wird hier Oracle OC4J, BEA WebLogic und Tomcat unterstützt.

Ein weiterer wichtiger Vorteil dieses Vorgehen ist, dass auf diese Art und Weise die Integration von Load Time Weaving aus AspectJ möglich wird. Wenn man einmal die allgemeine ClassLoader-Abstraktion hat, kann man auch gleich solche Sachen bauen und zum Beispiel so auch @Configurable flächendeckend für alle Objekte unterstützen, ohne dabei viel zu konfigurieren. Eine interessante Erweiterung also. Diese Themen werden jedoch in 2.1 erst richtig interessant.

Für die JPA-Unterstützung gibt es in Spring 2.0 einen eigenen XML-Namespace, so dass hier auch gleich die vereinfachte Konfiguration verwendet werden kann. Spring unterstützt die LocalEntityManagerFactoryBean, die den JPA-Ansatz für Java SE unterstützt und so eine recht einfache JPA-Integration bietet.

Alternative ist die ContainerEntityManagerFactoryBean, bei der die Java EE SPI genutzt wird und Spring einen entsprechenden Container "vorspielt". Er kann dann mit Spring konfiguriert werden, die Einstellungen können aus Spring-Ressourcen kommen und es wird die Spring Instrumentation für die Klassen verwendet.

Über den DataSourceExporter kann man auch auf die DataSource zugreifen, die von JPA genutzt wird, so dass man Transaktionen über JDBC und JPA Code aufspannen kann. Eine weitere interessante Möglichkeit, um verschiedenen Persistenz-Technologien zusammen zu nutzen.

Die nächste spannende Sache war, dass man Exception Übersetzung nun automatisch auf der Ebene der Spring Bean haben kann. Vorher musste man ein Template verwenden, um z.B. aus einer SQLException eine DataAccessException zu machen. Bei JPA sind die Exception RuntimeExceptions, so dass man auch ohne Spring kein catch schreiben muss. Mit Spring werden die Exceptions aber in DataAccessExceptions umgewandelt, die bei allen Persistenz-APIs (JDBC, JPA, Hibernate...) genutzt werden. Die findet jetzt implizit statt, indem man die Klasse mit der @Repository Annotation versieht. Diese Annotation zeigt an, dass die Klasse ein DAO implementiert und sie kommt aus den neuen Stereotype-Annotationen, die im Package org.springframework.stereotype liegen. Damit kann man die Klassen aus der Anwendung als entsprechende Implementierung typischer Patterns für Spring-Anwendungen deklariere.

Eine weitere Neuerung ist der AbstractJpaTests. Vor allem gibt es jetzt eine Spring Test-Klasse, die einen kurzen Namen hat. Diese Klasse löst ein subtiles und hässliches Problem: Wenn man einen Test startet, wird der Test die anderen Klassen nachladen und zwar nicht modifiziert. Also muss man die für JPA modifiziern. Das kann man aber nicht, weil die Klassen eben schon geladen worden sind und man Klassen nur einmal laden. Also gibt es einen ShadowingClassLoader, der den Test und alle assoziierten Klassen lädt und dann in einem zweiten Durchgang einen neuen ClassLoader baut, der dann die Klassen tatsächlich lädt. Der TestCase unterstützt auch die ganzen anderen JUnit 4 Features wie @ExspectedException, @Repeat, @Timed und @NotTransacctional.

Ein weiteres Ziel für die Spring JPA Integration ist die Vereinheitlichung der Criteria APIs. Dabei handelt es sich um APIs, mit denen man im Programm selbst eine Objekt-Struktur bauen kann, die dann als Query ausgeführt werden kann. Dazu gibt es das schöne Interface EntityManagerPlus. Hier wird es in Abstimmung mit Herstellern wie Oracle oder BEA sicher noch weitere Features geben, die man vereinheitlichen wird und über diese Schnittstelle anbieten wird.

In dieser Session sprachen Mike Keith von Oracle und Patrick Linskey von BEA über JPA. Eine wesentlichen Nachricht von der Spring One ist, dass Spring und JPA der Application Stack der Zukunft sein wird. Daher gibt es auch einen ausführlichen Track zu diesem Thema.

In dieser Session ging es dabei um die Grundlagen. Interessant waren daher eher die Zwischentöne und Nebenbemerkungen. So sagte Patrick, dass die DB Optimierungen noch fehlen, d.h. man hat sich bei JPA noch nicht intensiv um dieses Thema gekümmert. Ein Problem bei JPA ist, dass Updates mit JP QL nicht im Cache landen, so dass es Inkonsistenzen geben kann.

Mit JPA kann man die Persistenz mit Annotation und mit XML definieren. Die Frage ist nun, was man wo nutzen sollte. Patrick gab hier als Tipp, dass man Datenbank-Spezifika wie zum Beispiel den Spalten-Namen im XML definieren sollte, weil sich dieser ändern könnte, man so das Objekt-Modell auch auf einer anderen Datenbank verwenden kann und den manchmal hässlichen SQL-Code aus den Annotationen raushält. Dinge wie @Entity oder @Id sind aus seiner Sicht eher Bestandteile der Klasse, so dass man sie als Annotationen definieren kann. Er glaubt auch, dass man Tools sehen wird, die aus den Annotationen XML generieren, so dass man bei der Entwicklung mit den Annotationen arbeiten kann und später beim Deployment mit XML, um dann langfristig die Wartung zu vereinfachen. Außerdem ist er der Meinung, dass man das Überschreiben der Einstellungen aus den Annotationen mit den Einstellungen aus dem XML-File vermeiden sollte, weil man dann nicht weiß, welche Einstellung von wo kommt. Ich muss hier zustimmen, das Überschreiben von Konfigurationen ist eine wirklich schlechte Idee.

Ingesamt eine ganze gute Übersicht, aber eben eher auf Einsteiger-Niveau.

Dieser Vortrag kam von meinem Kollegen Bram Smeet aus den Niederlanden. Er sprach über <a href="http://www.directwebremoting.org">DWR</a>, womit man recht leicht AJAX-Systeme bauen kann. Im Prinzip ist bringt DWR AJAX mit RPCs und Java / JavaScript Marshalling. Man kann als von JavaScript aus einen Java-Server aufrufen und dabei werden Java-Objekte transparent in JavaScript übersetzt. Die meisten Browser werden von DWR dirket unterstützt.

Letztendlich hat man dann ein rudimentäres System, um JavaScript und Java aneinander zu binden. Wenn man dann im JavaScript-Code die HTML-Elemente ändert, kann man so recht einfach AJAX-Oberflächen bauen. Es hat allerdings keine direkte Unterstützung für vorgefertigte Komponenten, so dass man die GUI selber zusammenbauen muss.

Unterstützung für Debugging gibt es auch. Und man kann auch mehrere Aufrufe in einem Batch sammeln. Auch ein Push-Modell wird unterstützt, bei dem der Server an den Browser JavaScript-Ausdrücke schickt. Das ganze heißt "Reverse AJAX".

Die Spring-Integration bietet dann die Möglichkeit, Spring Beans über DWR zu exportieren. Dazu gibt es einen passenden Spring 2.0 XML Namespace.

Ingesamt ein interessanter Ansatz und auch mal ganz was anderes. Bram Smeet ist übrigens einer von zwei Committern, was zeigt, dass Interface21 eine Menge interessanter Technologien zu bieten hat.

Das Ende der Keynote beschätigte sich dann mit der Zukunft von Spring.

Ein wichtiges Thema ist die einfachere Konfiguration. Es soll mehr mit Konventionen, Defaults und Heuristiken gearbeitet werden. So kann man recht leicht vorhersagen, welchen PlatformTransactionManager man haben will, weil dies von der verwendeten Persistenz-Technologie abhängt. Dazu kommt dann die direkte Unterstützung für Enterprise Application Patterns, möglicherweise mit einem Maven 2 Generator und den dort verwendeten Archetypes.

Aus Rods Sicht ist ein wichtiges Thema die bessere Unterstützung für den Betrieb. Dazu kann man den ApplicationContext zum Beispiel über JMX managebar machen, Profiling und Tuning einbauen und ein weiteres wichtiges Thema ist sicher die Partitionierung der Anwendung mit Hilfe von OSGi, den man ja auch auf dem Spring Day auf der JAX sehen konnte. Dazu kommen dann Sachen wie dynamische Konfiguration und Warm-/Klatstarts.

Das Fazit: Es geht um Innovation, die einen Unterschied macht, also wirklich einen Wert bringt und nicht nur einfach Innovation um der Innovation willen ist. Da Spring ein POJO-Programmiermodell hat, kann man recht leicht Innovationen liefern, ohne dass etwas dadurch zerstört und so bietet auch Spring 2.0 Innovationen, ohne dass alter Code gebrochen wird.

Dann übernahm Adrian Colyer, Chief Scientist bei Interface21 und AspectJ Project Lead. Es ging dann erstmal um Java EE 5. EJB 3 bezeichnete er als rudimentäre Implementation eines Interception und Dependency Injection Systems, das fast die Mächtigkeit von Spring 1.0 hat. Neben dem Simplified Model gibt es dann ja in EJB 3 auch das Core Model, in dem sich dann die ganzen unangenehmen Sachen auch EJB 2.1 verstecken....

Die Überschneidung zwischen Spring und Java EE 5 hält er für klein - Java EE 5 ist eine Evolution, aber kein Ersatz für ein Java EE Framework. Außerdem hat es natürlich eine JDK 1.5 Abhängigkeit, die wohl bei dem derzeitigen Stand vieler Produktionssysteme auch ein Problem ist.

Dependency Injection in EJB 3 hat das Problem, dass es auf Annotationen basiert, was für Legacy Code (also alles vor JDK 1.5, was sehr viel ist), natürlich ein Problem ist. Außerdem benutzt es JNDI und es unterstützt auch keine Features wie Konstruktor Dependency Injection.

Interceptors in EJB 3 sind nach seinen Worten ein nicht erprobtes Modell, weil es eben keine Pointcuts hat. Dadurch hat man immer noch Scattering, d.h. ein Aspekt muss man in den Klassen immer noch einweben und man kann ihn nicht so leicht auf einige Klassen limitieren. Das Modell ist dabei nicht nur weniger mächtig, sondern auch komplexer, wie Adrian an einem Beispiel aus der EJB 3 Spezifikation zeigte. Dabei hat Spring vor allem auch typsichere Advices, in denen man dann keine Type Casts mehr machen muss.

Das ganze ist aber keine entweder/oder Entscheidung - immerhin haben wir ja auch einen EJB 3 Container für BEA geschrieben. Es ist nur einfach so, dass Spring in den Bereiche, in denen Spring eine Alternative zu EJB 3 ist, überlegen ist.

Rod übernahm dann wieder und sprach von weiteren Spring-Anwender: Die Bank of America oder Decare Systems. Außerdem wird Spring - wie vielleicht bekannt - von BEA, Oracle, IBM, ALfresco und Logic Blaze als Basis für eigene Systeme verwendet. Besonders schön das Zitat von Wai Weng, Executive Vice President bei BEA: "Spring hat die Nuss für einfache Enterprise Java Entwicklung geknackt."

Die Zusammenarbeit mit BEA ist ja bekanntermaßen gut und die Basis der Java EE 5.0 von Web Logic ist eben Spring, auf dem dann EJB 3 aufbaut. Gründe: Man kommt schneller zum Ziel, es gibt weniger Risiko und bessere Funktionalität. Das ganze ist als Open Source mit dem Pitchfork-Projekt verfügbar.

Rod zeigte dann Beispiele für Spring 2.0 und die Einfachheit und Mächtigkeit dieses Ansatzes. Interessant war dabei, dass Rod als Vorteil von Spring die Konfiguration von Klassen nannte, die selber nichts von Spring wissen. Die neuen XML-Namespaces sind eine Möglichkeit, Spring die Klassen bekannt zu machen, so dass man sie einfacher konfigurieren kann. Gerade bei AOP ist dies ein deutlicher Vorteil.

Interessant auch die Unterstützung für Script-Sprachen: Man kann einen Spring-Bean mit einer Script-Sprache implementieren und dann Spring regelmäßig nach Updates für das Skript pollen lassen. Dadurch ist in beliebigen Anwendungen ein schnelles Update der Logik möglich. Weiterer Punkt (zu dem ich auch noch was schreibe) ist Spring und die Java Persistence API aus JSR 220.