Topology for WS-Notification as an entry or exit point to the service integration bus
In addition to the ability to pass information between WS-Notification producers and consumers, the WS-Notification support provided in WebSphere Application Server also acts as an entry or exit point to the service integration bus. Event notifications published by WS-Notification applications are inserted into the service integration bus where they can be modified, rerouted or consumed by any of the other applications that are connected to the bus. Equally, publications sent by service integration bus clients such as JMS can be received by WS-Notification consumers.
We can configure WS-Notification so that web service applications receive event notifications generated by other clients of the service integration bus such as JMS clients. Similarly web service applications can generate notifications to be received by other client types. You achieve this configuration by creating a permanent topic namespace that allows messages to be shared between web service and non web service clients of the bus, as described in Provide access for WS-Notification applications to an existing bus topic space.
In the following figure a WS-Notification publisher inserts an event notification into the notification broker that is received by a JMS message consumer. Conversely a JMS message producer can publish a message that is received by a notification consumer. Messages pass from the publisher into the notification broker, using SOAP over HTTP , and travel through a WAS, to the JMS provider, and out to the JMS message consumer using JFAP. Conversely, messages pass from the JMS message producer into the JMS provider using JFAP, and travel through a WAS to the notification broker, and out to the notification consumer using SOAP over HTTP.
Figure 1. Example of the message paths from a publisher and a JMS MessageProducer
Interacting with JMS message types
The WS-Notification service is responsible for both inserting messages into the service integration bus (in response to Notify operations received from Web services) and receiving messages from the bus (in order to pass messages to a web service as a result of a Subscribe operation).
Messages inserted by the WS-Notification service are of the JMS BytesMessage type, so when a web service invokes the Notify operation against a WS-Notification service point, the application content of the message is inserted into the body of a JMS BytesMessage using the UTF-8 encoding.
For messages received by the WS-Notification service in response to a subscription the reverse conversion is applied. The received message is converted to the appropriate JMS message type. If the appropriate type is determined to be a BytesMessage type, then the body of the message is converted to a string using the UTF-8 encoding and proceeds through the code for checking before being sent to the requesting web service.
If the converted BytesMessage string does not contain an XML element when converted to a string then this message is ignored as having been originated by a non WS-Notification aware (JMS) application.
If the received message is determined to be a TextMessage then the body content of the message is extracted and processing proceeds in the same way as for the converted BytesMessage content. This means that JMS applications that want to provide event notifications to a WS-Notification application can choose to send the content as either a BytesMessage or a TextMessage depending upon which is more convenient to the application.
If the received message is neither a BytesMessage nor a TextMessage then it is discarded as having been originated by a non WS-Notification aware (JMS) application.
If wer subscriber applications use message content filtering, and are coded to specify the XPath Version 1.0 SelectorDomain, they can filter the message content of publications that are of type JMS TextMessage or BytesMessage.
Related concepts
Related tasks