Kap. 6 Message-Oriented Middleware (MOM) G 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten G 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen G 6.3Publish/Subscribe-Techniken Entkopplung von Sendern und Empfängern von Nachrichten Kapitel 6: Vorlesung MOM 1 6.1 Asynchrone Prozedur- bzw. Methodenaufrufe G Bisher haben wir nur synchrone Prozedur- bzw. Methodenaufrufe betrachtet, gemäss der RPC-Idee: 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 G Gut geeignet für die Integration unterschiedlicher Komponenten in verteilte Transaktionen G 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 lahmlegen 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
Message-Oriented Middleware (MOM) G 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 G MOM: Message-Oriented Middleware Inftrastruktur 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 lication Service A DBMS A DB A Enqueue Dequeue execute B queue Client Enqueue queue execute A lication Service B Dequeue DBMS B DB B Kapitel 6: Vorlesung MOM 3 Message-Oriented Middleware (MOM) G 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
Verbreitung von MOM G MOM ist kein komplett orthogonaler Ansatz zu den bisher besprochenen IS-Infrastrukturkomponenten sondern mehr oder weniger gut versteckt überall vorhanden G 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) G 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 Verbreitung von MOM G 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 G 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
6.2 Queued Transactions Clients Server G Ziel: Messages bzw. Aufträge werden dauerhaft zwischengespeichert (persistente Queues) und überstehen somit auch System-Crashes G Mehrere Clients können konkurrierend auf die Queue zugreifen Enqueue: Einfügen in die Queue G Analog können auch mehrere Server konkurrierend die Queue auslesen Dequeue: Messages aus der Queue nehmen Kapitel 6: Vorlesung MOM 7 Garantierte Ausführung G Das persistente Festschreiben von Messages in der Queue verhindert lediglich, dass Messages beim Crash der Queue verloren gehen G 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 G Garantierte Ausführung (exactly once) duch Implementierung asynchroner Client/Server-Aufrufe als Folge dreier unabhängiger Transaktionen (Queued Transactions) Client stellt Message zusammen, fügt diese in die Queue ein und führt Commit durch Server entnimmt die Message, führt den Aufruf aus, legt die Antwort in die Antwort-Queue und führt Commit durch Client entnimmt die Antwort aus der Antwort-Queue und führtcommitdurch Kapitel 6: Vorlesung MOM 8
Garantierte Ausführung Request Queue Clients Server Reply Queue G Transaktion 1: Einfügen in Queue G Transaktion 2: Auftrag ausführen G Transaktion 3: Antwort entnehmen Kapitel 6: Vorlesung MOM 9 Queued Transactions: Recovery Fehler können jetzt einfach behoben werden G Server-Fehler Abbruch von Transaktion 2 belässt den Auftrag in der Request Queue Kann von anderem Server bzw. nach Wiederhochfahren bearbeitet werden G 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
6.3 Publish/Subscribe-Techniken G 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 G Verwendung von Publish/Subscribe-Techniken zumeist für ereignisgesteuerte, lose Kommunikation zwischen Komponenten Sender veröffentlicht lediglich Ereignisse, erwartet keine Antwort G Gut geeignet, um komplexe Abläufe wie z.b. Workflows über verteilten Komponenten hinweg zu implementieren Kapitel 6: Vorlesung MOM 11 Varianten von Publish/Subscribe-Interaktionen (1) G Art der Beschreibung von Nachrichten bzw. Events Topics-basiert vs. Content-basiert G 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) G Content-basiertes Publish/Subscribe Nachrichten sind selbstbeschreibend Dadurch: viel flexibler, es wird kein gemeinsames Vokabular mehr benötigt Kapitel 6: Vorlesung MOM 12
Topics-basiertes Publish/Subscribe Subscriber Publisher ZH.Kultur.Theater ZH.Politik ZH.Kultur Publish/Subscribe Broker Kapitel 6: Vorlesung MOM 13 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
Varianten von Publish/Subscribe-Interaktionen (2) G 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 Bus-Architektur Event Broker.. Subscriptions Queues Filters Log Publishers Adapters Business rules Routers Adapters Subscribers Load-balancing ORB nach OHE99 Figur 8-10 Kapitel 6: Vorlesung MOM 16
Varianten von Publish/Subscribe-Interaktionen (3) G 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 G 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 Varianten von Publish/Subscribe-Interaktionen (4) G 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) G Transaktionsunterstützung Geschieht die Übertragung in Form von Transaktionen (gemäss der Idee der Queued Transactions)? Wichtig für komplexe Anwendungen (wie z.b. Workflows mittels Publish/Subscribe-Techniken) Kapitel 6: Vorlesung MOM 18
Varianten von Publish/Subscribe-Interaktionen (5) G 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