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

Doug,

I did not want to anticipate on the WG decision: if the WG decides to 
accept this issue as valid and resolves it by selecting WS-MC as the 
appropriate solution, it would be perfectly OK with me.

Cheers

Antoine

Doug Davis a écrit :
>
> 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
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.5/1882 - Release Date: 08/01/2009 08:13
>
>

Received on Friday, 9 January 2009 12:22:40 UTC