J2EE-Architektur und Enterprise JavaBeans

EJB als Teil der Java 2 Enterprise Edition (J2EE)

Die Enterprise JavaBeans Architektur stellt eine logische Erweiterung des JavaBeans-Komponentmodells um Serverkomponenten dar. Es sind also Komponenten, die serverseitig ausgeführt werden und einen großen Teil der Ablauflogik implementieren.
Ein EJB-Server stellt eine effiziente, hochgradig skalierbare, robuste Ausführungsumgebung bereit, die besonders für internetfähige Applikationen geignet ist.
Die Enterprise JavaBeans (EJB) Spezifikation ist Teil der J2EE, einer Standardplattform für Internetbasierte Anwendungen. Zur J2EE gehören neben den EJB noch weitere Dienste, insbesondere:

Java Naming and Directory Interface (JNDI): Zugriff auf Naming-Dienste wie DNS oder LDAP
Remote Method Invocation (RMI): Transparenter Zugriff auf entfernte Objekte
Java Messaging Service (JMS): Untertützung für asynchrone Kommunikation durch verschiedene Messaging-Systeme, z.B. verlässlichen Queuing, publish-and-subscribe-Dienste
Java Interface Definition Language (IDL): Eine CORBA-Schnittstelle für Java

Diese Bestandteile stelle ich im Abschnitt J2EE-Technologien noch etwas detaillierter vor.

Die Java 2 Enterprise Edition (J2EE) und ihre Container

Container Services

Container stellen die Schnittstelle zwischen einer Komponente und der sie unterstützenden umgebenden plattformspezifischen Funktionalität dar. Sie fungieren als Dienstleister für die immer gleichen Anforderungen der business objects.

Bevor eine Web-Komponente, eine EJB und ein Application Client ausgeführt werden können, müssen sie zu einer J2EE-Applikation zusammengesetzt und in ihre Container deployed werden ('Deploying'). Der Prozess des Zusammensetzens ('Assembling') erfordert spezifische Einstellungen für jede Komponente einer J2EE Application und für die J2EE Application selbst.

Am Container müssen dann noch Einstellungen vorgenommen werden, um die Unterstützung durch den J2EE Server zu konfigurieren. Das betrifft z.B. Einstellungen zu Sicherheit, Transaktionsmanagement, Java Naming and Directory Interface (JNDI) lookups und remote connectivity:

Das J2EE Sicherheitsmodell erlaubt es, eine Web-Komponente oder EJB so zu konfigurieren, dass nur autorisierte User Zugang zu bestimmten Systemressourcen bekommen.
Das J2EE Transaktionsmodell erlaubt es, Beziehungen zwischen Methoden so eng zu knüpfen, dass mehrere Methoden zusammenhängend als eine Transaktion behandelt werden.
JNDI lookup services bieten eine einheitliche Schnittstelle für die verschiedenen Namens- und Verzeichnisdienste in einem Netzwerk an, über die dann alle von der Applikation angesprochen werden können.
Das J2EE remote connectivity-Modell kümmert sich um low-level-Kommunikation zwischen Clients und Enterprise Beans. Ein Client kann Methoden einer EJB aufrufen, als wenn sich beide innerhalb derselben JVM befinden würden.

Die J2EE-Architektur stellt konfigurierbare Dienste zur Verfügung. Komponenten derselben J2EE Application können sich unterschiedlich verhalten, je nachdem, wohin sie deployed wurden. Beispielsweise können die Sicherheitseinstellungen einer EJB in der einen Produktionsumgebung weitreichende Rechte für den Datanbakzugriff vorsehen, während dieselbe Bean in einer anderern Produktionsumgebung viel restriktiver gehandhabt wird.

Container sorgen daneben noch für Dienste, die nicht konfigurierbar sind, wie beispielsweise das Management des Lebenszyklus von EJBs und Servlets, das Pooling von Datenbankverbindungen, Datenpersistzenz und Zugang zu anderen APIs der J2EE-Plattform. Obwohl die (container-managed) Datenpersistenz nicht konfigurierbar ist, erlaubt die J2EE-Architektur, die continer-manged persistence zu 'überschreiben', indem man entsprechenden Code in der Implemenation der EJB ablegt, der eine 'Handsteuerung' erlaubt. Man kann bean-managed persistence beispielsweise dazu benutzen, um eigene finder-Methoden zu implementieren oder um einen eigenen Datenbank-Cache anzulegen

Container Types

Durch das Deployen werden Komponenten einer J2EE- Applikation in ihren J2EE-Containern installiert.

Ein paar Begriffe:
J2EE server

Die Runtime -Umgebung eines J2EE-Produkts. Ein J2EE-Server stellt Web-Container und EJB-Contaibner zur Verfügung. Beispiel: JBOSS

Enterprise JavaBeans (EJB) container

Kümmert sich um die Ausführung von EJBs für J2EE-Applikationen. EJBs und ihre Container laufen auf einem J2EE-Server.

Web container

Kümmert sich um die Ausführung von Java Server Pages (JSP) und Servlets, den Web-Komponenten einer J2EE-Applikation. Web-Komponenten un ihre Container laufen auf einem J2EE-Server.

Application client container

Kümmert sich um die Ausführung von Client-Komponenten einer Applikation. Ist eine funktionseingeschränkte J2EE-Laufzeitumgebung ( unterstützt - vereinfacht gesagt - nur Security und Deploy-Funktionen aus der üblichen Container-Funktionalität) und läuft in der VM des Clients.

Applet container

Kümmert sich um die Ausführung von Applets. Besteht aus dem Web-Browser und seinem Java-Plug-in, die beide auf dem Client laufen.

Die Java 2 Enterprise Edition (J2EE) und die Vorgänge bei der Softwareentwicklung

Aus der Struktur des J2EE ergeben sich typische Vorgänge und Rollen
(von denen wir in unserer Übung natürlich die meisten selbst spielen müssen):

J2EE-Produkte in Form von Container und APIs zur Verfügung stellen: J2EE product provider
wiederverwendbare Applikationskomponenten (Beans) entwickeln: application component provider
aus Komponenten Applikationen zusammenbauen: application assembler
Komponenten und Anwendungen installieren: deployer
die Ablaufumgebung administrieren: system administrator
Werkzeuge für die einzelnen Aufgaben zur Verfügung stellen: tool provider

Als nächstes werden wir uns mit den Enterprise JavaBeans genauer befassen.

26.08.2003 Petra Haberer Version 1.0.1