SOAP strategies

[Paul Watson]

What are the reasonable current day choices and best bets for the future
when doing SOAP programming in Python? SOAP batteries do not appear to
be in the standard Python distribution.

Most of the SOAP related information I have been able to find on the web
is from 2001-2002. I am not sure if some packages are still maintained.
Most of this is old news.

http://soapy.sourceforge.net/
http://pywebsvcs.sourceforge.net/ (SOAPpy)
and what is the relation of this to ZSI

http://www.intertwingly.net/stories/2002/12/20/sbe.html
http://www.ibm.com/developerworks/library/ws-pyth5/
http://www.opensourcetutorials.com/...oding/Python/python-soap-libraries/page1.html

http://www.gossamer-threads.com/lists/python/python/619251 This is
current, but is this a long term strategy or a short term tactic?

 

[Paul Watson]

What are the reasonable current day choices and best bets for the future
when doing SOAP programming in Python? SOAP batteries do not appear to
be in the standard Python distribution.

Most of the SOAP related information I have been able to find on the web
is from 2001-2002. I am not sure if some packages are still maintained.
Most of this is old news.

http://soapy.sourceforge.net/
http://pywebsvcs.sourceforge.net/ (SOAPpy)
and what is the relation of this to ZSI

http://www.intertwingly.net/stories/2002/12/20/sbe.html
http://www.ibm.com/developerworks/library/ws-pyth5/
http://www.opensourcetutorials.com/...oding/Python/python-soap-libraries/page1.html

http://www.gossamer-threads.com/lists/python/python/619251 This is
current, but is this a long term strategy or a short term tactic?

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.

 

[Paul Boddie]

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

 

[Paul Watson]

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?

 

[Paul Watson]

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?