WAS-specific WS-Notification terminology
This terminology is implementation-specific, beyond the terminology defined in the WS-Notification standards, and applies to the WS-Notification implementation in WebSphere Application Server.
This topic does not include definitions of the messaging and web services terms used from existing WAS components such as service integration technologies.
- v7.0 and v6.1 implementations
- In this release there are two implementations of the WS-Notification service and service points:
- v7.0: Compose a JAX-WS WS-Notification service with web service qualities of service (QoS) via policy sets, or to apply JAX-WS handlers to the WS-Notification service. IBM recommends this type of service for new deployments.
- v6.1: 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 we 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 referenced 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
- We 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:
- 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.
- 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.
- 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 an IBM MQ network.
We can also set a configuration attribute of a permanent topic namespace to control the reliability (persistence or non persistence) setting applied to any messages inserted using a given topic namespace.
- Dynamic topic namespace
- A dynamic topic namespace does not require manual administration 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 with 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 we 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 us to pre-configure links between the NotificationBroker and a NotificationProducer, which can be a remote NotificationBroker or a NotificationProducer application.