6432 2009-01-14 19:12:21 +0000 Eventing: Push delivery mode does not work when the subscriber is not addressable 2009-09-16 08:13:47 +0000 1 1 1 Unclassified WS-Resource Access Eventing FPWD PC Windows NT CLOSED REMIND hasProposal P2 normal --- 6692 1 geoffbu gilbert.pilz bob dug martin.chapman ram.jeyaraman public-ws-resource-access-notifications oldest_to_newest 23093 0 geoffbu 2009-01-14 19:12:21 +0000 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 24179 1 martin.chapman 2009-03-11 20:43:24 +0000 This is Pull mode not Push! 24196 2 bob 2009-03-12 10:04:16 +0000 2009-03-12 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0066.html 24213 3 bob 2009-03-12 15:51:58 +0000 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 24429 4 bob 2009-03-29 22:40:10 +0000 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 26058 5 dug 2009-07-24 14:37:50 +0000 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 *** 26070 6 ylafon 2009-07-24 16:50:16 +0000 (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 :) 26226 7 ram.jeyaraman 2009-08-04 20:46:01 +0000 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. 26235 8 ram.jeyaraman 2009-08-05 16:34:57 +0000 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 ***