This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
from: public list: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0019.html Hi, My name is Antoine Mensch and I am a member of the OASIS WS-DD TC working on the Devices Profile for Web Services (DPWS). We've implemented WS-Eventing as part of DPWS for quite some time now, and we have run into the following issue: Description: The WS-Eventing default delivery mode (used in DPWS) is based on a push mechanism that requires the event source to connect to the subscriber to deliver the event notification. This creates problems in two very common cases: (i) when the subscriber is behind a firewall using NAT; (ii) when the subscriber is a Web application (e.g. Ajax or Java, Flash or Silverlight applets) which cannot accept incoming connections. Although the first problem can sometimes be solved using dynamic port mapping, the second one normally requires a change to the default security policy of the Web browser, which is generally not acceptable. Proposed resolution: Introduce a special URL to be used as the [address] of the notifyTo / endTo endpoint references in the Subscribe message. This special URL would inform the event source/subscribtion manager that event notifications are not to be sent directly to the subscriber, but rather that the subscriber will initiate a connection to fetch them. The proposed mechanism could work in a way similar to the one described in the WS-MakeConnection specification. Best regards, Antoine Mensch Odonata
This is Pull mode not Push!
2009-03-12 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0066.html
Discused on 2009-03-12 wg was generally agreed that makeConnection MAY be used as the mechanism for sending to non-addressable endpoints. Action-49
Proposal in http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0128.html at http://www.w3.org/2002/ws/ra/9/03/wseventing-6432-v1.html
New proposal: (Might be jumping the gun but this is based on the assumption that we accept the proposal for 6692 that was sent in) Modify section "2.2 Delivery" with the following (new text in ***): 2.2 Delivery This specification defines only an asynchronous method of delivery for notifications from the event source to event sink. Other methods or combination of methods may be defined through the use of delivery extensions. *** start *** When the wse:NotifyTo element is used within the Delivery element it specifies the endpoint to which Notifications are sent. For delivery to addressable endpoints this is sufficient. However, for non-addressable endpoints some additional mechanisms are needed. A subscriber MAY choose to leverage the [WS-MakeConnection] specification to enable delivery of Notifications to non-addressable endpoints. This specification defines a SOAP header that SHOULD be included in the messages to ensure that the receiver will detect and adhere to the semantics of the WS-MakeConnection specification for any WS-MakeConnection Anonymous URI used within the message: <wse:MCSupported mustUndersand="1"/> An endpoint receiving and accepting a message with this SOAP header MUST adhere to the semantics of the WS-MakeConnection specification for any EPR that uses the MakeConnection Anonymous URI in the wsa:Address element. See the [WS-MakeConnection] specification for more information, and an example, of how this would work. *** end ***
(In reply to comment #5) = > *** start *** > When the wse:NotifyTo element is used within the Delivery element it specifies > the endpoint to which Notifications are sent. For delivery to addressable > endpoints this is sufficient. However, for non-addressable endpoints some > additional mechanisms are needed. A subscriber MAY choose to leverage the > [WS-MakeConnection] specification to enable delivery of Notifications to > non-addressable endpoints. This specification defines a SOAP header that SHOULD > be included in the messages to ensure that the receiver will detect and adhere > to the semantics of the WS-MakeConnection specification for any > WS-MakeConnection Anonymous URI used within the message: > > <wse:MCSupported mustUndersand="1"/> Why is it using the wse namespace? It would be bad to change the eventing spec every time a new technology needs to be supported :) > An endpoint receiving and accepting a message with this SOAP header MUST adhere > to the semantics of the WS-MakeConnection specification for any EPR that uses > the MakeConnection Anonymous URI in the wsa:Address element. See the > [WS-MakeConnection] specification for more information, and an example, of how > this would work. > *** end *** Does it mandates some modifiations to WS-MakeConnection? And please let's continue this discussion on the main amiling-list for everbody :)
I propose the following: Modify section "2.2 Delivery" with the following (new text in ***): 2.2 Delivery This specification defines only an asynchronous method of delivery for notifications from the event source to event sink. Other methods or combination of methods may be defined through the use of delivery extensions. *** start *** When the wse:NotifyTo element is used within the Delivery element it specifies the endpoint to which Notifications are sent. For delivery to addressable endpoints this is sufficient. However, for non-addressable endpoints some additional mechanisms are needed. A subscriber MAY choose mechanisms, such as [WS-MakeConnection] specification, to enable delivery of Notifications to non-addressable endpoints. See the WS-MakeConnection [WS-MakeConnection] specification for more information, and an example, of how this would work. *** end *** I like to thank Doug Davis for helping with crafting this text.
I propose the following: Modify section "2.2 Delivery" with the following (new text in ***): 2.2 Delivery This specification defines only an asynchronous method of delivery for notifications from the event source to event sink. Other methods or combination of methods may be defined through the use of delivery extensions. *** start *** When the wse:NotifyTo element is used within the Delivery element it specifies the endpoint to which Notifications are sent. For delivery to addressable endpoints this is sufficient. However, for non-addressable endpoints some additional mechanisms are needed. A subscription manager MAY choose to support mechanisms, such as the [WS-MakeConnection] specification, to enable delivery of Notifications to non-addressable endpoints. See the WS-MakeConnection [WS-MakeConnection] specification for more information, and an example, of how this would work. *** end ***