Suche
#Enterprise Tales

EnterpriseTales: REST, ich hab da mal ne Frage

Ohne Frage, REST hat sich in den letzten Monaten als Programmierparadigma für verteilte Systeme, wie Microservices oder Web-APIs, mehr als etabliert. Stark vereinfacht gesprochen, kann REST als Abstraktion der Struktur und des Verhaltens des WWWs gesehen werden. Problematisch wird der ressourcenbasierte Ansatz allerdings immer dann, wenn komplexe Anfragen beantwortet werden sollen, wie uns das Beispiel des Star-Wars-Universums zeigt.

Zehn Jahre JPA: Von einem (Standard), der auszog, Veränderung einzuleiten

Am 11. Mai 2006 wurde der EJB-3.0-Standard veröffentlicht und mit ihm die Version 1.0 des Java Persistence API, kurz JPA. Und so hatte JPA vor einem knappen Dreivierteljahr seinen ersten runden Geburtstag. Zehn Jahre sind in der IT-Welt eine halbe Ewigkeit. Wie hat der JPA-Standard diese Zeit überstanden? Wo kam er her? Was hat er bewirkt? Und welche Bedeutung hat er heute und in der Zukunft?

EnterpriseTales: MVC 1.0? Wer braucht das schon!

Bisher war MVC 1.0 als eine der wesentlichen Neuerungen für Java EE 8 gesetzt. Doch mit der diesjährigen JavaOne und der von Oracle dort ausgegebenen Vision für die Zukunft des Enterprise-Java-Standards hat sich das grundlegend geändert. MVC 1.0 soll fallengelassen werden. Stattdessen stehen nun Cloud und Microservices im Fokus. Aber ist das wirklich ein Widerspruch?

EnterpriseTales: Klein, kleiner, AWS Lambda

Spätestens seitdem es State of the Art ist, seinen Monolithen in nette, kleine Module – aka Microservices – aufzutrennen, haben wir uns daran gewöhnt, dass der traditionelle Application Server dem alten Eisen zuzurechnen ist. Statt auf eine schwergewichtige Runtime zu setzen, bündelt man heutzutage die notwendigen Serverfragmente direkt mit dem fachlichen Code und spendiert ihm so eine Art integrierte Laufzeitumgebung. Das Ganze noch in mehreren Containern verpackt, ein wenig mit Management- und Monitoringfunktionalität versehen und fertig ist die Anwendung.

Enterprise Tales: Die Reihen im Maschinenraum lichten sich

Während sich derzeitig die (Enterprise-)Java-Community einmal mehr Sorgen über die Position von Oracle zu Java macht, bestimmen einige große Themen die Diskussionen, Medien und Konferenzen: Zum Beispiel das Eingeständnis, dass der Client und vor allem JavaScript nicht mehr zu vernachlässigen sind. Oder die Erkenntnis, dass monolithische Anwendungsarchitekturen überdacht werden sollten. Aber auch die Frage, was denn nun nach Java als Nächstes kommt. Und dennoch sollten wir, die Java-Community, aufpassen, dass die wirklich wichtigen Dinge nicht gänzlich vernachlässigt werden.

EnterpriseTales: Des Microservice großer Bruder

Da hat man sich gerade damit abgefunden, dass der über Jahre gewachsene Monolith aus der Mode gekommen sein soll und besser durch eine Hundertschaft von Microservices abgelöst werden sollte. Und schon erscheint ein neuer Stern am Firmament der Modularisierung. Nein, keine Angst, wir reden hier nicht über eine Reinkarnation von SOA, sondern über etwas mit deutlich höherem Potenzial: Self-contained Systems.

Enterprise Tales: Pragmatic REST

„To REST or not to REST“, das ist hier die Frage. Eines ist sicher, nur weil ich JSON oder XML Payload via HTTP an einen Server sende oder von eben diesem empfange, habe ich es sicherlich noch nicht zwangsweise mit einem RESTful API zu tun. Was also genau macht eine REST-Schnittstelle aus? Und ab wann kann man sie als wirklich gut gelungen bezeichnen? Spätestens bei dieser Frage gehen die Meinungen stark auseinander.

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.

  • 1
  • 2