Middleware am Beispiel des JEE Standards

Forschungszentrum Karlsruhe
Technik und Umwelt
Komponenten-orientierte Middleware am
Beispiel von Enterprise Java Beans (EJB)
Clemens Düpmeier, 16.05.2016
-1-
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
-2-
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
-3-
Forschungszentrum Karlsruhe
Technik und Umwelt
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 / Verzeichnisdienst (kennen wir ja bereits)
– Bessere Kontrolle der Parallelität
– und mächtigere Sychronisation, z.B. durch Verteilte Transaktionen
– Security (Nutzer und Authorisierungskonzepte)
– Persistenzdienste
– Zeitgesteuerte Dienste
– ...
•
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, 16.05.2016
-4-
Forschungszentrum Karlsruhe
Technik und Umwelt
Historische Entwicklung von Middleware
•
Erste Middlewaresysteme
ergänzten RPC um
– Transaktionen
– TP-Monitore
Clemens Düpmeier, 16.05.2016
•
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 TPFunktionalitäten in einer
Infrastruktur zusammen
-5-
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
-6-
Forschungszentrum Karlsruhe
Technik und Umwelt
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) + CloudComputing Laufzeitinfrastrukturen
Clemens Düpmeier, 16.05.2016
•
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
-7-
Forschungszentrum Karlsruhe
Technik und Umwelt
Das Problem der Cross Cutting Concerns
•
Querschnittsorientierte 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, 16.05.2016
-8-
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
-9-
Forschungszentrum Karlsruhe
Technik und Umwelt
Architektur eines Komponenten-Servers
Proxy / Stub anfordern
Client
Proxy
Methodenaufruf
Namensdienst
Weitere Hilfsfkt.
Persistenz
Business
Interface Lokal
Business
Interface Remote
Bean
Bean
Bean
Message
Dienst
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, 16.05.2016
- 10 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Welche Komponenten-Technologien gibt es?
• .NET Framework enthält Mechanismen für
Komponenten-orientierte Programmierung
• JEE-Standard definiert Enterprise Java
Beans (EJB) als Verteilte BusinessKomponenten
• Prinzipiell hat auch der Corba-Standard ein
Komponenten-basiertes Modell definiert,
das aber kaum genutzt wurde / wird
Clemens Düpmeier, 16.05.2016
- 11 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Querschnittsorientierte Funktionalitäten
(Cross Cutting Concerns)
Beispiel: Verteilte Transaktionen
Clemens Düpmeier, 16.05.2016
- 12 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 13 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Infrastruktur für Verteilte Transaktionen
Clemens Düpmeier, 16.05.2016
- 14 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 15 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 16 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 17 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Container gesteuerte Transaktion
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public 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, 16.05.2016
- 18 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Enterprise Java Beans
und zugehörige Container
Clemens Düpmeier, 16.05.2016
- 19 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 20 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Applikation und EJB's
<< EJB 2 >>
<< EJB 4 >>
<< Web Applikation >>
<< EJB 1 >>
<< GUI Applikation >>
<< EJB 5 >>
<< EJB 6 >>
<< 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, 16.05.2016
- 21 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Verteilbarkeit von Beans
Container I
<< Web Applikation >>
<< EJB 2 >>
Container II
<< EJB 4 >>
<< EJB 1 >>
<< EJB 5 >>
<< GUI Applikation >>
<< EJB 6 >>
<< EJB 3 >>
•
Beans können beliebig auf Containern verteilt werden
•
Die Benutzungsschnittstelle von Beans ist "locationtransparent"
•
Verteilung der Beans nur administrativer Vorgang
Clemens Düpmeier, 16.05.2016
- 22 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 23 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Elemente eines JEE-Applikationsservers
Lookup
Client
Container für Objekte
JNDI
Namensdienst
Zugriff
HTTP(S)
SOAP/HTTP
RMI / IIOP
RMI / JRMP
JEE Standard Dienste und API's
Java Native Directory (JNDI)
Java Message Service (JMS)
Legacy
Message
System
Transaktionen (JTA/JTS)
Servlet Container
und Webserver
Web-Services (JAX-WS)
Java-Persistence (JPA)
Database
REST-Services (JAX-RS)
EJB-Container
Java Connector (JCA)
Clemens Düpmeier, 16.05.2016
Legacy
System
- 24 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 25 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 26 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 27 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Welche EJB Arten gibt es?
Session Beans
Dienen der Modellierung
synchroner BusinessProzessaufrufe
Message Beans
Dienen zur Modellierung
asynchroner BusinessAbläufe
Entity Beans
Implementieren Entitäten,
also Datenobjekte
Clemens Düpmeier, 16.05.2016
- 28 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 29 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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
Clemens Düpmeier, 16.05.2016
- 30 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 31 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 32 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Interaktion Client mit Session-Bean
Applikationsserver
Client
(ProxyObjekt)
1
Transaktions-Service
Ergebnis
6
foo()
startet
Transaktion
2
StellvertreterObjekt
5
3
beendet
Transaktion
foo()
return
4
EJB-Instanz
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, 16.05.2016
- 33 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 34 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 35 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 36 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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 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
Clemens Düpmeier, 16.05.2016
- 37 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 38 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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
Transaktionen
Umfassen einen Methodenaufruf Können mehrere Methoden
oder werden vom Client gesteuert umfassen (Session-Kontext)
Web-Service
Als Web-Services veröffentlichbar Nein
Clemens Düpmeier, 16.05.2016
(Hauptspeicher)
- 39 -
Forschungszentrum Karlsruhe
Technik und Umwelt
EJB Typen - Entity Beans
•
•
Modellieren persistente Datenobjekte
Gibt es in zwei Varianten:
– EJB 2 Entitäten sind schwergewichtige Objekte (eventuell als Remote
Objekte verfügbar): Achtung: alt und deprecated
– 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, 16.05.2016
- 40 -
Forschungszentrum Karlsruhe
Technik und Umwelt
EJB 3 Entitäten = Java Persistence API (JPA)
•
Standardisierte Objekt Relationale Mapping (ORM) Technologie
– 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, kann aber 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, 16.05.2016
- 41 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 42 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Beispiel Entity-Bean
import javax.persistence.*;
@Entity
public class
@Id
private
private
private
…
// Hier
Contact implements Serializable {
Long id;
String surname;
String nickname;
getter und setter Methoden zu Feldern
// Hash und Equals Methoden für Bean
}
Clemens Düpmeier, 16.05.2016
- 43 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Beispiel: @ManyToOne, @OneToMany
@Entity
public class Student {
@Id
Long id;
String shortName;
String longName;
@ManyToOne
Course course;
}
@Entity
public class Course {
Course
ID
shortName
longName
Student
ID
matrikelNr
course
@OneToMany(mappedBy = "course")
public Set<Student> students=new HashSet<Student>();
}
Clemens Düpmeier, 16.05.2016
- 44 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Nutzung der JPA in Session Bean
import javax.persistence.*;
@Stateless
public ContactsBean {
@PersistenceContext
EntityManager em;
public void saveContact(Contact contact) {
em.persist(contact)
}
public Contact getContact(int id) {
return em.find(Contact.class, id);
}
}
Clemens Düpmeier, 16.05.2016
- 45 -
Forschungszentrum Karlsruhe
Technik und Umwelt
EJB Typen - 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
Driven Beans zur Bearbeitung weiter
•
Client und Bean sind bei dieser Kommunikationsart vollständig
voneinander entkoppelt
Clemens Düpmeier, 16.05.2016
- 46 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Nachrichten-basierte Kommunikation
Client
Server
Sender
Empfänger
Message
Broker
Clemens Düpmeier, 16.05.2016
Bearbeitung
Client
arbeitet
weiter
- 47 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 48 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Point-to-Point Kommunikation
Sender 1
Message
Broker
Empfänger
Sender 2
Queue
•
•
•
•
Ein oder mehrere Sender stellen Nachrichten in einer MessageWarteschlange (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, 16.05.2016
- 49 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Publish-Subscribe Modell
Sender 1
Message
Broker
Sender 2
Empfänger 1
Empfänger 2
Topic
• 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, 16.05.2016
- 50 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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 Broke 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, 16.05.2016
- 51 -
Forschungszentrum Karlsruhe
Technik und Umwelt
MOM, JMS und J2EE-Applikationsserver
•
JMS ist Bestandteil der J2EE-Spezifikation
•
Jeder JEE-konforme Applikationsserver muss
– JMS als Provider implementieren
– und die JMS-API bereitstellen
•
Message Driven Beans werden vom EJB-Container als JMSNachrichtenempfänger registriert
– Sie sind daher Empfänger von JMS-basierten Nachrichten
– Das Bean muss dazu nicht die JMS-API nutzen, sondern ein
Listener Interface zum Empfangen von Nachrichtenobjekte
vom Container implementieren
Clemens Düpmeier, 16.05.2016
- 52 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 53 -
Forschungszentrum Karlsruhe
Technik und Umwelt
J2EE-Applikationserver
fordert Referenz
auf Destination an
3
registriert Destinations
JNDI
1
Naming Service
sendet JMS-Nachricht an Destination
Client
•
•
•
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
Clemens Düpmeier, 16.05.2016
JMS-Provider
4
5
2
übermittelt Nachricht
an Empfänger
leitet sie an
6
Bean weiter
registriert sich
als Receiver für Destinations
EJB-Container
Bean
Instanz
?
erzeugt Bean
Instanzen
- 54 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Zugriff von Clients auf EJB's
Clemens Düpmeier, 16.05.2016
- 55 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 56 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 57 -
Forschungszentrum Karlsruhe
Technik und Umwelt
Dependeny Injection
public class CalculatorUser {
@EJB CalculatorRemote calculator;
void useCalculator() {
System.out.println("2 + 5 =" + calculator.add(2,5))
}
}
// 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, 16.05.2016
- 58 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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 EJBLaufzeitumgebung (SessionContext) zurück
•
Ebenfalls zum Zugriff auf Entity-Beans, siehe später Injektion eines
EntityManagers
Clemens Düpmeier, 16.05.2016
- 59 -
Forschungszentrum Karlsruhe
Technik und Umwelt
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, 16.05.2016
- 60 -
Forschungszentrum Karlsruhe
Technik und Umwelt
JNDI-Lookup ab EJB 3
Context ic = getInitialContext();
CalculatorRemote calculator
=(CalculatorRemote)ic.lookup("Calculator/remote");
System.out.println("2 + 5 =" + calculator.add(2, 5));
• Also Context initialisieren (Teil 1)
• Lookup des Proxy bei Namensdienst und direktes
Casten in Interface
• Und dann mit Proxy arbeiten
Clemens Düpmeier, 16.05.2016
- 61 -