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

Prasad,
 
I do not object to defining a mechanism for indicating, for example,
that server side dispatch is based on element QNames. What I object to
is mandating that every service must publish dispatching details in its
WSDL. 
 
Gudge


________________________________

	From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org] On Behalf Of Prasad Yendluri
	Sent: 13 July 2004 23:56
	To: www-ws-desc@w3.org
	Subject: Re: Action Item 2004-07-01 Solution to 168/R114
	
	
	Folks,
	
	I can relate to leaving this to the complexities of server side
implementation to figure how to dispatch the message (to the correct
operation), even though I do see cases where this can become difficult
(having to parse the entire message to determine the "real" operation
(performance issue))  if not totally ambiguous in the worst case.
	
	If we can make it easier for a client to direct a message at an
operation  on the server in a guaranteed fashion (from the client
perspective), it is really useful IMO. This gets my vote on "what the WG
wants" vs what 114 means.
	
	The arguments I have seen for not having this seem to be aligned
with 'we don't need it'  (there is no need for the server to tell the
client how it does its internal work) rather than would this be useful ?
I think it would be:
	
	1. In promoting the client and server sides having the same
understanding on what is being invoked unambiguously (goes towards
interop).
	
	2. Avoid debug head-aches on the server implementation when
things *do* go wrong.
	
	Cheers, Prasad
	
	-------- Original Message -------- 
Subject: 	RE: Action Item 2004-07-01 Solution to 168/R114	
Resent-Date: 	Tue, 13 Jul 2004 12:12:19 -0400 (EDT)	
Resent-From: 	www-ws-desc@w3.org	
Date: 	Tue, 13 Jul 2004 09:11:54 -0700	
From: 	Martin Gudgin <mgudgin@microsoft.com>
<mailto:mgudgin@microsoft.com> 	
To: 	Amelia A Lewis <alewis@tibco.com> <mailto:alewis@tibco.com> 	
CC: 	<www-ws-desc@w3.org> <mailto:www-ws-desc@w3.org> 	

	> -----Original Message-----
	
	> From: Amelia A Lewis [mailto:alewis@tibco.com] 
	> Sent: 13 July 2004 17:03
	> To: Martin Gudgin
	> Cc: www-ws-desc@w3.org
	> Subject: Re: Action Item 2004-07-01 Solution to 168/R114
	> 
	> On Tue, 13 Jul 2004 07:13:53 -0700
	> Martin Gudgin <mgudgin@microsoft.com>
<mailto:mgudgin@microsoft.com>  wrote:
	> > > From: www-ws-desc-request@w3.org 
	> > > [mailto:www-ws-desc-request@w3.org] On Behalf Of Tom
Jordahl
	> > > Sent: 13 July 2004 15:05
	> > > To: 'WS Description List'
	> > > Subject: RE: Action Item 2004-07-01 Solution to 168/R114
	> > > I would much prefer that WSDL 2.0 does not allow this 
	> > > situation to occur. 
	> > 
	> > Then WSDL 2.0 will not be able to describe a certain class 
	> of service.
	> 
	> Which is a deep, serious problem.
	
	Oh yes!
	
	> 
	> > > As
	> > > I read the requirement (114), we are tasked with providing
a 
	> > > mechanism to
	> > > ensure that this does not occur.
	> > 
	> > Then I think the requirement is wrong.
	> 
	> In fact, Tom's interpretation of the requirement is not 
	> necessarily the
	> correct one.  
	> R114 may be taken to read as "permit authors to indicate
	> this" rather than "require authors to indicate this".  
	
	I agree with you. However, I note David Booth said, earlier in
this
	thread:
	
	"However, I think the precise wording of R114 is somewhat
irrelevant.
	The 
	real question is what does the WG think we need."
	
	> If it 
	> is "permit",
	> we're done.  
	
	Yes, in this case RPC style is sufficient.
	
	> If it is "require", then there will be 
	> significant opposition
	> to selection of any particular dispatch algorithm, which in
turn means
	> that the indication of a dispatch algorithm must be "open", 
	> which means
	> that I can define mine as "none://of.your/business/".
	> 
	> The client can trust that the service *will* dispatch the
message,
	> somehow.  How, is not information necessary to the client.
	
	Absolutely!
	
	Gudge
	
	> 
	> Amy!
	> -- 
	> Amelia A. Lewis
	> Senior Architect
	> TIBCO/Extensibility, Inc.
	> alewis@tibco.com
	> 

Received on Wednesday, 14 July 2004 03:15:54 UTC