SOAP frustrations

[Andrew Dalke]

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

Sure.  Some background first.

The project I'm working on uses Python to integrate about 30 other
programs into one consistent interface.  On top of that is a web
application to interface to that Python code.  This is all intranet
access only.

People would like to use the service to compute various properties,
and use it as a RPC from whichever client.  Requests are conceptually
stateless and RPC-like, but the existing CGI interface is more
complicated than that in order to improve usability.  (Eg, the results
page provides alternative ways to view and download the data that
a client wouldn't need.)

So not only would screen scraping be bad because it makes it hard
for use to change the CGI-based systems, it's more complicated because
the client would need to turn a stateful server into a stateless one.
Hence we decided to work on a new way to access the service.

The clients can be from Python, Perl, VB, C++, and perhaps a couple
other languages, so we want something where libraries already exist.
We are already running a web server and would prefer not running
another one.  And yes, we are not immune to buzzwords, so SOAP comes
before XML-RPC on the list of mechanisms to consider.

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

Most of the project is written in Python (others in Perl, C, and in
domain-specific languages for each of the different components).  So
a big gain is reduction of mental effort when switching between
different parts of the system.

We could also use Perl, but I am a Python advocate so have my own
biases.  We don't have any existing Java code, so using that would
be rather more work.

I personally prefer pure Python because it's easier to install and
maintain.  (Eg, some of the machines don't have a C compiler, but
it's easy enough to go to a machine that does during installation.)
We already use extensions written in C so this isn't a real sticking
point.

We still prefer a way to use the web services under a .cgi model,
spawned off from the web server, although integration with Apache
is not out of the questions.

I know little about "SOAP concepts."  I want to do RPC.  I want
a list of arguments and I want to return a simple data structure.
I asked about XML-RPC.  No one said they wanted to run an XML-RPC
client if SOAP is functionally equivalent.  No one mentioned any
other API besides SOAP they wanted to use.  Yes, I could also
consider CORBA and DCOM, but I don't know how to layer those on
top of a web server, so setting up a new server would call for more
complicated administration.


> I ask for the purposes of trying to determine how people feel
 > about hybrid systems using Python and C++.

We've already got C extensions for Python.  I believe the C++
compiler is also installed on their systems, so this wouldn't be
a serious consideration.

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

There is a Python project called Twisted, which is a general purpose
service based system.  I looked at Twisted since I figured it might
have SOAP support, but it does not.  Zope also fits, since it has
(as I recall) multiple ways to access its services.

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

It may be that my needs are rather simple.  I don't need a larger
framework -- I don't need multiple protocols nor real object
support.  So I prefer not having to learn a complicated solution
to make things work.  Thus it would be hard to convince me to
use your system.

					Andrew
					dalke at dalkescientific.com