Beabsichtigte Gestaltungsprinzipien für Jakarta EE

Hallo Habr! Wir haben kürzlich das Buch „ Learning Java EE. Moderne Programmierung für große Unternehmen “ des deutschen Java-Meisters Sebastian Dashner veröffentlicht.


Herr Dashner schreibt und spricht aktiv über Themen im Zusammenhang mit modernem Java EE, sodass sein Blog die allgemeinen Designprinzipien für die jetzt von Eclipse entwickelte Jakarta EE-Plattform nicht ignorierte. Die Übersetzung dieses Artikels (Juni) machen wir Sie heute darauf aufmerksam.

Die Jakarta EE-Plattform übernimmt allmählich die Kontrolle, und mit ihr entstehen neue Spezifikationen für die Unternehmensentwicklung. Um sich auf die verschiedenen Standards und Technologien zu einigen, die in Kürze entstehen werden, wird die gesamte Java EE-Community nur profitieren, wenn die allgemeinen Entwurfsprinzipien für die Jakarta EE-Spezifikationen entwickelt werden.

Ich glaube, dass die Java EE-Technologie mit nur wenigen Prinzipien so erfolgreich war. Im Folgenden werde ich meinen Standpunkt darlegen, welche Designprinzipien, die sich in Java EE entwickelt haben, für mich am wichtigsten erscheinen, die einer weiteren Untersuchung wert sind und möglicherweise als Empfehlungen für das Design in Jakarta EE dienen können.

Ich beschloss, diesen Artikel zu schreiben, inspiriert von den Vorschlägen von Dmitry Kornilov über die Richtung, in die die technische Entwicklung von Jakarta EE gehen sollte.

Das erste ist die Geschäftslogik

Das in Java EE verwendete Programmiermodell ermöglicht es dem Entwickler, sich genau auf das zu konzentrieren, was erforderlich ist, dh auf die Geschäftslogik. Sie müssen keine API-Klassen mehr erben. Der Entwickler kann die Logik seines Themenbereichs in der üblichen Java-Sprache ausdrücken und das Verhalten des Anwendungsservers überwiegend deklarativ (mithilfe von Anmerkungen) steuern. Somit lässt sich das Framework nahtlos in Ihren Code integrieren und ist im Wesentlichen genauso einfach von dort zu entfernen. Verlassen Sie sich beim Entwerfen nicht auf die Wiederverwendung, sondern auf das einfache Entfernen.

Implementierungen sollten den Entwickler jedoch maximal von der schwierigsten Arbeit entlasten - das heißt, ihm ermöglichen, sich den technischen Anforderungen zu entziehen, die nicht mit der Geschäftslogik zusammenhängen. Beispiele sind Multithreading, Transaktionen, Steuerungsinversion oder HTTP-Anforderungsverarbeitung. Auf der Anwendungsseite ist langweilig gut :)

Es scheint mir wichtig zu sein, dass das Framework nicht nur die Implementierung der Geschäftslogik nicht beeinträchtigt, sondern auch Programmierer ermutigt, entwickelte Funktionen schnell in die Produktion zu bringen. Es ist nicht erforderlich, das Framework zu polieren, um zu glänzen - es ist besser, den Code der Geschäftslogik auf das Ideal zu bringen. Vergleichen Sie modernes Java EE oder Spring mit den altmodischen Versionen von J2EE - ich denke, Sie werden sofort verstehen, was ich meine.

Jakarta EE sollte sich in der gleichen Richtung entwickeln und sich dementsprechend auf Spezifikationen konzentrieren, die es Entwicklern ermöglichen, Geschäftslogik schnell zu implementieren.

Konfigurationskonventionen

Java EE minimiert die Konfiguration, die zum Definieren einer typischen Unternehmensanwendung erforderlich ist. In den meisten praktischen Situationen funktionieren Vereinbarungen sofort, es ist keine Konfiguration erforderlich. Sie benötigen also keine XML-Dateien mehr, um eine einfache Java EE-Anwendung zu konfigurieren. Ein weiteres Beispiel ist, dass JAX-RS Standard-HTTP-Antwortcodes bereitstellt, die den Rückgabewerten von JAX-RS-Methoden entsprechen.

Java EE bietet die Flexibilität, das Verhalten zu ändern und komplexere Skripts zu implementieren. Hierüber besteht jedoch keine Einigung.
Jakarta EE muss weiterhin das Einfache in das Leichte und das Komplexe in das Mögliche verwandeln.

Interoperabilitätsspezifikationen

Jakarta EE sollte die Interoperabilität der Spezifikationen fortsetzen und erweitern. Java EE entspricht den vorhandenen Spezifikationen und den darin enthaltenen Funktionen, die bereits Teil des Standards sind.

Entwickler können sich auf unterschiedliche Spezifikationen verlassen, um ohne Konfiguration gut miteinander zu interagieren. Erforderliche Standards: Wenn die Laufzeitumgebung sowohl Spezifikation A als auch Spezifikation B unterstützt, muss A + B miteinander interagieren. Beispiele: Komponentenvalidierung, JAXB oder JSON-B können in JAX-RS-Ressourcenklassen verwendet werden, und es ist keine weitere Konfiguration erforderlich.

Abhängigkeitsinjektion und CDI

Natürlich ist es für Jakarta EE unerwünscht, die bereits vorhandenen Dinge neu zu erfinden - zum Beispiel die Abhängigkeitsinjektion im Zusammenhang mit CDI. Es ist wünschenswert, dass die Spezifikationen die Stärken des JSR 330 oder gegebenenfalls des CDI verwenden und hervorheben.

Ein UriInfo Beispiel ist die Verwendung von UriInfo von JAX-RS in Ressourcenmethoden. Annotation @Inject unterstützt die Implementierung dieser Art von Methode noch nicht. Für den Programmierer ist es bequemer zu arbeiten, je mehr er sich auf den universellen Mechanismus verlässt.

Eine weitere spezifische Maßnahme ist folgende: CDI-Anbieter müssen in den Spezifikationen und gegebenenfalls typsichere Qualifikationsmerkmale für die zu erstellenden Typen angegeben werden. Daher kann die JAX-RS- ClientBuilder derzeit nur programmgesteuert über die ClientBuilder API abgerufen werden. Hersteller und Qualifizierer vereinfachen die Arbeit eines Programmierers durch deklarative Definitionen.

Deklarative Ansätze

Bei alledem stützt sich die Java EE-API stark auf einen deklarativen Ansatz, während die Umkehrung der Kontrolle verwendet wird. Daher rufen Entwickler die Funktionalität nicht direkt auf. Der Container ist für den Aufruf der Funktion verantwortlich, während wir uns auf Codedefinitionen verlassen. Beispiele (aus den aktuellsten Spezifikationen) sind JAX-RS, JSON-B oder CDI.

Jakarta EE bietet nicht nur umfassendere Software-APIs, sondern sollte auch die Verwendung deklarativer Definitionen und Steuerungsinversionen weiter erleichtern.

Bereitstellungsstrategien

Eine Besonderheit (und meiner Meinung nach ein großer Vorteil) von Java EE ist das hier vorgeschlagene Bereitstellungsmodell, bei dem sich geschäftliche Logikprobleme von der Implementierung lösen. Der Entwickler programmiert ausschließlich für die API, die nicht Teil des Bereitstellungsartefakts ist und vom Anwendungscontainer implementiert wird.
Diese kompakten Bereitstellungsartefakte vereinfachen und beschleunigen die Programmbereitstellung, einschließlich Zusammenstellung, Veröffentlichung und Bereitstellung als solche. Sie sind auch mit den Ebenen des Container-Dateisystems kompatibel, die beispielsweise in Docker verwendet werden. Während des Montageprozesses müssen Sie nur die geänderten Elemente neu erstellen oder erneut einreichen.

Im Idealfall sollten Bereitstellungsartefakte nur Geschäftslogik und nichts anderes enthalten. Laufzeitimplementierungen und möglicherweise hinzugefügte Bibliotheken von Drittanbietern werden auf einer niedrigeren Ebene bereitgestellt, z. B. in Anwendungsserverbibliotheken, die in der vorherigen Phase der Containerassemblierung hinzugefügt wurden.

In Jakarta EE müssen bereitgestellte Artefakte auch als erstklassige Entitäten betrachtet werden. Möglicherweise besteht die Möglichkeit, die Laufzeitumgebung basierend auf den von der Anwendung geforderten Spezifikationen weiter zu straffen. Jakarta EE erwartet jedoch, dass der Geschäftslogik und Produktivität des Entwicklers maximale Aufmerksamkeit geschenkt wird, und die Verfeinerung der Ausführungszeit ist bereits zweitrangig.

Testbarkeit

Durch Anwendung der oben genannten Prinzipien, insbesondere unter Vorzug der deklarativen Programmierung und der Abhängigkeitsinjektion, verbessern wir die Testbarkeit von Geschäftscode. Auf diese Weise können Entwickler Objekte in Testskripten direkt instanziieren, da Sie jetzt keine API-Klassen mehr erben oder unbequeme Funktionen aufrufen müssen, die Sie zuvor simulieren mussten.

In Jakarta EE ist es jedoch erforderlich, die Standardisierung von Integrationstests auf Codeebene ernsthaft zu verfeinern, damit sie nicht vom Hersteller abhängt. Zuvor war dies genau das, womit Sie sich bei der Arbeit mit Arquillian befassen mussten. In realen Projekten wäre ein solcher Standard nützlich, mit dem Sie nur Testbereitstellungsszenarien deklarieren und Funktionen für eine oder mehrere Komponenten aufrufen können. Zuvor habe ich geschrieben, dass ich Integrationstests auf Codeebene nicht als äußerst wichtig erachte, beispielsweise wenn eine Anwendung in integrierten Containern ausgeführt wird. Wenn Sie jedoch Integrationstests auf Codeebene standardisieren, wirkt sich dies eindeutig positiv aus.

Fazit

Ich denke, es ist kein Zufall, dass die Java EE-APIs in realen Projekten so häufig verwendet werden: Diese APIs sind gut durchdacht und nach klaren Prinzipien gestaltet, dank derer nicht nur eine einzige Spezifikation, sondern eine gesamte Plattform vereinheitlicht werden konnte. Mit ihnen können Sie mehrere Spezifikationen gleichzeitig verwenden, die im selben Sinne gehalten werden. Hier ist es uns gelungen, künstliche Hindernisse zu beseitigen, die die Arbeit des Programmierers nur erschweren. Daher ist meiner Meinung nach die gesamte Unternehmensentwicklung viel angenehmer geworden.