W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2003

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

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Wed, 29 Oct 2003 17:13:00 -0800
Message-ID: <3FA0659C.8090106@oracle.com>
To: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
Cc: "Amelia A. Lewis" <alewis@tibco.com>, www-ws-desc@w3.org


Jeffrey Schlimmer wrote:

> Umit, we seem to be talking past each other.
>
I believe we understand each other perfectly ;-)

>  
>
> 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?
>
>  
>
No, I am concerned that

-- the service will require something that a WSDL will not specify and 
the client will not know about.  (out of band info) OR
-- the service will require something which may not be in standard WSDL 
(extension, property/feature, etc.) that we are not requiring and the 
client will not be able to support it unless it knows about this extension.

> 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.
>
WS-I BP thought this was a relevant problem ;-). My point is we need to 
solve this problem in an interoperable way, not by an extension or some 
other spec which we do not require or talk about.

You seem to acknowledge that distinguishing on the wire signatures is a 
problem as you seem to suggest we methodologies that are described 
elsewhere can be used. What I am saying is that this problem is in scope 
for WSDL, because there is no way of guaranteeing the client to send the 
appropriate information to the service unless the client and the server 
agree on the contract. If this contract is not in WSDL, this 
communication is not interoperable, is it? WS-I BP 1.0 rule acknowledge 
this, too. Hence, I concluded that you seem to be saying 
interoperability is not a problem for WSDL.

IMHO, not considering interoperability issues will be a mistake for us. 
Solving this problem with BP rule is one option. I repeat I can happily 
entertain other alternatives to solve this here.

>  
>
> --Jeff
>
Cheers,

--umit

>  
>
> ------------------------------------------------------------------------
>
> 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 <mailto:umit.yalcinalp@oracle.com>
>
> 
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Wednesday, 29 October 2003 20:19:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:27 GMT