Standardmäßig löscht ein Broker eine Veröffentlichung, nachdem er sie an alle
Subskribenten gesendet hat. Ein Publisher kann jedoch angeben, dass im Broker eine Kopie der Veröffentlichung verbleiben soll. Diese Kopie wird als ständige Veröffentlichung bezeichnet.
Der Broker sendet eine Kopie der ständigen Veröffentlichung an alle Subskribenten, die ihr
Interesse am Thema dieser Veröffentlichung anmelden. Deshalb muss ein neuer Subskribent nicht
darauf warten, dass Informationen erneut veröffentlicht werden, damit er sie erhält.
So
erhält beispielsweise ein Subskribent, der eine Subskription für einen Aktienkurs einrichtet,
sofort den zuletzt veröffentlichten Kurs und muss nicht warten, bis sich der Aktienkurs ändert und
erneut veröffentlicht wird.
Wenn in der Publish-Nachricht die Veröffentlichungsoption
RetainPub angegeben ist, wird die Veröffentlichung vom Broker als ständige
Veröffentlichung gespeichert, wobei eine früher gespeicherte ständige Veröffentlichung für das
betreffende Thema gegebenenfalls ersetzt wird.
Da der Broker nur eine einzige ständige
Veröffentlichung für jedes Thema und jeden Subskriptionspunktion speichert, wird die alte
Veröffentlichung gelöscht, sobald eine neue empfangen wird.
Wenn Sie daran denken, ständige
Veröffentlichungen zu verwenden, beachten Sie die folgenden Fragen:
- Enthalten Ihre Veröffentlichungen Statusinformationen oder Ereignisdaten?
Ereignisdaten werden in der Regel nicht ständig veröffentlicht,
Statusinformationen dagegen ja. Wenn jedoch alle Subskriptionen für ein Thema eingerichtet werden,
bevor Veröffentlichungen zu dem Thema erfolgen, und auch keine neuen Subskriptionen erwartet
werden, besteht auch für Statusinformationen kein Bedarf für ständige Veröffentlichungen,
weil die Veröffentlichungen ohnehin sofort nach ihrem Erscheinen an alle Subskribenten geliefert
werden.
Bei Veröffentlichungen, die Statusinformationen enthalten, ist es möglicherweise nicht erforderlich, dass sie als
ständige Veröffentlichungen gespeichert werden, wenn sie häufig (z. B. jede Sekunde) erfolgen. Bei
einer so häufigen Veröffentlichung erhält ein neuer Subskribent (oder ein Subskribent, der sich
nach einer Störung erneut anmeldet) die aktuellen Statusinformationen nahezu sofort nach
Einrichtung der Subskription.
- Möchten Sie Veröffentlichungen nur auf Anforderung empfangen?
Bei der Verwendung von ständigen Veröffentlichungen können Subskribenten in
der Nachricht zur Registrierung als Subskribent die Option PubOnReqOnly angeben. Deshalb sendet der Broker einem Subskribenten nur dann Veröffentlichungen, wenn dieser
eine Aktualisierung anfordert. Der Broker sendet daraufhin die aktuelle ständige Veröffentlichung an den Subskribenten, der der Subskription entspricht.
- Können ständige Veröffentlichungen mit einmaligen Veröffentlichungen zum selben Thema kombiniert werden?
Diese Option wird nicht empfohlen. Wenn es eine ständige Veröffentlichung
gibt und dann eine einmalige Veröffentlichung zu demselben Thema erfolgt, bleibt die vorhandene
ständige Veröffentlichung erhalten. Sie wird nicht durch die einmalige Veröffentlichung
aktualisiert. Wenn ein Subskribent in der Nachricht zum Anmelden als Subskribent die Option
PubOnReqOnly angibt, erhält er keine der einmaligen Veröffentlichungen. Denn der
Broker sendet ihm nur die aktuelle ständige Veröffentlichung als Antwort auf eine Anforderung zur
Aktualisierung.
- Können von mehreren Anwendungen ständige Veröffentlichungen zu dem gleichen Thema vorgenommen werden?
Es wird empfohlen, dass nur eine Anwendung ständige Veröffentlichungen zu
demselben Thema bereitstellt. Falls dies doch geschieht und Veröffentlichungen nahezu simultan
erfolgen, ist ungewiss, welche Veröffentlichung als ständige Veröffentlichung gespeichert wird. Wenn die Publisher verschiedene Broker verwenden, ist auf jedem Broker möglicherweise eine andere
ständige Veröffentlichung für dasselbe Thema gespeichert.
- Wie wird die Subskribentenanwendung nach einer Störung wiederhergestellt?
Wenn der Publisher keine ständigen Veröffentlichungen verwendet, muss die
Subskribentenanwendung die aktuellen Statusinformationen gegebenenfalls lokal speichern. Verwendet
der Publisher ständige Veröffentlichungen, kann der Subskribent eine Aktualisierung anfordern, um
die Statusinformationen nach einem Neustart auf den neuesten Stand zu bringen.
Der Broker sendet auch dann weiter Veröffentlichungen an einen
registrierten Subskribenten, wenn dieser nicht aktiv ist. Diese Option kann dazu führen, dass sich
Nachrichten in der Warteschlange des Subskribenten stauen. Ein solcher Stau kann dadurch vermieden
werden, dass der Subskribent in der Nachricht zum Anmelden als Subskribent die Option
PubOnReqOnly angibt. Der Subskribent muss die Statusinformationen dann
regelmäßig aktualisieren, indem er entweder eine Aktualisierung anfordert oder eine temporäre
dynamische Warteschlange verwendet.
- Wie wirken sich ständige Veröffentlichungen auf die Leistung aus?
Der Broker muss ständige Veröffentlichungen in einer Datenbank speichern. Diese Option verringert
den Durchsatz. Wenn die Veröffentlichungen sehr umfangreich sind, ist viel Plattenspeicherplatz
erforderlich, um die ständigen Veröffentlichungen für die einzelnen Themen zu speichern. In einer
Multibroker-Umgebung werden ständige Veröffentlichungen von allen anderen verbundenen Brokern,
denen eine entsprechende Subskription vorliegt, gespeichert.
Geben Sie im Feld Expiry des Nachrichtendeskriptors (MQMD) ein
Verfallsdatum für eine ständige Veröffentlichung an.
Die Beispielanwendungen, die mit
WebSphere Event
Broker geliefert werden, enthalten folgende Muster:
In diesem Beispielprogramm werden ständige Veröffentlichungen verwendet, um die aktuellen Spielstände der überwachten Fußballspiele zu erfassen. Der Mustercode zeigt die Programmierung, die erforderlich ist, um diese Option zu unterstützen.
Sie können Beispiele nur anzeigen, wenn Sie das Information Center
verwenden, das im Message
Brokers Toolkit integriert ist.
Nicht alle Anwendungen können ständige
Veröffentlichungen bereitstellen, und nicht für alle ständigen Veröffentlichungen kann ein
Verfallsdatum festgelegt werden. Die folgende Tabelle zeigt, welche Anwendungen ständige
Veröffentlichungen bereitstellen können und ob die ständigen Veröffentlichungen ein Verfallsdatum
haben können.
|
MQ |
SCADA |
JMS/IP |
Ständige Veröffentlichung |
JA |
JA |
NEIN |
Verfallsdatum |
JA |
NEIN |
NEIN |
Die Spalten in der Tabelle verweisen auf drei Anwendungstypen. Die erste Zeile gibt
an, ob eine Veröffentlichung als ständige Veröffentlichung gespeichert werden kann, und die zweite
Zeile gibt an, ob für die Veröffentlichung ein Verfallsdatum festgelegt werden kann.