Standardmäßig löscht ein Broker eine Veröffentlichung, nachdem er sie an alle
Subskribenten gesendet hat. Ein Publisher kann jedoch angeben, dass der Broker eine Kopie einer
Veröffentlichung speichern 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. Das heißt, ein neuer Subskribent muss 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 keine Notwendigkeit für ständige Veröffentlichungen,
weil die Veröffentlichungen ohnehin sofort nach ihrem Erscheinen an alle Subskribenten geliefert
werden.
Veröffentlichungen, die Statusinformationen enthalten, müssen auch dann nicht 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.
Sie bewirkt, dass der Broker einem Subskribenten nur dann Veröffentlichungen sendet, wenn dieser
eine Aktualisierung anfordert. Der Broker sendet dem Subskribenten dann die aktuelle ständige
Veröffentlichung entsprechend seiner Subskription.
- Können ständige Veröffentlichungen mit einmaligen Veröffentlichungen für dasselbe Thema
kombiniert werden?
Dies 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 mehrere Anwendungen ständige Veröffentlichungen zu demselben Thema bereitstellen?
Es wird nicht empfohlen, dass mehrere Anwendungen ständige Veröffentlichungen zu
demselben Thema bereitstellen. 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. Dies 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. Dies verringert
den Durchsatz. Wenn die Veröffentlichungen sehr umfangreich sind, wird viel Plattenspeicherplatz
benötigt, 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 Message Broker geliefert werden, enthalten den Service 'Soccer
Results'. 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.
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.