Kap. 6 Message-Oriented Middleware (MOM)

Transkript

1 Kap. 6 Message-Oriented Middleware (MOM) 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen 6.3Publish/Subscribe-Techniken Entkopplung von Sendern und Empfängern von Nachrichten Kapitel 6: Vorlesung MOM 1

2 6.1 Asynchrone Prozedur- bzw. Methodenaufrufe Bisher haben wir nur synchrone Prozedur- bzw. Methodenaufrufe betrachtet: Client setzt einen (entfernten) Aufruf ab Dieser wird bearbeitet; währenddessen wartet der Client Nach Rückgabe des Ergebnisses wird die Ausführung des Client-Programms fortgesetzt Gut geeignet für die Integration unterschiedlicher Komponenten in verteilte Transaktionen Nachteile dieses Ansatzes Erfordert eine enge Kopplung der verwendeten Komponenten Client ist während langdauernden Prozedur- bzw. Methodenausführungen (die evtl. über mehrere Ebenen weiter propagiert werden können) blockiert Ausfall einer Komponente kann grosse Teile des Gesamtsystems lahm legen Mehrere Clients warten dann auf die Ausführung einer Methode/Prozedur Nicht geeignet im Fall von mobilen Komponenten bzw. Komponenten, die häufig nicht verfügbar sind Kapitel 6: Vorlesung MOM 2

3 Message-Oriented Middleware (MOM) Asynchrone Prozedur- bzw. Methodenaufrufe basieren auf dem Austausch von Nachrichten zwischen Komponenten Beinhalten sowohl Daten als auch Spezifikation der Prozedur- bzw. Methode, die ausgeführt werden soll MOM: Message-Oriented Middleware Infrastruktur zum Verschicken/ Empfangen von Messages MOM stellt APIs bereit, Clients müssen sich nicht um Message-Transfer kümmern Warteschlange (Queue), zum Zwischenlagern von Messages Ermöglicht asynchrone Kommunikation, selbst wenn Empfänger von Nachrichten temporär nicht verfügbar sind Keine direkte Verbindung nötig Application Service A DBMS A DB A Enqueue Dequeue execute B queue Client Enqueue queue Dequeue execute A Application Service B DBMS B DB B Kapitel 6: Vorlesung MOM 3

4 Message-Oriented Middleware (MOM) Unterschiedliche Varianten von MOM Transaktionsunterstützung Ohne Transaktionskontrolle: MOM gibt keine Garantie, dass die asynchron aufgerufenen Dienste auch wirklich ausgeführt werden (z.b. können bei nicht-persistenten Queues Nachrichten im Fall von Crashes verloren gehen) Queued Transactions: Gesicherter Austausch von Nachrichten zwischen persistenten Queues und Sendern/Empfängern (siehe Kap. 6.2) Art der Verbindung Point-to-point: Sender adressiert den Empfänger direkt (1:1-Kommunikation) Publish/Subscribe: Sender kennt die Empfänger seiner Nachrichten nicht (1:n-Kommunikation möglich) (siehe Kap. 6.3) Zusätzliche Aspekte Load Balancing: Auswahl, an welchen Server (eines Server-Pools) eine Message zur Bearbeitung weitergereicht wird, aufgrund von Lastinformation aller Server Prioritäten: Bevorzugung wichtiger Messages durch Einordnung in Queue gemäss deren Priorität (priority queues) Kapitel 6: Vorlesung MOM 4

5 Verbreitung von MOM MOM ist kein komplett orthogonaler Ansatz zu den bisher besprochenen IS-Infrastrukturkomponenten sondern mehr oder weniger gut versteckt überall vorhanden TP-Monitore: unterstützen in der Regel auch asynchrone Aufrufe TUXEDO: transaktionale Message Queues (TUXEDO/Q) sind dezidierte Systemkomponenten Möglichkeit, asynchrone Aufrufe abzusetzen: tpacall() bzw. die Ergebnisse eines asynchronen Aufrufs abzuholen: tpgetrply() Intern werden Queues verwendet, um Load Balancing durchzuführen (auch für synchrone Aufrufe) CORBA: Event Service und Notification Service (gehören beide zu den im Standard definierten Common Object Services) Ermöglichen Publish/Subscribe-Interaktionen Asynchrone Methodenaufrufe, i.d.r. ohne persistente Queues Kapitel 6: Vorlesung MOM 5

6 Verbreitung von MOM OTM: Messages sind zusammen mit Transaktionen und Objekten zentraler Bestandteil aller Objekt-Transaktions- Monitore COM+: Neben COM/DCOM und dem MS Transaction Server (MTS) gehört auch MS Message Queues (MSMQ) zum COM+Paket EJB: Unterstützung des Java Message Services (JMS) Sowohl point-to-point als auch Publish/Subscribe-Interaktionen zwischen Client- und Server-Objekten möglich Zusätzlich: MOM-Funktionalität implementiert als separates Software Paket, z.b. IBM MQSeries (zusammen mit Workflow Management-Unterstützung) Kapitel 6: Vorlesung MOM 6

7 6.2 Queued Transactions Clients Server Ziel: Messages bzw. Aufträge werden dauerhaft zwischengespeichert (persistente Queues) und überstehen somit auch System-Crashes Mehrere Clients können konkurrierend auf die Queue zugreifen Enqueue: Einfügen in die Queue Analog können auch mehrere Server konkurrierend die Queue auslesen Dequeue: Messages aus der Queue nehmen Kapitel 6: Vorlesung MOM 7

8 Garantierte Ausführung Das persistente Festschreiben von Messages in der Queue verhindert lediglich, dass Messages beim Crash der Queue verloren gehen Was passiert aber bei Server-Fehlern während der asynchrone Request bearbeitet wird? Im synchronen Fall ist dies kein Problem, das es zu einem Rollback der gesamten Transaktion führt Im asynchronen Fall muss das Enque bzw. Dequeue von Aufträgen atomar sein, d.h. muss in kurzen, aber verteilten Transaktionen zwischen Client und Queue sowie zwischen Queue und Server erfolgen Garantierte Ausführung (exactly once) duch Implementierung asynchroner Client/Server-Aufrufe als Folge dreier unabhängiger Transaktionen (Queued Transactions) 1. Client stellt Message zusammen, fügt diese in die Queue ein und führt Commit durch 2. Server entnimmt die Message, führt den Aufruf aus, legt die Antwort in die Antwort-Queue und führt Commit durch 3. Client entnimmt die Antwort aus der Antwort-Queue und führt Commit durch Kapitel 6: Vorlesung MOM 8

9 Garantierte Ausführung Request Queue Clients Server Reply Queue Transaktion 1: Einfügen in Queue Transaktion 2: Auftrag ausführen Transaktion 3: Antwort entnehmen Kapitel 6: Vorlesung MOM 9

10 Queued Transactions: Recovery Fehler können jetzt einfach behoben werden Server-Fehler Abbruch von Transaktion 2 belässt den Auftrag in der Request Queue Kann von anderem Server bzw. nach Wiederhochfahren bearbeitet werden Client-Fehler Zustand der Bearbeitung kann jederzeit über die Inhalte der Request- bzw. Reply-Queue überprüft werden Voraussetzung: Jeder Auftrag erhält eine eindeutige ID, die Request Queue verwaltet zusätzlich die höchste ID angenommener Aufträge pro Client ID max (C) Nach dem Aufstarten: Client überprüft, ob der Auftrag in einer der beiden Queues liegt (wenn dies der Fall ist, dann: Warten Request Queue oder Antwort abholen Reply Queue). Ansonsten: Falls ID > ID max (C): Auftrag nochmals abschicken Falls ID ID max (C): Warten, da Auftrag gerade in Bearbeitung Kapitel 6: Vorlesung MOM 10

11 6.3 Publish/Subscribe-Techniken Weitere Verallgemeinerung der asynchronen Kommunikation: neben der zeitlichen und räumlichen Entkopplung von Sender und Empfänger werden die Empfänger anonym Zentraler Bestandteil: Publish/Subscribe-Broker Empfänger müssen ihre Interessen beim Broker registrieren (subscription) Sender publiziert Nachrichten bzw. veröffentlicht Ereignisse, diese werden automatisch an die Empfänger weitergeleitet Sender müssen sich nicht um die Adressierung sämtlicher Empfänger kümmern Verwendung von Publish/Subscribe-Techniken zumeist für ereignisgesteuerte, lose Kommunikation zwischen Komponenten Sender veröffentlicht lediglich Ereignisse, erwartet keine Antwort Gut geeignet, um komplexe Abläufe wie z.b. Workflows über verteilten Komponenten hinweg zu implementieren Kapitel 6: Vorlesung MOM 11

12 Varianten von Publish/Subscribe-Interaktionen (1) Art der Beschreibung von Nachrichten bzw. Events Topics-basiert vs. Content-basiert Topics-basiertes Publish/Subscribe Voraussetzung: festgelegtes Vokabular für die Beschreibung von Nachrichten/Events durch Topics Meistens Verwendung eines hierarchischen Namensraums Dadurch jedoch recht unflexibel Realisierung Pro Topic ein eigener Kanal, eine eigene Queue, bzw. ein eigenes Interface (bei objektorientierter Implementierung) Content-basiertes Publish/Subscribe Nachrichten sind selbstbeschreibend Dadurch: viel flexibler, es wird kein gemeinsames Vokabular mehr benötigt Kapitel 6: Vorlesung MOM 12

13 Topics-basiertes Publish/Subscribe Subscriber Publisher ZH.Kultur.Theater ZH.Politik ZH.Kultur Publish/Subscribe Broker Kapitel 6: Vorlesung MOM 13

14 Content-basiertes Publish/Subscribe Subscriber Publisher Die Hamlet-Aufführung von Christoph Schlingensief im Pfauen, die im Vorfeld mit grossen Protesten seitens der SVP verbunden war, hatte gestern Premiere.. SVP, Protest Theater, Schauspielhaus Publish/Subscribe Broker Kapitel 6: Vorlesung MOM 14

15 Varianten von Publish/Subscribe-Interaktionen (2) Unterschiedliche Topologien eines Publish/Subscribe- Systems Dezentraler Ansatz: Peer-to-peer Nachricht/Event wird über Broadcast-Mechanismen veröffentlicht Jeder potentielle Empfänger muss sich die gewünschten Informationen selbst herausfiltern Grosser Kommunikationsoverhead z.b. TIB/Rendezvous, kommerzielles Publish/Subscribe-System von TIBCO Zentraler Broker Bus-Architektur, z.b. CORBA Event Service Hub-and-Spoke: Publish/Subscribe-Broker & (persistente) Queues (z.b. MQSeries von IBM) Kapitel 6: Vorlesung MOM 15

16 Bus-Architektur App App event event Event Broker event.. Subscriptions App Queues Filters App Log Publishers Adapters Business rules Adapters Subscribers event ORB Routers Load-balancing event event App App nach OHE99 Figur 8-10 Kapitel 6: Vorlesung MOM 16

17 Varianten von Publish/Subscribe-Interaktionen (3) Art der Filterung Global beim Broker Möglichkeit der Angabe von zusätzlichen Filterprädikaten bei der Subscription Broker überprüft diese Prädikate bevor eine Nachricht an den Empfänger weitergeschickt wird Lokal beim Empfänger Nachrichten werden (nach Topic bzw. Content) weitergeleitet. Zusätzliche Überprüfungen muss der Empfänger durchführen Ist bei dezentralen Ansätzen zwangsläufig der Fall Verteilung der Nachrichten Push: automatische Verteilung Pull: Empfänger muss explizit nachschauen, ob in der Queue, die seiner Subscription entspricht, Einträge eingegangen sind Kapitel 6: Vorlesung MOM 17

18 Varianten von Publish/Subscribe-Interaktionen (4) Persistenz Nicht-persistente Queues Events werden veröffentlicht und gleich weitergeleitet, falls Subscriber vorhanden sind, ansonsten verpuffen sie Es werden nur Events versandt, die nach der Subscription veröffentlicht worden sind Persistente Queues Publish/Subscribe-Broker speichert Events dauerhaft Subscriber können also bereits bei der Subscription auf archivierte Informationen zurückgreifen In vielen Produkten ist die Persistenz/Nicht-Persistenz eine Eigenschaft der Nachricht (d.h. der Publisher kann bestimmen, ob eine Nachricht dauerhaft gemacht werden soll oder nicht) Transaktionsunterstützung Transaktionslose Übertragung vs. Übertragung in Form von Queued Transactions Kapitel 6: Vorlesung MOM 18

19 Varianten von Publish/Subscribe-Interaktionen (5) Anzahl der Empfänger Events werden allen Subscribern zugänglich gemacht (gemäss Topic bzw. Content) Dies ist der Fall bei Nachrichtenaustausch über Publish/Subscribe Events werden lediglich einem Subscriber geschickt Auswahl des Empfängers aufgrund deren Auslastung Ziel: Load balancing (z.b. Queues in TP-Monitoren) Kapitel 6: Vorlesung MOM 19