Die Zukunft gestaltet die Community

MicroProfile 1.0 ist da: Der neue Microservices-Standard für Java EE

Dominik Mohilo

http://microprofile.io/

Versprechen gehalten: Wie angekündigt, haben Red Hat, IBM, Tomitribe, Payara und die London Java Community nun, drei Monate nach der DevNation-Konferenz, die erste stabile Version von MicroProfile geliefert. Bei dem Projekt geht es darum, eine Untermenge von Java-EE-Komponenten für die Entwicklung von Microservices in der Cloud bereit zu stellen. Wir berichten, was Version 1.0 tatsächlich im Gepäck hat und wie es mit dem Projekt weitergeht.

Die letzten drei Monate wurden beim Projekt MicroProfile für zweierlei Zwecke genutzt: Zunächst hatten Red Hat und Co. als Diskussionsgrundlage ein Forum bereitgestellt, in der Entwickler ihre Wünsche für ein Microservices-Subset für Java EE mitteilen konnten. Gleichzeitig wurde damit begonnen, ein erstes Modell dieses Subsets zu schaffen. Mit Version 1.0 ist dieses nun zur Verwendung freigegeben.

MicroProfile 1.0: Die Features

Das neue Java-EE-Profile unterstützt JAX-RS (Java API für RESTful Web Services), CDI (Contexts und Dependency Injection) und JSON-P (JavaScript Object Notation mit Padding). Um MicroProfile nutzen zu können, wird empfohlen, die Conference App oder die Beispiele zu klonen und auf einer der Implementierungen der beteiligten Unternehmen laufen zu lassen: WilfFly Swarm, Liberty Profile, Apache TomEE, Payara Micro und Hammock.

Auf seinem Blog hat Mark Little von Red Hat einen kleinen Ausblick in die Zukunft für Java EE und Microservices gegeben. Diese, so Little, wird in erster Linie von der Community gestaltet werden. Version 1.0 von MicroProfile wurde im Funktionsumfang mit Absicht klein gehalten, um einer größeren Community alle Möglichkeiten zu geben, bei der Definition der Ziele mitzuarbeiten.

MicroProfile als neuer Standard

Doch neben der Umfrage, bei der die Nutzer schlicht angeben, was sie gerne für Features hätten, haben die Macher von MicroProfile natürlich auch eigene Dinge im Hinterkopf, die sie unbedingt realisieren möchten. Dazu zählen unter anderem Asynchronität, reaktive Microservices, verbesserte Sicherheitsfunktionen und einige Komponenten aus dem NetflixOSS-Stack. Auch CDI-Annotationen für Circuit Breakers und Sprach-Features wie Lambdas sollen bald verfügbar sein.

Lesen Sie auch: Interview mit Mark Little: Wie MicroProfile Java EE und Microservices zusammenbringen will

Für Mark Little hat Java EE noch viel mehr für Microservices zu bieten, beispielsweise JPA, JTA, Bean Validation. Außerdem sollen die Punkte Monitoring, Logging und Tracing in verteilten Systemen angegangen werden.

Technically Java EE still has a lot more to offer microservices and we’ve been discussing these on the mailing list, including JPA, JTA (yes, I think transactions have a role to play!), Bean Validation and Concurrency Utilities, to name but four. We need to look at extensions to these efforts, or things which go beyond where they currently sit. For example CQRS is important for more advanced microservices developers.

Monitoring, logging and tracing in a distributed system is critical on a number of fronts, not least of which is debugging performance problems and errors, so we need to do more here.

MicroProfile ist, nach Einschätzung des Engineering-Vizepräsidenten von Red Hat, nun bereit, ein Standard zu werden. Hinzu kommt, dass das Projekt in absehbarer Zeit einer Foundation zugeführt werden soll, entsprechende Vorkehrungen werden bereits getroffen.

Weitere Informationen zum Projekt gibt es auf der Homepage von MicroProfile, zu Version 1.0 findet sich alles im offiziellen Blog-Eintrag.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

6 Kommentare auf "MicroProfile 1.0 ist da: Der neue Microservices-Standard für Java EE"

avatar
400
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

@Jaxenter

Mal grundsätzlich, das Hypen von Microservices hier auf der Website nimmt grad echt komplett überhand. Kaum ein Tag ohne mehrere News und Interviews, die sich um Microservices drehen, auch wenn das für den Wald-un-Wiesen-Java-Entwickler wohl ein Nicht-Thema bleiben dürfte. Alleine die Suche über den Browser nach dem Begriff „Microservices“ liefert 17 Treffer. Mehr abwechslung wäre IMHO nett. 🙂

Grüße

Redaktion JAXenter
Mitglied

Hallo TestP,

vielen Dank für deine Einschätzung. Du hast sicher Recht, dass Microservices hier stark thematisiert werden – es zeigt sich aber auch, dass das Interesse daran momentan groß ist.

Welche Themen würdest du gerne stärker auf JAXenter vertreten sehen?

Viele Grüße,

Redaktion JAXenter

Reiner
Gast

Was nützen Microservices wenn fast immer die (alternativlose! ) relationale Datenbank der eigentliche Flaschenhals Ist? Der Hype um diese Microservices geht vollkommen an der Realität vorbei. Die meisten Firmen oder Teams sind eher klein und überschaubar.

Jaxenter könnte vielleicht einmal über Graal/Truffle berichten. Das ist im Augenblick das Faszinierendste was im Javaland passiert.

Redaktion JAXenter
Mitglied

Hallo Reiner,

Graal/Truffle werden wir uns einmal genauer anschauen.

Vielen Dank für den Tipp!

Eberhard Wolff
Gast

Ich glaube auch, dass die Datenhaltung eine entscheidende Frage bei Microservices sind. Meiner Meinung nach sind relationale Datenbanken dabei nicht das Problem, sondern der Umgang mit den Daten. Jeder Microservice sollte ein eigenes Schema haben, um so die Unabhängigkeit zu gewähren. Ich spreche darüber auch auf der JAX: https://jax.de/session/datenarchitekturen-nicht-nur-fuer-microservices/

Unter meinen Kunden sind auch klein Teams, die ebenfalls Microservice nutzen. Beispielsweise sind das schnelle und einfach Deployment ist auch für kleine Teams interessant. Dennoch haben Microservices an einigen Stellen eine höhere Komplexität. Sie sind eben ein Trade-Off wie jede Architektur…

Oliver Gierke
Gast

Kurzer Hinweis: JSON-P meint hier ein anderes JSON-P, nämlich das JSON Processing API (https://json-processing-spec.java.net/). Warum sich der JCP hier — sowie auch bei JSON-B — dafür entschieden hat, bereits weit verbreitete Abkürzungen mit anderer Semantik zu verwenden, weiß vmtl. niemand so genau. Aber mehr Verwirrung ist ja immer gut. 🙂