RE: Proposal: Uniqueness on the Wire Requirement for WSDL 2.0

Umit, we seem to be talking past each other.

 

If my service requires a specific header to make this distinction and my
tools that know about this introduce this little secret souce as a
header, I would have clients built with my tools to nicely contact my
service. This does not mean that the client did not need to understand
or *not be aware* of the service's requirement, it is just that my
clients were built with this specific tool that introduced service's
requirement on the wire for them. Hmm.

 

Are you concerned that the client won't understand the WSDL and/or won't
be able to construct the messages described by the server?

 

In other words, are we saying that interoperability is not a problem of
WSDL? 



Of course not. We should not artificially constrain how the server
constructs its WSDL.

 

--Jeff

 

________________________________

From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com] 
Sent: Monday, October 27, 2003 10:48 AM
To: Amelia A. Lewis
Cc: Jeffrey Schlimmer; www-ws-desc@w3.org
Subject: Re: Proposal: Uniqueness on the Wire Requirement for WSDL 2.0

 



Amelia A. Lewis wrote:



I believe that Jeffrey has stated this very well.  WSDL certainly does
*not* need constraints on how a service may be defined, and as he has
here clearly stated, the lack of a single defined means for recognizing
an operation from its wire format is a problem for *service*, not
*client* (fsvo "client") code.  While it may be correct to demand that
WSDL insure that generated clients be able to determine a signature
unambiguously, I agree that it is incorrect to require all services to
be generated so straitly.
  

I am baffled as to why you think it is not a problem for the client.
Lets take on of these examples, shall we? If my service requires a
specific header to make this distinction and my tools that know about
this introduce this little secret souce as a header, I would have
clients built with my tools to nicely contact my service. This does not
mean that the client did not need to understand or *not be aware* of the
service's requirement, it is just that my clients were built with this
specific tool that introduced service's requirement on the wire for
them. Hmm. 

In other words, are we saying that interoperability is not a problem of
WSDL? 

What an interesting idea. 

--umit




 
Amy!
On Fri, 24 Oct 2003 17:56:59 -0700
Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
<mailto:jeffsch@windows.microsoft.com>  wrote:
 
  

	From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
	Jeffrey Schlimmer wrote:
	 
	 
	 I do not believe that WSDL 2.0 needs to be restrictive in this
	 case because there are interesting alternatives and because any
	 recommended alternative is arbitrarily restrictive.
	 
	I am aware that there may be alternatives. I have stated some in
the
	mail thread that started this, my point is that disambiguating
wire
	signatures is a problem that has been recognized and solved
already by
	WS-I BP. 1.0. This problem must be solved in an interoperable
way 
	 
	[jeffsch: I disagree that the problem must be solved in an
	interoperable way. If a service wants to have > 1 input message
with
	the same on-the-wire signature, why would anyone else care?]
	 
	and we should not need yet another profile. I am very
uncomfortable
	with the possibility of  leaving the same issues that are
addressed
	for interoperability for WSDL 1.1 to yet another profiling
exercise. 
	 
	 SOAP header blocks provide a very interesting dispatch model,
	 and there are likely to be strong conventions around using
	 specific header blocks for this. For example, WS-Addressing [1]
	 defines an Action header block that is particularly suited for
	 this purpose.
	 
	WS-Addressing was not part of our spec last time I looked ;-) 
	 
	[jeffsch: Agreed. However, as a WG we do not operate on a
closed-world
	assumption. There are various pieces of important work outside
the
	scope of the WG, and if there are interesting, viable
alternatives, we
	should not preclude them.]
	 
	 As Paul points out, there shouldn't be any constraint on Body
	 data; it is the application's business and should be whatever
is
	 appropriate for a given application. (Note to self: our current
	 design may already be overly restrictive here.) 
	 
	  
	 
	 Put another way, if a service wants to define > 1
	 operation/input/@Body that point to the same GED, why would
	 anyone else care?
	 
	As a vendor  that provide tools needs to be able to dispatch and
need
	to disambiguate an incoming message and relate it to a specific
	operation. 
	 
	[jeffsch: Fine. Your tool can enforce whatever restriction you
need to
	on the WSDL you generate and/or consume. I claim it is possible
to
	build tools that generate and consume WSDL without this
restriction.]
	 
	This is a real interoperability problem as vendors need to
consume
	WSDLs provided by services developed by other vendors tools and
need
	to disambiguate the incoming messages. 
	 
	[jeffsch: Vendors need to be able to generate client proxies
from WSDL
	generated by servers, but we both agree there is no problem on
the
	client side. Are you concerned about the problem of being able
to
	generate server proxies from WSDL defined by some third-party?]
	 
	As you probably know, a service provider can not disambiguate
between
	operations given an input message that may be associated with
two
	different operations as the operation doesn't appear on the
wire. 
	 
	[jeffsch: I claim there are >> ways that a service provider can
	disambiguate messages to the degree that it needs to, and since
the
	WSDL is written from the point of view of the service, it is up
to the
	service to ensure this property to the degree needed.]
	 
	By having this restriction, an interface is associated with a
service,
	hence an endpoint would be able to distinguish the incoming
messages. 
	 
	Our position is that this must be solved in an interoperable way
and
	leaving this to specifications or specific vendor
implementations are
	not acceptable as one vendors choice of disambiguating may not
be
	supported by another unless it is part of the standard. Hence,
one
	vendor will not be aware of headers or addressing choices which
will
	solve this problem. This is a real issue for interoperability. 
	 
	[jeffsch: This is not a problem for tools that generate client
	proxies. It may be an implementation issue for tools that
generate
	server stubs from WSDL specified by a third-party, but the
assumptions
	of specific implementations should not be baked into a
long-range
	specification like WSDL 2.0.]
	 
	If you would like to propose alternative ways of tackling this
issue
	within the context of the WSD wg, I am all ears. However, not
solving
	this problem is unacceptable. There is a solution that is
already
	published by WS-I and we should use it. 
	 
	[jeffsch: This is not an interoperability problem. And it does
not
	need to be solved by this WG.]
	 
	    

 
 
  





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