RE: RPC Style Issues (3)

Would it make sense to define the style attribute in the RPC namespace
too?

 

--Jeff

 

________________________________

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Tom Jordahl
Sent: Tuesday, October 28, 2003 6:22 AM
To: 'Umit Yalcinalp'
Cc: 'WS Description List'
Subject: RE: RPC Style Issues (3)

 

Umit wrote:

> As I tried to indicate, we have two issues.
> 
> (1) Being able to designate a void return as well as designating an
output parameter as the return value (your example). 
> (2) Allowing SOAP rpc return value convention to coexist in the RPC
style. 

 

OK, so let's talk about your solution to (1) first.

 

> -- Define an attribute "result" in the rpc namespace. Its value is a
QName. 
> -- Use the attribute in the output element to designate the return
value in the output message (body) itself. 
> -- If the attribute does not exist, then there is no return value. You
infer that it is void. 
> -- It is an error to have this attribute in the output element when
the style is not rpc. 

This doesn't sound unreasonable to me.  I think it might be a little bit
strange to introduce this attribute and start defining hard and fast
errors that would happen if it shows up without a style attribute, but
it certainly seems easy to understand and (better) easy to implement if
you are creating a tool which wants to pay attention to the RPC hint.
If your tool doesn't, you can ignore it.  So I would support this idea.

As for (2), I am indifferent as to whether we have support for this in
WSDL or not.  I would be fine if we said we didn't, since we are not
supporting the SOAP data model either.  Do we think users of SOAP RPC
will be doing WSDL?  If Schema can't represent the data model, that
would seem like a big problem and I would probably just skip WSDL
altogether if I were using it.  But I am just guessing.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com] 
Sent: Monday, October 27, 2003 9:44 PM
To: Tom Jordahl
Cc: 'Jacek Kopecky'; 'WS Description List'
Subject: Re: RPC Style Issues (3)

 



Tom Jordahl wrote:

Jacek wrote:
  

	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.
	    

 
 
I think this is the key on this issue.  Do we care if an RPC style WSDL
can come out with two different signature?
 
  void f([out] int x)
  int f()

Tom, 

This is an excellent example. With the current rules, only the second
signature is implied. We need a mechanism to designate both. I disagree
with Jacek's point. 

 
 
I would prefer if we could avoid this by giving some clear direction in
the specification, but I don't think we should try to move toward a SOAP
RPC-like indirect return element thingy.

As I tried to indicate, we have two issues.

(1) Being able to designate a void return as well as designating an
output parameter as the return value (your example). 
(2) Allowing SOAP rpc return value convention to coexist in the RPC
style. 

The WG can make an explicit decision not to allow (2). Lets not mix the
two. 

I would like to solve problem (1). We should decide whether (2) is
acceptable or not, but (1) must be solved and yield two different
signatures. This is NOT a 80/20 problem. From our perspective, they both
exist and *are* different. 

I propose another approach to solve (1) which was mentioned but not
clearly spelled out in my message starting this thread. 

-- Define an attribute "result" in the rpc namespace. Its value is a
QName. 

-- Use the attribute in the output element to designate the return value
in the output message (body) itself. 

<interface name="whatever" ...>
     <operation name="foo" pattern="..."
style="http://www.w3.org/@@@@/@@/wsdl/style/rpc" >
        <input.../>
        <output messageReference="..." 
                     body="..." 
                     rpc:result="tns:myValue"/>
</interface>

-- If the attribute does not exist, then there is no return value. You
infer that it is void. 
-- It is an error to have this attribute in the output element when the
style is not rpc. 

Basically, it is functionally equivalent to defining the result without
using the SOAP convention inside the message. Further, the message is
not changed. Instead it is defined in WSDL, but allows one to infer two
distinct signatures as needed. 


--umit 





 
 
--
Tom Jordahl
Macromedia Server Development
 
-----Original Message-----
From: Jacek Kopecky [mailto:jacek.kopecky@systinet.com] 
Sent: Friday, October 24, 2003 9:22 AM
To: Umit Yalcinalp
Cc: WS Description List
Subject: 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:Envelope...> 
	 <SOAP:Body ...> <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
	 
	 
	 
	 
	    

 
 
  

 

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