- From: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Date: Fri, 29 May 2009 15:27:58 -0700
- To: Doug Davis <dug@us.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <5AAAA6322448AA41840FC4563A30D6E8475A30D037@NA-EXMSG-C122.redmond.corp.microsoft>
Hi Doug,
Resurrecting this thread to talk specifically about 6432 and the use of MC, not to talk about using mode in general or even using mode to solve this issue.
One of the things that concerns me a little about using MC generically to solve the "Pull" problem is that it seems to limit the architecture that can be used to implement Eventing solutions. Perhaps you can shed some light on this.
In general, WS-Eventing allows quite a wide variety of possible architectures, in particular, the Event Source does not have to be the same as the subscription manager, but also the Event source does not even need to be the place where events are actually generated - really the event source is just the address to send the subscribe message to - Events can be sent (in push mode) from another or even several other sources.
So now if we use MC in a NotifyTo to subscribe to events, this NotifyTo may get forwarded on to these other processes that might actually "push" the events. It seems to me that the client may then have a really hard time understanding how to "poll" for these events, since the only options it really knows about are the event source and the subscription manager. Even ignoring the more complicated case for a moment, and using the basic case, it is not at all clear if the event sink should be polling the event source or the subscription manger for these events - and that is certainly not defined anywhere. Solving the complicated case would seem to involve either forcing events to be funneled through somewhere, or returning to the event sink all the actual addresses it needs to poll to get the events - which would be a significant extension on top of existing functionality.
Thoughts?
--Geoff
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Monday, April 13, 2009 12:56 PM
To: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
I'm finding most of this thread pretty pointless and repetitive (sadly, this applies to most threads in this WG). And thinking about Bob's recent note [1] about trying find compromises its clear that one side is more interested in something other than making progress. For example, in this thread all of the issues/concerns raised by people who "just don't get it" could have been answered by simply reading the MC spec itself - but its obvious that beyond a cursory glance at it (if even that), some people have not done even minimal homework - or they're purposely trying to not "get it". If they had then they would have seen the very clear example in there that shows how MC and WS-Eventing would compose together. Or, even though people have been patient and basically repeated the contents of the MC spec thru emails, and answered the same questions several times, we're still hearing the same questions being raised.
The current proposal [2] was put forward after taking the concerns of certain people very very seriously - despite the lack of constructive behavior from the other side. Its been reduced down to the point where, if adopted, WS-Eventing wouldn't mandate or even recommend MC - it simply mentions an option. This, IMO, is the bare minimum that could be done and still address the issue raised - and in the end if some people still don't like it then they don't have use it. Nothing in WS-E will force them to. However, because its so watered down I think we're doing people a disservice, but that's what happens when you have to "give-n-take". I've seen a lot of movement and compromising from one side on this (and other issues) - it's too bad this that good will only seems to flow one direction.
[1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0081.html
[2] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0128.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.
"Chou, Wu (Wu)" <wuchou@avaya.com>
Sent by: public-ws-resource-access-request@w3.org
04/13/2009 02:21 PM
To
"Asir Vedamuthu" <asirveda@microsoft.com>
cc
<public-ws-resource-access@w3.org>, "Li, Li (Li)" <lli5@avaya.com>
Subject
RE: issue 6432 - yet another proposal
It is a good idea to have a paper that explains how WS-MakeConnection (MC) composes with WS-Eventing and how it interworks with other WS-Addressing (WS-A)/WS-Eventing (WS-E) endpoints that do not support MC. We will also be interested to contribute to such a paper.
One particular question is: WS-A 1.0 Core specifies: "Comparison of [destination] property values is out of scope, other than using simple string comparison to detect whether the value is anonymous, that is, where [destination] has the value http://www.w3.org/2005/08/addressing/anonymous."
>From WS-A Core, it seems that some extension from WS-A implementation is needed in order to detect and understand the special MC anonymous EPR. If such extension is beyond the mandatory features of a WS-A endpoint, it would make sense to specify it as out-of-band to avoid additional requirements on a regular WS-A endpoint implementation.
The concern is: if the WS-A implementation cannot identify the special MC anonymous EPR by the simple string comparison as specified in WS-A 1.0 Core, it might treat the the special MC EPR as a regular EPR, and accept the event subscription to send events to it (MC anonymous EPR). If that happens, it could cause a major problem and the events won't be able to deliver.
To be concrete, assume there is an event source that understands WS-E and WS-A, but does not support MC. When the event subscriber sends a Subscribe message using the MC extension:
<wse:Subscribe>
<wse:Delivery>
<wse:NotifiyTo>
<wsa:Address>http://docs.oasis-open.org/ws-718 rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsa:Address>
</wse:NotifyTo>
</wse:Delivery>
</wse:Subscribe>
The event source checks the <wse:NotifyTo> EPR according to WS-A and decides it is neither "http://www.w3.org/2005/08/addressing/anonymous" nor "http://www.w3.org/2005/08/addressing/none" . Then it assumes it is an addressable EPR and will deliver notifications to it, which of course will fail.
This means using EPR alone to indicate MC style delivery will put an event source in one of the two situations:
1) The event source can be hit by a latent error because it does not recognize MC.
2) To avoid the latent error, the event source has to recognize the MC extension, even though it does not support MC.
- Wu Chou.
From: Asir Vedamuthu
Sent: Friday, April 10, 2009 5:00 PM
To: Christopher B Ferris
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
> Any event sink would be foolish to engage in MC interchange with
> an event source that did not advertise MC support in its policy.
Using WS-MakeConnection policy assertion to indicate the use of WS-MakeConnection protocol is possible. Earlier in the same mail thread [1], we mentioned that tiny subscribers are resource-challenged and may not have access to or may not understand metadata.
Anyway, such usages are outside the scope of WS-Eventing and should work with out-of-band agreements (and such agreements can be represented as a policy assertion).
Having said that, the Working Group should consider authoring a paper that explains how WS-MakeConnection composes with WS-Eventing using Doug's quoted sample as a starting point. We will be happy to help.
[1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0027.html
Regards,
Asir S Vedamuthu
Microsoft Corporation
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, April 09, 2009 6:32 AM
To: Asir Vedamuthu
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
Asir,
It says that comparison of destination properties is out of scope. It does not say that it is disallowed. The reason that that
statement is there is because URI comparison is non-trivial when you take into consideration all of the possible permutations
of encodings that might be used. Many specs have deferred to straight-forward string comparison as a means of side-stepping
the complexity.
As for your implied assertion that _all_ implementations need to understand MC, that is ludicrous. No one has suggested that, nor is it
necessary. Why do you think we spent all that time developing WS-Policy? MC has a policy assertion. Any event sink would be
foolish to engage in MC interchange with an event source that did not advertise MC support in its policy.
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986
From:
Asir Vedamuthu <asirveda@microsoft.com>
To:
Christopher B Ferris/Waltham/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Date:
04/08/2009 11:08 PM
Subject:
RE: issue 6432 - yet another proposal
________________________________
A WS-Addressing-aware implementation or library is NOT required to run character by character comparison to infer that a WS-MakeConnection extension is required to speak with an Event Sink.
"Comparison of [destination] property values is out of scope, other than using simple string comparison to detect whether the value is anonymous, that is, where [destination] has the value "http://www.w3.org/2005/08/addressing/anonymous"." [1]
An Endpoint Reference with encoded special semantics (WS-MakeConnection URI) ONLY makes sense IFF both sender and receiver understand the special semantics. This means, an Event Source (that is unaware of WS-MakeConnection) will not issue a fault that the Event Source does not understand the special semantics encoded in an Endpoint Reference.
What is the justification to require all WS-Eventing implementations to recognize WS-MakeConnection URI?
[1] http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrpropsinfoset
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 Christopher B Ferris
Sent: Wednesday, April 08, 2009 1:29 PM
To: public-ws-resource-access@w3.org
Subject: Re: issue 6432 - yet another proposal
Jeff is correct. Opacity is not a quality of an URI. It is a principle: you should not infer anything from the
structure (or the content) of the path component of the URI. Note the use of the word "should" - I'll come back to that
later.
For instance, just because an URI ends in .pdf does NOT mean that the client/agent that uses that URI in a GET
should expect to receive an application/pdf media type in the response entity body.
So, repeat after me, opacity is not a quality, it is a principle. One URI is neither more, nor less "opaque" than another.
Period.
Now, what Asir may be alluding to is that the MC Anon URI is constructed from a URI template:
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id={unique-String}
Here's where the opacity principle can be ignored: when the URI authority provides explicit information as to how to
interpret the structure of the URI, as the WS-Make Connection spec [1] does. One can do a character for character
match of the string
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=
If it matches the first 58 characters of another URI, then that (other) URI is a MCanon URI.
I refer you to the TAG finding that specifies that such practice is just fine thank-you very much [2] (3nd bullet in conclusions section):
"* Assignment authorities may publish specifications detailing the structure and semantics of the URIs they assign. Other users of those URIs may use such specifications to infer information about resources identified by URI assigned by that authority."
[1] http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html#_Toc162743905
[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061204.html
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986
From:
Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
To:
Yves Lafon <ylafon@w3.org>
Cc:
Gilbert Pilz <gilbert.pilz@oracle.com>, Asir Vedamuthu <asirveda@microsoft.com>, Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Date:
04/08/2009 03:16 PM
Subject:
Re: issue 6432 - yet another proposal
Sent by:
public-ws-resource-access-request@w3.org
________________________________
hi,
My understanding of the use of "opaque" wrt to URI's is that you
are not supposed to infer anything from the structure of the URI, not
that specific uri's don't have specific "meanings"/semantics as
defined in specs.
Otherwise it is totally meaningless to define a uri and give it
semantics.
So this argument and asir's response don't make sense to me. You can
certainly tell that the 2 uri's in question are different and you can
certainly know what the semantics of using them are. So i don't see a
problem.
-jeff
On Apr 08, 2009, at 2:34 AM, Yves Lafon wrote:
> On Tue, 7 Apr 2009, Gilbert Pilz wrote:
>
>> WS-Addressing 1.0 - Core defines two "special" URIs;
>> "http://www.w3.org/2005/08/addressing/anonymous" and
>> "http://www.w3.org/2005/08/addressing/none". Messages targeted to
>> either
>> of these URIs are processed differently from messages targeted to
>> "normal" URIs such as "http://webserivce.bea.com/. . .".
>
> Well, they are different, but unless you know WS-Addressing, or
> unless you resolve http://www.w3.org/2005/08/addressing/anonymous
> and find out the relationship between this URI and the WS-Addressing
> spec.
> If you resolve http://webservice.bea.com/..<http://webservice.bea.com/>. you will probably have
> information about the endpoint, or you may know it in advance from
> another document. So both URIs are opaque, unless you know their
> semantic.
>
>
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
> ~~Yves
>
>
--
Jeff Mischkinsky jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500 Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065
Received on Friday, 29 May 2009 22:28:44 UTC