Enterprise Java Beans (EJB) Projekt Verteilte Informationssysteme Freitag, 3.11.2000 Gerald Weber.

Präsentation zum Thema: "Enterprise Java Beans (EJB) Projekt Verteilte Informationssysteme Freitag, 3.11.2000 Gerald Weber."—  Präsentation transkript:

1 Enterprise Java Beans (EJB) Projekt Verteilte Informationssysteme Freitag, 3.11.2000 Gerald Weber

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

3 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

4 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

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

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

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

8 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.

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

10 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.

11 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: u Entity = persistenter Zustand u Transaction = kapselt Prozedur u Session = Clientbezogener Kontext u Message Client = Asynchroner Service

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

13 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

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

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

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

17 Gerald Weber - EJB 17 EJB als Komponenten  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

18 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

19 Gerald Weber - EJB 19 EJB Architektur RMI EJB-Server Clients RDBMS CORBA JDBC Container Legacy- Application B B

20 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 Cart JSP M. O.C. EJB Serv.+ Cont. HTTP Client DD

21 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

22 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.

23 Gerald Weber - EJB 23 Welche Klassen stellen EJB dar?  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

24 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) HomeRemote Bean Helper

25 Gerald Weber - EJB 25 Beispiel: Die EntityBean MyCat  Home-Interface MyCatHome: u create(String Name) u findByPrimaryKey(String) u findLike(String keyword) u ssv(integer percent)  Remote-Interface MyCat: u getPrice() etc. u setPrice() etc. u buy(int pieces)  Bean-Klasse MyCatBean: Implementiert Methoden aus MyCatHome und MyCat.  Deployment Descriptor: u type: entity u role admin: Alle Methoden u role customer: nicht setPrice().

26 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.

27 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.

28 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.

29 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.

30 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.

31 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

32 Gerald Weber - EJB 32 Persistenz: Alternativen bei EJB Bean 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

33 Gerald Weber - EJB 33 CMP am Beispiel  Einträge im Deployment Descriptor u Persistente Felder: price, stock, description, vendor u Informelle Beschreibung der FinderMethoden: findLike: „Findet alle Produkte mit ähnlichem Namen“  setPrice(int newprice) { price = newprice }

34 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"

35 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.

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

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

38 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

39 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