KOMPONTEN-BASIERTE
MIDDLEWARE
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
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
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
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
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
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
Architektur eines Servers mit Laufzeitcontainer für Komponenten
Client (Proxy) vewendet an Stelle der "echten" Business-Objekte Server-generierte Artifakte (Stellvertreter-Objekte)
Die Stellvertreter delegieren Aufrufe von außen an das Business-Bean
Die Container-generierten Stellvertreter-Objekte kümmern sich um die Cross Cutting Concerns
Instanzen der Bean-Klasse werden vom Container erzeugt, verwaltet und vernichtet
BeanBean Stellvertreter Bean
(Remote Zugriff) Stellvertreter
(lokal)
Komponenten-Container Namensdienst
Persistenz
Message Dienst Weitere Hilfsfkt.
Client
Proxy / Stub anfordern
Methodenaufruf Proxy
Bean- Instanzenpool
Beispiel: Verteilte Transaktion
Das obige Beispiel implementiert innerhalb der Business-Bean-Klasse eine User-gesteuerte Transaktion
Code nutzt die JTA = Java Transaction API für die Programmierung der Verteilten Transaktion
Die eigentliche Implementierung wird über den Java-Applikationsserver bereitgestellt, der den Transaktionsmanager bereitstellt und das Protokoll implementiert
Der Transaktionscode „verschmutzt“ den Businesscode: der eigentliche Businesscode besteht hier nur aus den Aufrufen im „blauen Kasten“
UserTransaction ut=context.getUserTransaction();
try {
ut.begin();
updateServer1();
updateServer2();
ut.commit();
} catch (Exception e) {
try { ut.rollback(); } catch (SystemException syex){ ... } }
Business-Code
Geht dies auch anders?
Container gesteuerte Transaktion bei einem Stateless Session-Bean Die Annotationen können auch weggelassen werden, da Default!
Hier wird die komplette updateServer()-Methode in eine Verteilte Transaktion eingepackt, welche der Container durchführt
Gutes Beispiel, wie Container den "Cross Cutting Concern"
Transaktionsverriegelung vom Anwendercode trennt (nennt man auch aspektorientierte Programmierung)
Möglich durch Komponenten-basierten Ansatz (wie bereits erklärt)
Die Stellvertreter-Objekte führen den eigentlichen Transaktionscode aus
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER) public MyUpdateBean {
@TransactionAttritbute(TransactionAttribute.REQUIRED) public void updateServer() {
updateServer1();
updateServer2();
} }
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.*;
@Stateless
public class AuskunftBean {
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) public List<Konzert> sucheKonzerte(String ortsName, Date date) { ...
} }
Interaktion Client mit Komponente
Client verbindet sich anstatt mit der Bean-Instanz einer Komponente mit Server-seitigen Stellvertreter-Objekt und ruft hier Methode auf (1), (6)
Stellvertreter-Objekt verwendet Hilfsservices für die Implementierung von Cross Cutting Concerns (hier eine Transaktion (2), (5))
Und delegieren Methodenaufrufe an die eigentliche Bean-Instanz(en) (3), (4), die für die Dauer der Beantwortung des Methodenaufrufs aus dem Bean-Instanz-Pool allokiert wir
Bean-Instanzen werden bei Bedarf durch den Container erzeugt und auch wieder vernichtet ; Der komplette Lebenszyklus von Beans wird vom Server verwaltet
Bean-Instanz Komponenten-Container
Transaktions-Service Client
(Proxy- Objekt)
Stellvertreter- Objekt 1
updateServer()
2 5
startet
Transaktion beendet
Transaktion updateServer() return
3 4
6
Ergebnis
Applikationsserver
Beispiel Autorisierung
@RolesAllowed ist Konfigurationsannotation, welche Authorisierungen für den Aufruf von Beanmethoden definiert
Als Default für alle Methoden ist der Aufruf nur Nutzern aus der Klasse
„RestrictedUsers“ gestattet
Bei der setNewRate() Methode wird nur einem Administrator Zugriff gewährt Die Methode convertCurrency() darf jeder aufrufen
Die Autorisierung wird ebenfalls im Stellvertreter-Objekt überprüft, bevor die jeweilige Methode aufgerufen wird
import javax.annotation.security.*;
@RolesAllowed("RestrictedUsers") public class Calculator {
@RolesAllowed("Administrator")
public void setNewRate(int rate) { //... } @PermitAll
public long convertCurrency(long amount) { //... } }
LIFECYCLE-MANAGEMENT, DEPENDENCY-INJECTION
Lifecycle-Management: Container erzeugt und verwaltet Objekte
Dependeny-Injection: bevor auf der Business-Logik-Klasse eines Beans eine Methode aufgerufen wird, checkt das Stellvertreter-Objekt, ob ein oder mehrere
„Dependency-Injections“ auf der Instanz durchgeführt werden müssen
Beispiel eines Lebenszyklus (in diesem Fall eines zustandslosen EJB Session-Beans)
Man beachte unter 1 die Dependency Injection
@PostConstruct und @PreDestroy Annotationen können verwendet werden, um „eigene“ Methoden in eine Bean-Klasse zu annotieren
die nach der Dependency-Injection aber vor der Nutzung der Beanklassen-Instanz bzw. vor der Zerstörung aufgerufen werden sollen
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
Automatische Auflösung von Abhängigkeiten (Dependency Injection)
Bei Objekten, die der Applikationsserver selbst verwaltet und damit selbst erzeugt, bietet er auch den Service
Objektvariablen automatisch mit Referenzen auf von ihm erzeugten Objekten auszufüllen: Injektion von benötigten Objekten (Dependeny Injection)
@Stateless
public class PlayerDao { @PersistenceContext EntityManager em;
… }
public class PlayerService { @Inject
PlayerDao playerDao;
… }
Injiziert einen EntityManager =
Objekt zum Zugriff auf Datenbankobjekte
Injiziert Objekt der Klasse „PlayerDao“
Ein von uns definiertes DAO-Objekt
Dependeny Injection von anderen 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 auf Folie vorher die 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();
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
Spring / Spring Boot Frameworks in Java
Jede Menge weiterer solcher Frameworks in anderen Programmiersprachen „Ruby on Rails“, „Node JS“
Prinzipiell hat auch der Corba-Standard ein Komponenten-
basiertes Modell definiert, das aber kaum genutzt wurde / wird
In Vorlesung haben wir aber UNO gesehen
Und Corbakomponenten sind in einigen Business-Bereichen (Börse, Banken) traditionell im Einsatz
ENTERPRISE JAVA BEANS
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
JEE-Applikationsserver
Installations- und Laufzeitumgebung für EJB's, Servlets, als Komponenten
Bietet zentrale Serverdienste und Laufzeitcontainer für Komponenten
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
Elemente eines JEE-Applikationsservers
EJB-Container Servlet Container
und Webserver JNDI
Namensdienst
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's Container für Objekte
Legacy Message
System Legacy Message
System
Database
Legacy System Client
HTTP(S) SOAP/HTTP
RMI / IIOP RMI / JRMP Zugriff über
Lookup
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
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
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
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.*;
@Remote
public interface CalculatorRemote {
public double add(double a, double b);
public double minus(double a, double b);
}
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.*;
@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; }
}
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-Service Client
(Proxy- Objekt)
Stellvertreter- Objekt 1 foo()
2 5
startet
Transaktion beendet
Transaktion foo()
return
3 4
6
Ergebnis
Applikationsserver
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
Lebenszyklus eines zustandslosen EJB Session- Beans
Man beachte unter 1 die Dependency Injection
@PostConstruct und @PreDestroy Annotationen können verwendet werden, um „eigene“ Methoden in eine Bean-Klasse zu annotieren
die nach der Dependency-Injection aber vor der Nutzung der Beanklassen-Instanz bzw. vor der Zerstörung aufgerufen werden sollen
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
Lebenszyklus eines zustandsbehafteten EJB
Session-Beans
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 import javax.ejb.*;
@Stateful
public class OrderBean implements Order { @Inject
private ShoppingCard basket;
public void addProductToShoppingCard(Product p) { basket.add(p);
}
@Remove
public pay() { ... } }
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)
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
MOM-MIDDLEWARE UND
MESSAGE DRIVEN BEANS
Wdh.: Synchrone versus asynchrone Komm. (2)
Asynchrone Kommunikation über Message Broker (MOM)
Asynchrone Kommunikation ohne stehende Verbindung zwischen Client und Server („fire and forget“)
Store and forward
Messages werden zwischengespeichert und weitergeleitet => Einfache Fehlerbehandlung
Lose Kopplung
Abläufe in Client und Server entkoppelt
Sender muss nicht physikalische Adresse des Empfängers kennen => Skalierbarkeit,
send
Queue
Message Broker
Queue
Gateway
Queue
Message Broker
receive
receive send
Client Server
Email-Prinzip
Zwei grundlegende Kommunikationsmodelle
Zwei Typen von Nachrichtenwarteschlangen (Destinations) als Ziel von Nachrichten
Queues repräsentieren ein Modell, wo jede Nachricht von genau einem Empfänger verarbeitet wird
(evtl. mehrere Sender aber ein Empfänger)
Topics arbeiten nach dem Publish-Subscribe Prinzip
(mehrere Publisher – mehrere Subscriber als Empfänger)
Weitere Warteschlangen-Eigenschaften (1) FIFO-Eigenschaft (First in first out)
Alle Nachrichten haben gleiche Priorität und werden in der Reihenfolge geliefert wie sie in Queue eingestellt werden
Prioritäts-Warteschlangen
Nachrichten haben Priorität als Eigenschaft und werden nach dieser Priorität neu in der Warteschlange angeordnet
Sender
Sender EmpfängerEmpfänger
Empfänger Empfänger Sender
Sender
Neue Anordnung
gemäß
ActiveMQ
Einer der meist genutzten Open Source MOM-Server
Bietet Unterstützung für eine Vielzahl von Transport- und Message-Protokollen
Transport
TCP/UDP SSL/TCP HTTP(s) WebSockets
Message-Protokolle
AMQP MQTT Stomp OpenWire
Simple Text Orientated Messaging Protocol (Stomp)
HTTP-Protokoll für MOM – ideal kombinierbar mit WebSockets Einfach
Viele APIs für unterschiedliche Sprachen
Sehr viele MOM-Systeme haben Stomp implementiert
CONNECT Protokollaktion SEND Protokollaktion
SUBSCRIBE Protokollaktion
Message Queueing for Telemetry Transport (MQTT) MOM Protokoll für Telemetrie-Anwendungen
Effizientes binäres Protokoll für Sender in kleinen Geräten entwickelt von IBM für Telemetrieanwendungen
Optimiert für wenig Hauptspeicher, geringe Bandbreite, kleinen Stromverbrauch; kleinste Message-Größe 2-Byte
Unterstützt große Anzahl an Geräten und Anwendungen als Clients Sehr lose Koppelung
Publish/Subscribe
At most Once, Exactly Once At least Once
Beispiel-
Anwendungsbereiche
Sensor-Netzwerke
Internet of Things (IoT)
JMS (Java Message Service)
Standard für Nachrichten-basierte Kommunikation in Java Application Programming Interface (API)
Service Provider Interface (SPI)
Clients nutzen die JMS-API, um Nachrichten zu senden oder sich für den Empfang zu registrieren, etc.
Ein Message Broker 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
MOM, JMS und JEE-Applikationsserver
JMS ist Bestandteil der JEE-Spezifikation
Jeder JEE-konforme Applikationsserver mit vollem Profil 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
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 andere MOM-Server 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
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 }
}
Ablauf Message-Komm. mit MessageBean
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
Bean
Instanz ?
erzeugt Bean Instanzen
EJB-Container
JMS-Provider
Naming Service
J2EE-Applikationserver
Client
JNDI
registriert Destinations
1
2
registriert sich
als Receiver für Destinations
3
sendet JMS-Nachricht an Destination4
fordert Referenz auf Destination an
5
6
übermittelt Nachricht an Empfänger
leitet sie an Bean weiter
(MICROSERVICE-BASIERTE)
MIDDLEWARE
Was ist SOA – Hat das was mit Web zu tun?
Der Begriff SOA (Service Oriented Architecture, dienstoriente Architektur) ist
zunächst nur ein Architekturmodell, um Dienste von Mitarbeitern und Organisationen zu strukturieren und über das Netzwerk zu nutzen und hat nichts unmittelbar mit Web oder Web-Services zu tun
SOA ist durch allgemeine Merkmale gekennzeichnet
Ein Dienst, in sich abgeschlossen und eigenständig nutzbar Der Dienst ist über Netzwerk verfügbar
Bei der Nutzung reicht es, seine Schnittstelle zu kennen
Der Dienst ist dynamisch gebunden: er wird erst zur Laufzeit lokalisiert und eingebunden
Plattformunabhängig und von keiner Programmiersprache abhängig
Was ist SOA – Hat das was mit Web zu tun? (2)
Prinzipiell weist CORBA einige Merkmale von SOA auf und
könnte als Implementierung für SOA-Anwendungen genutzt werden, allerdings gibt es da einige Probleme
CORBA Kommunikation ist nicht Internet-transparent CORBA ist schwer zu implementieren
Web-Services und Restful Web-Services haben viele der
Kommunikationseigenschaften, die SOA-Architekturen brauchen Plattform- und sprachunabhängig – leicht zu implementieren Internet-Transparenz
Unabhängigkeit von Implementierung und dynamische Bindbarkeit
=> Eine Kombination von Verteilten Komponenten Implementierungen mit Web- Service orientierten Schnittstellen nach außen bietet gute Grundlage für SOA- Anwendungen
SOA in der Praxis?
Microservice-Architektur nach „Fowler“
Wesentliches Prinzip
Funktionale Dekomposition in unabhängig von einander verwaltbare und deploybare Einheiten (Microservices)
Der Term „Micro bezieht sich auf die Größe: verwaltbar durch ein Entwicklungsteam (nicht mehr wie 4 – 9 Personen)
Funktionale Dekomposition bedeutet vertikale Zerlegung in Funktionen über Schichten hinweg und nicht horizontale Zerlegung in Schichten
Kein gemeinsamer Zustand oder etwa Interprozess-Kommunikation möglich
Spezifischere Eigenschaften
Jeder Microservice ist vollständig in Bezug auf:
Seine eigenständige Nutzbarkeit als Ressource (im Sinne von SOA)
Enthält Datenmanagement
eine Kommunikationsschnittstelle oder UI zur Nutzung
Microservices sind noch von einer Größe, so dass gilt:
„still fun to develop and to deploy“
Unabhängige Codebase
Jeder Service hat seine eigene Codebase
Die Codebase ist „fun sized“, d.h. klein genug, dass sie für Entwickler übersichtlich und einfach verwaltbar ist
Entwicklungstools sind auf der Codebase schnell (schnelles Compilieren, schneller Build, schnelles Deployment, schnelle Tests)
Der Startup eines Services geht sehr schnell
Keine zufälligen Querbeziehungen zwischen einzelnen
Codebases
Unabhängige Technologiestacks
Jeder Service hat seinen eigenen Technologiestack
Es kann der beste Technologiestack gewählt werden, der zur Implementierung der gewünschten Funktionalität passt
Teams können schnell mit neuen Technologiestacks experimentieren
Kein System- (Firmen-) weiter Technologie-Stack-Standard bedeutet auch
Weniger Probleme Innovationen durchzusetzen Keine versteckten Abhängigkeiten in Bezug auf Rucksack-Technologien
Jedes Serviceteam hat nur mit seinen eigenen Abhängigkeiten zu kämpfen
Der selektierte Stack kann oft sehr leichtgewichtig sein (z.B. nur einem eingebetteten Container laufen und kann von Komandozeile gestartet werden)
Unabhängig skalierbar
Jeder Microservice kann unabhängig skaliert werden
Identifizierte Bottlenecks können sofort adressiert werden
Sharding von Daten kann vom einem Microservice so wie benötigt angewendet werden
Services, die keine Bottlenecks darstellen, können ohne Skalierung
betrieben werden
Dezentralisierte Governance
Basisprinzip: Fokussiere auf die Standardisierung relevanter Teile und benutze vorhandene im Einsatz bewährte Standards und Infrastrukturen
Im Gegensatz zur klassischen Governance
Standardisiere
Kommunikationsprotokoll (HTTP) Message Format (JSON)
Und Kommunikationsschnittstellen (REST)
Und nicht z.B. Firmen-weit
Applikationsstack und Technologie
Konsequenzen
Man benötigt (zwingend) weitere Hilfsdienste
Abgespeckte („leichtgewichtige Middleware“)
Weitere zusätzliche Dienste z.B. für „Discovery Service“ zur Umsetzung von Load-Balancing
Proxy-Service-Facade, usw.
Mehr Einzelteile (Moving Parts)
Verlangt nach „Automatisierung“ (DevOps) des Build-Prozesses, Deployments und Runtime-Managements
Idealer Weise sollten Teile auf Rechnerinfrastruktur (Computing Cluster, Cloud-Infrastruktur) laufen, die hierfür instrumentiert ist
Microservice Referenzarchitektur (nach Gartner)
Auth/SSO LB / CB
Service-Gateway (API Gateway)
[URL-Raum-Mapping]
Service Discovery
Service Routing
Beziehungs- Management
Konfiguration
Clients (Browser, mobil)
Interne
Services Objektdienst
LB / CB Auth/SSO
Messdatendienst
LB / CB Auth/SSO
Assetdienst
LB / CB Auth/SSO
LB = Load Balancer; CB = Circuit Breaker
Message Server Infrastruktur
Plattform Automatisierung
Diagnostik
Container Automatisierung
Monitoring Benachrichtigung
Build und
Testautomatisierung Management Auth. / Autorisierung
Laufzeitplattform
API-Gateway
Um Clientzugriff auf eine
Vielzahl von Microservices zu vereinfachen, ist ein Gateway sinnvoll
Gateway stellt eine
„Load-balanced“
Basisadresse für alle Services zur Verfügung Routet Request dann auf
einzelne Serviceinstanzen, die wiederum „Load balanced“ sein können
Kann und sollte aber auch Daten aus mehrere Services
aggregieren
Service Discovery
Clients oder andere Services benötigen einen Mechanismus, um auf eine Instanz eines
Services zugreifen zu können
Nach Möglichkeit ohne hardcodierte IP-Adresse und Portangaben zu verwenden
Client sollte nur auf „lebendige“
Instanzen zugreifen können
Health-Checks
