Re: [NEW ISSUE] WS-Eventing Push delivery mode does not work when the subscriber is not addressable

Antoine,
  You mention using something "similar to MC" to support this - but I'm 
wondering why you didn't just say "use MC" ?  :-) 
Reusing an existing WS-* specs would be my preferred choice and if you 
look at one of the examples you mentioned (silverlight) it is already 
doing this I believe.

thanks
-Doug
______________________________________________________
STSM  |  Web Services Architect  |  IBM Software Group
(919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com



Antoine Mensch <antoine.mensch@odonata.fr> 
Sent by: public-ws-resource-access-request@w3.org
01/08/2009 01:18 PM
Please respond to
antoine.mensch@odonata.fr


To
public-ws-resource-access@w3.org
cc

Subject
[NEW ISSUE] WS-Eventing Push delivery mode does not work when the 
subscriber is not addressable







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