Optionen für die Zuordnung eines permanenten Topic-Namespace zu einem Bustopicbereich

Wenn Sie einen permanenten Topicname in einem WS-Notification-Service konfigurieren, geben Sie einen SIB-Topicbereich an, in dem Nachrichten als Reaktion auf die WSN-Operation "Notify" veröffentlicht werden und aus dem sie empfangen werden, wenn sie mit einer Subskription übereinstimmen. Sie können Viele-zu-viele-Beziehungen zwischen den permanenten Topic-Namespaces, die in einer Zelle definiert sind (d. h. für alle in der Zelle definierten WS-Notification-Services), und den SIB-Topicbereichen erstellen, denen sie zugeordnet sind. Diese Beziehungen können je nach Topologie, die von den Anwendungen benötigt wird, die Verbindungen zu dem WS-Notification-Service herstellen, relativ komplex werden. In diesem Artikel wird beschrieben, in welchen Fällen welche Konfigurationen geeignet sind.

Die folgenden Optionen sind in aufsteigender Reihenfolge nach Komplexität beschrieben. Für alle Konfigurationen mit Ausnahme der "1:1"-Zuordnung müssen Sie im Vorfeld sorgfältige Überlegungen anstellen:

"1:1"-Zuordnung zwischen einem SIB-Topicbereich und einem Topic-Namespace-URI

In dieser Situation ist entweder nur ein WS-Notification-Service im Bus definiert, oder, wenn zwei WS-Notification-Services definiert sind, enthält der zweite Service keinen Topic-Namespace, der demselben SIB-Topicbereich zugeordnet ist.

Diese Konfiguration ermöglicht WS-Notification-Anwendungen, Ereignisbenachrichtigungen in den SIB-Topicbereich einzubringen (oder von diesem zu empfangen). Dazu gehören auch Benachrichtigungen, die von anderen Clients im Bus stammen.

In Situationen, in denen mehrere WS-Notification-Services in einem Bus definiert sind, gewährleistet diese "1:1"-Zuordnung die Trennung der Clients, die mit dem jeweiligen Service verbunden sind, d. h. Ereignisbenachrichtigungen, die durch die Verwendung des ersten WS-Notification-Service eingebracht werden, können nicht von Anwendungen empfangen werden, die mit dem zweiten WS-Notification-Service verbunden sind. Dieses Trennungsmuster ist einer der Gründe für das Erstellen von zwei WS-Notification-Services in demselben Bus.

"N:1"-Zuordnung zwischen einem SIB-Topicbereich und einem Topic-Namespace-URI

In diesem Fall ist ein einzelner Topic-Namespace-URI mehreren SIB-Topicbereichen zugeordnet. Eine solche Zuordnung ist nur möglich, wenn mehrere WS-Notification-Services definiert sind, weil ein Namespace-URI nur jeweils einem SIB-Topicbereich in einem WS-Notification-Service zugeordnet werden kann.

Dieser Ansatz sollte gewählt werden, wenn viele Clients denselben Namespace-URI verwenden und Sie einen Teil der Clients absondern möchten, sodass diese nicht mit den anderen Clients interagieren. Die genaue Rechtfertigung für diese Vorgehensweise richtet sich nach der vorliegenden Situation. Im Allgemeinen ist dies jedoch nicht erforderlich. Dieses Trennungsmuster ist der zweite (und ausschlaggebende) Grund für das Erstellen mehrerer WS-Notification-Services in einem Bus.

"1:N"-Beziehung zwischen einem SIB-Topicbereich und mehreren Topic-Namespace-URIs (in demselben WS-Notification-Service)

In dieser Situation sind mehrere permanente Topic-Namespaces in demselben WS-Notification-Service definiert, die auf denselben SIB-Topicbereich verweisen.

Die offensichtliche Grund für diese Vorgehensweise liegt darin, dass es zwei Gruppen von Anwendungen gibt, die bereits für die beiden unterschiedlichen URIs codiert sind, diese Anwendungsgruppen in irgendeiner Weise miteinander verbunden sind und Sie deshalb die Verwendung desselben SIB-Topicbereichs durch die beiden Anwendungen zulassen möchten. Die folgenden Gründe können vorliegen:
  • Die von den beiden Anwendungsgruppen verwendeten Topics überlappen nicht, möchten aber mit denselben Anwendungen interagieren, die keine WS-Notification-Anwendungen sind. Bei der Verwendung dieses Musters müssen die anderen Busanwendungen lediglich eine Verbindung zu einem Topicbereich herstellen, um Nachrichten von beiden Anwendungsgruppen zu empfangen.
  • Die von den beiden Anwendungsgruppen verwendeten Topics überlappen in irgendeiner Form, und Sie möchten, dass sie in der Lage sind, Veröffentlichungen zu empfangen, die von Anwendungen in der anderen Gruppe gesendet werden. Wenn die beiden Namespaces beispielsweise exakt dieselben Topics enthalten, aber der Namespace-URI an ein standardisiertes Namensschema angepasst wurde, würden die älteren Anwendungen den ursprünglichen Namen und die neuen Anwendungen den neuen Namen verwenden.
Ein zweiter Grund für die Definition mehrerer Topic-Namespaces in demselben WS-Notification-Service (mit demselben SIB-Topicbereich, aber unterschiedlichen Namespace-URIs) ist die Anwendung unterschiedlicher Topicbereichsdokumente für unterschiedliche Anwendungsgruppen. Die folgenden Gründe können vorliegen:
  • Die Topic-Namespaces stehen in keiner Verbindung zueinander, aber Sie möchten denselben SIB-Topicbereich verwenden, um die Verwaltungskosten für das Erstellen eines separaten SIB-Topicbereichs vermeiden. Normalerweise sollten Sie diese Vorgehensweise nur dann wählen, wenn die von den Namespaces verwendeten Topics nicht überlappen, da ansonsten Kollisionen zwischen den beiden Anwendungsgruppen auftreten können.
  • Topics, die in den Namespaces definiert sind, überlappen, und Anwendungen, die die Namespaces verwenden, möchten möglicherweise mit denselben Anwendungen, die keine WS-Notification-Anwendungen sind, interagieren. In einer solchen Situation verwenden Sie ein Topic-Namespace-Dokument, um das Subset von Topics für einen bestimmten Topic-Namespace (in einer Baumstruktur) zu definieren, und ordnen dieses Dokument einer bestimmten Gruppe von Anwendungen zu. Wenn die Topic-Namespace-Dokumente für zwei unterschiedliche Gruppen von Anwendungen eine überlappende Topicstruktur definieren, empfängt eine Anwendung, die keine WS-Notification-Anwendung ist und das überlappende Topic subskribiert, Benachrichtigungen, die von beiden Anwendungsgruppen veröffentlicht werden.

"1:N"-Beziehung zwischen einem SIB-Topicbereich und mehreren Topic-Namespace-URIs (in unterschiedlichen WS-Notification-Services)

Wenn Sie mehrere WS-Notification-Services definiert haben, können Sie äquivalente permanente Topic-Namespace-Definitionen in jedem Service erstellen, um Clients, die mit mit den WS-Notification-Services verbunden sind, dieselben Funktionen bereitzustellen. Dies könnte jedoch auf einfachere Weise erreicht werden, indem alle Anwendungen so konfiguriert werden, dass sie eine Verbindung zu den Servicepunkten eines einzelnen Service herstellen.

Unterschiedliche Busse mit denselben SIB-Topicbereichsnamen

Ein zusätzlicher Fall, der für Verwirrung sorgen kann, ist der, dass es zwei SIBs mit jeweils einem definierten WS-Notification-Services gibt, die identische SIB-Topicbereichsnamen enthalten. In dieser Situation sind die verwendeten Topicbereichsdefinition vollkommen getrennt voneinander, und deshalb gibt es keine Überlappung zwischen Anwendungen, die die beiden WS-Notification-Services verwenden. Sie sollten auf Verwirrung in dieser Situation vorbereitet sein und entsprechende Maßnahmen ergreifen.


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=cjwsn_ptn_options
Dateiname:cjwsn_ptn_options.html