Kolumne

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.

Docker rockt Java: EC2 Container Service mit AWS

Bis vor Kurzem mussten Entwickler noch selbst Docker auf ihren EC2-Instanzen in Amazon Web Services installieren und das Management der Container vollständig selbst übernehmen. Mit der Einführung der Unterstützung von Docker in Elastic Beanstalk und OpsWorks wurde der Aufwand für die Nutzung von Containern bereits reduziert. Auf der Konferenz „AWS re:Invent 2014“ hat Amazon den neuen EC2 Container Service vorgestellt, der die Hürde für das Betreiben von Software in Docker-Containern noch einmal signifikant senkt.

Docker mit Maven steuern

Docker bietet eine alternative Möglichkeit, Java-Applikationen zu bauen und in Produktion zu setzen. Bisher wurden Java-Enterprise-WARs oder -EARs in vorinstallierte Java-EE-Server deployt. Jetzt können die Anwendungen direkt komplett, inklusive des Servers, in Docker-Containern ausgeliefert werden. Der Ausführungskontext wird gleich mit verpackt, und lästige Anpassungen entfallen. Mit dieser Methode können die Container überall laufen und schon in der Entwicklung für den Betrieb zusammengestellt werden.

Docker für Java-Entwickler

Infrastruktur macht die Ausführung unserer Software erst möglich. Der Markt erwartet von uns eine schnellere Lieferung von Änderungen, eine höhere Qualität und mehr Flexibilität im Betrieb. Beim Einsatz von Java als Basis unserer Anwendungen haben wir oft mit der fehlenden Einheitlichkeit unserer Produktions-, Test- und Entwicklungsumgebungen zu kämpfen. Der Anspruch „… runs anywhere“ hat leider in der Praxis seine Tücken. Zum Produkt gehören eben nicht nur das Java-Programm, sondern eine Vielzahl weiterer Infrastrukturkomponenten.

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.

Aus der Java-Trickkiste: Hotspot-Schalter

Die meisten Java-Entwickler wissen, wie man bei einer JVM die maximale Heap-Größe setzt oder – zumindest vor Java 8 – den Speicher für die Permanent Generation vergrößert. Aber Hotspot hat eine Vielzahl weiterer Einstellmöglichkeiten, und um die geht es diesen Monat.

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.

Bytecode-Analyse im Eigenbau

Im Java Magazin 12.2014 haben wir uns angesehen, wie man den Classpth scannen kann, ohne Klassen in die JVM zu laden und dann Reflection zu verwenden. Jetzt gehen wir wie angekündigt einen Schritt weiter und analysieren Aufrufketten auf Basis des Bytecodes. Als Beispiel dafür, was damit möglich ist, erstellen wir ein Ranking der am häufigsten aufgerufenen Methoden und suchen die Methoden mit der größten inneren Komplexität heraus. Wie schon letzten Monat verwenden wir dazu die Bytecode-Bibliothek asm.

Classpath-Scan im Eigenbau [Aus der Java-Trickkiste]

Viele moderne Frameworks können zur Initialisierung den Classpath nach annotierten Klassen durchsuchen (z. B. EJB 3, JPA, Spring und sogar Servlet-API 3!). Ich halte diesen Architekturstil für problematisch (Startzeit, Testbarkeit, Security etc.), aber das ist ein Thema für eine andere Kolumne. Und egal wie man zu ihnen steht, Classpath-Scans begegnen einem heutzutage auf Schritt und Tritt – ein Grund, sich die Mechanismen dahinter anzuschauen.

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.

Aus der Java-Trickkiste: Performancemythen

Performance ist ein beliebtes Thema für Entwicklerstammtische. Echte und vermeintliche Best Practices werden – oft als Teil persönlicher Erlebnisse – von Programmierergeneration zu Programmierergeneration weitergegeben. Diesen Monat nehme ich eine Reihe solcher Meinungen unter die Lupe, die mir in Projekten und bei Reviews immer wieder begegnen.

Java-Trickkiste: Patterns zum Instanziieren von Klassen

Diesen Monat stelle ich einige Patterns zum Instanziieren von Klassen vor. Bei Coaching und Codereviews erlebe ich, dass viele Entwickler sich weitgehend auf Default-Konstruktoren und DI-Frameworks beschränken – was nicht per se schlecht ist, aber es gibt für manche Situationen bessere Alternativen. Wenn das eine oder andere bekannt vorkommt: umso besser. Es geht hier nicht darum, bahnbrechende neue Ideen zu präsentieren, sondern ein paar im Prinzip bekannte Lösungen in Erinnerung zu rufen.

Knigge für Softwarearchitekten: Der Domäniker

Eine der empfohlenen Entwicklungsmethodiken für Softwarearchitekturen ist Domain-driven Design (Literatur dazu siehe hier, hier und hier). Dieses sieht vor, die Konzepte der Domäne, d. h. die Entities, die verarbeitet werden und die Services, die fachlich gebraucht werden, zuerst zu modellieren und dann möglichst unverändert eins zu eins im Sourcecode zu verankern. Das klingt einfach und fast selbstverständlich. Je stärker die Codestruktur mit der realen Welt übereinstimmt, desto leichter sind die Wartbarkeit und die Erweiterbarkeit der Software.

Die Systematischverbesserin [Knigge für Softwarearchitekten]

Oftmals ist die Forderung nach Verbesserung von Software eine Folge aus zu hohen Kosten von Änderungen oder Erweiterungen – denn unsere (fachlich oder betriebswirtschaftlich motivierten) Auftraggeber interessiert die innere Qualität von Systemen oftmals nur wenig. Veränderung von Software zum Besseren hin ist daher meist ein langwieriger Prozess, den Sie systematisch und schrittweise angehen müssen.

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.

Aus der Java-Trickkiste: Referenzen mit Sonderstatus

Dass es Weak, Soft und Phantomreferenzen gibt, ist inzwischen recht allgemein bekannt. Und man kann mit ihnen sogar praktische Probleme lösen – ein guter Grund, sie näher unter die Lupe zu nehmen. Die drei speziellen Referenztypen haben gemeinsam, dass sie von der Garbage Collection besonders behandelt werden. Das ist im C++-Quelltext der JVM fest implementiert, man kann also nicht einfach neue Arten von Referenzen mit Sonderbehandlung einführen.