Network Deployment (Distributed operating systems), v8.0 > Applications > Web services > WS-Notification
WS-Notification: Overview
WS-Notification enables web services to use the publish and subscribe messaging pattern.
You use publish and subscribe messaging to publish one message to many subscribers. In this pattern a producing application inserts (publishes) a message (event notification) into the messaging system having marked it with a topic that indicates the subject area of the message. Consuming applications that have subscribed to the topic in question, and have appropriate authority, all receive an independent copy of the message that was published by the producing application. Any consuming application can further filter messages for a given topic, by using a message content filter that is evaluated over the XML message content of the message body.
The WS-Notification implementation in WAS supports the WS-Notification standards, complies with the WS-I Basic Profile 1.0 requirements, and composes with other related standards such as WS-Addressing for High Availability and Workload Management, and WS-ReliableMessaging for reliable communication between components. At an application level, this enables a standardized approach for web service applications to participate in the publish and subscribe messaging pattern, whether this be listening for notification of a particular event occurrence, or inserting event notifications into the system for consumption by other applications or system management tooling. The open-standards nature of this web services specification mean that applications can communicate with each other irrespective of the underlying hardware platforms, software languages or vendor environments.
The WS-Notification standards
WAS implements the WS-Notification v1.3 family of standards that are developed under the supervision of the Organization for the Advancement of Structured Information Standards (OASIS). These standards define web service message exchanges that enable web service applications to use the publish and subscribe messaging pattern.
WS-Notification is described in a family of three standards:
- WS-BaseNotification v1.3 OASIS Standard, which defines basic producer/consumer application roles, and the filtering of message content through a selector expression.
- WS-BrokeredNotification v1.3 OASIS Standard, which extends Base Notification to define a broker role.
- WS-Topics v1.3 OASIS Standard, which defines topic syntaxes that can be used by implementers of either base notification or brokered notification.
WS-Notification can compose with other web services standards. For example:
- WS-ReliableMessaging allows web service endpoints to be configured to ensure that web service operations are invoked reliably across inherently unreliable transports such as HTTP.
The WS-Notification standard does not guarantee the reliability with which messages are published or received by applications, so we have to compose WS-Notification with WS-ReliableMessaging to provide reliability.
- WS-Distributed Management (WS-DM) defines specialized applications that are WS-Notification NotificationProducers, and a topic namespace document that describes the topics on which these applications should emit event notifications in order to provide management of a resource (such as a printer) by a web services client.
See also WS-Notification terminology.
The WS-Notification implementation in WAS
The key component of this implementation is the notification broker. This is a point of separation between producing applications that want to insert event notifications into the system, and consuming applications that want to receive the event notifications. WAS provides this broker ready for use, so that applications can concentrate on the business level functional requirements of sending and receiving events without needing to implement the more complex infrastructure aspects of the WS-Notification specifications, such as maintaining lists of active subscribers; parsing and matching topics and wildcards; distributing event notifications to subscribers; handling subscription lifecycles. This separation between producing and consuming business application means that the producer and consumer applications do not have to be available at exactly the same time in order for them to communicate. The broker retains a publication until the consumer becomes available.
The basic pattern of invocation for the notification broker is as follows:
- A web service application contacts the server by using the Web service endpoints exposed by the WS-Notification service point.
- The endpoint passes this invocation request through to the notification broker, which is responsible for parsing the request information and taking the appropriate action depending upon the type of request received.
The following figure shows an application server that contains a notification broker and a messaging engine. Within the messaging engine there is a durable subscription and a bus topic space. Between the application server and the outside world there is a Web service endpoint. In the outside world there is a publisher, a subscriber and a notification consumer. The publisher sends a notification message on a given topic, and the subscriber sends a subscribe request on behalf of the notification consumer to subscribe to the same topic. Both these messages are received by the web service endpoint, then routed into the associated broker and on to the topic space. Details of the subscription are filed as a durable subscription. The received notification message is forwarded by the broker to the notification consumer that has subscribed to the topic.
Figure 1. Invocation of the notification broker
The WS-Notification implementation in WAS v6.1 uses service integration bus-enabled web services to expose the WS-Notification service endpoint, so that it can be invoked by applications and configured with specific attributes such as WS-Security or JAX-RPC handlers. However, the v6.1 implementation is not compatible with JAX-WS handlers or applications, and it cannot compose with WS-ReliableMessaging. WAS v7.0 or later therefore continues to provide the v6.1 implementation, and also provides a new implementation of the WS-Notification services and service points that is not based on bus-enabled web services:
- 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.
When you create a v7.0 WS-Notification service, the wizard creates and deploys a JAX-WS based provider application. This application exposes the WS-Notification web service interfaces for each of the three WS-Notification service roles:
- Notification broker
- Subscription manager
- Publisher registration manager
When you create a v6.1 WS-Notification service, the wizard configures three service integration bus inbound services for the WS-Notification service, one for each of the three WS-Notification service roles:
- Notification broker
- Subscription manager
- Publisher registration manager
These inbound services are defined on the same service integration bus as the v6.1 WS-Notification service, and each of these inbound services refers to the same bus destination.
Usually, a bus destination is used as described in Bus destinations. However, this is not the case for v6.1 WS-Notification services. The destination that is associated with a v6.1 WS-Notification service does not relate to the topics for which the WS-Notification service can handle requests, and you should not alter or mediate the destination. In WS-Notification, the configuring of topics is handled through topic namespaces. See Create a new WS-Notification permanent topic namespace.
- Base notification
The Web Services Base Notification specification defines WSDL port types for applications that want to act as a NotificationProducer or a NotificationConsumer. A NotificationProducer is an application that inserts event notifications into the system, whereas a NotificationConsumer application receives event notifications that have been published by a different application (usually a NotificationProducer application).
- Brokered notification
The Web Services Brokered Notification specification defines how an intermediary - a NotificationBroker - is made responsible for disseminating messages produced by one or more Publishers to zero or more NotificationConsumers.
- WS-Topics
The WS-Topics standard describes how a NotificationProducer application can associate a Topic with the NotificationMessages that it produces.
WS-Notification
Use WS-Notification for publish and subscribe messaging for web services
Secure WS-Notification
Accomplishing common WS-Notification tasks
Develop applications that use WS-Notification
Filter the message content of publications
Related
http://www.research.ibm.com/journal/sj/444/niblett.html
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf
http://www.w3.org/TR/1999/REC-xpath-19991116
http://www.w3.org/TR/xquery-semantics/
http://docs.oasis-open.org/wsn/wsn-ws_brokered_notification-1.3-spec-os.pdf
http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.pdf
WS-Notification troubleshooting tips
http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc.html
http://www.ibm.com/developerworks/library/ar-wsnpat/
WS-Notification roles and goals
Concept topic