SOAP frustrations

[Graham Dumpleton]

Andrew Dalke <adalke at mindspring.com> wrote in message news:<3DAC6F04.2030704 at mindspring.com>...
>
> All in all, it's rather discouraging for me to work with SOAP in
> Python, and that's given a rather non-trivial amount of experience
> in doing Python.  I would think others have worse problems.
> 
> It's such that the more CS-y people at my client's site believe that
> web services in Python are still very immature and want to switch the
> project over to Java and WebLogic(!).  (I did point out that developing
> the library I did was still less time than setting that up, but there
> are other factors in the mix as well.)
> 
> What I don't get is, I figure there's enough people doing web services/
> SOAP with Python that there shouldn't be these problems.  Why then am
> I so frustrated with it?

A few strange questions which you might answer for me. Would be interested
in feedback from others as well.

What specifically do you believe you gain from using Python as opposed to
another language for implementing a web service where SOAP is specifically
used to interface to it? Are you specifically after a solution which is
pure Python or would you accept a system which allows you to use Python
to write your web services but where the bulk of the system is actually
C++? Do you want a system whereby you are dealing directly with SOAP
concepts, or is a more generic service API which might be callable from
XML-RPC as well as SOAP sound better?

I ask for the purposes of trying to determine how people feel about hybrid
systems using Python and C++. Yes they may not be as simple to set up in
the first place because of the extra step of having to compile C++ code,
but if the end result is still just as easy to use for those who want to
write only in Python, is the reliance on C++ a deterent?

The problem I have at the moment is that I have a system which is C++ at
its core and provides a means of building standalone or distributed systems
whereby services within the system communicate using an internal messaging
system. Those same services however, can also be accessed using XML-RPC
using a RPC over HTTP gateway that plugs easily and transparently into
the system.

With the way the system works, you can use C++ exclusively, Python exclusively
or a mix whereby some processes use Python and some use C++. In all cases
where Python is used, it is still not pure Python but a wrapper around the
C++ core.

At the moment, there is actually a SOAP gateway as well, but it relies on
using either ZSI or SOAP.py. From my experience in using those packages I
can relate to your frustrations as they don't always work how they should.
For those reasons I don't specifically promote there use and suggest people
use the XML-RPC interface if they need remote access in that way.

Note that whether XML-RPC or SOAP is used, in writing your service, you
are quite divorced from those interfaces and you write to a more generic
messaging system API. This obviously means that you can't explicitly
manipulate SOAP messages and you may not have access to all SOAP features.
It does however possibly mean that the whole thing is much easier to use
as something else worries about all the hard parts for you.

What I have been thinking about lately is using an existing C++ library
for SOAP, rather than a Python one, to write a RPC over HTTP gateway into
this system. I know this will most likely be more complicated to get
working in the first instance than when Python was used, but does achieve
the same end. That is, you can still write your services in Python, it is
just that the bit handling the SOAP requests is written in C++ and in
between the underlying messaging system handles the translation.

Such a system obviously means a bigger commitment than wacking together a
quick once off SOAP CGI script for one task. Such a system has the potential
to dramatically alter how you might otherwise implement a system. For a
real simple system it might be viewed as overkill, but for a large system,
it certainly has the range of functionality to make the task a lot easier.

Enough of the ramble. My final question and one for which I wouldn't be
surprised if I got no answers, is are hybrid frameworks for building more
general purpose service based systems, where web access is a useful extra,
of interest to Python programmers?

As much as it might have to offer in certain areas, so far, it seems to be
a hard slog in getting Python programmers interested.