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, 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.
- 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.