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
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
