Die Architektur von Enterprise JavaBeans

Gesamtübersicht: Die Architektur von Enterprise JavaBeans

• Überblick
• Der EJB-Server
• Der EJB Container
• Laufzeitumgebungen und Dienste

Der Server ist die Basiskomponente der EJB-Architektur. Er ist eine Laufzeitumgebung für mehrere Container. Jeder Container stellt wiederum eine Laufzeitumgebung für bestimmte Enterprise Beans zur Verfügung. Es wird von Herstellern immer mehr dazu tendiert, Java-Applikationsserver zu entwickeln, die J2EE-Plattform zu unterstützen. Kaum Hersteller entwickeln reinen EJB-Server.

• Das API des JDK 1.1.x oder das der Java-2-Plattform
  
  
• Das API der Spezifikation der Enterprise JavaBeans 1.1
  
  
• Das API des JNDI 1.2 (Java Naming and Directory Interface)
  
  
• Das UserTransaction-API aus JTA 1.0.1 (Java Transaction API)
  
  
• Das API der JDBC-2.0-Erweiterung (Java DataBase Connectivity)
  
  
• Das API von Java Mail 1.1 (für das Verschicken von E-Mails)
  
  

• Dienste
  
  
  • Namens- und Verzeichnisdienst:  Ein Client ist auf den Namensdienst angewiesen, damit er eine Bean finden kann. Ein Namendienst bietet zum einen die Möglichkeit, Referenzen auf entfernte Objekte unter bestimmten Namen an einem definierten Platz zu hinterlegen (Binding). Diese Namen können auch freigegeben werden. Zum anderen bietet er die Möglichkeit, die gebundene Objekte über deren Namen wiederzufinden (Lookup).
    
    Ein Verzeichnisdienst unterstütz nicht nur das Binden von Referenzen auf verteilte Objekte, sondern das Verwalten und Administrieren anderer Ressourcen wie z.B.: Drucker, Dateien, Anwendungsserver usw.
    
    
  • Persistenz:  Die Beans haben die vom Container gestellte Möglichkeit, über den Namens- und Verzeichnisdienst auf Datenbankverbindungen zuzugreifen. Damit können sie die Verantwortung dafür tragen, daß ihr Zustand persistent gemacht wird. Es gibt aber auch einen anderen Mechanismus, mit dessen Hilfe der Zustand von Beans automatisch persistent gemacht werden kann. Bei diesem Ansatz werden Daten von Beans durch den Container in der Regel in einer Datenbank. Als Ablageort muß es nicht unbedingt eine Datenbank sein. Es ist auch denkbar, daß es andere Container gibt, die die Daten in anderen Speichersystemen ablegen. Es besteht auch die Möglichkeit, Container zu entwickeln, die die Schnittstellen anderer Anwendungen benutzt, um dort Daten abzulegen oder auszulesen.
    
    Entscheidend ist es die Tatsache, daß es im Falle der automatischen Persistenz einer Enterprise-Bean für die Bean uninteressant ist, wo die Daten abgespeichert sind. Der Container muß dafür sorgen, daß die Daten abgespeichert werden und damit sie zu jedem Zeitpunkt einen konsistenten Zustand haben.
  
  
  
• Laufzeitumgebungen
  
  
  • Kontrolle des Lebenszyklus einer Enterprise Bean:  Der EJB-Container ist für die Kontrolle des Lebenszyklus einer Bean zuständig. Wenn Anfragen von Clients kommen, muß der EJB-Container die Bean-Instanzen angemessen erzeugen, zerstören bzw. wiederverwenden. Fordert beispielsweise ein Client nach einer Bean-Instanz, die noch nicht existiert, muß der Container sie neu erzeugen. Falls sie schon existiert, wird sie einfach an den Client zurückgeliefert. Der Container muß auch dafür sorgen, daß nicht mehr benötigte Bean-Instanzen gelöscht werden. Das Ganze wird als Instanzen-Pooling genannt.
    
    
  • Instanzen-Pooling und Aktivierung bzw. Passivierung:  Ein Anwendungssystem muß mit großer Belastung zurechtkommen. Es muß in der Lage sein, viele Clients bedienen zu können, ohne daß die lange Antwortzeiten entstehen. Je größer die Anzahl der Anfragen von Clients ist, desto höher ist die Anzahl der erzeugten Bean-Instanzen. Und damit zum einen die Anzahl von Bean-Instanzen nicht unkontrolliert wächst und zum anderen sie ständig wieder gelöscht werden müssen, hält der Container bestimmte Anzahl von Instanzen in einem Pool vorrätig. Solange sie sich im Pool befinden, sind sie im Zustand Pooled und deaktiviert. Bei Bedarf wird eine passende Bean aus dem Pool entnommen. Sie wird reaktiviert und befindet sich dann im Zustand Ready
    
    
  • Verteilung:  Der EJB-Container sorgt dafür, daß Clients Beans benutzen können. Es ist für den Client unerheblich , wo sich die Beans auf dem Server befinden. Der Ort, an dem die Beans existieren, ist für den transparent. Die Benutzung von Beans, die sich auf einem anderen Rechner, unterscheidet sich für den Client nicht wesentlich von der Benutzung von Objekten im gleich Adressraum. Für die Kommunikation zwischen Server und Clients wird Java RMI eingesetzt. Für die Kompatibilität mit CORBA kann auch RMI-IIOP benutzt werden. Der EJB-Container sorgt dafür, daß die Beans innerhalb des Containers von außen angesprochen werden können.
    
    
  • Transaktion (sowohl Laufzeitumgebung als auch Dienst):  Bei verteilten Anwendungen entstehen oft Fehlersituationen durch den gleichzeitigen Zugriff mehrerer Benutzer auf gemeinsame Daten. Um diese Fehlersituationen zu behandeln, werden Entwickler von Transaktionen unterstütz. Die auszuführenden Aktionen werden vom Entwickler in Transaktionen unterteilt. Der EJB-Container muß die Sorge dafür tragen, daß die einzelnen Aktionen einer Transaktion erfolgreich durchgeführt werden müssen. Falls ein Fehler auftritt, müssen alle bisher einzelnen erfolgreichdurchgeführten Aktionen wieder rückgängig gemacht werden. Die Unterstützung von Transaktionen ist ein wesentlicher Bestandteil der EJB-Spezifikation.
    
    
  • Sicherheit:  Jeder EJB-Container wird von der Spezifikation verpflichtet, eine Infrastruktur für das Sicherheitsmanagement als Bestandteil der Laufzeitumgebung zur Verfügung zu stellen. Zu dem Aufgabenbereich des jenigen, der die Beans installiert, gehört die Festlegung der Sicherheitspolitik. Für die Umsetzung dieser Sicherheitspolitik muß der EJB-Container die Sorge tragen. Die Sicherheitsmechanismen müssen für die Beans transparent sein, damit sie in möglichst vielen Systemen eingesetzt werden können. Deshalb soll im Code einer Enterprise-Bean möglichst keine Implementierung der Sicherheitsmechanismen vorhanden sein. Viel mehr sinnvoller ist die Verlagerung der Sicherheitsmechanismen in die Laufzeitumgebung der Komponenten. Zu den Sicherheitsmechanismen gehören die Rolle- und Rechteerteilung, die Authentifizierung des Benutzers durch eine Benutzerkennung und ein Paßwort und sichere Kommunikation z.B. durch den Einsatz von Secure-Socket-Layer.