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

Jim Webber wrote:

>Umit:
>
>  
>
>>	I'm +1 to leaving dispatching out of band on the basis that
>>	its the server's business to know how to dispatch and the WSDL
>>	is what the server has decided to tell *the client*. There's no
>>	need for the server to tell the client how *it* does 
>>its internal
>>	work.
>>
>>A big -1. It is a problem for interop. 
>>    
>>
>
>Could you elaborate on why? If I send you a message (one that you have
>advertised that you understand), you can use the that message plus any
>other data/knowledge you have internally to decide where to dispatch it.
>
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 don't want to know or need to know how you dispatch this, just that
>the message is processed somehow (which is described by the
>"processMessage" or "processThis" architectural model [1] very nicely).
>
A client needs to know the extra information that is needed to complete 
the envelope in order to pass the information around if the service 
requires it. Today, not including a SOAP Action in some vendors products 
will simply break the implementations. If this dependency was just 
expressed in WSDL, the client tools can simply include the additional 
information that is part of the envelope and/or transport. Otherwise, 
only a certain vendor's tools or the tools of their close set of friends 
can interoperate.


>
>Jim
>--
>
--umit

>http://jim.webber.name 
>
>[1] http://www.markbaker.ca/2002/09/Blog/2004/04/10 
>  
>

>
>  
>

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