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 that are associated with a virtual host, ensure that 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.

[AIX Solaris HP-UX Linux Windows][IBM i]This message is written to a log file in the ffdc directory, and to the SystemOut.log file.

Note: This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

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 WebSphere Application Server:
  • 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) Version 1.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 that 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, WebSphere Application Server only supports RegisterPublisher request messages that contain 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 open to the implementer, 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 you cannot get any messages from it, and you cannot associate an existing subscription with a new pull point.