Status of SOAP and Python.
Graham Dumpleton
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?
Martin von Loewis
> 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?
I certainly hope that SOAP is going to disappear rather sooner than
later, and that people who care about distributed systems come back to
well-defined interfaces, and efficient marshalling.
Regards,
Martin
Gabriel Ambuehl
Hello Martin,
Monday, October 08, 2001, 1:43:02 PM, you wrote:
>> 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?
> I certainly hope that SOAP is going to disappear rather sooner than
>
Considering that .NET is based on SOAP, this is rather unlikely to
happen. Now if .NET would disappear too...
> later, and that people who care about distributed systems come back
> to well-defined interfaces, and efficient marshalling.
So what do you recommend to use instead of SOAP? XML-RPC? Classic RPC
(*uaah*)?
Best regards,
Gabriel
Maxû¿ œ D
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5i
iQEVAwUBO8GJ9cZa2WpymlDxAQExBAgAzJBIMc2ss/vNXCfP/o4q7L7Nt4gC6/G4
XP+JgmcbynQOOh12EnlloT5wbWjDCtJ2fNtTDmzhST18CNy/B1jMwHrJNOiIveuW
meUyoTroZOwpCqhSGPqHrMpuGIcE5JioNOkF2nhH1Gp94eHd7pk8PA2b4ecXYkVi
A7WNsphBm5BDOZ2uzypej7rnGsb7aY+fqldDmWPCTy5aFPRAwkUKeeJ5ZnBybWVu
3b8G4eWfKJmffkis3IQswnX7F8YHIHFXtO0YNb7O246z3hwVPDX/tC7Hv6uZl6QA
cVUwJjiE50iPHSjD7eIKW+bZ5fVBm+6r+WYEVGeJdD0EEwEbdhw+YQ==
=5aDs
-----END PGP SIGNATURE-----
Martin von Loewis
> > I certainly hope that SOAP is going to disappear rather sooner than
> >
>
> Considering that .NET is based on SOAP, this is rather unlikely to
> happen. Now if .NET would disappear too...
I can only speculate on the future of .NET, given that it is not even
released yet... OTOH, I did speculate on the future of SOAP, too :-)
> > later, and that people who care about distributed systems come back
> > to well-defined interfaces, and efficient marshalling.
>
> So what do you recommend to use instead of SOAP? XML-RPC? Classic RPC
> (*uaah*)?
I still think CORBA is technically sound and convenient to use.
Regards,
Martin
David Bolen
> So what do you recommend to use instead of SOAP? XML-RPC? Classic RPC
> (*uaah*)?
I think it depends on what you need out of your RPC layer. If I
recall correctly, SOAP certainly aims higher than XML-RPC in terms of
object invocation as opposed to simple RPC, so their can be advantages
there. But that also introduces complexity. Also, there's the
question of whether you really need compatibility with other
systems/languages.
We've used XML-RPC successfully for internal communication in a
scheduling system we use, but as it turned out over time, the system
remained soley Python, so the interoperability issue turned out not to
be one, and in retrospect having to work a bit around issues such as
not supporting None and dictionaries must use string keys could have
been unnecessary. But it did certainly get things rolling quickly is
easy to use from Python.
For another remote site management tool, where information transferred
and transparency to upper level Python layers was most important (and
interoperability outside of Python wasn't), we just went to a simple
locally written RPC mechanism where the payload of the RPC was a
binary pickle compressed with zlib. Works very well and can pass
anything the Python scripts on either side may need to deal with (we
haven't had to do any custom marshalling yet although that may happen
if we run into an object that won't serialize by default).
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/