Das MicroProfile als Innovationsmotor der Java Enterprise-Plattform
An das Jahr 2016 werden sich Anhänger der Java EE-Plattform nur ungern zurück erinnern. Damals war die Entwicklung von Java EE 8 ins Stocken geraten, da Oracle seine Arbeiten am neuen Release praktisch eingestellt hatte. Gleichzeitig blieben Nachfragen über die Gründe unbeantwortet und Oracle ließ die Community über mehrere Monate im Unklaren über seine Zukunftspläne für die Plattform. Einige Beobachter befürchteten bereits, Oracle hätte das Interesse an Java EE komplett verloren und würde die Weiterentwicklung einfach einstellen. Dies hätte sicherlich das Ende der Plattform bedeutet – ein Schreckensszenario für die zahlreichen Unternehmen, die seit vielen Jahren in Java EE investieren.
Inzwischen sehen die Aussichten für die Java Enterprise-Plattform schon wieder deutlich besser aus. Java EE 8 wurde im Herbst 2017 endlich veröffentlicht. Und fast zeitgleich kündigte Oracle an, die alleinige Kontrolle über die Plattform aufzugeben – ein Schritt, der von einem immer größer werdenden Teil der Community schon länger gefordert wurde. So wird die Plattform künftig unter dem Dach der Eclipse Foundation weiterentwickelt. Als offizieller Projektname dient dabei "EE4J", ein neuer Brand-Name soll noch gefunden werden. Zwar sind viele organisatorische und rechtliche Fragen noch zu klären, doch unterm Strich ist eine deutliche Aufbruchstimmung in der Community zu spüren. Sie erhält nun Gelegenheit, bei der Weiterentwicklung der Plattform deutlich mehr Einfluss zu nehmen. Zudem wird erwartet, dass die Entwicklung künftig schneller voranschreitet, sich enger an aktuellen Trends orientiert und es häufigere Releases geben wird.
Einen wichtigen Beitrag zu dieser derzeitigen Aufbruchstimmung leistet die so genannte MicroProfile-Initiative. Dabei handelt es sich um den Zusammenschluss mehrerer Hersteller und Community-Mitglieder, welche aktiv die Weiterentwicklung der Plattform vorantreiben möchten. Wichtigstes Ziel ist die Entwicklung von Plattformerweiterungen, welche insbesondere den Einsatz im Umfeld von Cloud und Microservices besser unterstützen. Die Initiative hatte ihren Ursprung bereits im Jahr 2016, also nicht zufällig genau in jener Zeit, als Oracle die Community so lange im Ungewissen gelassen hatte. Grundidee der Initiative war damals der Vorschlag eines neuen Java EE Profiles. Profiles wurden mit Java EE 6 eingeführt und definieren jeweils eine Teilmenge der einzelnen Plattformtechnologien, die für einen ganz bestimmten Einsatzzweck gedacht ist. So wurde etwa das Web Profile standardisiert, welches eben genau diejenigen Java EE-APIs beinhaltet, die typischerweise für (einfache) Web-Anwendungen benötigt werden. Damit ist es für solche Anwendungen nicht mehr notwendig, einen kompletten ("Full Profile"-)Anwendungsserver einzusetzen, der die komplette Palette der Plattformtechnologien unterstützt. Stattdessen kann ein Web Profile-Anwendungsserver zum Einsatz kommen, der deutlich leichtgewichtiger daherkommt.
Analog dazu soll das nun vorgeschlagene MicroProfile eine Teilmenge von APIs definieren, welche typischerweise für die Entwicklung von Microservices benötigt werden. Der genaue Umfang und Inhalt des Profiles soll zunächst innerhalb der Community abgestimmt und entwickelt werden. Sobald ein Entwicklungsstand vorliegt, der als praxistauglich bewertet wird, soll das MicroProfile dann auch standardisiert werden. Wie genau dieser Standardisierungsprozess künftig im Kontext von EE4J aussehen wird, steht freilich noch nicht fest. Klar scheint nur, dass der bisherige Standardisierungsprozess nicht weiter zum Einsatz kommen wird.
Rascher Fortschritt
In einem ersten Release mit dem Namen MicroProfile 1.0 wurden im Herbst 2016 zunächst nur sehr wenige, bereits existierende Technologien benannt, die als absolutes Minimum für die Entwicklung von Microservices gelten dürfen. Hierbei handelte es sich um JAX-RS 2.0 (REST), CDI 1.2 (Context und Dependency Injection) und JSON-P 1.0 (JSON Processing). Die an der Initiative beteiligten Hersteller stellten in der Folge recht zügig unterschiedliche Implementierungen des MicroProfiles zur Verfügung. So entstanden sehr schlanke Anwendungsserver wie Wildfly Swarm oder Payara Micro, die eben nur Implementierungen genau dieser drei Technologien beinhalten mussten [1].
In diesem Zusammenhang wurden auch andere Ideen und Entwicklungen in den Fokus gerückt, an denen bereits zuvor – abseits des Java EE-Standards – verschiedene Hersteller gearbeitet hatten. Besonders zu nennen ist hier beispielsweise die Erzeugung so genannter FatJARS oder ÜberJARs. Dabei wird während des Build-Prozesses ein einziges resultierendes Artefakt erzeugt, welches sämtliche abhängigen Ressourcen, also insbesondere auch sämtliche benötigten Bibliotheken, enthält. Gegebenenfalls kann sogar der Anwendungsserver selbst mit verpackt werden. Somit entsteht eine einzige Datei, die in einem Docker-Container und/oder in der Cloud deployt werden kann, und die alles enthält, was die entwickelte Anwendung oder der Service zum Start benötigt.
Ebenfalls sehr interessant sind die Bemühungen der Hersteller, ihre Anwendungsserver so modular zu gestalten, dass beim Build-Vorgang ein maßgeschneiderter Anwendungsserver zusammengebaut wird, welcher nur genau jene Komponenten enthält, die von der deployten Anwendung benötigt werden. Dies verhindert unnötigen Ballast in Form von Technologien, die gar nicht zum Einsatz kommen.
Nachdem Oracle dann im Herbst 2017 ankündigte, die Kontrolle über die Plattform an die Eclipse Foundation abzugeben, nahm die Weiterentwicklung des MicroProfiles richtig Fahrt auf. Weitere Versionen des MicroProfile erschienen in rascher Folge. So wurden noch im dritten Quartal 2017 gleich zwei Folgeversionen präsentiert. Das MicroProfile 1.1 enthielt zusätzlich das komplett neu entwickelte Config 1.0, das den Zugriff von Anwendungen auf Konfigurationseinstellungen aus unterschiedlichen Quellen vereinheitlichen soll. Dies ist beispielsweise im Zusammenhang mit Containertechnologie interessant. Soll ein einmal gebauter Container in verschiedenen Umgebungen einsetzbar sein, darf die Anwendungskonfiguration nicht in die Anwendung integriert sein. Sie muss stattdessen von außen zugeführt werden. Dies kann auf unterschiedlichen Wegen geschehen und genau daher ist ein vereinheitlichter Zugriff auf solche Konfigurationseinstellungen wünschenswert.
Das MicroProfile 1.2 enthält bereits eine Weiterentwicklung dieser API namens Config 1.1, und darüber hinaus die neuen APIs Fault Tolerance 1.0, Health Check 1.0, Metrics 1.0 und JWT Authentication 1.0. Hiermit wurde die Grundlage zur Unterstützung von Features gelegt, die in der Community zum Teil seit längerer Zeit gefordert, für Java EE jedoch bisher nicht umgesetzt wurden. So unterstützt die Fault Tolerance-API verschiedene, für die Entwicklung verteilter Systeme so wichtigen Aspekte wie Timeouts, Retries und Fallbacks. Darüber hinaus werden Implementierungen für die bekannten Patterns "Circuit Breaker" und "Bulkhead" bereit gestellt. All dies soll Entwicklern dabei helfen, die typischen Herausforderungen verteilter Systeme besser meistern zu können.
Die aktuellen Trends hin zu Microservice-Architekturen und APIs hatten diese Herausforderungen gerade in der jüngeren Vergangenheit wieder verstärkt in den Fokus gerückt. Es stehen zwar auch abseits des MicroProfiles einige recht populäre Bibliotheken für diesen Zweck bereit. Die Fault Tolerance API standardisiert aber nun eine API für diese Aspekte.
Die HealthCheck- und Metrics-APIs des MicroProfile 1.2 dienen dazu, Laufzeitinformationen über einzelne Services zu erhalten oder zu testen, ob ein Service grundsätzlich einsatzbereit ist. Sie dienen also insbesondere dem Monitoring von Services. JWT Authentication 1.0 bietet standardisierte Unterstützung für den Einsatz von JSON Web Tokens, die aktuell sehr verbreitet für die Authentifizierung und Authorisierung von Service-Clients zum Einsatz kommen.
Es liegt nun an der Community, die Palette neuer Funktionalitäten zu testen und Feedback zu geben.
Während also allein diese beiden Releases bereits sehr umfangreiche Erweiterungen für die Plattform enthielten, liegt seit Jahresbeginn nun bereits das MicroProfile 1.3 vor. Für dieses Release wurden die Config-API (nochmals), sowie die Metrics-API aktualisiert. Zudem kamen OpenAPI 1.0, OpenTracing 1.0 und Rest Client 1.0 neu hinzu. Mit der MicroProfile OpenAPI 1.0 soll es möglich sein, eigene JAX-RS-Anwendungen mit Hilfe standardisierter Annotationen zu dokumentieren und auf diese Weise OpenAPI-V3-Dokumente zu erstellen. Bislang waren hierfür entweder proprietäre Annotationen notwendig oder es mussten Tools zum Einsatz kommen, welche den Source- oder Byte-Code von JAX-RS-Anwendungen analysieren und auf dieser Grundlage eine API-Dokumentation erstellen. Bei Open Tracing handelt es sich um einen herstellerübergreifenden Standard zur Nachverfolgung von Workflows oder Geschäftsvorgängen in verteilten Systemen. Die MicroProfile OpenTracing-API definiert hierfür eine Java-API, welche es ermöglichen soll, JAX-RS Anwendungen an solchen Nachverfolgungen teilnehmen zu lassen. Der Microprofile RESTClient ermöglicht den einfachen und typsicheren Zugriff auf REST-Schnittstellen.
Es gibt also eine ganze Palette neuer Funktionalitäten für die Java Enterprise-Plattform, die größtenteils seit langem schmerzlich vermisst und gefordert wurden. Es liegt nun an der Community, diese auf ihre Praxistauglichkeit hin zu testen und Feedback zu geben. Wer erste Experimente mit dem MicroProfile wagen möchte, kann hierzu eine der Implementierungen wie Wildfly Swarm, Open Liberty, Payara Micro oder Apache TomEE herunterladen und in eigene Projekte einbinden [1].
Die einzelnen Implementierungen sind nicht alle auf dem gleichen Entwicklungsstand, was die Unterstützung der zahlreichen neuen MicroProfile-APIs anbetrifft. Hier lohnt ein Blick in die jeweilige Dokumentation. Jedoch ist zu beobachten, dass die Hersteller sehr bemüht sind, ihre Implementierungen rasch zu vervollständigen und regelmäßig neue Releases zur Verfügung zu stellen.
Blick in die Glaskugel
Die Zukunft der Java Enterprise-Plattform erscheint aktuell ein wenig ungewiss. Zwar sind erste, wichtige Schritte gemacht und das EE4J-Projekt wurde bei der Eclipse Foundation auf dem Weg gebracht, doch gleichzeitig sind eine ganze Reihe von organisatorischen und rechtlichen Fragen noch zu klären. Erste Beobachter drängen bereits darauf, dass diese Verhandlungen zügig abgeschlossen werden sollten, damit es mit der technologischen Weiterentwicklung voran gehen kann. Dies gilt umso mehr, als erwartet wird, dass EE4J 1.0 im wesentlichen einen zu Java EE 8 identischen Funktionsumfang haben wird. Vielmehr wird es bei diesem Release darum gehen, den technischen, rechtlichen und organisatorischen Übergang zur Eclipse Foundation abzuschließen und nachzuweisen. Erst in Folgeversionen von EE4J ist mit technischen Neuerungen zu rechnen. Allzu lange sollte der Übergang also nicht mehr dauern, um die aktuelle Aufbruchsstimmung innerhalb der Community nicht wieder abebben zu lassen.
Angesichts des aktuellen Tatendrangs der Hersteller sollte Java EE-Anhängern nicht bange sein.
Gleichzeitig jedoch erweist sich die MicroProfile-Initiative als Innovationsmotor der Plattform. Losgelöst von den angesprochenen Übergangs- und Standardisierungsprozessen werden hier in rascher Folge sinnvolle und relevante Erweiterungen entwickelt, mit der Community abgestimmt und auf Praxistauglichkeit geprüft. Und diese Bestrebungen sind offenbar noch lange nicht am Ende: Die Pläne für ein künftiges MicroProfile 2.0 sind bereits beschlossen. Dann sollen die in Java EE 8 vorgestellten CDI 2.0, JSON-P 1.1, JAX-RS 2.1 und JSON-B 1.0 in das MicroProfile integriert werden.
Auch die MicroProfile-Initiative hat sich inzwischen der Eclipse Foundation angeschlossen, was die Verschmelzung ihrer Arbeitsergebnisse mit EE4J erleichtern wird. Sobald EE4J bereit dazu ist, sollte auch das MicroProfile so weit fortgeschritten sein, dass sich dessen einzelne Technologien prinzipiell recht zügig in die Plattform integrieren lassen. Somit würde ein EE4J-Release 1.1, das dann tatsächlich auch technische Fortschritte brächte, idealerweise nicht lange auf sich warten lassen. All dies ist natürlich noch Zukunftsmusik. Doch angesichts des aktuellen Tatendrangs der Hersteller sollte Anhängern der Java Enterprise-Plattform nicht bange sein.
Neuen Kommentar schreiben