Re: RPC Style Issues (3)

Umit, others, please see inside.

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/


On Thu, 2003-10-09 at 06:09, Umit Yalcinalp wrote:
> (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.

IMHO if we specify RPC rules that are different from SOAP 1.2 rules we
aren't disallowing the SOAP 1.2 rules, just not supporting them with
this operation style. I agree that this should be stated explicitly to
avoid confusion.

One of our reasons for not supporting SOAP 1.2 RPC could be that we
don't even support SOAP 1.2 Data Model, and SOAP 1.2 RPC is built on top
of that. Both supports could be added later, but as they cannot use XML
Schema, we must provide an XML-Schema-friendly RPC, too, otherwise our
users would probably complain.

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

At first (at the conf-call) I mistook your issue for not being able to
specify a null return value (with non-void return type) reliably. I
apologize for that.

On the issue that you actually have my opinion is that it doesn't matter
if the two functions    void f([out]int x)    and    int f()   
are equivalent to WSDL. While it means that in some cases the round-trip
from a programming language interface to WSDL and back may break, aiming
for the 90/10 (or better) case means we don't want to introduce the
SOAP-like indirect designation of the return element. Anyway, IMO the
round-trip issue is out of scope for WSDL, even though the RPC rules
might want to point this issue out.

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

I don't think we want to require all non-SOAP bindings to have an
exceptional case handling a SOAP 1.2 artifact.

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

How do we indicate that, for example, the 'return-value' out-parameter
in my operation is the return value? I don't think XML Schema allows us
to say that the soaprpc:result element will have the fixed value of
myns:return-value. IOW we would force the dynamic evaluation of the
return value accessor onto otherwise static operations. Tools generating
interfaces from WSDL wouldn't be able to guess which of the out
parameters is the return value.

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

Again, that's maybe until we support SOAP 1.2 Data Model (if ever).

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

I don't think we can say the attribute may only be used with the RPC
style - it would be hard to enforce (not impossible) in implementations.

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

An ugly stone, that is. 8-)

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

Received on Friday, 24 October 2003 09:21:28 UTC