Status of SOAP and Python.

[Graham Dumpleton]

For those in the inner circle who now, where is SOAP for Python heading?

Current contenders that I know of and have tried are:

  PythonWare soaplib
  PyWebSvcs SOAP
  Zolera ZSI

There is also the ActiveState (??) .NET for Python stuff, but I don't know
much about that.

Anyway, PythonWare release was in June. It uses its own way of passing
dictionaries which no one else uses, making it only useful with itself.
Even then I find it doesn't want to work with itself sometimes, but then
that might be the way I am using the encode and decode routines directly.
Further, it only supports DateTime, Boolean and Binary beyond the basic
Python types. Ie., No Time, Date, Duration, etc. Also doesn't support None.

Next is PyWebSvcs of which the last release was also in June. This package
does a better job, although one downside is that when Boolean, Date and Time
types and also Binary (I think) are converted to Python objects, the type
information is lost, being passed as int, tuples of ints or strings. This
isn't useful if you are gatewaying all requests into a distinct system, ie.,
where you don't know the nature of what each call represents, but where
you need to preserve the type information.

Although there has been a little traffic on the pywebsvcs mailing list,
questions on the web forums haven't been getting answered and there have
been no responses to bug reports or feature requests. People are still
downloading the package, but in general, little indication of whether it
is still being actively developed.

Most promising new addition to SOAP support for Python has been ZSI from
Zolera. It also doesn't seem to support None and am having troubles with
its handling of dictionaries and the fact that a single object returned
by a remote method is returned in a single item list by client. Must admit
I am waiting for response on these issues in case I am missing something.

In general some of the other problems that come up with SOAP being used
in Python are the inability to seemingly pass an empty dictionary. In the
pywebsvcs package it translates these as empty strings where as in ZSI it
translates them as an empty array. The PythonWare stuff can handle an
empty dictionary, but then it can't talk to anything else. Being fair, I
believe the empty dictionary problem comes back to a problem in the SOAP
protocol itself.

Next on the list of problems with dictionaries is the default encoding for
SOAP in which dictionaries are encoded has keys encoded as element names.
This means that key values in a dictionary must not only be strings, which
is also the case with XML-RPC, but that the values of the keys must follow
XML element name conventions. This means you can't just stick anything in
a key. Whitespace is generally a bad idea, as are various punctuations
characters, leading numerical data, anything starting with "[xX][mM][lL]"
etc. Note that although in XML-RPC, you can only have strings for keys,
you can use any value for it (well perhaps maybe only ASCII if you ask the
purists).

Note that their is a encoding called Apache:Map (name?) which can be used
in SOAP to get around the key is string restriction, ie., any value for
string, but also any type for key. The ZSI package has support for this,
but the others don't. Because this is outside the standard encoding for
SOAP, one can't expect SOAP implementations in other languages to support
it either. Hell will probably freeze other before Microsoft supports it
and I am sure they will come up with their own way of doing the same thing.

In terms of the implementations which are available there is no one way
of how faults should be handled, Again this is partly due to SOAP making
fault details use definable. This makes it confusing when you are trying to
pack the error messages of some distinct system into a SOAP fault, especially
when the SOAP packages idea of how to handle faults are more or less melded
with their particular dispatch mechanism, ignoring that someone may want to
use just their encoding and decoding routines in a different framework.

Anyway, the end result of all this is that I see SOAP in general as a mess.
In relation to Python and SOAP, I don't see the combination of the two to
be that inspiring. Right now, other RPC over HTTP protocols with the
simplicity of XML-RPC seem to be a better match with Python, although must
say that XML-RPC doesn't support None. But then, various people have added
it themselves and yet more have developed their own new protocols.

Enough of the rambling I guess. How do others see where SOAP is going in
relation to Python? Do people still think SOAP is the best thing since
sliced bread, or are people starting to realise it is pretty crappy after
all? What other SOAP for Python implementations are there out there? Does
anyone know if PythonWare and pywebsvcs are going to be coming out with
updated implementations? Is there any point in trying to provide a SOAP
gateway into a system capable of being used to build web services when it
already supports XML-RPC as well as a much more functional RPC over HTTP
protocol albeit one that is particular to that system? Anyone have any
better ideas?