Re: [Pywebsvcs-talk] Re: [XML-SIG] SOAP in CGI-like environments

[Rich S. <rs...@zo...>]

Sec 7 says model it as a struct with parameters in the order of the
function signature, but if you use sec5 encoding, you're entitled to
serialize them in aribtrary order.

But it does appear that the spec is inconsistent here, so I'll ask on
the soapbuilders mailing list.

> I'm just trying to make the entry point for SOAP as simple as possible.
> I got thinking about this because other languages can do multi-arg
> functions without a problem but ZSI only does one dictionary argument.

Nah, ZSI can do anything, it's just a matter of writing some code. :)

Seems to me you'd like to be able to do both of the following:
	server.add(3, 4)
	server.divide(numerator=3, denominator=12)
Well in python you'll get *args or **keywords, respectively -- one
preserves order and the other doesn't. :)

I will probably add something to ZSI that lets you do SOAP structs as a
list of (key,value) tuples.  And then some flags to say you want that.

Once I can marshal a dynamic structure in-order, it's easy enough to
call apply().  Now, should it call it with just the values or with
keyword args?  That is, do I call
	apply(add, (3,4) )
or
	apply(divide, (), { 'numerator': 3 'denominator': 12} )
?

In order to get something out there, I'm willing to implement
dispatch/invocation of something, ideally interoperable.  Since there is
no requirement that parameters names match, I'm inclined to implement
the nameless order-preserving.  I'm not inclined to use inspect() and
examine the implementor's calling sequence to see how to structure the
call, although if it seems simple enough ....

	/r$
	

> 
> > Real answer:  SOAP encoding says that within a struct order does not
> > matter, only names. So if there's an implementation that is using
> > gensym'd names (I use id() myself) and requiring its recipients to know
> > the order, that implementation is wrong.
> 
> The SOAP spec say: "Each [in] or [in/out] parameter is viewed as an
> accessor, with a name corresponding to the name of the parameter and
> type corresponding to the type of the parameter. These appear in the
> same order as in the method signature."
> 
> In other words order matters for RPC parameters!
> 
> $server = SOAP::Lite
>         ->uri($ns)
>         -> proxy($server_url);
> 
> print $server-> f2c(70, 90)
>         -> result;
> 
> <?xml version="1.0" encoding="UTF-8"?>
>   SOAP-ENV:Envelope
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>   xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
>  xmlns:xsd="http://www.w3.org/1999/XMLSchema">
> <SOAP-ENV:Body>
> <f2c><c-gensym3 xsi:type="xsd:int">70</c-gensym3>
>      <c-gensym5 xsi:type="xsd:int">90</c-gensym5></f2c>
> </SOAP-ENV:Body></SOAP-ENV:Envelope>
> 
> --
> Take a recipe. Leave a recipe.
> Python Cookbook!  http://www.ActiveState.com/pythoncookbook
> 
> _______________________________________________
> Pywebsvcs-talk mailing list
> Pyw...@li...
> https://lists.sourceforge.net/lists/listinfo/pywebsvcs-talk

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com