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.
- 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, you must 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, you must 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 you 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. Note: 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, you 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 you 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.