pywebsvcs-talk — General discussion of Python and web services

Re: [Pywebsvcs-talk] Dictionaries

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

> I was using the SOAP-Implementation from Actzero, yet.
> With that I just called a method with a dictionary and the Arguments Names
> were serialized as Tag Names:
> 
> order({"amount":"1", "othervalue":"some"})
> 
> <order>
> <amount xsi:type="xsd:string">1</amount>
> <othervalue xsi:type="xsd:string">some</othervalue>
> </order>
> 
> I couldn't find a way to do that with ZSI.

Try setting "aslist=0" when you create the Binding, or call AsList(0) on
the binding object after it's created.

> Another Problem:
> When using dispatch.AsCGI(myModule) it seems to call the right method, but
> generates a SOAP-fault saying "Loop over non-sequence".
> I altered the SOAP-Requests and the values, the remote method returns. The
> error remained.

I'm not sure what you mean.  If the method is getting called, then the
incoming message is being parsed.  So we need to see if the return
message is being parsed, or if it is an error in your code.  After you
create the binding, but before you invoke any message, try doing
<binding>.h.set_debuglevel(1)
	/r$
-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

RE: [Pywebsvcs-talk] Sending Literal XML with SOAP.py

[Dave S. <da...@mi...>]

I haven't tried that, but I do have a method that successfully returns HTML
in the body.  It simply returns a string that happens to consist of HTML
text.  SOAP.py escapes it in the payload (e.g., '<' to '&lt;'); I would
guess that it would do the same thing with XML test.

- Dave

-----Original Message-----
From: pyw...@li...
[mailto:pyw...@li...]On Behalf Of Michael
Svoboda
Sent: Tuesday, September 25, 2001 4:11 AM
To: pyw...@li...
Subject: [Pywebsvcs-talk] Sending Literal XML with SOAP.py


Is it possible to send Literal Xml in the SOAP Body using SOAP.py?
I couldn't find an example. Is there one?

Michael Svoboda

_______________________________________________
Pywebsvcs-talk mailing list
Pyw...@li...
https://lists.sourceforge.net/lists/listinfo/pywebsvcs-talk

[Pywebsvcs-talk] Dictionaries

[Daniel A. <da...@we...>]

I was using the SOAP-Implementation from Actzero, yet.
With that I just called a method with a dictionary and the Arguments Names
were serialized as Tag Names:

order({"amount":"1", "othervalue":"some"})

<order>
<amount xsi:type="xsd:string">1</amount>
<othervalue xsi:type="xsd:string">some</othervalue>
</order>                     

I couldn't find a way to do that with ZSI.
Is there?


Another Problem:
When using dispatch.AsCGI(myModule) it seems to call the right method, but
generates a SOAP-fault saying "Loop over non-sequence".
I altered the SOAP-Requests and the values, the remote method returns. The
error remained.


--
Daniel Allgaier (da...@we...)

[Pywebsvcs-talk] Sending Literal XML with SOAP.py

[Michael S. <mic...@so...>]

Is it possible to send Literal Xml in the SOAP Body using SOAP.py?
I couldn't find an example. Is there one?

Michael Svoboda

[Pywebsvcs-talk] Wrong Parameter Order

[Michael S. <mic...@so...>]

I'm using Python-SOAP as a client and Apache SOAP on the server side.
I deployed ther a method that has following signature:

doSomething(boolean isMember, String name, String text)

As far as I know, the Apache implementation considers just the order and
type of the methods parameters (And not name). Thus Apache needs the
parameters in the envelope in this order:
boolean, String, String

I use "SOAP.py" it seems to mee that it sets the order of the parameters
"randomly".

My Python call is like this:

server.doSomething(isMember = SOAP.booleanType(1) , name = 'Peter' ,
text = 'bla bla')

Python then generates this order in the body:

<ns0:doSomething xmlns:ns0="urn:doSomething">
	<name xsi:type="xsd:string">Peter</name>
	<isMember xsi:type="xsd:boolean">true</isMember>
	<text xsi:type="xsd:string">bla bla</text>
</ns0:doSomething>

But I would something like this:

<ns0:doSomething xmlns:ns0="urn:doSomething">
	<isMember xsi:type="xsd:boolean">true</isMember>
	<name xsi:type="xsd:string">Peter</name>
	<text xsi:type="xsd:string">bla bla</text>
</ns0:doSomething>

Has anyone an idea or a workaround?

Thanks for your help
Michael

Re: [Pywebsvcs-talk] Order of method parameters?

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

Generally, if you are using names, the order isn't supposed to matter.

(SOAP sec7 says RPC is modelled as a struct. SOAP sec5 says structs are
distinguished by name, not position.)

My guess is SOAP.py relies on Python just turning the keyword parameters
into a dictionary, so the order is lost before SOAP.py gets it.

If the order matters, try using just an argument list.
	/r$

PS:  Please subscribe.
-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

[Pywebsvcs-talk] Order of method parameters?

[Michael S. <mic...@so...>]

I got the following problem.
I'd like to call a method with these parameters:

server.doSomething(isMember = SOAP.booleanType(1) , name = 'Peter' ,
text = 'bla bla')

The order of the parameters I'd like to have is:
boolean, String, String

But when I look at the generated SOAP envelope the order is like this
(see below for the whole envelope):
String, boolean, String

Why does the Implementation changed the order? Did I miss something?

Thanks for your help.
Michael 


SOAP Envelope:

POST /soap/servlet/rpcrouter HTTP/1.0

Host: localhost:8070

User-agent: SOAP.py 0.9.6 (actzero.com)

Content-type: text/xml; charset="UTF-8"

Content-length: 573

SOAPAction: ""



<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
<SOAP-ENV:Body>
<ns0:doSomething xmlns:ns0="urn:doSomething">
<name xsi:type="xsd:string">Peter</name>
<isMember xsi:type="xsd:boolean">true</isMember>
<text xsi:type="xsd:string">bla bla</text>
</ns0:doSomething>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

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

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

Last week, Paul asked to be able to do this:
	#! /usr/bin/env python2.1
	import zsiserver
	...various functions...
	zsiserver.serve_forever()

This was analogous to the CGI-oriented dispatching we talked about the
previous week.

I added it, and it's in ZSI1.1 which will be released by the end of the
week.  I think I already mentioned the scripting-like client code.

So here's a script that can be either CGI or a stand-alone server:

    #! /usr/bin/env python2.1
    from ZSI import dispatch

    def hello(*args):
	return 'hello world'

    def auth():	#
	cb = dispatch.GetClientBinding()
	if not cb: return 'No binding avail'
	return cb.GetAuth()

    def echo(*args):
	args = list(args)
	args.append("It would be my pleasure to connect you.")
	return args

    def incr(*args):
	return [ k + 1 for k in args ]

    def average(*args):
	sum = 0
	for i in args: sum += i
	return sum / len(args) 

    if __name__ == '__main__':
	dispatch.AsCGI()
	#dispatch.AsServer(port=8000)

Here's client use:
	from ZSI.client import Binding, AUTH
	a = Binding(url="/cgi-bin/x")
	a.echo(1,2,3)
	a.SetAuth(AUTH.httpbasic, 'name', 'password')
	a.auth()

You can also use typecodes by invoking Send and RPC, e.g., with
params that describe the data.

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 did ask, and one person responded that the pragmatic thing to do is
turn off ordering.

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

And that is what I did.

> > $server = SOAP::Lite
> >         ->uri($ns)
> >         -> proxy($server_url);
> >
> > print $server-> f2c(70, 90)
> >         -> result;

s = SOAPIO('host:port', '/cgi-bin/dispatch')
print s.echo(1,2,3)
print s.foo('hello', 'world')
print s.echo('hello mom')

you can also get a "bound function"
	f = SOAPIO('host:post', '/some/uri', ssl=1).Delete
	f('/dev/null')
	f('c:/autoexec.bat')
etc.

There are also "modifiers" so you can do things like
	s.SetAuth(AUTH.httpbasic, 'myname', 'mypass').foo('bar')

It's built on top of httplib, so SSL is supported where available, but
proxies are not supported.
	/r$

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

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

In addition to leaving mail drippings, I forgot to add ...

> I got thinking about this because other languages can do multi-arg
> functions without a problem but ZSI only does one dictionary argument.

I did that because it's easy to get the calling sequence right, and
generic.  I suppose
	def foo(*args):
works just as well ...
-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

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

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

Arg, I slipeed and hit SEND by mistake.  Please ignore all those extra
mail-list trailers. :(

	/r$

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

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

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

Rich Salz wrote:
> 
> ...
> 
> Somewhat flip answer: without external schema information you don't know
> that the order matters. If you do know that the order matters, then do
> it Right (sic :) and use typecodes.

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.

> 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

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

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

Paul Prescod wrote:
> 
> It would be great if I could also do this:
> 
> #!/usr/bin/env python2.1
> import zsiserver
> 
...various functions
> 
> zsiserver.server_forever()

Sure.  You'll need at least one parameter, the URL, and I'd want to let
you do a whole bunch of registers (possibly with namespace) and then a
serve_forever ...  But that basic thing is no problem.  I assume you
don't care if it's built on python's httpserver.

> > The input arg will be a possibly-empty
> > dictionary;
> 
> I think there is a problem here. Some SOAP implementations generate
> bogus names (typically gensym) and depend instead on the *order* of
> parameters. But wrapping them in a dictionary loses order.

Somewhat flip answer: without external schema information you don't know
that the order matters. If you do know that the order matters, then do
it Right (sic :) and use typecodes.

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.

Order *does* matter for arrays, of course, and ZSI does them as python
lists.

	/r$

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

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

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

It would be great if I could also do this:

#!/usr/bin/env python2.1
import zsiserver
 
def hello(arg):
    return 'hello world'
 
def echo(arg):
    arg['Server'] = "It would be my pleasure to connect you."
    return arg

def incr(arg):
    for k,v in arg.items():
        if type(v) == type(1): arg[k] = v + 1
    return arg

zsiserver.server_forever()

Also, you said:

> The input arg will be a possibly-empty
> dictionary;

I think there is a problem here. Some SOAP implementations generate
bogus names (typically gensym) and depend instead on the *order* of
parameters. But wrapping them in a dictionary loses order.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook

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

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

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

I wrote a simple CGI dispatcher, took about 70 lines.  I'll add it to
ZSI 1.1, which will be released over the weekend.

Here is a sample CGI script.  The input arg will be a possibly-empty
dictionary; the return value is serialized back to the client.

#! /usr/bin/env python2.1
import cgizsi 

def hello(arg):
    return 'hello world'
        
def echo(arg):
    arg['Server'] = "It would be my pleasure to connect you."
    return arg
        
def incr(arg): 
    for k,v in arg.items():
        if type(v) == type(1): arg[k] = v + 1
    return arg
    
cgizsi.dispatch()

The dispatch method actually takes a list of module names to search, the
default is __main__.

I don't think I can make it any simpler. :)
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

[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

[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

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

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

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.

> >From a pedagogic point of view, may I suggest you start your
> documentation with a SOAP "hello world." As in:
> 
> use SOAP::Transport::HTTP;
> 
> SOAP::Transport::HTTP::CGI -> dispatch_to('Demo') -> handle;
> 
> package Demo;
> sub hi { return "hello, world"; }
> sub bye { return "goodbye, cruel world"; }

Does this mean that an incoming message like
	<S:Envelope xmlns:S="....">
	 <S:Body><hi/></S:Body>
	</S:Envelope>
means that the &Demo::hi() is invoked and a return packet like
	<S:Envelope xmlns:S="....">
	<S:Body>
	<hiResponse xsi:type="xsd:string">hello, world</hiResponse>
	</S:Body></S:Envelope>
is sent back?

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? 
Which must then check for parameters, or ignore them?
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.

> I'm trying to work up a talk on how EASY it is to work with SOAP in
> scripting languages.

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

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

> I'll try to boil your example down to the barest
> essence and see how close it gets to SOAP::Lite. :-)

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.
	/r$

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

[Pywebsvcs-talk] Minor patch for SOAPpy 0.9.7

[Rob J. <ro...@un...>]

In SOAPpy 0.9.7, SOAP.SOAPBuilder.dumpList has

                try:
                    typename = last._typename
                except:
                    typename = "SOAPStruct"

The variable "last" doesn't exist.  The except clause catches the resulting
exception and forces the typename of the array to always be "SOAPStruct".

Changing it to:

                try:
                    typename = sample._typename
                except:
                    typename = "SOAPStruct"

fixes it.

I noticed this because your bid sample was producing, in the Buy request,

	<items SOAP-ENC:arrayType="ns1:SOAPStruct[2]" xsi:type="SOAP-ENC:Array">

instead of the correct

	<items SOAP-ENC:arrayType="ns1:LineItem[2]" xsi:type="SOAP-ENC:Array">

I have also filed this as a bug on the sourceforge pywebsvcs site.

What's the upcoming timetable for SOAPpy?  It's pretty wonderful already,
actually :-)

Cheers,
Rob

[Pywebsvcs-talk] Test, please ignore

[Ng P. S. <ng...@po...>]

Pardon, people. Just checking...
-- 
Ng Pheng Siong <ng...@po...> * http://www.post1.com/home/ngps

Quidquid latine dictum sit, altum viditur.