This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6432 - Eventing: Push delivery mode does not work when the subscriber is not addressable
Summary: Eventing: Push delivery mode does not work when the subscriber is not address...
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: FPWD
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: hasProposal
Depends on: 6692
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-14 19:12 UTC by Geoff Bullen
Modified: 2009-09-16 08:13 UTC (History)
4 users (show)

See Also:


Attachments

Description Geoff Bullen 2009-01-14 19:12:21 UTC
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
Comment 1 Martin Chapman 2009-03-11 20:43:24 UTC
This is Pull mode not Push!
Comment 2 Robert Freund 2009-03-12 10:04:16 UTC
2009-03-12
proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0066.html
Comment 3 Robert Freund 2009-03-12 15:51:58 UTC
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

Comment 5 Doug Davis 2009-07-24 14:37:50 UTC
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 ***
Comment 6 Yves Lafon 2009-07-24 16:50:16 UTC
(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 :)


Comment 7 Ram Jeyaraman 2009-08-04 20:46:01 UTC
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.
Comment 8 Ram Jeyaraman 2009-08-05 16:34:57 UTC
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 ***