WS-Notification-Topologien
Diese WS-Notification-Implementierung kann eine Reihe unterschiedlicher Topologien unterstützen.
Durch die
Implementierung von WS-Notification in WebSphere Application Server können Sie Folgendes erreichen:
- Vorhandene Serviceintegrationstechnologien und Web-Service-Komponenten für die Bereitstellung der WS-Notification-Funktionalität verwenden.
- Interoperation mit anderen Publish/Subscribe-Messaging-Clients (z. B. Java™ Message Service (JMS), IBM MQ) und alternativen Nachrichtenbrokerprodukten.
- Unterstützung eines bedarfsbasierten Veröffentlichungsmuster (Demand Based Publisher).
- Administrative Definition einer WS-Notification-Subskription
für einen externen Benachrichtigungserzeuger:
- Subskription von anderen WS-Notification-Brokerimplementierungen und eingebundenen Brokern.
- Vorabdefinition einer Liste von Subskriptionsinformationen, die beim Systemstart zum Erstellen der entsprechenden Subskriptionen verwendet werden..
- Implementierung eines WS-Notification-NotificationBroker in Konfigurationen mit hoher Verfügbarkeit und Lastausgleich.
In WebSphere Application Server ermöglicht WS-Notification außerdem den Austausch von Ereignisbenachrichtigungen zwischen WS-Notification-Anwendungen und anderen Clients des Service Integration Bus. Beim Einsatz weiterer SIB-Funktionen können Sie diese Funktion auch verwenden, um Nachrichten mit anderen IBM Publish/Subscribe-Brokern auszutauschen.
Eine Übersicht über jede Topologie, die von dieser WS-Notification-Implementierung unterstützt wird, finden Sie in den folgenden Artikeln:
- Einfache Web-Service-Topologie. In dieser Topologie wird WebSphere Application Server ausschließlich als Notification-Broker verwendet, damit erzeugende und konsumierende WS-Notification-Anwendungen miteinander kommunizieren können. Die Anwendungen wissen nicht, dass der NotificationBroker-Service von WebSphere Application Server implementiert wird.
- Topologie für WS-Notification als Einstiegs- oder Ausstiegspunkt für den Service Integration Bus. Die in WebSphere Application Server bereitgestellte WS-Notification-Unterstützung ermöglicht nicht nur den Austausch zwischen WS-Notification-Erzeugern und -Konsumenten, sondern dient auch als Einstiegs- oder Ausstiegspunkt für den Service Integration Bus. Von WS-Notification-Anwendungen veröffentlichte Ereignisbenachrichtigungen werden in den Service Integration Bus eingefügt, wo sie geändert, umgeleitet oder von anderen Anwendungen, die mit dem Bus verbunden sind, konsumiert werden können. Gleichermaßen können die von SIB-Clients wie JMS gesendeten Veröffentlichungen von WS-Notification-Konsumenten empfangen werden.
- Netzimplementierung einer WS-Notification-Topologie. Diese Topologie ermöglicht, einen WS-Notification-Service in mehreren Servern einer WebSphere Application Server Network Deployment-Umgebung zu implementieren. In diesem Muster können Anwendungen eine Verbindung zu jedem WS-Notification-Servicepunkt herstellen und diese identisch verwenden, wenn sie Benachrichtigungen einfügen, weil WS-Notification-Topic-Namespaces von allen WS-Notification-Servicepunkten des WS-Notification-Service gemeinsam genutzt werden. Benachrichtigungen werden über den Bus an alle interessierten NotificationConsumers weitergegeben, unabhängig von der Position, an der sie mit dem Bus verbunden sind (d. h. unabhängig vom zugehörigen WS-Notification-Servicepunkt).
- WS-Notification in einer Clusterumgebung:
- Topologie mit Lastausgleich. In dieser Topologie sorgt der Administrator dafür, dass die Anforderungen von Clientanwendungen auf mehrere Server in der Zelle verteilt werden, ohne dabei einen bestimmten Server zu überlasten. Dies setzt voraus, dass alle WS-Notification-Servicepunkte des WS-Notification-Service als identisch betrachtet werden können, insbesondere dass alle Topic-Namespaces an jedem WS-Notification-Servicepunkt des Brokers verfügbar sind.
- Topologie mit hoher Verfügbarkeit. In dieser Topologie erstellt der Administrator einen Cluster von Servern mit einer einzigen Messaging-Engine und einem WS-Notification-Servicepunkt, um sicherzustellen, dass bei einem Ausfall des Servers, der die Messaging-Engine enthält, die von dieser Engine verwalteten Ressourcen (Subskriptionen, Ereignisbenachrichtigungen) für die fernen Anwendungen verfügbar bleiben. Die Messaging-Engine wird so konfiguriert, dass sie von den Servern im Cluster übernommen werden kann (Failover), um einen Betrieb mit hoher Verfügbarkeit zu gewährleisten.
- Topologie mit Lastausgleich und hoher Verfügbarkeit. Diese Topologie ist eine Kombination der Topologie mit Lastausgleich und der Topologie mit hoher Verfügbarkeit. In dieser Topologie gibt es mehrere Messaging-Engines im Cluster (wobei die Anzahl der Messaging-Engines kleiner-gleich der Anzahl der Server ist). Erste Anforderungen, die vom Proxy-Server empfangen werden, werden gleichmäßig auf die Server im Cluster verteilt, die WS-Notification-Servicepunkte haben. Nachfolgende Anforderungen für eine Ressource, die von dieser Anforderung (d. h. einer Subskription) erstellt wurde, werden an die affine Messaging-Engine zurückgeleitet, selbst wenn diese von einem anderen Server im Cluster übernommen wird.
- Topologie für die Veröffentlichung von Ereignissen zwischen Zellen. Für die Implementierung dieser Topologie werden vorhandene Funktionen des Service Integration Bus verwendet. WS-Notification-Services werden in jeder der beiden Zellen konfiguriert, und es wird ein SIB-Link konfiguriert, um die SIB-Topicbereiche der beiden Busse miteinander zu verbinden.
- Veröffentlichung von Ereignissen zwischen Zellen über eine MQ-Netztopologie. In dieser Topologie wird die SIB-Infrastruktur verwendet, um Ereignisbenachrichtigungen zwischen zwei Zellen (Bussen) über ein Netz von IBM MQ-Warteschlangenmanagern zu übertragen.