Network Deployment (Distributed operating systems), v8.0 > Reference > Developer best practices
WAS-specific WS-Notification terminology
This terminology is implementation-specific, over and above the terminology defined in the WS-Notification standards, and applies to the WS-Notification implementation in WAS.
This topic does not include definitions of the messaging and web services terms that are used from existing WAS components such as service integration technologies.
Version 7.0 and v6.1 implementations
In this release there are two implementations of the WS-Notification service and service points:
- Version 7.0
: Use this type of service to compose a JAX-WS WS-Notification service with web service qualities of service (QoS) via policy sets, or to apply JAX-WS handlers to your WS-Notification service. This is the recommended type of service for new deployments. This WS-Notification option has been available in WAS from v7.0.
- Version 6.1
: Use this type of service to expose a JAX-RPC WS-Notification service that uses the same technology provided in WAS v6.1, including the ability to apply JAX-RPC handlers to the service. This WS-Notification option has been available in WAS from v6.1.
WS-Notification service
A web services configuration entity associated with a particular service integration bus. A WS-Notification service provides the ability to expose some or all of the messaging resources defined on a service integration bus for use by WS-Notification applications.
You usually configure one WS-Notification service for a service integration bus, but you can configure more than one. See Reasons to create multiple WS-Notification services in a bus.
WS-Notification service client
A web service client application, acting on behalf of a WS-Notification service within the WS-Notification infrastructure in WAS.
WS-Notification service point
A web services configuration entity representing a "localization" of a particular WS-Notification service on a particular service integration bus member. A WS-Notification service point defines access to a WS-Notification service on a given bus member through a specified web service binding (for example SOAP over HTTP). Applications use the bus members associated with the WS-Notification service point to connect to the WS-Notification service.
The existence of a WS-Notification service point on a bus member implies that a WS-Notification web service is exposed from that bus member, and causes web service endpoints for the notification broker, subscription manager and publisher registration manager for this WS-Notification service to be exposed on the bus member with which the service point is associated. WS-Notification applications use these endpoints to interact with the WS-Notification service. See Create a new v7.0 WS-Notification service point or Create a new v6.1 WS-Notification service point.
We can define any number of WS-Notification service points for a given WS-Notification service. Each service point defined for the same WS-Notification service represents an alternative entry point to the service. Event notifications published to a particular WS-Notification service point are received by all applications connected to any service point of the same WS-Notification service (subject to subscription on the correct topic) regardless of the particular service point to which they are connected. See Reasons to create multiple WS-Notification service points.
Topic namespace
A topic namespace is a grouping of topics that allows information to be shared between applications. A WS-Notification topic namespace is a logical grouping of topics that is referenced by using a namespace URI such as http://www.example.com/widget.
WAS supports two patterns for the creation and use of topic namespaces:
Permanent topic namespace
You use a permanent topic namespace to statically define the association between a WS-Notification topic namespace URI and a service integration bus topic space destination. A permanent topic namespace has the following characteristics:
- We can use it to expose an existing service integration bus topic space for use by WS-Notification clients, thus permitting interoperation between the WS-Notification applications and existing publish and subscribe applications connected to the bus such as JMS.
- We can use it to restrict the structure and content of the topic namespace by applying one or more topic namespace documents that describe the required structure.
- We can use it as part of a topic space mapping configured on a service integration bus link (between two service integration buses) or a topic mapping as part of a publish and subscribe bridge between a service integration bus and a WebSphere MQ network.
We can also set a configuration attribute of a permanent topic namespace to control the reliability (persistence or non persistence) setting that is applied to any messages that are inserted by using a given topic namespace.
Dynamic topic namespace
A dynamic topic namespace does not require manual administration by using the administration console or scripting. A dynamic topic namespace is used automatically in response to a request from a WS-Notification application for a topic namespace URI that has not been defined as a permanent topic namespace (assuming the WS-Notification service has been configured to permit use of dynamic namespaces). A dynamic topic namespace has the following characteristics:
- It does not support interoperation between WS-Notification applications and other clients of the bus such as JMS.
- It is not possible to apply topic namespace documents to this topic space, and thus the structure and content of the topic space are unrestricted.
- It cannot be used as part of the configuration of service integration bus links or a publish and subscribe bridge.
Administered subscriber
As part of the configuration of a WS-Notification service point you can configure any number of administered subscribers for that service point. An administered subscriber provides a mechanism for the WS-Notification service point to subscribe to an external notification producer at server startup time.
An administered subscriber contains the name of a NotificationProducer application or a (different) NotificationBroker endpoint and details of a subscription request (for example topic) that the WS-Notification service point should register as part of the server startup procedure. This enables you to pre-configure links between the NotificationBroker and a NotificationProducer, which can be a remote NotificationBroker or a NotificationProducer application.
WS-Notification
Use WS-Notification for publish and subscribe messaging for web services
Secure WS-Notification
Related
WS-Notification troubleshooting tips