Es hat mich erwischt....
Tja, danke,
Matthias. Jetzt darf ich also drei Dinge über mich verraten, die kaum jemand weiß, und den Staffelstab an drei Blogger weiterreichen, die ihn dann weiterreichen sollten usw. Nun ja, also:
- Mein erstes Linux war nicht nur auf 3,5" Disketten, sondern es war auch direkt auf das Raw-Device ge-tar-t. Bekommen habe ich es von einem Informatik-Studenten (es war vor meinem eigenen Studium) und lief auf einem 386SX mit 16MHz und 2 MB RAM. Kernel-Version habe ich vergessen....
- Ich bin wahrscheinlich einer der wenigen, die freiwillig auf einen langsameren Computer umgestiegen sind: Von einem Intel Pentium 100MHz auf eine NeXTstation mono turbo - NeXTstep lief dort aber subjektiv flüssiger.
- Die C-64 und Amiga-Zeit ist an mir vorbei gegangen - ich habe sie auf einem Schneider CPC 464 verbracht.
So, und jetzt seid Ihr:
Johannes,
Michael und
Martin.
VMWare Fusion Beta für Mac OS X
Ein Traum wird wahr - und das noch vor Weihnachten! Das
VMWare Fusion Beta Programm ist angelaufen. Das ist VMWare für Mac OS X auf Intel. Runtergeladen, VMWare Image vom PC gestartet - geht. Allerdings nicht extrem schnell, was wohl aber auf den Debug-Code zurückzuführen ist. VMWare Tools kann man auch installieren - habe ich auch ausprobiert, nach einem Restart der VM gab es dann allerdings einen Knall (d.h. die VM fror ein). Dafür hat VMWare jetzt einen Bug Report mehr - was ja auch Ziel der Beta ist. Und es gibt dann all die coolen
VMWare Appliances, die darauf warten, ausprobiert zu werden - sehr cool!
Also: Danke, VMWare! Ich denke, ich werde das Produkt kaufen, wenn es raus kommt.
The Spring Experience: The Spring Value Proposition in the World of Java EE 5 and EJB 3.0
In diesem Vortrag ging es um das Thema, wie sich Spring positioniert, nachdem nun EJB 3.0 und Java EE 5 vorgestellt worden sind. Nach der Vorstellung von Java EE 5 und EJB 3.0, die ich mir hier spare, wurde zunächst die Frage geklärt, ob Spring mit EJB 3.0 konkurriert. Das ist nicht der Fall, man kann EJB 3.0 zusammen mit Spring nutzen. Außerdem wurde schon in der Übersicht deutlich, dass EJB 3.0 schlicht technisch unterlegen ist. So hat es nur ein einfaches Dependency Injection Modell, das mit Annotations arbeitet, da die XML-Konfiguration im Prinzip nicht sinnvoll nutzbar ist. Außerdem gibt es keine Möglichkeit, vorhandenen Code, der ohne Rücksicht auf EJB 3.0 geschrieben worden ist, mit der Dependency Injection von EJB 3.0 zu verwalten. Alles Dinge, die Springs Dependency Injection kann. Interessant auch, dass es zum jetzigen Zeitpunkt keinen produktionsreifen Server gibt, der EJB 3.0 unterstützt - was zwar bedeutet, das EJB 3.0 ein Standard ist, aber eben ohne produktionsreife Implementierungen.
Das ganze ist dann bei EJB 3.0 mit einem einfachen Interceptor-Modell versehen, während Spring hier eine vollwertige AOP-Implementierung bietet.
EJB 3.0 sind näher an echten POJOs als das EJB 2.1 Programmiermodell, aber durch die Annotationen gibt es dennoch Abhängigkeiten von EJB 3.0. Außerdem weiss eine abhängige Klassen bei EJB 3.0, dass eine EJB injiziert wird und nicht etwa ein einfaches Java-Objekt oder ein Web-Service, was bei Spring nicht der Fall ist. Sehr interessant war auch der ganz erhebliche Aufwand, den man in EJB 3.0 treiben muss, um einen primitiven Wert in eine EJB 3.0 Bean zu injizieren.
Es schlossen sich dann einige weitere Folien an, die Punkte aufzählten, die EJB 3.0 in der Dependency Injection nicht anbietet. Dazu zählt Constructor Dependency Injection, Method Dependency Injection, Unterstützung für Factories, keine Unterstützung für PropertyEditoren um eigene Datentypen per Dependency Injection konfigurierbar zu machen, es gibt nur eine Konfiguration pro Klasse, es gibt nur einen Lifecycle und vor allem kein Singleton-Lifecycle, der bei Spring seinen Wert bewiesen hat und die XML-Konfiguration ist wesentlich komplexer. Erweiterungsmöglichkeiten wie die Spring BeanPostProcessoren und BeanFactoryPostProcessoren existieren nicht, es gibt nur die vorgesehenen Konfigurations-Mechanismen, während Spring verschiedene Konfigurations-Mechanismen vorsieht und auch die Kern-Dependency-Mechanismen vom Einlesen der Konfiguration entkoppelt hat. Dynamische Möglichkeiten, die in Spring durch die TargetSource zur Verfügung stehen, gibt es in EJB 3.0 ebenfalls nicht. Und die Flexibilität von Spring ist so groß, dass man mit dem Pitchfork-Projekt sogar größere Teile der EJB 3.0 API mit Spring nutzen kann.
Übrigens vertraten die Vortragenden auch die Meinung, dass EJB 3.0 in der Realität wohl nicht ohne XML auskommt, weil man nur so Referenzen über Deployment Units (JAR Files) hinweg ausdrücken kann oder die JNDI-Namen nicht hart im Code haben will. Das XML ist dann in EJB 3.0 deutlich komplexer und schwieriger zu schreiben als jenes in Spring.
Die Zusammenfassung der Interceptor bzw. AOP-Features war "EJB 3.0 completly misses the Point". EJB 3.0 hat das Problem, dass man jede Klasse, die durch einen Interceptor behandelt werden soll, mit einer passenden Annotation versehen muss. Statt also eine Querschnittsbelang zentralisiert zu implementieren, zieht er sich als Annotation immer noch quer durch den Code - genau diese zentralisierte Implementierung eines Querschnittsbelangs ist aber das Ziel von AOP. Es wird durch das Pointcut-Modell erreicht, dass definiert, wo ein Aspekt einsetzen soll - genau dieser zentrale Teil des AOP-Konzepts fehlt aber EJB 3.0. Es gibt auch keine Möglichkeit für Introductions, bei denen man eine Klasse im Nachhinein um die Implementierung weiterer Interfaces ergänzt. Mit EJB 3.0 ist es ebenfalls nicht möglich, die Parameter eine Methode, die durch einen Interceptor ergänzt wird, an einen Parameter der Interceptor-Methode zu binden. Um auf die Parameter zuzugreifen, muss man also das Array der Parameter "von Hand" nach dem gewünschten Parameter durchsuchen. Außerdem fehlen Before, After Returning, After Throwing und After Advices - es gibt eben in EJB 3.0 nur Around-Advices.
Bei Transaktionen bietet EJB 3.0 nur Unterstützung für JTA und man kann auch das Rollback bei Exceptions nicht für einzelne Use Cases unterschiedlich gestalten.
Security bietet nur Unterstützung für JAAS-LoginModules, nur Rollen-basierte Authorisierung (keine ACLs, keine ACLs für Domänen-Objekte statt Services, keine Kombination verschiedener Authoriserungs-Mechanismen) und es ist schwer erweiterbar und testbar.
Spring bietet hier mit Acegi eine Lösung, die diese Features hat, aber vor allem leicht erweiterbar ist, sehr viele Technologien unterstützt und auf Spring AOP bzw. AspectJ aufsetzt.
Bei der Persistence unterstützen sowohl EJB 3.0 als auch Spring JPA als Teil von Java EE 5. Die gute Integration heterogener Technologie-Ansätze (90% JPA, 10% JDBC) hat Spring auch schon mit anderen Persistenz-Technologien bewiesen.
Es wurden dann noch Möglichkeiten vorgestellt, wie man von einem EJB 3.0 Adapter aus einen Spring Logik Kern ansprechen kann und das Projekt Pitchfork vorgestellt, das eine EJB 3.0 API auf dem Spring-Container implementiert und gleichzeitig die Basis für die EJB 3.0 Implementierung in BEA Web Logic ist.
Ich fand es bei diesem Vortrag vor allem recht spannend, konzentriert die Unterschiede zwischen Spring und EJB 3.0 zu sehen.
The Spring Experience: Designing for Multi User High Volume Applications in an Oracle Environment (Jim Clark)
In dieser Session ging es um Themen im Zusammenhang mit Oracle in Anwendungen mit hohen Ansprüchen an Verfügbarkeit und Performance. Das erste Thema war das Verhalten beim Ausfall einer Connection zur Datenbank. Oracle bietet dazu im Treiber selbst ein transparentes Fail-Over an. Dazu kommunizierte der JDBC-Treiber mit der Datenbnak. Wenn eine Connection ausfällt, wird sofort eine SQLConnection ausgelöst, damit die Anwendung reagieren kann. Anschließend werden dann die Ressourcen aufgeräumt und die Transaktion wird zurückgerollt. Falls ein ausgefallener Knoten wieder aktiv wird, wird einfach die Connection wieder zum Pool hinzugefügt. In der Anwendung muss man lediglich die OracleDataSource mit setConnectionCachingEnabled(true) und setFastConnectionFailover(true) entsprechend konfigurieren. Natürllich macht man das am besten in der Spring-Konfiguration... :-) Man kann dann mit OracleConnectionCacheManager.isFatalException(ex) herausfinden, ob eine Exception ein Fail-Over verursacht hat und kann dann die Aktion nochmal ausführen - dazu muss man dann den passenden Code schreiben.
Auf Ebene der Verbindungen wird auch ein Load Balancing ausgeführt. Auch hier kommuniziert der Treiber mit der Datenbank und wählt einen Knoten aus. Stehen keine Informationen zur Verfügung, wählt er zufällig einen Knoten aus. Per default teilt ist dieses Feature in der Datenbank allerdings allerdings ausgeschaltet, man muss es erst dort aktivieren, bevor es genutzt werden kann. Auf JDBC-Seite muss lediglich das Connection Fail Over aktiviert sein.
Für die Integration von Spring in den Oracle Application Server (OC4J) kann man eine managed DataSource benutzen, bei der man dann Transaktionen mit JTA verwaltet, oder man benutzt eine native DataSource mit nativer Transaktionssteuerung über die JDBC-Connection. Außerdem kann OC4J Spring als eine shared library verwenden, d.h. Spring wird nur einmal geladen und die jeweiligen Anwendungen nutzen dann diese eine Version. Oracle hat außerdem einen Dynamic Monitoring Service (DMS), den man durch Spring AOP mit Daten versehen kann und OC4J kann dadurch z.B. HTTP-Requests richtig routen und man kann ihn zum Beispiel mit JMX an und ausschalten.
Es ging dann noch um TopLink, den O/R-Mapper von Oracle. Hier empfiehlt sich die Nutzung von Named Queries, um die Optimierung der Queries zu erleichtern. Außerdem kann man Batch Reading und Joined Reading als Optimierungen verwenden. Weiter Möglichkeiten sind Lazy Reading und Lazy Cloning - dabei wird das Objekt erst dann kopiert, wenn es geändert wird.
Jim zeigte dann noch JDeveloper, die Entwicklungsumgebung von Oracle, und das dazugehörige neue Spring-Plug-In, das mittlerweile auch für Endanwender verfügbar sein sollte.
The Spring Experience: Using Dynamic Languages with Spring (Rod Johnson, Guillaume Laforge)
In diesem Vortrag haben Rod Johnson (CEO, Interface21) und Guillaume Laforge (Groovy Spec Lead) über das Thema Spring und dynamische Sprachen gesprochen - wenig überraschend über Groovy.
Warum ist das überhaupt interessante? Spring ist eben nicht nur für Java, sondern hat einen breiteren Ansatz, und Groovy ist recht leicht zu lernen. Außerdem ist Spring recht flexibel. So kann man mit Hilfe des Spring AOP Ansatzes Proxies erzeugen, die dann auch für Beans angewendet werden kann, die in einer dynamischen Sprache geschrieben sind.
Zu Integration mit einer dynamischen Sprache kann man (im Falle von Groovy) die GroovyScriptingFactory nutzen (dazu muss man dann noch einen ScriptFactoryPostProcessor in der Konfiguration definieren). Eine Alternative ist das <lang:grovy>-Element mit einer Referenz auf ein Source-File oder direkt Code in der Spring-Konfiguration mit dem <lang:inline>. Eine weitere Möglichkeit ist eine ganz normale Bean Definition. Letzteres hat den Vorteil, dass es sehr einfach ist, man kann "normale" Dependency Injection machen - sonst muss man das <lang:property>-Element verwenden. Allerdings kann man eine solche "normale" Bean-Definition nur bei Groovy nutzen, weil Groovy Java Byte Code für die eigenen Klassen erzeugt.
Gründe für die Verwendung von dynamischen Sprachen sind zum Beispiel die Integration in Spring MVC, denn gerade bei der Implementierung von Controller bekommt man so viel schneller Feedback und das Interface (Controller) bleibt immer gleich. Rod hat diesbzüglich auch schon experiementiert und das ganze macht wohl einen guten Eindruck.
Guillaume zeigte dann einen anderen Einsatszweck von dynamischen Sprachen und zwar DSLs. Er zeigte eine Sprache, die zum Definieren von Events verwendet werden kann. Was man dazu macht, ist, dass man eine neue Meta-Klasse definiert. Meta-Klassen definieren das Verhalten von Klassen und sind Teil des Meta Object Protocols. In dem Beispiel ändert man das Verhalten bei einem Methodenaufruf: Statt, dass eine Methode ausgeführt wird, wird ein neues Event erzeugt, man überlädt dazu die
invokeMethod()-Methode.
Ingesamt ein interessanter Vortrag, der zeigt, dass auch im Bereich dynamischer Sprachen Spring sich nicht verstecken muss.
The Spring Experience 2006
Ich weile im Moment bei der Spring Experience 2006 in Miami. Hier feiert man Weihnachten offensichtlich am liebsten am Strand in der Sonne...
Wie dem auch sei. Gestern wurde die Konferenz eröffnet, da saß ich allerdings noch im Flieger. Daher verweise ich hier auf
TheServersSide. Weitere Beiträge über einzelne Events hier wird es aber auf jeden Fall zu lesen geben.
Stay tuned!
The Spring Experience: Transaction Management in Mission Critical Applications (Jürgen Höller)
Eigentlich erscheint so ein Thema wie Transaktionen nicht so spannend, aber Jürgen Höller hat hier einige sehr interessante Punkte gemacht. Von daher lohnt es sich, darüber zu berichten:
Als erstes ging es um einige Mythen, die es im Bereich Transaktionen gibt. So wird die Nutzung von XA bzw. Two Phase Commit überbewertet. Man sollte es alleine schon aus Gründen des Durchsatzes möglichst nicht nutzen, aber auch für die Integration von JMS mit JDBC kann man statt XA auch ein eignes Bestätigen der JMS-Nachrichten nutzen.
Ein weiterer Mythos, mit dem man aber bei Spring-Entwicklern nicht mehr aufräumen muss, ist, dass nur durch die Nutzung von EJB deklarative Transaktionsverhalten möglich ist. Ebenfalls muss man auch nicht EJB nutzen, um eine verteilte Transaktionen mit verschiedenen Teilnehmern im Netzwerk zu implementieren. Allerdings ist auch eine solche Transaktion, bei der der Transaktionskontext im Netz übertragen wird, kaum sinnvoll bzw. wird kaum genutzt.
Wesentlicher Vorteil des Transaktions-Handling von Spring ist natürlich, dass die Demarkation der Transaktionen von der Infrastrukur getrennt ist. Man kann Demarkation mit XML, Annotationen oder programmatisch vornehmen und das dann mit einer beliebigen Transaktions-Infrastruktur kombinieren.
Ein konkreter Vorschlag für die Optimierung ist das Read-Only-Flag. Damit kann man insbesondere bei O/R Mappern und bei JDBC Performance gewinnen. Bei Hibernate wird dann die Change Detection ausgeschaltet, die sehr aufwändig ist.
Jürgen sprach dann über die nativen Transaktions-Manager, die zum Beispiel für JDBC oder Hibernate genutzt werden. Sie geben Zugriff auf alle Möglichkeiten der Datenbank und der Persistenz-Technologie. Erstaunlich viele Enterprise-Anwendungen kommen mit einem solchen Transkations-Manager aus und benötigen kein JTA-Transaktions-Manager. Die nativen Transaktions-Manager haben sogar Vorteile: Man kann eben alle Features der Infrastruktur verwenden, das Set-Up ist einfach und man kann gute Performance erreichen. So kann man mit einem JDBC 3.0 Treiber und einerm DataSourceTransaktionManager Isolations-Levels und auch Read-Only-Flags setzen und entsprechend bessere Performance erreichen.
Der WebLogicJtaTransactionManager bietet auch einige Vorteile gegenüber dem JtaTransactionManager, so die Unterstützung von Transaktions-Namen, Isolations-Level und verteilte Transaktionen mit WebLogic-RMI.
Eine interessante Idee war dann noch die NUtzung von Standalone JTA Managern, die man zum Beispiel in einem WAR-File mitliefern kann. Dadurch kann man XA-Transaktionen auch abwickeln, ohne dass man einen Application Server braucht. Man muss den Transaktion-Manager auch nicht in den Web-Server integrieren, sondern man lässt ihn einfach in der Web-Anwendung laufen - ein recht interessanter und praktikabler Ansatz.
Jürgen hat es geschafft, hier einen sehr spannenden Vortrag geliefert, der interessante technische Details dargestellt hat - auf jeden Fall empfehlenswert!
Interface21 Mailing Liste
Unter
http://lists.interface21.com/listmanager/listinfo/news-de gibt es
nun die Möglichkeit, sich zur Interface21 Mailing Liste anzumelden.
Neben Spring werden hier auch Neuigkeiten über Interface21 und andere
Interface21-Produkte veröffentlicht werden. Also: Am besten gleich subscriben, so lange noch Plätze frei sind... ;-)
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
