Bevor es um EJB im Detail geht, lohnt sich der Blick auf die Ebene darueber: Java EE selbst. EJB, JMS, JAX-WS und JPA sind keine unabhaengigen Bibliotheken, die man einzeln "installiert" - sie sind Teilspezifikationen eines gemeinsamen Plattform-Vertrags, und genau dieser Vertrag ist es, der WebSphere (und jeden anderen Java-EE-Server) fuer Anwendungen austauschbar macht.
Java EE (Java Platform, Enterprise Edition) ist eine Sammlung von Spezifikationen
("Umbrella-Spezifikation"), die jeweils unter dem Java Community Process (JCP) als eigene
JSRs (Java Specification Requests) entstanden sind und gemeinsam versioniert werden. "Java
EE 8" bedeutet: eine bestimmte, aufeinander abgestimmte Kombination von Spec-Versionen -
u.a. EJB 3.2, JMS 2.0, JAX-WS 2.2, JPA 2.1/2.2, Servlet 4.0, CDI 2.0. Ein Anwendungsserver,
der sich "Java-EE-8-kompatibel" nennt, muss fuer jede dieser Teilspezifikationen eine
funktionierende Implementierung mitbringen und einen gemeinsamen, spezifizierten
Zusammenspiel-Vertrag einhalten (z.B.: eine @Stateless-Bean darf sich per @PersistenceContext
einen JPA-EntityManager injizieren lassen, UND die Transaktion, in der beide laufen, ist
dieselbe).
Dieses Projekt zielt bewusst auf Java EE 7/8 (der javax.*-Namespace, siehe unten) - das
ist exakt der Stand, den WebSphere 8.5.5/9.0 traditional und aeltere WebSphere-Liberty-
Versionen abbilden.
Java EE definiert mehrere Container-Typen, von denen dieses Projekt zwei nutzt:
novaris-policy-core.novaris-policy-web)
dazu.Beide Container laufen im selben Application Server (WebSphere) und koennen im selben EAR
gepackt sein (siehe docs/10-ejb-konzepte/07-jndi-und-packaging.md) - der Witz an "Java EE"
ist gerade, dass diese Container nicht isoliert sind, sondern sich gegenseitig Objekte per
Dependency Injection und JNDI zur Verfuegung stellen.
Was der Container fuer eine Bean uebernimmt (und was in diesem Projekt an vielen Stellen explizit sichtbar gemacht wird, gerade weil es sonst "unsichtbare Magie" bleibt):
@PostConstruct/@PreDestroy, bei Stateful
zusaetzlich @PrePassivate/@PostActivate)@EJB, @Resource, @PersistenceContext)docs/10-ejb-konzepte/03-transaktionen-cmt-bmt.md)@RolesAllowed, siehe docs/10-ejb-konzepte/01-session-beans.md)docs/10-ejb-konzepte/05-interceptors.md)docs/10-ejb-konzepte/02-message-driven-beans.md)javax.* vs. Jakarta EE - warum dieses Projekt bei javax.* bleibt2017 uebergab Oracle die Java-EE-Spezifikationen an die Eclipse Foundation; aus rechtlichen
Gruenden (Oracle behielt die Namensrechte an "javax." und "Java EE") musste die Plattform
umbenannt werden: Jakarta EE*. Ab Jakarta EE 9 (2020) wurden alle Pakete konsequent von
javax.* nach jakarta.* umbenannt - ein rein mechanischer, aber quellcode-brechender
Schritt (jeder Import muss angepasst werden).
Dieses Projekt bleibt bewusst bei javax.*, weil das exakt der Stand ist, den reale
WebSphere-traditional-Installationen (8.5.5, 9.0) und die meisten produktiven WebSphere-
Liberty-Bestandsanwendungen bis heute fahren - die jakarta.*-Umstellung ist selbst einer
der grossen Migrationsschritte, die in einer spaeteren Phase dieses Projekts (explizit
"spaeter", siehe docs/00-ueberblick/systemlandschaft.md) separat behandelt wird, statt sie
mit dem inhaltlichen EJB-Lernstoff zu vermischen.
Tomcat ist nur ein Servlet-/JSP-Container (Web-Container) - er implementiert keinen EJB-Container, kein JMS, kein JAX-WS, keine CMT. Alles, was in diesem Projekt an EJB, JMS und Transaktionen gezeigt wird, braucht deshalb zwingend einen vollwertigen Java-EE- Anwendungsserver (WebSphere, oder - wie hier lokal genutzt - dessen freie Liberty-Kernbibliothek Open Liberty). Das ist der fundamentale Unterschied zwischen einem "Servlet-Container" und einem "Application Server", der in Stellenausschreibungen und Systemarchitektur-Diskussionen staendig auftaucht, aber selten sauber erklaert wird.
⌂ Cockpit