Re: eliminating <message>: adding hints to capture method signatures

Sanjiva Weerawarana wrote:

>The following is the proposal I sent to the message elimination
>programming model hints group of folks. There has been discussion
>of it, but primarily between myself and Umit. 
>
>The basic problem we were trying to solve is to allow someone
>who wants to describe methods (functions, whatever you call 'em)
>in WSDL so that the signature is somehow apparent or inferable.
>The solution I proposed allows one to infer the signature if
>the schemas involved have been defined in a certain manner. I 
>won't spill everything here, so read it and fire away ..
>
>Sanjiva.
>
>=========================================================================
>


Sanjiva,

Oracle has been thinking about the message removal proposal for a while. 
We thought of why we are removing message in the first place and what 
this new proposal means quite a bit. Here is our thinking.

Your proposal in essence prescribes a set of rules and conventions for 
WSDL descriptions to follow so that  (some of ) the messages that are 
exchanged by an interface can be suitable for RPC style binding. The 
proposal is not only about removing message, the proposal IS ALSO about 
replacing rpc signatures within interfaces over document style AND 
prescribing the messages and their formats to make it possible. In 
essence you are describing rpc binding on top of document/literal style. 
We cover the deficiencies in the approach in (1) and the implications of 
this approach in (2) and counter proposal in (3).

(1) First of all, we think that the proposal is not complete. If certain 
conventions are followed, ie. the appearance of the name of the 
operation as the wrapping element in the schema, the mapping rules 
between arguments and the method arguments, the specific declaration of 
the return value,  it is possible to infer RPC signatures from the 
conventions. However, the following must also be addressed:

(a)  For rpc signatures, the parameter order is critical. Even if the 
elements that are designated as arguments are named, the signatures that 
can be genered from the mapping rules is 1-many. We need this to be 
described formally so that there is no confusion for indicating the 
argument order for the element that designates the argument in the 
signature.

(b) The proposal should account for the work of WS-I and BP 1.0, and 
must not rediscover the requirements that are in existence with BP 1.0. 
For example, the proposal should not allow for more than one element as 
an input (that has been discussed).

We think that the proposal should not allow ambiguity either.

Consider the following example:

<element name="foo" type="tns:fooType"/>
<complexType name="fooType">
   <sequence>
   <element name="arg1" .../>
   <element name="arg2" .../>
...
   <element name="argn" ...>
   </sequence>
</complexType>

The following can not be allowed:

<operation name="iwillbeignored">
      <input element="tns:foo">
      ...
</operation>

<operation name="foo" encodingStyle="rpc">
      <input element="tns:foo"/>
      ...
</operation>

Per your proposal, the operation name DOES NOT appear on the wire unless 
the input element indicates it with the encodingStyle. In that case, 
again, it is not the encodingStyle that is causing it to appear, but the 
requirement of having a corresponding element.  Note that both these 
operations bear the same signature on the wire. 

<foo ...>
   <arg1>...
   <arg2>...

    ...
    <argn>
</foo>

As far as dispatching purposes are concerned, this is not acceptable 
because the receiver does not know what to do with this message. WS-I 
prevents this case.

(c) Having the encodingStyle optional, only as a hint,  is not 
acceptable for compliance purposes. The WSDL must adhere to the rules 
that have been defined and must be considered ill formed if there is an 
encodingStyle present and the rules stated are not followed. So, having 
this as a hint is a bad idea.

(d) Your proposal covers only the request/response case. A set of rules 
for solicit/response and other MEPs must also be defined, so that the 
messages that need to be added to the description is known.


(2) Your proposal has the following implications. These require explicit 
discussion as the remifications for WSDL is very interesting.

Your proposal removes message, but it also removes the operation 
concept. Why, because with this proposal, the operation name is 
irrelevant for the message exchange but the element that is designated 
as the input(or output depending on the message exchange pattern used), 
is the most significant thing. I feared this way back when [1] and my 
hunch was not really wrong :-)

In RPC style message exchange, operation conceptually is the very 
significant because it designates the method. In this proposal, the 
burden is on the WSDL designer to make the RPC interactions happen due 
to the following additional requirements which don't exist today:

b1. For each input (and output), the wrapper elements must be designated 
as they will appear on the wire by the WSDL designer. The types section 
of the schema has to contain these extra elements, the operation name 
wrapper elements i.e. foo. With operations (currently they are 
significant) however, it was possible to use the same type, say 
employee, to define many different operations, createEmployee, 
promoteEmployee, removeEmployee, etc. In this case, every one of these 
elements that correspond to the messages that are generated on the wire 
ARE essentially part of the description but the burden is on the user 
who has to define them!

b2. Ditto for the return structure and inclusion of the return value in 
the return structure, i.e. fooResponse. This is extra step and 
definition which must be handled by the WSDL designer. It is very SOAP 
centric.

b3. The parameter order must be defined (which we think is absolutely 
necessary). We can no longer assume  parameters to appear on the wire 
sequentially with this proposal.

b4 For each interaction which in WSDL 1.1 land did not require the user 
to do anything except declaring an operation, namely for operations 
which did not have any messages now requires them to contamplate what 
needs to be on the wire and declare it. This is a special case of b1, 
but illustrative:

Consider the following case (if message was retained):

<interface name="pingExample">
    <message name="empty"/>
    <operation name="ping">
       <input message="tns:empty"/>
       <output message=..."/>
    </operation>

</interface>

The new form would be

<element name="ping"/>
<interface name="pingExample">
   <operation name="ping">
         <input element="ping"/>
         <output element=..../>
</interface>



b5. We have just defined very operation centric inheritence in WSDL. 
Shifting the burden to the WSDL designer makes it hard as the messages 
will have to redefine the inheritence concept. I thought inheritence was 
about operations, not messages. How do we explain this to users?

b6. Similarly, I think of attributes would be part of interfaces, but I 
can not really think of them now as WSDL becomes message centric not 
interface centric. Although attributes in WSDL is still to be discussed, 
the mismatch of abstractions concern me.

Conclusion:

The implications for removing the message and replacing it with this 
proposal is making two jumps. Removing message is a good thing, 
depending on why we want to remove it. Requiring the RPC interactions to 
be defined by the user is the second jump. We are uncomfortable with the 
second jump. I am afraid killing two birds with one stone does not work 
here. :-)

This proposal requires the WSDL designer to muck with the abstract layer 
of the WSDL interface to achieve RPC signatures, because it requires the 
WSDL designer to think of which messages are going to be on the wire, 
how they should be represented and include them in the interface! This 
is quite bottom up because the approaches shifts the burden of how 
messages that are exchanged on the wire to the WSDL designer. We think 
this is not acceptable, because the abstract WSDL, namely the interface 
is not abstract anymore because the rpc on-the-wire artifacts are 
expected to be defined in the interface, instead of being inferred 
(which is today).

We think that with this approach WSDL will  become the message exchange 
language for SOAP, not necessarily an abstract message exchange 
language. As one of my colleagues observed, this deviates from being a 
description language and turns it  into a WMDL, a Wire Message 
Description Language.
In comparison, today, those rpc artifacts are inferred and understood by 
the tools. They are not in the WSDL's interface layer. This is why we 
have a problem with this conceptual approach because we think WSDL 
should be abstract enough in its definition of interfaces and free of 
these artifacts that can be generated by tools. This is not human user 
friendly and shifts the burden to the rpc users.


I also observe that the words "interface", "operation" does not imply 
anything with this direction. We might as well replace "interface" with 
"message-exchanges" and "operation" with "message-exchange" (along with 
WMDL with WSDL :-) ) and have the following:

<definitions>
   <message-exchanges>
      <types> ...        <message-exchange>
             <input element="..."/>
                  </message-exchange>
...
  </message-exchanges>
</definitions>

I claim the message-exchange does not even need a name as names in this 
context is not meaningful as they don't appear on the wire. For 
referencing capability, I would say using XPath would suffice. :-)

Joking aside, I also make the observation that the concepts that we have 
been trying to address, namely attributes and operation inheritence are 
very interface centric. This proposal deviates from this approach 
greatly and does not fit well, since it removes an abstraction instead 
of introducing one.

We also observed that this proposal will make WSDL an artifact consumed 
and generated only by tools, not by humans. Is human friendliness a 
necessity? As a person who has to decipher the WSDL documents everyday 
and debug the semantics, I can easily say that shifting the burden on to 
users is not a good direction. Human beings read and decode WSDL, so it 
is not only for the tools. The data  from our web services team supports 
that losing the user aspect would be really an unacceptable direction as 
it will alienate end users.

Therefore, I would like to ask the WSD community at large. Is this what 
we would like to do? Are we after describe a SOAP message exchange 
language which is targeted to infrastructure tools only? This approach 
therefore begs the question, "what exactly is WSDL?".  It is a simpler 
question that "what is a web service" and I think this question requires 
some exploring because the answer actually has architectural 
implications. Oracle is very uncomfortable taking this direction due to 
the  implications stated above.

Our Counter Proposal:

As a result, we conclude the following two choices remain:

--  the message should left as is.
--  your original proposal should be explored [2].

In this proposal [2], the message layer is removed, but operations and 
parts (which are indicated by input elements) are still significant. 
Yes, minOccurs/maxOccurs/nillable are available in Schema and will have 
to be repeated in the definition of inputs. We would like to see 
nillable included for this definition and the nillable attribute should 
be allowed only when element style is used.

We anticipate that again the same arguments with respect to this 
approach being impure and not belonging to WSDL will be discussed. 
Needless to say, we prefer this "impurity" over making WSDL a different 
beast than what it appears to becoming. This is less evil than requiring 
users to struggle with on-the-wire formats which are harder to 
understand than the ah-so-famous targetResource :-)

Cheers,

--umit

References

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0067.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0042.html

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