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

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. 

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.

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.

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

Jim
--
http://jim.webber.name

Received on Tuesday, 13 July 2004 20:58:04 UTC