[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WSN2.64 (action URI for Raw notifications)
In the 'direct' case as described in BrokeredNotification (line 293) the NotificationProducer is directly connected to the consuming application (which has an active useRaw=true subscription), and so it might be reasonable to assume that the NotificationProducer knows what an appropriate wsa:Action URI is for the consuming application.
In the 'brokered' case (see BrokeredNotification line 299) the situation is more complicated because the broker is acting as an intermediary, and so may not itself have knowledge of the action URI expected by the consuming application. Additionally the publisher application may have utilized the wrapped notification pattern, meaning that there is no 'custom' action URI from the publisher.
<proposal part 1 (the default behaviour)>
The NotificationProducer SHOULD utilise the same Action URI as defined for the Notify operation, except in situations where the NotificationProducer has specialist knowledge of the consuming application which would cause it to use some alternative URI.
</proposal part 1>
There are several options that could be applied to determine the URI to be specified when sending a Raw notification;
i) A constant string (as specified in part 1 of the proposal above)
ii) A URI string that reflects the topic name
iii) Administrative configuration in the topic namespace document
iv) Policy extension to allow the Subscriber application to nominate the action URI
In order to determine the best choice of these options we should consider the application patterns that we are trying to serve by providing a customization ability. Either the consuming application is intending to take some kind of action on the basis of the action URI (WSA-aware app) or it is not (non-WSA aware app). Clearly non-WSA aware applications will not be affected by any customization, and will be equally happy with the proposed default.
In the case where the consuming application requires a particular action URI string to be specified (WSA aware app), the most likely pattern is that the application is an existing web service application that knows nothing about WSN which has a set of operations defined in its WSDL, and action URI strings attached to each of these operations (including the default case where the expected action URI is made up of the application portType and operation names). When the notification is emitted from the NotificationBroker the operation that gets invoked will be determined by the enclosing XML element of the application (body) content, so we need to provide a mechanism by which it is possible to control the action URI on a per-message-type basis. Specifying it at the topic level is insufficient since the application will most likely expect a different action URI for each operation.
The two basic options here are (iii) configure the URI in the topic namespace document, or (iv) allow something on the subscribe request. The latter of these options would allow individual configuration of the action URI on a per consumer basis, however on reflection I don't think that the requirement for this level of flexibility is sufficiently strong to merit the extra burden that it places on the Subscriber. As a result of this I think the best approach is to describe (possibly in the Policy document?) a specific use for the topic/{any} in the topic namespace document as described below.
<proposal part 2 (configurable behaviour)>
A new policy assertion section should be added to the WSN Policy document that describes a standard mechanism for controlling the action URI sent with a Raw notification on a per-message-type basis. Support for this policy is optional. The behaviour described by this policy element applies only to notifications emitted for Raw subscriptions, and does not apply to The policy element can be inserted in the wstop:Topic/{any} position described on line 412 of the WS-Topics specification.
When using the RawActionURI element in a topic document, a wsnp:messageType element SHOULD be specified for every message type defined in the messageTypes attribute of the wstop:Topic element in which it is contained. In situations where a wsnp:messageType element is not defined for a type defined in the wstop:Topic attribute, the default URI string described in part 1 of this proposal MUST be applied to any raw notifications emitted by the producing application.
<wstop:Topic name="myTopic" messageTypes="xyz:m1 abc:m2">
<wsnp:RawActionURI>
<wsnp:messageType name="xyz:m1" action="http://example.com/myCustomActionURI"/>
<wsnp:messageType name="abc:m2" action="http://example.com/myOtherCustomActionURI"/>
<wsnp:RawActionURI>
</abc:myTopic>
A sample schema for this policy element might be as follows;
<xsd:element name="RawActionURI">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="MessageType" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:QName"
use="required" />
<xsd:attribute name="action" type="xsd:anyURI"
use="required" />
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</proposal part 2>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]