Enterprise Java Beans EJB Projekt Verteilte Informationssysteme Freitag

Enterprise Java Beans (EJB) Projekt Verteilte Informationssysteme Freitag, 3. 11. 2000 4. 11. 1999 Gerald Weber - EJB Gerald Weber

Überblick u Middleware, Zweck und Funktion -> Bedarf für EJB u Applikationsserver: EJB für Skalierbarkeit u EJB als Komponenten Gerald Weber - EJB 2

Middleware u u u 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 3

RPC und CORBA: Motivation u u u 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 4

Proxies, Stubs, Skeletons Server Client Lokales Objekt Naming-S. Skeleton Stub STUB calls Gerald Weber - EJB SKELETON 5

Realisierung des Aufrufs Möglichkeiten der Parameterübergabe: u Call by reference: Bei verteilt zugreifbaren Referenzen. u Call by Value: Bei Daten. u Strukturierte Daten werden durch Middleware als Datenstrom versandt. Gerald Weber - EJB 6

Verteiltes OO-Modell vs. lokales OO -Modell u u 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 7

Einfache Serverarchitektur u u u u 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 8

Überblick u Middleware, Zweck und Funktion -> Bedarf für EJB u Applikationsserver: EJB für Skalierbarkeit u EJB als Komponenten Gerald Weber - EJB 9

Applikationsserver: EJB für Skalierbarkeit u u 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 10

EJB als Standard für Objektpools u u Mismatch zwischen lokalen und verteilten Objekten: EJB definiert einen „Standard-Mismatch“ Server-Implementierung hängt von Objekt-Charakter ab. Oberklassen: u Entity = persistenter Zustand u Transaction = kapselt Prozedur u Session = Clientbezogener Kontext u Message Client = Asynchroner Service Gerald Weber - EJB 11

EJB Objektpool u u 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: u gebunden (sie repräsentieren ein verteiltes Objekt) u gepoolt (sie sind bereit, gebunden zu werden) Gerald Weber - EJB 12

Auslagerung u u u 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 13

Life-Cycle-management u u 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 u zum Life-Cycle-Management ein Home-Interface u ein Remote-Interface, mit den Business-Methoden (Instanzmethoden). Nur ein Pool für beide Interfaces Gerald Weber - EJB 14

EJB Pool Container Client Home Remote Pool Home Servant Client Gerald Weber - EJB 15

Überblick u Middleware, Zweck und Funktion -> Bedarf für EJB u Applikationsserver: EJB für Skalierbarkeit u EJB als Komponenten Gerald Weber - EJB 16

EJB als Komponenten u u u Zweck, Nutzung, Funktion der Beans Standard auf Java-Sprachebene [EJBSpec 2. 0] u Allgemein u Session Beans u Entity Beans u Transaktionen u Sicherheit, Zugriff, Benutzeridentifikation Kritik Gerald Weber - EJB 17

Ziele der EJB Architektur u u 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 18

EJB Architektur EJB-Server RMI Clients RDBMS B JDBC Contain er B CORBA Legacy. Application Gerald Weber - EJB 19

Beispiel: E-Commerce-System u Bean-Provider Cat. com bietet Produktkatalog My. Cat an u App. Assembler Web. Vend erstellt Applikation Buy. Me u Marktplatz Good. Stuff ist Deployer, EJBServer und Container kommen von Mega. Beans . jar JSP Client Gerald Weber - EJB HTTP My. Cat Cart. jar Order DD EJB M. Serv. + Cont. C. O. 20

EJB Rollen u u u 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 Systemprogrammierung, Load Balancing) System-Administrator Gerald Weber - EJB 21

Komponentenbegriff u u u 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 22

Welche Klassen stellen EJB dar? u u EJB repräsentieren grobkörnige Business-Objekte: u Sitzungsobjekte: Session Beans u 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 23

Java-Sprachebene: Elemente einer EJBean u u u 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) Gerald Weber - EJB Home Remote Bean Helper 24

Beispiel: Die Entity. Bean My. Cat u u Home-Interface My. Cat. Home: u create(String Name) u find. By. Primary. Key(String) u find. Like(String keyword) u ssv(integer percent) Remote-Interface My. Cat: u get. Price() etc. u set. Price() etc. u buy(int pieces) u u Bean-Klasse My. Cat. Bean: Implementiert Methoden aus My. Cat. Home und My. Cat. Deployment Descriptor: u type: entity u role admin: Alle Methoden u role customer: nicht set. Price(). Gerald Weber - EJB 25

EJB Contracts: Client-View-Contract u u u 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 JVMGrenzen hinweg. Dyn. Bean-Nutzung mit Meta. Data-Interface. Gerald Weber - EJB 26

Component Contract (Erklärt Container) u u u 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 27

Einschränkungen für EJB u u 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 28

Session. Beans u u u 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 29

Transaktionen: ACID Eigenschaften u u 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 30

Grundidee der Persistenz bei EJB u u 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. Gerald Weber - EJB DBMS Beans 31

Persistenz: Alternativen bei EJB Bean Managed u Datenzugriff muß programmiert werden u Routinen: find, load, store, remove, create Container Managed u Datenzugriff wird vom Container beim Deployment erzeugt u Automatisches Mapping auf die Datenbank. Business-Methoden werden in gleicher Weise implementie Gerald Weber - EJB 32

CMP am Beispiel u u Einträge im Deployment Descriptor u Persistente Felder: price, stock, description, vendor u Informelle Beschreibung der Finder. Methoden: find. Like: „Findet alle Produkte mit ähnlichem Namen“ set. Price(int newprice) { price = newprice } Gerald Weber - EJB 33

Bean Managed Persistence am Beispiel u u u ejb. Create(. . . ): "insert into Cat. Table Values (. . . )" ejbfind. Like(keyword): "select. . . where ID = $name"; ejb. Load(): "select. . . where ID = $name"; price = resultset. get(" price "). . . ejb. Store(): if (dirty) "update. . . where ID = $name" ; ejb. Remove(): "delete. . . where ID = $name" Gerald Weber - EJB 34

CMP in EJB Version 2. 0 u u 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 35

Verteilte Transaktionen Client Transactional Client begin. T, commit T. Object Recoverable Server T. Object R. S. abort Tr. Service Gerald Weber - EJB Context 2 PC 36

Transaction Demarcation u u u Session. Beans: Container-/Bean-managed Entity. Beans: Nur Container-managed Container Managed: u Transaktions-attribut im DD per Methode: Required, Supports, not. Supp. , Req. New, Mand. , Never u Bei Client-Call ohne Transaktionskontext: Business-methode wird mit Transaktion gekapselt u Für Abbruch set. Rollback. Only(), auch bei Exceptions Ses. B. : Updates bleiben, Ent. B. : Updates verloren Gerald Weber - EJB 37

Security u u 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. get. Caller. Principal() EJBContext. is. Caller. In. Role(String role) //z. B. Limits Gerald Weber - EJB 38

Kritik u u Ständig sich änder Standard (? ) Performanz ist unklar. Unklarkeiten bei der gesamten Architektur. Unklarheiten in der Spezifikation Gültigkeit Handle, Bean-To-Bean Roles Gerald Weber - EJB 39