10 Nachrichtenorientierte Middleware

1
10 Nachrichtenorientierte Middleware
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
von Informationen (mobile Geräte!) ? Dienst für
Vermittlung und persistente Zwischenspeicherung
? E-mail?
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
4
Erzeuger Dienst Verbraucher (producers) (
consumers)
. . .
. . .
. . .
Kanäle, Schlangen, mailboxes, topics, subjects,
...
Informationsfluss Quelle Senke Aufruf Klient
Dienst Aufruf Dienst Klient (Rückruf,
callback)
5
10.1.1 Nachrichtendienste
Typisches Nachrichten/Ereignis-Modell class Messa
ge String header // message kind etc. int
priority // overrides FIFO handling Map
properties // for selective acceptance ..... St
ring 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
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 gt 80" Typische
Filtersprache Teilsprache von SQL
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 Interessenten zuge
stellt, nicht durch einen weggenommen
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
9
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
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
erforderlich rot permanentes Polling
11
10.2 IBM MQSeries(Bestandteil des IBM
Application Server WebSphere)
Modell
Queue Manager . . .
Klient
Queue Manager . . .
Host
Host
12
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
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
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
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 !
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
PushConsumer
push
push
PullConsumer
PullSupplier
pull
pull
17
PushSupplier
PushConsumer
push
push
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.
18
PullConsumer
PullSupplier
pull
pull
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.
19
? ? Channel ? ?
PushSupplier
PushConsumer
push
push
PullConsumer
PullSupplier
pull
pull
Kanal wird über 4 verschiedene Schnittstellen
angesprochen ? ProxyPushConsumer ?
ProxyPushSupplier ? ProxyPullConsumer ?
ProxyPullSupplier
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 psnil) 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
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 pcnil)
22
Kanal hat 2 Schnittstellen, über die man
Zugriff auf die Schnittstellen ????
erhält interface ConsumerAdmin
ProxyPushSupplier obtain_push_supplier()
ProxyPullSupplier obtain_pull_supplier() interf
ace 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
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
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