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.