Network Deployment (Distributed operating systems), v8.0 > Reference > Troubleshoot 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 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.

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

With WAS v8 you can configure the server to use the HPEL log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files or native z/OS logging facilities. If you are using HPEL, you can access all of your log and trace information using $PROFILE/bin/LogViewer.sh.


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 WAS:

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".

Filter 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 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, WAS only supports RegisterPublisher request messages that contain a single topic expression.

Unsupported optional elements

Use 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, after a subscription is created, only its WS-ResourceProperties ResourceLifetime scheduled destruction properties can be modified.

Call 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 you cannot get any messages from it, and you cannot associate an existing subscription with a new pull point.


WS-Notification
Use HPEL to troubleshoot applications
Use WS-Notification for publish and subscribe messaging for web services
Secure WS-Notification


Related


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
WS-Notification troubleshooting tips
Virtual host collection

+

Search Tips   |   Advanced Search