Nachrichtenreihenfolge

Die Nachrichtenreihenfolge ist für einige asynchrone Messaging-Anwendungen wichtig, d. h., es ist wichtig, dass die Nachrichten in derselben Reihenfolge konsumiert werde, in der der Erzeuger sie sendet. Wenn dieser Typ von Nachrichtenreihenfolge für Ihre Anwendung wichtig ist, muss dies im Design berücksichtigt werden.

Eine Messaging-Anwendung, die Sitzplatzreservierungen verarbeitet, kann beispielsweise Erzeugerkomponenten und eine Konsumentenkomponente haben. Eine Erzeugerkomponente sendet eine Nachricht an die Konsumentenkomponente, wenn ein Kunde einen Sitzplatz reserviert. Wenn der Kunde die Reservierung storniert, sendet derselbe Erzeuger (oder möglicherweise auch ein anderer Erzeuger) eine zweite Nachricht. Gewöhnlich muss die Konsumentenkomponente die erste Nachricht (in der der Sitzplatz reserviert wird) verarbeiten, bevor sie die zweite Nachricht (in der die Reservierung storniert wird) verarbeitet.

Einige Anwendungen verwenden ein synchrones Muster (Anforderung-Antwort), bei dem der Erzeuger auf eine Antwort zu jeder Nachricht wartet, bevor er die nächste Nachricht sendet. Bei diesem Typ von Anwendung steuert der Konsument die Reihenfolge, in der er die Nachrichten empfängt, und kann so sicherstellen, dass dies dieselbe Reihenfolge ist, in der die Nachrichten vom Erzeuger bzw. von den Erzeugern gesendet werden. Andere Anwendungen verwenden ein asynchrones Muster (Senden und Vergessen), bei dem der Erzeuger Nachrichten sendet, ohne auf Antworten zu warten. Selbst bei diesem Typ von Anwendung wird die Reihenfolge gewöhnlich beibehalten, d. h., ein Konsument kann davon ausgehen, dass er Nachrichten in derselben Reihenfolge empfängt, in der sie von Erzeugern gesendet werden. Dies gilt insbesondere dann, wenn zwischen aufeinander folgenden Nachrichten eine erhebliche Zeitspanne liegt. Im Design müssen Faktoren, die diese Reihenfolge unterbrechen könnten, jedoch berücksichtigt werden.

Die Reihenfolge der Nachrichten wird unterbrochen, wenn Ihre Anwendung Nachrichten mit unterschiedlichen Prioritäten sendet (Nachrichten mit einer höheren Priorität können Nachrichten mit einer niedrigeren Priorität überholen) oder wenn Ihre Anwendung aufgrund der Spezifikation von Nachrichtenselektoren explizit eine andere als die erste in der Reihenfolge empfängt. Es können sich aber auch Parallelverarbeitung und Fehler- bzw. Ausnahmebehandlung auf die Nachrichtenreihenfolge auswirken.

Parallelverarbeitung

Mehrere Ziele
Wenn ein Erzeuger eine Nachricht an ein Ziel sendet und anschließend eine zweite Nachricht an ein anderes Ziel sendet, ist es möglich, dass die zweite Nachricht an ihrem Ziel ankommt, bevor die erste Nachricht ihr Ziel erreicht. Dieser Fall kann auch dann eintreten, wenn der Erzeuger beide Nachrichten in derselben Transaktion sendet (die Transaktion stellt sicher, dass beide Sendevorgänge scheitern oder beide Sendevorgänge abgeschlossen werden, aber die Zustellreihenfolge wird nicht gewährleistet). Sollte dies ein Problem für Ihre Anwendung darstellen, sollten Sie die Verwendung mehrerer Ziele für diese Anwendung vermeiden.
Mehrere Erzeuger
Wenn ein Erzeuger eine Nachricht an ein Ziel sendet und anschließend ein zweiter Erzeuger eine zweite Nachricht an dasselbe Ziel sendet, ist es möglich, dass die zweite Nachricht vor der ersten Nachricht am Ziel ankommt. Dieser Fall kann auch dann eintreten, wenn sich der zweite Erzeuger mit dem ersten Erzeuger synchronisiert, z. B., indem er auf ein Signal des ersten Erzeugers gewartet wird, bevor er seine Nachricht (die zweite) sendet. Es kann auch dann passieren, wenn die Erzeuger transaktionsorientiert sind (die Tatsache, dass eine Transaktion abgeschlossen ist, bedeutet nicht, dass sich die Nachrichten am Ziel befinden - die Serviceintegration kann eine Transaktion zuerst abschließen und die Nachrichten zu einem späteren Zeitpunkt zustellen). Sollte dies ein Problem für Ihre Anwendung darstellen, sollten Sie die Verwendung mehrerer Erzeuger für diese Anwendung vermeiden. Die Verwendung eines einzigen Erzeugers, der in mehreren parallelen Threads ausgeführt wird, sollte ebenfalls vermieden werden.
Mehrere Konsumenten
Wenn zwei Nachrichten an einem Warteschlangenziel ankommen und mehrere Konsumenten vorhanden sind, ist es möglich, dass ein Konsument die erste Nachricht und ein anderer Konsument die zweite Nachricht empfängt. Können die Konsumenten parallel ausgeführt werden können, verarbeitet der Konsument, der die zweite Nachricht empfängt, diese möglicherweise verarbeiten, bevor der andere Konsument die erste Nachricht verarbeitet. Wenn ein Konsument eine Nachricht transaktionsgesteuert empfängt und die Transaktion anschließend rückgängig macht, wird die Nachricht an das Ziel zurückgegeben, an dem ein anderer Konsument sie empfangen kann. Mittlerweile kann dieser andere Konsument bereits andere (spätere) Nachrichten empfangen und verarbeitet haben. Sollte dies ein Problem für Ihre Anwendung darstellen, sollten Sie die Verwendung mehrerer Konsumenten für diese Anwendung vermeiden. Mehrere MDB-Aufrufe pro Endpunkt sollten ebenfalls nicht zugelassen werden (siehe MDB-Regulierung für den Standard-Messaging-Provider konfigurieren). Alternativ können Sie die Verwendung einer strikt einzuhaltenden Nachrichtenreihenfolge in Betracht ziehen (siehe Strikte Nachrichtenreihenfolge für Busziele).
Clustering und partitionierte Ziele
Wenn ein Warteschlangenziel einem Busmember des Typs "Cluster" mit mehreren Messaging-Engines zugeordnet wird, enthält jede Messaging-Engine eine Partition des Ziels (d. h. einen der Warteschlangenpunkte des Ziels). Die Serviceintegration kann verschiedenen Partitionen verschiedene Nachrichten für dieses Ziel zustellen. Diese Konfiguration des Warteschlangenziels kann eine erweiterte Verfügbarkeit, Skalierbarkeit und Lastausgleich bereitstellen, eignet sich aber gewöhnlich nicht für Anwendungen, in denen die Nachrichtenreihenfolge von Bedeutung ist. Die Serviceintegration gewährleistet nicht die Reihenfolge von Nachrichten, die an verschiedene Partitionen desselben Ziels gesendet werden. Eine Messaging-Engine kann ausfallen, während sich Nachrichten in der Zielpartition befinden, in der sich die Engine befindet. Diese Nachrichten stehen Konsumenten erst nach dem Neustart der Messaging-Engine zur Verfügung. Die Serviceintegration kann mit der Zustellung neuerer Nachrichten an andere Partitionen (in anderen Messaging-Engines) fortfahren, und Konsumenten können diese neueren Nachrichten vor älteren Nachrichten in der Partition der ausgefallenen Messaging-Engine empfangen und verarbeiten. Der Artikel Lastausgleich bei Warteschlangenzielen enthält weitere Einzelheiten zu diesem Konfigurationstyp. Außerdem wird die Verwendung der Option "Nachrichtenaffinität" erläutert, mit der die Nachrichtenreihenfolge zwischen einem einzelnen Erzeuger und einem einzelnen Konsumenten in einem Cluster aufrecht erhalten werden kann (dies gilt jedoch nicht, wenn sich der Cluster in einem anderen Service Integration Bus befindet).
Publish/Subscribe
Beim Publish/Subscribe-Messaging gewährleistet die Serviceintegration nicht die Reihenfolge der Nachrichten, die von verschiedenen Instanzen einer Subskription empfangen werden, einschließlich separater Instanzen einer permanenten Subskription, die mit der Einstellung "Gemeinsame Nutzung zulassen" für die Eigenschaft "Permanente Subskriptionen gemeinsam nutzen" erstellt wurden.

Fehler und Ausnahmebedingungen

Servicequalität
Die Servicequalität für eine Nachricht bestimmt, wie sich Fehler und Ausnahmebedingungen auf die Zustellung der Nachricht auswirken können (siehe Nachrichtenzuverlässigkeitsstufen - JMS-Zustellmodus und Servicequalität der Serviceintegration). Je nach Servicequalität kann ein Fehler oder eine Ausnahmebedingung bewirken, dass die Serviceintegration die Nachricht zuverlässig (genau einmal) oder weniger zuverlässig (mehr als einmal oder gar nicht) zustellt. Bei der Servicequalität "Express, nicht persistent" ist es beispielsweise möglich, dass Nachrichtenfolgen nach einem Fehler erneut zugestellt werden. Die zugrunde liegende Reihenfolge der Nachrichtenfolgen wird jedoch immer beibehalten, sodass Nachrichten in der Reihenfolge 1, 2, 3, 2, 3, 4 ankommen können. Allgemeiner gesagt, die Serviceintegration garantiert nicht die Einhaltung der Reihenfolge verschiedener Nachrichten, die mit unterschiedlichen Servicequalitäten gesendet werden. Wenn dies ein Problem für Ihre Anwendung darstellt, müssen Sie unbedingt eine entsprechende Servicequalität auswählen und vermeiden, unterschiedliche Servicequalitäten für Nachrichten an dasselbe Ziel zu verwenden.
Ausnahmeziele
In bestimmten Fehlerszenarien kann die Serviceintegration eine Nachricht einem Ausnahmeziel zustellen oder eine Nachricht einem Ziel zustellen und sie anschließend an ein Ausnahmeziel übertragen. Die Serviceintegration gewährleistet nicht die Reihenfolge von Nachrichten, die sie an ein Ausnahmeziel sendet oder überträgt. Wenn dies ein Problem für Ihre Anwendung darstellt, können Sie das Ziel so konfigurieren, dass es kein Ausnahmeziel verwendet (siehe Ausnahmeziele). Wenn sich der Erzeuger und das Ziel in unterschiedlichen Bussen befinden, können Sie die Verbindungen zwischen diesen Bussen ohne Ausnahmeziel konfigurieren (siehe Fremde Busse und Ausnahmezielverarbeitung für eine Verbindung zu einem fremden Bus konfigurieren).
Transaktions-Rollback
Die Aktivierungsspezifikation für eine Message-driven Bean (MDB) kann eine Verzögerung zwischen fehlschlagenden Nachrichtenwiederholungen spezifizieren. Diese Verzögerung räumt eine gewisse Zeit für die Behebung der Fehlerbedingung, die zum Rollback geführt hat, ein, bevor dieselbe Nachricht die MDB erneut ansteuert. Während die Nachricht auf diese Weise verzögert wird, kann jedoch eine andere (spätere) Nachricht die MDB ansteuern (siehe MDB-Anwendung vor Problemen mit Systemressourcen schützen). Sollte dies ein Problem für Ihre Anwendung darstellen, können Sie die maximal zulässige Anzahl aufeinander folgender Fehler auf eins beschränken (siehe JMS-Aktivierungsspezifikation [Einstellungen]) oder die Option für die strikte Einhaltung der Nachrichtenreihenfolge verwenden (siehe Strikte Nachrichtenreihenfolge für Busziele).
Unbestätigte Transaktionen auflösen
Bei der zweiphasige Festschreibungsverarbeitung kann eine Anwendung fehlschlagen, während eine JMS-Sende- oder -Empfangsoperation einen unbestätigten Status hat. In einem solchen Fall kann die Anwendung erneut gestartet werden, bevor der unbestätigte Status aufgelöst wurde, sodass eine oder mehrere Nachrichten beim Neustart der Anwendung "unsichtbar" sind, aber später "sichtbar" werden. Andere Nachrichten an das Ziel sind nicht betroffen. Eine konsumierende Anwendung kann eine Nachricht (z. B. Nachricht 2) empfangen, die logisch einer "unsichtbaren" Nachricht (z. B. Nachricht 1) folgt. Später, nach der Auflösung der unbestätigten Transaktion, empfängt die Anwendung die zuvor "unsichtbare" Nachricht (Nachricht 1). Auf diese Weise kann die Anwendung Nachrichten in der falschen Reihenfolge empfangen und verarbeiten. Sollte dies ein Problem für Ihre Anwendung darstellen, können Sie die Option für die strikte Einhaltung der Nachrichtenreihenfolge verwenden (siehe Strikte Nachrichtenreihenfolge für Busziele).

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjj8000_
Dateiname:cjj8000_.html