Komponenten-orientierte Middleware am Beispiel von Enterprise Java Beans (EJB) Clemens Düpmeier, 28.03.2017.

Präsentation zum Thema: "Komponenten-orientierte Middleware am Beispiel von Enterprise Java Beans (EJB) Clemens Düpmeier, 28.03.2017."—  Präsentation transkript:

1 Komponenten-orientierte Middleware am Beispiel von Enterprise Java Beans (EJB)
Clemens Düpmeier,

2 Vorteile von Verteilter Objektkommunikation
Verteilte Objekttechnologien erleichtern die Programmierung Programmierer muss kein Protokoll schreiben und implementieren Es können beliebig komplexe Daten übertragen werden Verwendung (fast) so einfach wie lokale Funktionen Technologie kümmert sich um die wesentlichen Fehlersituationen Verteilte Kommunikation kann auf fast beliebiger Granularitätsebene stattfinden Beliebige Granularität bei Entfernten Objekte, Parameter und Returnwerten Allerdings muss man auf Performance aufpassen Serverseite hat bereits einfaches Management von Paralellität in der Abarbeitung von Client-Requests eingebaut und stellt weitere Dienstleistungen, wie Aktivierung, etc. bereit Clemens Düpmeier,

3 Was kann an Verteilter Objektkommunikation noch verbessert werden?
Gibt es auch Nachteile? Was kann an Verteilter Objektkommunikation noch verbessert werden? Clemens Düpmeier,

4 Probleme mit VT-Technologien
Verteilte Objekte in RMI, CORBA, etc. sind an diese Kommunikationsart gebunden Programmierer brauchen häufig bessere Kontrolle über Art des parallelen Zugriffs Der Zugriff auf gemeinsame Ressourcen muss vom Programmierer selbst synchronisiert werden Viele Verteilte Objekte brauchen häufig einen Zugriffsschutz, der vom Applikationsprogrammierer selbst in die Applikationen hineincodiert werden muss Objekte benötigen generell weitere Hilfsdienste, wie Transaktionen, Persistenzmechanismen, etc., die traditionell in die Objekte selbst hineinprogrammiert wurden Clemens Düpmeier,

5 Bessere Kontrolle der Parallelität?
Ein Verteiltes Objekt ist typischer Weise "Singleton" Wünschenswert sind weitere Modelle privates Sessionobjekt – i.e. ein Verteiltes Objekt pro Client Mehre Instanzen eines Objektes bedienen Clients parallel Clemens Düpmeier,

6 Von VT-Objekten zur Middleware
Zur Realisierung von VT-Systemen braucht man zusätzlich zur Kommunikation noch weitere Funktionalitäten (in Corba Common Object Services) genannt Namensdienst / Verzeichnisdients (kennen wir ja bereits) Bessere Kontrolle der Parallelität und mächtigere Sychronisation, z.B. durch Verteilte Transaktionen Security (Nutzer und Authorisierungskonzepte) Persistenzdienste Zeitdienste ... Software, die neben VT-Kommunikation weitere solcher Hilfsservices bereitstellt, nennt man Middleware Middleware bietet sowohl eine Abstraktion für die Programmierung von Funktionalitäten (Programmiermodelle und API's) als auch Infrastruktur zur Umsetzung der benötigten Dienstleistungen Clemens Düpmeier,

7 Historische Entwicklung von Middleware
Erste Middlewaresysteme ergänzten RPC um Transaktionen TP-Monitore Message Broker ergänzten RPC um asynchrone Dienste Corba-Middleware hatte bereits vollständiges Hilfsservice-Konzept Applikationsserver fassen sowohl MOM als auch Object-Broker und TP-Funktionalitäten in einer Infrastruktur zusammen Clemens Düpmeier,

8 Internet stellt weitere Anforderungen
Web als Frontend sowohl für web-basierte Oberflächen Rich Client Plattformen Kommunikation über Web über Web-Services RESTful-Services Clemens Düpmeier,

9 Duale Rolle der Middleware
Als Infrastruktur Plattform für Programmierung und als Laufzeitumgebung für komplexe, verteilte Anwendungen Bereitstellung von Basisdiensten Integrierte flexible Administrations- und Konfigurationsfunktionalitäten Trend zu Service orientierten Architekturplattformen (SOA) + Cloud-Computing Laufzeitinfrastrukturen Als Programmierabstraktion Verdecken Low-Level Details, wie Hardware, Netzwerk- und Verteilungsdetails Trend geht zu immer höher angesiedelten, mächtigen Konstrukten, die tiefere Schichten zudecken Evolution wird getrieben durch Technologieentwicklung bei Programmiersprachen und Frameworks, z.B. im Bereich von Java EJB Clemens Düpmeier,

10 Das Problem der Cross Cutting Concerns
Querschnittsorientiert Funktionalitäten (Cross Cutting Concerns) wurden früher in die Verteilten Objekte hineinprogrammiert und "verschmutzen" den eigentlichen Businesscode Dieser ist dann typischer Weise an eine spezielle Middleware Plattform gebunden und die Business-Funktionalität kann nicht ohne Kommunikationscode, etc. wiederverwendet werden => Wunsch nach Trennung der Business-Logik von den Cross Cutting Concern Funktionalitäten Clemens Düpmeier,

11 Wie kann das Problem gelöst werden?
Eine Komponenten-basierte Architektur trennt die Business-Logik weitgehend von den Cross Cutting Concerns Business-Logik wird von Anwendungsprogrammierern in einfache Klassen (Komponenten) programmiert Ein Container verwaltet die Komponenten und kümmert sich um die Concerns Zuordnung von Cross Cutting Concerns zu Komponenten kann deklarativ statt programmatorisch erfolgen auch aspektorientierte Softwarekonzepte (AOP) ermöglichen eine Trennung von Businesscode und Cross Cutting Concern Code Clemens Düpmeier,

12 Architektur eines Komponenten-Servers
Referenz anfordern Namensdienst Weitere Hilfsfkt. Client Persistenz Business Interface Lokal Bean Bean Bean Message Dienst Business Interface Remote Methodenaufruf Komponenten-Container Client verwendet an Stelle der "echten" Business-Objekte Server-generierte Artifakte Artifakte delegieren Aufrufe von außen an das Business-Bean Die Container-generierten Artifakte kümmern sich um Cross Cutting Concerns Clemens Düpmeier,

13 Welche Komponenten-Technologien gibt es?
.NET Framework enthält Mechanismen für Komponenten-orientierte Programmierung J2EE-Standard definiert Enterprise Java Beans (EJB) als Verteilte Business-Komponenten Prinzipiell hat auch der Corba-Standard ein Komponenten-basiertes Modell definiert, das aber kaum genutzt wurde / wird Clemens Düpmeier,

14 JEE als Komponenten-orientierte Middleware
Browser (Controller) Servlet(s) EJB J M S Legacy System EJB 3 J D B C (View) JSP RMI Database J N D I EJB (Model) GUI Anwend. EJB Corba Dienste Folie, die fast alle in der Vorlesung vorgestellten Methodiken unter einem Framework (J2EE = Java 2 Enterprise Edition Framework) vereint. Man sieht hier den Webserver mit Servlet Engine, der nach dem Model-View-Controller Prinzip geschriebene Web-Applikationen enthält. Diese greifen über JNDI auf Objekte in einem J2EE konformen Applikationsserver zu, der Enterprise JavaBeans Objekte enthält, die Zugriff auf Daten in Legacy Systemen und Datenbanken kapseln oder über CORBA mit anderen Anwendungen kommunizieren. Die Kommunikation mit solchen EJB Objekten erfolgt in J2EE implizit über RMI. Die Model Objekte im Webserver oder Java GUI Anwendungen kommunizieren direkt über RMI mit den jeweiligen EJB Objekten. Der Zugriff auf relationale Datenbanken erfolgt aus den EJB Objekten heraus über JDBC. Legacy Systeme binden die EJB durch Verwendung des JMS Services oder mit Hilfe der Java Connector API an. Web/HTTP Server CORBA RMI Application Server Clemens Düpmeier,

15 Querschnittsorientierte Funktionalitäten (Cross Cutting Concerns)
Beispiel: Verteilte Transaktionen Clemens Düpmeier,

16 Verteilte Transaktionen - Motivation
System rechts modelliert Verteiltes System mit zwei getrennten Serversystemen Einmal Produktdatenbank mit Anzahl verfügbarer Produkte Lagerhaltung mit realen Produkten ab Lager Änderungen (z.B. Verkauf von Produkt) müssen in beiden Systemen konsistent durchgeführt werden Client braucht Transaktionskonzept über beide Systeme hinweg Clemens Düpmeier,

17 Infrastruktur für Verteilte Transaktionen
Clemens Düpmeier,

18 Koordination von Verteilten Transaktionen
Ablauf der Transaktionen auf den Verteilten Knoten muss koordiniert werden Hierzu wird ein Koordinator bestimmt (Transaktionsmanager) bestimmt (auf einem der Server) Zum Start sendet Client ein openTransaction() an den Koordinator Dieser startet die Transaktion und gibt ihr eine eindeutige ID (TID) Der Koordinator entscheidet am Ende, ob die Verteilte Transaktion korrekt beendet werden kann oder abgebrochen werden muss Teilnehmer an der Transaktion melden sich bei ihm mit einer Art joinTransaction(Transaktions-ID, Reference auf Teilnehmer) Methode an Der Koordinator kennt damit jeden Teilnehmer Zur Koordination wird nun ein "2-Phasen-Commit-Protokoll" eingesetzt, dass erst ausgeführt wird, wenn alle Operationen auf den einzelnen Knoten bereits formuliert sind (also am Ende der Transaktion) Clemens Düpmeier,

19 2-Phasen-Commit (2PC) - Protokoll
Der Koordinator organisiert und überwacht das Protokoll Jeder transaktionale Client unterhält eigenen Transaktionslog, in dem alle relevanten Ereignisse festgehalten werden Das Protokoll besteht aus zwei Phasen Phase 1: Abstimmungsphase (1) Aufforderung zur Stimmabgabe (CanCommit request?) (2) Stimmabgabe (Yes or no) Phase 2: Abschluss und Umsetzung gemäß Abstimmungsergebnis in Phase 1 (3) Mitteilung über Entscheidung des Koordinator (doCommit / doAbort) (4) Bestätigung der erfolgreichen Durchführung der Entscheidung (acknowledge) Clemens Düpmeier,

20 2-Phase Commit Clemens Düpmeier,

21 2-Phase Commit Clemens Düpmeier,

22 2-Phase Commit Clemens Düpmeier,

23 2-Phase Commit Clemens Düpmeier,

24 2-Phase Commit Clemens Düpmeier,

25 2-Phase Commit Clemens Düpmeier,

26 2-Phase Commit Clemens Düpmeier,

27 2-Phase Commit Clemens Düpmeier,

28 JTA-Transaction Beispielcode
UserTransaction ut=context.getUserTransaction(); try { ut.begin(); updateServer1(); updateServer2(); ut.commit(); } catch (Exception e) { try { ut.rollback(); } catch (SystemException syex){ ... } } JTA = Java Transaction API API für Verteilte Transaktionen in Java Das obige Beispiel implementiert eine Bean oder User-gesteuerte Transaktion Implementierung wird über Java-Applikationsserver bereitgestellt, die den Transaktionsmanager für JTA-Transaktionen implementieren Clemens Düpmeier,

29 Container gesteuerte Transaktion
public calls MyUpdateBean { @TransactionAttritbute(TransactionAttribute.REQUIRED) public void updateServer() { updateServer1(); updateServer2(); } Container gesteuerte Transaktion bei Stateless Session-Bean Die Annotationen können auch weggelassen werden, da Default! Hier wird die komplette updateServer()-Methode in eine Verteilte Transaktion eingepackt Gutes Beispiel, wie Container "Cross Cutting Concern" Transaktionsverriegelung vom Anwendercode trennt Möglich durch Komponenten-basierten Ansatz (wie bereits erklärt) Clemens Düpmeier,

30 und zugehörige Container
Enterprise Java Beans und zugehörige Container Clemens Düpmeier,

31 Was sind Enterprise Java Beans
Objektorientierte Softwarekomponenten als Bausteine für Verteilte Anwendungen Zur Laufzeit in einem EJB Container untergebracht und von diesem verwaltet EJB's können sich gegenseitig aufrufen Oder von Clientprogrammen genutzt werden Dabei können die sich gegenseitig nutzenden Beans / Clientanwendungen über verschiedene Rechner / Container verteilt sein Clemens Düpmeier,

32 Applikation und EJB's Beans können sich gegenseitig nutzen
<< Web Applikation >> << EJB 1 >> << EJB 5 >> << EJB 6 >> << GUI Applikation >> << EJB 3 >> Beans können sich gegenseitig nutzen Manche Beans können von mehr als einer Anwendung oder einem Bean genutzt werden Clemens Düpmeier,

33 Verteilbarkeit von Beans
Container I Container II << Web Applikation >> << EJB 2 >> << EJB 4 >> << EJB 1 >> << EJB 5 >> << EJB 6 >> << GUI Applikation >> << EJB 3 >> Beans können beliebig auf Containern verteilt werden Die Benutzungsschnittstelle von Beans ist "location-transparent" Verteilung der Beans nur administrativer Vorgang Clemens Düpmeier,

34 JEE-Applikationsserver
Installations- und Laufzeitumgebung für EJB's, Servlets, ... Bietet zentrale Serverdienste Security Dienste Transaktionssemantik für Beans Session Management Parallelität (parallelen Zugriff auf Beans) Life Cycle Management von Beans Persistenzdienste / Zugriff auf Datenbanken / Connection Pooling Kommunikationsdienste Integration von Legacy Applikationen über JMS / Connector Dienste Clemens Düpmeier,

35 Elemente eines JEE-Applikationsservers
Client Container für Objekte Lookup JEE Standard Dienste und API's JNDI Namensdienst Java Native Directory (JNDI) Legacy Message System HTTP(S) SOAP/HTTP RMI / IIOP RMI / JRMP Java Message Service (JMS) Zugriff Transaktionen (JTA/JTS) Servlet Container und Webserver Web-Services (JAX-WS) Database Java-Persistence (JPA) EJB-Container REST-Services (JAX-RS) Legacy System Java Connector (JCA) Clemens Düpmeier,

36 Elemente des EJB-Containers
Concurrency Handling Transaction Handling LifeCycle Handling ... Client Instance Pooling EJB Business Interface Implementation EJB Instanz EJB Business Interface EJB EJB EJB Clemens Düpmeier,

37 Welche Formen von Beans?
EJB Anwendungen organisieren Geschäftsmodelle in Form von kooperierenden EJB's und zugehörigen Anwendungen Jede Komponente repräsentiert dabei entweder eine Entität des Geschäftsmodells oder einen Prozess des Geschäftsmodells Clemens Düpmeier,

38 Entitäten im Geschäftsmodell
Entitäten im Geschäftsmodell kapseln Informationsbausteine eines Unternehmens Sie haben einen Zustand, der von Geschäftsprozessen modifiziert werden kann Dieser Zustand ist typischer Weise persistent (in Datenbank) Entitäten sind auch ohne Geschäftsprozess für sich genommen eigenständige Objekte Entitäten können wie bei Entitäten von ER-Modellen Beziehungen untereinander haben (1-1, 1-M, M-N) Beispiele: Account, Kunde, Mitarbeiter, Konto, etc. Clemens Düpmeier,

39 Prozesse des Geschäftsmodells
Geschäftsprozesse sind Objekte, die die Interaktion eines Benutzers mit Entitäten des Geschäftsmodells kapseln Geschäftsprozesse können ebenfalls einen Zustand haben Dieser Zustand existiert aber nur für die Dauer des Prozessablaufs Der Zustand kann dabei persistent oder transient sein Zwei Formen Collaborative: Mehr als ein Benutzer am Gesamtablauf beteiligt typischer Weise persistent Conversational: Nur ein Benutzer beteiligt, typischer Weis transient Beispiele Kauf einer Ware, Durchführen einer Banktransaktion, Die meisten Web-Anwendungen kann man als Conversational Prozesse ansehen Clemens Düpmeier,

40 Welche EJB Arten gibt es?
Session Beans Dienen der Modellierung synchroner Business-Prozessaufrufe Message Beans Dienen zur Modellierung asynchroner Business-Abläufe Entity Beans Implementieren Entitäten, also Datenobjekte Clemens Düpmeier,

41 EJB Typen - Session Bean
Nutzung: Für die Implementierung von Geschäftslogik (Business-Prozessen) Typischer Weise synchrone Aufrufe, aber asynchron ab EJB 3.1 möglich Oftmals Fassade (Facade Pattern) zur Bereitstellung der internen Geschäftslogik nach außen Session Bean Objekte sind transiente, nur im Hauptspeicher befindliche Objekte d.h. sie überleben keine Systemabstürze oder Neustarts Session Beans können an Container-definierten Transaktionen teilnehmen oder selbst welche aufsetzen Session Beans gibt es in zwei Ausführungen Zustandlose (Stateless) Session Beans Zustandsbehaftete (Stateful) Session Beans Clemens Düpmeier,

42 EJB Typen - Entity Beans
Modellieren persistente Datenstruktur Gibt es in zwei Varianten: EJB 2 Entitäten sind schwergewichtige Objekte (eventuell als Remote Objekte verfügbar) EJB 3 Entitäten sind POJO Objekte (objekt-relational über die Java Persistence API auf Datenbanktabellen gemappte Objekte) Repräsentieren Datenobjekte, die persistent in Datenbank gespeichert werden Haben Lebenszeit, die evtl. unabhängig von bestimmten Business Prozess sind Viele Clients können evtl. gleichzeitig auf die gleiche Entität zugreifen Clemens Düpmeier,

43 EJB Typen - Message Beans
Werden asynchron aufgerufen, um JMS (Java Message System) Nachrichten zu verarbeiten Funktionieren ähnlich zu zustandslosen Session-Beans Anwendung: Zum Modellen von Geschäftslogik, die mit asynchroner Nachrichtenvermittlung zu tun hat Eingang einer Bestellnachricht von einem Business System bei einem anderen, z.B. Clemens Düpmeier,

44 Welche Bean Art für welchen Zweck
Entitäten von Geschäftsprozessen werden typischer Weise auf Entity Beans oder Entity Objekte (POJO's) abgebildet "Conversational" Geschäftsprozesse sind Kandidaten für Session Beans "Collaborative" Prozesse sind Mischung aus Entity Beans zur Haltung von Zustandsinformationen und Session Bean zur Abbildung des Prozesse Clemens Düpmeier,

45 Abhängige Objekte Nicht alle Klassen der Anwendung werden auf Beans abgebildet Session Beans und EJB 2 Entity Beans sind eher "schwergewichtige" Objekte Beans benutzen häufig eine Reihe von "privaten" Klassen für von Ihnen abhängige Objekte, die nicht nach außen sichtbar sein sollen Clemens Düpmeier,

46 Session-Beans Clemens Düpmeier,

47 Kommunikationsschnittstellen
Session-Beans stellen die Schnittstelle (Fassade) von Geschäftslogik nach aussen da Sie bieten Schnittstellen zur lokalen Interface) entfernten RMI-IIOP basierten Interface) oder sogar Web-Service Interface) Kommunikation mit Clients Verschiedene Session-Bean Varianten definieren dabei, welche Art der Bindung zwischen Client und Bean besteht zustandslos zustandsbehaftet (i.e. Session mit Client) Singleton-Pattern (ab EJB Clemens Düpmeier,

48 Bestandteile eines Session-Bean
Session-Bean (und andere schwergewichtige Beans) bestehen aus 3 Teilen Client Schnittstellen Interfaces beschreiben die Geschäftslogik Schnittstellen des EJB für Clients Interfaces in EJB 3.1 optional (über Annotationen der EJB-Klasse) EJB Klasse implementiert die Geschäftsmethoden und die Schnittstelleninterfaces kann weitere Hilfsklassen oder ganze Klassenbibliotheken zur Unterstützung benutzen (Optionale Konfiguration) über Deployment Deskriptor XML Konfigurationsdatei, optional zu Annotationen Kann Konfigurationsinformationen über das Bean, wie Name, Transaktionskontext, etc enthalten hat Priorität gegenüber äquivalenten Annotationen Clemens Düpmeier,

49 Beispiel für ein Session-Bean Interface
import javax.ejb.*; @Remote public interface CalculatorRemote { public double add(double a, double b); public double minus(double a, double b); } In EJB 3 wird Typ des Interfaces durch Annotation deklariert @Remote für entferntes Interface @Local (= Default) für lokales Interface Man beachte, dass das Remote Interface weder von Remote (RMI) ableitet, noch RemoteException implementieren muss – Nur die Container generierten Artifakte tun dies Clemens Düpmeier,

50 Beispiel für die Implementierungsklasse
import javax.ejb.*; @Stateless public class Calculator implements CalculatorRemote { public double add(double a, double b) { return a + b; } public double minus(double a, double b) { return a – b; } } In EJB 3 wird Typ des Beans durch Annotation bestimmt @Stateless für zustandsloses Session Bean @Statefull für zustandsbehaftete Session Beans Man beachte, dass Implementierungsklasse weder von UnicastRemoteObject noch PortableRemoteObject ableitet, obwohl das Bean eine entfernte Schnittstelle bereitstellt Clemens Düpmeier,

51 Interaktion Client mit Session-Bean
Applikationsserver Referenz anfordern Namensdienst Weitere Hilfsfkt. Client Persistenz Business Interface Lokal Bean Bean Bean Message Dienst Business Interface Remote Methodenaufruf Komponenten-Container Client verwendet an Stelle der "echten" Business-Objekte Server-generierte Artifakte Die Artifakte implementieren die definierten Interfaces, z.B. das "Entfernte Interface" Artifakte delegieren Aufrufe von außen an das Business-Bean Artifakte kümmern sich um Cross Cutting Concerns Clemens Düpmeier,

52 Interaktion Client mit Session-Bean (2)
Applikationsserver Transaktions-Service Client Ergebnis startet Transaktion 6 5 beendet Transaktion 2 foo() foo() Stellvertreter- Objekt 3 EJB-Instanz 1 4 return EJB-Container Client verbindet sich anstatt mit den EJB-Instanzen mit Server-seitigen Stellvertreter-Objekten und ruft hier Methode auf (1), (6) Stellvertreter-Objekte verwenden Hilfsservices für die Implementierung von Cross Cutting Concerns (hier Transaktionen (2), (5)) Und delegieren Methodenaufrufe an EJB-Instanz(en) (3), (4) Clemens Düpmeier,

53 Zustandslose (Stateless) Session-Beans
realisieren zustandslose Business-Methoden, d.h. Verbindung Client zu Bean existiert genau für die Dauer eines Methodenaufrufs Bean merkt sich keine Zustandsinformationen zum Client über die Dauer eines Methodenaufrufs hinaus Zustand der Bean vor und nach einem Methodenaufruf sind gleich Die Reihenfolge, in der Methoden aufgerufen werden, ist aus Sicht des Bean irrelevant D.h. nicht, dass ein Stateless Bean keinen Zustand haben kann aber dieser Zustand ist unabhängig vom Client z.B. kann eine Stateless Bean eine Datenbankverbindung halten Clemens Düpmeier,

54 Instanz-Pooling und Stateless Session-Beans
Eine Verbindung zwischen Stateless Session Bean und Client besteht nur für die Dauer eines Methodenaufrufs Container erzeugt für ein Session-Bean in der Regel einen Pool äquivalenter Instanzen Instanzen können bei Bedarf neu erzeugt oder vernichtet werden (kein persistenter Zustand!) - Resourcemanagement Server entscheidet, welche Instanz für einen Methodenaufruf verwendet wird Clients sind nur an spezifische Instanzen für die Dauer eines Methodenaufrufs gebunden Clemens Düpmeier,

55 Lebenszyklus einer Stateless Session-Bean
Beaninstanzen werden bei Bedarf erzeugt und in Instanzen-Pool abgelegt Dann zur Bearbeitung ein oder mehrerer Client-Geschäftsmethodenaufrufe verwendet Container kann Bean jederzeit wieder vernichten Programmierer interagiert mit Lebenszyklus über annotierte Methoden in der Beanklasse @PostConstruct @PreDestroy @Timeout does not exist newInstance() Dependency Injection @PostConstruct @PreDestroy method-ready pool Aufruf Geschäftsmethode @Timeout Clemens Düpmeier,

56 Interaktion mit Lebenszyklus
import javax.ejb.*; @Stateless public class Calculator implements CalculatorRemote { @PostConstruct public void onPostConstruct() { // OK, initialize needed resources } @PreDestroy public void onPreDestroy() { // OK, let's destroy our resources } ... } @PostConstruct annotierte Methoden werden von Container nach Initialisierung und Dependency Injection der Bean aufgerufen @PreDestroy annotierte Methoden vor der Vernichtung der Bean Clemens Düpmeier,

57 Transaktionen und Stateless Session-Beans
Container-verwaltete Transaktionen auf Session-Beans sofern nicht anders definiert umfassen genau einen Methodenaufruf Client kann allerdings sebst einen Transaktionskontext definieren, der über verschiedene Methodenaufrufe einer Stateless Session-Bean hinausgeht Clemens Düpmeier,

58 Deklarative Transaktionalität
Transaktionsattribut-Wert Bedeutung NotSupported Transaktion wird von Methode nicht unterstützt Supports Transaktion wird von Methode unterstützt Required (Default) Methode verlangt Transaktion RequiresNew Methode verlangt sogar eine eigene, neue Transaktion – läuft nicht im Kontext einer ander Transaktion Mandatory Eine bestehende Transaktion ist erforderlich Never Es darf keine Transaktion bereits bestehen Clemens Düpmeier,

59 Setzen des Transaktionsattributes
import javax.ejb.*; @Stateless public class AuskunftBean { @TransactionAttribute(TransactionAttributeTyp.NOT_SUPPORTED) public List<Konzert> sucheKonzerte(String ortsName, Date date) { } } Ohne Setzen des TransactionAttributes führt der Container standardmäßig bei Stateless-Beans die Transaktionsbehandlungsform "Required" d.h. er wrappt selbst automatisch die Methode in eine Transaktion, wenn der Client nicht bereits eine aufgesetzt hat Möchte man das nicht, kann man das Attribut auf einen anderen Wert setzen Im obigen Beispiel deutet die Methodenimplementierung an, dass sie Transaktionen nicht unterstützt (d.h. die Transaktion – falls vorhanden – wird während des Aufrufs der Methode ausgesetzt Clemens Düpmeier,

60 Zustandsbehaftete (Stateful) Session-Beans
Halten im Gegensatz zu Stateless-Beans einen Client-spezifischen Zustand (Conversational State, dialogbezogener Zustand) und definieren damit eine private Session mit einem einzigen Client mehr als ein Methodenaufruf eines Clients erfolgt in der Regel auf der gleichen Beaninstanz Ein- und die gleiche Beaninstanz bedient zu einer Zeit nur genau einen Client maximal Bean-Instanzen können allerdings passiviert und wieder aktiviert werden Clemens Düpmeier,

61 Stateful Bean und Conversational State
import javax.ejb.*; @Stateful public class OrderBean implements Order { private ShoppingCard basket; public void addProductToShoppingCard(Product p) { basket.add(p); } public pay() { ... } } Stateful Session-Beans deklariert man mit der an der Bean-Klasse Interne Variablen, wie der Warenkorb im Beispiel, existieren mit ihrem Zustand für die Dauer der Session des Clients mit der ihm zugeordneten Bean-Instanz (Conversational State) Achtung: Der Conversational State ist nicht notwendig persistent über die Laufdauer der Session hinweg Clemens Düpmeier,

62 Aktivierung und Passivierung
Ist der Conversational State einer Stateful Session Bean groß kann der Hauptspeicherverbrauch bei einer großen Anzahl potentieller Clients sehr groß sein Zum Resourcenmanagement unterstützen Stateful Session-Beans daher Aktivierung und Passivierung Bei der Passivierung wird der Conversational State einer Stateful Bean mit einem Client auf Sekundärspeicher gesichert und die Instanz dann vernichtet oder freigegeben (für andere Clients) Bei der Aktivierung wird in eine frische oder freigegebene Instanz der Conversation State einer vorherigen Session mit einem Client wieder reingeladen und damit die Session mit diesem Client reaktiviert Prinzipiell kann jede Stateful Session Bean, die an keiner aktiven Transaktion teilnimmt, passiviert werden Ob und wie entscheidet der Container (z.B. nach einem Least Recently Used Algorithmus) Clemens Düpmeier,

63 Lebenszyklus von Stateful Beans
does not exist method-ready passive method-ready in TX newInstance() Dependency Injection @PostConstruct afterBegin() afterCompletion(false) beforeCompletion() afterCompletion(true) Transaktionale Methode Transaktionale Methode Commit Rollback @PreDestroy @Remove-Methode oder zu lange inaktiv zu lange inaktiv @PrePassivate "Least recently used" erneuter Methodenaufruf @PostActivate nicht-transaktionale Methode Mit entsprechend annotierten Methoden kann das Bean an Zustandsänderungen teilnehmen Beans in Transaktion können nicht passiviert werden! Bean kann durch Implementierung eines Interfaces am Ablauf einer Transaktion teilnehmen (afterBegin(), ...) Clemens Düpmeier,

64 Stateful Session-Beans und Transaktionen
Auch Methoden einer Stateful Session-Bean können transaktional sein Im Gegensatz zu Stateless Beans können mehrere Methodenaufrufe an einer Transaktion teilnehmen d.h. sie laufen im gleichen Transaktionskontext in einem Session-basierten Transaktionskontext Der Zustand von an der Transaktion beteiligten Resourcen, z.B. Datenbankverbindungen, wird bei Abbruch der Transaktion automatisch zurückgesetzt Dies gilt nicht für den Conservational State der Bean selbst Diesen muss man selbst manuell – falls notwendig - zurücksetzen Clemens Düpmeier,

65 Synchronisation des Conversational State
package javax.ejb; public interface SessionSynchronization { void afterBegin() throws EJBException, RemoteException; void afterCompletion(boolean committed) throws EJBException, RemoteException; void beforeCompletion() throws EJBException, RemoteException; } Eine Bean kann das SessionSynchronization Interface implementieren Der Container ruft die darin befindlichen Methoden im Rahmen der Änderung von Transaktionszuständen auf Wozu ist das gut? Die Bean kann hiermit ihren eigenen Conversational State mit dem persistenten Zustandsänderungen im Rahmen der Transaktion koordinieren Clemens Düpmeier,

66 Vergleich der Session-Bean Varianten
Stateless Stateful Verwendung Einfache Services oder zustandslose Prozesse Zustandsbehaftete Geschäftsprozesse, die sich über mehrere Methodenaufrufe erstrecken Clientbindung Bindung nur für die Dauer eines Methodenaufrufs Für die Dauer des gesamten Geschäftsprozesses Optimierung der Resourcen Instanz-Pooling (Parallelität, Performance) Aktivierung / Passivierung (Hauptspeicher) Transaktionen Umfassen einen Methodenaufruf oder werden vom Client gesteuert Können mehrere Methoden umfassen (Session-Kontext) Web-Service Als Web-Services veröffentlichbar Nein Clemens Düpmeier,

67 Zugriff von Clients auf EJB's
Clemens Düpmeier,

68 Clientzugriff auf EJB's
Hier sind mehrere Fälle zu unterscheiden Zugriff auf lokale Beans innerhalb des gleichen Containers bzw. Zugriff auf entfernte Beans innerhalb eines entfernten Containers JNDI-Lookup oder Dependency Injection möglich Zugriff von extern und außerhalb eines Containers (J2SE) Über JNDI-Lookup Clemens Düpmeier,

69 Dependency Injection (DI)
Anwendung des "Inversion of Control (IoC) Prinzips Hollywood-Prinzip: "Don't call us, we call you" Nicht Anwendungscode, sondern ein umgebendes Framework sollte sich darum kümmern, dass Resourcen oder Services innerhalb von Anwendungen verfügbar sind Der Container instanziiert und verwaltet Resource- und Serviceobjekte und injiziert Referenzen auf diese in den Anwendungscode an durch den Anwendungsprogrammierer vorgegebene Stellen z.B. in speziell annotierte Variablen oder in Konstruktoren oder setter-Methoden Clemens Düpmeier,

70 Dependeny Injection public class CalculatorUser { @EJB CalculatorRemote calculator; void useCalculator() { System.out.println("2 + 5 =" + calculator.add(205)) } // oder setter injection public class CalculatorUser { private CalculatorRemote myCalculator; @EJB void setCalculator(CalculatorRemote calculator) { myCalculator=calculator; } } In EJB funktioniert Injektion in Variablen und über Argumente von Settern Clemens Düpmeier,

71 Dependeny Injection mit Resourcen
@Resource(name = "myDB") public void setDataSource(DataSource myDB) { customerDB = myDB; } // oder z.B. für den EJBSessionContext @Resource javax.ejb.SessionContext sc; ... TimerService ts = sc.getTimerService(); Dependeny Injection funktioniert auch mit Resourcen, wie DataSource Objekten, i.e. Datenbank-Zugängen SessionContext-Objekten = gibt Objekt zum Zugriff auf EJB-Laufzeitumgebung (SessionContext) zurück Ebenfalls zum Zugriff auf Entity-Beans, siehe später Injektion eines EntityManagers Clemens Düpmeier,

72 Externen EJB Client programmieren
Konfiguration des JNDI (Java Native Directory Interface) Zugriffs auf Nameserver, der EJB Container Namensdienst ist Hier sind Properties, wie Zugriffsklasse, Servername, Portnummer, etc. des Nameservers zu setzen (produktabhängig) Mit new InitialContext(properties) bekommt man dann Referenz auf Namensdienst Holen eines Proxy Objektes auf das EJB über den Namensdienst Context.lookup(….) Evtl. Casten auf Interface Arbeiten mit dem EJB über die Proxyobjektreferenz Man benötigt zum Compilieren und zur Laufzeit die zum Server passenden Client Jar Dateien Clemens Düpmeier,

73 Beispiel Clientsourcecode – Teil1
public static Context getInitialContext() throws javax.naming.NamingException { Properties p = new Properties(); p.put(Context.INITIAL_CONTEXT_FACTORY, „org.jnp.Interfaces.NamingContextFactory“); p.put(Context.URL_PKG_PREFIXES, „org.jboss.naming:org.jnp.Interfaces“); p.put(Context.PROVIDER_URL,“jnp://localhost:1099“); return new InitialContext(properties); } OK, hier beispielhaft Konfiguration der Namensdienstattribute für einen JBOSS Server Dies ist halt abhängig vom jeweiligen Server Clemens Düpmeier,

74 Beispiel Clientsourcecode – Teil 2
Context jndiContext = getInitialContext(); Object ref=jndiContext.lookup("Calculator/remote"); CalculatorRemote rechner=(CalculatorRemote)PortableRemoteObject.narrow(ref, CalculatorRemote.class); System.out.println("2 + 5 =" + rechner.add(2, 5)); Also Context initialisieren (Teil 1) Lookup des Proxy bei Namensdienst Casten (weil Proxy Corba Object) Und dann mit Proxy arbeiten Clemens Düpmeier,

75 JNDI-Lookup ab EJB 3 Also Context initialisieren (Teil 1)
Context ic = getInitialContext(); CalculatorRemote calculator =(CalculatorRemote)ic.lookup("Calculator/remote"); System.out.println("2 + 5 =" + rechner.add(2, 5)); Also Context initialisieren (Teil 1) Lookup des Proxy bei Namensdienst und direktes Casten in Interface Kein PortableRemoteObject.narrow(...) mehr Und dann mit Proxy arbeiten Clemens Düpmeier,

76 JPA – Java Persistence API
Entity Beans JPA – Java Persistence API Clemens Düpmeier,

77 Java Persistence API (JPA)
Standardisierte ORM API Entities sind POJO‘s „Pluggable“ Persistence Engine (Persistenz Provider) Entstanden aus „besten Teilen“ von TopLink, JDO und Hibernate mit Expertise der EJB Hersteller Standardisiert als Teil von EJB 3 Enthalten in JEE 5, kann auch in JSE genutzt werden Zahlreiche Implementierungen, u.a. natürlich in Referenz Implementierung (Name: „TopLink Essentials“) Kommerzielle TopLink Version Hibernate BEA Kodo, Apache OpenJPA, … Clemens Düpmeier,

78 Anatomie eines JPA Entities
Abstrakte oder konkrete Top Level Java Klasse Nicht-final Felder / Objekteigenschaften Argumentloser Konstruktor Benötigt keine Interfaces Interfaces nicht zwingend Interfaces aber für Callback Funktionalität des Container nutzbar Direkter Feld oder Eigenschafts-basierter Zugriff Über Getter / Setter Kann (muss aber nicht) serialisierbar sein Damit übertragbar in Remote Calls Clemens Düpmeier,

79 Minimale Entität Entity Klasse muss als Entity markiert sein public class Person { … } Über Metadateneintrag in XML Mapping Datei <entity class="myPackage.Person" /> Clemens Düpmeier,

80 Minimale Entität Jede Entität braucht eindeutigen Identifier @Entity public class Person { @Id Long id; public Long getId { return id; } public void setId(Long id) { this.id = id; } String firstName; public String getFirstName { return firstName; } public void setFirstName(String name) { firstName=name; } } Clemens Düpmeier,

81 Identität von persistenten Entities
Eindeutiger Identifier in Entity Klasse => abgebildet auf Primärschlüssel in Datenbank Identifiziert persistentes Datenbank Objekt eindeutig in Hauptspeicher und Datenbank Einfache Id – Einzelnes Objektattribut @Id int id; Zusammengesetztes Attribut @Id int id; @Id String name Eingebettete Id – einzelnes Feld von PK Klassentyp @EmbeddedId PersonPK id; Eigene PK Klasse Clemens Düpmeier,

82 Persistenz Kontext Abstraktion, die eine Menge von "verwalteten" (managed) Entitäten repräsentiert Entitäten sind im Persistenz Kontext eindeutig durch ID identifizierbar Genau eine Instanz mit einer eindeutigen Identität befindet sich in einem Persistenz Kontext Ein Persistenz Kontext wird verwaltet von einem EntityManager (Teil der Persistenz Maschinerie) Der Inhalt des Persistenz Kontext ändert sich als Resultat von Operationen auf dem EntityManager über dessen API Clemens Düpmeier,

83 Entity-Manager und Persistenz-Kontext
Persistenz-Kontext definiert "Cache" von verwalteten (Managed) Entity-Instanzen Nicht alle Entities sind verwaltet Nicht-verwaltete Entities nennt man "Detached" EntityManager em= MyEntity e1=(MyEntity)em.find(...); Entity Manager Persistenz-Kontext Entity 1 Entity 2 Entity 3 Clemens Düpmeier,

84 Entity Manager Sichtbare Schnittstelle der Clientanwendung zum Persistenz Provider Bietet Schnittstelle zur API mit allen Basis Persistenz Operationen Kann man sich als Proxy Objekt zum Zugriff auf einen Persistenz Kontext vorstellen Innerhalb eines Lebenszyklus Zugriff auf verschiedene Persistenz Kontexte möglich Clemens Düpmeier,

85 Typen von Entity-Managern, Scope des Persistenz-Kontext
Frage: Wie lange werden Entitäten als "Managed" verwaltet bzw. wie lange existiert ein Persistenz-Kontext? Applikations-verwaltete Entity-Manager bei diesen Entity-Managern bestimmt die Applikation selbst, wie lange Entities in einem Persistenz-Kontext verwaltet werden Container-Managed Entity-Manager Transaction-Scope (Standard) Verwaltungslebensdauer der Entitäten = eine Transaktion im Container Extended-Scope Laufzeit des Persistenz-Kontext an die Lebenszeit des Kontext eines Session-Bean gebunden Clemens Düpmeier,

86 Transaction-Scope Persistenz-Kontext
Default in Containern Entity-Manager wird vom Container verwaltet und direkt injiziert (siehe später) Alle Entitäten, auf denen während einer Transaktion gearbeitet wird, gehören typischer Weise zum Persistenz-Kontext Wenn Transaktion beendet wird, werden die Entities "detached" (verlieren also ihren Bezug zum Persistenz-Kontext) Der selbe Persistenz-Kontext wird zu allen Beans, die an der gleichen Transaktion beteiligt sind, propagiert Clemens Düpmeier,

87 Extended-Scope Persistenz-Kontext
Managed-Entities existieren über verschiedene Transaktionen hinweg Explizite Unterstützung für länger andauernde Operationen, evtl. über mehrere Clientzugriffe hinweg Anzahl der Managed-Objekte kann rasch wachsen In Containern ist Lebenszeit eines Extended-Scope Persistenz-Kontext an Lebenszeit eines zugehörigen Session-Beans gekoppelt Kann durch Schließen des Kontexts (close() Methode des Entity-Managers explizit aufgeräumt werden Clemens Düpmeier,

88 Lebenszyklus von Entitäten
Neu angelegte Entities sind transient persist() Operation bringt sie in den Zustand "Managed" Verschiedene Operationen können Entity in den Zustand "Detached" bringen merge() bringt Entität zurück in den Zustand "Managed" Clemens Düpmeier,

89 Wie komme ich zu einem Entity Manager
private EntityManagerFactory emf = Persistence.createEntityManagerFactory("LecturePU"); private EntityManager em = emf.createEntityManager(); Eine statische Methode der Persistence Klasse erzeugt eine Factory für EntityManager zu einer bestimmten Persistenz Engine die Persistenz Engine ist oben über den Namen "LecturePU" bezeichnt Innerhalb der persistence.xml Konfigurationsdatei wird die Persistenz Engine mit Namen "LecturePU" genauer definiert Einen EntityManager bekomme ich von der Factory durch Aufruf der Methode createEntityManager Clemens Düpmeier,

90 persistence.xml - definiert Persistenz Engine "LecturePU"
<?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns=" xmlns:xsi=" xsi:schemaLocation=" <persistence-unit name="LecturePU" transaction-type="RESOURCE_LOCAL"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <class>model.Person</class> <class>model.Dozent</class> <properties> <property name="hibernate.connection.username" value="root"/> <property name="hibernate.connection.driver_class" value="com.mysql.jdbc.Driver"/> <property name="hibernate.connection.password" value=""/> <property name="hibernate.connection.url" value="jdbc:mysql://localhost/Vorlesungen"/> <property name="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider"/> <property name="hibernate.hbm2ddl.auto" value="update"/> </properties> </persistence-unit> </persistence> Clemens Düpmeier,

91 Durch Injektion @PersistenceContext private EntityManager em; // hier weiterer Code @PersistenceContext injiziert EntityManager Instanz in die Variable em Wir durch Laufzeitcode ersetzt, der die Variable em instanziiert Injektion funktioniert in EJB 3 auch für andere Objektarten (EJB‘s, Ressourcen, etc.) Clemens Düpmeier,

92 Entity-Manager und Transaktionen
JPA unterstützt zwei Arten von Transaktionen JTA (Java Transaction API)-Transaktionen typischer Weise in Containern können Transaktionen über verschiedene Datenquellen zusammenfassen unterstützen verschiedene Scopes (Typen) von Entity-Manager Instanzen Resource-Local Transaktionen Transaktionen, die direkt auf JDBC-Transaktionen abgebildet sind unabhängig von irgendwelchen JTA-Transaktionen typischer Weise in Applikationen, die Container-basierte Transaktionen nicht unterstützen (Standalone-Applikation, reine Web-Applikation) Clemens Düpmeier,

93 EntityManager und Transaktionen
public class PersonDAO { private EntityManagerFactory emf= Persistence.createEntityManagerFactory("LecturePU"); private EntityManager em = emf.createEntityManager(); public PersonDAO() { } public void persist(Object object) { try { em.getTransaction().begin(); em.persist(object); em.getTransaction().commit(); } catch(Exception e) { Logger.getLogger(getClass().getName()).log(Level.SEVERE,"exception caught", e); em.getTransaction().rollback(); } finally { em.close(); } EntityManager erhält man über Factory em.persist() sichert das Objekt in der Datenbank Man beachte die Verwendung der Transaktion Clemens Düpmeier,

94 Grundlegende Methoden des Entity Manager
persist() – Sichern des Zustands eines Entities auf die Datenbank remove() – Entfernen eines Entities aus der Datenbank refresh() – Update des Entity Zustandes aus der Datenbank merge() – Synchronisation des Zustandes eines "detached" (abgehängten) Entities mit dem Datenbankzustand find() – Finden eines Datenbank Entities über PK createQuery() – Dynamische Datenbankabfrage über JP QL createNamedQuery() – Instanz einer vordefinierten Abfrage generieren createNativeQuery() – Native Datenbankabfrage contains() – Feststellenn, ob Entity in Datenbank existiert flush() – Synchronisation des Persistenz Kontextes mit der Datenbank Clemens Düpmeier,

95 Die Method persist() fügt neue Entity Instanz in Datenbank ein
sichert persistenten Zustand einer Entität und jeden von dieser Entität aus erreichbare "Unterentität" (closure) Nicht verwaltete Entitäten werden hierzu zu verwalteten Entitäten public Person createPerson(int id, String firstName, String lastName) { Person person = new Person(id, firstName, lastName); entityManager.persist(person); return person; } Clemens Düpmeier,

96 Methoden find() und remove()
Abfrage einer über Primärschlüssel eindeutig identifizierten Entität remove() Löschen einer über Primärschlüssel eindeutig identifizierten Identität public void removePerson(int id) { Person person = entityManager.find(Person.class,id); entityManager.remove(person); } Clemens Düpmeier,

97 Abfragen Dynamisch oder statisch (Named Queries) definierbar
Objektorientierte SQL Schnittstelle basierend auf JP QL (HQL, EJB QL) Unterstützung für native SQL Abfragen Benannte Parameter, die zur Laufzeit gebunden werden (Prepared Statements) Navigation über Ergebnisse in Form von "Seiten" Einzelobjekte oder Objektmengen als Ergebnis der Anfrage Batch Update und Delete Operationen Hersteller-spezifische Hinweise, wie die Query ausgeführt werden soll Clemens Düpmeier,

98 Query API Query Instanzen erhält man über die bereits vorgestellten Factory Methoden des Entity Managers Auf Query Instanzen folgende API anwendbar getResultList() - Rückgabe eine Liste von Resultaten getSingleResult() – Rückgabe eines einzigen Resultats executeUpdate() – Batch Update oder Delete Operationen setFirstResult() – Nr. des ersten Rückgabeobjektes setMaxResults() – Maximale Zahl der zurückzugebenden Resultate setParameter() – Angabe eines benannten (positionellen) Parameters setHint() – Angabe eines Hersteller-spezifischen Hinweises für die Abfrage Clemens Düpmeier,

99 Dynamische Abfragen createQuery() Methode des Entity Managers verwenden und JP QL String übergeben Auf zurückgegebenes Query Objekt korrekte Methode zur Ausführung der Query anwenden getResultList(), getSingleResult(), executeUpdate() Abfrage kann bei Erzeugung oder bei Ausführung vorübersetzt und geprüft werden Maximale Flexibilität für Abfragedefinition und Ausführung Clemens Düpmeier,

100 Beispiel: Dynamische Query
public List findAll(String entityName) { return em.createQuery( "select e from " + entityName + " e") .setMaxResults(100) .getResultList(); } Gibt alle Instanzen eines gegebenen Entitätentyps zurück Man beachte, dass Variable entityName wie Objekttyp verwendet wird e in select Klausel steht also für Objekt vom Typ "entityName" Bsp.: "select e from Person e", falls entityName="Person" Clemens Düpmeier,

101 Mapping mit JPA Mapping Metadaten können in XML Dateien oder als Annotation spezifiziert werden Spezifikation des logischen Modells Spezifikation der Abbildung auf Tabellen und Spalten, etc. XML Dateien können weitere Dinge, wie Defaults, benannte Queries, Hersteller-spezifische Dinge enthalten Standard Regeln reduzieren Abbildungspflicht auf das Minimum Clemens Düpmeier,

102 Einfache Mapping Regeln
Jede Objekteigenschaft einer markierten Klasse wird auf eine Spalte abgebildet kann gegebenenfalls ein anderer Spaltenname festgelegt werden Standard Java Typen werden automatisch auf entsprechende Datenbanktypen abgedildet Manchmal möchte man den Typ genauer spezifizieren, z.B. die Länge eines Jeder Default kann auch überschrieben werden Clemens Düpmeier,

103 Beispiel für einfache Mapping Regeln
@Entity public class Person { @Id Long id; @Column(length=100) String firstName; String lastName; @Lob Image photo } ID FIRSTNAME LASTNAME PHOTO Einfaches Mapping der Entity Person Clemens Düpmeier,

104 Einfaches Mapping mit XML Datei
<entity class="myPackages.Person"> <attributes> <id name="id"/> <basic name="firstName"> <column length="100"> </basic> <basic name="lastName"/> <basic name="photo"><lob/></basic> </attributes> </entity> Mapping der Person Klasse über gesonderte XML Datei Clemens Düpmeier,

105 Mapping von Beziehungen
Unterstützung für das Mapping der gängigen Beziehungen - ein Entity - mehrere Entities unidirektional oder bidirektional birektionale Beziehungen haben beim Mapping eine Eigentümerseite und eine inverse Mapping Seite Die Eigentümerseite spezifiziert das physikalische Mapping (= Abbildung auf Tabellen) @JoinColumn Attribut definiert den Fremdschlüssel Clemens Düpmeier,

106 Beispiel: @ManyToOne, @OneToMany
@Entity public class Student { @Id Long id; String shortName; String longName; @ManyToOne Course course; } public class Course { @OneToMany(mappedBy = "course") public Set<Student> students=new HashSet<Student>(); } Course ID shortName longName Student ID matrikelNr course Clemens Düpmeier,

107 Achtung: Bidirektionalität
@Entity public class Student { …. @ManyToOne Course course; public setCourse(Course course){ course.addStudent(this); this.course=course; } } public class Course { @OneToMany(mappedBy = "course") public Set<Student> students=new HashSet<Student>(); public addStudent(Student student) { student.setCourse(this); students.add(student); } } Course ID shortName longName Student ID matrikelNr course Clemens Düpmeier,

108 Beispiel: @ManyToMany
Dozent @Entity public class Dozent { @Id long id; private String dozentId; @ManyToMany Set<Lecture> lectures= new HashSet<Lecture>(); } public class Lecture { @ManyToMany(mappedBy = "lectures") public Set<Dozent> dozents=new HashSet<Dozent>(); } ID dozentId dozent_id lecture_id Lecture ID lectureName description Clemens Düpmeier,

109 Beispiel: Komponenten - Komposition
@Entity public class Address { @Id int id; String street; String town; … } public class Person { String firstName; String lastName; @OneToOne(cascade = CascadeType.ALL) Address homeAddress; } Address ID street town zipCode Person ID firstName lastName homeAddress Clemens Düpmeier,

110 Beispiel: Komponenten - Komposition
@Embeddable public class Address { // Kein Schlüssel String street; String town; … } public class Person { String firstName; String lastName; @Embedded Address homeAddress; } Person ID firstName lastName street town zipCode In diesem Fall hat die Komponente keine eigene Tabelle Clemens Düpmeier,

111 Bsp.: Entwicklung eines JPA Entity Beans
1. Schritt Erzeugen einer Entity Klasse Festlegung des Persistenz-Providers (evtl. vorher Konfiguration Datenbank, Treiber, etc) Weitergehende Konfiguration über Annotation und/oder Konfigurationsdateien Oft nicht nötig, da Defaults ausreichen Clemens Düpmeier,

112 Beispiel Entity-Bean @Entity
import javax.persistence.*; @Entity public class Address implements Serializable { @Id private Long id; private String surname; private String nickname; … // Hier getter und setter Methoden zu Feldern // Hash und Equals Methoden für Bean } Clemens Düpmeier,

113 Asynchrone Nachrichten-basierte Kommunikation
Message Driven Beans Asynchrone Nachrichten-basierte Kommunikation Clemens Düpmeier,

114 Message Driven Beans Ermöglichen Clients asynchrone Kommunikation mit EJB's Kommunikation erfolgt indirekt über das Senden / Empfangen von Nachrichten Die Nachrichten werden von geeigneten Transporteinheiten transportiert Message Oriented Middleware (MOM) z.B. Java Message Service (JMS) ab EJB 2.1 auch ander MOM an Stelle von JMS integrierbar EJB-Container leiten dann empfangene Nachrichten an Message Drive Beans zur Bearbeitung weiter Client und Bean sind bei dieser Kommunikationsart vollständig voneinander entkoppelt Clemens Düpmeier,

115 Nachrichten-basierte Kommunikation
Client Server Empfänger Sender Message Broker Client arbeitet weiter Bearbeitung Clemens Düpmeier,

116 Nachrichten und Message Broker
Zentraler Bestandteil einer MOM ist der Message Broker Komponente zum Transport und Zwischenspeicherung von Nachrichten Die Zwischenspeicherung erfolgt in Nachrichten-Warteschlangen Der Message Broker leitet die Nachrichten dann an die Empfänger weiter Empfänger müssen sich dazu bei einem Message Broker registrieren Messages (Nachrichten) können beliebige Form haben Inhalt kann ein beliebiges Objekt sein Bedeutung der Message kann Anfrage, Meldung oder Ereignis, oder sonst was sein Clemens Düpmeier,

117 Vorteile von Nachrichten-basierter Komm.
Die bereits erwähnte "lose Koppelung" trennt Sender und Empfänger vollständig voneinander kann die Performance durch Asynchronität erhöhen Erhöht die Zuverlässigkeit, da Empfänger auch dann die Nachricht bekommen, wenn sie im Augenblick des Sendens nicht empfangsbereit sind ermöglicht das einfache Versenden von Nachrichten an mehrere Empfänger / Bearbeiter Clemens Düpmeier,

118 Zwei Kommunikationsmodelle
Zwei Typen von Nachrichtenwarteschlangen (Destinations) als Ziel von Nachrichten Queues repräsentieren das Point-to-Point Kommunikationsmodell (evtl. mehrere Sender aber ein Empfänger) Topics arbeiten nach dem Publish-Subscribe Prinzip (mehrere Publisher – mehrere Receiver) Clemens Düpmeier,

119 Point-to-Point Kommunikation
Message Broker Sender 1 Empfänger Sender 2 Queue Ein oder mehrere Sender stellen Nachrichten in einer Message-Warteschlange (Queue) ein Der Message Broker leitet jede Message an genau einen registrierten Message-Empfänger weiter Allerdings können sich mehrere Empfänger an der gleiche Queue registrieren Der Message Broker entscheidet dann selbstständig, an welchen Empfänger er welche Message weiterleitet Clemens Düpmeier,

120 Publish-Subscribe Modell
Message Broker Topic Empfänger 1 Sender 1 Sender 2 Empfänger 2 Ein oder mehrere Sender stellen Nachrichten in einer Topic-Warteschlange (Topic) ein Der Message Broker leitet jede Message an alle Subscriber von diesem Topic weiter Empfänger können sich für mehr als ein Topic im Message Broker registrieren Clemens Düpmeier,

121 JMS (Java Message Service)
Standard für Nachrichten-basierte Kommunikation in Java Application Programming Interface (API) Service Provider Interface (SPI) Clients nutzen die JMS-API, um Nachrichten zu senden oder sich für den Empfang zu registrieren, etc. Ein Message Broker Implementierer implementiert die SPI ähnlich einem JDBC-Treiber, um JMS-Nachrichtenkomm. über seine Infrastruktur zu ermöglichen (JMS-Provider) Vorteil: Mehr als ein Provider kann so über eine standardisierte API genutzt werden Clemens Düpmeier,

122 QueueConnectionFactory TopicConnectionFactory
JMS-API QueueConnectionFactory TopicConnectionFactory createQueueConnection() createTopicConnection() QueueConnection Message TopicConnection createQueueSession() createTopicSession() QueueSession TopicSession create() create() createSender() createReceiver() createPublisher() createSubscriber() QueueSender QueueReceiver TopicPublisher TopicSubscriber send() publish() onMessage() onMessage() Queue Topic Message Broker Topic Message Broker Topic Point-to-Point Publish-Subscribe Clemens Düpmeier,

123 MOM, JMS und J2EE-Applikationsserver
JMS ist Bestandteil der J2EE-Spezifikation Jeder J2EE-konforme Applikationsserver muss JMS als Provider implementieren und die JMS-API bereitstellen Message Beans werden vom EJB-Container als JMS-Nachrichtenempfänger registriert Sie sind daher Empfänger von JMS-basierten Nachrichten Das Bean muss dazu nicht die JMS-API nutzen, sondern die Message Bean Schnittstelle nutzen Clemens Düpmeier,

124 J2EE-Applikationserver
fordert Referenz auf Destination an JNDI registriert Destinations Naming Service 3 1 Client sendet JMS-Nachricht an Destination JMS-Provider 4 5 Client sendet Messages nicht direkt an Bean, sondern an Message Provider EJB-Container registriert sich selbst als Empfänger Und leitet dann die Messages an Bean weiter 2 übermittelt Nachricht an Empfänger registriert sich als Receiver für Destinations leitet sie an Bean weiter EJB-Container 6 Bean Instanz ? erzeugt Bean Instanzen Clemens Düpmeier,

125 Eigenschaften von Message Driven Beans
Sie bestehen nur aus aus annotierter Implementierungsklasse und Deploymentdeskriptor-Eintrag Keine Interfaces, da nicht direkt durch Client adressierbar Implementieren Methoden eines Listener Interfaces (z.B. MessageListener), die zum Message-Empfang vom Container aufgerufen werden Clemens Düpmeier,

126 Eigenschaften von Message Driven Beans (2)
Ansonsten vergleichbar mit Stateless Session Bean Container verwaltet Instanzen-Pool von Beaninstanzen Nachricht wird jeweils an eine der Instanzen zur Bearbeitung weitergeleitet Verschiedene Nachrichten können parallel bearbeitet werden Zustandsloses Life-Cycle Modell wie bei Stateless Session Beans Clemens Düpmeier,

127 Zwei Typen von Message Driven Beans
JMS basierte Message Driven Beans implementieren das "javax.jms.MessageListener" Interface und können damit JMS-konforme Nachrichten verarbeiten Connector-based Message Driven Beans implementieren vorgegebenes Interface eines J2EE-Connectors (Resource Adapter zur Integration einer externen Legacy-Anwendung in den Applikationsserver) z.B. Enterprise Applikationen, wie SAP-System, externes Mail-System, externes CORBA-System, anderes Legacy Message System Können daher Messages von der zugehörigen externen Legacy-Applikation verarbeiten Clemens Düpmeier,

128 JMS Message Driven Bean
@MessageDriven(activationConfig={ @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"), @ActivationConfigProperty(propertyName="destination", propertyValue="queue/tickets"), @ActivationConfigProperty(propertyName="messageSelector", propertyValue="subject LIKE 'Storno%'")}) public class StornoMessagBean implements MessageListener { @Resource private MessageDrivenContext mdc; public void onMessage(Message message) { // hier Verarbeitung der Message } Die activationConfig-Angabe konfiguriert das Empfangsverhalten der Message Driven Bean JMS-MDBs müssen das MessageListener Interface implementieren Clemens Düpmeier,

129 JMS MessageListener Interface
package javax.jms; public interface MessageListener { public void onMessage(javax.jms.Message mesage); } JMS Message Driven Beans müssen das MessageListener Interface implementieren enthält "onMessage()"-Methode, die zum Empfangen der JMS-Message aufgerufen wird diese Methode wird vom EJB-Container aufgerufen, um die Verarbeitung der Message in der Bean anzustoßen Clemens Düpmeier,

130 Konfiguration der Empfangsparameter
Durch Attribut activationConfig Annotation oder im Deployment-Deskriptor Menge Angaben abhängig von der Art der Message Driven Bean Bei JMS z.B. destinationType : Queue oder Topic destination : Name der Destination messageSelector: Expression zum Filtern der Nachrichten Clemens Düpmeier,

131 Connector basierte Message Driven Bean (1)
@MessageDriven(activationConfig={ @ActivationConfigProperty(propertyName="mailServer", propertyValue="mail.ourdomain.com"), @ActivationConfigProperty(propertyName="mailFolder", propertyValue="INBOX"), @ActivationConfigProperty(propertyName="storeProtocal", propertyValue="imap"), @ActivationConfigProperty(propertyName="userName", @ActivationConfigProperty(propertyName="password", propertyValue="ejb123")}) @ResourceAdapter("mail-ra.rar") // Angabe des Connectors ... Annotationen definieren Art des Connectors und Connector-spezifische Empfangsparameter hier für ein externes -System, was angebunden ist Clemens Düpmeier,

132 Connector basierte Message Driven Bean (2)
@MessageDriven(activationConfig={ // Angabe des Connectors public class StornoMailBean implements MailListener { @EJB private StornatorLocal stornator; public void onMessage(Message message) { // hier Verarbeitung der Message } Connector-basierte JMS-MDBs müssen ein zum Connector gehöriges Interface implementieren hier das MailListener Interface Dies kann aus einer oder mehreren Interface-Methoden mit durch den Connector definierten Message-Argumenten bestehen Clemens Düpmeier,

133 Connector basierte Message Driven Bean (3)
@EJB private Stornator stornator; public void onMessage(Message message) { try { String subject = message.getSubject(); StringTokenizer tokenizer=new StringTokenizer(subject," "); String command=tokenizer.nextToken(); if ("STORNO".equalsIgnoreCase(command)) { String bestellNr=tokenizer.nextToken(); stornator.storniereBestellung(bestellNr); } else { // nicht verarbeiten } } catch (Exception e) { ... } } Message-Behandlungsmethode extrahiert subject-Zeile aus der Message wenn dies das Wort "STORNO" gefolgt von einer Bestellnummer enthält wird eine zugehörige Bestellung über das Stornator-Bean gelöscht Clemens Düpmeier,

134 Ein JMS-Client ConnectionFactory und Queue (siehe JMS API)
public class StornoClient { public class void main(String args[]) throws Exception { String bestellnummer = args[0]; Context context=new InitialContext(System.getProperties()); ConnectionFactory conFac= (ConnectionFactory)context.lookup("ConnectionFactory"); Connection con = conFac.createConnection(); Sesssion session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); Queue queue = (Queue)context.lookup("queue/tickets"); ... } Client besorgt sich über JNDI ConnectionFactory und Queue (siehe JMS API) und erzeugt Connection und Session Objekte (siehe JMS API) Clemens Düpmeier,

135 Ein JMS-Client (2) einen MessageProducer
public class StornoClient { public class void main(String args[]) throws Exception { ... MessageProducer sender = session.createProducer(queue); TextMessage message = session.createTextMessage(); message.setProperty("subject","STORNO " + bestellnummer); message.setText("Stornierung der Bestellung " + bestellnummer); sender.send(message); connection.close(); } Client erzeugt über Session einen MessageProducer und eine Message vom Typ TextMessage Die Message wird über den Producer (sender) abgeschickt Clemens Düpmeier,

136 Wann EJB'S nutzen? Clemens Düpmeier,

137 Mögliche Problempunkte
Performanz Kommunikationsaufwand Anzahl der Entfernten Aufrufe Menge an Daten, die dabei transferiert werden Marshalling / Unmarshalling Datenbank / Entity Bean Aufwand Mapping zwischen Tabellen und Objekten Beim Einsatz z.B. von Transaktionen Deadlock möglich und / oder Aufwand zur Vermeidung Komplizierte Transaktionssemantik Clemens Düpmeier,

138 Mögliche Problempunkte (2)
Programmierung und Design Erhöhte Komplexität Erhöhte Entwicklungszeit Kontiniuierliche Revision der Spezifikation …. Clemens Düpmeier,

139 Wann nutzen? Regeln zur Nutzung von EJB Wenn Skalierbarkeit gefragt
Wenn Transaktionen notwendig Wenn ausgefeilte Security Anforderungen gegeben Quality of Service Features vorhanden sein müssen Wann eher nicht? Schnelle, prototypische Lösung gefragt Kein Skalierbarkeit, keine Transaktionen, etc. notwendig Aufwand zum Training zu groß gegenüber Nutzen Clemens Düpmeier,

140 Stadt- Info- Datenbank
EJB-Container WWW Client Web-Server Servlets GUI Anw. Stadt- Info- Datenbank Internet Intranet Remote Web-Service Web-Service HTTP RMI-IIOP Einpflegen von Daten JDBC Beispiel für Anwendung Clemens Düpmeier,