1 / 39

Enterprise Java Beans (EJB)

Enterprise Java Beans (EJB). Projekt Verteilte Informationssysteme Freitag, 3.11.2000. Gerald Weber. Überblick. Middleware, Zweck und Funktion -> Bedarf für EJB Applikationsserver: EJB für Skalierbarkeit EJB als Komponenten. Middleware.

alice
Download Presentation

Enterprise Java Beans (EJB)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. Proxies, Stubs, Skeletons Server Client Stub Naming-S. Lokales Objekt Skeleton STUB calls SKELETON 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 . 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 Client Home Pool Home Servant Remote 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 EJB-Server RDBMS RMI JDBC B Clients Container B CORBA Legacy- Application 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 JSP DD Cart .jar Order Client EJBServ.+Cont. M. Client HTTP Client C. O. 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. 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) Java-Sprachebene: Elemente einer EJBean Home Remote Bean Helper Helper Gerald Weber - EJB

  25. 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(). Beispiel: Die EntityBean MyCat 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. 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. Grundidee der Persistenz bei EJB DBMS Beans Gerald Weber - EJB

  32. 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. Persistenz: Alternativen bei EJB 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 RecoverableServer T.Object TransactionalClient Client R.S. T.Object beginT, commit abort Context Tr.-Service 2PC 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 Gerald Weber - EJB

More Related