Download - 10 Nachrichtenorientierte Middleware
vs10 1
10 Nachrichtenorientierte Middleware
vs10 2
10.1 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 vonInformationen (mobile Geräte!)
Dienst für Vermittlung und persistente Zwischenspeicherung E-mail?
vs10 3
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“
vs10 4
Informationsfluss: Quelle SenkeAufruf: Klient DienstAufruf: Dienst Klient (Rückruf, callback)
Erzeuger Dienst Verbraucher(producers) (consumers)
Kanäle, Schlangen, mailboxes, topics, subjects, ...
.
.
.
.
.
....
vs10 5
10.1.1 Nachrichtendienste
Typisches Nachrichten/Ereignis-Modell
class Message {String header; // message kind etc.int priority; // overrides FIFO handlingMap 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
vs10 6
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
vs10 7
10.1.2 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 Interessentenzugestellt, nicht durch einen „weggenommen“
vs10 8
í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}
vs10 9
Beachte : Verbraucherseitig handelt es sich um eineasynchrone 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 Operationenput und get enthalten
Beachte : Nachrichten werden nicht gespeichert, sondern gleichweitergegeben; was vor dem Abonnieren passiert warerfährt der Verbraucher nicht – es sei denn:
Nachrichten tragen eine Angabe Lebensdauer (time-to-live) und werden entsprechend aufbewahrt und weitergereicht
vs10 10
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)
: Wirkungsrichtung grün: Pufferung erforderlichrot: permanentes Polling
vs10 11
10.2 IBM MQSeries
(Bestandteil des IBM Application Server WebSphere)
Host
Queue Manager . . .
Queue Manager . . .
Klient
Host
Modell
vs10 12
int mqInit()
Initialisierung der MQ-Bibliothek
int mqConnect(String queueManager, String host, String channel)
Herstellung einer logischen Verbindungzu einem Queue Manager auf der angegebenen Stationund Ablieferung einer Berechtigung (handle) dafür
int mqDisconnect(int qmHandle)
Lösen der Verbindung zum angegebenen QueueManager;qmHandle ist danach ungültig.
vs10 13
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 angegebenenQueueManager; qHandle ist danach ungültig.
vs10 14
int mqSend(int qmHandle, int qHandle, String message)
hängt eine Nachricht an die angegebene Queuebeim 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 angegebenenZeit (in Zehntelsekunden) vorhanden und nicht größer alsdie angegebene Länge- sonst Fehler
int mqSendOpt(...) dsgl. mit verschiedenen Optionen,
String mqGetOpt(...) z.B. Warten auf bestimmte Nachrichtenart
vs10 15
10.3 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 !
vs10 16
10.3.1 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
PushConsumerpush
pullpull
push
vs10 17
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.
PushSupplier PushConsumerpush push
vs10 18
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 pullpull
vs10 19
PushSupplier
PullConsumerPullSupplier
PushConsumerpush
pullpull
push
Channel
Kanal wird über 4 verschiedene Schnittstellen angesprochen:
ProxyPushConsumer ProxyPushSupplier ProxyPullConsumer ProxyPullSupplier
vs10 20
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
vs10 21
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)
vs10 22
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
}
vs10 23
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.
vs10 24
10.3.2 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