Action 2005-09-12 i056

I took an action item to explore the issues sorrounding the last
proposal, Proposal 6 [1] to close i056 [2]. 
I found two issues with respect to the proposal. There is another issue
with respect to anonymous URI which I will raise separately. 
(1) 
 The proposal appears reasonable if we were to assume that there are two
ways to define the value for the destination property, either by using
endpoint/address or by including a wsa:EndpointReference element as a
child of wsdl20:endpoint/wsdl11:port element and using
wsa:EndpointReference/wsa:Address element. The issue is to determine a
reasonable value for the destination property when there is a
corresponding description for the endpoint represented by a endpoint
description component that included one of these two options. 

The problem is the 4th bullet. This bullet defines the value of the
destination property to be anonymous when neither methods as described
above exist to specify a meaningful endpoint address. In this case, the
proposal tells us to assume that the destination is an anonymous URI.
This is a mistake. 

(a) The whole point of specifying the destination property via WSDL is
to come up with a meaningful URI for the destination for the INITIAL
message when the first message is sent to an endpoint described by a
WSDL endpoint component. Anonymous URI definition is only for response
type messages, such as ReplyTo/FaultTo, acknowledgements, etc. to define
a back channel, not a valid destination to send the initial message to
an endpoint. Therefore, anonymous URI definition as specified in Section
5.3 in SOAP binding does not apply to the initial message. Hence, it
does not apply. 

(a) In the case that the bullet describes, the value of the destination
is UNDEFINED and should be left as is. This is due to the fact that a
WSDL will not have a URI or a meaningful endpoint is because 

-- The valid address may be defined at a later time during deployment
-- It may not be described as a URI, it may be binding dependent. 
-- It may be communicated via out-of-band methods, via a configuration,
policy, etc which is independent of WSDL, such as a corporate
repository. 

As a matter of fact, todays WSDL f2f was dedicated to discussing these
use cases in clarifying why we do not supply an endpoint address in
WSDL. Not having an address does not mean that it represents a channel,
it means it will be specified in a different way elsewhere as intended
by the WSDL wg. 

In this case, the value of the destination is not going to be anonymous
but will be defined in other means, out of band! 

For those two reasons, I propose striking out either bullet 4, or
rewriting it as follows (subject to editor modifications retaining the
meaning) 

{If there is no wsa:EndpointReference and the endpoint or port address
is not specified then the value of [destination] is undefined. There may
be other mechanisms that the value of the destination property is
determined, such as  further deployment, configuration, etc. }

This means that the destination property is never without a value as
intended by the spec. 

(2) The second issue that I found with the proposal is slightly
different. This is about the proposal overall. I thought of why we have
this proposal in the first place. 

I am questioning how we distinguish the use cases that lead us to
include an EPR as a child of endpoint in WSDL. Based on this proposal,
both approaches provide population of the address property to determine
what the destination value is and it appears that this is the only
purpose to include an EPR as the child. 

If I may point out, the endpoint component already has an address. It is
not clear when a WSDL author would choose to include an EPR as a child
of endpoint instead of an address.  I think we need to make this
distinction or use case very clear as to when one would choose one over
the other. 

I could not come up with a good reason, here is why. 

Both EPR and endpoint/address element will provide a value for the
destination. So, nothing gained there using an EPR.  That leaves us with
refParams. 

Now, if you think refParams are specifically generated for a client like
cookies, then one would not typically put an EPR in a WSDL statically as
a child of endpoint since the whole point of generating refParams is
that they are dynamic, hence do not belong in the WSDL. It defies the
purpose since you can not generate specific EPRs that are tailored to a
client. 

If this is not the compelling use case, then we are left with the
unspeakeable refParams to distinguish resources on the service side
case. I can understand this a little bit better, but I would think that
EPRs generated for this kind of use will probably need to include
dynamically generated refParams and one would not include an EPR to
designate a destination address as the child of an endpoint element in a
WSDL document. So, there goes the utility of refParams. In both cases of
using refPs, I am not convinced that I would use them in a WSDL. 

What is left in an EPR? Metadata. Well, WSDL that contains the metadata
of the EPR, which would be a circular definition. Therefore, an EPR
which is defined as a child in an endpoint element in WSDL containing
metadata which is already defined in the parent is somewhat an oxymoron.


Then, please explain to me why we are allowing an EPR as a child of an
endpoint element in a WSDL document. The use cases are not compelling to
me. I can be easily convinced if one could come up with why we would
choose an EPR over an endpoint/address in a WSDL instead. 

Therefore, I conclude that there is no compelling reason to include an
Endpoint as a child element in an endpoint component to designate the
value of the destination property. Endpoint/address already covers this.


Looking at the proposals for Issue i056, it seems to me that the
simplest one to adopt is Proposal 1 instead. 

Thanks, 

--umit



[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Apr/0062
[2] http://www.w3.org/2002/ws/addr/wd-issues/#i056
----------------------

Dr. Umit Yalcinalp
Standards Architect
NetWeaver Industry Standards
SAP Labs, LLC
umit.yalcinalp@sap.com
Tel: (650) 320-3095