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

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.

 

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.

 

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?

 

--Jeff

 

[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

> 

>