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

[Paul P. <pa...@Ac...>]

Rich Salz wrote:
> 
> Yes, one of the things missing from ZSI is a dispatch framework.  There
> are a couple of reasons for that.  First, I wanted to get some feedback
> on usage models before "blessing" one particular style.  It's also a
> result of my transport-neutral approach; ZOPE's dispatch style is
> probably different from a dynamic application gateway, which is
> different from a dedicated apache-based web service, etc.

They both sound like arguments for a pluggable dispatch mechanism. So
you could plug in Zope dispatch or Apache dispatch or ...

> > >From a pedagogic point of view, may I suggest you start your
> > documentation with a SOAP "hello world." As in:
> >

>          <S:Body><hi/></S:Body>

Yep.

>         <hiResponse xsi:type="xsd:string">hello, world</hiResponse>
>         </S:Body></S:Envelope>
> is sent back?

Yes, that's what I would expect.

> Welll...  I suppose I could do something like that. :)  I do have a
> couple of questions, tho.  What if there is data in the sent <hi>
> element?  Is that parsed and passed as parameters to the hi() method?

Yes.

> Which must then check for parameters, or ignore them?

Yes.

> That is, can I do
>         <S:Body><hi><p1>you stinking</p1><foo>mongrel</foo></hi></S:Body>
> ?
> 
> It turns out, I believe, that SOAP::Lite won't actually be able to parse
> that message.  It requires the SOAP message to be fully typed.  But if
> it *could* parse it, I assume the p1 and foo parameters would somehow be
> made available (as a dictionary?) to Demo::hi.  But suppose hi takes no
> parameters?  Does Demo::hi have to error-check and be ready to generate
> faults?  More on this below...  I'm headed somewhere.

SOAP::Lite is written for Perl. Argument lists are always passed as just
lists. It is the programmer's choice whether to check the number of
arguments or not. And whether to use them or not.

>...
> It's easy to be loose and sloppy, but I think it's actually hard to do
> the right thing.  SOAP in RPC mode is really strongly-typed, and that
> makes an interesting mix when you work with loosely-typed scripting
> languages.  ZSI is different from other scripting SOAP implementations
> -- it seems to be the only Python one that can work with typed and -- if
> you have a "schema," in the form of ZSI "typecodes" -- completely
> untyped messages.  

The PHP SOAP seems to have a similar concept. Only simpler. :-)

$server = new soap_server;

/* 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;
}

> ... ZSI enforces type-correctness at th SOAP message
> level. If you want the "hi" method <hi>...</hi> to take any kind of
> parameter, you must explicitly say "TC.Any()" and ZSI will try interpret
> the message (provided it contains type information) or raise an
> "Unparseable message" exception.

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.

> "Python ZSI" is intended to evoke "Java RMI", on purpose.

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.

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.

> Attached is something that I could add to ZSI.  I think it works like
> the SOAP::Lite dispatcher, or as close as it can without using 'eval'
> :)  Not tested, but byte-compiled.

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?
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook