Enterprise Java Beans 19.11.2002

Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Fachhochschule München, Fachbereich Informatik
Software-Engineering II WS 2002 / 2003
bei
Prof. Dr. Streng
Seminararbeit Gruppe SEII03
Komponentenmodelle: Enterprise Java Beans
19.11.2002
Alexander Kubicki (Verfasser) 09 42 62 98 0111
07 IF 8W
Mischa Gwinner
09 74 49 98 0111
07 IF 8W
Ranko Krvavac
09 53 43 97 0133
07 IF 6WP
Gruppe SEII03
1
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Inhaltsverzeichnis
1.
Einleitung
4
2.
Überblick Komponentenmodelle
4
2.1
DCE
4
2.2
COM / DCOM
4
2.3
CORBA
5
2.4
RMI
5
2.5
JavaBeans
6
2.6
Enterprise Java Beans
6
2.7
Web-Services
7
3.
J2EE-Applikationen und Enterprise Java Beans
7
3.1
3.1.1
3.1.2
3.1.3
J2EE-Architektur und EJB-Server
Schichten-Architektur
J2EE-Server
EJB-Container
7
8
10
12
3.2
Aufgabenverteilung und Entwicklerrollen
13
3.3
J2EE-Spezifikationen und API
14
3.4
Bestandteile eines EJB
20
3.5
3.5.1
EJB-Arten
Session Beans
23
24
3.5.1.1 Stateless Session Beans
25
3.5.1.2 Stateful Session Beans
3.5.2 Entity Beans
3.5.3 Message-Driven Beans
26
28
31
3.6
Deployment
32
3.7
Benutzung von EJB
33
3.8
Dateiformate
34
4
Beispiel
35
4.1
Entwicklungsschritte
35
4.2
4.2.1
4.2.2
4.2.3
EJB-Klassen erstellen und kompilieren
Die EJB-Klasse
Das Remote-Interface
Das Home-Interface
36
37
38
38
Gruppe SEII03
2
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Web-Client erstellen
39
4.4
Konfigurationsdateien erstellen
41
4.5
Verzeichnisstruktur erstellen
44
4.6
Archiv-Dateien erstellen
45
4.7
Anwendung auf Applikations-Server installieren und starten
46
5
Ausblick
47
6
Fragen und Antworten
49
7
Quellenverzeichnis
51
Gruppe SEII03
3
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
1. Einleitung
Auf dem Weg zu unternehmensweiten Anwendungen wurden bei der
Entwicklung von Softwarekomponenten-Modellen und deren AustauschMethoden verschiedene Techniken entwickelt.
Zunächst eine kurze Übersicht über einige Komponentenmodelle und
deren Entwicklung. Sie reicht von einheitlichen Schnittstellendefinitionen
bis zu modularen, web-basierten Software-Komponenten.
Dabei leistet die Java 2 Enterprise Edition (J2EE) einen wichtigen Beitrag,
um auf Java-Basis die eigentliche Geschäftslogik sowohl von
Systemdiensten als auch von der Benutzerschnittstelle abzukoppeln.
Es wird ihre Architektur und Spezifikation beschrieben. Das hierbei
verwendete Komponentenmodell der Enterprise Java Beans wird in
seinen Bestandteilen, den Bean-Arten, seine Entwicklung und Benutzung
erläutert.
In einem Beispiel wird eine Applikation mit Enterprise Java Beans
vorgestellt.
2. Überblick Komponentenmodelle
In der Entwicklung von Komponentenmodellen wurden und werden
Konzepte teilweise übernommen.
2.1
DCE
Eine wichtige Entwicklung war Distributed Computing Environment (DCE).
Diese einheitliche Schnittstellendefinition sollte auf allen Plattformen, vom
Desktop PC bis hin zum Großrechner, verwendbar sein. DCE hatte keinen
großen Erfolg, nicht zuletzt wegen des umfangreichen API mit 600
Funktionen.
2.2
COM / DCOM
DCE wurde von Microsoft zum Component Object Model (COM)
weiterentwickelt. Es ist für lokale Funktionsaufrufe, Interprozess- und
Netzwerkkommunikation zuständig. Seit Windows NT 4.0 kann mittels
DCOM (Distributed-COM) Datenaustausch zwischen verteilten Objekten
Gruppe SEII03
4
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
erfolgen. Zunächst nur für Microsoft-Betriebssysteme entwickelt, existiert
COM heute auch auf Apple und einigen UNIX-Derivaten.
Ein Beispiel für COM-Objekte ist Active-X. Die (theoretische)
Plattformunabhängigkeit ist nur gegeben, solange kein spezielles API
verwendet wird. Auch werden bei API-Nutzung (z.B. WIN32-API) fast
keine Sicherheitsmechanismen verwendet.
2.3
CORBA
Die Object Management Architecture (OMA) wurde von der Object
Management Group (OMG) entwickelt. Das Kernstück stellt der sog.
Object Request Broker (ORB) dar. Es handelt sich dabei um eine Art
Vermittlungszentrale zwischen den Objekten. Der ORB nimmt Anfragen
entgegen, lokalisiert das entsprechende Objekt, übermittelt anschliessend
die Anfrage und dann das Ergebnis der Operation. Der ORB wurde als
Common Object Request Broker Architecture (CORBA) standardisiert und
ermöglicht folglich die Kommunikation zwischen Systemen verschiedener
Hersteller auf heterogenen Plattformen mit unterschiedlichen
Programmiersprachen. Unterschiedlichste Applikationen können so als
CORBA-Services verpackt werden und mit neuen Systemen
zusammenarbeiten.
Der entscheidende Nachteil des CORBA-Standards ist die Beschränkung
auf die gemeinsamen Eigenschaften dieser Sprachen.
Für Java bedeutet dies, dass viele Features wie die verteilte Garbage
Collection, oder die Sicherheit der Java Virtual Machine keine
Entsprechung finden. Auch die Portierbarkeit von verteilten Anwendungen
kann z.B. durch maschinennahe Sprachen wesentlich erschwert werden.
Ferner ist CORBA sehr komplex, kann nicht über Firewalls hinweg
arbeiten, ORBs unterschiedlicher Hersteller sind zueinander inkompatibel
und CORBA wird nicht von Microsoft unterstützt.
2.4
RMI
Mittels Remote Method Invocation (RMI) und einer Java
Entwicklungsumgebung können objektorientierte Programme erstellt
werden, deren Objekte auf unterschiedlichen Rechnern in einem verteilten
Netzwerk miteinander interagieren können.
RMI ist einfacher zu implementieren als CORBA und leichter verfügbar
(SDK von SUN). Es ist allerdings auf Java beschränkt und nicht so
leistungsfähig wie CORBA oder DCOM.
Gruppe SEII03
5
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
2.5
JavaBeans
Ab Java Version 1.1 ist mit dem Bean-API ein Komponentenmodell von
SUN verfügbar. Es lassen sich kleine bis mittlere Komponenten
unterschiedlichen Größe und Komplexität (Granularität) entwickeln.
Die wichtige Plattformunabhängigkeit ist aber nicht mehr gegeben, wenn
Beans in plattformspezifische Komponentenmodelle integriert werden.
Die Integration geschieht mit Hilfe einer „Bridge“, so dass z.B. Aufrufe
zwischen JavaBeans und ActiveX/COM möglich sind
Zugriffe erfolgen über öffentliche Methoden (Get-/Set-Methoden) und
können somit genau festgelegt werden. Eine BeanInfo-Klasse beinhaltet
alle Informationen über Properties, Methoden und Events einer Bean.
Eine Instanz der Klasse java.beans.Introspector sucht zu einer Bean die
korrespondierende BeanInfo-Klasse. Ist diese nicht vorhanden, so nutzt
der Introspector das Java-Reflection-API und die Designpatterns der
Namensgebung von Methoden und Events der JavaBeans-Spezifikation,
um die benötigte Information zu generieren.
Kann eine BeanInfo-Klasse gefunden werden, so werden nur die
fehlenden Deskriptoren ergänzt. Das Ergebnis der Introspection ist eine
BeanInfo-Klasse, die nun teilweise benutzerdefinierte und durch den
Introspector generierte Informationen enthält. Kann keine BeanInfo-Klasse
gefunden werden, generiert der Introspector alle Informationen und liefert
sie in einem BeanInfo-Objekt zurück.
2.6
Enterprise Java Beans
Enterprise Java Beans (EJB) haben zwar einen Teil ihres Namens mit
JavaBeans gemein, es handelt sich hierbei jedoch um zwei eigenständige
Komponentenmodelle der Firma Sun Microsystems. Es kann aber z.B.
auch hier das mächtige Java-Reflection-API verwendet werden. EJB sind
innerhelb einer eigenen Spezifikation, der Java 2 Enterprise Edition
(J2EE), definiert. Zusätzlich sind weitere APIs enthalten, die den
Datenaustausch vereinfachen.
Die EJB Komponenten-Technologie ist gegenüber JavaBeans komplexer,
da sie eine mehrschichtige Server-Struktur erfordert, wobei EJB auf
beliebig vielen sog. Applikations-Servern laufen können.
Auch ist sie kompatibel zu CORBA und kann mit verschiedenen
Plattformen und Programmiersprachen zusammenarbeiten.
Im Folgenden werden Enterprise Java Beans, deren Laufzeit-Umgebung
und die nötigen Entwicklungswerkzeuge vorgestellt.
Gruppe SEII03
6
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
2.7
Web-Services
Web-Services sind modulare, internet-basierte Software-Komponenten.
Sie werden durch den Anbieter im WWW zur Verfügung gestellt und durch
die Applikation des Nutzers online verwendet.
Sun-One und Microsoft .Net sind zwei unterschiediche Ansätze hierzu.
Nach der aktuellen J2EE-Spezifikation können Enterprise Java Beans zu
Web-Services erweitert werden.
3. J2EE-Applikationen und Enterprise Java Beans
Für Enterprise Java Beans muss die Java Erweiterung J2EE verwendet
werden: Zusätzlich zum normalen Java-SDK wird von SUN das JavaSDKEE in der gleichen Version benötigt (beides kostenfrei). Es umfasst
die nötigen APIs, ein grafisches Tool zu EJB-Erstellung, sowie einen
Applicationserver (Referenzserver von SUN Microsystems).
Von den APIs sind entsprechend den EJB-Funktionalitäten nur einige
essentiell wichtig. Als Alternative zum beigefügten grafischen Tool (Java
deploytool) können auch bekannte Java-Entwicklungswerkzeuge in den
jeweiligen Enterprise-Versionen (Forte for Java EE, Jbuilder EE,
Together J) genutzt werden. Der Referenzserver kann ebenfalls durch
modernere und performantere Application-Server ersetzt werden (z.B.
Jboss, Silverstream, Bea WebLogic, IBM Websphere, iPlanet), wobei die
mitgelieferte Datenbank ebenfalls ausgetauscht werden kann (z.B. Oracle,
SQL Server, PostgreSQL, MySQL, Instant-DB)
3.1
J2EE-Architektur und EJB-Server
Man kann die Funktionsweise von EJB gut mit Applets und Servlets
vergleichen, die beide kein unabhängiges, eigenständiges Programm sind,
sondern eine geeignete Laufzeitumgebung zum Ablaufen benötigen. Beim
Applet ist diese Laufzeitumgebung der Webbrowser und beim Servlet die
sog. Servlet Engine des Webservers (z.B. Tomcat für Apache-Webserver).
Bei EJB übernimmt diese Funktionalität der Container des ApplikationsServers. Ein Container kann mehrere EJBs enthalten.
Der Unterschied zwischen Applets / Servlets und EJB liegt auf der
Anwendungsseite. Applets liefern ihre Ergebnisse direkt an ein GUI auf
dem Client. Demgegenüber bearbeiten EJB komplexe Berechnungen oder
Transaktionen auf einem Server und stellen diese Ergebnisse anderen
Komponenten oder Applikationen zur Verfügung.
Gruppe SEII03
7
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Das Ziel von EJB ist es, die Entwicklung von verteilten,
komponentenbasierten, serverseitigen Java-Applikationen zu vereinfachen
und Aufgaben wie Sicherheits-und Transaktions- oder
Verteilungsverwaltung von den Komponentenentwicklern fernzuhalten.
Enterprise Java Beans sind für eine moderne Mehr-Schichten-Architektur
ausgelegt.
3.1.1 Schichten-Architektur
Die ersten Client/Server Systeme bestanden aus zwei Schichten (TwoTiers-Architecture), dem User Interface auf dem Client und der Datenbank
auf dem Server. Solche Systeme sind derzeit noch üblich. Zwei-SchichtenArchitekturen führen den größten Teil der Business Logic auf dem Client
aus, der anschließend mittels SQL-Statements den Server aktualisiert.
Client
Server
Frontend und
Datenbank
Businesslogik
Abb.1: Zwei-Schichten-Architektur
Die Three-Tiers-Architektur wird durch eine schlanke Klientensicht in der
Präsentationsschicht charakterisiert. Die Anwendungslogik (Business
Logic) mit den eigentlichen Applikationen wird in der zweiten Schicht auf
dem Application-Server (Middleware) ausgeführt und nutzt die
Datenbanken der Datenschicht.
Hierbei benutzen Client und Server typischerweise ein Protokoll, daß die
Konversation auf der Ebene von Geschäftsvorfallstransaktionen anstatt
von Tabellen und Reihen repräsentiert.
Gruppe SEII03
8
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Dieses Konstrukt bietet in vielerlei Hinsicht Vorteile. Die Entwicklungs-,
Wartungs- und Erweiterungskosten sind niedriger, da die komplette
Geschäftslogik zentral platziert ist und so nicht auf jedem Clientrechner
Änderungen durchgeführt werden müssen. Die Kommunikation zwischen
Client und Datenbank geschieht nicht mehr direkt. Dies bringt Vorteile
bezüglich Lizenzen, Netzwerkauslastung und einer eventuellen
Umstellung der Datenbank. Des weiteren ist z.B. die Möglichkeit einer
Absicherung der Präsentationsschicht durch eine Firewall positiv zu
beurteilen, da somit eine leichte Webintegration realisierbar ist. Die
dahinterstehenden Geschäftsprozesse sind davon nicht betroffen.
Zusammenfassend kann man sagen, dass durch diese Architektur Vorteile
bezüglich Skalierbarkeit, Performanz, Lastverteilung, Verfügbarkeit,
Flexibilität und nicht zuletzt Softwarewiederverwendung gegeben sind.
Client
Application-Server
Frontend
Businesslogik
Datenbank-Server
Datenbank
Abb.2: Three-Tiers-Architecture
n-Tiers-Architectures sind Verallgemeinerungen von Three TierArchitectures. Jede Ebene der Software sorgt für einen anderen Level an
Services zu den Ebenen darunter und daneben. In n-Tier-Architectures
wird das Netzwerk vielmehr als ein Pool von verteilten Services betrachtet,
als einfach der Zugriff eines Client auf einen einzelnen Server.
Client
Service 1
Frontend
Service n
Datenbank-Server
Datenbank
Abb.3 n-Tiers-Architecture
Gruppe SEII03
9
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Im Folgenden wird von einer Three-Tiers-Architecture ausgegangen.
Abb.4 Drei-Schichtenmodell
3.1.2 J2EE-Server
Als Clients können Web-Browser oder Standalone-Applikationen
verwendet werden.
Standalone-Applikationen benutzen einen eigenen Client oder sind ein
Applet in einer Spezialanwendung (z.B. Mobiltelefone). Sie bieten den
Vorteil direkt auf die Datenbank-Ebene zugreifen zu können.
Web-Browser sind auf allen heute gängigen Betriebssystemen bereits
vorhanden und bedürfen im Gegensatz zu Standalone-Applikationen
keiner speziellen Administration. Auch betreffen Änderungen des Frontend
nur den (hierbei benötigten) Webserver alleine, was gerade bei einer
großen Client-Anzahl eine sehr effiziente System-Wartung ermöglicht.
Im Folgenden wird von einem web-basierten Frontend ausgegangen:
Dazu ist neben dem EJB-Server mit seinen EJB-Containern auch ein
Webserver erforderlich. Dieser muß dabei auch dynamische WebseitenInhalte erzeugen können.
Nach Definition im J2EE-Standard ist dies mittels der server-seitigen
Techniken „Java Servlet“ oder „Java Server Pages“ (JSP) möglich. Hierzu
ist wiederum einer Erweiterung des Web-Servers um eine Servlet-Engine
nötig. Beispielsweise ist Jacarta-Tomcat eine Servlet-Engine zum ApacheWebserver.
Gruppe SEII03
10
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
J2EE-Server
WEB-Container
WEB-Browser
JSP
Servlet
Standalone
Client
EJB-Container
Enterprise
Data
EJB
Client Tier
(Client)
Middle Tier
(Application-Server)
Enterprise information System Tier
(Datenbank-Server)
Abb.5 Beziehungen im Drei-Schichtenmodell
Der Vorteil von Java Server Pages ist, das sie automatisch nach Ihrer
Erstellung von der Servlet-Engine des Webservers in (aktualisierte)
Servlets umgewandelt werden. Diese können bei Anfrage durch den Client
sofort auf dem Webserver ausgeführt werden. Der Nachteil von Java
Server Pages ist die Vermischung von HTML- und Java-Code, JSP-Tags
und anderen Informationen wie z.B. Java Script.
Dies wird bei der Verwendung von Servlets verhindert, da sie reine JavaKlassen sind. Web-Ausgaben werden dynamisch mittels system.out.println
erzeugt. Dann kann es aber auch nötig sein, zum Servlet geeignete
statische Webseiten bereitzustellen.
Gruppe SEII03
11
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
3.1.3 EJB-Container
Der EJB-Container übernimmt die Steuerung der Datenkommunikation
und entlastet somit den EJB-Entwckler erheblich.
Der entfernte Client greift über die Java-eigene Remote-MethodInvocation (RMI) und das Java Remote-MethodProtokoll (JRMP) auf den
Server zu. Einige Applikationsserver unterstützen optional das Internet
Inter-ORB Protokoll aus CORBA.
Der EJB-Server stellt für jede EJB-Komponente einen EJB-Container zur
Verfügung. Der Client kommuniziert nicht mit der Komponente selbst
sondern mit dem Container. Dies hat den großen Vorteil, dass sich der
Komponententwickler nur mit seinem Anwendungsfall, also der
Geschäftslogik auseinandersetzten muss, und die konkrete
Implementierung der Schnittstelle dem Container überlassen kann. Diese
Schnittstelle ist in der EJB-Spezifiktaion klar definiert (Component
Contract).
Die Bereitstellung einer Laufzeitumgebung („Container“) für EJB ist die
wichtigste Aufgabe des Application-Servers. Darüberhinaus werden
Dienste, wie z.B. die Life-Cycle-Management, Netzwerkverbindungen,
Sicherheit, Datenbankzugriff, Prozess- und Threadverwaltung, und
Persistenz zur Verfügung gestellt. Durch diese Architektur kann sich der
Entwickler vollständig auf die eigentlich Logik der Applikation
konzentrieren.
EJB-Server
EJB-Container
Client
EJB-Komponente
Component Contract
Abb.5 Architektur einer EJB-Anwendung
Gruppe SEII03
12
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
3.2
Aufgabenverteilung und Entwicklerrollen
Aufgrund der J2EE-Architektur (siehe 3.3) ist es möglich, dass die
verschiedenen Komponenten (Enterprise Bean, Container, ...) unabhängig
voneinander entwickelt werden können:
•
Der Enterprise Bean-Provider erstellt sowohl die Enterprise
Java Beans als nötige Web-Komponenten (JSPs, Servlets).
EJBs beinhelten die Geschäftslogik und benutzen dazu die
Container-Dienste des Application-Servers (Verteilung,
Transaktionssteuerung, Persistenz, Sicherheit). EJBs können in
Eigenentwicklung entstehen oder zugekauft werden.
•
Der Application Assembler setzt aus den einzelnen SoftwareKomponenten, den EJBs, die gewünschte Applikation
zusammen. Dabei sind nur Problemstellung und EJBSchnittstellen relevant (nicht die EJB-Implementierung). Neben
Anpassungen kann aber auch die Erstellung von speziellen
EJBs nötig werden. Außerdem erstellt oder modifiziert er den
Deployment-Descriptor der Applikation (in XML).
•
Der EJB Container / Server Provider stellt den
Applikationsserver, also die Laufzeitumgebung mit Low-LevelSystemdiensten für die Enterprise Java Beans, zur Verfügung
(z.B. JBoss). Im Moment wird der passende Container für den
Server gleich mitgeliefert.
•
Der Deployer richtet die Applikation auf dem Zielsystem ein. Er
gibt dem Applikationsserver die erstellten SoftwareKomponenten bekannt, d.h. er legt sie in einem bestimmten
Verzeichnis des Servers ab. Zusätzlich werden gegenüber der
Testumgebung veränderte Hardware, Transaktionen und
Sicherheit (Firewall,...) angepasst.
•
Der System Administrator ist für die Anwendung nach der
Implementierung verantwortlich. Er muss sich also um die
täglichen durch mitgelieferte Management Tools kümmern.
Gruppe SEII03
13
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
.
Abb.6 Entwicklerrollen
Für alle Aufgaben stellt der Tool Provider die J2EE-Entwicklungsumgebung und deren Tools bereit (z.B. Sun Forte for Java EE als IDE,
Jakarta ANT für Deployment-Descriptoren).
3.3
J2EE-Spezifikationen und API
Die „Java 2 Platform Standard Edition“ (J2SE) wird durch die „Java 2
Platform Enterprise Edition“ (J2EE) erweitert. Sie besteht aus mehreren
APIs, zu denen auch die Enterprise Java Beans gehören. Die momentan
aktuellste J2EE-Spezifikation (v1.4) ist der „Proposed Final Draft 2 / Public
Draft“ vom 08.11.2002. Eine J2EE-Patform besteht aus folgenden API:
Enterprise Java Beans 2.1(EJB):
EJBs ist ein server-seitiges Komponentenmodell, das Portabilität über
verschiedene Applikationsserver hinweg bietet. Dieses Framework stellt
verschiedene Dienste für Appliakationskomponenten zur Verfügung. Es
gibt drei EJB-Arten: Session-, Entity- und Message-Driven Beans. Bei
Datenbankoperationen mittels eines Entity-Beans ist kein SQL-Code oder
die Benutzung des JDBC-API notwendig (aber möglich), da der Container
des Application-Server dies übernimmt .
Als Neuerung gegenüber der Version 2.0 wurde Unterstützung für
Webservices eingefügt: Stateless Session Beans (siehe 3.5.1.1) und
Message-Driven Beans (siehe 3.5.3) können als SOAP 1.1-basierte
Webservices veröffentlicht werden. Mittels SOAP 1.1 können Methoden
Gruppe SEII03
14
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
eines Stateless Session Bean durch fremde Web-Service Plattformen wie
Microsoft .net, Apache Axis, Perl verwendet werden.
Java Naming and Directory Interface (JNDI):
JNDI bietet Zugang zu Namens- und Verzeichnisdiensten (z.B. NDS oder
LDAP), um entfernte Objekte zu lokalisieren und zu verwenden.
Remote Method Invocation (RMI-IIOP):
Mit RMI können Java-Funktionsaufrufe über Rechnergrenzen hinweg
erfolgen.
Virtuelle Kommunikation
Client
Remote-Objekt
Interface
Interface
Rumpf (stub)
Gerüst (skeleton)
Remote Reference Layer
Netzwerkverbindung
Abb.7 Remote Method Invocation
Java Interface Definition Language (JIDL):
Mit JIDL können entfernte Funktionsaufrufe über CORBA und IIOP
(Internet-Inter-ORB-Protocol) erfolgen.
Java Database Connectivity 3.0(JDBC):
JDBC ermöglicht den Zugang zu relationale Datenbanken mittels SQL: In
einem Entity-Bean können die vom Container vorgegebenen
Datenbanfunktionen überladen werden. Oder ein Session-Bean muss auf
die Datenbank zugreifen. Auf Seite des Clients kann ein JSP oder Servlet
die Datenbank auch ohne Umweg über das EJB benutzen. Das JDBC-API
besteht aus zwei Teilen: Ab Version 2.0 ist JDBC in die Pakete java.sql
(für JDBC-konforme Treiber) und javax.sql (JDBC für J2EE) aufgeteilt.
Es gibt 4 Typen von JDBC-Treibern:
Gruppe SEII03
15
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Typ1: Der Treiber verwendet eine native Bibliothek mit einem allgemeinen
Interface (nicht datenbankspezifisch). Beispiel ist die JDBC-ODBCBrücke im Java-SDK.
Typ2: Der Treiber greift über eine native Bibliothek auf einen
datenbankspezifischen Treiber zu (schneller als Typ1).
Typ3: Der Treiber selbst ist reines Java und kommuniziert über ein
datenbankunabhängiges Protokoll mit einem Datenbankportal.
Beispiel sind Java-Applets, wegen deren Sicherheitsrestriktionen.
Typ4: Der Treiber selbst ist reines Java, kommuniziert direkt mit der
Datenbank und ist datenbankabhängig (Leistungsstärker Typ 2 und
fast genauso schnell).
Java Servlet 2.4:
Hierdurch können http-spezifische Klassen erstellt werden, wobei die
Logik nach Anfrage durch den Client auf dem (Web-)Server abläuft.
Java Server Pages 2.0 (JSP):
Eine Java Server Page ist ein textbasiertes Dokument mit statischen
(HTML,WML,XML) und dynamischen(JAVA-Code, JSP-Tags) Elementen.
Java Message Service 1.1 (JMS):
J2EE-Komponenten können besonders bei verteilten Systemen
Nachrichten senden, empfangen und lesen (z.B. Asynchrone
Kommunikation mit Queuing).
Java Transaction API 1.0 (JTA) :
JTA stellt Transaktionssicherheit für Datenbankzugriffe her (z.B. commit,
rollback). Verteilte Transaktionen auf der Basis des OTS (Object
Transaction Service) von CORBA können durchgeührte werden.
Java Mail 1.3 :
Durch Java Mail können J2EE-Komponenten Email aus ihrer Applikation
heraus senden. Das JavaMail-API besteht aus zwei Teilen: Die
Anwendung benutzt das Application-Level-Interface, um Email zu
versenden. Daneben existiert das Service-Provider-Interface. Für Java
und Java-Enterprise Applikationen existieren wie verschiedene API: J2EE
verwendet javax.mail.* .
Gruppe SEII03
16
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
J2EE Connector API 1.5 :
Dies ist ein API zur Erzeugung von Komponenten (resource adapter), die
den J2EE-Komponenten die Kommunikation mit Enterprise-InformationSystems (z.B. Datenbank) ermöglicht. Es wird von J2EESystemintegratoren benötigt.
Java Authentication and Authorisation Service 1.0 (JAAS):
Es dient der benutzerbasierten Autentifizierung und Autorisierung in J2EE
Applikationen. JAAS ist eine Version des Pluggable Authentication Module
(PAM) Framework, das in Java 2 enthalten ist.
Die Neuerungen in der Version 1.4 des J2EE betreffen vor allem WebServices:
Java Web Services 1.1 und Java Web Services Developer Pack
1.0_01 (Java WSDP):
Das Java WSDP ist z.B eine Werkzeugsammlung, die Java-Entwicklern
ermöglicht XML-Applikationen, Web-services und Web-Applikatonen zu
erstellen, testen und veröffentlichen. Enthalten sind folgende APIs:
Das Java XML Pack umfasst:
Java API for XML Messaging (JAXM) v1.1_01
Java API for XML Processing (JAXP) v1.2_01
Java API for XML Registries (JAXR) v1.0_02
Java API for XML-based RPC (JAX-RPC) v1.0_01
Java WSDP Registry Server v1.0_02
SOAP API with Attachments for Java (SAAJ) v1.1_02
Web Application Deployment Tool
JavaServer Pages Standard Tag Library (JSTL) v1.0.1
Ant Build Tool 1.4.1
Apache Tomcat 4.1.2 container
Gruppe SEII03
17
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
JAXM ist analog zu JMS für den Nachrichtenaustausch mittels SOAP
zuständig. Auch ist damit eine neue Bean-Art, JAXM-basierte MessageDriven Beans (JAXM-MDB), möglich.
Gruppe SEII03
18
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
JAX-RPC ist ähnlich zu Java-RMI, aber benutzt SOAP als Protokoll.
Mittels JAX-RPC können Session-, Entity-, und Message-Driven-BeanMethoden u.a. Microsoft .net Web-Services verwenden.
Abb.8 EJB verwendet Web-Service
Gruppe SEII03
19
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
JAX-RPC kann auch als Grundlage für das neues Endpoint-Interface
dienen. Ein stateless Session Bean kann als Web Service fungieren.
Abb.9 Web-Service verwendet EJB
3.4
Bestandteile eines EJB
Ein Enterprise Java Bean besteht im wesentlichen aus folgenden
Bestandteilen:
•
Home-Interface
•
Remote-Interface
•
EJB-Klasse
•
Primary-Key (-Klasse) , (nur Entity Beans, siehe 3.5.2)
•
Deployment-Deskriptor
Das Home-Interface definiert die Verwaltungmethoden des EJB, d.h. alle
Methoden, die seinen Lebenszyklus betreffen. Es beinhaltet das Interface
javax.ejb.EJBHome, das eine Grundfunktionalität eines Home Interfaces
definiert.
Gruppe SEII03
20
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Alle Methoden in diesem Interface müssen Java-RMI kompatibel sein, d.h.
jede Methode muß von dem java.rmi-Package genutzt werden können.
Der Client benutzt diese Schnittstelle um EJB-Instanzen zu erzeugen, um
sie zu finden und um sie zu löschen. Der Rückgabewert der create()Methode ist das Remote Interface für die EJB.
Das Remote-Interface definiert die „Business-Methoden“ des EJB. Damit
sind alle Funktionalitäten gemeint, die vom EJB nach außen hin
angeboten werden.
Ein EJB Remote Interface enthält das javax.ejb.EJBObject-Interface und
kann jede gewünschte Methode beinhalten, wobei die Rückgabewerte für
jede Methode RMI-kompatibel sein müssen und jede Methode eine
java.rmi.RemoteException beinhalten muß.
Ferner muß jede Methode des Remote-Interface exakt mit der
entsprechenden Methode der jeweiligen EJB-Klasse übereinstimmen.
Die EJB-Klasse implementiert alle Methoden, die im Home- und RemoteInterface deklariert wurden. Beispielsweise muss ejbCreate() zum
erzeugen eines EJB enthalten sein. Darüber hinaus finden sich in dieser
Klasse noch einige „Callback-Methoden“, die im entsprechenden Interface
des zugehörigen EJB-Typs definiert sind. Sie werden vom Container
aufgerufen um den Zustand des EJB zu steuern.
Der Primary-Key ist nur bei Entity-Beans relevant. Er gibt einer EJBInstanz eine eindeutige Identität gegenüber dem Client. Mit Hilfe des
Primärschlüssels kann der Client nach einer bestimmten EJB-Instanz auf
dem Server suchen. Bei zusamengesetzten Schlüsseln ist eine PrimaryKey-Klasse möglich.
Der Deploymentdiskriptor ist im wesentlichen eine XML-Datei, die
Verzeichnisinformationen und Benennungen über das EJB enthält. Hier
wird z.B. der Name, der Typ oder das Transaktionsverhalten angegeben.
Gruppe SEII03
21
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.10 Vererbungsbeziehungen von Home- und Remote-Interface
Das Remote-Interface (Book) ist immer abgeleitet vom Interface
EJBObject im package javax.ejb. Das Remote-Interface (BookHome) wird
abgeleitet vom Interface EJBHome, im package javax.ejb. Beide
Interfaces, EJBObject und EJBHome, sind wiederum abgeleitet von
Interface java.rmi.Remote.
Nur Klassen, die dieses Interface Implementieren, können im Sinne von
RMI als verteilte Objekte angesprochen werden.
Zusätzlich wird noch ein EJB-Client benötigt. Dies ist ein Stück Software
(JSP oder Servlet), das eine Funktion eines EJB in Anspruch nehmen will:
Es findet über das „Java Naming and Directory Interface“ (JNDI) die
gewünschte Komponente dank deren EJB-Home-Schnittstelle.
Die angeforderte Funktion der Komponente wird dann über deren EJBRemote-Schnittstelle aufgerufen. Der Client kann das EJB nie direkt
ansprechen.
Enterprise-Java-Beans können mit anderen EJB-Komponenten oder mit
einer Datenbank kommunizieren. Zur Migration der EJB-Technologie in
vorhandene Firmenumgebungen ist es hilfreich, daß alte Software sich bei
Bedarf mit Java-Code umhüllen und integrieren läßt (Wrapper).
Gruppe SEII03
22
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
3.5
EJB-Arten
Es gibt es drei verschiedene EJB-Typen: Session Beans, Entity Beans,
Message-driven Beans sowie deren Untertypen.
Abb.11 EJB-Typen
Alle drei Interfaces der Bean-Typen sind abgeleitet vom Interface
EnterpriseBean, im package javax.ejb. Es ist, genau wie das ElternInterface java.io.Serializable, lediglich ein „Marker-Interface“, enthält also
keine Methodendeklarationen.
Innerhalb der Bean-Interfaces sind Methoden deklariert, die der Container
benutzt um den Zustand der Bean zu verwalten (z.B. ejbActivate(),
ejbRemove() usw.). Diese Methoden werden allgemein auch als
„Callback-Methoden“ bezeichnet.
Gruppe SEII03
23
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Eine Sonderrolle spielt das Interface MessageDrivenBean. Es ist
abgeleitet von Interface javax.jms.MessageListener. Dieses Interface
deklariert nur eine Methode, nämlich „onMessage(java.jms.Message)“.
Abb.12 Vererbungsbeziehungen der EJB-Interfaces
3.5.1 Session Beans
Session Beans können einem Client für die Dauer einer Sitzung
(„Session“) exklusiv zu Verfügung gestellt werden. Sie enthalten BusinessLogik und sind üblicherweise mit einem EJB-Client assoziiert, der für ihre
Erzeugung und Zerstörung verantwortlich ist. Session Beans sind
transiente Objekte, die einen Shutdown des Servers nicht überleben. Sie
werden in „Stateless Session Beans“ und „Stateful Session Beans“
unterteilt.
Sie können zudem über Persistenz verfügen, d.h. mittels spezieller
Methoden über Client Sessions hinweg gespeichert werden, um den
Zustand (Daten) zu erhalten.
Allgemeine Verwendungszwecke für Session Beans:
-
Jederzeit hat nur ein Client Zugriff auf das EJB
-
Der EJB-Zustand ist nicht persistent (z.B. nur einige
Stunden)
Gruppe SEII03
24
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Beispielsweise würde der virtuelle Einkaufwagen eines Online-Shops und
sein Inhalt durch ein Session-Bean repräsentiert werden.
3.5.1.1 Stateless Session Beans
Diese EJBs besitzen keinen definierten Zustand, durch den sich eine
Instanz von einer anderen unterscheiden würde. Im allgemeinen hat Sie
auch keine Attribute weil bei Ihrer Erzeugung kein bestimmter Zustand
initialisiert werden muß (create() – Methode ohne Parameter).
Ein Stateless Session Bean kann von jedem beliebigen Client (auch von
mehreren) für einen Aufruf verwendet werden. Das bedeutet, daß ein
Client bei zwei aufeinander folgenden Methodenaufrufen durchaus zwei
verschiedenen Bean-Instanzen zugeordnet bekommen kann.
Um Ressourcen zu schonen werden Stateless Session Beans vom EJBContainer in Pools verwaltet.
Stateless Session Beans sollten bei einem oder mehreren zutreffenden
Krierien verwendet werden:
-
Der EJB-Status enthält keine Daten für einen speziellen Client
-
Ein einzelner Methodenaufruf der EJB führt eine allgemeine
Operation durch, die für alle Clients gültig ist (z.B. E-Mail
senden)
-
Das EJB benutzt die Datenbank nur lesend, um den Clients
häufig benötigte Daten zur Verfügung zu stellen
Gruppe SEII03
25
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.13 Zustandsdiagramm eines Stateless Session Bean
3.5.1.2 Stateful Session Beans
Im Gegensatz zu den Stateless Session Beans besitzen Stateful Session
Beans einen definierten Zustand, durch den sich eine Instanz von einer
anderen unterscheidet. Dieser ergibt sich aus den Werten der Attribute,
sowie allen verwendeten Ressourcen (z.B. Datenbankverbindungen). Sie
können daher nur von jeweils einem Client verwendet werden. Es können
verschiedene Zustände initialisiert werden (mehrere create() – Methoden
mit verschiedenen Parametern.
Ein Stateful Session Bean wird für die Dauer einer Session exklusiv einem
Client zugeordnet. Der Lebenszyklus der Instanz ist eng an den Client
gebunden,d.h. sie wird explizit vom Client erzeugt und auch wieder
gelöscht.
Durch die unterschiedlichen Zustände der einzelnen Bean-Instanzen ist
keine Pool-Verwaltung möglich um Ressourcen zu sparen. Statt dessen
werden Stateful Session Beans von Container passiviert, falls die Anzahl
sich im Arbeitsspeicher befindlicher Instanzen verringern werden muß.
Dafür wird die Instanz serialisiert und auf ein sekundäres Speichermedium
(z.B. Festplatte) geschrieben. Wird eine passivierte Instanz wieder
gebraucht, wird sie deserialisiert und wieder in den Arbeitsspeicher
geladen.
Gruppe SEII03
26
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Eine Stateful Session Bean kann sich in drei verschiedenen Zuständen
befinden:
Wenn eine Neue Instanz vom Client angefordert wird, geht das EJB nach
dem Aufruf von ejbCreate(...) des Home-Interfaces in den Zustand Ready
über (Der Container wird veranlasst, eine neue Instanz anzulegen).
Das EJB ist nun bereit, verschiedene vom Client aufgerufene Methoden
auszuführen. Tritt innerhalb einer Methode eine RuntimeException auf,
wird die Instanz von Container verworfen und der Client durch eine
RemoteException benachrichtigt.
Muß der Container das EJB passivieren um Ressourcen zu sparen, ruft er
ejbPassivate() auf. In dieser Methode können vom EJB-Provider noch
bestehende Ressourcen, die nicht serialisiert werden konnten,
geschlossen werden. Das EJB geht in den Zustand Passiviert über.
Um die Instanz wieder zu aktivieren, ruft der Container ejbActivate() auf.
Das EJB geht in den Zustand Ready über.
Falls ein Client vergessen hat die ihm zugeordnete Instanz explizit durch
ejbRemove() des Home-Interfaces zu löschen, wird das EJB irgendwann
einmal vom Container passiviert werden. Nach einer gewissen
Zeitspanne, in der die Instanz von keinem Client angefordert wurde, wird
die Bean automatisch vom Container gelöscht.
Abb.14 Zustandsdiagramm eines Stateful Session Bean
Stateful Session Beans sollten bei einem oder mehreren zutreffenden
Kriterien verwendet werden:
Gruppe SEII03
27
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
-
Der EJB-Status repräsentiert die Interaktion zwischen dem EJB
und einem speziellen Client
-
Das EJB muß Informationen bezüglich des Client auch zwischen
Methodenaufrufen speichern
-
Das EJB vermittelt zwischen dem Client und anderen
Komponenten der Applikation (bestimmte Sicht für den Client)
-
Das EJB koordiniert den Arbeitsablauf mehrerer EJB’s
3.5.2 Entity Beans
Entity Beans repräsentieren typischerweise Daten aus einer Datenbank.
Sie sind jedoch nicht nur als Datenspeicher zu betrachten, sondern als
vollständige Geschäftsobjekte mit eigener Funktionalität. Das bedeutet,
daß Entity Beans Methoden besitzen, die auf den Daten der Bean
(Attribute) arbeiten.
Entity Beans besitzen eine eindeutige Identität in Form ihres
Primärschlüssels. Normalerweise wird als Primärschlüssel der
Primärschlüssel der Datenbanktabelle verwendet. Handelt es sich um
einen zusammengesetzten Schlüssel aus mehren Attributen, wird eine
Primärschlüssel-Klasse definiert, die als Attribute die Spalten der
Datenbanktabelle enthält, die den Primärschlüssel der Datenbank
ergeben. Der Client kann mit Hilfe der „findByPrimaryKey(key) – Methode“
nach einer bestimmten Instanz auf dem Server suchen.
Entity Beans können von mehreren Clients parallel genutzt werden, so
daß sie transaktionsbewußt sein müssen.
Entity Beans sind persistent, da die dazugehörigen Daten in der
Datenbank abgespeichert sind. Sie überleben also einen Shutdown des
Servers. Ein Systemausfall oder Crash der virtuellen Maschine kann ein
Rollback laufender Datenbank-Transaktionen zur Folge haben, wird
jedoch nie das EJB oder die Referenzen der Clients auf diese
Komponente zerstören. Die Clients können sich später über den
eindeutigen Primärschlüssel wieder mit genau der vorher benutzten
Komponente verbinden.
Es gibt zwei verschieden Arten ein Entity Bean persistent in der
Datenbank zu speichern:
Bei Container-Managed Persistence (CMP) sorgt der Container für die
Synchronisation der Bean mit der Datenbank. Dafür werden vom
Container-Provider Tools zu Verfügung gestellt. Mit deren Hilfe werden die
Gruppe SEII03
28
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
entsprechenden SQL-Statements für das Mapping der Bean-Attribute auf
die Datenbank generiert.
Bei Bean-Managed Persistence (BMP) ist der Bean-Provider selbst dafür
verantwortlich das EJB mit der Datenbank synchron zu halten. Die nötigen
Datenbankzugriffe werden vom Entwickler mit Hilfe von JDBC in den
entsprechenden Methoden selbst codiert.
Abb.15 Zustandsdiagramm eines Entity Bean
Um Ressourcen zu sparen werden Entity Beans vom Container in Pools
verwaltet. Dabei unterhält der Container für jede Bean-Klasse einen
eigenen Pool. Um die Anzahl im Pool befindlicher Instanzen zu
vergrößern, erzeugt der Container eine neue Instanz und ruft die Methode
setEntityContext() auf. Die Bean-Instanz kann nun Anfragen des Clients
bearbeiten. Sie hat jedoch noch keine eindeutige Identität in Form eines
Primärschlüssels.
Sucht der Client eine bestimmte Instanz anhand des Primärschlüssels,
leitet der Container die Anfrage an eine beliebige Bean im Pool weiter.
Von der jeweiligen Bean wird die Methode ejbFindByPrimaryKey(key)
aufgerufen. Liefert die Suche in der Datenbank ein Ergebnis in Form eines
Primärschlüssels, wird eine Instanz aus dem Pool vorbereitet und durch
den Aufruf von ejbActivate() in den Zustand ReadyAsync gebracht. In
diesem Zustand hat die Bean bereits eine eindeutige Identität und kann
ihren Primärschlüssel über den EntityContext abfragen. Die Instanz ist
jedoch noch nicht mit der Datenbank synchronisiert.
Gruppe SEII03
29
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Die Synchronisation erfolgt in der Methode ejbLoad(), die anschließend
von Container aufgerufen wird. In dieser Methode werden die nötigen
SQL-Abfragen ausgeführt um die Attribute der Bean zu initialisieren.
Möchte der Client einen neuen Datenbankeintrag erzeugen erfolgt dies mit
dem Aufruf ejbCreate(...) unter Angabe des Primärschlüssels und allen
sonstigen Attributen als Parameter. Eine Bean-Instanz wird aus dem Pool
genommen und führt die nötigen SQL-Befehle aus.
Die Instanz wechselt anschließend in den Zustand ReadySyn in dem sie
mit der Datenbank synchronisiert ist. Zum löschen eines Eintrags dient die
Methode ejbRemove(). Der entsprechende Datensatz wird gelöscht und
die Bean-Instanz geht in den Zustand Pooled über.
Befindet sich die Bean im Zustand ReadySync kann sie verschiedene vom
Client gewünschte Methoden ausführen. Ändern sich dabei die
Attributwerte nicht, bleibt die Instanz im Zustand ReadySync. Wenn sich
die Attributwerte ändern geht sie in den Zustand ReadyUpdate über. In
diesem Zustand kann sie noch weitere Methoden ausführen. Der EJBContainer wird jedoch bald die Methode ejbStore() aufrufen um die Bean
wieder mit der Datenbank zu synchronisieren. In dieser Methode werden
die SQL-Updates ausgeführt.
Entity Beans sollten bei folgenden Bedingungen verwendet werden:
-
Das EJB repräsentiert Business-Daten und keine Methode
-
Der EJB-Status muss persistent sein (Speicherung in
Datenbank)
Beispielsweise soll für einen einzelnen Mitarbeiter in einer
Mitarbeiterdatenbank ein employee-Objekt erstellt werden. Der EJB-Client
erzeugt ein EJB-Objekt auf dem Server und arbeitet mit ihm, als wenn es
ein lokales Objekt wäre. Hierbei würde ein Entity-Bean verwendet werden.
Gruppe SEII03
30
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
3.5.3 Message-Driven Beans
Message-driven Beans (MDB) wurden mit der EJB-Spezifikation 2.0
eingeführt. Ein MDB ist ein asynchroner Nachrichtenkonsument für das
Java Message Service API (javax.jms.Message). Durch den asynchronen
Aufruf erhält man eine zeitliche Entkopplung von Sender und Empfänger.
Eine MDB besitzt kein Konversationsgedächtnis und hat keine sichtbare
Identität für den Client. Eine Besonderheit besteht darin, dass eine MDB
kein Home- oder Remote-Interface besitzt (nur die EJB-Klasse). Die.
Kommunikation des Clients mit der Bean erfolgt in diesem Fall über eine
javax.jms.Queue oder einen javax jms.Topic .
Die Nachrichten können von jeder J2EE-Komponente (Application-Client,
EJB, Web-Komponente) gesendet werden. Teilweise gilt das auch für
J2EE-fremde Komponenten.
In einigen Aspekten ist das Message-Driven Bean mit einem StatelessSession Bean zu vergleichen:
- Eine Instanz des Message-Driven Bean enthält keine weder
Daten noch Status für einen speziellen Client
- Alle Instanzen eines Message-Driven Bean sind gleich:
gleiche Nachricht an alle MDB’s, kontinuierliche
Nachrichtenverarbeitung durch mehrere MDB’s
- Ein einzelnes MDB kann Nachrichten vieler Clients verarbeiten
Message-Driven Beans sollten bei folgender Bedingung verwendet
werden:
Bei synchronem Empfangen vom Nachrichten durch Session- und EntityBeans wird der Empfänger blockiert und dadurch die Server-Kapazität
belastet. Um dies zu vermeiden, sollten MDB’s mit asynchronem
Nachrichtenempfang verwendet werden.
Gruppe SEII03
31
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.16 Zustandsdiagramm eines Message Driven Bean
3.6
Deployment
Beim Deployment des EJB, also bei der endgültigen Installation im EJBContainer, generiert der Container automatisch die zugehörigen
Implementierungen des Home- und Remote-Interfaces.
Zusätzlich wird für jede der beiden Implementierungen noch eine Stubund eine Skeleton-Klasse erzeugt, damit die Implementierungsklassen mit
Hilfe von RMI ansprechbar sind. Bei der Kommunikation per RMI muß auf
Seite des Clients eine Stub-Klasse vorhanden sein. Eine dazugehörige
Skeleton-Klasse liegt auf dem Server.
Der Client arbeitet nun mit dem Remote-Objekt, als ob er ein lokales JavaObjekt ansprechen würde. Die Methodenaufrufe werden jedoch vom Stub
serialisiert und über das Netzwerk an das entsprechende Skeleton-Objekt
gesendet. Dort wird der Methodenaufruf deserialisiert und am RemoteObjekt ausgeführt. Das Ergebnis des Aufrufes wird wiederum von
Skeleton serialisiert und an den Stub übermittelt. Dort wird das Ergebnis
der Anfrage deserialisiert und an das aufrufende Objekt übergeben.
Gruppe SEII03
32
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
3.7
Benutzung von EJB
Will ein Client ein Bean auf dem Server erzeugen, benutzt er das Java
Naming and Directory Interface (JNDI) zur Lokalisierung des Home
Interfaces für die Klasse des EJBs.
JNDI ist eine Standard-Erweiterung zu Java und bietet einen globalen
Service zu jeglicher Java-Umgebung. Es ermöglicht Java-Programmen die
Lokalisierung und Benutzung von Resourcen per Namen sowie die
Ermittlung und Analyse von Informationen und Strukuren über diese
Resourcen.
Das Client-seitige Home-Interface-Object führt einen Remote Method Call
(RMI) an den EJB Container aus, der dann eine EJB Component erzeugt.
Der Rückgabewert der create()-Methode ist das Remote Interface für die
EJB.
Der Client kann dann die Methoden des EJBs aufrufen, die an den
Container weitergereicht werden.
Der Container verzögert typischerweise die Weitergabe der Methode an
die EJB Component, da er gleichzeitig noch Fehlerprüfungen vornehmen
(z.B. ob EJB Component existent ist) und ggf. Exceptions werfen muß.
Das Home Interface enthält auch eine Methode, in der dem Container
mitgeteilt wird, wenn ein EJB Component entfernt werden soll. Diese
Methode zerstört die Server-seitige Instanz. Beim Versuch, ein zerstörtes
EJB anzusprechen, wird eine Exception geworfen.
Entitiy Beans haben zusätzliche Finder-Methoden im Home-Interface, um
basierend auf dem Primary Key des EJBs einzelne persistente EJBs zu
lokalisieren.
Gruppe SEII03
33
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.17 Zugriff auf EJB-Komponenten
3.8
Dateiformate
J2EE-Applikationen müssen folgende Dateifomate unterstützen:
HTML 3.2 / gif / jpg / jar / class (Java Klassen) / XML
J2EE-Applikationen sind durch *.ear (Enterprise Archiv) gekennzeichnet.
Sie enthalten nach Bedarf Web-Clients (*.war , Web Archiv), Enterprise
Beans (*.jar , Java Archiv) und Standalone-Clients (*.jar). DeploymentDeskriptoren sind über mehreren Hierachieebenen hinweg in „META-INF“Verzeichnissen enthalten.
*.ear, *.war und *.jar können durch das Java jar-Pack-Tool erzeugt
werden. Es ist ein zip-Format mit Beachtung von Gross- und
Kleinschreibung. Daher kann z.B. unter Windows ein zip-Packer (nur) zum
Entpacken der Archive verwendet werden.
Gruppe SEII03
34
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Enterprise Archiv (EAR) File
WAR-File
JAR-File
WAR-File
JAR-File
WAR-File
META-INF
Abb.18 EJB-Dateiarchive
4
Beispiel
Das folgende Beispiel dient dem praktischen
Programmierung von J2EE-Anwendungen:
Einstieg
in
die
Es stellt eine einfache Bankanwendung dar, mit deren Hilfe ein EuroGeldbetrag in US-Dollar, japanische Yen und britisches Pfund
umgerechnet wird.
Mittels eines Web-Client (JSP) wird auf ein Session EJB zur Berechnung
zugegriffen. Um das Beispiel einfach zu halten, sind die drei
Wechselkurse in diesem EJB gespeichert (keine Verwendung einer
Datenbank).
4.1
Entwicklungsschritte
Bei der Erstellung von J2EE-Anwendungen können
Entwicklungswerkzeuge mit verschiedenem Unterstützungsgrad
verwendet werden:
Gruppe SEII03
35
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Hierzu gehören Deploytools für Konfigurationsdateien und ServerInstallation (z.B. SUN Deploytool, JAKARTA Ant),
Entwicklungsumgebungen mit integriertem EJB-Wizard (z.B. SUN Forte
for Java Enterprise Edition) oder Case-Tools für vollständige J2EEApplikationen aus UML ( TOGETHERSOFT Together ControlCenter).
Bei diesem Beispiel wurden aus Gründen der Übersichtlichkeit extrem
wenig Unterstützungswerkzeuge benutzt. Dies brachte bei der
Entwicklung teilweise auch einen Zeitgewinn mit sich.
Die einzelnen Entwicklungsschritte im Überblick:
•
EJB-Klassen erstellen und kompilieren
•
Web-Client erstellen
•
Konfigurationsdateien (XML) erstellen
•
Verzeichnisstruktur erstellen
•
Archiv-Dateien (jar, war, ear) erstellen
•
Anwendung auf Applikations-Server installieren und starten
Im Folgenden wird nun näher darauf eingegangen.
4.2
EJB-Klassen erstellen und kompilieren
Das Beispiel benutzt ein Session-EJB, da dies zunächst einfacher als ein
Entity-EJB zu erstellen ist. Es besteht aus der EJB-Klasse, deren Homeund Remoteinterface
Es wird die Java-Version 1.3.1 in der Standard- und der Enterpriseversion
verwendet (sdk 1.3.1 / sdk 1.3.1ee).
Für die Kompilierung müssen die Umgebungsvariablen JAVA_HOME und
J2EE_HOME auf die entsprechenden Verzeichnisse verweisen und das
Paket sdk1.3.1ee/lib/j2ee.jar im Java-classpath angeben werden.
Als Entwicklungsumgebung unter Windows XP wird die frei erhältliche IDE
JCreator LE von Xinox Software benutzt (www.jcreator.com). Sie kann
aber auch durch jedes andere Verfahren zur Kompilierung ersetzt werden.
Gruppe SEII03
36
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
4.2.1 Die EJB-Klasse
package converter.ejb;
import java.rmi.RemoteException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import java.math.*;
public class ConverterBean implements SessionBean
{
//Exchange Rate: 28.09.2002 , 12:56
BigDecimal yenRate = new BigDecimal("120.1500");
BigDecimal dollarRate = new BigDecimal("1.0233");
BigDecimal poundRate = new BigDecimal("0.628");
public BigDecimal euroToDollar(BigDecimal euros)
{
return euros.multiply(dollarRate);
}
public BigDecimal euroToYen(BigDecimal euros)
{
return euros.multiply(yenRate);
}
public BigDecimal euroToPound(BigDecimal euros)
{
return euros.multiply(poundRate);
}
public ConverterBean() {}
public void ejbCreate() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sc) {}
}
Abb.19 Datei ConverterBean.java
Die package-Angabe ist für die spätere Verzeichnisstruktur der jar- und
war-packages (siehe 4.5) nötig.
Die Importanweisungen für EJB-Exceptions und Session-Bean
Eigenschaften sind ebenso wie die hier nicht definierten VerwaltungsMethoden (Im Container definiert, überladen möglich) durch den J2EEStandard vorgeschrieben.
Auch wird eine Klassenbenennung empfohlen: EJB-Klassen als
„KlasseBean“, Homeinterface als „KlasseHome“ und Remoteinterface als
„Klasse“.
Gruppe SEII03
37
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Die Business-Methoden im Beispiel erfordern java.math.* wegen des
Datentyps BigDecimal (siehe auch JSP-Client x.x.x). Die
Konvertierungsraten und –Methoden stellen die Businesslogik in diesem
EJB dar.
4.2.2 Das Remote-Interface
package converter.ejb;
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
import java.math.*;
public interface Converter extends EJBObject {
public BigDecimal euroToDollar(BigDecimal dollars) throws RemoteException;
public BigDecimal euroToYen(BigDecimal yen) throws RemoteException;
public BigDecimal euroToPound(BigDecimal yen) throws RemoteException;
}
Abb.20 Datei Converter.java
Hier werden nur die Deklarationen der Business-Methoden des EJB
mitsamt RemoteExceptions angegeben (als Interface).
Die Package-Angabe dient der EJB-Verwaltung und die ImportAnweisungen sind bis auf java.math.* durch J2EE vorgegeben.
4.2.3 Das Home-Interface
package converter.ejb;
import java.io.Serializable;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface ConverterHome extends EJBHome
{
Converter create() throws RemoteException, CreateException;
}
Abb.21 Datei ConverterHome.java
Gruppe SEII03
38
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Hier werden nur die Deklarationen der Verwaltungs-Methoden des EJB
mitsamt Exceptions angegeben (als Interface). Die Package-Angabe dient
der EJB-Verwaltung und die Import-Anweisungen sind bis auf java.math.*
durch J2EE vorgegeben.
4.3
Web-Client erstellen
<%@page
<%@page
<%@page
<%@page
<%@page
<%@page
import="converter.ejb.*"%>
import="javax.naming.*"%>
import="javax.rmi.PortableRemoteObject"%>
import="java.rmi.RemoteException"%>
import="javax.ejb.*"%>
import="java.math.*"%>
<%!
private Converter converter = null;
public void jspInit()
{
try
{
Context ic = new InitialContext();
Object objRef = ic.lookup("converter/MyConverter");
ConverterHome home = (ConverterHome) PortableRemoteObject.narrow
(objRef, ConverterHome.class);
converter = home.create();
}
catch (RemoteException ex)
{
System.out.println("Couldn't create converter bean."+
ex.getMessage());
}
catch (CreateException ex)
{
System.out.println("Couldn't create converter bean."+
ex.getMessage());
}
catch (NamingException ex)
{
System.out.println("Unable to lookup home: "+ "TheConverter "+
ex.getMessage());
}
}
public void jspDestroy()
{
converter = null;
}
%>
Abb.22 Datei Index.jsp (Teil1)
Gruppe SEII03
39
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
In der JSP wird zunächst eine Verbindung zum EJB aufgebaut ( jspInit() ):
•
Holen eines neuen Context: Context ic = new InitialContext()
•
Suchen des EJB über JNDI: Object objRef = ic.lookup
("converter/ MyConverter") ; Der Name „converter/
MyConverter“ wird später im Deployment-Descriptor
festgelegt.
•
Holen des Home-Interfaces über das PortableRemoteObject:
ConverterHome home = (ConverterHome) PortableRemote
Object.narrow (objRef, ConverterHome.class)
•
Erstellen des EJB mittels Home-Interfaces: converter =
home.create() ; Rückgabeobjekt ist das Remote-Interface
<html>
<head>
<title>Converter</title>
</head>
<body>
<bgcolor="white">
<h1><b><center></center></b></h1>
<hr>
<p>Enter Euro-amount to convert:</p>
<form method="get">
<input type="text" name="amount" size="25">
<br>
<p>
<input type="submit" value="Submit">
<input type="reset" value="Reset">
</form>
<%
String amount = request.getParameter("amount");
if ( amount != null && amount.length() > 0 )
{
BigDecimal d = new BigDecimal(amount) ;
%>
<p>
<%= amount %> Euro are
<p>
<p>
US-Dollar
: <%= converter.euroToDollar(d) %>
<p>
Japanese Yen : <%= converter.euroToYen(d) %>
<p>
British Pound: <%= converter.euroToPound(d) %>
</body>
</html>
Abb.23 Datei Index.jsp (Teil2)
Gruppe SEII03
40
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Nun kann die Logik der JSP auch die Methoden des EJB ansprechen:
4.4
•
Übernahme des URL-Parameter: String amount =
request.getParameter("amount")
•
Konvertierung des Parameters: BigDecimal d = new
BigDecimal(amount)
•
Aufruf der Methoden des Remote-Interfaces:
converter.euroToDollar(d)
Konfigurationsdateien erstellen
Konfigurationsdateien (DTD in XML) werden auch BereitstellungsDeskriptoren oder Deployment-Deskriptoren genannt. Sie enthalten in
dieser Beispielanwendung nur die nötigsten XML-Tags. Auch hier wird aus
Gründen der Übersichtlichkeit nur wenig Hilfswerkzeuge verwendet.
Wichtig ist hierbei u.a. die korrekte Gross-/Kleinschreibung.
Die nötigen Konfigurationsdateien sind nur zum Teil nach j2EE
standardisiert und werden durch spezielle Dateien des verwendeten
Applikationsservers ergänzt.
Zu den allgemeingültigen Dateien gehören:
•
web.xml zur Beschreibung des Web-Bestandteiles der
Applikation und der Startseite in Web
•
ejb-jar.xml zur Beschreibung der EJB’s inklusive deren
Interfaces
•
application.xml zu Beschreibung der Web-, EJB- und JavaBestandteile der vollständigen Anwendung
Gruppe SEII03
41
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
<?xml version="1.0"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<display-name>Converter Application</display-name>
<description>
This is a Currency Exchange Example to demonstrate EJB programming
It was written Alexander Kubicki
</description>
<context-param>
<param-name>appname</param-name>
<param-value>Converter</param-value>
<description>
The name of this application.
</description>
</context-param>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
Abb.24 Datei web.xml
Die Angabe des DOCTYPE ist hier wegen Java zwingend erforderlich. Die
welcome-file-list stellt die Startseiten des Web-Client dar.
<?xml version="1.0"?>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>TheConverter</ejb-name>
<home>converter.ejb.ConverterHome</home>
<remote>converter.ejb.Converter</remote>
<ejb-class>converter.ejb.ConverterBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
Abb.25 Datei ejb-jar.xml
Gruppe SEII03
42
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Hier werden die Bestandteile und Eigenschaften aller EJB’s angegeben.
Die Pfadnamen müssen mit den Klassennamen (im Package
converter.ejb) und der Verzeichnisstruktur (siehe 4.5 ) übereinstimmen.
Eine Entity-EJB würde hier eine eigene Sektion und zusätzliche XML-Tags
besitzen.
<?xml version="1.0"?>
<application>
<display-name>ConverterApp</display-name>
<description>Simple Bank Application</description>
<module>
<web>
<web-uri>converter.war</web-uri>
<context-root>converter</context-root>
</web>
</module>
<module>
<ejb>converter.jar</ejb>
</module>
</application>
Abb.26 Datei application.xml
Auf höchster Ebene werden hier die Namen der einzenen Archiv-Dateien
angegeben, deren Endungen durch J2EE vorgegeben sind.
Der in diesem Beispiel verwendete und frei erhältliche Applikations-Server
JBoss 2.4.6 verwendet folgende Server-spezifische Konfigurationsdateien:
•
jboss.xml zur Angabe von Namen für JNDI- und VerzeichnisReferenzierung
•
jaws.xml zum Mapping von EJB-Datentypen auf Datentypen
der Datenbank (nur bei Entity-EJB, hier nicht benötigt)
•
jboss-web.xml für ergänzende und serverspezifische Angaben
zur web.xml (hier nicht verwendet)
Gruppe SEII03
43
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
<?xml version="1.0"?>
<jboss>
<enterprise-beans>
<session>
<ejb-name>TheConverter</ejb-name>
<jndi-name>converter/MyConverter</jndi-name>
</session>
</enterprise-beans>
</jboss>
Abb.27 Datei jboss.xml
Hier werden die Bezeichnungen angegeben, unter denen ein Client das
EJB via JNDI ansprechen kann (siehe 4.3)
4.5
Verzeichnisstruktur erstellen
Im nachfolgenden Schritt müssen die Archiv-Dateien (*.war,*.jar,*.ear)
gemäss der J2EE-Spezifikation erstellt werden. Auch dabei sollen keine
Hilfswerkzeuge wie deploytool oder Ant zu Einsatz kommen.
Deswegen wird nun eine Verzeichnishierachie erstellt, die später gepackt
werden kann. Die bereits erstellten Dateien werden in die entsprechenden
Verzeichnisse eingefügt (wie in den XML-Dateien angegeben).
Gruppe SEII03
44
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.28 Verzeichnisbaum
4.6
Archiv-Dateien erstellen
Nach J2EE-Spezifikation müssen mit dem Java-Archiv-Tool JAR drei
Archiv-Dateien erstellt werden:
•
converter.war für den Web-Client (web archiv)
•
converter.jar für das EJB (java archiv)
•
converter.ear für die vollständige J2EE Applikation (enterprise
archiv)
Die Verzeichnisse und Dateien werden auf der Kommandozeile wie folgt
komprimiert:
1)
Im WAR-Verzeichnis: jar cvf converter.war *.*
2)
Datei converter.war ins EAR-Verzeichnis kopieren
3)
Im JAR-Verzeichnis: jar cvf converter.jar *.*
4)
Datei converter.jar ins EAR-Verzeichnis kopieren
5)
Im EAR-Verzeichnis: jar cvf converter.ear *.*
Gruppe SEII03
45
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
4.7
Anwendung auf Applikations-Server installieren und
starten
Die zuletzt erstellte Datei converter.ear stellt die komplette J2EEApplikation dar und muss auf dem verwendeten Applikationsserver
installiert werden.
Bei einigen Servern muss hierzu ein eigenes Werkzeug verwendet werden
(z.B. Bea Web Logic). Der in diesem Beispiel verwendete freie
Applikationsserver JBOSS bietet einen praktischen Automatismus (AutoDeploy): Die fehlerfreie J2EE-Anwendung, also die Datei converter.ear,
muss nur in ein spezielles deploy-Verzeichnis eingefügt werden. Der
Server entpackt und installiert die Datei selbstständig. Ab der Version 3.0
erstellt JBoss automatisch auch praktische Web-Clients für die
Administration der EJB’s
Zum Starten der Anwendung in diesem Beispiel mit lokaler
JBoss 2.4.6-Installation wird folgende WEB-URL aufgerufen:
http://localhost:8081/converter
Hierbei gilt zu beachten:
•
Fast jeder Applikationsserver verwendet standardmässig
andere Portnummern, die aber individuell angepasst werden
können (hier 8081 statt 8080)
•
Jeder Applikationsserver verwendet für Applikationen sowie
Server-Verwaltung zwei verschiedene Portnummern
Gruppe SEII03
46
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.29 Screenshot EJB-Beispiel
5
Ausblick
Wie in 3.3 dargestellt, wird das J2EE-Framework von SUN zur WebServices-Technologie erweitert (SUN ONE). Zusätzlich wird auch der
Zugriff von und zu Microsoft .net ermöglicht.
Im Vergleich zu verteilten Web-Anwendungen wie EJB mittels J2EE
werden mit Web Services die bisher nur intern verwendeten Dienste von
EJB-, CORBA- oder DCOM- Komponenten nach außen bekannt und
nutzbar gemacht.
Web Services werden über XML-Dokumente (Extensible Markup
Language) in WSDL (Web Services Definition Language) beschrieben.
Damit wird in zentralen Datenbanken ein UDDI-Verzeichnis (Universal
Description, Discovery and Integration) der verfügbaren Dienste
aufgebaut. Durch WSDL werden die Mechanismen früherer Standards
zum Datenaustausch, wie etwa bei COM und RPC ersetzt. Das Protokoll
SOAP (Simple Object Access Protocol) basiert auf XML und ersetzt die
proprietären Spezifikationen und Protokolle aus der CORBA-, DCOModer RMI-Welt.
Gruppe SEII03
47
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.30 Web-Services
Ein stateless Session Bean, BookCatalog EJB, benutzt JAX-RPC um den
Preis eines Buches in einem .net Web-Service zu ermitteln. Dieser
verarbeitet die SOAP-Nachricht und sendet eine Antwort an eine
Hilfsklasse. Sie extrahiert das Ergebnis aus der SOAP-Nachricht und gibt
es an den Client zurück.
Gruppe SEII03
48
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
6
Fragen und Antworten
1.
Nennen Sie 3 wichtige J2EE-APIs
o Enterprise Java Beans (EJB)
o Remote Method Invocation (RMI)
o Java Naming and Directory Interface (JNDI)
2.
Nennen Sie die EJB-Typen ggf. Ihre Unterteilung
o Session-Bean (stateful und stateless)
o Entity-Bean (Container Managed und Bean Managed)
o Message-Driven-Bean
3.
Nennen Sie die Bestandteile eines EJB und deren Aufgaben
o Home-Interface (Verwaltungmethoden)
o RemoteInterface (Businessmethoden)
o EJB-Klasse (Implementierung)
o Deployment-Deskriptoren (Konfiguration)
4.
Wie ist eine Three-Tier-Architecture aufgebaut?
Es gibt
o Frontend
o Business-Logik
o Datenbank
5.
Welche Schritte zur Benutzung von Enterprise Java Beans
sind nötig?
1. Home-Interface des EJB mit JNDI suchen
Gruppe SEII03
49
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
2. Server-Objekt mittels Home-Interface erzeugen und
Remote-Interface bekommen
3. Business-Methoden des Remote-Interface anwenden
6.
Was ist die Hauptaufgabe eines EJB-Containers?
o Bereitstellung einer Laufzeitumgebung für EJB
Gruppe SEII03
50
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
7
Quellenverzeichnis
Besel, Ulrich, Menzel, Martin, Multerer, Klaus, Studienarbeit zur
Vorlesung Software-Engineering II: Software-Komponenten-Modelle
ActiveX, JavaBeans,Enterprise JavaBeans, Fachhochschule München
Fachbereich Informatik, 2001
Haefel, Monson, Monson-Haefel's Guide to Enterprise JavaBeans EJB 2.1 Web Services: Part1, URL:
http://theserverside.com/resources/ (26.08.2002, 17:35 MEZ)
Haefel, Monson, Monson-Haefel's Guide to Enterprise JavaBeans What’s new in EJB 2.1, URL: http://theserverside.com/resources/
(26.08.2002, 17:35 MEZ)
Humbold, Stefan, Lamprechter, Christian, Kalter, Guido, Studienarbeit
zur Vorlesung Software-Engineering II: Komponentenmodelle:
Enterprise JavaBeans (EJB), Fachhochschule München Fachbereich
Informatik, 2000
Krechowezki, Oleg, Studienarbeit zur Vorlesung SoftwareEngineering II: J2EE Application Server, Fachhochschule München
Fachbereich Informatik, 2001
Kubicki, Alexander, Bericht des 2. Praktischen Studiensemesters
Informatik, Fraunhofer-Institut für Experimentelles Software
Engineering, Kaiserslautern, 2002
Miciecki, Christian, Sempruch, Rafael, Sperl, Roland, Studienarbeit zur
Vorlesung Software-Engineering II: Komponentenmodelle: JavaBeans
und Enterprise JavaBeans, Fachhochschule München Fachbereich
Informatik, 2000
Sun Microsystems, Enterprise Java Beans Specification, Version 2.1, ,
URL: http://java.sun.com/products/ejb [pdf Format] (26.08.2002, 17:40
MEZ)
Sun Microsystems, The J2EE Tutorial, A beginner's guide to
developing enterprise applications on the Java 2 Platform,
Enterprise Edition SDK version 1.3, Date 9/17/01 , URL:
http://java.sun.com/j2eetutorial/index.html (26.08.2002, 17:40 MEZ)
Sun Microsystems, Java 2 Platform, Enterprise Edition Specification
Version 1.4, , URL: http://java.sun.com/j2ee/docs.html [pdf Format]
(26.08.2002, 17:40 MEZ)
Gruppe SEII03
51
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Turau, Volker, Java Server Pages und J2EE: unternehmensweite
Web-basierte Anwendungen, dpunkt Verlag, Heidelberg, 2001
Willax, Theodor, Wulf, Marten, Zielinski, Stefan, Studienarbeit zur
Vorlesung Software-Engineering II: Enterprise Java Beans,
Fachhochschule München Fachbereich Informatik, 2002
Wutka, Mark, J2EE Developer’s Guide (dt.): JSP,Servlets, EJB 2.0,
JNDI, JMS, JDBC, Corba, XML, RMI, Markt+Technik Verlag,München
2002
8
Abbildungsverzeichnis
Abb.1: Zwei-Schichten-Architektur
8
Abb.2: Three-Tiers-Architecture
9
Abb.3 n-Tiers-Architecture
9
Abb.4 Drei-Schichtenmodell
10
Abb.5 Beziehungen im Drei-Schichtenmodell
11
Abb.5 Architektur einer EJB-Anwendung
12
Abb.6 Entwicklerrollen
14
Abb.7 Remote Method Invocation
15
Abb.8 EJB verwendet Web-Service
19
Abb.9 Web-Service verwendet EJB
20
Abb.10 Vererbungsbeziehungen von Home- und Remote-Interface
22
Abb.11 EJB-Typen
23
Abb.12 Vererbungsbeziehungen der EJB-Interfaces
24
Abb.13 Zustandsdiagramm eines Stateless Session Bean
26
Abb.14 Zustandsdiagramm eines Stateful Session Bean
27
Abb.15 Zustandsdiagramm eines Entity Bean
29
Abb.16 Zustandsdiagramm eines Message Driven Bean
32
Abb.17 Zugriff auf EJB-Komponenten
34
Abb.18 EJB-Dateiarchive
35
Abb.19 Datei ConverterBean.java
37
Gruppe SEII03
52
Fachhochschule München – Software Engineering II
Komponentenmodelle : Enterprise Java Beans
Abb.20 Datei Converter.java
38
Abb.21 Datei ConverterHome.java
38
Abb.22 Datei Index.jsp (Teil1)
39
Abb.23 Datei Index.jsp (Teil2)
40
Abb.24 Datei web.xml
42
Abb.25 Datei ejb-jar.xml
42
Abb.26 Datei application.xml
43
Abb.27 Datei jboss.xml
44
Abb.28 Verzeichnisbaum
45
Abb.29 Screenshot EJB-Beispiel
47
Abb.30 Web-Services
48
Gruppe SEII03
53