Reasons to create multiple WS-Notification service points
There are two main cases in which you might want to create more than one WS-Notification service point for a given WS-Notification service.
These two cases are as follows:
- To provide WS-Notification access through more than one server in the cell.
- To provide a mechanism through which WS-Notification applications can connect to the same server, by using different bindings or security parameters.
To provide WS-Notification access through more than one server in the cell, define at most one WS-Notification service point for each server in the cell. This enables work load balancing, either on the basis of manual distribution of clients across servers, or automatically as described in the Load balanced topology. Note that, for some or many servers, you might not define a service point at all.
To provide a mechanism through which WS-Notification applications can connect to the same server, by using different bindings or security parameters, define more than one WS-Notification service point on a particular server, then channel particular applications through particular service points. There are two further sub-cases to this option:
- WS-Notification service points of different types (bindings). For example if we create one service point for applications that use SOAP over HTTP, and a second one for SOAP over JMS, this allows applications written to use either of these bindings to connect to the WS-Notification service in question.
There is a performance cost in using SOAP over JMS, as described in WS-Notification: Supported bindings.
- Multiple WS-Notification service points that use the same binding. For example, we can define two service points on the same server that both use the SOAP over HTTP binding. For simple cases there is no reason to do this because both service points will provide identical functions, but in advanced situations we can use this configuration to differentiate between the two service points. For example, you might want to configure different security policies on each of the service points. One security policy might be set for connections originated from outside the trusted environment, mandating SSL transport encryption and a separate authorization check. The second policy might be for applications running inside the trusted environment, which would still require the authorization policy, but not require SSL. Another example is to require use of WS-ReliableMessaging on one service point, to be used by applications with high business value messages (in which reliable transport is important) and a separate service point that does not use WS-ReliableMessaging for low value event notifications.
Related concepts
WS-Notification
Related tasks
Use WS-Notification for publish and subscribe messaging for web services Secure WS-Notification Create a new Version 6.1 WS-Notification service point Interacting at run time with WS-Notification
WS-Notification troubleshooting tips createWSNServicePoint command
Related information:
WS-Notification service points [Settings]