Forschungszentrum Karlsruhe Technik und Umwelt Clemens Düpmeier, 11.02.2014 Komponenten-orientierte Middleware am Beispiel von Enterprise Java Beans (EJB)

Forschungszentrum KarlsruheTechnik und Umwelt

Clemens Düpmeier, 11.04.23

Komponenten-orientierte Middleware am Beispiel von Enterprise Java Beans (EJB)

- 1 -



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

- 2 -



Gibt es auch Nachteile?

Was kann an Verteilter Objektkommunikation noch verbessert

werden?

- 3 -



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

- 4 -



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

- 5 -



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

- 6 -



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

- 7 -



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

- 8 -



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

- 9 -



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

- 10 -



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

- 11 -



Architektur eines Komponenten-Servers

• 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

BeanBeanBeanBusinessInterface Remote

BusinessInterface Lokal

Komponenten-Container

Namensdienst

Persistenz

MessageDienst

Weitere Hilfsfkt.

Client

Referenz anfordern

Methodenaufruf

- 12 -



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

- 13 -



JEE als Komponenten-orientierte Middleware

BrowserLegacySystem

LegacySystem

Database

(Controller)Servlet(s)

(Model)

Web/HTTP Server

3

(View)JSPGUI

Anwend.

EJBEJB

EJB

EJB

JMS

JDBC

CORBA

JNDI

CorbaDienst

e

Application ServerRMI

RMI

- 14 -



Querschnittsorientierte Funktionalitäten (Cross Cutting Concerns)

Beispiel: Verteilte Transaktionen

- 15 -



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

- 16 -



Infrastruktur für Verteilte Transaktionen

- 17 -



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)

- 18 -



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)

- 19 -



2-Phase Commit

- 20 -



2-Phase Commit

- 21 -



2-Phase Commit

- 22 -



2-Phase Commit

- 23 -



2-Phase Commit

- 24 -



2-Phase Commit

- 25 -



2-Phase Commit

- 26 -



2-Phase Commit

- 27 -



JTA-Transaction Beispielcode

• 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

UserTransaction ut=context.getUserTransaction();

try {ut.begin();updateServer1();updateServer2();ut.commit();

} catch (Exception e) {try { ut.rollback(); } catch (SystemException syex){ ... }

}

- 28 -



Container gesteuerte Transaktion

• 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)

@Stateless@TransactionManagement(TransactionManagementType.CONTAINER)public calls MyUpdateBean {

@TransactionAttritbute(TransactionAttribute.REQUIRED)public void updateServer() {

updateServer1();updateServer2();

}

}

- 29 -



Enterprise Java Beans

und zugehörige Container

- 30 -



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

- 31 -



Applikation und EJB's

• Beans können sich gegenseitig nutzen

• Manche Beans können von mehr als einer Anwendung oder einem Bean genutzt werden

<< EJB 1 >>

<< EJB 2 >>

<< EJB 3 >>

<< EJB 4 >>

<< EJB 5 >>

<< EJB 6 >>

<< Web Applikation >>

<< GUI Applikation >>

- 32 -



Verteilbarkeit von Beans

• Beans können beliebig auf Containern verteilt werden

• Die Benutzungsschnittstelle von Beans ist "location-transparent"

• Verteilung der Beans nur administrativer Vorgang

<< EJB 1 >>

<< EJB 2 >>

<< EJB 3 >>

<< EJB 4 >>

<< EJB 5 >>

<< EJB 6 >>

<< Web Applikation >>

<< GUI Applikation >>

Container I Container II

- 33 -



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

- 34 -



Elemente eines JEE-Applikationsservers

EJB-Container

Servlet Containerund Webserver

JNDINamensdienst

Java Message Service (JMS)

Transaktionen (JTA/JTS)

Web-Services (JAX-WS)

Java Native Directory (JNDI)

Java-Persistence (JPA)

REST-Services (JAX-RS)

Java Connector (JCA)

JEE Standard Dienste und API'sContainer für Objekte

LegacyMessageSystem

LegacyMessageSystem

Database

LegacySystem

Client

HTTP(S)SOAP/HTTPRMI / IIOP

RMI / JRMP

Zugriff

Lookup

- 35 -



Elemente des EJB-Containers

ConcurrencyHandling

TransactionHandling

LifeCycleHandling

...

InstancePooling

EJB

EJB

EJB

EJBEJB

EJBInstanz

BusinessInterface

Implementation

Client

BusinessInterface

- 36 -



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

- 37 -



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.

- 38 -



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

- 39 -



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

- 40 -



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

- 41 -



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

- 42 -



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.

- 43 -



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

- 44 -



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

- 45 -



Session-Beans

- 46 -



Kommunikationsschnittstellen

• Session-Beans stellen die Schnittstelle (Fassade) von Geschäftslogik nach aussen da

– Sie bieten Schnittstellen zur

• lokalen (@Local Interface)

• entfernten RMI-IIOP basierten (@Remote Interface)

• oder sogar Web-Service (@WebService Interface)

Kommunikation mit Clients

• Verschiedene Session-Bean Varianten definieren dabei, welche Art der Bindung zwischen Client und Bean besteht

– zustandslos (@Stateless)

– zustandsbehaftet (i.e. Session mit Client) (@Stateful)

– Singleton-Pattern (ab EJB 3.1 @Singleton)

- 47 -



Bestandteile eines Session-Bean• Session-Bean (und andere schwergewichtige Beans) bestehen aus 3 Teilen

– Client Schnittstellen

• @Local, @Remote oder @WebService 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

- 48 -



Beispiel für ein Session-Bean Interface

• 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

import javax.ejb.*;

@Remotepublic interface CalculatorRemote {

public double add(double a, double b);public double minus(double a, double b);

}

- 49 -



Beispiel für die Implementierungsklasse

• 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

import javax.ejb.*;

@Statelesspublic class Calculator implements CalculatorRemote {

public double add(double a, double b) {return a + b; }

public double minus(double a, double b) {return a – b; }

}

- 50 -



Interaktion Client mit Session-Bean

• 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

BeanBeanBeanBusinessInterface Remote

BusinessInterface Lokal

Komponenten-Container

Namensdienst

Persistenz

MessageDienst

Weitere Hilfsfkt.

Client

Referenz anfordern

Methodenaufruf

Applikationsserver

- 51 -



Interaktion Client mit Session-Bean (2)

• 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)

EJB-Instanz

EJB-Container

Transaktions-ServiceClient

Stellvertreter-Objekt

1foo()

2 5startetTransaktion beendet

Transaktion

foo()

return

34

6

Ergebnis

Applikationsserver

- 52 -



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

- 53 -



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

- 54 -



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

method-readypool

1. newInstance()2. Dependency Injection3. @PostConstruct

AufrufGeschäftsmethode

@Timeout

@PreDestroy

- 55 -



Interaktion mit Lebenszyklus

• @PostConstruct annotierte Methoden werden von Container nach Initialisierung und Dependency Injection der Bean aufgerufen

• @PreDestroy annotierte Methoden vor der Vernichtung der Bean

import javax.ejb.*;

@Statelesspublic class Calculator implements CalculatorRemote {

@PostConstructpublic void onPostConstruct() {

// OK, initialize needed resources } @PreDestroy public void onPreDestroy() { // OK, let's destroy our resources } ...

}

- 56 -



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

- 57 -



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

- 58 -



Setzen des Transaktionsattributes

• 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

import javax.ejb.*;

@Statelesspublic class AuskunftBean {

@TransactionAttribute(TransactionAttributeTyp.NOT_SUPPORTED) public List<Konzert> sucheKonzerte(String ortsName, Date date) { ... }

}

- 59 -



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

- 60 -



Stateful Bean und Conversational State

• Stateful Session-Beans deklariert man mit der Annotation @Stateful 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

import javax.ejb.*;

@Statefulpublic class OrderBean implements Order { private ShoppingCard basket;

public void addProductToShoppingCard(Product p) { basket.add(p); } public pay() { ... }

}

- 61 -



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)

- 62 -



Lebenszyklus von Stateful Beans

• Mit entsprechend annotierten Methoden kann das Bean an Zustandsänderungen teilnehmen (@Notationen)

• Beans in Transaktion können nicht passiviert werden!

• Bean kann durch Implementierung eines Interfaces am Ablauf einer Transaktion teilnehmen (afterBegin(), ...)

does notexist

method-ready passive

method-readyin TX

1. newInstance()2. Dependency Injection3. @PostConstruct

afterBegin()afterCompletion(false)

1. beforeCompletion()2. afterCompletion(true)

Transaktionale Methode

Transaktionale Methode

Commit

Rollback

@PreDestroy

@Remove-Methodeoder zu lange inaktiv

zu lange inaktiv

@PrePassivate"Least recently used"

erneuter Methodenaufruf@PostActivate

nicht-transaktionaleMethode

- 63 -



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

- 64 -



Synchronisation des Conversational State

• 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

package javax.ejb;

public interface SessionSynchronization { void afterBegin() throws EJBException, RemoteException; void afterCompletion(boolean committed)

throws EJBException, RemoteException; void beforeCompletion() throws EJBException, RemoteException;}

- 65 -



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

- 66 -



Zugriff von Clients auf EJB's

- 67 -



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

- 68 -



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

- 69 -



Dependeny Injection

• In EJB funktioniert Injektion in Variablen und über Argumente von Settern

public class CalculatorUser {@EJB CalculatorRemote calculator;

void useCalculator() {System.out.println("2 + 5 =" + calculator.add(205))

}}// oder setter injectionpublic class CalculatorUser {

private CalculatorRemote myCalculator;@EJB

void setCalculator(CalculatorRemote calculator) {myCalculator=calculator;

}}

- 70 -



Dependeny Injection mit Resourcen

• 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

@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();

- 71 -



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

- 72 -



Beispiel Clientsourcecode – Teil1

• OK, hier beispielhaft Konfiguration der Namensdienstattribute für einen JBOSS Server

• Dies ist halt abhängig vom jeweiligen Server

public static Context getInitialContext() throwsjavax.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);}

- 73 -



Beispiel Clientsourcecode – Teil 2

• Also Context initialisieren (Teil 1)

• Lookup des Proxy bei Namensdienst

• Casten (weil Proxy Corba Object)

• Und dann mit Proxy arbeiten

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));

- 74 -



JNDI-Lookup ab EJB 3

• Also Context initialisieren (Teil 1)

• Lookup des Proxy bei Namensdienst und direktes Casten in Interface

• Kein PortableRemoteObject.narrow(...) mehr

• Und dann mit Proxy arbeiten

Context ic = getInitialContext();

CalculatorRemote calculator =(CalculatorRemote)ic.lookup("Calculator/remote");

System.out.println("2 + 5 =" + rechner.add(2, 5));

- 75 -



Entity Beans

JPA – Java Persistence API

- 76 -



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, …

- 77 -



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

- 78 -



Minimale Entität

• Entity Klasse muss als Entity markiert sein

1. Über @Entity Annotation

@Entity

public class Person { … }

2. Über Metadateneintrag in XML Mapping Datei

<entity class="myPackage.Person" />

- 79 -



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; }}

- 80 -



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

1. Einfache Id – Einzelnes Objektattribut

@Id int id;

2. Zusammengesetztes Attribut

@Id int id; @Id String name

3. Eingebettete Id – einzelnes Feld von PK Klassentyp

@EmbeddedId PersonPK id;

EigenePKKlasse

- 81 -



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

- 82 -



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"

Entity 1 Entity 2

Entity 3

Entity Manager

EntityManager em= ....

MyEntity e1=(MyEntity)em.find(...);

Persistenz-Kontext

- 83 -



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

- 84 -



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

- 85 -



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

- 86 -



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

- 87 -



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"

- 88 -



Wie komme ich zu einem Entity Manager

• 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

private EntityManagerFactory emf = Persistence.createEntityManagerFactory("LecturePU");

private EntityManager em = emf.createEntityManager();

- 89 -



<?xml version="1.0" encoding="UTF-8"?><persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"><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>

persistence.xml - definiert Persistenz Engine "LecturePU"

- 90 -



Durch Injektion

• @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.)

@PersistenceContextprivate EntityManager em;

// hier weiterer Code

- 91 -



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)

- 92 -



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 und Transaktionen

• EntityManager erhält man über Factory

• em.persist() sichert das Objekt in der Datenbank

• Man beachte die Verwendung der Transaktion

- 93 -



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

- 94 -



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;

}

- 95 -



Methoden find() und remove()

• find()

– 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);

}

- 96 -



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

- 97 -



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

- 98 -



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

- 99 -



Beispiel: Dynamische Query

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

public List findAll(String entityName) {return em.createQuery(

"select e from " + entityName + " e").setMaxResults(100).getResultList();

}

- 100 -



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

- 101 -



Einfache Mapping Regeln

• Jede Objekteigenschaft einer als @Entity markierten Klasse wird auf eine Spalte abgebildet

– Mit @Column 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 Strings

@Column(name="name",length=100)

• Jeder Default kann auch überschrieben werden

- 102 -



Beispiel für einfache Mapping Regeln

• Einfaches Mapping der Entity Person

@Entitypublic class Person {

@IdLong id;

@Column(length=100)String firstName;

String lastName;

@LobImage photo

}

ID FIRSTNAME LASTNAME PHOTO

- 103 -



Einfaches Mapping mit XML Datei

• Mapping der Person Klasse über gesonderte 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>

- 104 -



Mapping von Beziehungen

• Unterstützung für das Mapping der gängigen Beziehungen

• @ManyToOne, @OneToOne - ein Entity

• @ManyToMany, @OneToMany - 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

- 105 -



Beispiel: @ManyToOne, @OneToMany

@Entitypublic class Student {

@IdLong id;String shortName;String longName;

@ManyToOneCourse course;

}

public class Course {

@OneToMany(mappedBy = "course")public Set<Student> students=new HashSet<Student>();

}

ID shortName longName

ID matrikelNr course

Course

Student

- 106 -



Achtung: Bidirektionalität@Entitypublic 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); }}

ID shortName longName

ID matrikelNr course

Course

Student

- 107 -



Beispiel: @ManyToMany

@Entitypublic 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

ID lectureName description

Dozent

Lecture

dozent_id lecture_id

- 108 -



Beispiel: Komponenten - Komposition

@Entitypublic class Address {

@Idint id;String street;String town;…

}

public class Person {String firstName;String lastName;

@OneToOne(cascade = CascadeType.ALL)Address homeAddress;

}

ID street town zipCode

ID firstName lastName homeAddress

Address

Person

- 109 -



Beispiel: Komponenten - Komposition@Embeddablepublic class Address {

// Kein SchlüsselString street;String town;…

}

public class Person {String firstName;String lastName;

@EmbeddedAddress homeAddress;

}

ID firstName lastName street town zipCode

Person

In diesem Fall hat die Komponentekeine eigene Tabelle

- 110 -



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

- 111 -



Beispiel Entity-Bean

import javax.persistence.*;

@Entitypublic class Address implements Serializable {

@Idprivate Long id;private String surname;private String nickname;…// Hier getter und setter Methoden zu Feldern

// Hash und Equals Methoden für Bean}

- 112 -



Message Driven Beans

Asynchrone Nachrichten-basierte Kommunikation

- 113 -



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

- 114 -



Nachrichten-basierte KommunikationClient Server

Sender Empfänger

MessageBroker

Client arbeitetweiter

Bearbeitung

- 115 -



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

- 116 -



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

- 117 -



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)

- 118 -



Point-to-Point Kommunikation

• 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

MessageBroker

Queue

Sender 1

Sender 2

Empfänger

- 119 -



Publish-Subscribe Modell

• 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

MessageBroker

Topic

Sender 1

Sender 2

Empfänger 1

Empfänger 2

- 120 -



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

- 121 -



QueueConnectionFactory

QueueConnection

QueueSession

QueueSender QueueReceiver

Queue

MessageBroker

Topic

createQueueConnection()

createQueueSession()

createSender() createReceiver()

send() onMessage()

TopicConnectionFactory

TopicConnection

TopicSession

TopicPublisher TopicSubscriber

Topic

MessageBroker

Topic

createTopicConnection()

createTopicSession()

createPublisher() createSubscriber()

publish() onMessage()

Message

create() create()

Point-to-Point Publish-Subscribe

JMS-API

- 122 -



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

- 123 -



BeanInstanz ?

erzeugt Bean Instanzen

EJB-Container

JMS-Provider

Naming Service

J2EE-Applikationserver

Client

JNDIregistriert Destinations

1

2registriert sichals Receiver für Destinations

3

4sendet JMS-Nachricht an Destination

fordert Referenzauf Destination an

5

6

übermittelt Nachrichtan Empfänger

leitet sie anBean weiter

• 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

- 124 -



Eigenschaften von Message Driven Beans

• Sie bestehen nur aus

– aus annotierter Implementierungsklasse

(Annotation @MessageDriven)

– 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

- 125 -



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

- 126 -



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

- 127 -



JMS Message Driven Bean

• Die activationConfig-Angabe konfiguriert das Empfangsverhalten der Message Driven Bean

• JMS-MDBs müssen das MessageListener Interface implementieren

@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 }}

- 128 -



JMS MessageListener Interface

• 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

package javax.jms;

public interface MessageListener { public void onMessage(javax.jms.Message mesage);}

- 129 -



Konfiguration der Empfangsparameter

• Durch Attribut activationConfig der @MessageDriven Annotation

– oder im Deployment-Deskriptor

• Menge von @ActivationConfigProperty 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

- 130 -



Connector basierte Message Driven Bean (1)

• Annotationen definieren Art des Connectors und

• Connector-spezifische Empfangsparameter

– hier für ein externes Email-System, was angebunden ist

@MessageDriven(activationConfig={ @ActivationConfigProperty(propertyName="mailServer",

propertyValue="mail.ourdomain.com"), @ActivationConfigProperty(propertyName="mailFolder",

propertyValue="INBOX"), @ActivationConfigProperty(propertyName="storeProtocal",

propertyValue="imap"), @ActivationConfigProperty(propertyName="userName",

propertyValue="[email protected]"), @ActivationConfigProperty(propertyName="password",

propertyValue="ejb123")}) @ResourceAdapter("mail-ra.rar") // Angabe des Connectors...

- 131 -




• 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

@MessageDriven(activationConfig={ ...})@ResourceAdapter("mail-ra.rar") // Angabe des Connectors

public class StornoMailBean implements MailListener { @EJB private StornatorLocal stornator;

public void onMessage(Message message) { // hier Verarbeitung der Message }}

- 132 -




• 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

@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 { // E-Mail nicht verarbeiten }

} catch (Exception e) { ... }}

- 133 -



Ein JMS-Client

• Client besorgt sich über JNDI

– ConnectionFactory und Queue (siehe JMS API)

– und erzeugt Connection und Session Objekte (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"); ... }}

- 134 -



Ein JMS-Client (2)

• Client erzeugt über Session

– einen MessageProducer

– und eine Message vom Typ TextMessage• Die Message wird über den Producer (sender) abgeschickt

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(); }}

- 135 -



Wann EJB'S nutzen?

- 136 -



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

- 137 -



Mögliche Problempunkte (2)

• Programmierung und Design

– Erhöhte Komplexität

– Erhöhte Entwicklungszeit

– Kontiniuierliche Revision der Spezifikation

– ….

- 138 -



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

- 139 -



EJB-Container

WWWClient

Web-ServerServlets

GUIAnw.

Stadt-Info-

Datenbank

GUIAnw.

Internet Intranet

RemoteWeb-Service

Web-Service

HTTP RMI-IIOP

RMI-IIOP

Einpflegen von Daten

JDBC

Beispielfür Anwendung

- 140 -

Forschungszentrum Karlsruhe Technik und Umwelt Clemens Düpmeier, 11.02.2014 Komponenten-orientierte Middleware am Beispiel von Enterprise Java Beans (EJB)

Documents