Ein gesundes und erfolgreiches Jahr

Ein gesundes
und erfolgreiches
Jahr
2005!
J2EE und Enterprise Java Beans
Komponentenbasierte
Softwareentwicklung mit der Java 2
Enterprise Edition und Enterprise Java
Beans
Ein Überblick
Inhalt
I Typische Anforderungen an Enterprise Software

Begriffsklärung „Enterprise Software“

Typische Anforderungen
II J2EE – Eine Übersicht

Was ist J2EE?

Aufbau von J2EE – Anwendungen

Lösungsansätze für Anforderungen aus Teil I

Servlets und JSPs
IIIEnterprise JavaBeans (EJB)

Was sind EJB?

Vorstellung der EJB-Typen
IVZusammenfassung: EJB-Komponenten, J2EE Patterns
Enterprise Software
●
Kein scharf abgegrenzter Begriff
●
Mögliche Beschreibung:
►
●
●
●
„Enterprise Software ist Software zur direkten
Unterstützung oder Abwicklung betriebswirtschaftlich
relevanter Vorgänge“
Diese Vorgänge sind Teile von Geschäftsprozessen
(Beispiel siehe nächste Folie)
Begriffe, die dasselbe bezeichnen: BIS, CIS, EIS, ...
Sehr verbreitet bei Banken, Versicherungen und in der
Industrie
Beispiel-Geschäftsprozeß
Anforderungen an EIS
●
Wirtschaftliche Rahmenbedingungen
►
●
Kompatibilität mit heterogenen Umgebungen, z.B.
►
●
Kosten vs. Nutzen
Integration von vorhandenen Anwendungen, Datenbanken,
Harware,...
Typische Anforderungen:
►
Transaktionsschutz (ACID-Eigenschaften auch über
mehrere Systeme hinweg sicherstellen)
►
Sicherheit (Authentisierung, Autorisierung)
►
Offenheit und Integrierbarkeit
►
Skalierbarkeit, Verteilbarkeit
►
Verfügbarkeit
Teil 2 - J2EE
I Typische Anforderungen an Enterprise Software

Begriffsklärung „Enterprise Software“

Typische Anforderungen
II J2EE – Eine Übersicht

Was ist J2EE?

Aufbau von J2EE – Anwendungen

Lösungsansätze für Anforderungen aus Teil I

Servlets und JSPs
IIIEnterprise JavaBeans (EJB)

Was sind EJB?

Vorstellung der EJB-Typen
IVZusammenfassung: EJB-Komponenten, J2EE Patterns
Was ist J2EE?
●
J2EE ...
►
Ist eine Menge an Erweiterungen der J2SE, die genau wie
diese von Sun spezifiziert werden
- Erweiterungen sind im wesentlichen eigenständige
Spezifikationen aus der Java-Welt (Bsp. JDBC), welche
für Enterprise-Software nützlich sein können
►
►
►
Ist durch diese Erweiterungen für Entwicklung
mehrschichtiger Anwendungen geeignet
Bietet Unterstützung für Installation/Inbetriebnahme der
Anwendung
Beinhaltet Komponentenmodell
Typen von J2EE Komponenten
●
J2EE-Anwendungen sind aus folgenden Komponenten
aufgebaut
►
Klientenapplikationen und Applets
- Als Komponente wird hier ein normales Java-Programm
verstanden, im Idealfall eine reine
Benutzungsschnittstelle (ohne eigene Anwendungslogik)
►
Web-Komponenten
- Sind Servlets und Java Server Pages; Programme die
eine Anforderung erhalten und eine Antwort darauf
generieren
►
Enterprise JavaBeans
- Java-Klassen in denen die Anwendungslogik und der
Datenzugriff einer J2EE-Anwendung implementiert sein
können
Zentraler Begriff:Container
●
●
Container ist eine Metapher für die Laufzeitumgebung der
verschiedenen Komponententypen: Jeder Typ ist nur
„innerhalb“ seines bestimmten Containertyps lauffähig
Bei J2EE:
►
Basislaufzeitumgebung ist immer J2SE
►
Dienst-APIs unterscheiden sich
Dienst
API
Dienst
API
Komponente
Dienst
API
Komponente
Dienst
API
Container
Dienst
API
Server
Container-Verantwortlichkeiten
●
Aller Zugriff (Erzeugung, Aufruf von Operationen etc.) auf
J2EE-Komponenten erfolgt nur über den Container
►
●
Web- und EJB-Komponenten haben einen definierten
Lebenszyklus (erlaubte Zustände und Übergänge)
►
●
Für zugreifende Programme sieht es allerdings so aus, als
würden sie direkt die jew. Komponente benutzen
Container verwaltet diesen Lebenszyklus
Verwaltung von Systemresourcen (Speicher,
Datenbankverbindungen etc.)
Containertypen und APIs in J2EE 1.4
J2EE - „Module“
●
●
Zusammenfassung mehrerer J2EE-Komponenten gleichen
Typs zu einer Installationseinheit
Dieser Installationseinheit liegt ein sog. Deployment
Descriptor bei
►
●
Ein Deployment Descriptor ist eine Konfigurationsdatei im
XML-Format, in der angegeben ist, wie die einzelnen
Komponenten eines Moduls installiert werden sollen
Es gibt 4 Typen von J2EE-Modulen
►
EJB-Module (jar-Datei)
►
Web-Module (war-Datei)
►
Application Client Module (jar-Datei)
►
Reource Adapter Module (rar-Datei)
Zusammensetzung einer J2EEAnwendung
Abbildung
aus [3]
J2EE - Rollen
●
J2EE Product Provider
►
●
Tool Provider
►
●
Entwickler von EJB, Web-Komponenten und Klientenanwendungen
Application Assembler
►
●
Anbieter von Werkzeugen für die anderen Rollen
Application Component Provider
►
●
Anbieter von J2EE-Plattformen bzw. einzelner APIs; Anbieter von
DBMS und Betriebssystemen
Zusammenstellen von Applikationen aus Komponenten des
Component Provider
Application Deployer and Administrator
►
Installation und Wartung der Anwendung
J2EE-Lösungsansätze für
Anforderungen aus Teil 1
●
Transaktionsschutz
►
EJB-Container enthält u.a. Unterstützung für verteilte
Transaktionen; Transaktionen auch rein deklarativ
steuerbar
- ALSO: Verwendung einer bestimmten Art von EJB
addressiert die ACID Anforderungen
●
Sicherheit
►
Web-Container enthält Authentisierung für Http-Klienten
►
Benutzer-, Rollen- & Rechteverwaltung
►
Deklarative Angabe von verlangten Rollen
J2EE-Lösungsansätze (cont.)
●
Offenheit und Integrierbarkeit
►
Fernaufrufbarkeit von EJB
►
Lose Koppelung z.B. durch Webdienste
►
Namensdienste
●
Leichte Installation durch definierte Archivformate
●
Skalierbarkeit
►
●
Lastenverteilung durch Clustering möglich
Ausfallsicherheit
►
z.B. Clustering
Web-Komponenten:Servlets
●
●
Servlets sind Java-Klassen, die auf einem Server mit
Web-Container laufen und deren Aufgabe es ist, einen
Dienst zu erbringen, d.h. in Abhängigkeit irgendwelcher
Eingabedaten irgendwelche Ausgabedaten zu erzeugen
Meist in folgendem Szenario:
►
►
►
►
Der Klient eines Servlets schickt einen HTTP-Befehl an den
Web-Container
Der Web-Container erkennt, an welches Servlet dieser
Befehl gehen sollte und wandelt ihn in einen ServletMethodenaufruf um (meist doGet(), doPost())
In diesen Methoden wird eine Antwort vorbereitet
Der Web-Container sendet diese als HTTP-Antwort an den
Aufrufer
Kleines Beispiel
public class HelloWorldServlet extends HttpServlet
{
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
String webmaster = getServletContext()
.getInitParameter("webmaster");
}
}
PrintWriter pw = response.getWriter();
pw.write("<html><body>");
pw.write("<h1>HELLO WORLD!</h1>");
pw.write("<p>"+webmaster+"</p>");
pw.write("</body></html>");
pw.flush();
Zugehöriger Descriptor
<web-app>
<display-name>Test Servlet</display-name>
...
<context-param>
<param-name>webmaster</param-name>
<param-value>[email protected]</param-value>
</context-param>
<servlet>
<servlet-name>Shelloworld</servlet-name>
<servlet-class>test.HelloWorldServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Shelloworld</servlet-name>
<url-pattern>/hw</url-pattern>
</servlet-mapping>
</web-app>
http://container:8080/myApp/hw
Teil 3 – Enterprise Java Beans
I Typische Anforderungen an Enterprise Software

Begriffsklärung „Enterprise Software“

Typische Anforderungen
II J2EE – Eine Übersicht

Was ist J2EE?

Aufbau von J2EE – Anwendungen

Lösungsansätze für Anforderungen aus Teil I

Servlets und JSPs
IIIEnterprise JavaBeans (EJB)

Was sind EJB?

Vorstellung der EJB-Typen
IVZusammenfassung: EJB-Komponenten, J2EE Patterns
Was sind EJB?
●
Enterprise JavaBeans ...
►
Sind keine Java Beans (EJB ≠ Java Beans)
- EJB haben kein Property-Konzept mit get – und set –
Methoden, bound properties etc...
- EJB haben kein Eventmodell wie JavaBeans
- EJB sind ein anderes Komponentenkonzept als
JavaBeans
►
►
Sind normale Java-Klassen, die den Vorgaben („Verträgen“)
(Schnittstellen,etc..) der EJB-Spezifikation genügen
J2EE – Spezifikation stellt einen Container für EJB zur
Verfügung
Wieso EJB für Anwendungslogik?
●
Vorteile von EJB sind vor allem Vorteile die der EJBContainer bietet:
►
Transaktions- und Sicherheitseinstellungen lassen sich
deklarartiv & unabhängig von der Implementierung
vornehmen
- Zugriff auf die EJB-Klassen erfolgt immer über den
Container (erzeugt und verwaltet die Objekte)
►
Persitenz-Einstellungen lassen sich deklarativ vornehmen
- Im Idealfall muß keine einzige Zeile JDBC-Code
geschrieben werden und die verwendete Datenbank erst
bei der Installation der Bean angegeben werden
►
●
Reichhaltiges Angebot an Bibliotheken
Portierbarkeit von Anwendungslogik auf Container
unterschiedlicher Hersteller
Typen von EJB
●
EJB-Komponenten können
►
Einen zustandslosen Dienst repräsentieren, der synchron
aufgerufen werden kann
- Das kann auch ein XML-Webdienst sein (1.4)
►
►
►
►
Einen zustandslosen Dienst repräsentieren, der asynchron
aufgerufen werden kann
Eine Sitzung mit einem Klienten über mehrere synchrone
Aufrufe hinweg repräsentieren (Zustandsaufbewahrung)
Ein Geschäftsobjekt repräsentieren, was von mehreren
Klienten benutzt werden kann
Ein persistentes Objekt darstellen
Dienst := Menge von Geschäftsoperationen
Typen von EJB (cont.)
●
Session Beans
►
„stateless“
- Synchroner Aufruf von Operationen, kein Zustand
►
„stateful“
- Synchroner Aufruf, Zustand wird über mehrere Aufrufe
hinweg behalten
●
Message Driven Beans
►
●
Asynchroner Aufruf, kein Zustand
Entity Beans
►
Synchroner Aufruf, automatische Persitenz, keine
Sessionverwaltung
Zweiteiliger Komponentenvertrag
Schnittstellen f. Lokalen
und Entfernten Zugriff
sowie für Metadaten, ...
Abbildung
aus [1]
Implementierung von
Geschäftslogik,
Erzeugungsmethoden,
Callback-Methoden, ...
Session Beans - Eigenschaften
●
Enthält Methoden der Geschäftlogik („speichere neues
Rezept“)
●
1:1 – Beziehung zu Klienten
●
Methoden können in Transaktionen gruppiert werden
●
●
●
●
Methoden operieren typischerweise auf persistenten
Daten (direkter DB-Zugriff oder Zugriff auf Entity Beans)
Relativ kurzlebig; verschwinden wenn der EJB-Container
abstürzt
EJB-Container stellen normalerweise einen kompletten
Pool an Session-Beans zur Verfügung
Session-Beans können „stateful“ und „stateless“ sein
Session-Bean: Klientensicht
●
Session Beans besitzen zwei Schnittstellen, genannt
►
Remote (bzw. Local) Home Interface
- Enthält Methoden zum Kontrollieren des Lebenszyklus
einer Session Bean
- Erbt von javax.ejb.EJBHome bzw. javax.ejb.EJBLocalHome
►
Remote (bzw. Local) Component Interface
- Enthält die Methoden der Geschäftslogik
- Erbt von javax.ejb.EJBObject/javax.ejb.EJBLocalObject
●
Klienten benutzen JNDI* um ein Verweis auf eine HomeSchnittstelle zu bekommen. Dieser dient als Fabrik zum
Erzeugen der Sessionbean-Objekte.
*Java Naming & Directory Interface
Erzeugen eines Session Beans
●
Der Klient kennt:
Ort des Namensdienstes
HashTable prop = new HashTable();
prop.put("java.naming.provider.url", "med-host:9999");
try {
Logischer Name des Beans
InitialContext context = new InitialContext(prop);
Object ref = context.lookup("verordnungen/Rezept");
RezeptHome home = (RezeptHome) PortableRemoteObject.narrow (ref,
RezeptHome.class);
Rezept r = home.create();
}
catch(CreateException ce) {...}
catch(RemoteException re) {...}
Namen von Home- und RemoteSchnittstelle
... Als Bild
Abbildung
aus [1]
Remote Home Interface
●
●
Gedacht für den Fernaufruf (Alle Operationen deklarieren
mögliche RemoteExceptions !)
Erzeugen von Session-Bean-Objekten
►
●
remove(Handle h); remove(Object primaryKey);
Abfragen von Metadaten (Vgl. BeanInfo...)
►
●
z.B. createRezept();
Entfernen von Session-Bean-Objekten
►
●
create<METHOD>(...):Object,
getEJBMetadata():EJBMetaData
Erzeugen eines Serialisierbaren "Handles"
►
getHomeHandle():Handle
Local Home Interface
●
●
●
●
Für lokalen zugriff, d.h. Klient und EJB laufen in der
selben JVM-Instanz
Eingeführt als Effizienzsteigerung gegenüber RMI
Nur Erzeugen und Entfernen von SessionBean-Objekten
ist möglich, wieder mit der Ausnahme von remove(Object pk)
Achtung! Unterschiedliche Aufrufsemantik bei lokalen
Objekten (call-by-value)
►
►
Objekte können von Klienten und Bean gleichzeitig
referenziert werden
Zustand eines Beans darf nicht einem anderen Bean
zugewiesen werden (liegt in der Verantwortung des
Bean-Entwicklers)
EJBObject & EJBLocalObject
●
●
●
●
Werden vom Container als Implementierungen der
"Remote" bzw. "Local"-Komponentenschnittstellen zur
verfügung gestellt
Deligieren Aufrufe der Geschäftsmethoden an die
eigentliche Session-Bean
Es exsitieren vordefinierte Methoden
►
Für den Zugriff auf das zugehörige Home – Interface
►
Für den Test, ob zwei Session Beans identisch sind
►
Für das Entfernen des bestimmten Session Beans
Für EJBObject (d.h. Im Remote-Fall) zusätzlich
►
Erzeugen eines Objekt-Handles
Objektidentität
●
Stateful Session Beans haben eindeutige Identität, die
Beim Erzeugen vom Container zugewiesen wird
Foo foo1 = fooHome.create(...);
Foo foo2 = fooHome.create(...);
if (foo1.isIdentical(foo1)) {// true
...}
if (foo1.isIdentical(foo2)) {// false
...}
●
Stateless Session Beans einer bestimmten HomeSchnittstelle haben immer dieselbe Identität
Foo foo1 = fooHome.create(...);
Foo foo2 = fooHome.create(...);
if (foo1.isIdentical(foo1)) {// true
...}
if (foo1.isIdentical(foo2)) {// true
...}
Zusammenfassung Klientensicht
Umsetzung von Session Beans
●
Als Session-Bean Entwickler muß man folgendes
bereitstellen:
►
Das Remote Home-Interface:
- Erben von javax.ejb.EJBHome
- Alle Methoden deklarieren RemoteExceptions
- create<METHOD> - Methoden, die als Rückgabewert das
Komponenten-Interface haben und CreateException
deklarieren
►
Analog, für Local Home Interface (EJBLocalHome), jedoch
ohne RemoteExceptions
Umsetzung von Session Beans (2)
►
Die Komponenten-Schnittstelle
- Erben von javax.ejb.EJBObject
- Methoden deklarieren RemoteException
- Signaturen der Anwendungsmethoden, die in der
eigentlichen Bean-Klasse (s. Nächste Folie)
implementiert sind
►
Analog für lokale Komponentenschnittstelle
►
(Web Service Endpoint Interface)
Umsetzung von Sessions (3)
►
Eine Klasse, die die Anwendungslogik enthält
- Implementiert javax.ejb.SessionBean
- Public, nicht final, nicht abstakt, ohne finalize()
- Parameterloser Konstruktor
- Anwendungsmethoden und ejbCreate-Methoden
- Im "stateful"-Fall optional: Schnittstelle
javax.ejb.SessionSynchronisation
- Im "stateless"-Fall optional: Schnittstelle
javax.ejb.TimedObject
Beispiel:
fernaurufbares
Stateful
Session
Bean
Lebenszyklus
eines "stateful
session bean"
(intern, im ggs.
zu dem Zyklus,
den der Klient
sieht)
Transaktionsmarkierung
<ejb-jar>
...
<assembly-descriptor>
...
<container-transaction>
<method>
<ejb-name>eRezept</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>eRezept</ejb-name>
<method-name>addPosition</method-name>
</method>
<trans-attribute>Mandatory</trans-attribute>
...
</assembly-descriptor>
</ejb-jar>
Entity Beans - Eigenschaften
●
●
Repräsentieren Objektorientierte Sicht auf Persistente
Daten (z.B. in einem RDBMS)
1:N – Beziehung zu Klienten (Nebenläufiger Zugiff über
Transaktionen geregelt)
●
Sind im ggs. zu Session Beans relativ langlebig
●
Methoden dienen der Manipulation von Daten
●
Container stellen die Konsitenz der OO-Sicht mit den
eigentlichen Daten sicher
Entity Beans - Klientensicht
●
Analog zu den Session Beans
●
Zusätzlich im Remote (bzw. Local) Home Interface:
►
"finder" – Methoden zum finden von Entity Beans oder
Mengen von Entity Beans
- findByPrimaryKey(pk)
- Weitere, z.B.
►
findeRezepteMitWirkstoff(String wirkstoff)
Sog. Home-Methoden für Operationen, die nicht einzelne
Bean-Instanzen betreffen
- z.B.
●
(obligatorisch)
anzahlVonRezeptenMitMedikament(String med):int
Zusätzlich in der Komponentenschnittstelle:
►
getPrimaryKey():Object
Entity Beans - Klientensicht
Vgl.
Session
Beans
Umsetzung von Entity Beans
●
Definition eines "abstakten Persistenzschemas" analog zu
einem Schema für ein RDBMS (z.B. durch Entity
Relationship - Modell)
►
►
●
●
Entity ≈ Entity Bean mit sog. "container managed
persistant fields" (cmp)
Relationship ≈ sog. "container managed relationships"
(cmr)
Diese Definition erfolgt deklarativ im ejb-jar.xml –
Deployment-Descriptor
Ist (wie ER-Modell) unabhängig von konkreten DBImplementierungen
Datenmodell-Beispiel
<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>Rezept</ejb-name>
<home>de.eGK.RezeptHome</home>
<remote>de.eGK.Rezept</remote>
<ejb-class>de.eGK.RezeptEntity</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.String</prim-key-class>
<reentrant>False</reentrant>
<cmp-field>
<field-name>id</field-name>
</cmp-field>
<cmp-field>
<field-name>datum</field-name>
</cmp-field>
<primkey-field>id</primkey-field>
<resource-ref>
<res-ref-name>jdbc/postgresql</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</entity>
</enterprise-beans>
[...]
Wird später vom
"Deployer" angegeben
Rezept
id
datum
Datenmodell-Beispiel (cont.)
<relationships>
<ejb-relation>
<ejb-relation-name>Rezept-Position</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>
rezept-hat-position
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>Rezept</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>positionen</cmr-field-name>
<cmr-field-type>java.util.Collection </cmr-field-type>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role>
<ejb-relationship-role-name>
position-aus-rezept
</ejb-relationship-role-name>
<multiplicity>Many</multiplicity>
<relationship-role-source>
<ejb-name>Position</ejb-name>
</relationship-role-source>
</ejb-relationship-role>
<ejb-relation>
Rezept
1
N
Position
Umsetzung von Entities (2)
●
●
●
●
●
Die Entity-Bean Klasse muss abstakt sein und abstakte
get/set – Methoden für jedes cmp – und cmr – Feld aus
dem abstakten Persistenz-Schema enthalten
Sie muß die Schnittstelle javax.ejb.EntityBean
implementieren
Sie muß ejbCreate<METHOD> und ejbHome<Method> - aus
dem Home-Interface sowie Geschäftsmethoden aus dem
Remote-Interface implementieren
Leeren Konstruktor anbieten
Weitere Verantwortlichkeiten des Bean Providers : siehe
[1]
EJB - QL
●
●
●
●
Und: Implementierung der finder-Methoden (z.B.
findByPrimaryKey())???
Es exisitiert eine Anfrage-Sprache für das abstrakte
Schema namens "EJB-QL"
Die Anfragen der Finder-Methoden werden in EJB-QL im
Deployment Descriptor deklariert
Der Container muß diese Anfragen zur Installationszeit in
die Anfragesprache des jew. DB-Systems übersetzen
(meist SQL)
EJB QL :: = select_clause from_clause [where_clause] [orderby_clause]
EJB QL - Beispiel
<enterprise-beans>
<entity>
<ejb-name>Rezept</ejb-name>
<!-- Klassen der Home & Remote-Interfaces, CMP-Definitionen etc -->
[...]
<query>
<query-method>
<method-name>findeRezeptMitWirkstoff</method-name>
</query-method>
<ejb-ql>SELECT r FROM Rezept r, Position p, Medikament m
WHERE .... AND m.wirkstoff=?1
</ejb-ql>
</query>
[...]
Zustansdiagramm: Entity Beans
Message Driven Beans
●
●
●
Empfänger asynchroner Nachrichten (die z.B. von
anderen Beans per JMS gesendet wurden)
Haben keinen Zustand, keine Home- oder
Komponentenschnittstelle
Bean-Klasse muß javax.ejb.MessageDrivenBean und
javax.jms.MessageListener implementieren
JMS 1
JMS 2
Message Driven Beans (2)
Zusammenfassung
●
●
●
EJB: Komponentenarchitektur die verschiedene
Anforderung an "Enterprise Software" gerecht werden soll
EJB-Container ist Laufzeitumgebung für EJBKomponenten und stellt für jeden EJB-Typ spezielle
Dienste zur Verfügung
Es gibt
►
Session Beans (mit oder ohne Zustand)
- Transaktionen, Sicherheit
►
Entity Beans
- Objektorientierte Sicht auf persistente Daten
►
Message Driven Beans
- Empfänger asynchroner Nachrichten
Vorteile von EJB
●
●
●
●
EJB – Komponenten erleichtern die Entwicklung von
großen Anwendungskomponenten, die den "Enterprise"Anforderungen standhalten müssen
Standard garantiert theoretische Portierbarkeit
Im Idealfall muß nur noch Anwendungscode
programmiert werden: Nicht-Anwendungscode (DBVerbindungen, Transaktionskontrolle, Sicherheit, ...)
obliegt dem Container und wird deklarativ gesteuert.
Interoperabilität von EJB mit CORBA und XMLWebservices
Nachteile
●
●
●
●
●
Anspruch, viele Ansprüche von Enterprise Software zu
erfüllen, führt zu einem relativ komplexen Standard: man
muß viel Zeit investieren, um EJB's sinnvoll anwenden zu
können.
Nicht geeignet/benötigt für kleinere Anwendungen
Wahrscheinlich historisch bedingt: unsaubere Klassenbzw. Schnittstellenhierarchien (Bsp. Nächste Folie)
Abstraktes Persistenzschema d. Entity Beans impliziert
eine neue Sprache, die gelernt werden muß: EJB QL
EJB, die fernaufrufbar sind deklarieren immer
RemoteExceptions (müssen im Klienten immer behandelt
werden!)
EJBContext
SessionContext
EJBContext
EntityContext
MessageDrivenContext
Ausblick: EJB 3.0
●
●
●
Java 5.0 Annotationen: Verwenden von Annotationen in
den Bean-Klassen (Bean-Entwickler braucht keinen
Deployment Descriptor mehr zur Verfügung zu stellen)
Mehr default-Konfigurationen (Configuration by
Exception)
Komponenten-Schnittstellen nicht mehr EJBObject,
EJBLocalObject – Implementierungen
●
Home-Interfaces werden nicht mehr benötigt
●
Generelle Reduktion der "Checked Exceptions"
●
uvm.
Quellen
●
[1] Enterprise JavaBeansTM Specification,Version 2.1 & 3.0
(Early Draft) http://java.sun.com/products/ejb/docs.html
●
[2] J2EE 1.4 -Tutorial von Sun
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
●
[3] Vorlesungsfolien zu "Bau betrieblicher
Informationssysteme mit J2EE WS2004/5" Teil (0) und (1)
http://projects.mi.fu-berlin.de/w/bin/view/SE/VorlesungBISJ2EE2004
●
●
[4] Applying Enterprise JavaBeans™:Component-Based
Development for the J2EE™ Platform, Second Edition (Addison
Wesley 2003) von Vlada Matena, Sanjeev Krishnan,
Linda DeMichiel, Beth Stearns
[5] Erarbeitung einer Stategie zur Einführung der
Gesundheitskarte: Geschäftsprozeßmodell Version 1.1;
bIT4health-Konsortium, 12. August 2004