RE: [destination] MAP and WSDL address

Umit

<uy>It seems that we could relax the language to allow the override with 
careful wording by requiring the destination to always contain a 
meaningful value (i.e. non anonymous) unless it is a response 
message.</uy> 
Actually, that wasn't the intent of my initial note.  Whether (or not) we 
allow the [destination] to be anonymous/blank is probably not specific to 
the WSDL spec and so (I believe that) this should not drive the direction 
of this text.  Incidentally, although the text we have in the core/soap 
does not explicitly prevent the destination from being blank/anon on 
requests, we state in the core spec that the anonymous URI is for 
endpoints which cannot have a meaningful IRI assigned - this is probably 
sufficient to prevent its mis-use.

I agree that we need to relax the wording of section 4.1 (but without 
worrying about the anonymous case).  One possibility would be to change 
the text to allow the [destination] to differ from the WSDL address in 
some cases.  For example, the addition of the text 'In the absence of any 
additional information' below:

>> 4.1 Destination 
>> 
>> In the absence of any additional information, 
>> the value of the [destination] message addressing property for a 
message sent to an endpoint MUST match the 
>> value of the {address} property of the endpoint component (WSDL 2.0) or 
the address value provided by the relevant 
>> port extension (WSDL 1.1). For a SOAP 1.1 port described using WSDL 
1.1, the value is provided by the location 
>> attribute of the soap11:address extension element. 

or, alternatively explicitly state 'or its runtime override' like this:

>> 4.1 Destination 
>> 
>> In the case of WSDL 2.0, the value of the [destination] message 
addressing property for a message sent to an endpoint MUST match the 
>> value of the {address} property of the endpoint component or its 
runtime override.
>> In the case of WSDL 1.1, the value of the [destination] message 
addressing property for a message sent to an endpoint MUST match the 
>> value of or the address value provided by the relevant 
>> port extension (WSDL 1.1) or its runtime override. For a SOAP 1.1 port 
described using WSDL 1.1, the value is provided by the location 
>> attribute of the soap11:address extension element. 

Katy




"Yalcinalp, Umit" <umit.yalcinalp@sap.com> 
21/12/2005 23:33

To
"Rogers, Tony" <Tony.Rogers@ca.com>, Katy Warr/UK/IBM@IBMGB, 
<public-ws-addressing@w3.org>
cc

Subject
RE: [destination] MAP and WSDL address






For an request message (not the response) the destination value (either as 
it appears in WSDL or after being overridden) must not be anonymous. The 
anonymous URI is simply not meaningful as there is no destination to send 
the first message to. 
 
--umit
 

From: Rogers, Tony [mailto:Tony.Rogers@ca.com] 
Sent: Wednesday, Dec 21, 2005 1:30 PM
To: Yalcinalp, Umit; Katy Warr; public-ws-addressing@w3.org
Subject: RE: [destination] MAP and WSDL address

That sounds like a good idea. Perhaps we should require that it contain a 
meaningful value, and suggest that in many?most?normal?common? cases this 
value would be ...
 
Tony

From: public-ws-addressing-request@w3.org on behalf of Yalcinalp, Umit
Sent: Thu 22-Dec-05 7:07
To: Katy Warr; public-ws-addressing@w3.org
Subject: RE: [destination] MAP and WSDL address

Katy, 
 
We made them dependent in order for the values to be driven by WSDL. 
Further, we wanted the destination to always contain a value (unless it is 
an anonymous response). The intent was not to prevent the override, but to 
require a "value" for the destination to be present unless it is a 
synchronous response. The problem is due to mapping destination property 
(mandatory) to wsa:To (optional). The wsa:To is optional only when the 
destination is anonymous (hence synchronous response). 
 
The case you are referring to does not pertain to the synchronous response 
but to the destination property which is intended for the request message 
to be sent. I do not think we deliberately wanted to prevent the override 
in this case. That is my recollection anyway.
 
It seems that we could relax the language to allow the override with 
careful wording by requiring the destination to always contain a 
meaningful value (i.e. non anonymous) unless it is a response message. 
 
--umit
 

From: public-ws-addressing-request@w3.org 
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Katy Warr
Sent: Wednesday, Dec 21, 2005 3:34 AM
To: public-ws-addressing@w3.org
Subject: [destination] MAP and WSDL address


The WS-A WSDL spec appears to be too restrictive wrt [destination] MAP.   

Here is the text: 

>> 4.1 Destination 
>> 
>> The value of the [destination] message addressing property for a 
message sent to an endpoint MUST match the 
>> value of the {address} property of the endpoint component (WSDL 2.0) or 
the address value provided by the relevant 
>> port extension (WSDL 1.1). For a SOAP 1.1 port described using WSDL 
1.1, the value is provided by the location 
>> attribute of the soap11:address extension element. 

However, there are scenarios where the WSDL address is overridden at 
runtime 
by the programming model (for example: JAX-RPC targetEndpointAddress). 
The mandating of the [destination] MAP to the WSDL address in the above 
text does not allow for override.   
It forces the [destination] to be the development-time WSDL address rather 
than an updated runtime address.   

Looking back at the issue that generated this text, I wondered whether the 
intent was that the [destination] should be 
derived from the WSDL address only in the absence of additional 
information (as proposal 1 of the issue below)? 

This text was a result of issue 56: 
http://www.w3.org/2002/ws/addr/wd-issues/#i056 
It was resolved with option 1 from the f2f minutes:
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0001 
The text for option 1 is: 
>> The [destination] property is taken from the endpoint or port address - 

>> derived address (WSDL 2.0) or the applicable WSDL 1.1 extension (for 
>> SOAP it is taken from soap:address/@location). ... 

Before opening this as an issue, what are other folk's opinions? 

Thanks 
Katy