ws-rx message

Subject: Re: [ws-rx] Re: Comment on WSDL spec: use of Anonymous Element

From: Christopher B Ferris <chrisfer@us.ibm.com>
To: Alastair Green <alastair.green@choreology.com>
Date: Tue, 8 Aug 2006 11:33:44 -0500

Alastair,

I don't think that MakeConnection "invites a response"... rather, it opens up the back-channel
(when transmitted over a protocol such as HTTP that has an inherent back-channel) for the
transmission of a message.

I think that there is a difference... a large one at that.

A SOAP Response is entirely different than a protocol response message. In the context
of a oneway message, carried over a protocol such as HTTP, there is a response message
that may not carry a SOAP envelope in its entity body. It is a protocol-level response, not necessarily
a SOAP level-response. The fact that we are exploiting this is what MakeConnection is all about.

As Paul indicated, I would be happy if we suggested that WS-A none URI be specified as the
ReplyTo address, but frankly, I think that that is something for the WS-A WG to work out.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Alastair Green <alastair.green@choreology.com> wrote on 08/08/2006 11:42:10 AM: > Chris, > > Redoing part of WS-A in RM creates difficulty in WS-A WSDL (start of > thread). Raises question: Why won't standard WS-A anon facility work? > > You have to say something about where you reply to. If you want the > reply to come on the back-channel then WS-A has a way of saying that > (and you get that by default). > > If you say there is no reply, then you are saying: don't send a > response. But MC precisely invites a response. How is a WS-A > implementation supposed to understand (without being RM aware) that > reply=none really means (functionally) reply=anon? I perceive > unnecessary layering tangle. WS-A layer now expected to hold HTTP > response for app, even though told that there is no response. > > Researching further, I don't understand why an RM-specific > alternative to reply=anon has been introduced for the "address" > case, but not for the "sequence" case. > > I believe regular "use back channel" feature of WS-A can be used, > and the RM layer can handle RM "sessions", in both cases. > > Does my example of sequence case indicate expected behaviour? Would > it be wrong to say MC/reply=anon with sequence case? > > First part of long message addresses Doug's points about the > application-level set-up message: I don't understand the relevance > of that type of message. > > Alastair > > > > Christopher B Ferris wrote:
> > Alastair, > > Is this a long and drawn out manner of stating that when a message > is a true oneway (e.g. no > response is expected) then the wsa:ReplyTo should be the WS-A none > URI rather than > simply leaving it absent and hence falling trap to the "if not > present, default to anon" gotcha? > > I guess I am not seeing an issue here, although I guess it would be > fine if we recommended or required > that the MakeConnection wsa:ReplyTo MAP carry the WS-A none URI. > > Cheers, > > Christopher Ferris > STSM, Software Group Standards Strategy > email: chrisfer@us.ibm.com > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 > phone: +1 508 377 9295 > > public-ws-addressing-request@w3.org wrote on 08/08/2006 07:06:32 AM: > > > Doug, Paul -- > > > > I'm going to try to address both your comments. if I can summarize > > Paul's it was: what's the big deal about [reply endpoint] when > > MakeConnection is "one-way"?. > > > > Given RX timescales you may want to treat these remarks as "early > > public review". > > > > * * * > > > > Doug's message 1 is an application-level set-up call which > > establishes common understanding of the UUID. This type of message > > is exemplified by that shown in the CD example Step 1, unless I have > > completely misunderstood. > > > > In that example, a subscriber, who cannot listen, sends a subscribe > > message to a publisher, saying something like "subscribe me for > > topics A, B, C. The identity of this subscription request is UUID > > X". Thereafter, the publisher knows that X equals "subscription for > > topics A, B, C". > > > > Assertion 1 (please correct me if I am wrong): The format, content > > etc of this type of message (and its manner of transmission) are > > entirely application-specific. It may or may not require an > > acknowledgement. It could be sent by carrier pigeon, or by fax. The > > subscribe message, if sent as SOAP-with-Addressing, might receive a > > reply, or might not receive a reply, and if it did, it might receive > > it anon or addressable. There are no RM rules that apply to this > > message. There are only application rules. It cannot do its job > > usefully unless it passes the UUID: that is all we can say. > > > > Assertion 2. At present there is an RM rule which says: "the > > mutually understood UUID must be reflected in the [destination > > endpoint] according to an RM URI scheme". There are no RM rules to > > say whether the connection UUID, during the course of establishing > > mutual understanding, travels alone, embedded in a URI, in a body > > element or a header element. These are all matters of bilateral > > agreement at an app level between (in this case) the > > consumer/subscriber and the producer/publisher. > > > > [The example is potentially a bit misleading in this respect. > > > > The use of the full "anon-URI?id={uuid}" value in the <targetEPR/>, > > and the use of the element name "targetEPR" make one think > > "addressing", when one would be better off thinking "subscription > > identity" (at an app level). The example set-up message would work > > perfectly well if it read: > > > > <S:Body> > >  > > <SubscriptionIdentity>{uuid}</SubscriptionIdentity> > > </S:Body> > > > > Btw, given that the use of MakeConnection requires a prior > > understanding between two parties of the connection identity, there > > seems no reason why {uuid} has to be a UUID. It does need to be > > bilaterally unambiguous.] > > > > * * * > > > > Message 2 is MakeConnection. If the subscriber sends a > > MakeConnection, specifying UUID X, then the publisher knows it is > > dealing with traffic relating to subscription X, i.e. for topics A, > > B and C. At an application level, we assume that the contract > > thereafter is: start reliably communicating a stream of messages, > > relating to topics A, B and C, therefore implying sequence creation > > etc, until something causes the stream to close. > > > > So the subscriber will repeatedly send MakeConnection, citing the > > UUID X, read the HTTP response, and handle the response as if it > > were an inbound RM/RM-app message. > > > > The exchange that RM defines (rather than illustrates) is the > > MakeConnection, back-call-on-the-connection one. It's this exchange > > that I am discussing. MakeConnection is the message affected by the > > WSAW anon=required discussion, as I see it. > > > > [While it is probably helpful for diagnostic reasons to repeat the > > UUID back to the sender of MakeConnection in the [destination > > endpoint], it is actually redundant, as the HTTP Response is > > automatically and uniquely correlated with the HTTP Request. This > > might lead one to the conclusion that the simple solution would have > > been: send UUID on MakeConnection, and then respond to it on the > > anonymous back-channel without reflection of UUID in any form > > However, this would reduce the symmetry with the Sequence identified > > use of MakeConnection, see comments later] > > > > * * * > > > > There are two modes in which this exchange can work (reflecting the > > joint proposal, as I understand it): > > > > a) Send response as part of a sequence that already exists > > b) Use response to create a new sequence, etc > > > > This is relevant to answering Paul F's question, relating to the > > significance of ReplyTo. > > > > If there is a sequence, then the sequence Identifier is a > > correlation synonym for the UUID. The reply message may be sent on > > the back-channel; it must carry the wsrm:Identifier (as a separate > > header element), it need not carry the UUID. > > > > If there is no sequence, then the reply message must carry or imply > > the UUID. (I'm going to assume that carrying the UUID is better than > > implying it.) The question is how? > > > > Looking at these two cases, it is striking that both > > > > a) require a response on the back-channel, > > b) need to carry an identifier (one of the sequence, one of the > > "connection"/"session") > > > > Doug's comment that there is no wsa:ReplyTo on the MakeConnection, > > that it is "one way", is relevant here. In fact there is no such > > thing (in the XML infoset) as a non-existent [reply endpoint]. If > > wsa:ReplyTo is absent, then it is inferred to be the anon-URI. The > > only way you can stop that inference is to set the [reply endpoint] > > to none or to a "real address". I don't think you want to do either > > of those things, in this context. > > > > With these points in mind, I think it is worth looking again at my > > previous postings. > > > > The orthodox way of saying "respond on the back-channel" is setting > > [reply endpoint] to anon. This can be done explicitly or by > > inference from absence. > > > > I think there has to be a good reason to invent a new way of > > expressing this semantic. Doing so has repercussions (see the > > original starting point of this thread, re WSA W anon/required). The > > (very valuable) use case of MakeConnection does not require an > > alternate mechnanism for stating the back channel semantic. > > > > We can illustrate all of this by placing three examples side by side: > > > > * * * > > > > 1. Example using sequence Identifier: MakeConnection and reply [asper CD 04] > > 2. Example using hypothetical connection identifier: MakeConnection > > and reply [as it could be, simplified] > > 3. Example using current Address [as per CD 04] > > > > 1a. Example using sequence Identifier: MakeConnection > > > > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608" > > xmlns:wsa="http://www.w3.org/2005/08/addressing"> > > <S:Header> > > <wsa:MessageID>http://example.org/subscriptionService/ > > guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID> > > <wsa:Action>http://docs.oasis-open. > org/wsrx/wsrm/200608/MakeConnection > > </wsa:Action> > > <wsa:To>http://example.org/subscriptionService</wsa:To> > >  > > </S:Header> > > <S:Body> > > <wsrm:MakeConnection> > > <wsrm:Identifier>http://Business456. > > com/SubscribeTopics/Sequence/7456-3278</wsrm:Identifier> > > </wsrm:MakeConnection> > > </S:Body> > > </S:Envelope> > > > > 1b. Example using sequence Identifier: reply to MakeConnection > > > > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608" > > xmlns:wsa="http://www.w3.org/2005/08/addressing"> > > <S:Header> > > <wsa:MessageID>http://example.org/subscriptionService/ > > guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID> > > <wsa:RelatesTo>http://example.org/subscriptionService/ > > guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo> > > <wsa:ReplyTo><wsa:Address>http://example.org/subscriptionService > > </wsa:Address></wsa:ReplyTo> > > <wsa:Action>http://example.com/subscriptionService/publish > > </wsa:Action> > > <wsrm:Sequence> > > <wsrm:Identifier>http://Business456. > > com/SubscribeTopics/Sequence/7456-3278</wsrm:Identifier> > > <wsrm:MessageNumber>1</wsrm:MessageNumber> > > </wsrm:Sequence> > > </S:Header> > > <S:Body> > >  > > </S:Body> > > </S:Envelope> > > > > 2a. Example using hypothetical connection identifier: MakeConnection > > > > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608" > > xmlns:wsa="http://www.w3.org/2005/08/addressing"> > > <S:Header> > > <wsa:MessageID>http://example.org/subscriptionService/ > > guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID> > > <wsa:Action>http://docs.oasis-open. > org/wsrx/wsrm/200608/MakeConnection > > </wsa:Action> > > <wsa:To>http://example.org/subscriptionService</wsa:To> > >  > > </S:Header> > > <S:Body> > > <wsrm:MakeConnection> > > <wsrm:ConnectionIdentifier>http://Business456.com/ > > SubscribeTopics/Stream/7457</wsrm:ConnectionIdentifier> > > </wsrm:MakeConnection> > > </S:Body> > > </S:Envelope> > > > > 2b. Example using hypothetical connection identifier: reply to > > MakeConnection (CreateSequence) > > > > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608" > > xmlns:wsa="http://www.w3.org/2005/08/addressing"> > > <S:Header> > > <wsa:MessageID>http://example.org/subscriptionService/ > > guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID> > > <wsa:RelatesTo>http://example.org/subscriptionService/ > > guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo> > > <wsa:Action>http://docs.oasis-open- > org/wsrx/wsrm/200608/CreateSequence > > </wsa:Action> > > <wsa:ReplyTo>http://example.org/subscriptionService</wsa:ReplyTo> > > <wsrm:ConnectionIdentifier> > > http://Business456.com/SubscribeTopics/Stream/7457 > > </wsrm:ConnectionIdentifier> > > </S:Header> > > <S:Body> > > <wsrm:CreateSequence> > > <wsrm:AcksTo> > > <wsa:Address>http://example.org/subscriptionService > > </wsa:Address> > > </wsrm:AcksTo> > > </wsrm:CreateSequence> > > </S:Body> > > </S:Envelope> > > > > 3a. Example using wsrm:Address: MakeConnection > > > > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608" > > xmlns:wsa="http://www.w3.org/2005/08/addressing"> > > <S:Header> > > <wsa:MessageID>http://example.org/subscriptionService/ > > guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID> > > <wsa:Action>http://docs.oasis-open. > org/wsrx/wsrm/200608/MakeConnection > > </wsa:Action> > > <wsa:To>http://example.org/subscriptionService</wsa:To> > >  > > </S:Header> > > <S:Body> > > <wsrm:MakeConnection> > > <wsrm:Address> > > http://docs.oasis-open. > > org/wsrx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000 > > </wsrm:Address> > > </wsrm:MakeConnection> > > </S:Body> > > </S:Envelope> > > > > 3b. Example using wsrm:Address: reply to MakeConnection (CreateSequence) > > > > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608" > > xmlns:wsa="http://www.w3.org/2005/08/addressing"> > > <S:Header> > > <wsa:MessageID>http://example.org/subscriptionService/ > > guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID> > > <wsa:RelatesTo>http://example.org/subscriptionService/ > > guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo> > > <wsa:Action>http://docs.oasis-open- > org/wsrx/wsrm/200608/CreateSequence > > </wsa:Action> > > <wsa:To> > > > >  > > > > http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous? > > id=550e8400-e29b-11d4-a716-446655440000 > > </wsa:To> > > <wsa:ReplyTo>http://example.org/subscriptionService</wsa:ReplyTo> > > </S:Header> > > <S:Body> > > <wsrm:CreateSequence> > > <wsrm:AcksTo> > > <wsa:Address>http://example.org/subscriptionService > > </wsa:Address> > > </wsrm:AcksTo> > > </wsrm:CreateSequence> > > </S:Body> > > </S:Envelope> > > > > Yours, > > > > Alastair > > > > Doug Davis wrote: > > > > Alastair, > > I think you're mixing up the messages a bit. There are two messages > > at play: > > 1 - the message containing the EPR to send subsequent messages to. > > In some cases this message will have the EPR in its wsa:ReplyTo > > header, but it could also be placed someplace else depending > > on its use. And it is this EPR that needs to be tagged as the > > polling one (ie. it has the RM anon URI). > > This message will contain application specific data in the Body > > so your suggestion of placing some UUID in there will not work. > > This gets back to the necessity to keep all info about where to > > send messages encapsulated into whatever EPR we want to be tagged > > as the polling one. > > > > 2 - the MakeConnection message. > > This message does not have a wsa:ReplyTo, its a one-way. This > > message does contain a Body which is the correlation info used > > by the receiver of this message to find an appropriate message > > to send back. So, basically the stuff in the Body must match > > the EPR from message 1. And given that in some cases the only > > thing remaining from the EPR in message 1 is the serialized > > version of it, we must be able to find messages based solely > > on what's in the outgoing message itself. Which means the > > wsa:To field. Again, ref-p's are bad for this purpose. :-) > > > > HTH > > > > thanks > > -Doug > > > > > > > > Alastair Green <alastair.green@choreology.com> wrote on 08/07/2006 > > 02:02:55 PM: > > > > > Doug, > > > > > > I think I'm connecting, if you'll pardon the pun. > > > > > > 1. As I read WS-A, the [destination endpoint][address] must be set > > > to [reply endpoint][address] for a reply. > > > > > > 2. If [reply endpoint] is omitted (as per the CD example), then > > > [reply endpoint] = anon, by default. > > > > > > 3. If [destination endpoint] = "anon-URI?id={uuid}", then > > > [destination endpoint] <> [reply endpoint][address] (which was > > > simple, unornamented anon-URI), which contradicts premise 1. > > > > > > Does that make sense? If so, then I think you would need to set > > > [reply endpoint] to none, explicitly, to avoid that clash (given > > > RM's current approach). But this causes > > > > > > 4. The WS-A processor that sent MakeConnection to get very confused. > > > It wasn't expecting anything but an HTTP 200 series by way of a > > > response, but is about to get a full-scale SOAP message bounding back. > > > > > > +++ > > > > > > Further thoughts, which continue, in my mind, to question the > > > current RM approach, but which may ease the WSA W problem. > > > > > > a) You could have defined an extension element in the [reply > > > endpoint] for the UUID. > > > > > > b) Or, you could have chosen to send the UUID in the body element. > > > > > > c) In either case, this could team up with setting [reply > > endpoint] to anon. > > > > > > d) As in 3. above, you shouldn't then set response [destination > > > endpoint] to anon?id={uuid}. > > > > > > e) So, you need to set [reply endpoint] to anon, and set > > > [destination endpoint][address] to anon. > > > > > > f) which begs the question, where does the UUID go? > > > > > > g) If you passed an extension element UUID, or a UUID in the body > > > element, and then passed it back as an extension element in the anon > > > EPR that should be OK, because you have followed the rules for reply > > > formulation with respect to the [destination endpoint][address] > > > /[reference parameters]. The fact you have chosen to put an > > > extension element in the response is WS-A 3.3/3.4 legal, as I read > > > it. That's a higher-layer behaviour that does not contradict WS-A > > > base behaviour, which is constrained. > > > > > > +++ > > > > > > Why is g) not viable in your view? The processors that need to > > > understand the body/extension UUID element are the RM senders and > > > responders (not the WS-A processors, which passively pass on the > > > UUID to the RM receiver of MakeConnection, and pass on the extension > > > element to the RM receiver of the response). > > > > > > In other words, the awareness of RM-ness that is demanded in > > > formulating MakeConnection, and in replying to it, resides in the > > > same place, and at the same level, as in the current (CD) solution. > > > > > > The difference being: that the MakeConnection is now a regular > > > [reply endpoint] = anon. At which point special WSAW rules are not needed. > > > > > > I don't see any lesser or greater problem with intermediaries, > > > onward transmission etc than would apply with the current solution, > > > if that is a concern. On this point, I think I may be missing > > > something, or misunderstanding your area of concern? > > > > > > So, to summarize: > > > > > > 1. asimple-non out, special, ornamented-anon back is a problem. > > > 2. none out, anon back is a problem. > > > 3. extension element UUID out, extension element UUID back, is no > > > different, in layer terms, than body UUID out, ornamented address > > > back, i.e. is not a problem. > > > 4. anon out means no problem with anon = required. > > > > > > > > > * * * > > > > > > My last point was indeed completely beside the point of your issue : > > > -) -- it is an independent issue about WSAW, and a limitation that > > > the proposed syntax seems to impose by applying the flag across all > > > "response endpoints". > > > > > > Alastair > > > > > > Doug Davis wrote: > > > > > > Alastair, > > > We did consider adding some extra metadata to the EPR (outside of > > > the wsa:Address and ref-p's), but there's a problem - this metadata > > > is not copied over into the response message - just the wsa:Address > > > and ref-p's are. This means that any data placed elsewhere in the > > > EPR is lost once the message is serialized. So unless we assume the > > > impl can hold on to the original EPR for the entire message path > > > (which we can't in distributed systems), the identity part must be > > > in either the address or ref-p's. And, as you said, ref-p's aren't > > > good for this. > > > > > > What's interesting about your anon?unique-id example is that that > > > solution might work very nicely (we talked about this in the past) - > > > but as you said it would require WSA to say anon URIs 'start > > > with...' - and WSA is closed :-( > > > > > > I got a bit lost on your last point - it almost sounded like a > > > complaint about the current WSA WSDL spec instead of my issue - or > > > did I not follow it? > > > > > > I noticed that on the agenda for tomorrow's WSA call (I think its > > > tomorrow) is a CR issue that mentioned how this wording in the WSDL > > > spec prevents the use of "none". I can't help but think that both > > > issues (mine and the other CR issue) would be solved nicely if the > > > wording were turned around a bit and said something about how this > > > flag indicates whether or not the endpoint supports addressable > > > endpoints in the response EPRs. Not sure of the exact wording, but > > > if instead of taking about specific URIs (like anon and none) it > > > talked about whether the endpoint supported the notion of creating > > > it own connections to the EPR then it wouldn't need to get into the > > > business of listing all of the URIs that are valid. And I think it > > > would relay the exact same information. > > > > > > thanks > > > -Doug > > > > > > > > > > > > > > Alastair Green <alastair.green@choreology.com> > > > 08/04/2006 10:57 AM > > > > > > To > > > > > > Doug Davis/Raleigh/IBM@IBMUS > > > > > > cc > > > > > > public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, > > > ws-rx@lists.oasis-open.org, abbieb@nortel.com, aclark@novell.com, > > > akira.tanaka.pr@hitachi.com, aleyfer@actional.com, anash@reactivity.com, > > > andreas.bjarlestam@ericsson.com, anil.edakkunni@soa.com, anil. > > john@jhuapl.edu > > > , Anish.Karmarkar@oracle.com, Anthony Nadalin/Austin/IBM@IBMUS, > > > asakala@iona.com, ash@rainingdata.com, ashok.malhotra@oracle.com, > > > asirveda@microsoft.com, atarashi@sv.nec-labs.com, atmanes@gmail.com, > > > audet@nortel.com, barreto@adobe.com, bhakti.mehta@sun.com, blake. > > > dournaee@intel.com, bob.freund@hitachisoftware.com, bob.sunday@pwgsc.gc.ca > , > > > b.eckenfels@seeburger.de, carolina.canales@ericsson.com, > chamikara@wso2.com > > , > > > chappell@sonicsoftware.com, Charles Levay/Raleigh/IBM@IBMUS, > > > chouthri@sv.nec-labs.com, Christopher B Ferris/Waltham/IBM@IBMUS, > > > Christopher.Kurt@microsoft.com, chris.hipson@bt.com, "'von > Riegen, Claus'" > > > <claus.von.riegen@sap.com>, coevans@microsoft.com, > cunningham_david@bah.com > > , > > > dan@actional.com, "'Burdett, David'" <david.burdett@sap.com>, > > > dconnelly@openapplications.org, Diane Jordan/Raleigh/IBM@IBMUS, > > > dkmin@konkuk.ac.kr, dleshc@tibco.com, dmoberg@us.axway.com, > > dnickull@adobe.com > > > , "'David Orchard'" <dorchard@bea.com>, doug.bunting@sun.com, > > > eisaku.nishiyama.dd@hitachi.com, email@cbvenkat.net, eoghan.glynn@iona.com > , > > > Eric.Newcomer@iona.com, eric.rajkovic@oracle.com, eric. > > > wells@hitachisoftware.com, ganga.sah@oracle.com, gatfora@uk.ibm.com, > > > gboschi@sonicsoftware.com, gdaniels@sonicsoftware.com, "'Gilbert Pilz'" > > > <Gilbert.Pilz@bea.com>, girish.juneja@intel.com, gregcarp@microsoft.com, > > > greg.pavlik@oracle.com, hbenmalek@us.fujitsu.com, heiko.braun@jboss.com, > > > ian.c.jones@bt.com, ian_robinson@uk.ibm.com, james.speer@capgemini.com, > > > jamie.clark@oasis-open.org, jdurand@us.fujitsu.com, jeff. > > > mischkinsky@oracle.com, jekanaya@cs.indiana.edu, Jiri.Tejkl@systinet.com, > > > jjchoe@tmax.co.kr, jkchoi@methodi.com, jmarsh@microsoft.com, joeri. > > > van_cleynenbreugel@alcatel.be, john.gotze@oasis-open.org, john. > > kemp@nokia.com > > > , joseph.2.waller@bt.com, junghc@nca.or.kr, jypyon@nca.or.kr, k- > > > seki@da.jp.nec.com, kcyee@cecid.hku.hk, kiwasa@jp.fujitsu.com, > > > lburch@novell.com, lily.liu@webmethods.com, "'Lei Jin'" <ljin@bea.com>, > > > machi@nca.or.kr, "'Mark Little'" <mark.little@jboss.com>, > > > "'Schenecker, Mark'" <mark.schenecker@sap.com>, "'de Boer, Martijn'" > > > <martijn.de.boer@sap.com>, "'Raepple, Martin'" <martin.raepple@sap.com>, > > > mary.mcrae@oasis-open.org, matsuki.yoshino.pw@hitachi.com, > > mckierna@uk.ibm.com > > > , mgoodner@microsoft.com, mhb@itst.dk, "'Bechauf, Michael'" > > > <michael.bechauf@sap.com>, mike.grogan@sun.com, millwood@uk.ibm.com, > > > mlovett@uk.ibm.com, mlyons@layer7tech.com, mschenecker@e2open.com, > > > mwang@tibco.com, nickr@enosis.com, nilo.mitra@ericsson.com, > > > nobuyuki.yamamoto.vw@hitachi.com, Ondrej.Hrebicek@microsoft.com, > > paul@wso2.com > > > , pauld@mitre.org, paul.cotton@microsoft.com, paul.knight@nortel.com, > > > peter.furniss@erebor.co.uk, peter_niblett@uk.ibm.com, pete.wenzel@sun.com > , > > > prateek.mishra@oracle.com, pyendluri@webmethods.com, Richard > > > Salz/Cambridge/IBM@IBMUS, robin@oasis-open.org, sada@jp.fujitsu.com, > > > "'Patil, Sanjay'" <sanjay.patil@sap.com>, sanka@wso2.com, > scayron@acord.org > > > , Scott Hinkelman/Austin/IBM@IBMUS, shengsong.ni@oracle.com, > > > shivajee@tibco.com, srcarter@novell.com, stefanba@microsoft.com, > > > "'Rossmanith, Stefan'" <stefan.rossmanith@sap.com>, "'Winkler, Steve'" > > > <steve.winkler@sap.com>, sumit.gupta@oracle.com, tboubez@layer7tech.com, > > > tejeswar.das@iona.com, thomas.erl@soasystems.com, thomas.t.bui@boeing.com > , > > > timothy@drummondgroup.com, toby.considine@unc.edu, tom@coastin.com, > > > "'Yalcinalp, Umit'" <umit.yalcinalp@sap.com>, vfurman@webmethods.com > > > , "'Shipkowitz, Vicki'" <vicki.shipkowitz@sap.com>, vikas@sonoasystems.com > > > , "'Videlov, Vladimir'" <vladimir.videlov@sap.com>, Martin Chapman > > > <martin.chapman@oracle.com> > > > > > > Subject > > > > > > Re: Comment on WSDL spec: use of Anonymous Element > > > > > > > > > > > > > > > Hi Doug, > > > > > > Comments interspersed: > > > > > > Doug Davis wrote: > > > > > > Alastair, > > > There are a couple of different things at play here. First, sorry > > > about the long cc-list but the wsrx mailing list still doesn't > > > appear to work so I need to include the entire wsrx team manually :-( > > > I thought my mail client was going to expire when I just did "reply all". > > > > > > In a non-anonymous world the wsa:Address field represents both the > > > fact that the destination can access connections and it identifies > > > the party. And I think that makes sense. There is no reason to not > > > have a single URI do that (let's not get into the 'identity' issue > > > w.r.t. ref-p's :-). So, if we then switch over to the anonymous > > > case, IMO, I don't believe the implementation should need to change
> > > w.r.t. the purpose of this URI. > > > Here's what I don't understand. In the non-anon case an EPR (address > > > + stuff) is used to target. In the anon case, so far as I can tell, > > > there is nothing in WS-A to stop the same "full EPR" (address + > > > stuff) be Follow-Ups: Anon / RM MakeConnection: [reply ep] = none From: Alastair Green <alastair.green@choreology.com> References: Re: [ws-rx] Re: Comment on WSDL spec: use of Anonymous Element From: Alastair Green <alastair.green@choreology.com> [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]