Upload
liselotte-kemme
View
216
Download
1
Embed Size (px)
Citation preview
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Komponenten-orientierte Middleware am Beispiel von Enterprise Java Beans (EJB)
- 1 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 2 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 3 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 4 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 5 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 6 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 7 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 8 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 9 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
Proxy / Stub anfordern
Methodenaufruf
- 10 -
Proxy
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Welche Komponenten-Technologien gibt es?
• .NET Framework enthält Mechanismen für Komponenten-orientierte Programmierung
• JEE-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
- 11 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Querschnittsorientierte Funktionalitäten (Cross Cutting Concerns)
Beispiel: Verteilte Transaktionen
- 12 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 13 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Infrastruktur für Verteilte Transaktionen
- 14 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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)
- 15 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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)
- 16 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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){ ... }
}
- 17 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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 MyUpdateBean {
@TransactionAttritbute(TransactionAttribute.REQUIRED)public void updateServer() {
updateServer1();updateServer2();
}}
- 18 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Enterprise Java Beans
und zugehörige Container
- 19 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 20 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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 >>
- 21 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 22 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 23 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
Database
LegacySystem
Client
HTTP(S)SOAP/HTTPRMI / IIOP
RMI / JRMP
Zugriff
Lookup
- 24 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 25 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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.
- 26 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 27 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 28 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 29 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 30 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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);
}
- 31 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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; }
}
- 32 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Interaktion Client mit Session-Bean
• 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(Proxy-Objekt)
Stellvertreter-Objekt
1 foo()
2 5startetTransaktion beendet
Transaktion
foo()
return
34
6
Ergebnis
Applikationsserver
- 33 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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) { ... } }
- 34 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 35 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 36 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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() { ... } }
- 37 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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)
- 38 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Vergleich der Session-Bean VariantenStateless 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 gesteuertKönnen mehrere Methoden umfassen (Session-Kontext)
Web-Service Als Web-Services veröffentlichbar Nein
- 39 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 40 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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, …
- 41 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 42 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Beispiel Entity-Beanimport javax.persistence.*;
@Entitypublic class Contact 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}
- 43 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Beispiel: @ManyToOne, @OneToMany@Entitypublic class Student {
@IdLong id;String shortName;String longName;
@ManyToOneCourse course;
}@Entitypublic class Course {
@OneToMany(mappedBy = "course")public Set<Student> students=new HashSet<Student>();
}
ID shortName longName
ID matrikelNr course
Course
Student
- 44 -
Forschungszentrum KarlsruheTechnik und Umwelt
Nutzung der JPA in Session Bean
Clemens Düpmeier, 26.04.23 - 45 -
import javax.persistence.*;
@Statelesspublic ContactsBean {
@PersistenceContextEntityManager em;
public void saveContact(Contact contact) {em.persist(contact)
}
public Contact getContact(int id) {return em.find(Contact.class, id);
}}
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 46 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Nachrichten-basierte KommunikationClient Server
Sender Empfänger
MessageBroker
Client arbeitetweiter
Bearbeitung
- 47 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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)
- 48 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 49 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 50 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 51 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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 JMS-
Nachrichtenempfä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
- 52 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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 }}
- 53 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 54 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
Zugriff von Clients auf EJB's
- 55 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 56 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 57 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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;
}}
- 58 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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();
- 59 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
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
- 60 -
Forschungszentrum KarlsruheTechnik und Umwelt
Clemens Düpmeier, 26.04.23
JNDI-Lookup ab EJB 3
• Also Context initialisieren (Teil 1)• Lookup des Proxy bei Namensdienst und direktes
Casten in Interface• Und dann mit Proxy arbeiten
Context ic = getInitialContext();
CalculatorRemote calculator =(CalculatorRemote)ic.lookup("Calculator/remote");
System.out.println("2 + 5 =" + rechner.add(2, 5));
- 61 -