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

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 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 ;-)

> 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. 
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. 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. 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.

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.

>  
>
> --Jeff
>
--umit

>  
>
> [1] http://www-106.ibm.com/developerworks/webservices/library/ws-add/
>
>  
>
>  
>
>> -----Original Message-----
>
>> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
>
>> Behalf Of Umit Yalcinalp
>
>> Sent: Monday, October 20, 2003 3:26 PM
>
>> To: WS Description List
>
>> Subject: Proposal: Uniqueness on the Wire Requirement for WSDL 2.0
>
>>
>
>>
>
>> Folks,
>
>>
>
>> Today, the operation name do not appear on the wire. The input and
>
>> outputs are described with respect to messages exchanged and the
>
>> operation name is just for tools and bindings to refer to. This brings
>
>> up an interesting requirement for endpoints tobe able to correlate the
>
>> input/output messages to operations that define these message exchanges.
>
>> The wire signature for operations must be unambiguous.
>
>>
>
>> There are three different ways of solving this problem that I can think
>
>> of:
>
>>
>
>> 1. Require that operation names DO appear on the wire. This can be
>
>> achieved by wrappering the name of the operation, as required for RPC
>
>> style. This is actually NOT a real burden actually on the processors to
>
>> unwrap the actual message and obtain the actual element that designates
>
>> the input. The soap Body is treated similarly by the processors.
>
>>
>
>> 2.  Describe a header that contains the name of the operation and is
>
>> REQUIRED as part of the envelope. Note that some implementations and
>
>> platforms DO carry this information using soapAction and use this info
>
>> for dispatching purposes.  However, this is very SOAP specific. Further,
>
>> this is a bit different than specifying properties/features as this
>
>> header MUST always be present for interoperability and for non SOAP/HTTP
>
>> bindings to use it appropriately.
>
>>
>
>> Of course, these two approaches indicate that the operation name MUST
>
>> appear somewhere on the wire, either in the message or in the header :-).
>
>>
>
>> 3.  I would like to bring one of the WS-I BP 1.0 rules into picture and
>
>> propose that we have a similar requirement in the spec as the third
>
>> option. See [1] Section 5.6.7, rule R2710. This rule is written with
>
>> respect to WSDL 1.1, where the binding indicates how the message on the
>
>> wire would be constructed/indicated.
>
>>
>
>> In our current spec, however, the structure of the messages are already
>
>> defined by input/output messages. So the binding has very little to do
>
>> with this requirement. Instead the burden of defining wire signature for
>
>> operations shifts to requiring interfaces to contain unique messages.
>
>>
>
>> This can be achieved by requiring an interface not to use the same
>
>> element as an input (or output) in more than one operation. This is in
>
>> spirit the same requirement as stated in R2710.
>
>>
>
>> I propose a rule  to be added in section 3.1.3. along the lines of the
>
>> following:
>
>>
>
>> "An element declaration MUST NOT be referenced from the body of input
>
>> (or output) element information items of more than one  interface
>
>> operation component children of an interface component"
>
>>
>
>> If we are not going to have the operation name to appear on the wire, it
>
>> is essential for us to add this rule to the spec.
>
>>
>
>> Cheers,
>
>>
>
>> --umit
>
>>
>
>> [1] http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm
>
>>
>
>> -------------------
>
>> Umit Yalcinalp
>
>> Consulting Member of Technical Staff
>
>> ORACLE
>
>> Phone: +1 650 607 6154
>
>> Email: umit.yalcinalp@oracle.com
>
>>
>
>>
>
>  
>

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