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


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


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


Stub

Naming-S.

STUB calls SKELETON

Skeleton

Client Server

Lokales Objekt

Proxies, Stubs, Skeletons


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 .


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.


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.



-> Bedarf für EJB


EJB als Komponenten


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.


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


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)


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


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


EJB Pool

Container

RemoteHomeServant

Home PoolClient

Client



-> Bedarf für EJB


EJB als Komponenten


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


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


EJB Architektur

RMI

EJB-Server

Clients

RDBMS

CORBA

JDBC

Container

Legacy-Application

B

B


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


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


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.


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


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


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().


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.


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.


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.


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.


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.


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


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


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}


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"


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.


Verteilte Transaktionen

Context

ClientTransactional

Client

T.Object

RecoverableServer

R.S.T.

Object

beginT,commit

abort

2PCTr.-Service


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


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


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

Documents

Enterprise Java Beans (EJB)