Re: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm related to use ofextended anonymous uri

[Doug Davis <dug@us.ibm.com>]

Background:
WS-Addressing's WSDL Binding spec[1]
 defines a WSDL marker called "wsaw:Anonymous".  This
marker can have several values:
<wsaw:Anonymous>required</wsaw:Anonymous>
Means that all wsa:ReplyTo/wsa:FaultTo
EPRs in incoming messages MUST use WSA's 'anonymous' URI

<wsaw:Anonymous>prohibited</wsaw:Anonymous>
Means that all wsa:ReplyTo/wsa:FaultTo
EPRs in incoming messages MUST NOT use WSA's 'anonymous' URI

<wsaw:Anonmous>optional</wsaw:Anonymous>
Means that all wsa:ReplyTo/wsa:FaultTo
EPRs MAY use WSA's 'anonymous' URI

WSA had another CR opened[2]  in
which it was resolved that the WSA WG had not taken into account 'none'
into this processing.  As a result they special cased 'none' to be
allowed when wsaw:Anonymous is set to 'required' or 'prohibited'.  

The use of this marker basically indicates
whether or not the endpoint can support sending responses asynchronously,
or not.

How RM got involved:
RM's MakeConnection defines a new 'special'
URI that shares similar characteristics to WSA's anonymous URI.  It
was noticed that if an endpoint used this wsaw:Anonymous marker with a
value of 'required' (meaning it only supported synchronous responses),
then it would prohibit the use of not only RM's anonymous URI but any other
'non-addressable' URI defined by other specifications.  As a result,
CR33 was opened against WSA's WSDL Binding spec asking for a change.  Several
proposals (ranging from very minor tweaks (MUST->SHOULD) all the way
to fairly significant (but possibly handy) changes) were suggested but
none were adopted by the WSA WG.

The WSA discussions:
During the process of discussing CR33
there were several topics:
- rather than looking at the bigger
issue of how a new URI defined by some specification can compose with WSA's
wsaw:Anonymous URI, the WSA WG kept wanting to reexamine whether or not
RM's solution was the right choice.  For example, could WSA's anon+ref-p's
be used instead.
- could a new (RM-specific) WSDL marker
be defined to solve this?
- could a value of wsaw:Anonymous=optional
be used instead

Briefly touching on these....
- The RX TC spent a long time trying
to make sure RM's solution composed well with existing implementations
of WSA and with the WSA specs themselves.  Some of the key aspects
we tried to keep in mind were: ref-p's were opaque to everyone but the
minter of the EPR and to the final destination of a message (and the EPR
in question is the [destination] EPR); the WSA processing model should
remain unchanged when RM's anon URI is used.  We felt that we had
found a solution that fit very nicely with WSA and was consistent with
how WSA chose to define and use their own 'special' URIs.  Its worth
pointing out that when WSA realized they had not taken into account all
of their own special URIs when developing the wsaw:Anonymous marker, rather
than opening the door for everyone to 'special case' their own special
URIs, they opened it up just enough for their own URIs and no one else's.
- A new RM-specific WSDL marker would
not solve this problem because then if both were in the WSDL then we would
have conflicting markers.  One would say "only WSA's anon is
allowed" and one would say "WSA's anon and RM's anon is allowed"
- this conflict would be hard for people to resolve.  We also could
not have just the RM one because a client that only supported WSA and didn't
know about RM would not know anything about this RM-specific WSDL marker
- meaning it must see the WSA WSDL marker.
- Using wsaw:Anonymous=optional would
not work because this value means that addressable URIs are permitted -
which is not the semantics the server would want.

During the last WSA conf call the WG
could not come to any kind of resolution - as indicated by Bob's note.
 

Proposal:
Given that any WS-* specification may
find the need to define new 'special' URIs (RM is just one - WS-Discovery
is another), the WSA WG should find a generic solution that allows for
other specifications to compose with their spec.  To that end I propose
the following solution:
Adopt some new text to the MakeConnection
section that says: the use of the <wsaw:Anonymous>required</wsaw:Anonymous>
WSDL marker prohibits other Web Service specifications from defining their
own non-addressable URIs.  Therefore, it is RECOMMENDED that implementations
not use this WSDL marker.

thanks
-Doug

[1] http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/
[2] http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr32
[3] http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr33

Marc Goodner <mgoodner@microsoft.com>

09/19/2006 01:24 PM

To	"ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] PR issue 3 - WS-Addressing comment/question related to WS-RM

This is PR issue 3 (PR003).

Note the PR issue list should be up by tomorrow, location TBD.

-----Original Message-----
From: Bob Freund [mailto:bob@freunds.com]
Sent: Tuesday, September 19, 2006 8:00 AM
To: ws-rx-comment@lists.oasis-open.org
Subject: [ws-rx-comment] WS-Addressing comment/question related to WS-RM

As chair of WS-Addressing I am forwarding the following comment made by
one of our members:



"

I've been puzzling through the spaghetti of dependant specs for a while,
and haven't determined conclusively how to reconcile the WSDL in Appendix
B with the MakeConnection example in Appendix C.6.



The WSDL describes request-response operations such as CreateSequence,
with input CreateSequence and output CreateSequenceResponse messages.
While the WSDL doesn't describe a binding for this, it is easy to imagine
a straightforward way to bind this to a SOAP/HTTP request-response.



However, the MakeConnection example shows a MakeConnection message resulting
in a CreateSequence response message, which then results in a CreateSequenceResponse
messages, followed by an HTTP 202.  That is, the first request corresponds
to a one-way message (no problem here), the first response corresponds
to a request of a request-response, and the second request corresponds
to the response of a request-response.



What standard binding could be used to describe this behavior?  I
can't find any of the specs (WSDL 1.1, WSDL 2.0, WS-I BP) that explicitly
say the WSDL-described request message must be mapped to an HTTP request,
but I'm also not aware of any implementation that allows requests to be
mapped to anything else.  Is this just a too-obvious-to-state loophole
or am I missing something?"



Thanks

-bob