J and I and Me: Juni 2005

JDO 2 in Action

In dieser Session gaben uns Craig Russell (JDO Spec Lead) und Patrick Linskey einen Einblick in JDO 2 und die Features. Die Session war dadurch auf Anfänger Niveau. Hinterher habe ich auch gemerkt, dass ich eigentlich zu "Real-World Experience in Application Scaling using Java Data Objects" wollte, aber das wäre auch nicht besser gewesen, denn dort ging es um ein Projekt, das selber eine objekt-orientierte Datenbank entwickelt hat. Das ist zwar recht interessant, aber wohl nur von geringer Praxisrelevanz.

In der Session wurde bei den Vorteilen als erstes das Aufschieben von Entscheidungen genannt. Das fand ich spannend, weil Spring genau das auch tut und ich dort aber immer das Gefühl habe, dass dieses Argument eher nicht überzeugt. Dabei ist bei Spring das Argument noch stärker, dann man kann die Logik auf einem Application Server, einem Web Server und in Java SE verwenden, während JDO nur den Persistenzteil lösen kann.

Ein für Deutsche witziger Begriff ist POPO: Plain Old Persistent Object. Craig Russel will wohl wie Martin Fowler unseren Sprachgebrauch beeinflussen....

Ein Hinweis war dann noch, dass O/R Mapper nur bei großen Objekt Modellen sinnvoll sind. Ich würde sogar noch einen Schritt weiter gehen, und diese Vorraussetzung nur für notwendig, nicht aber für hinreichend halten. Uach große Objekt Modelle können ggf. mit Table Data Gateway , Active Record oder Row Data Gateway (siehe Patterns of Enterprise Application Architecture) besser bedient sein, auch wenn das natürlich Ausnahmen sind.

Ansonsten gab es einige Randpunkte zu JDO 2: Generics funktionieren. Es gibt Use Case spezifische Fetch Groups, was eben auch einer der Punkte ist, die anscheinden jetzt alle O/R Mapper Hersteller gemerkt haben. Projektionen gibt es auch, also die Möglichkeit, nur einige Felder der Datensätze auszulesen.

Ein wichtiges Optimierungsziel ist natürlich die Minimierung der Datenbank Roundtrips. Man kann dann bei JDO das Tuning komplett in der XML Konfiguration machen. Dort kann man Fetch Groups und Fetch Plans definieren. Die kann man dann bei den Queries angeben. Eine interessante Idee, deren Auswirkungen mir unklar sind, ist, dass bei einer Fetch Group beim Zugriff auf irgendein Feld gleich die ganze Fetch Group geladen wird. Das könnte eine gute Idee sein, weil es wahrscheinlich bei Daten tatsächlich Gruppen gibt, die man immer zusammen laden kann. Auf der anderen Seite schränkt es die Flexibilität ein, d.h. man kann nicht mehr bei einem Use Case bestimmte Felder laden und bei einem anderen komplett andere, weil die Fetch Groups eben eine Gruppierung vornehmen.

Das große Thema ist natürlich JDO 2 und EJB 3. Hier wurde darauf hingewiesen, dass das die Ideen zu Implementierung des Domain Models ähnlich sind und auch der Life Cycle ist ähnlich. API, Metadaten und Callbacks sind konzeptionell ähnlich. Bei den Queries sind jeweils andere Standards erlaubt, so dass man die jeweils andere Abfragesprache integriert werden kann.

Was mir am meisten aufgefallen ist, war die Teilnehmeranzahl. JDO sollte angesichts von JSR 220 / EJB 3 kein großes Thema mehr sein, aber die Leute finden es immer noch spannend. Vielleicht passiert hier doch noch mehr, als man so denken würde.

¶ 15:52 0 comments

High Performance Persistence - Oracle Top Link

Auch die andere Seite der Persistenz-Technologien durfte auf der Java One natürlich zu Wort kommen. Hier habe es einige Tipps und Einsichten, die nicht unbedingt etwas mit Top Link zu tun haben. Der erste Tipp (eher offensichtlich) ist, Optimistic Locking, dass bis auf hohe Kollisionsraten Pessimistic Locking überlegen ist.

Das Thema Optimierung von Queries nahm auch hier einen größeren Teil der Zeit ein. Auch hier war der Punkt erstmal die Umsetzung von Queries mit Subjoins, Joins und Batches. Ein Problem ist dann natürlich, dass das entstehende SQL möglicherweise zu komplex ist.

Ein Tipp war noch die Verwendung von Projektionen, also nur einen Teil der Felder zu lesen. Dies erlaubt EJB QL neuerdings. Das gleiche gilt für Aggregate, also Dinge wie die Summe bilden oder eine Anzahl zählen.

Man sollte außerdem nur eine kurze DB Transaktion am Ende der Client Interaktion machen, was auch logisch ist, denn die gesamten Client Interaktion ist schlicht zu lang.

Top Link hat ein Transfered Transaction Model, was bedeutete, dass am Ende der Interaktion Updates nur auf die Felder gemacht werden, die sich geändert haben. Updates, Inserts und Deletes werden in der richtigen Reihenfolge bzgl. der Constraints gemacht. Dadurch ergeben sich einfache Transaktionen und wenig Deadlocks.

Die Transaktion muss Objekte verwalten, um zum Beispiel Änderungen an den Objekten zu entdecken. Man sollte also wenig Objekte allokieren und nur geänderte Objekte an der Transaktion registrieren. Ob dies ein Nachteil der Verfahrensweise von Top Link ist, Kopien der Objekte für das Entdecken von Änderungen zu nutzen, ist mir unklar.

Caching ist natürlich auch ein (das?) Thema bei Performance. Man benötigt auf jeden Fall einen Cache, da man sonst die Objekt Identität nicht hinbekommt: Wenn zwei Objekte denselben Datensatz repräsentieren sollen, sollte man dafür dasselbe Objekt verwenden. Dazu braucht man einen Cache. Für einen effektiven Cache muss man aber Datenzugriff haben, der sich wiederholt, entweder in der Session oder über mehrere User hinweg. Es gibt bei Top Link - wie auch bei anderen O/R Mappern - mehrere Caches, so dass man auch an dieser Stelle durch geschickte Konfiguration einiges erreichen kann.

Er bestätigte mich dann noch in der Einschätzung zu O/R Mappern und Performance im allgemeinen: Durch die O/R Mapper hat man eine flexible Zugriffschicht, die konfigurierbar ist und von dem konkreten Zugriff abstrahiert. Durch Änderungen in diesem Bereich kann man dann Performance Tuning betreiben, das sonst nur mit Code Änderungen oder möglicherweise gar nicht machbar ist.

¶ 15:29 0 comments

Der Hammer in Java Performance: Azul

Wir waren auf einen Tipp von Trifork hin beim Vortrag "Breaking Scaling Barriers". Dort wurde zunächst motiviert, wo das Problem steckt: Wir werden bald CPUs mit 4 Cores haben. Wenn man dann einen kleinen Server nimmt, landet man bei 8-16 Cores. Nun gibt es Amdahl's Gesetz, das besagt, dass die Performance von der Menge des serialisierten Codes abhängt. Und zwar sehr stark, so dass wenige Prozent schon tödlich sein können. Also: Serialsierung sollte eliminiert werden.

So weit so gut. Was heißt das für Java? Nun ja, Serialisierung funktioniert mit dem synchronized Schlüsselwort. Dies ist aber zu konservativ. Wenn man bei einer Hashmap Einträge in unterschiedliche Bereiche einfügt, gibt es kein Problem. Die gibt es nur, wenn man versucht, denselben Eintrag zu modifizieren. Als Begriffe wurden Lock Contention (Anwendungen streiten sich um den Lock) und Data Contention (Anwendungen streiten sich tatsächlich um die Daten).

Wie geht man damit um? Datenbanken machen hier Optimistic Locking: Erstmal die Änderungen machen, schauen, ob es Probleme gab, und dann ggf. zurückrollen. Das könnte man bei synchronized ja auch machen. Man muss nur die Datenkollisionen und ggf. ein Rollback machen.

Das genau macht Azul. Dadurch wird synchronized parallel ausgeführt, wenn es keine Data Contention gibt. Dadurch skaliert das ganze beliebig. Allerdings muss man schauen, dass man Data Contention vermeidet. Allerdings wird das Programmiermodell auch viel einfacher. Man kann einfach eine Methode synchronized machen z.B. beim Double Checked Locking Szenario. Dadurch wird es wesentliche einfacher, den Code zu schreiben.

Wir sind danach zum Azul Stand gegangen. Das konkrete Produkt ist eine Art CPU Appliance, die man einfach in's Netz hängt. Dann installiert man ein anderes JDK und die Anwendungen laufen auf der Appliance. Unterstützt werden im Moment Linux und Solaris. Es kommen HP UX, AIX und zLinux. Auf dem Host Rechner tauscht man einfach das JDK aus. Neben dem synchronized Handling hat die JVM auch eine optimierten Garbage Collector, der praktisch verzögerungsfrei arbeitet (40 ms). Die Boxen kommen mit 96, 192 und 384 CPUs. Man kann einfach einen Cluster bauen und die Tasks für die JVM landen dann in dem Cluster. Eine CPU ist ungefähr halb so schnell wie ein P4 und 96 CPUs kosten ca. 100k$ (Daumenzahl!). Die Maschinen können sehr große Heaps verwalten. Die Box kann maximal 256GB aufnehmen. Das ist dann auch die maximale Heap Size und das ist schon recht beeindruckend. Support gibt's übrigens von IBM und damit weltweit und BEA wird es wohl auch demnächst unterstützen.

Interessant sind die Auswirkungen auf die IT Systeme: Man kann einen Cluster aus schnellen CPUs für Java aufbauen. Das ganze kann man zwischen verschiedenen Host Systemen verteilen, die auch unterschiedliche Betriebssysteme haben. Das ganze ist wie Networked Attached Storage, nur eben CPUs. Ansonsten ist das Ding einfach wahnsinnig schnell und cool!

¶ 07:27 0 comments

Hibernate 3

Bei diesem Thema hatten wir die Ehre, Gavin King, den Hibernate Lead, zu erleben. Er gab zunächst einen Überblick über die Hibernate 3 Features. Spannend fand ich die Aufteilung in die unterschiedlichen Projekte:

Die Basic Engine, die Persistenz anhand der bekannten .hbm.xml Files macht.
Hibernate Annotations, was Persistenz nach den JSR 220 Annotationen umsetzt
Der Entity Manager ebenfalls nach JSR 220
Es wird wohl PersistenceManager Plugins für verschiedene Appliaction Server geben.
Einen EJB 3 Microkernel, der
Hibernate Tools für Ant und Eclipse

Er ging dann länglich auf das Thema Vererbung ein. Dort gibt es ja zahlreiche Möglichkeiten, Vererbung in Relationen auszudrücken und dann anschließend lustige Problem, darauf performant Queries zu mahcne.

Interessanter war das Thema der Navigation von Relationen. Hier sieht er vier Möglichkeiten:

Select mit einem Schlüsselwert. Für jeden Wert muss ich dann eine Query machen.
Select mit In ("Batch"). In diesem Fall kann man eine Query und einige wenige Queries verwenden, um für mehrere Werte die abhängigen Werte zu selektieren.
Join über die beiden Tabellen: das impliziet allerdings Eager Loading
Subquery: Erst die eine Tabelle laden und dann von der zweiten Tabelle über einen Join mit der ersten Tabelle die Werte laden.

Das ist schon mal ganz interessant, weil ich auch schon mal an ähnliches Diskussionen mit ähnlichem Ergebnis beteiligt war. Davon getrennt sieht er dann das Thema Eager und Lazy Loading, womit er bis auf Joins auch recht hat.

Diese Sachen soll man in den Quries angeben können, weil sie Use Case spezifisch sind. Auch hier bin ich genau dieser Meinung.

Mit Filter

Ein cooles Feature sind Filter. Damit ist es möglich, in einer Transaktion die sichtbaren Daten einzuschränken. Damit ist z.B. Historisierung bzw. das Arbeiten auf historischen Daten einfach: Man baut einen Filter, der zum Beispiel an einem Zeitstempel die Daten entsprechend selektiert. Mehrere Filter können kombiniert werden. Die Definition ist in XML an den Klassen. In der Session kann man dann einen Filter aktivieren und auch parametrisieren.

Ein weiteres Thema war Batch Verarbeitung. Dabei geht es zum einen um die Verwendung von JDBC Statement Batching und zum anderen um Delete und Update Operationen, die mit einer SQL artigen Syntax mehrere Datensätze mit nur einer Query ändern können. Bei einigen Sachen kann das sehr schief gehen. Wenn man zum Beispiel Sätze aus einer Tabelle und einer abhängigen Tabelle löscht, wird man zunächst die Abhängigen löschen, die an entsprechenden Sätzen in der anderen Tabelle hängen. Dann kommt die andere Tabelle selbst dran. Wenn dieser letzte Schritt aber z.B. von der Anzahl abhängiger Objekte abhängt, geht das schief, weile diese Anzahl 0 ist und daher kein einziger Datensatz gelöscht werden würde. Hier muss man dann eine temporäre Tabelle verwenden. In Hibernate 3.1 kommt hier noch mehr: Insert as Select (sozusagen das Kopieren von Objekten) und Delete Joins, also Löschen mit abhängigen Tabellen.

Fazit

Das sieht recht vielversprechend aus. Hibernate wird ja heute schon breit genutzt. Die Query Features sind genau jene, die ich auch erwartet hätte. Die Batch Sachen sind zum Teil sinnvoll, bei anderen Dingen frage ich mich, warum ich nicht einfach die Kapselung durchbreche und es mit SQL mache. Das ist performanter und möglicherweise auch einfacher. Gerade das Einführen einer temporären Tabelle finde ich sehr unschön.

¶ 06:45 0 comments

WS Interoperability

Wie wir ja alle wissen, haben Microsoft und Sun seit einiger Zeit ein Abkommen, mit dem sie Interoperabilitaet ihrer Loesungen zusichern wollen. Eines der Ergebnisse ist diese Session, in den MS und Sun zusammen genau dies zeigen wollen.

Die erste interessante Beobachtung ist, dass der MS Mitarbeiter tatsaechlich mit einem Applaus empfangen wurde. Und dieser war auch nicht gerade zurueckhaltend. Tja, nach innen gerichtet ist die Java Community vielleicht doch nicht. Im weiteren ging es dann erstmal um den WS-* Stack, in dem vor allem WS-Securityu, WS-Transaction, WS-Reliability und WS-Event (mit Publish/Subschribe) kurz erlaeutert wurden. Ausserdem gab es einen Hinweis auf WS-Management, das noch vorgestellt werden sollte.

Daneben wurden kurz vertikalen Protokolle dargestellt, die fuer bestimmte Industrien standardisiert werden.

Die WS Standardisierung laeuft ueber einen Workshop Prozess: Es werden Workshops abgehalten, dann macht man Implementierungen und holt sich darueber Feedback und dann gibt es wieder einen Workshop. Vor allem in den letzten 6 Monaten scheint sich in dem WS-* Bereich einiges getan zu haben.

Eine Demo...

Es gab dann eine Demo der Interoperabilitaet zwischen Indigo, dem neuen Kommunikationsprotokoll in Windows, das WS-* unterstuetzt, und Java. Das ganze sollte eine langweilige Demo werden, weil man dann ja sieht, wie einfach die Interoperabilitaet ist. Dabei kam auf Java Seite JSR 181 Annotationen zum Einsatz und zwar genau eine an der Klasse. Dazu dann noch ein Deployment Descriptor und das ganze laeuft. Auf dem Client nutzt man WSDL und JAX-WS, um dann auf einen Web Service zuzugreifen.

Auf der anderen Seite war das vorgehen aehnlich einfach mit dem Erzeugen einer Web Service Referenz in Visual Studio .NET. Leider gab es bei dem konkreten Server Zugriff dann ein Problem...

Interessant war noch die Aussage, dass es im Bereich WS-* eine vom Benutzer gewuenschte Bewegung in Richtung Interoperabilitaet gibt und dadurch eine Konvergenz der Plattformen entsteht. Ich bin da nicht so sicher. Vielleicht ist das ganze ja auch so, um durch eine Integration langfristig zu einer Migration zu kommen. Das Problem kam spaeter auch unter dem Motto Interoperate - Innovate zur Sprache. Die Plattformen muessen interoperabel sein, aber auch Innovationen bieten, um Kunden zu ueberzeugen. Das wird nocht interessant...

Message Exchange Pattern

Der naechste Punkt waren Message Exchange Pattern. Dabei gibt es neben Request / Response auch One Way und WSDL 2.0 bringt wohl noch mehr. Das ist nichts wirklich neues. Interessanter ist die Idee einer Konversation, die einen Zustand hat und zwischen zwei dedizierten Partnern laeuft. Das hat ja bisher im Web Services bereich gefehlt, allerdings auch mit Absicht, denn zustandsbehaftet ist eben schwieriger. Weiteres Thema in der Zukunft in Interface Evolution. Auch ein fast klassisches Thema bei verteilten Systemen...

Es wurde am Rande auch die Behauptung aufgestellt, SOA sei Entwickler-getrieben. Dem kann ich nun gar nicht zustimmen, denn SOA definiert eine Strukturierung der Unternehmens IT und bietet Vorteile fuer die Fachbereiche, da die Prozesse flexibler in IT abgebildet werden.

Coole WS-Management Demo...

Die naechste Demo beschaeftigte sich mit WS-Management. Dabei geht es um das Service und System Management mit Web Services. Dazu zeigte ein Microsoft Mitarbeiter, wie man mit der Micosoft Operations Management Console zunaechst einen Sun Server ueberwacht. Dabei kann man auch auf dem Server z.B. vergesteuert eine LED blinken lassen, damit der Operator weiss, welcher Rechner hin ist. Auf dem Sun Server lief uebrigens Windows 2003 Server, daher war das erstmal langweilig. Im naechsten Schritt wurde dann gezeigt, wie man aus einem Sun Server Prozessorluefter entfernen kann, dies wird dann auf der Console angezeigt und man kann letztendlich Solaris und die Hardware runterfahren. Dazu dienst ein Hardware Management Prozessor, der WS Management spricht.

Fazit

Ob Interoperabilitaet wirklich kein mehr Thema ist, hat die Session nicht beantwortet. Irgendwo gibt es wahrscheinlich Probleme und die haette man dann nennen sollen - fuer mich war es zu wenig Praxis. Die WS-Management Demo war cool, aber eher fuer SysAdmins interessant. Es zeigt aber deutlich, dass Web Services nicht SOA sind, sondern auch in Kontexten eingesetzt werden koennen, wo primitive Protokolle wie SNMP eigentlich zu Hause sind.

¶ 03:06 0 comments

In San Francisco nichts neues?

Eine Kritik, die ich gestern gehört habe, war die Bemerkung, dass es auf der Java One im Vergleich zu den letzten Jahren nichts neues gibt. Das erste was ich dazu sagen muss, ist, dass das nicht überraschend ist. Früher war es auch so, dass man auf der CeBIT jedes Jahr etwas gesehen hat, was völlig revolutionär war und die Technologie entschieden weiter bringt. Irgendwann war dann das PC Innovationspotential erschöpft und es wurde langweilig. Für Java ist dies nicht unbedingt eine schlechte Nachricht. Wenn wir glauben, Anwendungen bauen zu können, die Jahrzehnte überdauern (und genau das passiert bei Java), dann muss die Basis stabil werden. Wie es weitergeht kann man dann auch bald im Java Magazin lesen, in dem ich einen Artikel unter dem Titel "Das nächste Java" veröffentliche, der diesem Thema nachgeht. Das ganze ist im Rahmen einer Serie, die Johannes Link koordiniert.

¶ 00:45 0 comments

Trifork L4

Ich war gerade auf dem Trifork Stand hier. Trifork hat jetzt neben dem Profiler P4 auch den Leak Detector L4 auf dem Markt. Er verfolgt ein interessantes Konzept: Zu einem bestimmten Zeitpunkt wird ein Snapshot der Anwendung gemacht, bei dem von einigen Root Objekten aus der gesamte Objektgraph durchnavigiert wird. Diese Root Objekte sind recht wenige, z.B. die Servlets oder EJBs. Anschließend wird dann diese Information genommen und an den Viewer (eine Rich Client Java Anwendung) übertragen. Wenn man nun noch einen Snapshot macht, kann man die beiden vergleichen und herausfinden, wieviele Objekte wo allokiert worden sind. Dadurch sollte man dann den Verursacher des Memory Problems schnell finden. Während der Laufzeit sind wohl kaum Performance Nachteile zu befürchten. Das Übertragen zum Viewer ist dann eine andere Sache. Ich bin auf den praktischen Einsatz gespannt.

¶ 23:54 0 comments

Groovy oder nicht oder was?

Eine Sache, die bisher ein großes Echo erzeugt, ist Groovy. Die erste Sache: Ja, es ist "nur" ein vereinfachtes Java, aber das Ziel, Software Entwicklung einfacher zu machen ist der Ursprung des Fortschritts in diesem Bereich. Und der Wert von Java ist nicht die Sprache, sondern die Plattform mit ihren Features wie z.B. in Java EE.

Die andere Sache ist eher strategisch: Es gibt schon einige Probleme. So die unterschiedliche Syntax des JSR Groovies und des classic Groovy, die eine Portierung erzwungen haben. Das andere Problem ist, dass es im Moment noch keine 1.0 gibt, sondern nur vorläufige Versionen. Warum diese Themen nicht im Vortrag vorgekommen sind, ist mir unklar. Also: Interessante Technologie, ob man das im Moment als zentrales Entwicklungstool verwenden will, ist eine offene Frage.

¶ 22:01 0 comments

Mick Jordan spricht über Isolates, Aggregates und Java Cluster.

¶ 20:28 0 comments

Rod Johnson und Jürgen Höller erläutern den Massen Spring.

¶ 19:59 0 comments

Party...

Dankenswerterweise hatte uns Trifork auf die Trifork, Solar Metric und Tangosol Party eingeladen. War recht nett. Linda DeMichel (EJB 3 Spec Lead) und Patrick Linskey (Solar Metric) waren da, aber mit denen haben wir nur kurz geredet. Wir haben erstmal mit Torben von Trifork geredet. Rod Johnson, Jürgen Höller und Rob Harrop aus dem Spring Bereich waren da und wir haben eine längeres Gespräch mit Jürgen Höller (dem Hauptentwickler) gehabt, das recht spannend war. Dann ging es erschöpft in's Bett...

¶ 17:13 0 comments

Portal Panel

In dieser Session saßen die Repräsentanten der Player (Sun, BEA, Vignette und Pumbtree) im Umfeld dieses Themas im Panel. Eine interessante Sache, die ich mitgenommen habe, ist, dass Portale die GUI einer SOA sind. Ich habe dann die Möglichkeit, eine Integration auf der SOA oder der Portal-Ebene zu implementieren. Wo ich das tue, hängt dann von dem Szenario ab. Sollen die Sachen im Portal nur nebeneinander existieren, mache ich das auf Portal Ebene. Sollen sie wirklich auch Prozesse integrieren, mache ich es auf SOA Ebene.

Vorteile der Portal Produkte gegenüber handgestrickten Sachen sind:

Security Unterstützung und Integration mit vorhandenen Security Lösungen
Plattform für Konsolidierung und dann eine einfachere Administration, weil es nur noch den Portal Server gibt.
Integration mit z.B. Siebel oder SAP schon vorhanden

Ingesamt habe ich hier einiges über das Thema gelernt.

¶ 17:02 0 comments

Clustering mit Java

Dieser Vortrag wurde von Sun Research und zwar von Grzegorz Czajkowski und Mick Jordan bestritten. Mick Jordan war mir irgendwie bekannt und einmal Googeln ergab dann, dass ich auch tatsächlich recht hatte: Er hatte an dem Thema orthogonale Persistenz gearbeitet, was auch an der Uni Hamburg, wo ich studiert habe, ein Thema war. Der macht also nicht erst seit gestern coole Forschung...

Das ganze ging damit los, zu Definieren, was ein Cluster ist. Es kam ungefähr raus: Ein Cluster ist ein System aus mehreren Rechnern. Nun stellt sich die Frage, was in der Java Welt ein System ist. Hier gibt es verschiedene Antworten:

Ein System ist eine JVM
Ein System ist eine Java EE Ablaufumgebung
Ein System ist ein Subset einer Java EE Ablaufumgebung (Servlet Container, EJB Container, JNDI)
Ein System wird durch die Applikation festgelegt. Das ist zum Beispiel bei JGroups oder JINI der Fall.

Es ging dann damit weiter, dass dargestellt wurde, dass Research auf die JVM guckt, während die Produkte auf Java EE Clustering schauen. Böse Zungen behaupten nun natürlich, dass Research grundsätzlich nichts praxisrelevantes macht. Aber ganz ist es nicht. Die Idee ein einziges System Image eines ganzen Clusters zu haben ist zum Beispiel für High Performance Computing durchaus sinnvoll, bei dem System Failure auch recht egal ist, was bei Java EE natürlich eine extrem wichtige Motivation für Cluster ist.

Es gab dann eine Übersicht existierender Research Systeme nach "A Distributed Runtime for Java: Yesterday and Today" (Michael Factor, Assaf Schuster, Konstantin Shagin, IPDPS 2004). Folgende Arten von Systemen wurden unterschieden:

Cluster Aware JVMs
Compileren auf ein Cluster-fähiges System (z.B. Distributed Shared Memory)
Standard JVMs und modifizierter Source- oder Bytecode für die Plattform

Letzteres wird heute am meisten gemacht, da Änderungen an der JVM nicht mehr wirklich trivial sind.

Zusammenfassend ist also das Problem, dass zwischen Produkten und Forschung eine Lücke gibt und Produkte machen daher ad-hoc Lösungen.

Die Frage, die sich natürlich stellt, ist, ob der Ansatz eines einzigen System Images wirklich sinnvoll ist. Außerdem gibt es wohl kaum Angaben über die Performance der existierenden Ansätze und Failure Resistance ist wahrscheinlich ein Problem. Also?

Isolates

Der neue Ansatz sind Isolates,, die in JSR 121 gerade standardisiert werden. Dieser JSR läuft seit 2000, steht aber jetzt im 2nd Public Review und wird wohl wirklich bald abgeschlossen.

Die Idee ist, eine Art eigenen Java Prozess mit eigenem Main starten zu können. Dies kann dann ein eigener Betriebssystem Prozess sein, der potentiell auf einem anderen Rechner läuft. Im Gegensatz zu Threads kann man keine Daten gemeinsam benutzen, sondern muss sie explizit kopieren. Dieses Thema hatte ich auf der JAOO letztes Jahr auch schon mal gesehen und als sehr cool empfunden. Allerdings war es für mich zu dem Zeitpunkt eher eine Möglichkeit, innerhalb eines Application Servers zum Beispiel die JMS Implementierung als eigenen Betriebssystem Prozess zu haben, um ihn dann getrennt mit Ressourcen und Prioritäten zu versorgen. Das ist halt ein Problem, dass man bei Java im Moment hat: Eine JVM ist ein Prozess und Steuerung durch das Betriebssystem sind kaum sinnvoll machbar, weil man nur den ganzen Prozess verwalten kann. Das ist schade, denn genau in diesem Bereich sind Betriebssysteme eigentlich gut...

Cluster und Isolates

Aber zurück zum Thema. Die Idee ist nun:
"A sea if isolates on top of a cluster"

Damit kann man einen Cluster gut abbilden. Die nächste Idee ist ein Aggregate. Dies ist die Menge von Isolates auf einem bestimmten Knoten. Man kann nun Isolates und Aggregates remote steuern und starten.

Das wirklich interessante und für mich neue war dann das Administrieren der Aggregates. Man kann z.B. die verfügbare CPU, Speicher und Netz konfigureiern mit einer Resource Management API. Die kann Resource Domains definieren, den man Isolates zuordnen kann. Dort gibt es dann Warnungen oder echte Beschränkungen, wenn ein Limit überschritten wird.

Das ganze ist recht mächtig. Man kann globale Regeln definieren oder lokale Regeln, also solche, die nur ein Isolate betreffen. Das ganze ist programmierbar und damit sowohl flexibel als auch gefährlich. Ich habe dann noch nachgefragt, ob die globale Sicht über den Cluster nicht nur eingeschränkt sinnvoll ist, weil so ein globaler Zustand eventuell sehr teuer zu ermitteln ist. Die Antwort war, dass er eben nur ermittelt wird, wenn der Code tatsächlich ausgeführt wird und man muss halt wissen, was man tut.

Fazit

Dieses Vorhaben ist extrem wichtig, um im Enterprise in Zukunft noch bessere Java Unterstützung zu haben. Hier - wie auch schon bei dem BEA Vortrag - wird deutlich, dass die JVM immer mehr Ähnlichkeit mit einem Betriebssystem bekommen. Die Frage hier ist allerdings, ob und wann wirklich JVMs kommen, die die Features so umsetzten, wie man das bei Enterprise Anwendungen braucht. Auf jeden Fall bin ich mir unsicher, ob im .NET Umfeld ähnliche Dinge passsieren...

Links

http://research.sun.com/projects/barcelona/

¶ 16:12 0 comments

Pragmatic SOA

In dieser Session ging es um konkrete Erfahrungen mit SOA aus einem Projekt. Erster Punkt war, dass man den ROI (Return on Investment) nach 12-18 Monaten erreichen soll, was bedeutet dass man schnell zu Ergebnissen kommen muss. Dazu gab es folgende Tipps:

Klein anfangen
Opportunistisch sein
Erst wenig Web Services entwicklen
Vorhandene Sachen als Web Services exportieren

Ziel ist dann eine Applikation, die im Netzwerk läuft und Schichten hat.

Kommunikation kann folgende Eigenschaften haben:

lang-läufige Transaktionen
asynchron
zuverlässig
sicher
Policy-getrieben

Dann ging es um das konkrete Projekt: Automative Credit Aggregation System ist ein Joint Venture mehrerer Autohersteller für den amerikanischen Markt.

Ein Problem, dass das Projekt nicht gelöst hat, ist Single Sign On. Die bewährten Best Praticeses fangen damit an, dass Schnittstellen in WSDL definiert werden sollten und nicht aus irgendwas generiert werden sollten. Gleiches gilt für die XML Schemata der Dokumente. Das ist eine logische und bewährte Geschichte.

Die Dokumente kann man dann als String oder direkt in der SOAP Message verschicken. Bei Binaries kann man sie durch SOAP mit Attachements verschicken oder im SOAP Body unterbringen.

Ein Problem, dass sich offensichtlich in der Realität tatsächlich ergibt ist Non-Repudiation (Nicht-Abstreitbarkeit). Dabei geht es darum, dass das Senden einer Nachricht nicht abgestritten werden kann, um auf eine eventuelle juristische Auseinandersetzung vorbereitet zu sein. Hier hilft das Signing von XML Security. Bei zuverlässiger Nachrichtenzustellungen gibt es mit WE-Reliability und WS-Reliable Messaging zwei Lösungen. Orchestrierung dann mit WS BPEL.

Die Tipps zum Abschluß waren:

Das Business muss die Services finden
XML Dokumente sollten definiert werden statt Objekten
Asynchrone Kommunikation ist eine gute Sache

Fazit

SOA ist vielleicht wirklich ein Thema, dass alle 10 Jahre auftaucht, wie gestern einer sagte. Man ist hier doch sehr stark an Mainframe, EDI, MQSeries usw. erinnert. Die Best Practices sind recht logisch und sollten gut etabliert sein. Bei dem ROI sollte man dann wohl gleich anfangen....

¶ 11:10 0 comments

Spring

Das erste Ergebnis des Vortrags stand vor dem Beginn des Vortrags schon fest: Spring ist ein Erfolg. Wodran man das ermessen kann? Nun ja, der Vortrag ist schlicht überlaufen. Die Leute stehen auf der Tribühne und sitzen in den Gängen.

Inhaltlich will ich nicht so viel schreiben, es ging halt um Dependency Injection, AOP und DAO Unterstützung. Interessant sind eher die Sachen am Rande. Rod Johnson fing mit der Präsentation an und hat dem ganzen den Namen: "Agile" Java EE gegeben. Ganz cool.

Ziel ist schnelleres und besseres Java EE durch Einfachheit. Java EE ist zwar sehr mächtig, aber unter Druck vor allem am unteren Ende des Spektrums. Technologien wie .NET, PHP oder Ruby gehören hier zu den Herausforderern. An der Stelle kritisierte Rod vor allem die nach innen gerichtet Java Community auf der Java One. Obwohl ich seine Kritik teile, würde ich bei der Konferenz auch nicht erwarten, dass man über den Java Tellerrand hinausschaut. Es ist schließlich die Java One. Die wirklich schlimme Aussage war aber: "Java EE is considered expensive and slow". Ich kann mir vorstellen, dass dies tatsächlich zutrifft. Es geht nicht darum, ob das tatsächlich so ist, sondern um die Vorstellungen der Manager. Zudem muss man sagen, dass wirklich tragfähige Konzepte für Java EE Architektur noch nicht so extrem lange vorhanden sind.

Das Java EE tragfähig und eine gute Basis ist, wird aber nicht bestritten. Es geht um den Umgang mit Java EE. Einige Problemfelder:

Tests sind zu schwierig
Es entsteht einfach zu viel Code. Petstore ist das bekannte Beispiel.
Schwergewichtige Ablaufumgebung, z.B. für Tests problematisch

Der Sinn der Entwicklung eines In-House Frameworks wurde recht drastisch durch ein Grabstein mit den Jahresangaben 1999-2002 IIRC dargestellt. Ein In-House Framework kann eben nicht von der Erfahrung vieler Projekte profitieren und eine Firma will auch lieber in die Implementierung von Geschäftslogik statt des Frameworks investieren.

Jürgen Höller stellte die technischen Details vor. Interessant war noch die Darstellung von Transaktionen als Killer Anwendung für AOP. Hier wurde auch der Vergleich "EJB++ statt AspectJ" verwendet. Zudem wurde darauf hingewiesen, dass EJB CMT schon das gleiche ist, also das ein produktionsreifes Vorgehen ist.

Das Spring diese Probleme löst, sollte klar sein.

Fazit

Das spannende war die exorbitante Beteiligung, die deutlich zeigt, wie wichtig das Thema sein wird. Auch Rod Johnson hat einige Kommentare in der Richtung gebracht: Spring sei eine der wichtigen Technologien für die Zukunft von Java EE. Er glaubt, dass ein großer Teil der Zuhörer in einem halben Jahr nicht mehr Dependency Injection in Vorträgen kennen lernen müssen, weil ihnen zu dem Zeitpunkt ein Manager gesagt hat, dass sie es einfach verwenden sollen. Das ganze ist mit Sicherheit auf dem richtigen Weg!

¶ 10:43 0 comments

Geronimo

Geronimo ist das Apache Projekt, in dem ein J2EE kompatibler Application Server entstehen soll. Diese Session sollte die Architektur darstellen.

Natürlich ist die erste Herausforderung, andere Projekte zu integrieren. Dann ist ein weiteres Problem, dass man unterschiedliche Szenarien für das Deployment eines Application Servers hat:

Desktop für einen Entwickler
Unmanaged Server, d.h. ein kleiner Server, um den sich sonst niemand kümmert
Managed Server (clustered, in einer Enterprise Umgebung)

Aus diesen Anforderungen ergibt sich der Wunsch nach einem leicht-gewichtigen Kernel als eine non-intrusive Integrations Plattform. Features sind:

Component Registry
Repository
Component Management

Soweit alles Standard. Eine interessante Sache ist der Begriff eines Services als eine Ansammlung von Komponenten, die kollaborativ einen bestimmten Dienst anbieten. Diese soll es auch mehrfach parallel geben können z.B. für Versionierung. Außerdem muss man die Dependencies verwalten.

Dann wurde der Technologiestack vorgestellt. Wie gesagt: Geronimo ist eine Ansammlung von mehreren Services, um einen J2EE Container zusammenzustellen. Hier einige der Technologien (vor allem jene, die nicht aus dem Apache Projekt kommen):

Jetty als Web Container (Tomcat geht aber auch) Coole Entscheidung, die anscheinend darauf basiert, dass von Tomcat niemand Interesse gezeigt hat.
OpenEJB, der wohl auch hohe nebenläufige Belastungen ausgelegt ist
TranOL für JCA
ActiveMQ für JMS
Axis für Web Services

GBean

Basis der ganzen Geschichte sind GBeans und ein Dependency Injection Container. Allerdings hat dieser Container einige andere Probleme zu lösen als z.B. Spring: Er muss langlebige Komponenten mit System Failures, Reboot, parallelen Version und schneller Recovery unterstützen.

Eine interessante Geschichte ist auch der Configuration Builder, mit dem man z.B. aus einem EAR und einem Deployment Plan eine Gesamtkonfiguration bauen kann, die man dann nur noch auf alle Server im Cluster kopieren muss. Das Vorgehen erleichtert natürlich den Umgang mit sehr großen Konfigurationen.

Fazit

Das ganze hört sich danach an, als hätte es Hand und Fuß. Aus dem Vortrag konnte ich keine echten großen Vorteile von Geronimo entnehmen. Insbesondere gibt es das alte Problem, dass ein Java EE Container keine durchgängige Architektur hat. Servlets und EJBs sind beide Komponenten, die eigentlich gleich verwaltet werden sollten. Wenn ich aber einen externen Web Container einbinde, wird das kaum gehen. Was bedeutet das? Den technisch perfekten Application Server gibt es auch hier nicht, aber das ist nichts wirklich neues...

¶ 02:19 0 comments

Meet the Java EE Performance Experts

In dieser Session gab es die Möglichkeit, direkt mit den Leuten zu reden, die bei Sun für diese Themen verantwortlich sind. Ich habe mitgenommen, dass es für JDK 1.5 ein Performance Whitepaper und ein GC Tuning Paper gibt, was schon mal für das neue JDK recht spannend ist. Auch hier war wieder das Thema Community ein Thema. Donnerstag haben sie wohl entschieden, auch auf java.net eine Community zu eröffnen. Das ist sowieso ein Eindruck, den ich deutlich von der Konferenz mitnehme: Die Sun Leute wollen eine Community aufbauen und weisen an jeder Stelle darauf hin. Eine recht interessante Entwicklung.

Es gab einige interessante Aussagen. So wurde aus dem Publikum nach JRockit und seiner besseren Performance gefragt. Die Antwort war, dass das Sun JDK eine breite Palette an Plattformen unterstützen muss und man daher bzgl. Optimierungen vorsichtiger sein will und auch die Qualitätslatte sehr hoch legt.

Eine weitere interessante Frage war, was denn mit den fehlenden Optimierungsoptionen bei JavaC ist. Die Antwort war, dass man by Design keine Optimierungen an dieser Stelle machen will, sondern nur einfaches Compilieren, da alle Optimierungen plattformspezifisch sind und in den JIT gehören. Eine recht interessante Aussage, die letztendlich sagt, dass C++ Compiler wegen der Optimierung bei der Compilierung und dem fehlenden JIT unterlegen sein sollten...

Links

http://java.sun.com/performance/
http://performance.dev.java.net/

¶ 02:05 0 comments

Keynote Scott McNealy

Vor der Keynote hat John Gage noch ein Projekt vorgestellt, bei dem es datum geht, das Einkaufen von Blumen per Handy zu realisieren. Das Interessante ist, dass das Projekt nicht nur in Indien entwickelt worden ist, sondern sogar für den indischen Markt gedacht ist. Dort gibt es angeblich 350 Mill Mobiltelefone und in China nochmal ungefährt dieselbe Anzahl. Auch hier ein Fokus auf mobile Anwendungen - und den Fokus auf diesen Markt wird sich gleich noch deutlicher zeigen.

Dann kam Scott McNealy auf die Bühne. Ich war überrascht, denn auf mich machte er bei weitem nicht den Eindruck, den eine charismatischer CEO machen sollte. Wahrscheinlich war entweder ich oder er noch recht müde.

Die erste Nachricht war, dass die JSR 208 Session vom Vortag am meisten Leute angezogen hatte. Dies bestätigt also, dass dieses Thema sehr wichtig ist. In diesem Bereich war dann auch die wichtige Ankündigung, die McNealy dann machte: Sun hat SeeBeyond gekauft, die im EAI (Enterprise Application Integration) und SOA (Service-Oriented Architecture) Bereich aktiv sind. Produkt ist ICAN, das auf Java EE basiert und angeblich das einzige Produkt in dieser Richtung ist.

Dann kamen Zahlen:

4,5 Millionen Java Entwickler
912 JCP Mitglieder (meistens Firmen, die Java unterstützen)
1 Milliarde Java Cards

Zu letzterem Thema wurde dann ein Herr von Axalto auf die Bühne gebeten. Die belgische Firma alleine 400 Millionen JavaCards verkauft.

Der Rest des Vortrages war eher visionär. Der Kernwert von Sun ist "Share like no other". Das Problem, dass er sieht, ist der Digital Divide: Leute, die noch nie einen Rechner benutzt haben gegenüber Leuten, die das täglich tun. Die nächste Folie zeigte dann die Uno und Bono von U2, die wohl auch in dieser Richtung denken. Ich dachte zwar bisher, Apple sei der IT Partner von U2, aber gut.

Healthcare

Was bedeutet das konkret? Ein Bereich ist Healthcare. Hier würde es sich anbieten, zur Integration der verschiedenen Systeme zu einer SOA Architektur zu greifen, damit nicht dieselben Untersuchungen x-mal gemacht werden und die Daten der Patienten überall verfügbar sind, also auch, wenn man mal auf Reise ist. Interessanterweise kommt See Beyond aus dem Bereich der Integration von Healthcare Anwendungen.

Hier wurde als leuchtendes Beispiel Brasilien angeführt. Dort wurde offensichtlich dieser zentrale Datenbestand realisiert. Brasilien hat eine strategische Entscheidung zugunsten offener Standards und damit Java. Das ganze hat 2,5 Mill. Zeilen Code und wurde in 4 Monaten gebaut. Es ist Open Source und soll auch in Afrika kommen. Die spannende Frage, die sich mir gestellt hat, ist, wie vergleichbar das ganze mit der deutschen Gesundheitskarte ist.

Education

Der andere Bereich, denn McNealy sieht, ist Education. Hier ist aber das Problem, dass es wol kein Geld bekommt. Mehrere Initiativen sind hervorgehoben worden:

Java Education Initiative (JEDI) aus den Phillipinen
BlueJ für das Lernen von Objekt-Orientierung
Global Education Learning Community (GELC)
Student Developer Community

Fazit

Meiner Meinung nach ist inhaltlich nicht viel passiert. JSR 208 und JBI bekommen durch die Aquisition von See Beyond nochmal einen zusätzlichen Fokus. Ansonsten ist es spannend, wie Sun anscheinend auf der oberen Management Ebene tickt. Letztendlich geht es ihnen vor allem darum, die Welt zu ändern und besser zu machen und dass sehr explizit. Bei Schwartz war das noch weniger sichtbar als bei Scott McNealy. Auf jeden Fall ein lohnendes Ziel und eine interessante Art, eine Firma dieser Größenordnung auszurichten.

¶ 15:28 0 comments

Java Web Service Performance

Diese Session hat auf der Ebene der JVM auf die Performance Themen bei Web Services geguckt. Der Vortragende (Eugene Kuznetsov) hatte früher JVMs unter anderem für den Max implementiert (was ihn mir schon sympathisch gemacht hat) und arbeitet jetzt an Web Services Themen.

Der erste Punkt, den er machte, war, dass bei Web Services nicht nur Parsing gemacht wird, was ja immer dem Verdacht unterliegt, langsam zu sein, sondern auch Validierung , Transformationen, XPath und XSLT. Diese Themen sind in Wirklichkeit wesentlich performanceintensiver.

Dann ging er darauf ein, dass Transaktionen pro Minute kaum ein sinnvolles Maß in diesem Bereich ist, weil man nicht weiß, was in den Transaktionen jeweils passiert ist.

Ein Problem aus seiner Sicht ist die Objekt-Allokationen: Beim Parsen von XML werden viele Objekte allokiert, so dass das Demarshalling viel Garbage produziert, auch wenn es nur darum geht, nur ein Objekt zu demarshallen. Seiner Meinung nach ist JAXB hier eine sinnvolle Alternative, weil es weniger Allokationen durchführt.

¶ 14:55 0 comments

Java SE Zukunft

Ich hatte eigentlich gedacht, hier mehr Details zu den neuen JVM Features mitzunehmen. Leider ging es dann um Swing, AWT usw, was mich nicht wirklich interessiert hat. Mitgenommen habe ich:

Java Entwicklungszeit geht laut Sun Umfrage zu 43% um Desktop, 41% Server und 4% mobile.
QNext scheint eine generische P2P Software in Java zu sein. Kann man auch selbst erweitern.
Es gibt unter http://jdk.dev.java.net/ mehr Informationen. Das ganze läuft unter dem Namen "Project Peabody" und kümmert sich um die Features in den nächste Java SE Releases.

¶ 14:43 0 comments

Groovy

Der Name alleine ist schon spannend. Bei Groovy handelt es sich um eine Skriptsprache, die speziell auf die Java Plattform abgestimmt ist. Erstes Indiz ist, dass ein Java Programm auch ein Groovy Programm ist. Warum will man das überhaupt haben?

Wiederverwendung und Glue Code wird deutlich mehr geschrieben als "echter" Code
Ebenfalls wird mehr Testcode geschrieben als echter Code

Groovy ist binärkompatibel mit Java, d.h. es werden auch .class Files erzeugt. Gleichzeitig werden die bekannten Java Datenstrukturen verwendet. Eine Groovy List ist also eine Java List.

Einige Unterschiede:

Groovy kann dynamisch typisiert werden, d.h. Typen müssen erst zur Laufzeit bekannt sein und der Typ einer Variable muss nicht deklariert werden
Eigene und einfachere Syntax für Lists, Maps, Arrays, Beans usw.
Closures, d.h. man kann Codeblöcke an andere Objekte übergeben
Bei der Ausgabe von String werden ${variable} mit dem Variablenwert ersetzt, was "+variable+" überflüssig macht.
Man kann nachträglich Methoden in das System einbauen

Anwendungen: Ant

Die erste interesssante Anwendung ist, dass man in Ant Files Groovy Skripte einbauen kann die über ant. Ant Task aufrufen können. Das ist vor allem interessant, weil es ein historischer Irrtum ist, dass Ant XML Files verwendet. Mittlerweile sagt der Urheber von Ant, dass er heute eher eine Skriptsprache verwenden würde. Mit dem einfachen Zugriff auf die verschiedenen Ant Features scheint dies jetzt leicht realisierbar.

Anwendung: XML und andere hierachische Strukturen

Eine weitere interessante Sache ist, dass man mit Groovy hierachische Strukturen wie XML Daten oder Swing GUIs sehr leicht erzeugen kann. Und es ist wirklich einfach.

Anwendung: Excel Fernsteuerung

Als Live Demo kam dann noch die ActiveX Integration am Beispiel einer Fernsteuerung von Excel. Dies hat er in einer interaktiven Groovy Shell vorgeführt, was extrem cool war. Normalerweise würde ich aus Java nie versuchen, Excel fernzusteuern, aber mit diesen Mitteln war es kinderleicht.

Nachteile & Vorteile

Groovy kommt erst im September als 1.0, wird aber schon sehr produktiv genutzt. Es erreicht 20-90% der Java Performance, aber man braucht nur 50% der Java Entwicklungszeit.

Links

http://groovy.codehaus.org/

¶ 08:00 0 comments

JSR 208 Java Business Integration

Das soll sie also sein, die Session in der uns zwei der Specification Group Mitglieder vermitteln, was JSR 208 so sein soll und wie die Integration von Geschäftsprozessen mit Java so funktionierne soll. Um eine lange Geschichte kurz zu machen: Ich habe nur wenig aus der Session mitgenommen.

Das erste interessante ist, dass in diesem Bereich genug proprietäre Ansätze vorhanden sind, so dass eine Standardisierung sinnvoll erscheint. Dies ist anders als bei EJB, wo ich deutlich das Gefühl habe, dass der Standard erst den Markt geschaffen hat. Der Stand des JSR ist, dass er fertig ist, aber im Moment noch nur der Public Final Draft verfügbar ist.

Inhaltlich legt die Spec anscheinend fest, dass es im wesentlichen einen Normalized Message Router gibt, der verschiedene Kommunikationsprotokolle (WS-I Basic SOAP, JMS, ...) und verschiedene Logik zum Konvertieren von Nachrichten enthalten soll (BPEL, XSLT, Java EE, ...). Das ganze ist WSDL 2.0 inspiriert. Die Nachrichten werden durch XML Sachen beschrieben, können aber auch anders vorliegen. Außerdem können die Nachrichten auch Meta-Daten enthalten. Der Message Austausch ist nicht reliable, d.h. bei einem Crash können die Nachrichten verloren gehen und dieses Problem soll auf der Applikationsebene gelöst werden. Hier kann man durchaus geteilter Meinung über den Sinn sein, aber es wurde auch gesagt, dass Transaktionen unterstützt werden und von daher hier noch einiges möglich ist. Allerdings gab es hier keine Details.

Interessanterweise hat man auch beim Programmiermodell gelernt: Man kann die komplette Mächtigkeit der Plattform verwenden und ist nicht durch ein eigenes Programmiermodell eingeschränkt, wie dies z.B. bei EJB der Fall ist.

Zudem ist auch das Modell für die Administration standardisiert, d.h. es gibt einen vollständig portablen, JMX basierten Installationsprozess. Etwas, was bei Java EE oder EJB bisher so auch nicht existiert hat.

Idee ist, ein Marktplatz für JBI Plattformen und Plug Ins zu schaffen.

Fazit

Anhand dieser Session alleine lässt sich nicht viel sagen. Es ist halt das übliche EAI Konzept. Aber es wird recht viel Hype aufgebaut. Schauen wir mal.

Links

http://java.sun.com/integration/

¶ 07:40 0 comments

BEA Keynote

Eigentlich wollte ich nur aus Mitleid zu der BEA Key Note gehen: Die Firma hatte ja in letzter Zeit einen deutlichen Brain Drain im Management und der J2EE - ich meine natürlich Java EE - Markt ist z.B. durch JBoss sehr unter Preisdruck. Aber dann kam alles ganz anders...

Das neue Motto von BEA ist "Think Liquid", was darauf hinweisen soll, dass man sich zum Ziel gesetzt hat, die eingefrorenen IT Systeme "aufzutauen". Das ist ja eine Sache, die zum Beispiel auch zu den Zielen von SOA gehört und mit Sicherheit ein valider Ansatz ist, aber die Frage aufwirft, was man denn da noch neues machen kann. Allerdings ging Mark Carges (CTO) nicht ein.

Expansion und Vereinfachung mit Frameworks

Stattdessen fing er mit den Themen Expansion und Vereinfachung an. Seiner Meinung nach sind Frameworks der größte Produktivitätssprung seit IDE. In diesem Bereich sieht er Beehive, was ja auch eigentlich von BEA kam, und richtig: Spring. Gleichzeitig sieht er den Application Server nur noch als Runtime für Anwendungen, die mit solchen Frameworks gebaut werden. Das ganze ist natürlich recht komisch, weil er damit eigentlich sagt, dass BEA einfach keinen wirklich wichtigen Markt hat, sondern nur noch eine Ablaufumgebung baut.

Die Frameworks bringen mit POJOs, Dependency Injection, Metadaten und AOP eine wesentliche Vereinfachung. Dabei habe ich noch den interessanten Gedanken mitgenommen, dass Annotations und XML im Prinzip nur zwei unterschiedliche Formen von Metadaten sind. In Spring ist das ja auch sehr gut zu sehen, denn Transaktionen kann man genau so steuern: Entweder mit einer Konfiguration eines Pointcuts in der XML Konfiguration oder mit Annotationen im Code.

So weit hat er also sehr deutlich die Probleme angesprochen, die ich auch bei BEA gesehen hatte, ohne sie als Probleme zu bennene. Dann kam der Lösungteil.

Als erstes gibt BEA der Entwicklung im Enterprise Umfeld den Namen "blended mode": Es werden kommerziellen und Open-Source Tools zusammen eingesetzt.

BEAs Anwort

An dieser Stelle muss man natürlich - klassischer Vertrieb - klarmachen, dass es dennoch Probleme gibt, die man lösen muss. Hier sieht er vor allem:

Integrations Tests
Developer und Adminstrator Werkzeuge
Plattform Migration

BEA will zunächst bestimmte Frameworks auf WLS zertifizieren, was bedeutet, dass BEA selbst Unterstützung für diese Frameworks anbietet. Darunter fallen Spring (zusammen mit Interface21), Struts, Beehive und JSF. Das ganze geht dann anscheinend mit WLS 9 los.

Der nächste Punkt ist BEA Workshop. Die IDE wurde schon auf die Eclipse Plattform portiert. Jetzt soll BEA Workshop zum einen Beehive, Spring und Struts als Frameworks unterstützen. Bei den Servern soll es WLS, Geronimo und Tomcat sein. Hier fragt man sich, warum BEA überhaupt andere Server unterstützen will. Die Antwort ist, dass man einfache Migration auf WLS anbieten will, wenn man aus Tomcat "herauswächst", weil man Transaktionsunterstützung (JTA) braucht.

An dieser Stelle kamen dann Rod Johnson (Interface21 und derjenige, der das Spring gestartet hat) zusammen mit einem BEA Mitarbeiter auf die Bühne, um die Spring Integration zu zeigen. Er geht nochmal darauf ein, dass Spring Anwendungen bereits sehr breit in Produktion sind. Er sieht vor allem den Vorteil, dass man die Freiheit hat, eine beliebige Infrastruktur auszuwählen.

Konkret gibt es nun eine Unterstützung für die proprietären WLS Transaktionen in Spring und umgekehrt eine auf der JMX Integration basierende Lösung zum Monitoren von Spring Bean mit WLS Werkzeugen.

Was bedeutet das nun? Spring ist so wichtig, dass BEA sich damit beschäftigt. Gleichzeitig bin ich unsicher, ob es eine gute Idee von Rod Johnson war, mit BEA dieses Abkommen zu schließen. Es bedeutet zwar ein offizielles Siegel des Vertrauens von BEA, was man wohl kaum unterschätzen kann, und eine Service-Organisation, die Spring unterstützt. Auf der anderen Seite bedeutet es, dass sich mindestens Interface21, aber vielleicht auch Spring in die Nähe von BEA stellt, die aber eben nur einen Teil des Java EE Markts darstellen. Aber kaum jemand wird dies so wahrnehmen, dass Spring eine BEA-only Sache wird. Zumal BEA auch noch Beehive hat, das gegen Spring positioniert ist.

Dennoch hat BEA immer noch das Problem, dass es sich neue Märkte erschließen muss. Auf genau diesen Punkt wird als nächstes eingegangen.

Neue JVMs braucht das Land

Das erste Problem, dass er addressiert, sind JVM. BEA hat hier mit JRockit auch ein Eisen im Feuer, dass nun auch von der Intel/AMD auf die SPARC Plattform portiert werden soll. Nun sollte man denken, dass das Thema JVMs nach 10 Jahren endlich irgendwie gelöst ist, aber es gibt immer noch Probleme. Ein Thema ist Unterstützung der Administratoren. Hier ist BEA JRockit schon jetzt sehr gut. Das nächste Thema sind Memory Leaks. Die JVM ist recht offensichtlich eine sinnvolle Stelle, um diese Art von Problemen zu finden und zu analysieren, ohne dabei die Performance total in den Keller zu bringen. An dieser Strelle kann man dann auch Statistiken und Performance Daten erheben. Hier sieht BEA einige Herausforderungen. Ein anderes Thema ist deterministische Garbage Collection, also Garbage Collection, die eine vorhersagbare Zeit braucht. Nur damit kann man Entzeitansprüche befriedigen. Das ist zum Beispiel wichtig, wenn man in der Telekommunikation bei Switches etwas ausrichten will.

Eine weitere wichtige Sache ist Virtualisierung. Zur Zeit spielt dies Thema mit Virtual PC eine Rolle. Dieses Produkt war Microsoft so wichtig, dass es gleich die Firma gekauft hat. Das andere Produkt ist VMWare. Das Verfahren ist recht alt, denn es war schon bei Mainframes gang und gäbe. Jetzt wird es wohl bald Hardware Unterstützung in der Intel Welt für Virtualisierung geben. Damit wird in der JVM eine direkte Unterstützung für diese Features der Chips denkbar, der dann dazu führt, dass die JVM Funktionen übernimmt, die früher das Betriebssystem hatte. Dies ist dringend sinnvoll, denn nur so kann man wirklich feingranulare Administrator und gute Skalierbarkeit ermöglichen.

Neue Betätigungsfelder

Wenn man dann diese Features auf JVM Ebene hat, kann man auch ganz andere Felder für Java erschließen. Ein Bereicht ist Telekommunikation. Hier hat BEA schon ein Produkt, dass neben Java EE auch Voice over IP (VoIP) und SIP für Internet Telefonie unterstützt. Hier gibt es mit JSR 116 auch schon ein Standard für SIP Servlets.

Ein anderer Anwendungsfall ist RFID, bei dem viel mehr Clients auftreten (im Bereich von >100Mill). Hier will man schon am Rand des System, also direkt an den RFID Sensoren, Geschäftslogik haben will wie Filter oder Events. Dort muss man dann sicher eine andere (light-weight) Infrastruktur haben und eher kein großen Application Server.

Das interessante ist nun, dass im Finanzbereich ähnliche Anforderungen existieren. Dort gibt es Markt Ticker, Order Daten und Newsfeeds, die Events erzeugen, auf die dann eine Business Logik in einer bestimmten Zeit reagieren muss. Hier wird das Thema Prädikate interessant, also die Möglichkeit, Events mit Meta Daten zu versehen und anschließend zu filtern.

Abschließend fasste er nochmal zusammen, dass JVMs und Server Frameworks wichtige Themen sieht. Als die neuen Anwendungsfelder von Java EE sieht er große Systeme, die Event basiert sind. Daher sind hier technisch auch (verteilte) Caches und modularisierte Server notwendig.

Fazit

Ingesamt hat mich der Vortrag überzeugt. Im Bereiche Java EE geht BEA den sinnvollen Weg, die vorhanden Frameworks zu nutzen und zu unterstützen. Die neuen Themen wie JVM und Event-basierte System finde ich unbedingt sinnvoll und ich bin mal gespannt, was für Anwendungen daraus entstehen.

¶ 01:32 0 comments

10 Jahre ist Java jetzt schon alt...

¶ 21:50 0 comments

Die JavaOne ist groß. Sehr groß. Riesig. Angeblich sollen 15000 Leute kommen...

¶ 21:39 0 comments

Der Anfang

Die JavaOne hat angefangen mit der Einführung durch Jonathan Schwarz (COO) und einigen anderen Leuten aus dem Software Bereich. Schwarz hat in den Mittelpunkt seines Vortrages das Thema Communities und Participation gestellt. Java sieht er als die Grundlage einer ganzen Menge von Anwendung, wenn nicht vom ganzen Web.

Mobile Java

Ein wichtiger Eindruck für mich ist der Einfluss der mobilen Endgeräte auf Java. Inzwischen gibt es mehr Java-fähige mobile Endgeräte als Java-fähige PCs und dieses Thema führte in der Veranstaltung auch durch einen entsprechenden Fokus. So hat zum Beispiel Research in Motion, die den Blackberry für mobile EMails herstellen, Java Anwendungen gezeigt. Ein Herr von NTT Docomo (japanische Telefongesellschaft) stellte dar, dass von den 10 Mrd $, die sie mit mobilem Content machen, 6 Mrd $ auf Java basieren. Gespannt bin ich hier, was außer mobilen Spielen noch kommen wird.
Ein anderes interessantes Thema scheint JSR 208 (Java Business Integration) und die darauf basierende SOA Vision zu sein.

Sun NeWS

Die gesamte JavaOne hat einen deutlichen Sun Fokus und so gab es dann einige Infos von Sun. Zum einen will Sun seinen Application Server und sein Enterprise Service Bus Produkt (das JSR 208 implementiert) Open Source machen. Schwarz stellte dies als etwas dar, was Sun in Zukunft noch öfter machen wird. NetBeans wird in der gesammten Veranstaltung gepusht und es wurde dann gezeigt, wie einfach es ist, mit NetBeans eine AJAX (Asynchronous Java and XML) Anwendung zu bauen. Dabei handelt es sich um Anwendungen, die wie GMail oder Google Maps mit JavaScript dynamisch das DOM des HTML Dokuments ändern und zwar anhand von XML Daten, die vom Server kommen. Dieses Modell erlaubt wesentlich interaktivere Web Oberflächen. Ein weiteres Thema ist dtrace, mit dem man unter Solaris das Verhalten von Anwendungen tracen kann, und zwar coolerweise über die Ebenenen Java - C Libraries - Kernel hinweg, was integrierte Performance Untersuchungen erlaubt. dtrace ist übrigens auch Open Source und Solaris kostenlos...
Sehr spannend fand ich dann, dass Sun jetzt eine neue Workstation mit AMD Prozessor anbietet. Nun gut, das Business ist eigentlich tod. Aber Sun bietet die Maschine mit einem Service Vertrag und aller Software(u.a. Entwickler Tools) an und das für 30$/Monat. Weitere Kosten gibt es nicht. Das ist das erste Mal, dass ich mitbekomme, dass man das Handy Business Modell auf Hardware ausweitet.

IBM und Java
IBM hat nochmal sein Commitment zu Java bestätigt. Alle Enterprise IBM Produkte (WebSphere, DB2) werden interessanterweise auf Solaris AMD und Sparc portiert. Außerdem hat IBM die Java Lizenz um weitere 11 Jahre verlängert und sie sprachen "von den Dekaden, die noch kommen." Vielleicht ist das wirklich die Größenordnung, in denen man bei Java irgendwann denken muss...

Wie geht es weiter mit Java?
Eine weitere Änderung ist auf der Namensebene: J2EE heißt jetzt Java EE, J2SE Java SE und J2ME Java ME. Die Versionen haben jetzt kein .0 mehr, wahrscheinlich um die Entwickler, die keine .0 Version verwenden, zur Mitarbeit zu überreden. Das nächste Java ist also Java SE 6 und kommt Sommer 2006. Die Releasezyklen sollen 18 Monate lang werden, Java 7 kommt also Anfang 2008.
Neue Features:

Ease of Developement

Management (JMX in Java 5 war ja ein Anfang)

JSR 223 Scripting Language Interface (Javascript, Rhino Implementierung)

JSR 221 JDBC 4.0 mit mehr Annotations
Javadoc Erweiterungen

Desktop

Java SE 6 wird Longhorn Look and Feel haben
noch ein paar Punkte u.a. Java 2D mit besserem Text Rendering und OpenGL / Direct3D Nutzung

More Open

Unter http://mustang.dev.java.net gibt es die weekly build
Man kann selber Sachen einreichen (Bug Fixes/Features)
Dafür gibt es auch Mentoren (!)
...und man darf neuerdings auch eine modifizierte JVM nutzen, z.B. wenn man einen Bug selbst fixen will, um seine Anwendung produktiv zu bekommen

Auf technischer Ebene wird Mustang (Java 6) zum Beispiel auch in die JVM neue Bytecodes einbauen, um dynamische Sprachen (z.B. Jython) besser zu unterstützen. Ansonsten soll es neues in NIO geben, XML soll einfacher werden, Friend Sichtbarkeit über Package Grenzen (ein widerliches C++ mäßiges Feature, wie ich finde) und Method References.

Java 2 EE wird vor allem einfacher werden, um auch für Leute, die 2 Tier Anwendungen und einfache Web Anwendungen bauen, attraktiv zu werden. Das wissen wir ja schon länger und auch inhatlich gab es dann wenig überraschendes. So soll die Vereinfachung erreicht werden durch:

Fokus auf POJOs
Annotations für Web Services, XML, EJB und Datenbank Mapping
Dependency Injection

Features gibt es vor allem im Bereich

Web Services
EJB
Persistence
Java Server Faces (JSF)

Ob das jetzt wirklich glücklich macht, sei dahin gestellt, denn diese Dinge kann man eben auch heute schon auf die eine oder andere Weise erreichen, z.B. kommt einem ja spontan Spring in den Sinn. Auf der anderen Seite ist es einfach die Richtung, in die Java EE gehen muss, denn dort warten die besten Möglichkeiten für eine weitere Expansion. Es ist also eigentlich nur ein Streit um die Methoden, nicht aber um das Ziel. Solche Streits sind jedoch meistens die härtesten.

¶ 21:06 0 comments

Über mich