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, using different bindings or security
parameters.
To provide WS-Notification access through more than one server
in the cell, you need to 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 use pattern. 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, using different bindings or security
parameters., you need to 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 using
SOAP over HTTP, and a second one for SOAP over JMS, this allows applications
written using either of these bindings to connect to the WS-Notification
service in question.
- Multiple WS-Notification service points using the same binding.
For example, you can define two service points on the same server
both using the SOAP over HTTP binding. For simple cases there is no
reason to do this because both service points will provide identical
functionality, but in advanced situations this configuration allows
you 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-RM for low value event notifications.