WildFly 11 ist gelandet

Elytron heißt die neue Sicherheitsinfrastruktur und ist die Vereinheitlichung auf ein neues, gemeinsames Sicherheitsframework für den gesamten Anwendungsserver. In der Vergangenheit musste das Team um WildFly die Sicherheitsinfrastrukturen (picketbox und security-realms) trennen. Jede für sich deckte verschiedene Anwendungsfälle ab und arbeitete weitestgehend unabhängig von ihrem Pendant. Neben der Vereinheitlichung bietet Elytron diverse neue Funktionen an. Dazu gehören beispielsweise Privilegienverteilung über mehrere Service Invocations, Identitätswechsel, Verifizierung von pre-request TLS und umfangreiche Sicherheitsrichtlinien. Letztendlich verbessert Elytron die allgemeine Erweiterbarkeit des Systems, indem sie eine enge Integration mit SSO/IDP-Systemen wie KeyCloak erlaubt.

Obwohl WildFly 11 eine neue Sicherheitsinfrastruktur einführt, sind die bestehenden Security-Domain- und Securitty-Realm-Konfigurationen und APIs alle noch vorhanden und werden intern auf Elytron abgebildet. Um die Auswirkung dieser Änderung abzumildern, verwenden WildFlys Standardeinstellungen immer noch die alten Sicherheitsdomänen und -Realms. Weitere Informationen erhalten sie in der Elytron-Dokumentation.

Vereinfachte EJB/Naming Proxies

Die Entwickler um den bekannten Application Server für Java EE haben JNDI- und  EJB-Aufrufe in WildFly 11 vereinfacht und verbessert. Sie haben eine neue Client-Bibliothek geschaffen, den WildFly Naming Client. Mit dessen Hilfe lässt sich der Zugriff auf WildFly mit minimalen Eigenschaften und Konfigurationen festlegen. Auf EJBs und andere Quellen kann der Nutzer in einem dynamischen Discovery Mode oder einem Point-to-Point Mode zugreifen. Letzterer sperrt alle EJB-Proxies zu einer angegebenen Adresse. Eine intuitivere Semantik löst die alte Kontextfunktion ab. Zusätzlich besteht seit Elytron die Möglichkeit, die User-Identität zwischen Anfragen zu ändern. Zudem können auch ältere Clients aus früheren WildFly-Versionen weiterhin verwendet werden.

Anfrageorientiertes EJB/JNDI über HTTP

Seit WildFly 8 können alle Protokolle, mit Ausnahme von IIOP, HTTP Upgrade verwenden, um über eine reduzierte Anzahl von Ports auf dem Server zu kommunizieren. Weil aber HTTP Upgrade die Verbindung in das verwendete native Protokoll konvertiert, können HTTP-Load-Balancer, die als Vermittler dienen, nur bei inititalem Verbindungsaufbau arbeiten. Um Balancing auf dem Invocation Level zu ermöglichen, ist neues, unverändertes HTTP-Protokoll hinzugekommen. Clients, die http:// URLs anstelle von remoting+http:// verwenden, können es nutzen. Da dieses Protokoll ein Standard-HTTP-Verhalten verwendet, kann es von jedem Load-Balancer und nicht nur von dem in WildFly eingebauten Lastausgleich effizient abgeglichen werden.

WildFly OpenSSL & HTTP/2

Verbesserungen in Sachen Shutdown/Startup

Der Mechanismus des Graceful Shutdown kommt jetzt auch mit verteilten Daten zurecht. Er erlaubt bestehenden Transaktionen, lokale Operationen fortzuführen, aber lehnt neue Transaktion ab. Außerdem gibt es einen neuen EJB-Parameter, der es erlaubt, dass zusätzliche Remote-Aufrufe gegen eine etablierte/aktive Remote-Transaktion erfolgen können. Schließlich kann der Anwender nun den Server direkt im suspended Modus starten. Dies ist nun Teil der Standardstartsequenz, in der der Server zuerst unterbrochen und dann nach dem Start aller Dienste fortgesetzt wird, so dass neue Anfragen während des kurzen Zeitfensters des Serverstarts nicht angenommen werden.

Management- und Konfigurationsverbesserungen

WildFly 11 unterstützt nun auch remote verwaltete, exploded Deployments. Dieser Support ermöglicht Clients, Inhalte wie HTML- und JSP-Dateien innerhalb des Deployments zu aktualisieren, ohne dass eine vollständiges Redeployment erforderlich ist. Zusätzlich gibt es eine neue Verwaltungsoperation, mit der einzelne Dateien in jedem Deployment gelesen werden können. Fehler im XML führen ab sofort dazu, dass die Fehlermeldungen in der XML-Datei aussagekräftiger und einfacher zu verstehen sind.