RPC Style Issues (3)

There are several issues with the current rule that specifies a result. 
Several alternatives were discussed, but unfortunately not recorded 
during the f2f briefly. I think rediscussion of these here would be useful.

(a) The methodology does not follow the SOAP 1.2 rules for rpc [1]. 
Hence, the SOAP 1.2 rules are not allowed given the current proposal. We 
think that this is a major issue. Our RPC rules should enable the use of 
SOAP 1.2 RPC representation, or at least not disallow the use of SOAP 
1.2 RPC representation. More on this below.

(b) It is impossible to have a "void" return type when there are only 
output parameters. This is due to the fact that the current rule is too 
restrictive. For example, for a function that has a single output 
parameter that does not return a value the rule will label the output 
parameter as a result. This behaviour is simply incorrect for our 
purposes. We thought of using other rules, but found out that *without* 
designating a result value externally to the output values being 
returned, it is impossible to do this.

Maybe revisiting the SOAP 1.2 rules may be fruitful to solve these two 
problems. Lets give an example for how SOAP 1.2 rules would designate a 
return value:

The return value in [1] is indicated by the value of the EII 
{http://www.w3.org/2003/05/soap-rpc}result. For example, an response for 
a Java method, float getStockQuote (String symbol) may look like this:

<SOAP:Envelope ...>
 <SOAP:Body ...>
   <myns:getStockQuote ...>
     <rpc:result rpc:http://www.w3.org/2003/05/soap-rpc>
       return-value
     </rpc:result>
     <return-value>10e0</return-value>
   </myns:getStockQuote>
 </SOAP:Body>
</SOAP:envelope>

Here the element rpc:result is NOT part of the signature, but allows one 
to identify the return value. The absence of rpc:result implies that the 
return type of the method was 'void'.

This allows the SOAP message to "dynamically" identify the return value. 
In the context of WSDL, what the RPC rules are trying to do is to 
identify the return value "statically". Given that most language 
bindings (at least the interfaces) will rely on "static" WSDL 
information to generate the signature, the return value will be 
determined from the WSDL.
However today with the adopted changes by removing message/parts, the 
message content is completely defined by the definition of input and/or 
output elements directly in the schema. Therefore the scheme provided by 
SOAP 1.2 requires us to define the result element  in the schema.

So the question that has to be answered is how to define rules that do 
not contract SOAP 1.2 without adopting SOAP 1.2 RPC representation.  The 
problematic part is the "rpc:result" element which appear to be very 
SOAP specific. The only way to solve the problem is to make an exception 
for the rpc:result element. Since this is in SOAP 1.2 NS, this should 
not really be a problem for non-SOAP mappings at the binding level.

In order to do this, we need to modify the existing rules to say:

- Output elements also contain only local element children with the 
exception of  {http://www.w3.org/2003/05/soap-rpc}result.

- The child elements of input and output represent input and output 
parameters of the operation ("<part>" in WSDL 1.1), except for the child 
element {http://www.w3.org/2003/05/soap-rpc}result.

...

Alternately, we can have a blanket exception for the element 
{http://www.w3.org/2003/05/soap-rpc}result.
What this means is that the a SOAP message cannot dynamically designate 
the return value, but since the inputs & outputs of a function are 
statically defined in WSDL and the designation of a result with a 
special element must be specified in the schema.

If we don't do this, we need to say explicitly that SOAP 1.2 RPC 
representation will not be supported by WSDL 2.0. Therefore, we should 
revisit this issue.


Alternative way to do this is to designate an attribute defined in WSDL 
namespace that can be optional and be used in an operation component to 
name the element that would designate the return value. This attribute 
is only allowed to be used when rpc style is indicated. The alternate 
method declares the return value statically, but suffers the same 
problem of not allowing SOAP 1.2 rpc rules to be followed.

It seems to me that making an exception to allow using the soap 
namespace designated element without requiring that a SOAP binding to be
be used may be killing two birds with one stone.

[1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapforrpc
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html

--umit





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

Received on Thursday, 9 October 2003 00:10:04 UTC