RE: issue 6432 - yet another proposal

As we discussed at the f2f this is really no different from the Subscriber 
sending in a NotifyTo with a wsa:Address value of ftp://www.foo.com.  How 
does the Subscriber know whether or not the source will support ftp, or 
any special URI (like urn's)?  This is why the Subscriber needs to look at 
the source's metadata (wsdl, policy...) and make sure it supports what its 
trying to ask it to do.  If it doesn't see the MC policy assertion then 
its taking a gamble that it'll support the MCanonURI. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Asir Vedamuthu <asirveda@microsoft.com> 
04/07/2009 10:39 AM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: issue 6432 - yet another proposal






> MC doesn't change that - it just changes how the connection is 
established
 
How would an Event Source infer the above from an EPR that carries a 
WS-MakeConnection URI with special semantics? What if the Event Source is 
unaware of WS-MakeConnection? 
 
(Keep in mind, tiny subscribers are resource-challenged and may not have 
access to or may not understand metadata)
 
First, the Event Source will not issue a fault that it does not understand 
the special semantics encoded in an EPR (WS-A does not have any must 
understand [1] processing). To mitigate this, as per your recommended 
approach [2] dated April 1st, should a subscriber use a SOAP Header Block 
(<Header:UseMakeConnection s:MustUnderstand=1/>) to force a must 
understand fault?
 
Second, the related Event Source may literally interpret the 
WS-MakeConnection URI and send events to the OASIS-owned special URI [3]?
 
[1] http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#eprextensibility 
[2] 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0003.html 

[3] http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=XXX
 
Regards,
 
Asir S Vedamuthu
Microsoft Corporation
 
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, March 30, 2009 1:48 PM
To: Asir Vedamuthu
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
 

Please see the MC spec [1] it has a very detailed example of how MC and a 
pub/sub specification compose together. 
Its better to not use the terms 'push' or 'pull' - it uses a 
WS-Addressing/EPR-based mode. 

[1] http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 


Asir Vedamuthu <asirveda@microsoft.com> 
03/30/2009 04:43 PM 


To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org> 
cc

Subject
RE: issue 6432 - yet another proposal
 








I am afraid that we do not understand how WS-Eventing composes with 
WS-MakeConnection. Is this a push mode or a pull mode? Has anyone 
implemented WS-Eventing and WS-MakeConnection combo? 
  
Regards, 
  
Asir S Vedamuthu 
Microsoft Corporation 
  
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Saturday, March 28, 2009 9:45 AM
To: public-ws-resource-access@w3.org
Subject: issue 6432 - yet another proposal 
  

(resending since I think the first one was rejected due to the attachment) 


I was re-reading Bob's comments [1] and I think I might have been reading 
too much into the existing wording as well.  Even if people use MC the 
messages are still sent asynchronously and unsolicited (whatever those 
terms may mean).  MC doesn't change that - it just changes how the 
connection is established.  With that in mind, I don't think we need to 
really modify the definition of Push mode (other than to make it clear 
that the sink is identified by an EPR).  However, I think it would be wise 
to rethink the name of "Push" mode.  Assuming for the moment that we do 
keep the Mode attribute, "Push" mode is really misnamed since its not 
really about Push vs Pull, its really just about using an EPR to identify 
the Sink - what people choose to put in that EPR is up to them.  With that 
in mind I've attached another proposal that does two things: 
1 - renames "Push Mode" to "EPR Mode" - which more accurately reflects 
what we're doing from a SOAP perspective 
2 - adds the minor hint of using MC for non-addressable endpoints from the 
previous proposal - which is what this issue is really about 

I think this keeps the wording that Wu was looking for, but aligns 
WS-Eventing with how all other WS-* specs use EPRs.  And is 100% backwards 
compatible - no coding changes are needed for existing implementations. We 
can then, separately, discuss whether or not we want to explicitly support 
the notion of non-EPR-based delivery modes in Dave's issue [2].  Not to 
mix topics but I will point out that in Wu's issue 6425 [3] we agreed to 
mandate that the Event Source be identified by an EPR. 

Proposal:  http://www.soaphub.org/public/files/w3c/wseventing-6432-v1.html 


[1] 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0122.html 

[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692 
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.