Download - Enterprise Java Beans (EJB)
Enterprise Java Beans (EJB)
Projekt Verteilte Informationssysteme Freitag, 3.11.2000
Gerald Weber
Gerald Weber - EJB 2
Überblick Middleware, Zweck und Funktion
-> Bedarf für EJB
Applikationsserver: EJB für Skalierbarkeit
EJB als Komponenten
Gerald Weber - EJB 3
Middleware Zweck: Unterstützung von Verteiter
Applikationsprogrammierung. Bietet Infrastruktur, die von Low-Level Aufgaben
abstrahiert. Middleware-Ansätze:
- Remote Procedure Call (RPC)- Message Oriented Middleware (MOM)- Object Oriented Middleware: CORBA, DCOM, RMI
Gerald Weber - EJB 4
RPC und CORBA: Motivation Motivation aus Sicht der Verteilungsproblematik:
Kommunikation zwischen Verteilten Prozessen soll durch den Austausch strukturierter Daten erfolgen.
Motivation aus Sicht der Programmierparadigmen:Verteilungstransparenz!Ein verteilter Aufruf soll wie ein lokaler Aufruf wirken.
Realisierung über Proxies
Gerald Weber - EJB 5
Stub
Naming-S.
STUB calls SKELETON
Skeleton
Client Server
Lokales Objekt
Proxies, Stubs, Skeletons
Gerald Weber - EJB 6
Realisierung des AufrufsMöglichkeiten der Parameterübergabe: Call by reference: Bei verteilt zugreifbaren
Referenzen. Call by Value: Bei Daten. Strukturierte Daten werden durch Middleware als
Datenstrom versandt .
Gerald Weber - EJB 7
Verteiltes OO-Modell vs. lokales OO-Modell Das Verteilte Modell kann auf verschiedene
Zielsprachen abgebildet werden (CORBA) Ein verteiltes Objekt soll länger leben als einzelne
Prozesse (insbesondere bei Persistenz) Die Infrastruktur erfordert weitere, technische
Methoden neben den Business-Methoden. Naives Mapping (z.B. RMI): Ein lokales Objekt
entspricht einem verteilten Objekt -> Skalierbarkeitsproblem.
Gerald Weber - EJB 8
Einfache Serverarchitektur Ein Serverprozess nimmt alle Requests an einem
Rechner entgegen. Jedem Request ordnet er nach einer
Namenskonvention ein ausführbares Programm zu. Das Programm wird als Prozess gestartet. Es erhält die Parameter als Standardinput. Der Standardoutput ist der Rückgabewert. Hohe Verfügbarkeit, keine Alterung. begrenzt skalierbar.
Gerald Weber - EJB 9
Überblick Middleware, Zweck und Funktion
-> Bedarf für EJB
Applikationsserver: EJB für Skalierbarkeit
EJB als Komponenten
Gerald Weber - EJB 10
Applikationsserver: EJB für Skalierbarkeit Verteilte OO-Systeme benötigen Server. Skalierbarkeitsproblem: Es sind oft mehr verteilte
Objekte referenziert als im Server lokal gehalten werden können.
Performanceproblem: Die Ressourcen, die zur Bearbeitung eines Requests erforderlich sind, sind- begrenzt- teuer beim Aufbau.
Lösung: Objektpools.
Gerald Weber - EJB 11
EJB als Standard für Objektpools Mismatch zwischen lokalen und verteilten Objekten:
EJB definiert einen „Standard-Mismatch“ Server-Implementierung hängt von Objekt-Charakter
ab. Oberklassen: Entity = persistenter Zustand Transaction = kapselt Prozedur Session = Clientbezogener Kontext Message Client = Asynchroner Service
Gerald Weber - EJB 12
EJB Objektpool EJB-Objektpool ist ein Pool von Java-Objekten
(Terminus: Servants, leider in EJB nicht verwandt), der vom Server vorgehalten wird.
Servants können in ihrem Leben verschiedene verteilte Objekte repräsentieren. Entscheidende Zustände: gebunden (sie repräsentieren ein verteiltes
Objekt) gepoolt (sie sind bereit, gebunden zu werden)
Gerald Weber - EJB 13
Auslagerung EJB verwendet nicht die Virtual-Memory Funktion des
Betriebssystems. Alle Servants sind im Hauptspeicher. Wenn zu viele verteilte Objekte referenziert sind,
müssen Servants ihre Bindung abgeben und ihr Zustand muss ausgelagert werden: passivate/activate
Gerald Weber - EJB 14
Life-Cycle-management Der Lebenszyklus verteilter Objekte wird bei EJB auf
standardisierte Weise gemanaged. In einer EJB-Welt gibt es Kollektionen von Objekten.
(EJ Beans?) Jede Kollektion von Objekten besitzt
zum Life-Cycle-Management ein Home-Interface ein Remote-Interface, mit den Business-Methoden
(Instanzmethoden). Nur ein Pool für beide Interfaces
Gerald Weber - EJB 15
EJB Pool
Container
RemoteHomeServant
Home PoolClient
Client
Gerald Weber - EJB 16
Überblick Middleware, Zweck und Funktion
-> Bedarf für EJB
Applikationsserver: EJB für Skalierbarkeit
EJB als Komponenten
Gerald Weber - EJB 17
EJB als Komponenten Zweck, Nutzung, Funktion der Beans Standard auf Java-Sprachebene [EJBSpec 2.0]
Allgemein Session Beans Entity Beans Transaktionen Sicherheit, Zugriff, Benutzeridentifikation
Kritik
Gerald Weber - EJB 18
Ziele der EJB Architektur Standard-Applikationsserver-Architektur für Java Abstraktion von Low-Level Aufgaben bei
Transaktionen, Multithreading, Connection Pooling Komponenten-Orientierung: Applikationen können
aus Teilen verschiedener Hersteller aufgebaut werden
Definierte Rollenverteilung für die Systemerstellung,Definition der Aufgaben der Rollen durch Contracts
Gerald Weber - EJB 19
EJB Architektur
RMI
EJB-Server
Clients
RDBMS
CORBA
JDBC
Container
Legacy-Application
B
B
Gerald Weber - EJB 20
Beispiel: E-Commerce-System Bean-Provider Cat.com bietet
Produktkatalog MyCat an
App. Assembler WebVend erstellt Applikation BuyMe
Marktplatz GoodStuff ist Deployer, EJBServer und Container kommen von MegaBeans
MyCat.jar
MyCat.jar Order
CartJSP
M.O.C.
EJBServ.+Cont.
HTTPClientClient
Client
DD
Gerald Weber - EJB 21
EJB Rollen Bean Provider (Experte im Anwendungsbereich) Application Assembler: (Experte im
Anwendungsbereich) Deployer (Experte für spezielle Systemumgebung) EJB Server Experte (TP-Experte, z.B. DB-Anbieter) EJB Container Provider (Experte für System-
programmierung, Load Balancing) System-Administrator
Gerald Weber - EJB 22
Komponentenbegriff Beans implementieren Business-Logik. Beans sind verteilte Objekte. Bean ist über eine Anzahl von Parametern anpaßbar. Beans enthalten deklarative Information (Deployment-
Descriptor). Client-Zugriff erfolgt durch festgelegte
Interfacegruppe.
Gerald Weber - EJB 23
Welche Klassen stellen EJB dar? EJB repräsentieren grobkörnige Business-Objekte:
Sitzungsobjekte: Session Beans Persistente Objekte: Entity Beans
Beispiel: Eine Bean für Rechnung, aber nicht für Rechnungsposten
Keine aktiven Objekte Beans haben ein Analyse-Interface
Gerald Weber - EJB 24
Java-Sprachebene: Elemente einer EJBean Home Interface: Feste Arten
von Klassen-Methoden. U.a. Life-cycle-Management Methoden
Remote Interface: Instanzmethoden, Business-Methoden
Beanklasse: Implementiert beide Interfaces
Deployment Descriptor Verwendete andere Klassen
(Helper Classes)
Home Remote
Bean
HelperHelper
Gerald Weber - EJB 25
Beispiel: Die EntityBean MyCat Home-Interface MyCatHome:
create(String Name) findByPrimaryKey(String) findLike(String keyword) ssv(integer percent)
Remote-Interface MyCat: getPrice() etc. setPrice() etc. buy(int pieces)
Bean-Klasse MyCatBean: Implementiert Methoden aus MyCatHome und MyCat.
Deployment Descriptor: type: entity role admin: Alle
Methoden role customer: nicht
setPrice().
Gerald Weber - EJB 26
EJB Contracts: Client-View-Contract Client kann durch RMI oder CORBA auf Bean zugreifen. Pro Deployment einer Bean ist ein Home-Interface-
Objekt in JNDI eingetragen und für den Client nutzbar. Bean Instanzen implementieren das Remote-interface
Der Client erhält sie durch das Home-Interface. Der Client kann ein sog. Handle erhalten. Dieses
identifiziert Bean-Instanzen oder -Homes über JVM-Grenzen hinweg.
Dyn. Bean-Nutzung mit MetaData-Interface.
Gerald Weber - EJB 27
Component Contract (Erklärt Container) Bean implementiert Business-M., Life-cycle-M. u.a.
Callbacks. Container ruft diese sinngemäß auf. Container behandelt Trans., Security and Exceptions. Container bietet JNDI-Environment, EJBContext. Bean Provider vermeidet Programmierung, die das
Container Runtime Management stört. Optional: Container behandelt Persistenz. Deployment-Descriptor enthält entsprechende Daten.
Gerald Weber - EJB 28
Einschränkungen für EJB Dürfen keine Nebenläufigkeitsmechanismen
(Threads, synchronised-Statement) nutzen. Dürfen keine r/w statischen Variablen nutzen. Dürfen nur die explizit erlaubten Dienste nutzen. Dürfen nicht selbst Transaktionsgrenzen setzen.
Gerald Weber - EJB 29
SessionBeans Enthalten Interaktionszustand (conversational state) Lebensdauer wird vom Client kontrolliert. Kann auf Platte ausgelagert werden (passivation)
mittels Serialization. Kann nur von einem Client angesprochen werden. Kann gespeichert werden als Handle.
Gerald Weber - EJB 30
Transaktionen: ACID - Eigenschaften Atomicity: Jede Transaktion wird ganz oder gar nicht
ausgeführt (= Sicht der anderen Nutzer). Consistency: Transaktionen hinterlassen die
Datenbank in einem konsistenten Zustand. Isolation: Transaktionen erscheinen, als wenn sie
hintereinander (sequentiell) ausgeführt würden. Durability: Wenn eine Transaktion erfolgreich beendet
ist, sind ihre Änderungen an Daten persistent.
Gerald Weber - EJB 31
Grundidee der Persistenz bei EJB ACID - Eigenschaften von
Transaktionen werden genutzt.
Innerhalb einer Transaktion kann mit genau einer Kopie gearbeitet werden.
Diese muß vor einem Commit gespeichert werden.
Eine Kopie je Transaktion.
DBMS
Beans
Gerald Weber - EJB 32
Persistenz: Alternativen bei EJBBean Managed Datenzugriff muß
programmiert werden Routinen:
find, load, store, remove, create
Container Managed Datenzugriff wird vom
Container beim Deployment erzeugt
Automatisches Mapping auf die Datenbank.
Business-Methoden werden in gleicher Weise implementiert
Gerald Weber - EJB 33
CMP am Beispiel Einträge im Deployment Descriptor
Persistente Felder: price, stock, description, vendor Informelle Beschreibung der FinderMethoden:
findLike: „Findet alle Produkte mit ähnlichem Namen“
setPrice(int newprice) { price = newprice}
Gerald Weber - EJB 34
Bean Managed Persistence am Beispiel ejbCreate(...): "insert into CatTable Values (...)" ejbfindLike(keyword):
"select ... where ID = $name"; ejbLoad(): "select ... where ID = $name";
price = resultset.get(" price ") ... ejbStore(): if (dirty)
"update ... where ID = $name" ; ejbRemove(): "delete ... where ID = $name"
Gerald Weber - EJB 35
CMP in EJB Version 2.0 Wird vom Persistence-Manager gelöst. UML-artige Modelle können verarbeitet werden. Finder-Methoden werden mit EJBQL beschrieben:
SQL, aber Ergebnis ist immer Primärschlüsselliste. Business-Methoden können weitergehende select-
Anfragen stellen.
Gerald Weber - EJB 36
Verteilte Transaktionen
Context
ClientTransactional
Client
T.Object
RecoverableServer
R.S.T.
Object
beginT,commit
abort
2PCTr.-Service
Gerald Weber - EJB 37
Transaction Demarcation SessionBeans: Container-/Bean-managed EntityBeans: Nur Container-managed Container Managed:
Transaktions-attribut im DD per Methode:Required, Supports, notSupp., Req.New, Mand., Never
Bei Client-Call ohne Transaktionskontext:Business-methode wird mit Transaktion gekapselt
Für Abbruch setRollbackOnly(), auch bei ExceptionsSes.B.: Updates bleiben, Ent.B.: Updates verloren
Gerald Weber - EJB 38
Security App.Ass. definiert Sicherheits-Rollen (security roles),
diesen gibt er (das) Zugriffsrecht per Methode Deployer weist Benutzern (Principals) S.-Rollen zu,
ebenso weist er Beans Rollen zu (auch zu RM) Container ermöglicht dieses Sicherheitsprotokoll Bean-managed Security (zusätzlich):
EJBContext.getCallerPrincipal()EJBContext.isCallerInRole(String role) //z.B. Limits
Gerald Weber - EJB 39
Kritik Ständig sich ändernder Standard (?) Performanz ist unklar. Unklarkeiten bei der gesamten Architektur. Unklarheiten in der Spezifikation
Gültigkeit Handle, Bean-To-Bean Roles