Konzept: Überblick über Java 2 Platform Enterprise Edition (J2EE)
Diese Richtlinie enthält einen vollständigen Überblick über die J2EE-Plattform.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

In der heutigen schnelllebigen Welt des e-Business mit komplexen verteilten Anwendungen ist es von entscheidender Bedeutung, Unternehmensanwendungen schnell auf den Markt zu bringen. Dies bedeutet, dass Ihr Projektteam es sich nicht erlauben kann, Zeit für die Entwicklung von Services auf Systemebene aufzuwenden, wie ferne Konnektivität, Benennung, Persistenz, Sicherheit oder Transaktionsmanagement. Ihr Projektteam muss portierbare, wiederverwendbare Komponenten entwickeln und einsetzen, und sollte seine Zeit nicht damit vergeuden, erprobte und echte Architekturen neu zu erfinden.

Java™ 2 Platform, Enterprise Edition (J2EE™) unterstützt Sie dabei durch Bereitstellung eines gut dokumentierten, auf Standards basierenden Frameworks zur Entwicklung und Ausführung von verteilten, mehrschichtigen, komponentenbasierten Java-Anwendungen. Dieses Framework regelt einen Großteil der einer Anwendung zugrunde liegenden Komplexität, beispielsweise ferne Konnektivität, Benennung, Persistenz, Sicherheit und Transaktionsmanagement, so dass die Entwickler den Kopf frei haben, um sich auf die Geschäftslogik der Anwendung zu konzentrieren.

Die J2EE-Plattform besteht aus folgenden Teilen:

  • Einer Reihe von Standards für J2EE-Komponenten und für die J2EE-Plattform, auf der die Komponenten ausgeführt werden.
  • Einem Entwurf für die Anwendungsentwicklung, der die J2EE-Plattform ausführlich beschreibt, und leistungsfähige und bewährte Verfahren zur Entwicklung von J2EE-Anwendungen enthält.
  • Eine von Sun Microsystems Inc. bereitgestellte Referenzimplementierung der J2EE-Plattform, die als Standard verwendet wird, an dem kommerzielle J2EE-Produkte gemessen werden können. Die Referenzimplementierung enthält vollständig entwickelte Musteranwendungen.
  • Eine Kompatibilitätstestsuite zum Testen und Bewerten von kommerziellen J2EE-Implementierungen anhand der J2EE-Standards.

Die J2EE-Plattform ist analog zu den Services, die in Ihrem Computer von den Programmierungstools bereitgestellt werden, die das Betriebssystem nutzen. Das Betriebssystem stellt Standardservices bereit, auf deren Basis Sie Anwendungen entwickeln und ausführen können, ohne dass Sie sich um die Verwaltung von Operationen wie Plattenzugriff, Speicher, Videoausgabe, Netzbetrieb usw. kümmern müssen, die auf niedrigerer Ebene erfolgt. Ihre Aufgabe besteht darin, sich mit den Details einer Anwendung zu beschäftigen, nicht mit den Details des zugrunde liegenden Systems. Die J2EE-Plattform stellt ein hoch entwickeltes Betriebssystem für Unternehmensanwendungen bereit.

Durch Verwendung der J2EE-Plattform wird der Entwicklungsaufwand verringert, so dass Ihr Projektteam seine Anstrengungen auf die tatsächliche Geschäftslogik der Anwendung konzentrieren kann, anstatt wertvolle Entwicklungszeit bei der Lösung von Problemen auf Systemebene zu verlieren. Ein Projektteam, dass sich auf die eigentliche Aufgabe der Anwendung konzentrieren kann, anstatt sich damit zu beschäftigen, wie alle zugrunde liegenden Services bereitgestellt werden können, die die Anwendung benötigt, ist viel eher in der Lage, termingerecht ein fehlerfreies System zu liefern, das den vorgegebenen Benutzeranforderungen entspricht.

Nähere Informationen finden Sie im Überblick zur J2EE-Plattform von Sun unter http://java.sun.com/. Folgen Sie den Links zu Products & APIs > Java™ 2 Platform, Enterprise Edition (J2EE™) > Overview.

Kurze Zusammenfassung der J2EE-Entwicklung

Aus der Perspektive des Anwendungsentwicklers:

  • Sie erwerben eine kommerzielle J2EE-Plattform in Form eines J2EE-kompatiblen Servers. Das Verhalten des J2EE-Servers ist im J2EE-Standard spezifiziert.
  • Sie entwickeln J2EE-Komponenten oder erwerben vorgefertigte J2EE-Komponenten.
  • Sie implementieren die J2EE-Komponenten auf Ihrem J2EE-kompatiblen Server und führen Sie dort aus. Dieser Server stellt alle Services bereit, die die J2EE-Komponenten benötigen.

Beispiel

Ein einfaches Beispiel einer J2EE-Anwendung ist eine e-commerce-Site, in der ein Client (Benutzer) einen Webbrowser verwendet, um über Remote-Zugriff auf einen J2EE-Server zuzugreifen. Der J2EE-Server stellt Services auf der Webschicht und der Geschäftsschicht bereit und interagiert mit einer EIS-(Back-end-)Schicht (Enterprise Information Systems), die RDBMS-Zugriff gewährt.

Weshalb sollte J2EE verwendet werden?

Die J2EE-Plattform sollte für die Entwicklung von Java-e-commerce-Anwendungen oder Unternehmensanwendungen verwendet werden, wenn eine der folgenden Anforderungen zutrifft:

Jeder dieser Punkte wird im weiteren Verlauf dieses Abschnitts näher erläutert.

Standardisiertes, von der Branche getestetes Framework

J2EE-Komponenten werden in J2EE-Containern ausgeführt, die normalerweise von einem J2EE-kompatiblen Server bereitgestellt werden. Diese Container stellen eine Reihe von Standardservices (APIs) bereit, die von den J2EE-Komponenten verwendet werden. Es handelt sich dabei um folgende APIs:

  • J2SE 1.4
    • JDBC
    • Java IDL
    • Remote Method Invocation mit Internet Inter-ORB Protocol (RMI-IIOP) von CORBA
    • Java Naming and Directory Interface (JNDI)
    • Java Authentication and Authorization Service (JAAS)
  • Java Transaction API (JTA)
  • JavaMail
  • Java Message Service (JMS).
    Nähere Informationen zu JMS finden Sie unter Konzept: Java Messaging Service (JMS).
  • JavaBeans Activation Framework (JAF)
  • Enterprise JavaBeans (EJB)
  • Java Servlet
  • Java API for XML Processing (JAXP)
  • Java Connector (Anmerkung: Wird in Versionen vor J2EE 1.3 nicht unterstützt)
  • JavaServer Pages (JSP)
  • Web Services for J2EE (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)
  • Java API for XML-based RPC (JAX-RPC) (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)
  • SOAP with attachments API for Java (SAAJ) (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)
  • Java API for XML Registries (JAXR) (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)
  • J2EE Management (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)
  • Java Management Extensions (JMX) (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)
  • J2EE Deployment (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)
  • Java Authorization Service Provider Contract for Containers (JACC) (Anmerkung: Wird in Versionen vor J2EE 1.4 nicht unterstützt)

Portierbarkeit

J2EE-Komponenten und -Anwendungen sind auf J2EE-kompatible Servern portierbar, ohne dass eine Codeänderung erforderlich ist. Sie können Ihre Anwendung daher auf dem gewünschten J2EE-kompatiblen Server implementieren, indem Sie lediglich die serverspezifischen Implementierungsdaten aktualisieren, die in den in XML (eXtended Markup Language) geschriebenen Implementierungsdeskriptordateien enthalten sind.

Die Standardisierung der J2EE-Spezifikation hat in der Branche einen Wettbewerb ausgelöst, so dass Sie unter einer Reihe von J2EE-kompatiblen Servern auswählen können, je nachdem, welche Anforderungen er erfüllen soll und wie viel er kosten soll.

Wiederverwendbare Komponenten

Weil sie dem J2EE-Standard entsprechen, können vorgefertigte J2EE-Komponenten erworben werden und gemäß den Anforderungen direkt in Ihre J2EE-Anwendung integriert werden, so dass Sie den Entwicklungsaufwand (insbesondere für das Debug und Testen) dafür sparen können.

Wenn Sie eine Komponente entwickeln, können Sie sie in einer anderen Anwendung wiederverwenden, oder gegebenenfalls in anderen J2EE-kompatiblen Servern implementieren.

Bewährte und echte Architektur- und Designmuster

Die J2EE-Plattform definiert eine klar strukturierte, mehrschichtige Architektur. Indem Ihre Entwickler die J2EE-Architektur als Basis verwenden, können sie die tatsächliche Geschäftslogik für Ihre Anwendung schnell entwickeln.

Die J2EE-Dokumentation umfasst Folgendes:

  • Einen Entwurf für die Anwendungsentwicklung, der die J2EE-Plattform ausführlich beschreibt und bewährte Verfahren zur Entwicklung von J2EE-Anwendungen enthält.
  • Gut dokumentierte J2EE-Muster (Best Practices), die Lösungen für häufige J2EE-Architektur- und -Designprobleme beschreiben.

Nähere Informationen zur J2EE-Plattform finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu J2EE > Blueprints.

Skalierbarkeit

J2EE unterstützt die Skalierbarkeit zur Leistungssteigerung oder zur Bewältigung von wachsenden Arbeitslasten wie folgt:

  • Features zur Leistungsverbesserung im J2EE-Container: Zu diesen Features gehören der Zusammenschluss von Ressourcen zu einem Ressourcenpool (Datenbankverbindungspool, Session-Bean-Pool und Thread-Pool), die asynchrone Nachrichtenübermittlung und effizientes Life-Cycle-Management für die Komponenten. Beispielsweise ist das Öffnen einer Datenbankverbindung langsam. Die Datenbankverbindungen könnten auch eine knappe Ressource sein, beispielsweise aufgrund von Lizenzbeschränkungen. Die J2EE-Plattform löst dieses Problem durch Verwendung eines Datenbankverbindungspools: Der J2EE-Container verwaltet einen Pool von geöffneten Verbindungen, die gegebenenfalls einer Komponente zugeordnet werden können, so dass schnelle und effiziente Verbindungen möglich sind.
  • Lastverteilung durch Clustering: Dieselben Komponenten werden auf mehrere Server auf unterschiedlichen Maschinen implementiert. Die Arbeitslast kann anschließend wie erforderlich auf die Server verteilt werden, beispielsweise entsprechend einem Algorithmus, der die Arbeitslast im Wechsel zuteilt, oder gemäß der Serverauslastung. Die J2EE-Plattformspezifikation definiert zwar keine Funktionalität für Lastverteilung, empfiehlt diese jedoch für Server im oberen Leistungsbereich. Hersteller von J2EE-Servern bieten eine Reihe von Lösungen für die Lastverteilung.
  • Anwendungspartitionierung: Logisch getrennte Teile einer Anwendung können auf verschiedenen Servern implementiert werden. Beispielsweise können die Subsysteme für Bestand und Abrechnung einer Anwendung für Onlineversand auf separaten Servern implementiert werden.

Entwicklungs- und Implementierungstools

Die Hersteller haben auf die Nachfrage nach J2EE-Tools reagiert und bieten in ihren IDEs (Java Integrated Development Environments) eine hervorragende Unterstützung für die J2EE-Entwicklung. Dazu gehören folgende Tools:

  • Assistenten für die Servlet-Erstellung
  • Assistenten und Dialoge für die EJB-Erstellung und -Verwaltung
  • Generierung und Verwaltung von Implementierungsdeskriptoren
  • EJB-Objekt-zu-Datenbank-Zuordnung (einschließlich Generierung von Implementierungsdeskriptorinformationen für containergesteuerte Beziehungen)
  • Integration mit einem Webcontainer zum Testen von Web-Services
  • Nahtloses Implementieren, Debug und Testen von EJBs in IDE durch Integration mit einem J2EE-EJB-Container und dessen Implementierungstools
  • Automatische Generierung von J2EE-Testclients
  • Integration mit UML-Modellierungstools

Back-end-Integration

Das Back-end bezeichnet die EIS-Schicht (Enterprise Information System) der Anwendung. Back-end-Systeme können z. B. RDBMS, traditionelle Systeme, oder ERP-Systeme (Enterprise Resource Planning) sein.

J2EE unterstützt den transaktionsorientierten Zugriff auf RDBMS EISs durch Verwendung der JDBC- und JTA-APIs. Außerdem unterstützen die EJB-Container eine über Container realisierte Transaktionspersistenz, bei der transaktionsorientierte RDBMS-Verbindungen und -Zugriffe automatisch vom Container gesteuert werden.

Das J2EE Connector Architecture Service Provider Interface (SPI) definiert einen Standard für die Verbindung von Nicht-RDBMS-EIS-Ressourcen mit einem J2EE-Container. Ein EIS-spezifischer Ressourcenadapter (der vom EIS-Hersteller bereitgestellt wird) wird in den J2EE-Container integriert und erweitert den Container durch eine transaktionsorientierte und sichere Unterstützung für das entsprechende EIS. Anschließend können die Komponenten im Container über das J2EE Connector Architecture SPI auf das EIS zugreifen.

Anmerkung: Das J2EE Connector Architecture SPI wird in Versionen vor J2EE 1.3 nicht unterstützt.

Sicherheit

J2EE bietet einfache, leistungsfähige Sicherheitsfunktionen. Die Sicherheitsinformationen für J2EE-Komponenten sind in deren Implementierungsdeskriptoren definiert. Diese Informationen definieren, welche Sicherheitsrollen für den Zugriff auf einen bestimmten URL und/oder auf Methoden einer Komponente berechtigt sind. Eine Sicherheitsrolle ist lediglich ein logischer Name für eine Gruppe von Benutzern. Beispielsweise könnte den Mitgliedern des Managementteams eines Unternehmens eine Rolle mit dem Namen "Manager" zugeordnet werden.

Weil die Sicherheitsinformationen im Implementierungsdeskriptor deklariert sind, kann das Sicherheitsverhalten ohne aufwändige Codeaktualisierung, -Debug und -test geändert werden.

Mehrschichtige Architektur

J2EE ist eine mehrschichtige verteilte Anwendungsarchitektur bestehend aus einer Clientschicht, einer Mittelschicht und einer EIS- oder Back-end-Schicht.

Abbildung 1 zeigt die mehrschichtige Architektur der J2EE-Plattform sowie die verschiedenen J2EE-Container, die die J2EE-Komponenten unterstützen.

Im Begleittext beschriebenes Diagramm.

Abbildung 1: Mehrschichtige J2EE-Architektur

Clientschicht

Die Komponenten der Clientschicht werden in Clientcontainern ausgeführt. Die Clientschicht kann auf eine der folgenden Arten implementiert werden:

  • Eigenständige Java-Anwendungen - normalerweise eine GUI (auch "Thick Client" genannt). Eine solche Java-Anwendung muss auf jeder Clientmaschine installiert werden. Eine Java-Anwendung kann über APIs, wie z. B. JDBC, auf die EIS-Schicht oder die Mittelschicht zugreifen.
  • Statische HTML-Seiten - stellen eine eingeschränkte GUI für eine Anwendung bereit.
  • Dynamisches HTML - generiert von JSP-Seiten oder Servlets.
  • Applets - werden in einem Webbrowser ausgeführt. Applets sind in eine HTML-Seite eingebettet und werden normalerweise für eine GUI verwendet.

Mittelschicht

Die Mittelschicht besteht aus der Webschicht und der Geschätfsschicht. Komponenten der Webschicht werden in einem J2EE-Webserver ausgeführt, der einen Webcontainer bereitstellt. Komponenten der Geschäftsschicht werden in einem J2EE-Anwendungsserver ausgeführt, der einen EJB-Container bereitstellt.

Webschicht

Komponenten der Webschicht sind Servlets und JSP-Seiten, die die Interaktion mit der Clientschicht steuern, so dass die Clients von der Business- und EIS-Schicht isoliert werden. Clients stellen Anfragen an die Webschicht, die diese Anfragen verarbeitet und die Antworten an die Clients zurückgibt. Anfragen der Clients an Komponenten in der Webschicht führen im allgemeinen zu Anfragen der Webschicht an Komponenten in der Geschäftsschicht, die wiederum Anfragen an die EIS-Schicht zur Folge haben können.

Geschäftsschicht

Komponenten der Geschäftsschicht sind EJBs.

  • Sie enthalten die Geschäftslogik der Anwendung.
  • Sie stellen entsprechend der Geschäftslogik Anfragen an die EIS-Schicht, die normalerweise aufgrund einer Anfrage aus der Webschicht erfolgen.

EIS-Schicht

Die EIS-Schicht stellt die gespeicherten Daten der Anwendung dar, häufig in Form eines RDBMS. Die EIS-Schicht kann auch aus traditionellen Systemen oder ERPs bestehen, auf die Zugriff über die J2EE Connector Architecture API besteht.

Nähere Informationen zur J2EE Connector Architecture API finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > J2EE Connector Architecture.

Nähere Informationen zu den Standardimplementierungskonfigurationen von J2EE finden Sie unter Konzept: J2EE-Implementierungskonfigurationen.

J2EE-Server

J2EE-Server sind kommerzielle Produkte, die die J2EE-Plattform implementieren. Beispiele für kommerzielle J2EE-Server sind BEA WebLogic, Borland Enterprise Server, IBM WebSphere und iPlanet.

Der Begriff "J2EE-Server" ist relativ weit gefasst. Normalerweise ist damit ein J2EE-Server gemeint, der sowohl einen Webcontainer als auch einen EJB-Container unterstützt. Im engeren Sinne unterstützt ein J2EE-Webserver (wie z. B. die Referenzimplementierung des J2EE-Webservers Tomcat) einen Webcontainer, und ein J2EE-Anwendungsserver (oder EJB-Server) unterstützt einen EJB-Container.

J2EE-Container

J2EE-Komponenten befinden sich in J2EE-Containern oder werden darin ausgeführt. J2EE-Container werden im allgemeinen als Teil eines kommerziellen J2EE-Servers bereitgestellt. Die Container bieten eine Laufzeitumgebung und eine Standardgruppe von Services (APIs) für die J2EE-Komponenten, die im Container ausgeführt werden, und unterstützen die Standard-J2SE-APIs.

J2EE definiert folgende Containerarten:

Anwendungsclientcontainer

Ein J2EE-Anwendungsclient wird in einem Anwendungsclientcontainer ausgeführt, der die folgenden J2EE-APIs unterstützt: JDBC, JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, J2EE Management und JMX.

Im Prinzip bestehen die Anwendungsclientcontainer aus der Standard-J2SE-Installation. Der Anwendungsclientcontainer muss das JAAS-Callback-Handler-Interface unterstützen, um die Sicherheitsanforderungen der restlichen Unternehmensanwendung in den Web- und EJB-Containern zu erfüllen.

Applet-Container

Ein Applet wird in einem Applet-Container ausgeführt, der das Applet-Programmiermodell sowie die Standard-J2SE-APIs unterstützt. Applet-Container werden praktisch als Java-Plug-in für einen Webbrowser bereitgestellt.

Webcontainer

Webkomponenten (JSP-Seiten und Servlets) werden in einem Webcontainer ausgeführt, der entweder als Teil eines J2EE-Servers oder als eigenständiger J2EE-Webserver bereitgestellt wird. Ein Webcontainer unterstützt die folgenden J2EE-APIs und Pakete: JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, J2EE Connector Architecture, JTA, JSR, SAAJ, J2EE Management, Java Servlet und JSP.

EJB-Container

EJB-Komponenten werden in einem EJB-Container ausgeführt, der als Teil eines J2EE-Servers bereitgestellt wird.

Ein EJB-Container unterstützt die folgenden J2EE-APIs und -Technologien: EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, JTA, JSR, SAAJ, J2EE Management und J2EE Connector Architecture.

Eine Übersicht über die Hauptfunktionalität der EJB-Container finden Sie in folgenden Unterabschnitten:

Datenfernverarbeitung

EJB-Container verbergen die Komplexität der Datenfernverarbeitung gegenüber den Entwicklern, indem sie Containerklassen verwenden, die die EJB-Schnittstellen implementieren (die Klassen werden zusammen mit RMI-Stub-Klassen während der Kompilierung der EJB von den Containertools zur Verwendung durch die Clients generiert). Diese Implementierungsklassen sind ferne Java-Objekte, auf die ein Client mit der Java-RMI zugreifen kann. Aus der Perspektive des Clients betrachtet bedeutet dies, dass der Client lediglich Methoden der EJB-Schnittstelle aufruft, ohne Berücksichtigung der Datenfernverarbeitung.

Parallelität

EJB-Container können Anforderungen von mehreren Clients, die gleichzeitig erfolgen, transparent verwalten. Clients können so agieren, als hätten sie exklusiven Zugriff auf die EJB. Wenn beispielsweise zwei Clients dieselbe Entity-EJB anfordern, liefert der Container jedem Client eine eigene Instanz und verwaltet die Synchronisation intern ohne Wissen des Clients.

Benennung

Der EJB-Container stellt einen JNDI-Namespace zur Lokalisierung der im Container implementierten EJBs bereit. EJB-Clients können nach EJBs suchen, um eine Home-Schnittstelle zu erhalten. Die Home-Schnittstelle für ein EJB stellt Methoden zum Suchen und Erstellen von EJB-Instanzen bereit. Clients können auf die EJBs zugreifen, sofern der JNDI-Namenskontext von ihrer Position aus aufgerufen werden kann.

Persistenz

EJB-Entwickler können unter zwei Methoden zum Speichern von persistenten Daten der Entity-EJB wählen: Container Managed Persistence (CMP, d. h. über Container realisierte Transaktionspersistenz) und Bean Managed Persistence (BMP, über JavaBeans realisierte Transaktionspersistenz). CMP delegiert die Zuständigkeit für die Implementierung des Datenzugriffcodes an den Container, während bei Verwendung von BMP der EJB-Entwickler für die Implementierung dieses Codes zuständig ist. CMP erlaubt es dem EJB-Entwickler, für den Zugriff auf den persistenten Speicher eine Standardimplementierung zu verwenden. Dazu muss er lediglich containergesteuerte Felder in einem Implementierungsdeskriptor deklarieren.

Transaktionsmanagement

Eine Transaktion ist eine Operationsfolge, die atomar erfolgreich ist oder atomar fehlschlägt, d. h., wenn eine Operation in der Folge fehlschlägt, wird am Systemstatus keine Änderung vorgenommen. Angenommen, Sie möchten z. B. Flugtickets ausstellen. In diesem Fall würden Sie das Kreditkartenkonto des Kunden prüfen, das Konto belasten und anschließend die Tickets ausstellen. Diese Operationsfolge sollte in einer einzigen Transaktion erfolgen. Wenn daher eine der Operationen fehlschlägt, bleibt das Kreditkartenkonto des Kunden unverändert und es werden keine Tickets ausgestellt.

EJBs können entweder die Bean-gesteuerte Transaktionsdemarkation oder die containergesteuerte Transaktionsdemarkation verwenden. Diese werden in den nächsten beiden Abschnitten erläutert.

Bean-gesteuerte Transaktionsdemarkation

Bei der Bean-gesteuerten Transaktionsdemarkation wird eine einfache API verwendet, um die Grenzen der Transaktion zu demarkieren. Dabei handelt es sich um die Java Transaction API (JTA). Sie wird verwendet, um die Transaktionsdemarkation über das Programm zu steuern, beispielsweise indem eine der Methoden begin(), commit() und rollback() der JTA-UserTransaction-Schnittstelle aufgerufen wird. Das Codieren der Rollback-Logik für Transaktionsausnahmebedingungen ist Aufgabe des Entwicklers, da der Container dies nicht automatisch steuern kann.

Anmerkung: Entity-EJBs können die Bean-gesteuerte Transaktionsdemarkation nicht verwenden. Sie können nur die containergesteuerte Transaktionsdemarkation verwenden.

Containergesteuerte Transaktionsdemarkation

Bei der containergesteuerten Transaktionsdemarkation werden Beginn und Ende der Transaktionen nicht über Code gesteuert. Statt dessen werden für jede Methode Ihrer EJB Transaktionsattribute in den EJB-Implementierungsdeskriptor aufgenommen. Das Transaktionsattribut (eines der Attribute Required, RequiresNew, NotSupported, Supports, Mandatory oder Never) zeigt dem Container den Geltungsbereich der Transaktion für die Methode an. Wenn beispielsweise innerhalb einer Transaktion ein Client ausgeführt wird und dieser Client eine Methode Ihrer EJB aufruft, deren Transaktionsattribut auf Required gesetzt ist, dann wird die Methode innerhalb des Geltungsbereichs der vorhandenen Transaktion aufgerufen.

Wenn möglich, sollten Sie die containergesteuerte Transaktionsdemarkation anstelle der Bean-gesteuertenTransaktionsdemarkation verwenden, so dass Hinzufügen, Debug und Test von Transaktionsdemarkationscode in Ihrer Komponente entfällt. Statt dessen wird das Transaktionsverhalten jeder Ihrer EJB-Methoden zum Zeitpunkt der Implementierung im Implementierungsdeskriptor festgelegt. Daher kann das Transaktionsverhalten ohne aufwändige Codeaktualisierung, -Debug und -test geändert werden.

Verteilte Transaktionen

Eine verteilte Transaktion ist eine Transaktion, die über mehrere Datenbanken und/oder über mehrere Anwendungen hinweg koordiniert werden muss. Sie steht im Gegensatz zu einer zentralisierten Transaktion, die beispielsweise dann vorliegt, wenn ein einzelner J2EE-Anwendungsserver Transaktionen in einer einzelnen Datenbank festschreibt.

Für verteilte Transaktionen, die z. B. dann vorliegen, wenn mehrere Datenbanken aktualisiert werden, ist eine zweiphasige Festschreibung erforderlich. Einige EJB-Container (z. B. BEA WebLogic Server 6.0) unterstützen die zweiphasige Festschreibung über das XA-Protokoll von Open Group. Der Anwendungsprogrammierer muss keinen Code schreiben, um die zweiphasige Festschreibung zu steuern, sie wird vom EJB-Container gesteuert.

Sicherheitsmanagement

Der EJB-Container steuert die EJB-Sicherheit mit Hilfe von Sicherheitsinformationen im Implementierungsdeskriptor. Im Implementierungsdeskriptor muss eine Gruppe von Rollen deklariert werden, und für jede EJB-Methode müssen die Rollen deklariert werden, die zum Aufruf der Methode berechtigt sind.

Zur Laufzeit wird jedem Client der EJB eine Rolle zugeordnet, und der EJB-Container steuert den Zugriff auf die Methoden der EJB, indem er prüft, ob eine bestimmte Clientrolle zum Aufruf einer bestimmten Methode berechtigt ist.

Weil die Sicherheitsinformationen im Implementierungsdeskriptor deklariert sind, kann das Sicherheitsverhalten ohne aufwändige Codeaktualisierung, -Debug und -test geändert werden.

Life-Cycle-Management

Als Antwort auf die Clientanfragen durchlaufen EJBs während ihres Lebenszyklus eine Reihe von Zuständen. Der EJB-Container ist zuständig für die Steuerung dieses Lebenszyklus.

Zum Zeitpunkt des Containerstarts erstellt der Container einen Pool von EJB-Instanzen in einem Ressourcenpool (um die Startzeit zu reduzieren, wenn die EJB-Ressource benötigt wird). Wenn ein EJB-Client das Erstellen einer EJB anfordert, wird ihm eine Instanz aus dem Pool zugeordnet. Anschließend kann der Client die EJB anfordern. Wenn ein EJB-Client das Entfernen einer EJB anfordert, wird die Instanz an den Pool zurückgegeben.

Der EJB-Container benachrichtigt eine EJB-Instanz über verschiedene Ereignisse im EJB-Lebenszyklus. Dazu verwendet er eine Reihe von Standard-Callback-Methoden wie die folgenden:

  • ejbCreate() - wird vom Container aufgerufen, nachdem die EJB-Instanz erstellt wurde
  • ejbRemove() - wird vom Container aufgerufen, wenn die EJB-Instanz gelöscht werden soll
  • ejbActivate() - wird vom Container aufgerufen, nachdem die EJB-Instanz aus einem passiven Status wiederhergestellt wird
  • ejbPassivate() - wird vom Container aufgerufen, wenn die EJB-Instanz passiviert werden soll
  • ejbStore() - wird vom Container aufgerufen, wenn die EJB-Instanz in eine Datenbank geschrieben werden soll
  • ejbLoad() - wird vom Container aufgerufen, nachdem die Felder der EJB-Instanz aus der Datenbank geladen wurden

Jede EJB muss diese Callbacks implementieren, obwohl die Implementierung der Callback-Methode in der EJB häufig leer ist. Beispiel: Der Container ruft die EJB-Methode ejbRemove() auf, um der EJB mitzuteilen, dass die EJB entfernt werden soll (aufgrund einer Clientanforderung zum Entfernen der EJB). In der EJB-Methode ejbRemove() müssten die Operationen codiert werden, die ausgeführt werden müssen, bevor die EJB entfernt werden kann, beispielsweise die Freigabe der von der EJB belegten Ressourcen.

EJBs können gegebenenfalls vom Container passiviert werden, d. h. die Statusinformationen werden gespeichert und die EJB-Instanz wird zur Verwendung durch den Ressourcenpool freigegeben. Eine passivierte EJB wird vom Container aktiviert, d. h. die Statusinformationen werden wiederhergestellt, wenn eine Clientanfrage nach diesem bestimmten EJB-Objekt empfangen wird.

Datenbankverbindungspool

Das Öffnen einer Datenbankverbindung ist langsam. Die Datenbankverbindungen könnten außerdem eine knappe Ressource sein, beispielsweise aufgrund von Lizenzbeschränkungen. Der EJB-Container löst dieses Problem durch Verwendung eines Datenbankverbindungspools: Der Container verwaltet einen Pool von geöffneten Verbindungen, die gegebenenfalls einer Komponente zugeordnet oder wieder freigegeben werden können, so dass schnelle und effiziente Verbindungen möglich sind.

Datenbankverbindungen für Entity-Beans, die CMP verwenden, werden automatisch verwaltet. Ein Verbindungs- oder SQL-Code muss nicht geschrieben werden, sondern Sie geben lediglich den JNDI-Namen der JDBC-Datenquelle im EJB-Implementierungsdeskriptor an und verwenden containerspezifische Implementierungstools, um die Verbindungsroutinen zu generieren. Der Container verwaltet den Datenbankverbindungspool.

Für Entity-Beans, die BMP verwenden, oder für Session-EJBs müssen Sie Verbindungscode schreiben, damit eine Verbindung zu einer JDBC-Datenquelle hergestellt wird, und SQL-Code schreiben, um auf die Datenbank zuzugreifen. Die JDBC-Datenquelle wird weiterhin vom Container verwaltet, d. h. sie verwendet tatsächlich einen vom Container verwalteten Datenbankverbindungspool.

Messaging

EJB-Container müssen das Messaging (Nachrichtenaustausch) unterstützen, um einen asynchronen Austausch von Nachrichten zu ermöglichen. JMS oder andere Nachrichtentypen können für Nachrichten verwendet werden, die vom nachrichtengesteuerten EBJ-Prozess geliefert werden. Aufgrund der Abhängigkeit des JMS von EJBs, müssen sie den transaktionsorientierten Zugriff aus Web- und EJB-Containerkomponenten, wie Servlets, JSP-Seiten und EJBs, unterstützen.

J2EE-Komponenten

Der folgende Abschnitt enthält eine kurze Erläuterung aller Arten von J2EE-Komponenten. J2EE-Komponenten sind Applets, Anwendungsclients, Webkomponenten und Enterprise JavaBeans. J2EE-Komponenten werden in J2EE-Containern ausgeführt.

Applets

Applets sind kleine Programme, die zusammen mit einer Webseite gesendet werden können und in einem Webbrowser ausgeführt werden. Sie könnten auch in anderen Umgebungen ausgeführt werden, die das Applet-Programmiermodell unterstützen.

Applets werden hauptsächlich zur Implementierung von Benutzerschnittstellen verwendet und können das Leistungsspektrum von HTML-Seiten erheblich erweitern.

Anwendungsclients

Anwendungsclients sind Java-Anwendungen. Sie haben Zugriff auf die Funktionen der J2EE-Mittelschicht und EIS-Schicht. Normalerweise sind sie Desktopanwendungen, die eine Benutzerschnittstelle bereitstellen. Sie können zur Implementierung eines "Thick Client" verwendet werden. Siehe dazu die Beschreibung in Konzept: Verteilungsmuster.

Webkomponenten

Java-Servlets

Mit Hilfe der Java-Servlet-Technologie kann ein Webserver Anforderungen von einem Webclient verarbeiten und Antworten mit dynamischem Inhalt zurückgeben. Ein Java-Servlet kann mit anderen Web- und EJB-Komponenten zusammenarbeiten, um diesen dynamischen Inhalt zu erzeugen. Der generierte Inhalt kann die Form eines beliebigen textbasierten Dokuments haben, einschließlich HTML und XML. Außerdem kann ein Java-Servlet als Web-Services-Endpunkt in Kollaboration mit der API JAX-RPC verwendet werden.

Anmerkung: Die Verwendung des Servlets als Web-Services-Endpunkt ist ein neues Feature von J2EE 1.4 (JAX-RPC 1.1) und wird daher in früheren Versionen nicht unterstützt.

Nähere Informationen zu J2EE-Servlets finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu J2EE > Blueprints.

JavaServer Pages

Die Technologie JavaServer Pages (JSP) basiert auf Java-Servlets, ist aber textbasiert anstatt codebasiert. Eine JSP-Seite verarbeitet Anfragen und generiert Antworten wie ein Servlet, aber ihre Logik ist primär an der Darstellung orientiert. Eine JSP-Seite enthält zum größten Teil statisches HTML, das das Format für die Darstellung der Daten definiert, die von anderen Quellen empfangen werden, z. B. JavaBeans und EJBs. Zur Erweiterung von JSP oder zum Hinzufügen neuer Funktionalität kann der Entwickler von Webkomponenten Bibliotheken mit angepassten Tags erstellen.

Nähere Informationen zu JSP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu J2EE > Blueprints.

HTML-Seiten

HTML-Seiten können zur Unterstützung von Benutzerschnittstellen verwendet werden. Sie können als statische Webseiten definiert oder von Servlets und JSP-Seiten generiert werden. Die J2EE-Spezifikation fordert, dass J2EE-Webclients die Darstellung von HTML-Seiten unterstützen.

JavaBeans

Die JavaBeans API definiert eine Architektur zur Erstellung wiederverwendbarer Komponenten. Diese Komponenten können mit Hilfe von Tools zur Anwendungserstellung editiert und assembliert werden Zur Implementierung von JavaBeans wird regulärer Java-Code verwendet, so dass die Implementierung für andere Programmierer, die diese Komponenten eventuell verwenden möchten, sowie für die Tools lesbar bleibt.

JavaBeans ist keine J2EE-Technologie, wird aber von den J2EE-Technologien verwendet. Beispielsweise können EJBs JavaBeans als Wertobjekte verwenden. Lesen Sie bezüglich der Unterschiede zwischen JavaBeans und Enterprise JavaBeans den Abschnitt Vergleich zwischen JavaBeans und EJBs.

Nähere Informationen zu JavaBeans finden Sie unter Konzept: JavaBeans.

Enterprise JavaBeans

Die Spezifikation für Enterprise JavaBeans definiert eine Architektur für die Entwicklung und Implementierung von komponentenbasierten, transaktionalen verteilten Geschäftsanwendungen.

Die von der EJB-Spezifikation definierten Komponenten werden als Enterprise JavaBeans (EJBs) bezeichnet. EJBs sind serverseitige Java-Komponenten, in denen Sie die Geschäftsregeln Ihrer Anwendung implementieren.

EJBs werden in einer Umgebung implementiert und ausgeführt, die als EJB-Container bezeichnet wird und weiter oben unter der Überschrift EJB-Container erläutert wurde. Ein EJB-Container stellt Services wie Transaktionsmanagement, Datenbankkonnektivität und Sicherheit zur Verfügung. Indem sie diese Komplexität verbirgt, erlaubt es die EJB-Architektur, dass sich die Entwickler der Komponenten auf die Geschäftslogik konzentrieren können.

Eine Enterprise JavaBean (EJB) ist die Kollaboration (Collaboration) von Java-Schnittstellen, einer EJB-Implementierungsklasse und einem XML-Implementierungsdeskriptor. Die EJB-Schnittstellen und Implementierungsklassen müssen mit Regeln konform sein, die in der EJB-Spezifiktion definiert sind, beispielsweise müssen bestimmte Schnittstellen implementiert und bestimmte Callback-Methoden bereitgestellt werden.

Die EJB-Schnittstellen umfassen Home-Schnittstellen, die Methoden zum Suchen und Erstellen von EJB-Instanzen bereitstellen, und Komponentenschnittstellen, die Geschäftsmethoden für eine bestimmte EJB-Instanz bereitstellen. Dabei kann es sich um ferne Schnittstellen handeln, d. h., sie können über das Netz aufgerufen werden, oder um lokale Schnittstellen, d. h., sie müssen von demselben Prozess (oder genauer gesagt in derselben Java Virtual Machine) aufgerufen werden. Die EJB-Schnittstellen werden von EJB-Containerklassen implementiert, die Methoden an die EJB-Implementierungsklasse delegieren. Eine Ausnahme ist eine Finder-Methode einer containergesteuerten Entity-EJB, die von der Containerklasse selbst gesteuert wird.

Es gibt drei Arten von EJBs: Session-Beans, Entity-Beans und nachrichtengesteuerte Beans.

Nähere Informationen zu EJBs finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu J2EE > Blueprints.

Session-Beans

Eine Session-Bean-Komponente stellt Services bereit, die eine clientspezifische Geschäftslogik implementieren. Ein einzelner Client kann über lokale oder ferne Schnittstellen auf jede Session-Bean zugreifen. Session-Beans können Daten in einer Datenbank speichern, sie rufen in der Regel jedoch Entity-Beans auf, die Geschäftsobjekte darstellen, um Daten zu speichern. Session-Bean-Instanzen können einen transienten Dialogstatus annehmen.

Eine Session-Bean kann über die Methode getAllCustomers() verfügen, die die Menge aller Kunden in der Datenbank zurückgibt. Diese Bean würde ihre Informationen von der Entity-Bean Customer erhalten und die Ergebnisse an den Client zurückgeben.

Stateless-Session-Beans, d. h. Session-Beans ohne Statusaufzeichnung, können als Web-Services-Endpunkte gemäß der JSR- und EJB-Spezifikation verwendet werden.

Anmerkung: Die Verwendung von Stateless-Session-Beans als Web-Services ist ein neues Feature in J2EE 1.4 (JSR 109 und EJB 2.1) und wird daher in früheren Versionen nicht unterstützt.

Nähere Informationen zu Session-Beans finden Sie in der Enterprise JavaBeans Spezifikation Version 2.1 unter http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Enterprise JavaBeans.

Entity-Beans

Eine Entity-Bean-Komponente stellt Services bereit, die geschäftsobjektspezifische Logik implementieren. Mehrere Clients können über lokale oder ferne Schnittstellen gleichzeitig auf eine Entity-Bean-Instanz zugreifen. Entity-Beans speichern Geschäftsobjektdaten in Datenbanken, und die gespeicherten Daten können einen Container- oder Clientabsturz unbeschädigt überstehen.

Eine Entity-Bean könnte einen Kunden darstellen, der als Zeile in der Kundentabelle einer relationalen Datenbank gespeichert ist. Der EJB-Entwickler wählt die Methode der Persistenz aus, in diesem Fall eine relationale Datenbank.

Es gibt zwei Methoden der Entity-Bean-Persistenz: über Container realisierte Transaktionspersistenz (Container-Managed Persistence, CMP) und über JavaBeans realisierte Transaktionspersistenz (Bean-Managed Persistence, BMP). BMP-Entity-Beans müssen den Datenzugriffscode implementieren, während diese Funktionalität in den CMP-Entity-Beans über den Container implementiert ist. CMP-Containerimplementierungen werden normalerweise für die Persistenz in relationalen Datenbanken bereitgestellt, obwohl auch andere Arten der Persistenz möglich sind (z. B. Objektdatenbank, dateibasierte Persistenz usw.).

Nähere Informationen zu Entity-Beans finden Sie in der Enterprise JavaBeans Spezifikation Version 2.1 unter http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Enterprise JavaBeans.

Nachrichtengesteuerte Beans

Eine nachrichtengesteuerte Bean-Komponente stellt einen Service bereit, der die für die Nachrichtenverarbeitung spezifische Geschäftslogik implementiert. Nur der Container kann diesen Service aufrufen. Der Client kann diesen Service nicht direkt über ferne oder lokale Schnittstellen aufrufen. Wenn eine Nachricht an einem von der Bean verwalteten Ziel- oder Endpunkt ankommt, ruft der Container eine Instanz der nachrichtengesteuerten Bean auf, die dem Ziel als MessageListener zugeordnet ist. Nachrichtengesteuerte Bean-Instanzen unterstützen keinen Dialogstatus, aber sie können Instanzvariablen mit Ressourcenreferenzen (z. B. eine Datenbankverbindung) über mehrere Methodenaufrufe hinweg aufrechterhalten.

Anmerkung: Nachrichtengesteuerte Beans werden vor EJB 2.0 nicht unterstützt. Die Unterstützung anderer Nachrichtentypen als JMS ist ein neues Feature der EJB-Spezifikation 2.1 und wird daher in früheren Versionen nicht unterstützt.

Nähere Informationen zu nachrichtengesteuerten Beans finden Sie in der Enterprise JavaBeans Spezifikation Version 2.0 unter http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Enterprise JavaBeans.

Vergleich zwischen JavaBeans und EJBs

Obwohl sie einen ähnlichen Namen haben, sind EJBs weitaus komplexer als reguläre JavaBeans. Beide definieren Architekturen für wiederverwendbare Komponenten, aber EJBs fügen die erforderliche Unterstützung zur Erstellung von verteilten Mehrbenutzerservices hinzu. Beide Komponententypen können mit Tools zur Anwendungserstellung assembliert werden, aber EJBs müssen in einem EJB-Container implementiert werden, damit sie ausgeführt werden können.

Services (APIs) für J2EE-Komponenten

J2EE-Container unterstützen alle J2SE-Standard-APIs sowie, abhängig vom Containertyp, eine Untermenge der J2EE-APIs. Die Komponenten in einem Container können auf diese verfügbare Untermenge zugreifen. Die folgende Tabelle enthält eine Kurzbeschreibung aller APIs und listet die J2EE-Container auf, in der sie verfügbar sind.

Name
Beschreibung
J2EE-Containers, in denen
die APIs verfügbar sind

EJB 2.1

Die EJB-Spezifikation definiert ein Komponentenmodell für EJB-Komponenten der Business-Ebene, die automatisch Services wie ferne Kommunikation, Transaktionsmanagement, Sicherheit und Persistenz unterstützen.

Nähere Informationen zu EJB finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Enterprise JavaBeans.

  • EJB
  • Anwendungsclient*
  • Web*

* nur Client-API

JAAS

Java Authentication and Authorization Service (JAAS) stellt Services zur Authentifizierung und Autorisierung von Benutzern bereit, um sicherzustellen, dass diese zur Ausführung einer Aktion berechtigt sind.

Nähere Informationen zu JAAS finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2SE > Core Java > Java Authentication and Authorization Service (JAAS).

  • Anwendungsclient
  • Web
  • EJB

JAF 1.0

Das JavaBeans Activation Framework (JAF) stellt Services bereit, mit denen Daten identifiziert werden und eine JavaBean zur Bearbeitung dieser Daten instanziert wird.

Nähere Informationen zu JAF finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2SE > Desktop Java > JavaBeans > JavaBeans Activation Framework.

  • Anwendungsclient
  • Web
  • EJB

JAXP 1.2

Java API for XML Processing (JAXP) stellt eine abstrakte Schnittstelle für die XML-Dokumentverarbeitung bereit, die mit kompatiblen Parsern und Umsetzungsprogrammen genutzt werden kann, die DOM SAX oder XSLT verwenden.

Nähere Informationen zu JAXP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Java API for XML Processing (JAXP).

  • Anwendungsclient
  • Web
  • EJB

JAX-RPC 1.1

Die Spezifikation JAX-RPC definiert Client-APIs für den Zugriff auf Webservices sowie Verfahren zur Implementierung von Web-Service-Endpunkten.

Nähere Informationen zu JAX-RPC finden Sie unter JAX-RPC.

  • Anwendungsclient
  • Web
  • EJB

Web Services for J2EE 1.1

Die Spezifikation Web Services for J2EE (JSR-109) definiert das Leistungsspektrum, das ein J2EE-Anwendungsserver
zur Implementierung von Web-Service-Endpunkten unterstützen muss.

Nähere Informationen zu Web Services for J2EE finden Sie auf der Website http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html

  • Anwendungsclient
  • Web
  • EJB

SAAJ 1.2

Die API SSAJ bietet die Möglichkeit der Bearbeitung von SOAP-Nachrichten.

Nähere Informationen zu JAXP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > SOAP with Attachments API for Java (SAAJ).

  • Anwendungsclient
  • Web
  • EJB

JAXR 1.0

Die JAXR/JAXR-Spezifikation definiert APIs für den Clientzugriff auf XML-basierte Registrys wie WebXML-Registrys und UDDI-Registrys.

Nähere Informationen zu JAXP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Java API for XML Registries (JAXR).

  • Anwendungsclient
  • Web
  • EJB

JavaMail 1.3

Die API JavaMail stellt ein Framework bereit, das zwecks Erstellung von Java-basierten E-Mail-Anwendungen erweitert werden kann.

Nähere Informationen zu JavaMail finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > JavaMail.

  • Anwendungsclient
  • Web
  • EJB

JDBC 3.0

Java Database Connectivity (JDBC) ist eine API für den Zugriff auf Tabellendatenquellen wie SQL-Datenbanken, Spreadsheets und Flachdateien.

Nähere Informationen zu JDBC finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > JDBC.

  • Anwendungsclient
  • Web
  • EJB

JMS 1.1

Java Message Service (JMS) stellt Services für asynchrones Messaging zum Zweck der Datenübertragung und Benachrichtigung über Ereignisse bereit. Mit JMS ist es möglich, nachrichtengesteuerte EJBs zu verwenden, um Nachrichten, die an JMS-Topics und -Warteschlangen übergeben wurden, asynchron zu verarbeiten.

Nähere Informationen zu JMS finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Java Message Service.

  • Anwendungsclient
  • Web
  • EJB

JNDI

Die Spezifikation Java Naming and Directory Interface (JNDI) stellt Benennungs- und Verzeichnisservices zwecks Registrierung und Suche von verteilten Komponenten und Ressourcen bereit. Die Clients müssen lediglich den registrierten JNDI-Namen der Komponente oder Ressource kennen, deren tatsächliche Position im Netz muss nicht bekannt sein.

Beispiel: EJBs werden zum Zeitpunkt der Implementierung mit Hilfe des Feldes ejb-name des Implementierungsdeskriptors im Unternehmensverzeichnis registriert. J2EE-Clients suchen eine EJB mit der JDNI-Suchfunktion: Die Clients müssen lediglich den Namen kennen, unter dem die EJB im Verzeichnis registriert wurde. Die JNDI-Suchfunktion gibt eine Referenz auf das Ausgangsobjekt der EJB zurück.

Nähere Informationen zu JNDI finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2SE > Core Java > Java Naming and Directory Interface (JNDI).

  • Anwendungsclient
  • Web
  • EJB

JTA 1.0

Java Transaction API (JTA) definiert Schnittstellen zur Verwaltung verteilter Transaktionsservices zwischen Transaktionsmanager, Ressourcenmanager, Anwendungsserver und Anwendung.

Nähere Informationen zu JTA finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu "Products & Technologies > J2EE > Transactions".

  • Web
  • EJB

J2EE Connector 1.5

Das J2EE Connector Architecture Service Provider Interface (SPI) definiert einen Standard zur Verbindung von EIS-Ressourcen mit einem J2EE-Container: Ein EIS-spezifischer Ressourcenadapter (der vom EIS-Hersteller bereitgestellt wird) wird in den J2EE-Container integriert und erweitert den Container durch eine transaktionsorientierte und sichere Unterstützung für das entsprechende EIS. Anschließend können die Komponenten im Container über das J2EE Connector Architecture SPI auf das EIS zugreifen.

Nähere Informationen zu J2EE Connectors finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu "Products & Technologies > J2EE > J2EE Connector Architecture".

  • Web
  • EJB

JSP 2.0

Die Technologie JavaServer Pages bietet Webentwicklern die Möglichkeit zum Erstellen und Verwalten von dynamischen Webseiten. JSP-Seiten sind textbasiert und verwenden XML-ähnliche Tags, um Geschäftslogik auszuführen und angepasste Inhalte zu generieren. Die Technologie JSP ermöglicht das Delegieren der Geschäftslogik an andere Komponenten, so dass nur die Darstellungslogik in die JSP-Seite eingebettet werden muss.

Nähere Informationen zu JSP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu "Products & Technologies > J2EE > JavaServer Pages".

Web

Servlet 2.4

Java Servlets erweitern die Funktionalität des Webservers, indem Sie das Erstellen von webbasierten Anwendungen unterstützen. Servlets werden häufig in interaktiven Webanwendungen verwendet, in denen der Webserver als Antwort auf Benutzeranfragen dynamisch generierte Inhalte aus vorhandenen Business-Systemen zurückgibt.

Nähere Informationen zu Java Servlets finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Java Servlet.

Web

RMI-IIOP

Die über das Internet Inter-Orb Protocol ausgeführte Technologie des Remote Method Invocation (RMI-IIOP) erlaubt den Java-Komponenten die Kommunikation mit traditionellen CORBA-Komponenten, die in anderen Sprachen, z. B. C++ oder Smalltalk, geschrieben sind.

Nähere Informationen zu RMI-IIOP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products and APIs > RMI-IIOP.

  • Anwendungsclient
  • Web
  • EJB

J2EE Management 1.0

Die J2EE Management API stellt für die Management-Tools APIs zur Abfrage eines J2EE-Anwendungsserver bereit,
um dessen aktuellen Status, die implementierten Anwendungen usw. zu ermitteln.

Nähere Informationen zu RMI-IIOP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > J2EE Management Specification.

  • Anwendungsclient
  • Web
  • EJB

JMX 1.2

Die JMX API wird von der J2EE Management API verwendet, um einen Teil der erforderlichen Unterstützung für die Verwaltung eines J2EE-Produkts bereitzustellen.

Nähere Informationen zu RMI-IIOP finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2SE > Core Java > Java Management Extensions (JMX).

  • Anwendungsclient
  • Web
  • EJB

J2EE Deployment 1.1

Die J2EE Deployment API definiert die Schnittstellen zwischen der Laufzeitumgebung
eines Implementierungstools und Plug-in-Komponenten, die von einem J2EE-Anwendungsserver bereitgestellt werden.

Nähere Informationen zu J2EE Deployment finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > J2EE Deployment Specification.

JACC 1.0

Die Spezifikation JACC definiert einen Vertrag zwischen einem J2EE-Anwendungsserver und dem
Provider einer Berechtigungs-Policy.

Nähere Informationen zu JACC finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Products & Technologies > J2EE > Java Authorization Contract for Containers.

  • Anwendungsclient
  • Web
  • EJB

Assemblierung und Implementierung

J2EE-Anwendungen bestehen aus dem Anwendungsimplementierungsdeskriptor (application.xml) und einem oder mehreren J2EE-Modulen, die die Anwendung bilden. Die Module sind wiederverwendbare, portierbare Komponenten. J2EE-Anwendungen sind in .ear-Archive gepackt.

Implementierungsdeskriptoren

Implementierungsdeskriptoren sind XML-Dateien, die in J2EE-Anwendungen und J2EE-Modulen verwendet werden. Sie enthalten Konfigurationsdaten, die der J2EE-Server zum Zeitpunkt der Implementierung liest. Anhand dieser Konfigurationsdaten kann der Server die J2EE-Anwendung oder das J2EE-Modul deklarativ anpassen, ohne den Quellcode oder Klassen zu ändern.

Für jede J2EE-Anwendung oder jedes J2EE-Modul existiert ein generischer Implementierungsdeskriptortyp. Generische Implementierungsdeskriptoren wie die Datei ejb-jar.xml des EJB-Moduls definieren Angaben, die für die EJB gelten, unabhängig davon, auf welchem Server sie implementiert ist. Serverspezifische Implementierungsdeskriptoren definieren Angaben, die nur für einen bestimmten Server gelten. Serverspezifische Implementierungsdeskriptoren verwenden Namen, in denen der Server, für den Sie gelten, enthalten ist.

J2EE-Module

Ein J2EE-Modul besteht aus einem Implementierungsdeskriptor für das Modul und aus einer Reihe von Elementen, die das Modul bilden. Dazu gehört Folgendes:

  • Nicht-Java-Elemente, die auf dem Webserver implementiert werden ((JSP-Seiten, Bilddateien, statische HTML-Seiten), mit anderen Worten, Elemente des virtuellen Verzeichnisses.
  • Java-Elemente, die auf einem Webserver implementiert werden (Servlets, JavaBeans, Java-Klassen)
  • Elemente, die auf einem EJB-Server implementiert werden (EJBs und die unterstützenden Java-Klassen)

Es gibt drei Arten von J2EE-Modulen:

J2EE-Anwendungsclient

J2EE-Anwendungsclientmodule sind in .jar-Archive gepackt und enthalten Folgendes:

  • Implementierungsdeskriptor application-client.xml
  • .class-Dateien der Anwendungsclientimplementierung
Webkomponente

Webkomponentenmodule sind in .war-Archive gepackt und enthalten Folgendes:

  • Implementierungsdeskriptor web.xml und serverspezifische Implementierungsdeskriptoren
  • JSP-Seiten
  • HTML-Seiten
  • Bilder (z. B. .gif und .jpg)
  • Servlet-Klassendateien

Wenn das Modul ein Web-Service ist, enthält das .war-Archiv Folgendes:

  • Implementierungsdeskriptor webservices.xml
  • Servlet-Klassendateien
  • WSDL-Dateien
Enterprise JavaBean

Ein einzelnes Enterprise-JavaBean-JAR-Archiv kann eine Reihe von EJBs enthalten, ihre Implementierungsdaten sind aber in einem einzigen Satz von Implementierungsdeskriptoren gespeichert (ejb-jar.xml plus serverspezifische Implementierungsdeskriptoren).

Ein Enterprise-JavaBean-Standardmodul enthält Folgendes:

  • ejb-jar.xml und serverspezifische Implementierungsdeskriptoren
  • EJB-Implementierungsklassendateien

Ein Enterprise-JavaBean-Web-Servicemodul enthält Folgendes:

  • Die Implementierungsdeskriptoren webservices.xml
  • EJB-Implementierungsklassendateien

Nähere Informationen zum Packen und Implementieren von J2EE finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu Docs & Training > J2EE Platform, Enterprise Edition > Java Blueprints Program.

J2EE-Anwendungsentwicklung

Der Prozess der J2EE-Anwendungsentwicklung definiert mehrere Rollen und Phasen. Die folgenden Abschnitte erläutern die von der J2EE-Spezifikation bereitgestellten Entwicklungsrollen und die Entwicklungsphasen, in denen diese Rollen mitwirken.

Rollen der J2EE-Anwendungsentwicklung

Die Rollen der Anwendungsentwicklung sind in der folgenden Tabelle zusammengefasst.

Name der Rolle Beschreibung

Provider des J2EE-Produkts

Der Provider des J2EE-Produkts ist der Lieferant einer J2EE-Plattformimplementierung, auch J2EE-Produkt genannt. Provider von J2EE-Produkten sind BEA, IBM und Sun Microsystems. In der Regel nutzen diese Unternehmen ihre vorhandenen Stärken und liefern eine Implementierung der J2EE-Plattform. Beispielsweise baut die BEA-Implementierung auf dem sehr erfolgreichen Tuxedo-Transaktionsverarbeitungsmonitor auf. Der Provider eines J2EE-Produkts stellt auch die Tools bereit, die zur Unterstützung der Anwendungsimplementierung und -verwaltung erforderlich sind.

Provider der Anwendungskomponente

Der Provider der Anwendungskomponente umfasst tatsächlich eine Reihe von Rollen, wie EJB-Entwickler und HTML-Dokumentdesigner. Diese Rollen sind zuständig für das Erstellen der J2EE-Anwendungskomponenten mit Hilfe der dafür bereitgestellten Tools.

Anwendungsassembler

Der Anwendungsassembler erstellt mit Hilfe der dafür bereitgestellten Tools eine J2EE-Anwendung aus J2EE-Anwendungskomponenten. Die J2EE-Anwendung wird als EAR-Datei (Enterprise Archive) geliefert. Außerdem beschreibt der Anwendungsassembler alle externen Abhängigkeiten der J2EE-Anwendung. Der Implementierer löst diese Abhängigkeiten auf, wenn die J2EE-Anwendung tatsächlich implementiert wird.

Implementierer

Der Implementierer ist zuständig für die Implementierung einer J2EE-Anwendung und der Anwendungskomponenten, aus denen sie besteht, in der Betriebsumgebung. Die erste Phase der Implementierung umfasst die Installation der verschiedenen Anwendungskomponenten in den relevanten J2EE-Containern. Die zweite Phase der Implementierung beinhaltet die Konfiguration aller externen Abhängigkeiten, die deklariert wurden, damit diese aufgelöst werden können. Beispielsweise werden Sicherheitsrollen, die definiert wurden, den Benutzergruppen und Accounts in der Betriebsumgebung zugeordnet. Die dritte Phase der Implementierung umfasst die Ausführung der neuen Anwendung, so dass sie zum Empfang von Anforderungen bereit ist.

Systemadministrator

Der Systemadministrator ist zuständig für die Laufzeitinfrastruktur, wozu alle implementierten J2EE-Anwendungen gehören. Diese Rolle verwendet zur Ausführung dieser Aufgabe die geeigneten Tools, die vom Provider des J2EE-Produkts bereitgestellt werden.

Toolprovider

Der Toolprovider stellt Tools zur Entwicklung und zum Packen von Anwendungskomponenten bereit. Diese Tools entsprechen häufig den unterschiedlichen Typen von Anwendungskomponenten, die erzeugt werden, und umfassen IDEs, wie IBM VisualAge for Java und Borland JBuilder.

Provider der Systemkomponente

Der Provider der Systemkomponente stellt unterschiedliche Komponenten auf Systemebene bereit, wie z. B. Ressourcenadapter oder Provider von Berechtigungs-Policys.


Diese Rollen sind nicht exklusiv, und insbesondere in kleinen Entwicklerteams oder in einer Prototypsituation kann eine Einzelperson mehrere Rollen annehmen.

Phasen der J2EE-Anwendungsentwicklung

In diesem Abschnitt werden die verschiedenen Phasen der J2EE-Anwendungsentwicklung entsprechend der J2EE-Spezifikation beschrieben. Folgende Entwicklungsphasen existieren:

  • Entwicklung von Komponenten
  • Eine J2EE-Anwendung muss mindestens ein J2EE-Modul enthalten, daher ist mindestens eine Phase der Komponentenentwicklung erforderlich. Die letzten zwei Phasen sind immer erforderlich, weil alle J2EE-Anwendungen assembliert und implementiert werden müssen.

    In der folgenden Tabelle sind die Entwicklungsphasen für J2EE-Anwendungen zusammengefasst.

    J2EE-Entwicklungsphase Aufgaben Von folgender J2EE-Rolle ausgeführt Ergebnisse in

    Erstellung von J2EE-Anwendungsclients

    • Clientcode schreiben und Klassen kompilieren
    • Implementierungsdeskriptor application-client.xml erstellen
    • Ein JAR-Dateiarchiv erstellen, das die Klassendateien und XML-Dateien enthält.

    Provider der Anwendungskomponente (Softwareentwickler)

    Eine JAR-Datei, die den J2EE-Anwendungsclient enthält

    Erstellung von Webkomponenten

    • Servlet-Code schreiben und Klassen kompilieren
    • JSP- und HTML-Seiten schreiben
    • Den Implementierungsdeskriptor web.xml erstellen
    • Ein WAR-Dateiarchiv (Web Application Archive) mit den Klassendateien sowie den .jsp-, .html- und XML-Dateien erstellen

    Provider der Anwendungskomponente (Softwareentwickler: Servlets; Web-Designer: JSP-Seiten, HTML-Seiten)

    Eine WAR-Datei mit der Webkomponente

    Erstellung einer Enterprise JavaBean

    • EJB-Code schreiben und Klassen kompilieren
    • Den Implementierungsdeskriptor ejb-jar.xml und serverspezifische Implementierungsdeskriptoren erstellen
    • Ein JAR-Dateiarchiv mit den Klassen- und XML-Dateien erstellen

    Provider der Anwendungskomponente (Softwareentwickler)

    Eine JAR-Datei mit der Enterprise JavaBean

    J2EE-Anwendungsassemblierung

    • Den Deploymentdeskriptor application.xml erstellen
    • Ein EAR-Dateiarchiv mit den EJBs (JAR), Webkomponenten (WAR) und XML-Dateien erstellen

    Anwendungsassembler

    Eine EAR-Datei mit der J2EE-Anwendung

    J2EE-Anwendungsimplementierung

    • Die J2EE-Anwendung (EAR) zur J2EE-Serverumgebung hinzufügen
    • Den Implementierungsdeskriptor application.xml gemäß der Konfiguration der lokalen Umgebung editieren
    • Die J2EE-Anwendung im J2EE-Server implementieren

    Implementierer

    Eine installierte und konfigurierte J2EE-Anwendung


    Jede Phase des Entwicklungsprozesses produziert ein Ergebnis, das in der nächsten Phase verwendet wird. Die in den Phasen der Komponentenentwicklung erstellten Komponenten werden in der Phase der J2EE-Anwendungsassemblierung verwendet, um das EAR-Archiv der J2EE-Anwendung zu produzieren. In der Phase der J2EE-Anwendungsimplementierung wird das EAR-Archiv im J2EE-Server implementiert.

    Die Ergebnisse jeder Phase sind portierbar und müssen nicht von denselben Personen und nicht einmal in derselben Umgebung ausgeführt werden, sofern die gewählte Umgebung die Anforderungen für eine J2EE-Plattform erfüllt.

    Nähere Informationen zum Packen und Implementieren von J2EE finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu J2EE > Blueprints.

    Weitere Informationen

    Weitere Informationen zu J2EE finden Sie in den J2EE-Entwürfen (Blueprints) von Sun. Sie finden Sie auf der Website http://java.sun.com/. Folgen Sie den Links zu J2EE > Blueprints > Guidelines: Designing Enterprise Applications with the J2EE Platform, Second Edition.

    Eine Kopie dieses Dokuments ist außerdem in Rational Unified Process enthalten.

    Die Kapitel der Sun-J2EE-Entwürfe mit Informationen zu speziellen Themen sind in der folgenden Tabelle zusammengefasst.

    J2EE-Konzept Kapitel in den J2EE-Entwürfen (Blueprints)

    Technologien der J2EE-Plattform

    Kapitel 2

    Enterprise JavaBeans

    Kapitel 5

    Transaktionen

    Kapitel 8

    Sicherheit

    Kapitel 9

    Servlets

    Kapitel 4

    JavaServer Pages

    Kapitel 4

    Implementieren und Packen

    Kapitel 7