W-JAX am Dienstag 10.11.

Resumée W-JAX vom 10.11

Da dies mein erster Besuch auf der W-JAX war, war ich natürlich ordentlich gespannt, wie die einzelnen Sessions wohl ablaufen werden.

Eröffnet wurde der Tag mit einer Keynote von Ted Newark, der etwas provokative Titel „Why the next five years will be about languages“ liess schon einiges Versprechen.

Ich sage mal, ich habe selten einen so kompetenten Speaker wie Ted erlebt, mit Wortwitz und Eloquenz konnte er mich durchaus überzeugen.

Idee hinter der Keynote war hauptsächlich, herauszuarbeiten wieso das Thema Languages die letzten paar Jahre (Jahrzehnte?) nicht wirklich relevant für das tägliche Business war.

Die Essenz der Aussage von Ted hierauf war, das Sprachen typischerweise im akademischen Bereich entwickelt werden. Der Fokus einer akademischen Arbeit ist üblicherweise aber der, einer „akademisches“ Problem zu lösen. Ist dieses akademische Problem gelöst, verliert sich das Interesse an der Weiterentwicklung dieser Sprache in den meisten Fällen leider sehr schnell.

Versuchte man also früher, als Entwickler eine „neue“ Sprache zu verwenden, stiess man sehr schnell an die Problematik, dass die Funktionalität einer Sprache über diese spezifische Problemstellung hinaus dürftig, wenn überhaupt vorhanden war (humoristisches, leicht übertriebenes Beispiel von Ted war die Frage, wie greife ich in einer hypotetischen Sprache auf eine relationale Datenbank zu? Die Antwort hierauf, „Relational Databases? I never heard of this new Thing??“. Es herrscht wohl die Meinung vor, dass Sprachen üblicherweise von Professoren entwickelt werden, die mindestens ein Jahrzehnt nicht mehr draussen in Projekten waren;-).

Heute scheint es möglich zu sein, seine eigene „einfache“ Sprache innerhalb von einem Tag zu entwickeln, und zwar nicht von Akademikern, sondern vom Standardentwickler wie auch ich einer bin. Eingie Beispiele zu neuen Sprachen, die natürlich zur Sprache kamen waren Groovy, Ruby, Scala etc. Insgesamt stimmte die Keynote auf einen erfolgreichen Tag ein.

Die zweite Session die ich besucht habe war geleitet von … Hierbei ging es darum, die Neuigkeiten in JEE6 gegenüber JEE5 und sogar J2ee herauszuarbeiten. Der Vortragsstil des Referenten ist als durchaus „nüchtern“ zu beschreiben, da wünsche ich mir doch ein wenig mehr Enthusiasmus, nichts desto trotz war es für mich interessant, mal zu hören, was denn alles so zu kommen scheint. (Ich habe in meiner täglichen Arbeit eher weniger mit EJBs etc.. zu tun, deswegen muss ich leider eingestehen dass ich hier nicht mehr so ganz auf dem laufenden bin).

Der Referent berichtete aus seinem täglichen Projektgeschäft und speziell von einem Projekt zur Erstellung eines FTS ( Führerlosen Transportsystems auf Basis von EJB und Java, als Frontend kam ein Swing Client zum Einsatz).

Meiner Ansicht nach interessante Änderungen die mit EJB 3.1 komme sind:

  1. @Singleton-Annotation : hierbei bietet die Spec die Möglichkeit, eine EJB wirklich nur einmal (pro JVM) zur Verfügung zu stellen. Könnte sich durchaus eigenen, um Applicationsettings einmalig global zu setzen. Hieraus ergeben sich natürlich recht interessante Multithreadingproblematiken, was ist zum Beispiel, wenn mehrere Clients gleichzeit auf die Singleton Instanz zugreifen? Hier bietet die Spec einigre interessante Annotations, mit denen das Locking geregelt werden kann (@Lock(READ oder WRITE) oder @AccessTimeout.
  2. Endlich, standardisierte JNDI-Namen für EJBs , und zwar Herstellerunabhängig nach dem Pattern java:global/<app>/<module>/beanImpl:Interface, keine Ahnung wieso das nicht schon früher kam.
  3. Timerservice (@Timeout, @Schedule etc., müsste man sich mal im Detail anschauen)
  4. @Asynchronous, wir haben jetzt die Möglichkeit, eine Session-Bean-Methode asynchron auszuführen, d.h. Die Methode kehrt sofort zurück und liefert bei Bedarf ein Future (JDK 1.5), mit dem das Ergebnis abgefragt werden kann.
  5. Die Möglichkeit, einen EJBContainer lokal programmatisch durchzustarten (für beispielsweise UnitTests : EJBContainer.createEJBContainer(), über diesen bekommt man beispielsweise einen Context, mit dem alle EJBs abgefragt werden können). Extrem cooles Feature!!
  6. Man braucht keine Interfaces mehr (@LocalBean)

Container die EJB3.1 aktuell schon unterstützen sind Glassfish V3, Jboss 5.2 und OpenEJB.

Die dritte Session des Tages trug den verheissungsvollen Titel „EJB in the Large“. Die Referentin war direkt aus Brasilien eingeflogen, um aus Ihrer täglichen Arbeit zu berichten. Das Projekt das hier beschrieben wurde ist als durchaus eindrucksvoll zu bewerten. Es wurde beschrieben, wie ein „Health Care System“ für die Stadt „Sao Paolo“ in sage und schreibe 9 Monaten entwickelt wurde, und zwar auf Basis von EJB 2.1, Entity Beans, Xdoclet, Drools, Luntbuild und CrossDB. Das System konnte täglich ca. 1 Mio Anfragen bearbeiten, was zusammen mit der eingesetzten Technologie schon beinahe Sagenhaft ist.

Auch die Ansätze die die Referentin (gleichzeitig Projektleiterin) gewählt hat, waren sehr interessant. Insgesamt waren in dem Projekt ca. 70 Entwickler beschäftigt aufgeteilt in 3 Teams, teilweise EJB Experten, teilweise aber auch nicht. Am Ende bestand das Projekt aus 600!! EJB-Instanzen (für jeden Use-Case wurde eine eigene SessionFacade erstellt). Der Persistenzlayer wurde mit EntityBeans realisiert. (Aber nicht komplett, denn beispielsweise wurde aus Performancegründen komplett auf das Queriying mittels EntityBeans verzichtet. Dies wurde separat mit einem SQL-Framework CrossDB erstellt).

Der Vortrag an sich konnte leider wenig beeindrucken. Abgerundet wurde das Ganze von einem „Film“ gedreht von Sun, der ca. 10 Minuten dauerte. Ich habe derweil versucht, meine Eindrücke ordentlich zusammenzuschreiben;-).

Der Vortrag bestand eigentlich aus zwei Teilen. Im zweiten Teil sollte die Migration auf EJB 3 beschrieben werden, aufgrund des eher dürftigen ersten Teils habe ich mich aber entschlossen, den zweiten Teil auszulassen.

Als nächstes kam die Keynote von Adam Bien („The Future of Enterprise Java“). Gewohnt souverän versuchte hier Adam Bien die rosige Zukunft von Enterprise Java zu bestätigen, und das prognostizierte Aussterben von EJB zu widerlegen;-).

Das Fazit, dem ich mich persönlich durchaus anschliesse, EJB wird in nächster Zeit nicht aussterben! Good news!

Der nächste Workshop hatte den Titel „JPA under the Hood“ und wurde gehalten von Alois Reitbauer.

Kern des Workshops sollte es sein, herauszuarbeiten, wie sich verschiedene Persistenzframeworks für bestimmte Use-Cases verhalten (untersucht hat der Speaker Hibernate, EclipseLink und OpenJPA). Hierbei wurden u.a. die UseCases ObjectCache und QueryCache betrachtet.

Sehr interessant war für mich hier die vom Speaker eingesetzte Software. Die zentrale Frage hierbei war, kenne ich mein System wirklich, wenn ich nur die Interfaces kenne? (JPA? Hallo?).

Erste Frage: Das Query „select User u where u.id=1“

Essenz: Niemals feste Parameter in Queries kodieren, denn diese Queries können nicht im Querye-Cache landen und werden vom ORM-Framework immer und immer wieder ausgeführt.

Interessanterweise checkt sowohl OpenJPA als auch EclipseLink, dass es den Parameter hierzu ersetzen muss (gespeichert wird also die Query „select User u where u.id=?“.

Hibernate hingegen setzt tatsächlich die nicht parametrisierte Query ab.

Zweite Frage:

Was passiert, wenn der User geladen wird, eine Änderung in der Datenbank gemacht wird und dann diesselbe Query erneut abgesetzt wird?

Antwort: Die Änderungen aus der Datenbank werden nicht geladen, weil die Persistenzframeworks auf Objektidentität prüfen und bemerken, das der User mit der bestimmten ID bereits im Cache vorhanden ist. Durchaus überrsaschend, wenn auch logisch.

Dritte Frage:

Ist „getReference“ tatsächlich sinnvoll? GetReference() bietet die Möglichkeit, eine Referenz aus einer Klasse zu laden, ohne das die eigentliche Klasse wirklich geladen werden muss. (Beispielsweise kann man eine AdressEntity eines Users laden, ohne das der User komplett geladen werden muss).

Ergebnis: Ja, das funktioniert sowohl in Hibernate als auf OpenJPA. EclipseLink lädt leider standardmässig trotzdem alles aus der Datenbank, vorsichtshalber.

Vierte Frage:

Wieviele Connections werden erzeugt, wenn man in einem Loop ständig neue Sessions anfordert?

Antwort: Ohne Transaktionen, eine. Mit Transaktionen erzeugt Hibernate für jede angeforderte Session eine eigene Connection (autsch!).

Eergebnis: Es wäre schön, wenn alle Persistenzframeworks einen gemeinsamen Defaultstandard hätten. Ist aber nicht der Fall…

Im nächsten Workshop ging es um die Specs JSR-299, 330 und 340. Der Referent war Werner Keil, leider habe ich bisher keinen so schlechten Vortrag gehört, deswegen habe ich die gesamte Session versucht, mein Wlan ans Laufen zu bekommen;-).

Die Letzte Session war definitv das Highlight des Tages : Live on Stage Jave EE 6 Hacking mit Adam Bien.

Unter anderem wurden einige SessionBeans erstellt, Restful-Zugriff, JSF 2.0 Seiten, JPA Entities etc.. immer wieder ein Spass, Adam zuzuschauen.

Bin schon gespannt, was morgen kommt.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s