Enterprise Tales

Enterprise Tales: Welches JavaScript-Framework passt zu mir?

Noch vor wenigen Jahren von vielen Enterprise-Entwicklern als Unheil bringendes Voodoo abgetan, gewinnt JavaScript in modernen Webanwendungen mehr und mehr an Bedeutung. Entsprechend groß ist auch der Zoo an wunderverheißenden Frameworks, aus denen es das passende zu wählen gilt. Wie so oft im Leben gilt leider auch hier: „Wer die Wahl hat, hat die Qual“.

Enterprise Tales: MVC 1.0, das Aus für JSF?

Dass Java EE 8 mit einem neuen, MVC-basierten Webframework (JSR 371) aufwarten wird, sollte sich mittlerweile herumgesprochen haben. Genauso wie die Tatsache, dass nicht wenige Mitglieder der Java-Community den Sinn eines weiteren Webframeworks innerhalb des Enterprise-Java-Standards in Frage stellen. Zum einen bekommt der bisherige Platzhirsch JSF Konkurrenz aus den eigenen Reihen. Zum anderen gibt es bereits MVC-Alternativen außerhalb des Standards. Muss das neue Framework also wirklich sein?

Es tut sich was im Web: Servlet 4.0 mit HTTP/2

Mit jeder neuen Java-EE-Version gibt es auch eine neue Servlet-Version. Diese Regel gilt schon seit J2EE 1.2, und sie wird auch mit Java EE 8 Bestand haben. Der Plan lautet, dass mit Java EE 8 Servlet 4.0 ausgeliefert wird. Neu ist allerdings, dass die neue Servlet-Spezifikation auf einer neuen HTTP-Version basiert. Alle bisherigen Servlet-Versionen seit 2.3 basieren auf HTTP/1.1, das es seit 1999 gibt.

Version 2.0 der CDI Specification auch in Java SE nutzbar

Bisher ist CDI ein Komponentenframework, das Dependency Injection zur Verfügung stellt, allerdings nur für Java-EE-Anwendungen. Die aktuell gültige Version ist das Maintenance-Release 1.2. Wie wir bereits in der letzten Kolumne berichteten, hat die Spezifizierung von CDI 2.0 aber schon begonnen. Und sie bringt ein durchaus interessantes Feature, mit dem es möglich sein wird, CDI auch außerhalb eines Java-EE-Containers standardisiert zu benutzen. CDI soll in Java SE nutzbar werden. Wir werden in dieser Kolumne vorstellen, wie das API aussehen könnte und was noch fehlt.

Asynchrone Events in CDI 2.0

CDI ist seit der Version 1.0 in Java EE 6 der neue Enterprise-Komponentenstandard. Während es mit CDI 1.1 in Java EE 7 nur ein Minor Update gab, kann für Java EE 8 wieder mit einem größeren Entwicklungsschritt gerechnet werden. Die Spezifizierung von CDI 2.0 hat bereits begonnen. Eines der Themen, die auf der Agenda stehen, ist die asynchrone Verarbeitung von Events. Wir werfen in dieser Kolumne einen Blick auf den aktuellen Stand der Spezifikation und geben einen Ausblick darauf, was für Möglichkeiten asynchrone Events bieten.

Alles valide? Bean Validation in POJOs mittels aspektorientierter Programmierung

Wir berichteten im Rahmen dieser Kolumne bereits über die Neuerungen von Bean Validation 1.1. Besonders erwähnenswert war und ist dabei das neue Feature der Method Validation. Leider ist die Integration dieses Features noch nicht sehr weit vorangeschritten. Bisher ist es nur bei CDI-Beans möglich, sich darauf zu verlassen, dass z. B. ein Parameter, der mit @NotNull annotiert ist, auch wirklich niemals null ist. In allen anderen Situationen hilft es normalerweise nur, die Method Validation aus dem Code heraus „von Hand“ aufzurufen. In dieser Kolumne wollen wir eine alternative Möglichkeit vorstellen. Damit ist es möglich, in beliebigen POJOs auf Method Validation zu setzen.

Testen im Kontext: Integration Testing in Java EE

„Der Begriff Integrationstest bezeichnet […] eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dienen, verschiedene voneinander abhängige Komponenten eines komplexen Systems im Zusammenspiel miteinander zu testen.“ (Wikipedia). Wie kann ich aber eine Menge an abhängigen Komponenten (also in Java EE z. B. EJBs oder CDI-Beans) gemeinsam testen, ohne das Ganze gleich auf meinem Testserver deployen zu müssen? Das Problem ist klar: Moderne Enterprise-Anwendungen basieren auf Dependency Injection. Das bedeutet, dass der Container die Abhängigkeit zwischen den Komponenten auflöst und gegenseitig in die Komponenten injiziert.

Reduce to the Max: Microservices

Es gibt wohl kaum ein Thema in der Softwareentwicklung, das derzeit so heiß diskutiert wird wie die Wunderwelt der Microservices. Von „einfach genial“ bis hin zu „alter Wein in neuen Schläuchen“ trifft man auf die unterschiedlichsten Meinungen. Nicht selten begründen sich dabei die verschiedenen Einstellungen der Diskutanten schon in der Auffassung, was sich denn genau hinter dem Begriff „Microservices“ verbirgt. Grund genug für EnterpriseTales, einen Blick hinter die Kulissen zu wagen.

Wenn Scopes fremdgehen: Mehr Spaß mit CDI-Scopes

Eine klassische Webarchitektur besteht mindestens aus einer Serviceschicht, die in CDI @ApplicationScoped ist, und einer darüberliegenden Controllerschicht, deren Beans je nach Anwendungsfall @RequestScoped, @ConversationScoped oder @SessionScoped sind und die Services injiziert bekommen. So weit, so normal. Dank des CDI-Proxy-Mechanismus ist aber auch der umgekehrte Weg möglich, also die Injection einer @RequestScoped, @ConversationScoped oder @SessionScoped Bean in eine @ApplicationScoped Bean (also z. B. in den Service). Auf diese Weise lässt sich z. B. ein @RequestScoped EntityManager, der gerade angemeldete Benutzer oder der aktuelle Mandant überall injizieren, wo sie benötigt werden – jedenfalls in der klassischen Webanwendung. Sobald man aber asynchron unterwegs ist, ergeben sich einige Schwierigkeiten, die wir in dieser Kolumne näher beleuchten und umschiffen wollen.

Was erwartet uns in Java EE 8?

Kaum haben wir uns an die neuen Features von Java EE 7 gewöhnt, ist auch schon die nächste Version des Java-Enterprise-Standards am Horizont sichtbar. Pünktlich zur JavaOne 2014 wurde der zu Java EE 8 gehörende JSR 366 vom Java EE Executive Committee (EC) einstimmig angenommen. Grund genug, einmal zu schauen, was uns zum geplanten Releasetermin in Q3 2016 so alles erwartet.

Java EE 8 meets MVC: ein Blick in die Kristallkugel

Für viele überraschend hat Oracle für Java EE 8 einen neuen Java Specification Request zur Ergänzung des aktuellen Web-Development-Stacks angekündigt: MVC 1.0. Obwohl bisher kaum Details zum neuen API bekannt wurden, spaltet der JSR 371 schon jetzt die Community. Grund genug, einen Blick hinter die Kulissen zu wagen.

Multi-Browser-Tab-Support in Java EE 7

Webentwickler kennen das Problem. Bei der Umsetzung bestimmter Use Cases (z. B. Wizards) ist es notwendig, Daten über mehrere Requests hinweg vorzuhalten. Vor Java EE 6 gab es da nur die Möglichkeit, die Daten @SessionScoped abzulegen. Wenn aber der Benutzer die Webanwendung in zwei oder mehr Browsertabs oder -Fenstern verwendet, werden diese Daten zwischen beiden Tabs oder Fenstern geteilt, was meist zu unerwünschten Effekten führt. Der mit JSF 2.0 neu hinzugekommene View Scope (den es seit JSF 2.2 auch als CDI Scope gibt) löst das Problem, solange man sich auf einer XHTML-Seite befindet. Möchte man aber Daten (innerhalb eines Tabs) über mehrere Seiten hinweg behalten und dabei nicht auf Multi-Browser-Tab-Support verzichten, muss man zu anderen Mitteln greifen. Wir werden in dieser Kolumne betrachten, welche Möglichkeiten es da gibt und worauf man dabei achten muss.

Java-EE-Architekturen und JPA: Verwendung des EntityManager im Java-EE-Stack

In der letzten ET-Kolumne haben wir gelernt, wie man mittels JPA Use-Case-bezogen Daten laden kann – oder das Laden bewusst unterdrückt. Das Zauberwort hier heißt „Lazy Loading“. Neben den bereits in JPA 2.0 vorhandenen Möglichkeiten sind wir dabei auch auf das in JPA 2.1 kommende Feature der Fetch bzw. Load Graphs eingegangen. Heute wollen wir einen Schritt weiter gehen und analysieren, wie verschiedene Architekturen den Umgang mit Lazy Loading beeinflussen können und welche Möglichkeiten es im Umkehrschluss gibt, Lazy Loading im gesamten Applikationsstack zu berücksichtigen und sinnvoll verwendbar zu machen.