EAR-Packaging und Deployment

Beispiel: novaris-policy-ear (bundelt novaris-policy-core + novaris-policy-web-legacy-jsf).

docs/10-ejb-konzepte/07-jndi-und-packaging.md fuehrt die Archivhierarchie (ejb-jar/war/ear) grundlegend ein. Dieses Dokument geht auf die konkrete Umsetzung in diesem Projekt und den WebSphere-Deploymentweg ein.

Warum jetzt, in Phase 4, und nicht frueher?

Ein EAR ergibt erst dann echten Sinn, wenn es tatsaechlich mehr als ein Modul zu buendeln gibt. Bis Phase 3 bestand die Landschaft ausschliesslich aus eigenstaendigen JAR-Modulen (EJB-Modul, SOAP-/JMS-Partnersysteme) ohne Web-Schicht - ein EAR mit nur einem EJB-Modul waere unnoetige Verpackung ohne Nutzen gewesen. Erst mit novaris-policy-web-legacy-jsf (Phase 4) gibt es zwei Module, die tatsaechlich denselben Klassenlader und denselben JNDI-Namensraum teilen sollen.

Der eigentliche technische Grund fuer ein gemeinsames EAR

Der entscheidende Effekt: Module im selben EAR koennen sich per lokalen EJB-Interfaces erreichen (siehe docs/10-ejb-konzepte/01-session-beans.md, Abschnitt "Local vs. Remote"). PolicyOverviewBean (Web-Modul) injiziert @EJB PolicyManagementLocal - kein PolicyManagementRemote - und das funktioniert nur, weil beide Module (Web und EJB) im selben EAR, also demselben Anwendungs-Klassenlader, laufen. Waeren sie separat deployt (zwei unabhaengige Anwendungen, ggf. auf unterschiedlichen Servern), muesste die Web-Schicht zwingend das teurere PolicyManagementRemote-Interface verwenden.

Aufbau des EAR

novaris-policy.ear
├── META-INF/
│   └── application.xml          <- welche Module, welcher Context-Root, welche Rollen
├── novaris-policy-core.jar       <- das EJB-Modul (aus Phase 1/2/3)
└── novaris-policy-web-legacy-jsf.war   <- das Web-Modul (aus Phase 4)

src/main/application/META-INF/application.xml (siehe dessen Kopfkommentar) ist bewusst von Hand geschrieben statt automatisch vom maven-ear-plugin generiert - dieselbe Haltung wie bei ejb-jar.xml in Phase 1: die Security-Rollen-Deklaration soll im Code sichtbar und nachvollziehbar bleiben.

Wichtig: dieselben drei Rollennamen (PolicyAdmin, Underwriter, CustomerServiceRep) tauchen an DREI Stellen auf - ejb-jar.xml (EJB-Modul), web.xml (Web-Modul) und application.xml (EAR-Ebene). Das ist keine Redundanz aus Versehen: jede Ebene deklariert die Rollen fuer ihren eigenen Zustaendigkeitsbereich (Methodenschutz auf EJB-Ebene, URL-Schutz auf Web-Ebene, anwendungsweite Sichtbarkeit auf EAR-Ebene). Die Zuordnung ("Benutzer X hat Rolle Y") passiert an keiner dieser Stellen im Code, sondern ausschliesslich beim Deployment.

Deployment: WebSphere Admin Console/`wsadmin` vs. Liberty

WebSphere traditional: Ein EAR wird ueber die Admin Console ("Applications → New Application → New Enterprise Application", EAR-Datei hochladen) oder per wsadmin-Skript (Jython/Jacl) installiert. Waehrend der Installation fragt der Assistent u.a. genau die Security-Rollen-Zuordnung ab ("Map security roles to users/groups") - die <security-role>-Eintraege aus application.xml erscheinen hier als vorausgefuellte Liste, die ein Administrator den tatsaechlichen Benutzern/Gruppen der Zielumgebung zuordnet.
WebSphere Liberty: Deutlich leichtgewichtiger - eine EAR- (oder WAR-)Datei wird einfach in das apps-Verzeichnis der Serverinstanz gelegt (oder per <application>-Element in server.xml referenziert); Liberty entpackt/deployt sie beim naechsten Start bzw. erkennt neue Dateien automatisch (Hot Deployment). Die Rollen-Zuordnung passiert dort per <application-bnd> in server.xml (siehe bereits vorhandenes Beispiel in novaris-policy-core/src/main/liberty/config/server.xml).

Status in diesem Projekt

novaris-policy-ear baut erfolgreich (mvn package) zu einer echten, WebSphere-deploybaren EAR-Datei - der Build-Teil ist vollstaendig lauffaehig. Das tatsaechliche Deployment auf einen echten Liberty-Server (inklusive Verifikation, dass die Web-zu-EJB-Aufrufe wirklich funktionieren) folgt in Phase 5 zusammen mit der uebrigen Container-/Testcontainers- Verkabelung.