SOAP strategies

Paul Watson paul.hermeneutic at gmail.com
Tue Feb 19 22:12:55 CET 2008


On Tue, 2008-02-19 at 10:01 -0800, Paul Boddie wrote:
> On 19 Feb, 16:59, Paul Watson <paul.hermeneu... at gmail.com> wrote:
> >
> > Have I offended?  My apologies if I have.  I thought I showed that I had
> > done some homework and used Google and did the other things to show that
> > I was willing to put forth some effort.  Please tell me if I have missed
> > something.  If I should look somewhere besides Python for doing SOAP,
> > then please say that also.  Thanks.
> 
> There's a Wiki page here about Web services in Python:
> 
> http://wiki.python.org/moin/WebServices
> 
> I don't think that there's been a great deal of visible activity
> around SOAP in the Python community other than that you've already
> noticed. I entertained the idea of doing some more complete SOAP
> support as an add-on to the libxml2dom project, but not wanting to
> implement all the related specifications (schemas, service
> descriptions), I struggle to see the benefit compared to simpler
> solutions.
> 
> That's not to say that SOAP has no value. Clearly, if you consider the
> different "use cases", SOAP is probably more appropriate for some than
> other solutions would be. If one were exposing some kind of repository
> through some kind of Web service, I'd consider approaches like REST,
> along with technologies like WebDAV (which overlaps with REST), XML-
> RPC and SOAP. But if the Web service were to involve issuing
> relatively complicated queries, and/or the repository wasn't strictly
> hierarchical (or couldn't be elegantly represented in such a way),
> then it would arguably be less appropriate to deploy a "pure" REST
> solution, favouring XML-RPC and SOAP instead.
> 
> What undermines SOAP for me is that if I'm not too interested in
> treating it like some kind of RPC mechanism, then I can get most of
> the pertinent benefits from exchanging plain XML documents. You can,
> of course, do SOAP like this, but the obligation to look after the
> boilerplate elements (which should permit lots of fancy features like
> "routing", if such stuff is actually used in the real world) seems
> like a distraction to me.
> 
> Paul

Many thanks for your comments.  I will take a look at the site.

My primary orientation is in accessing large (one or more terabyte)
databases and doing data integration (ETL, ELT, EAI, EII) work.  Any
other suggestions?




More information about the Python-list mailing list