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.
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:
-
Sie möchten ein standardisiertes, von der Branche getestetes
Framework, das Transaktionsmanagement, Benennung, Sicherheit, ferne Konnektivität und Datenbankzugriff
unterstützt.
-
Portierbarkeit ist erforderlich, d. h., es muss möglich sein, Ihre Komponenten auf einem
beliebigen J2EE-kompatiblen Server zu implementieren.
-
Sie möchten Ihre Komponenten wiederverwenden oder vorgefertigte Komponenten
verwenden, die Sie erworben haben.
-
Sie möchten die Erfahrungen Ihres Entwicklers bezüglich der Architektur auf der J2EE-Plattform nutzen, und bewährte und echte Architektur- und Designmuster
verwenden.
-
Ihr System muss skalierbar sein, um wachsende Arbeitslasten zu bewältigen.
-
Sie möchten die Entwicklungszeit verringern, indem Sie leistungsfähige Entwicklungs- und Implementierungstools der J2EE-Plattform verwenden.
-
Sie möchte eine einfache Integration mit Back-end-Systemen erreichen.
-
Sie möchten einfache, leistungsfähige Sicherheitsfunktionen nutzen.
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)
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.
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).
|
|
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.
|
|
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).
|
|
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.
|
|
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
|
|
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).
|
|
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).
|
|
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.
|
|
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.
|
|
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.
|
|
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).
|
|
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".
|
|
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".
|
|
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.
|
|
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.
|
|
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).
|
|
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.
|
|
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
|
|