WAS v8.5 > Reference > Troubleshooting tips

WS-Notification: Known restrictions

The main known restrictions that apply when using WS-Notification.


Composition with WS-Policy

This implementation of WS-Notification does not compose with WS-Policy.


Virtual hosts

For WS-Notification applications associated with a virtual host, ensure the virtual host has an alias that uses the host name or an asterisk (*), for example, myHost:9080 or *:9080. The virtual host can have additional separate aliases that use an IP address or the string localhost, but these aliases are not automatically resolved to the host name.

If the virtual host does not have an alias that uses the host name or an asterisk, the following message is produced when the application subscribes to a WS-Notification broker:

CWWAR0202E: None of the web services endpoints for this host match
the aliases for the virtual host: host_name.

This message is written to a log file in the ffdc directory, and to the SystemOut.log file.

IBM recommends using the HPEL log and trace infrastructure. With HPEL, one views logs using the LogViewer command-line tool in PROFILE/bin.


Optional specification elements

The WS-Notification standards define a series of optional elements that can be implemented at the discretion of the provider. The following items list those optional elements that are supported or not supported in WebSphere Application Server:

Supported optional elements

All three topic dialects that are defined by the WS-Topics standard are supported in WAS:

  • Simple topics. That is, single-level root topics with no wildcards. For example "stock".
  • Concrete topics. That is, multi-level topics with no wildcards. For example "stock/IBM", "sport/football/results".
  • Full topics. That is, multi-level topics with wildcards and conjunctions. For example "stock//.", "sport/football/*", "sport/*/results", "t1/t3 | t3/t4".

Filtering of the following event notifications (selectors) is supported:

  • The XPath 1.0 dialect as specified in the XML Path Language (XPath) v1.0 W3C recommendation, where the evaluation context is the NotificationMessage.
  • Any filter defined as executed over the message body, except for a filter that uses the XPath 2.0 dialect.

Subscription and PublisherRegistration termination is supported. That is, scheduled and immediate destruction of WS-Resources.

RequiresRegistration is supported, and can be set to true or false.

Demand-based publishers, as defined in Chapter 4 of the brokered notification specification, are supported. Demand based publishers allow producers to request they be paused or resumed by the broker, depending upon whether there are any consumers listening on the topics for which they produce messages. This supports situations where it is expensive to create a notification message. However, when registering a demand-based publisher, WAS only supports RegisterPublisher request messages containing a single topic expression.

Unsupported optional elements

Using the XPath 2.0 dialect to filter event notifications (selectors) is not supported.

The following optional operations from WS-ResourceProperties for SubscriptionManager and PublisherRegistrationManager are not supported:

  • GetMultipleResourceProperties

  • SetResourceProperties
  • QueryResourceProperties
  • GetResourcePropertyDocument.

Consequently, once a subscription is created, only its WS-ResourceProperties ResourceLifetime scheduled destruction properties can be modified.

Calling the GetCurrentMessage operation always results in a NoCurrentMessageOnTopicFault exception.


Interpretation of the specification

There are several areas of the WS-Notification standards in which decisions are left open to the implementor, or not fully specified. The following items describe the interpretations made in this implementation.

Messages that are published while a subscription is paused

The Web Services Base Notification specification describes several options that are open to the implementor regarding what to do with messages that are generated by a NotificationProducer (or NotificationBroker) while a subscription is paused. In this implementation all notifications that are generated during the period of time a subscription is paused are retained at the server until the subscription is resumed.

Lifetime of a pull point that has been associated with a subscription

A pull point that has been associated with a subscription remains in existence when the associated subscription is deleted. However any calls to GetMessages for that pull point return zero messages.

Conversely, if a pull point associated with a subscription is deleted or expired then the associated subscription remains in existence. However we cannot get any messages from it, and we cannot associate an existing subscription with a new pull point.


Related concepts:

WS-Notification


Related


Troubleshoot applications with HPEL
Use WS-Notification for publish and subscribe messaging for web services
Secure WS-Notification


Reference:

WS-Notification troubleshooting tips

Events and service-oriented architecture: The OASIS Web Services Notification specifications

OASIS Web Services Notification (WSN) technical committee

WS-BaseNotification v1.3 OASIS Standard

XML Path Language (XPath) v1.0

XQuery 1.0 and XPath 2.0 Formal Semantics

WS-BrokeredNotification v1.3 OASIS Standard

WS-Topics v1.3 OASIS Standard


Related information:

Virtual host page


+

Search Tips   |   Advanced Search