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

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

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

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

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

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

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

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

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

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

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 Clemens Düpmeier, 12.04.2017

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Clemens Düpmeier, 12.04.2017

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

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

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

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

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

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

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

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

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