SOAP.py and Python 2.1.1

[Graham Dumpleton]

Gabriel Ambuehl <gabriel_ambuehl at buz.ch> wrote in message news:<mailman.1002532328.1438.python-list at python.org>...
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Hello Andrew,
> 
> Monday, October 08, 2001, 12:46:22 AM, you wrote:
> >> This confuses me cause I thought xml should be available from
> >> stock and I've even got expat-1.2 and expat 1.95 installed so
> >> what's wrong here?
> > IIRC, the pyexpat module frequently doesn't get built
> > automatically, even when expat is installed.  You'll need to
> > manually, build it.
> 
> Ok, so I installed PyXML-0.6.6 by hand. Now pyexpat is no longer
> missing, but SOAP.py still doesn't work (not even the card test)
> cause
> it complains about unsupported UTF-8 encoding:
> 
> <unknown>:1:36: Unsupported encoding 'UTF-8'
> 
> Am I better off using another SOAP toolkit or XML-RPC?

Another SOAP toolkit I am looking at at the moment and which looks quite
promising is ZSI from Zolera. The address is:

  http://www.zolera.com/resources/opensrc/zsi/zsi.html

I have found a few issues with it in the way I am trying to use it, but
have come up with fixes and am conversing with the author about it. ZSI
still has good backing whereas the pywebsvcs code is in slow mode as the
people who were developing have changed jobs and don't have as much time
to work on it. The pywebsvcs people are happy to take on more maintainers
if anyone is offering though.

Whether you go SOAP or XML-RPC depends a bit on what you are trying to do.
One difference is that with SOAP there is the concept of being able to
provide a strict schema defining what requests should look like. This can
be an aid to client developers who want to talk to your system. SOAP also
has various other features which XML-RPC doesn't, such as named parameters
as well as positional parameters, whereas XML-RPC only supports positional
parameters.

I don't know what type of system you are trying to build, but you might
have a look at OSE. I am not suggesting OSE from the point of view of one
particular protocol or the other but more so the philosophy of the framework.
What OSE lets you do is write systems which can be called using either
SOAP or XML-RPC protocols, albeit only with positional parameters for both.

Right now OSE is using its own python implementation of XML-RPC and is
dependent on the pywebsvcs SOAP.py for SOAP. In the nest release however
it has been structured so that it can be configured to use different
implementations of XML-RPC and SOAP encoders/decoders depending on what
you have.

When it ships it will probably be configured to use a C++ implementation
of XML-RPC which comes with the package. This will croak if you start passing
it CDATA, XML comments, processing instructions etc. If that is a problem,
with just one variable setting, you will instead be able to switch to a
Python XML parser based implementation which again comes with the package.
This of course will run slower. Still not happy, then there are also bindings
for using the PythonWare and py-xmlrpc implementations. Similarly with SOAP,
there will be bindings for the PythonWare, pywebsvcs SOAP.py and hopefully
ZSI implementations.

The important bit is that despite which implementation of the protocol you
use, your server code stays the same. You can therefore quite happily change
from one protocol implementation to another if one implementation causes
you problems. If you want, you can even mark up specific services against
different URLs using different protocols. Ie., one process could be accessible
at the same time using not only SOAP and XML-RPC protocols, but multiple
implementations of each at the same time.

Some may think this is going a bit overboard, but frankly with the less than
optimal interoperability of some SOAP packages at the moment, being able to
use multiple implementations at the same time can be a bonus. At least until
the implementations become more solid.

Anyway, if you find OSE of interest, if you can't get pywebsvcs SOAP.py
to work under it, you can still develop services but use XML-RPC. That
or even use NET-RPC, yet another XML-RPC like protocol which it supports.
Then down the track, you can offer SOAP access when you work that out and
not have to change your actual server code.

If you want to know more about OSE, have a look at:

  http://ose.sourceforge.net

If you want a sneek preview at slightly more updated version of documentation
for next release, have a look at:

  http://ose.sourceforge.net/python-manual.pdf

Note that the latter documentation doesn't talk about the ability to switch
protocol implementations yet though. :-)

BTW, OSE is released under the QPL. More information on the site.