- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Mon, 26 Sep 2005 20:04:15 -0700
- To: <public-ws-addressing@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D64165418612@uspale20.pal.sap.corp>
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
Received on Tuesday, 27 September 2005 03:03:57 UTC