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) being used to target the reply.
If one pursues this, what you intuitively want is: callback EPR =
{address
= anon URI, ref-param[0] = identity}.
But ref-params are opaque. Not what you want. (Although I can't see how
to stop an app contract, e.g. RM, specifying that we'll use a
mutually-known
type for a ref-param, and make its presence mandatory for certain
messages).
Assume that ref-param is not good. Why not add an RM extension element
to the EPR? This retains the identity lexeme within the EPR. A WS-A
impl
should be happy to insert and extract such extension elements, even if
it hasn't a clue what they mean.
In the simple WS-Addr anon use-case
the URI still indicates both things - whether or not (and 'not' in this
case) the destination will accept a connection, and it also indicates
the
identity - sort of. The identity is implicitly defined by the fact
that it is tied to the connection on which the request came in on. If
we did what you're suggesting and add a second header then, IMO, RM
would
require quite a big change to people's soap processor. I think WS-Addr
did a really good thing by keeping everything people need to know with
a single structure - the EPR. Even with the introduction of the
anonymous
URI (which could very easily have been introduced in a much less
cleaner
fashion), most of the SOAP processor doesn't really need to know what
the
specific value of the wsa:Address element is until it tries to actually
send the message over the wire.
So, if we then switch over the MakeConnection use-case, I think
RM did the right thing by using the same mechanism WS-Addr did - keep
everything
within a single EPR.
OK, but I think you may be conflating "a single EPR"
with "the address element of a single EPR".
This allows for most of the SOAP
processor
to be totally unaware of the actually transport mechanism until (or
close
to) the time the message is serialized on the wire. If there were
additional headers to carry this information then existing WS-Addr
logic
of mapping a wsa:ReplyTo over to a wsa:To + ref-p headers when
constructing
a response might need to also change. There's also lots of other
use-cases where the logic to handle the RM code isn't on the same
machine
doing this WS-Addr mapping so if its not aware of RM at all it wouldn't
even know to include some special bit on the outgoing message (either
in
the message or in the soap processor's metadata about the message) to
indicate
that MakeConnection will be used. Things are just a whole lot easier
if everything is encapsulated in a single EPR, and more specifically in
the wsa:Address field. Which is exactly how WS-Addr anon works today.
Hmm, back to the conflation. I can't see anything in
the
WS-Addr spec that prevents use of ref params, metadata or extensibility
elements within an anon EPR. Here, you want to use the special value
of [address], and put an application-defined type/value in the rest of
the EPR. That would fit your requirement to "keep it in the EPR".
I don't think loosening the
wording
makes thing indeterminate - it still requires a URI with the proper
semantics,
but it allows for the composition of other specifications that may
defined
their own. And, IMO, as long as they are consistent with WS-Addr's
definition of anon, from a WS-Addr perspective, then how they choose to
add additional semantics is up to them.
I'm not convinced. I think you are layer-violating --
introducing precisely the problem that you are trying to avoid.
At the SOAP processing level this message is full of arcane headers of
unknown meaning. At the WS-A processor level, these are commonplace
headers
with well-defined meanings, which may contain some arcane app ref
params
and extension elements of unknown meaning.
[reply endpoint][address] = anon URI means: "send a response on the
back-channel". At the last minute the WS-A processor whacks the arcana
(ref-params, metadata and extensibility elements) into the header and
whisks
them off on the response. Receiving WS-A processor gives the arcana to
the app, for which they are meaningful (for routing or correlation or
whatever).
This works because the WS-A receiver can look at well-known, expected
endpoint
[reply endpoint] and can find the well-known, expected anon URI -- and
need think no further. Anon URI = use back channel.
If the URI is different (anon-URI?tum-ti-tum-ti-tum) then the WS-A
processor
has to assume that it's something special. In fact, it's going to try
to
address it as a "real address", surely? Only the RM layer knows
that "?<string>" is irrelevant to back-channel choice.
I can think of three ways of getting around this:
1) Amend WS-Addressing Core to say: the distinguished URI is "any
URI which begins with the following distinguished string".
2) Amend WS-Addressing Core to say: the following distinguished
metadata
element or additional property means: whatever the content of
[address],
use the back-channel.
3) Put an extension element in the EPR that is routing data at the app
level.
1) & 2) involve amending WS-Addressing, which doesn't seem like a
great
idea.
3) Involves no change to WS-Addressing.
If the WSDL says: anon is required, then what is the value inserted on
the wire for [reply endpoint][address]? If more definition is required
to establish that, then we seem to be losing the low-level, generic
capability
WS-Addressing has defined. That's what I meant by indeterminacy.
In talking about this with Chris Ferris, he mentioned another
alternative...
instead of saying "MUST", perhaps the text related to the wsaw:Anon
flag could simply say "SHOULD". This clearly indicates
that WS-Addr's anon URI is the URI of choice, but if there are good
reasons
for using some other one then the processor will allow those as well.
Let me raise another point about the WSAW wording. It
talks about "response endpoints" in the plural. Will the
required, etc apply to all endpoints which can be responded to, i.e.
[from
e], [reply e], [fault e], or is it specific to each? It seems to imply
the former.
If ths is so, then it precludes routing tricks like the following
(which
is practically useful):
[from endpoint] is my address if you need to send me a second (e.g.
repeated)
response.
[reply endpoint] = anon-URI, which is where to send your first
response,
which we hope gets through.
This feature allows retrying protocols to maximize use of HTTP
responses,
but not be limited by them. I would like to be able to express this as
a contractual statement: this endpoint may be anon, this one must not
be:
from/prohibited, reply/optional. I have a use case in a customer
business
protocol for exactly this behaviour. I think it's a useful optimization
in other contexts.
Yrs,
Alastair
thanks,
-Doug
Doug,
This is probably a dumb question, but aren't you trying to change the
wrong spec?
In RM you are using a single header property to indicate two things:
"we're doing back-channel here, and it's part of a logical connection,
identified thus".
Why can't you separate the communication of these two semantics, by
using two properties:
1) wsa:ReplyTo = anonymous URI
2) wsrm:MakeConnection = connection identity?
2) without 1) would be illegal.
In your example posted on the WS-RX list, you state that [reply
endpoint] is not set because MakeConnection is a "one-way message".
But
it's a message that usually/frequently expects a reply (at a WS-A
level). Unlike many other applications, a WS-RM MC sender will tolerate
an empty response (no SOAP in the HTTP body), but I don't think that
stops one viewing this as a utilization of the request-reply pattern
implied by use of reply-to.
If you loosen the WSAW wording, then surely it becomes indeterminate.
What does "required" imply on the wire, thereafter?
Alastair
Doug Davis wrote:
>
> To elaborate a little on Bob's note [1], in the WSA WSDL spec,
when
> talking about the various values for the Anonymous Element it
lists:
>
> "optional": This value indicates that a response endpoint
EPR in a
> request message MAY contain an anonymous URI as an address.
> "required":This value indicates that all response endpoint
EPRs in a
> request message MUST always use anonymous URI as an address.
> If a response endpoint EPR does not contain the anonymous URI as
an
> address value, then a predefined InvalidAddressingHeader fault
defined
> in Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP
> Binding] MUST be generated.
> "prohibited":This value indicates that any response EPRs
in a request
> message MUST NOT use anonymous URI as an address.
> If a response endpoint EPR contains the anonymous URI as an
address
> value, then a predefined InvalidAddressingHeader fault defined in
Web
> Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP
Binding]
> MUST be generated.
>
>
> The problem comes up when another spec defines their own version
of
> anonymous - like WS-RM does. It defines an anon URI which acts
almost
> exactly like the WSA one in that it means "send it on the
transport
> specific back-channel". However, if the wsaw:Anonymous
element is set
> to "required" then the above text would seem to imply that
regardless
> of whether or not the RM spec is supported by the endpoint, the
client
> can never send a wsa:ReplyTo with anything other than WSA's
anonymous.
> So the above text precludes another spec from ever extending
WSA to
> define their own anon URI where from a WSA perspective its
equivalent.
> If the text were loosened up a bit to not mention the WSA anon
URI
> specifically, but rather something more generic like: "... MUST
always
> use a URI implying the transport specific back-channel" then
the use
> of the wsaw:Anonymous element would not preclude other specs
defining
> their own anon URI and not violate the meaning of the
wsaw:Anonymous.
>
> thanks
> -Doug
>
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/0009.html
|