Menu

Seite41E

Anonymous

4.3 Literatur

Erstellung der Server-seitigen Anwendung

Auf Grundlage des The Java EE 5 Tutorials und dem dazugehörigen Beispielanwendungen insbesondere Duke's Bank, soll die Umstellung vom bereits bekannten J2EE 1.4 auf Java EE 5 erfolgen. Die Beschreibung der Unterschiede zwischen den beiden findet sich hier.

Zur Vertiefung in EJB 3.0 bieten sich die Spezifikationen selbst an, aber auch das EJB Glossar sowie die nach Themen sortierte Linkliste auf EnterpriseJavaBeans.eu. Es stehen einige Beispielkapitel des Buches "EJB 3 für Umsteiger" im Netz.

Speziell für die Umsetzung der Java Persistence API aus der EJB 3.0 Spezifikation existieren eine Reihe von Artikeln. Auf Java Persistence API FAQ werden grundlegende Fragen zur JPA geklärt. Bei Bea werden die existierenden Persistenz-Mechanismen verglichen. In Migrating JDBC Data Access Objects to use EJB3 wird gezeigt, wie DAOs, die bisher direkt mit JDBC auf der Datenbank operiert haben, durch solche ersetzt werden, die die JPA verwenden. Schluchert hat seine EJB 3 and Java Persistence API Tutorials frei verfügbar ins Netz gestellt. Bei OnJava erschien Standardizing Java Persistence with the EJB3 Java Persistence API und A standardized object-relational mapping mechanism for the Java platform auf JavaWorld bietet ebenfalls eine Einführung in JPA.

Da in der Beispiel-Zielanwendung der JBoss AS als Anwendungsserver mit EJB 3.0 Container und in ihm Hibernate als Umsetzung der JPA verwendet werden, finden sich auf diese Index-Seite die notwendigen Anleitungen. Mit JBoss TrailBlazer wird Schritt für Schritt eine EJB-3.0-Beispiel-Anwendung mit JBoss erstellt.

Laliluna veranschaulicht mit seinem First EJB 3 Tutorial die Erstellung einer EJB-3.0-Anwendung mit ANT und JBoss. Der DevX-Artikel Banish Your Resistance to Persistence with the EJB 3.0 Persistence API verwendet JBoss und Maven. CaveatEmptor ist ein Beispiel für eine Online-Auktions-Anwendung, die mit EJB3.0/JPA realisiert wurde. Die Aeonstore Java Persistence Application demonstriert ebenfalls die Anwendung von JPA mittels Hibernate (Hibernate 3.2 Configurations).

Erstellung der Client-seitigen Anwendung

Wie in Difference between a stand-alone Java client and an Application Client component beschrieben, gibt es die Möglichkeit, den Client mit oder ohne Application Client Container (ACC) zu implementieren. Der Vorteil des ACC besteht darin, dass dadruch im Client selbst auf die explizite Ausformulierung des Aufrufs des JNDI Namensdienstes verzichtet werden könnte. Der ACC muss dazu aber vom jeweiligen Anwendungsserver implementiert werden, der in Form von Bibliotheken dann vom Client eingebunden wird. Der Sun Application Server und Glassfish sind Anwendungsserver, die den ACC unterstützen. JBoss bietet dafür den JBoss Client.

Falls wir den Client als Stand-Alone implementieren wollen, müssen die EJBs über den Namensdienst explizit eingebunden werden. Mit der Kombination von ServiceDelegate und ServiceLocator kann dieser Vorgang gekapselt werden. Die Client-Anwendung muss nun nur noch das ServiceDelegate kennen. Das ServiceDelegate selbst stellt dem Client die benötigten Geschäftsmethoden zur Verfügung. In der Methodenimplementierung wird im Delegate der als Singleton implementierte ServiceLocator referenziert und das benötigte Session-Bean bezogen.

Dazu wird im ServiceLocator das im Namensdienst registrierte Bean geholt. Warum das Service-Locator-Pattern auch mit EJB 3.0 weiterhin bevorzugt werden sollte, erklärt der Artikel ServiceLocator Pattern: Does EJB 3 Really Kill It Off?.

Erstellen der Generator-Anwendung

Erstellen und Konfigurieren der Projekte

Es werden drei Plugin-Projekte benötigt: rad.domain, rad.generator und rad.platform. Wenn sie in Eclipse angelegt wurden, können
über die MANIFEST.MF im Ordner META-INF unter dem Reiter "Dependencies" benötigte Plugins angegeben werden. Neben den openArchitectureWare-Plugins können auch Referenzen auf die anderen von uns angelegten Plugin-Projekte hier gesetzt werden. Damit die Bibliotheken der abhängigen Plugins in den Classpath des Projekts geholt werden, muss über das Kontextmenü des Projektordners

PDE Tools > Update Classpath...

aufgerufen werden. Die Bibliotheken sind nun unter dem Unterordner "Plug-in Dependencies im Projekt gruppiert. Projekten, die openArchitectureWare verwenden sollen, kann ebenfalls über das Kontextmenü des Projektordners mit

openArchitectureWare > add openArchitectureWare Nature

die Unterstützung von openArchitectureWare gesetzt werden, d.h. dass die speziellen Dateiformate und Sprachen von oAW interpretiert werden (Syntax-Hervorhebung, Parser u.ä.)

Die Manifest-Dateien der Projekte

MANIFEST.MF des rad.domain-Projektes

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Domain Plug-in
Bundle-SymbolicName: rad.domain
Bundle-Version: 1.0.0
Bundle-Localization: plugin
Eclipse-LazyStart: true
Require-Bundle: rad.generator,
rad.platform
org.openarchitectureware.base,
org.openarchitectureware.core.workflow,
org.openarchitectureware.workflow,
org.openarchitectureware.workflow.editor

MANIFEST.MF des rad.generator-Projektes

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Generator Plug-in
Bundle-SymbolicName: rad.generator
Bundle-Version: 1.0.0
Bundle-Localization: plugin
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
com.ibm.etools.emf.event,
org.openarchitectureware.base,
org.openarchitectureware.check.editor,
org.openarchitectureware.core.check,
org.openarchitectureware.core.emftools,
org.openarchitectureware.core.expressions,
org.openarchitectureware.core.feature.source,
org.openarchitectureware.core.libraries,
org.openarchitectureware.core.workflow,
org.openarchitectureware.core.xpand2,
org.openarchitectureware.emftools,
org.openarchitectureware.plugins.feature.source,
org.openarchitectureware.recipe,
org.openarchitectureware.recipe.core,
org.openarchitectureware.recipe.eclipseChecks,
org.openarchitectureware.recipe.feature.source,
org.openarchitectureware.recipe.simpleChecks,
org.openarchitectureware.recipe.workflow,
org.openarchitectureware.util.stdlib,
org.openarchitectureware.util.stdlib.feature.source,
org.openarchitectureware.workflow,
org.openarchitectureware.workflow.editor,
org.openarchitectureware.xpand2.editor,
org.openarchitectureware.xtend.editor,
org.openarchitectureware.xtext.core,
org.openarchitectureware.xtext.editor,
org.openarchitectureware.xtext.editor.base,
org.openarchitectureware.xtext.ui
Eclipse-LazyStart: true

weiter zu 4.4 Erweiterungs- und Verbesserungsmöglichkeiten
zurück zu 4.2.7 Erstellen des Generatorgesamtpakets
zurück zu 4.2 Implementierung des Generators
zurück zu 4 Implementierung
zurück zu [FrontPage]


Related

Documentation: FrontPage
Documentation: Seite000
Documentation: Seite400
Documentation: Seite41D
Documentation: Seite420
Documentation: Seite440