Re: Action Item 2004-07-01 Solution to 168/R114

Jim Webber wrote:

>Hey Umit, 
>
>  
>
>>You nailed it right there, this is where the contention is. 
>>The data/knowledge that one decides where to dispatch does 
>>not depend on "internal" knowledge today, it depends on 
>>"external" knowledge, meaning usage of a specific 
>>specification such as WS-Addressing, WS-MD, or mechanism such 
>>a SOAP Action, which you need to "carry" around in your 
>>message exchange. The content of the message is NOT only the 
>>actual message that you have in your interface/operation 
>>anymore, but depends on the  content of the "envelope" and 
>>perhaps the transport specific mechanism is you are relying 
>>on it. It is externalized. Hence as a client without knowing 
>>what it is, you can not simply interoperate. See my reply to 
>>Amy in this thread on this issue as well. 
>>    
>>
>
>I agree that it is the content of the message that is important (and I
>am sorry that I wasn't more explicit I don't object to the whole
>envelope being used in this case).
>
>Now while I accept that there will be WS-Addressing or
>WS-MessageDelivery headers in the envelope and that both these qualify
>as external means, I am certainly of the opinion that some uses of both
>of these specs is utterly flawed (e.g. embedding "opaque" data in an EPR
>to contextualise an interaction). These kind of mechanisms put far too
>much faith in and pressure on the consumer of a service. 
>
Ah, there are agreements there I see which we can start discussing in 
another thread :-)

>
>While I cannot prevent this from happening, I just don't want to provide
>a mechanism in WSDL for promoting such. If someone wants to hang
>themselves then I'd rather not be a rope-vendor.
>
The reality is that parties communicate today relying on extra stuff to 
be present in their envelope. If you don't know "which extra stuff" 
should be there, you can not really communicate with the service. This 
is not promoting for such use, but rather making it explicit so that it 
is inherently hidden. Let the market decide which version of 
extensibility they will adopt.

All I want for Xmas is the marker in my WSDL to require services that 
are users of such mechanisms to explicitly declare what they really rely 
on.
If I know the extension to communicate the operation name as declared in 
WSDL, I am fine. If I don't,  I treat it like another mandatory 
extension that I don't understand and can not process it. This is the 
gut of my proposal. As a matter of fact, that is exactly the reason why  
we required an explicit declaration of a feature in a WSDL document  in 
WS-Message Delivery note [1] (see section 4.1) so the consumers of the 
WSDL document were aware that the extra bits of information would be 
provided part of the envelope and this was part of the contract was 
required by WS-Message Delivery.

I gave up on insisting on providing the exact mechanism in WSDL as there 
was not going to be any agreement on what it must be and there were 
existing mechanisms that vendors used. I support freedom of choice as 
long as we declare what the choice is;-). 

>
>However I disagree with the notion that your transport mechanism should
>have any bearing on the semantics of the message, if it did then we may
>have to re-write applications just to use a specific transport. For
>example if I had faxed this message to you then it would have the same
>content and would be read in the same way. I just chose to use SMTP as
>the transport instead.
>  
>
Yes, that is why I personally dislike SOAP Action for the same reasons :-)

>I think I've just invited the wrath of Mark B. here :-)
>

>
>Jim
>--
>http://jim.webber.name 
>
>  
>
Cheers,

--umit

[1] http://www.w3.org/Submission/2004/SUBM-ws-messagedelivery-20040426/

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com