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

Sanjiva Weerawarana wrote:
> Hi Umit,
> 
> 
>>I am afraid you are skewing the requirement a bit. 
> 
> 
> Actually now I think its the other way around :-).
> 
> 
>>The problem is 
>>not really exposing how the dispatch is done, the 
>>problem is exposing to the client enough information so that
>>it knows how to construct messages AND headers so that dispatch
>>can be done by the receiver.
> 
> 
> +1 for telling the client all (s)he needs to know. I assume we
> are ok on the body. We removed @headers and have now agreed to
> add the AD header feature as a way to introduce "headers" 
> abstractly. 
> 
> That is *plenty* to describe all the payload AND headers the
> client must send. If that's all we are talking about then we are
> indeed done!
> 
> 
>>I have said this many times in this thread that there are 
>>many ways a service can implement it, the question is what
>>the client must know to enable the dispatch.
> 
> 
> There's a subtle overstatement above from my POV: the client only
> needs to adhere to the requirements indicated in the WSDL. *How*
> those requirements enable dispatch in the server *is not* the
> client's business. It simply doesn't care ...
> 
> 
>>If your view of the world is that WSDL does not contain the
>>contract and there is some other out of band mechanism to
>>communicate this information, then we are arguing about a 
>>different problem. 
> 
> 
> That's not the point. If indeed some "extra" info (like WS-Addr's
> <wsa:Action> header) is required for the server to correctly process
> the message then of course the client must be informed that its 
> gotta comply. I fully expect to put that hint into WSDL (which WS-Addr
> already does for WSDL 1.1)!
> 
> I think the main point is that we must stop thinking about this from
> a "dispatch problem" point of view. The issue is that the client must
> be told everything it needs to know in order to get what it wants
> done, done. Part of that info may be used for dispatch, part of it
> to charge the client's credit card and the other part to offer him
> some custom marketing stuff. I, the client, don't care what gets 
> used for what. (I certainly may not want to use a service which
> insists on receiving my bank account info, but that's a different
> matter.)
> 
> It seems like we're nearly in violent agreement. 

Let me check how violent the agreement really is. I agree with you
that dispatching is not the issue.

Here's the issue as I see it: the WSDL author went as far as to
define several operations on an interface. Operations partition the
set of all valid message exchanges (interactions) with a service
in disjoint subsets. If one interface can define two operations,
O1 and O2, that use the same MEP and both have signature A->B
(i.e. they take an A and return a B), then the combination of
the actual messages "a" and "b" as transmitted doesn't tell
the whole story. In general, you need the "operation name" to
be transmitted. (Maybe there is some rule that says "if the value X
is > 1000 it's O1, otherwise it's O2", as Gudge offered. But then
the culprit seems to be the insufficiently powerful type system
used to define A, since it merged two disjoint types into one:
in reality, O1 and O2 have different signatures.)

Umit's proposed Operation Name feature simply makes it required to
describe in a WSDL document _a_ rule (one of the many possible ones)
that makes it possible to determine which interaction set (= operation)
a message exchange belongs to. It does not mandate using it for
dispatching, a crystal ball would work just as well as long as
it's consistent with the rule given in the WSDL.

I see value in making it possible for an external observer with
perfect visibility over the wire used to communicate to unambiguously
classify any exchanges it sees into the correct bucket (= operation).
As Prasad pointed out, this fosters interoperability, e.g. by enabling
tools such as the WS-I Analyzer to do their job.

Are you still in violent agreement? Or did I go astray somewhere?

Thanks,
Roberto

-- 
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici@sun.com

Received on Tuesday, 13 July 2004 20:07:25 UTC