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

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

> /* 3. call the add_to_map() method for each service (function) you want
> to expose:
> 
> $server->add_to_map(
>         "echoString",           // function name
>         array("string"),        // array of input types
>         array("string")         // array of output types
> );
> 
> function echoString($string){
>         return $string;
> }

The interop server code included with ZSI works almost exactly like
this.

> Why not let the programmer decide how strongly or loosely typed he or
> she wants to be. If you know something is a string, pass it as a string
> and if they don't want a string, they'll throw an exception.

You can do that by using an ANY typecode.  SOAP structures become
dictionaries, all other data better be typed.

> I thought that Java RMI tries to be as transparent as possible. If you
> are calling from a dynamically typed language into the same dynamically
> typed language (which is one possible configuration), it seems strange
> to insist on a statically typed layer in between.

Well as I said, soap is a typed layer.  It's intended to evoke RMI in
that rather than creating dictionaries, etc., ZSI creates python objects
by call __init__ and then calling setattr() as it find data within the
SOAP struct.

> Also, for a service described WSDL, the typecode becomes irrelevant as
> your documentation says. So it is possible to be both concise and strict
> if you push the strictness into the WSDL.

Yes.  The next step would be to have a WSDL compiler (which is trivial,
except for the part that needs to do XSD:) and have the "typecodes"
generated automatically.  So that whole big chapter of the doc melts
away into an internals doc.

I don't believe most web services will be "send me any data" kinds of
things.  I think they will support statically defined interfaces.  So by
enforcing proper message format at the SOAP (ZSI) layer, the application
doesn't have to do any kind of checking.  It's equivalent to validating
the incoming document against a schema.

There *are* places where this approach doesn't hold.  Generic gateways,
browser-based.. "browsers" etc., where you want things like a Corba
InterfaceRepository or COM typelibs. You can do that with ZSI -- it's
what most toolkits seem to support -- but I think that's the minority
use.

> It looks good to me! One question, though...do the args get passed as
> DOM nodes or do you do conversions based on XSI:type? Will multiple arg
> RPC calls get expanded to multiple Python args or do you always get
> exactly one argument?

You get exactly one argument that is a python dictionary
	<foo>
		<a xsi:type="xsd:string">hello world</a>
		<b2>
			<nest1 xsi:type="xsd:string">yes</next1>
			<n2 xsi:type="xsd:float">NaN</n2>
		</b2>
		<c xsi:type="xsd:integer">123</c>
	<foo>
Then the following call will be made
	foo({a: u'hello world', b: {nest1: u'yes', n2: float('NaN')}, c: 123})

Make sense?
	/r$

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