J and I and Me
2005-06-28
 
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:
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.
 
Bookmark and Share
Comments: Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff