eliminating <message>: adding hints to capture method signatures

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.

=========================================================================

Hi Umit, Everyone,

I've been thinking about how to solve this problem and have some thoughts
I'd like to share with you. First of all, when we eliminate message, an
operation basically is a mapping from one schema element to another:
      operation o : element e-in -> element e-out
The name of the operation "o" is now a qname, but there is no statement
that that must appear anywhere on the wire. The bodies of the messages are
the elements above. The operation name simply allows us to refer to a
specific interaction as, fundamentally, the "operation" concept exists to
group together all the elements involved with one interaction.

OK, so given this, the question (as Umit so eloquently posed below) is how
to capture RPC signatures. Why is that important? As Jeffrey mentioned
during the last F2F, a lot of people do start with a method from some
language and generate WSDL. They would like to see some relationship of the
resulting WSDL operation to the method signature obviously. Similarly,
people generate stubs from WSDLs and if the WSDL came from a method
already, it certainly makes sense to expect that the stub signature and the
original method signature have something to do with each other (like being
the same if in the same programming environment).

So how do we do this? I had a simple thought that may be too simple to be
true, but let me try it.

Remember our friend @encodingStyle? OK so we've removed the encoded/literal
concept, but if you recall we still have @encodingStyle to tell users some
information about how a schema was developed. It seems to me that's
precisely what's needed here too: a way to indicate to the users that the
element schemas follow a certain pattern thap map to signatures. Relax, I'm
not going as far as defining a language mapping!

So what I'm thinking of is something like this:
      <operation name="foo" encodingStyle="http://w3.org/wsdl12/rpc">
            <input element="x:e-in"/>
            <output element="x:e-out"/>
      </operation>
Here are possible rules for
/definitions/interface/operation/@encodingStyle:
      (1) it has no default value
      (2) if its not given then no information about the "style" of the
operation's elements is available
      (3) its value is a list of URIs with the first URI being the most
significant and the others being subordinate to the first.

We would define some specific values for this attribute. Specifically,
@encodingStyle="http://w3.org/wsdl12/rpc" (URI shortcutted for brevity)
would mean:
      (1) The input and output elements have been defined according to a
pattern indicated by these rules.
      (2) Input/output elements contain only local element children (i.e.,
no global elements allowed). (No <choice> etc. allowed? Not sure but
probably should say so.)
      (3) Input element's name's localPart and operation/@name are the
same.
      (4) Output element's name's localPart is
concat(operation/@name,"Response").
      (5) Input and output elements are both in the same namespace.
      (6) The child elements of input and output represent input and output
parameters of the operation. ("<part>" in WSDL 1.1)
      (7) If there exists foo such that there are child elements named foo
in both input and output elements, then that represents an in/out
parameter.
      (8) If there does not exist any such foo in both elements then all
the parameters are input-only and/or output-only as appropriate (depending
on whether they're in the input or output element).

We can tighten this list up as much as we want (for example, do we want to
allow min/maxOccurs on the child elements? WSDL 1.1 didn't allow that). The
list above is a sleepy, in-flight approximation of what's needed to fully
extract an RPC signature details from the element pair.

Now, I said that @encodingStyle is a list of URIs. I said that because one
may also want to indciate that each of the child element schemas were
written using SOAPEnc conventions or XMI conventions for example. In that
case, the user can define a URI to indicate those conventions and then say:
      <operation name=.. encodingStyle="http://w3.org/wsdl12/rpc
uri-saying-params-are-soap-enc">
         ...
      </operation>
Since SOAPEnc is a bit special (it is an adjunct of SOAP 1.2 afterall), I
suggest we give that specific case a URI and put that in our spec.. Then
that would also serve as an example of how to define such subordinate
encoding hints. Also, if the user put only the SOAPEnc URI in
@encodingStyle, then it would mean that the entire element is defined using
those conventions.

Oh yes, as a part of this proposal we would also drop
/definitions/binding/soap/@encodingStyle as that info can now be captured
here.

What do yall think? I think its elegent, cool and simple because it allows
us to use a well-known WSDL concept to solve this problem. Furthermore, it
gives us the room to define all the semantics that we desire for how method
signatures could go in/out of WSDL. Of course, this'd be an optional
attribute as its only a hint - a WSDL consumer may happily consume the WSDL
and use the service while completely ignoring the attribute even if it were
present. However, another may choose to use it to provide the "natural"
signature mapping that users expect.

Bye,

Sanjiva.

Received on Thursday, 17 July 2003 17:53:48 UTC