Network Deployment (Distributed operating systems), v8.0 > Applications > Web services > WS-Notification
WS-Notification topologies
A number of different topologies can be supported by this WS-Notification implementation.
Through the implementation of WS-Notification in WAS, you can achieve the following goals:
- Use existing service integration technologies and web services components to deliver WS-Notification functions.
- Interoperate with other publish and subscribe messaging clients (for example JMS, WebSphere MQ) and with alternative message brokering products.
- Support a demand based publisher pattern of publication.
- Administratively define a WS-Notification subscription to an external notification producer:
- Subscribe to other WS-Notification broker implementations and federated brokers.
- Predefine a list of subscription information used at system startup to create the appropriate subscriptions.
- Subscribe to other WS-Notification broker implementations and federated brokers.
- Deploy a WS-Notification NotificationBroker in highly available and workload managed configurations.
Within WAS, WS-Notification also allows interchange of event notification between WS-Notification applications and other clients of the service integration bus. By exploiting other service integration bus functions you can also use this function to interchange messages with other IBM publish and subscribe brokers such as WBI Event Broker or Message Broker.
For an overview of each of the topologies that are supported by this WS-Notification implementation, see the following topics:
- Simple web services topology. In this topology
WAS is used solely as a notification broker to enable producing and consuming WS-Notification applications to communicate with each other. The applications are unaware that the NotificationBroker service is implemented by
WAS.
- Topology for WS-Notification as an entry or exit point to the service integration bus. In addition to the ability to pass information between WS-Notification producers and consumers, the WS-Notification support provided in WAS also acts as an entry or exit point to the service integration bus. Event notifications that are published by WS-Notification applications are inserted into the service integration bus where they can be modified, rerouted or consumed by any of the other applications that are connected to the bus. Equally, publications sent by service integration bus clients such as JMS can be received by WS-Notification consumers.
- Network deployment of WS-Notification topology. This topology shows the potential to deploy a WS-Notification service across multiple servers in a
WAS Network Deployment environment. In this pattern applications can connect to any WS-Notification service point and use them identically when inserting notifications, because WS-Notification topic namespaces are shared by all the WS-Notification service points of the WS-Notification service. Notification messages are propagated throughout the bus to any interested NotificationConsumers, regardless of the location where they attached to the bus (that is, regardless of the WS-Notification service point to which they are connected).
- WS-Notification in a clustered environment:
- Load balanced topology. In this topology the administrator aims to share client application requests across multiple servers in the cell without overloading any particular server. This requires that all WS-Notification service points of the WS-Notification service can be considered the same - in particular that all topic namespaces are available at every WS-Notification service point of the broker.
- High availability topology. In this topology the administrator creates a cluster of servers containing a single messaging engine and WS-Notification service point, in order to ensure that should the server containing the messaging engine fail, the resources it manages (subscriptions, event notifications) remain available to the remote applications. The messaging engine is configured to fail over between the various servers in the cluster in order to provide highly available operation.
- Load balanced high availability topology. This topology is a combination of the load-balanced topology and the high-availability topology. In this topology there is more than one messaging engine in the cluster (where the number of messaging engines is less than or equal to the number of servers). Initial requests received by the proxy server are load balanced across the cluster, to those servers that host WS-Notification service points. Subsequent requests for a resource that is created by that request (that is a subscription) are routed back to the affine messaging engine, even where it might have failed across to a different server in the cluster.
- Load balanced topology. In this topology the administrator aims to share client application requests across multiple servers in the cell without overloading any particular server. This requires that all WS-Notification service points of the WS-Notification service can be considered the same - in particular that all topic namespaces are available at every WS-Notification service point of the broker.
- Event publication between cells topology. Implementation of this topology uses existing functions of the service integration bus. WS-Notification services are configured in each of two cells, and a service integration bus link is configured to link the service integration bus topic spaces between the two buses.
- Event publication between cells through an MQ network topology. In this topology the service integration bus infrastructure is used to transmit event notifications between two cells (buses) through a network of WebSphere MQ queue managers.
WS-Notification
Use WS-Notification for publish and subscribe messaging for web services
Secure WS-Notification
Accomplishing common WS-Notification tasks
Develop applications that use WS-Notification
Related
WS-Notification troubleshooting tips
WS-Notification roles and goals
Concept topic