Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Vs101 10 Nachrichtenorientierte Middleware. vs102 10.1 Nachrichten- und Ereignisdienste Motivation: ? Defizite objektorientierter verteilter Systeme ?

Ähnliche Präsentationen


Präsentation zum Thema: "Vs101 10 Nachrichtenorientierte Middleware. vs102 10.1 Nachrichten- und Ereignisdienste Motivation: ? Defizite objektorientierter verteilter Systeme ?"—  Präsentation transkript:

1 vs Nachrichtenorientierte Middleware

2 vs Nachrichten- und Ereignisdienste Motivation: ? Defizite objektorientierter verteilter Systeme ? Anderer Architekturstil sinnvoll für manche Anwendungen, z.B. Sensorsysteme, Unterstützung von Geschäftsprozessen,... Interaktion von Prozessen über Ereignisse, Nachrichten Pipes? TCP-Verbindungen? Keine festen Verbindungen zwischen Quellen und Senken von Informationen (mobile Geräte!) Dienst für Vermittlung und persistente Zwischenspeicherung ?

3 vs103 Selektive Entgegennahme durch die Empfänger Prioritäten, Filterung Zusammengehörige Sendungen als Bestandteile von Transaktionen Ereignisdienst (event service) Nachrichtendienst (message service) (beide Begriffe sehr ähnlich, fast synonym) Benachrichtigung über Ereignis

4 vs104 Informationsfluss:QuelleSenke Aufruf:KlientDienst Aufruf:DienstKlient (Rückruf, callback) Erzeuger DienstVerbraucher (producers)(consumers) Kanäle, Schlangen, mailboxes, topics, subjects,

5 vs Nachrichtendienste Typisches Nachrichten/Ereignis-Modell classMessage { String header;// message kind etc. int priority;// overrides FIFO handling Map properties;// for selective acceptance..... String payload;// e.g., XML text } bezieht sich nur auf wenige elementare Typen ( int,String,.. ) die hoffentlich in allen Teilsystemen bekannt sind und auf die jeweiligen Programmiersprachen abbildbar sind Typisches Kanal-Modell: Menge von Nachrichten

6 vs106 Schnittstelle eines Kanals: ínterface Channel { void put(Message msg); // erweitert die Nachrichtenmenge um msg Message get(); // entnimmt der Nachrichtenmenge eine Nachricht // - sobald vorhanden Message get(String filter); // entnimmt der Nachrichtenmenge eine Nachricht, // deren properties der Bedingung filter genügen // - sobald vorhanden } Beispiel für eine Bedingung: "temperature > 80" Typische Filtersprache: Teilsprache von SQL

7 vs Ereignisdienste Registrierung von Verbrauchern/Erzeugern beim Dienst ermöglicht aktivere Rolle des Dienstes (Erzeuger:) Ankündigen (publish) von Nachrichten (Ereignismeldungen, notifications) zu bestimmtem Gegenstand (subject, topic) (Verbraucher:) Abonnieren (subscribe) von Nachrichten Gegenstand Kanal – aber Nachricht wird allen Interessenten zugestellt, nicht durch einen weggenommen

8 vs108 ínterface Subject { void subscribe(Handler h, String filter); // sobald eine passende Nachricht eintrifft, // wird ein Thread erzeugt, der h.handle(msg) ausführt. // Beachte: dies geschieht für alle registrierten Abonnenten h ! void unsubscribe(Handler h); // Registrierung löschen void publish(Generator g); // g.generate() wird zu gewissen Zeitpunkten aufgerufen, // um beim Erzeuger die nächste Nachricht abzurufen void unpublish(Generator g); // Registrierung löschen }

9 vs109 Beachte :Verbraucherseitig handelt es sich um eine asynchrone Variante des Beobachter-Musters (vgl. auch Java-Ereignisbehandlung) Beachte :Erzeugerseitig handelt es sich um Polling, sofern generate bei Abwesenheit neuer Daten nicht blockiert Beachte :Die Schnittstelle könnte zusätzlich die Operationen put und get enthalten Beachte :Nachrichten werden nicht gespeichert, sondern gleich weitergegeben; was vor dem Abonnieren passiert war erfährt der Verbraucher nicht – es sei denn: Nachrichten tragen eine Angabe Lebensdauer (time-to-live) und werden entsprechend aufbewahrt und weitergereicht

10 vs1010 Klassifikation entsprechend dem Initiator des Informationsflusses: Push mode: Informationsfluss wird durch Quelle angestoßen Pull mode:Informationsfluss wird durch Senke angestoßen put (Push) handle (Push) generate (Pull) get (Pull) : Wirkungsrichtunggrün: Pufferung erforderlich rot:permanentes Polling

11 vs IBM MQSeries (Bestandteil des IBM Application Server WebSphere) Host Queue Manager... Queue Manager... Klient Host Modell

12 vs1012 int mqInit() Initialisierung der MQ-Bibliothek int mqConnect(String queueManager, String host, String channel) Herstellung einer logischen Verbindung zu einem Queue Manager auf der angegebenen Station und Ablieferung einer Berechtigung (handle) dafür int mqDisconnect(int qmHandle) Lösen der Verbindung zum angegebenen QueueManager; qmHandle ist danach ungültig.

13 vs1013 int mqOpenQueue(int qmHandle, String queue, int options) Öffnen einer Queue beim angegebenen Queue Manager, d.h. Beschaffen einer Berechtigung int mqCloseQueue(int qmHandle, int qHandle) Schließen der angegebenen Queue beim angegebenen QueueManager; qHandle ist danach ungültig.

14 vs1014 int mqSend(int qmHandle, int qHandle, String message) hängt eine Nachricht an die angegebene Queue beim angegebenen QueueManager an, falls noch Platz - sonst wird Fehlercode geliefert String mqGet(int qmHandle, int qHandle, int maxlen, int timeout) entnimmt eine Nachricht, sofern innerhalb der angegebenen Zeit (in Zehntelsekunden) vorhanden und nicht größer als die angegebene Länge - sonst Fehler int mqSendOpt(...) dsgl. mit verschiedenen Optionen, String mqGetOpt(...) z.B. Warten auf bestimmte Nachrichtenart

15 vs CORBA Notification Service (umfasst früheren Event Service) = hauptsächlich syntaktische Spezifikation von Schnittstellen mit wenig vorgeschriebener Semantik ! Kanal (channel) ist Umschlagplatz von Ereignismeldungen (event notifications) als Nachrichten. Nachrichtenquelle heißt supplier. Nachrichtensenke heißt consumer. Alle diese sind CORBA-Objekte mit gewissen Schnittstellen !

16 vs Event Service (Modul CosEventComm ) ! Für ein und denselben Kanal können Quellen und Senken wahlweise entweder im Pull- oder im Push-Modus arbeiten PushSupplier PullConsumerPullSupplier PushConsumer push pull push

17 vs1017 interface PushConsumer { void push(in any data) raises(Disconnected); void disconnect_push_consumer(); } // nach disconnect kein push mehr möglich interface PushSupplier { void disconnect_push_supplier(); } // nach disconnect kein push mehr möglich Ein PushSupplier ruft push auf, wird aber selbst nicht aufgerufen – es sei denn für ein disconnect. PushSupplierPushConsumer push

18 vs1018 interface PullSupplier { any pull() raises(Disconnected); any try_pull(out boolean has_event) raises(Disconnected); void disconnect_pull_supplier(); } // nach disconnect kein pull mehr möglich interface PullConsumer { void disconnect_pull_consumer(); } // nach disconnect kein pull mehr möglich Ein PullConsumer ruft pull auf, wird aber selbst nicht aufgerufen – es sei denn für ein disconnect. PullConsumerPullSupplier pull

19 vs1019 PushSupplier PullConsumerPullSupplier PushConsumer push pull push Channel Kanal wird über 4 verschiedene Schnittstellen angesprochen: ProxyPushConsumer ProxyPushSupplier ProxyPullConsumer ProxyPullSupplier

20 vs1020 interface ProxyPushConsumer : PushConsumer { void connect_push_supplier(in PushSupplier ps) raises(AlreadyConnected); } // erlaubt anschließendes push durch den Supplier // und gegebenenfalls disconnect durch den Kanal // (sofern nicht ps=nil ) interface ProxyPushSupplier : PushSupplier { void connect_push_consumer(in PushConsumer pc) raises(AlreadyConnected); } // ermöglicht pc.push durch den Kanal // und gegebenenfalls disconnect durch den Kanal

21 vs1021 interface ProxyPullConsumer : PullConsumer { void connect_pull_supplier(in PullSupplier ps) raises(AlreadyConnected); } // ermöglicht ps.pull durch den Kanal // und gegebenenfalls disconnect durch den Kanal interface ProxyPullSupplier : PullSupplier { void connect_pull_consumer(in PullConsumer pc) raises(AlreadyConnected); } // erlaubt anschließendes pull durch den Consumer // und gegebenenfalls disconnect durch den Kanal // (sofern nicht pc=nil )

22 vs1022 Kanal hat 2 Schnittstellen, über die man Zugriff auf die Schnittstellen erhält: interface ConsumerAdmin { ProxyPushSupplier obtain_push_supplier(); ProxyPullSupplier obtain_pull_supplier(); } interface SupplierAdmin { ProxyPushConsumer obtain_push_consumer(); ProxyPullConsumer obtain_pull_consumer(); } - und diese erhält man durch die Wurzel-Schnittstelle des Kanals: interface EventChannel { ConsumerAdmin for_consumers(); SupplierAdmin for_suppliers(); void destroy(); // Finalisierung des Kanals }

23 vs1023 Erzeugung eines Kanal-Objekts ist – wie üblich - nicht Gegenstand von CORBA Auffinden eines Kanal-Objekts verläuft wie üblich, z.B. über Namensdienst Zur Typisierung: - Die gezeigten push/pull -Operationen sind generisch. - Ein Modul CosTypedEventComm erlaubt Typfestlegung bei der Verbindungsherstellung. - Vorzuziehen ist aber der Notification Service.

24 vs Notification Service Erweiterung des Event Service um: Filterung von Ereignismeldungen (beliebige Filtersprachen + default constraint language) Steuerung der Dienstgüte (Reihenfolge, Zuverlässigkeit, Lebensdauer, …) Information über die Kommunikationspartner (z.B. Ist jemand an meinen Ereignissen interessiert?) Bessere Typisierung durch Structured Events Empfohlene Lektüre: Brose et al. 2001


Herunterladen ppt "Vs101 10 Nachrichtenorientierte Middleware. vs102 10.1 Nachrichten- und Ereignisdienste Motivation: ? Defizite objektorientierter verteilter Systeme ?"

Ähnliche Präsentationen


Google-Anzeigen