Pages: 1, 2
Now What do I do With It?
There are two approaches you can take to your SOAP education. One is to regard SOAP simply as a featureful, remote-procedure mechanism. It's useful in that role. Many organizations are rolling out internal applications that rely on SOAP as a public programming interface. SOAP's portability plays nicely in this game. It's convenient to write servers in systems programming languages including Java and extended SQL while rapidly developing clients in languages like Visual Basic, Python, and Delphi. You can also use PySOAP to write servers in Python with as little code as
import SOAP def echo(s): return s + "\n " + s server = SOAP.SOAPServer(("localhost", 8080)) server.registerFunction(echo) server.serve_forever()
You'd access this in Python with
import SOAP server = SOAP.SOAPProxy("http://localhost:8080") print server.echo("Hello, there ...")
Notice what the SOAP module achieves:
echo, is defined on the server side but is exposed as a method available for use in the client. The PySOAP distribution includes a
SOAPpy095/README with salient examples of client and server use.
You can also use SOAP to communicate across an organizational boundary. In this model, SOAP is part of a larger, emerging standard called Web Services. Web Services provide computer-to-computer information and communications similar to the way the Web currently mediates between computers and humans. Think of it this way: the Weather Channel delivers pages humans can read, with information about temperature and other conditions. The XMethods service demonstrated above renders similar information, in a form that's handy for further automated computations.
If you're a public utility, for example, you might use public Web Services for temperature, humidity, fuel prices, and other variables to calculate improved management of power generation and distribution.
XML-RPC vs. SOAP
One of the best-documented Web Services is the Meerkat syndication service. Meerkat uses XML-RPC to communicate content and information about content. How does SOAP compare to XML-RPC? Which should you use?
As of June 2001, XML-RPC remains more mature and simpler to implement. However, there are several reasons I favor SOAP for my own development work. XML-RPC's easier implementation matters little to me in application programming because PySOAP wraps up SOAP's difficulty. With a good SOAP binding in hand, I find SOAP's scalability, extensibility, transaction-awareness, and transport flexibility make it easier to use than XML-RPC for typical problems. XML-RPC is only a remote-procedure technology, with a fixed set of data types and XML element names. SOAP adds to these the ability to marshal objects (in the sense of an object-oriented language like Python) and messages, and it can also communicate named parameters and attributes.
As convenient as I find PySOAP, I exaggerated when I wrote, "PySOAP wraps up SOAP's difficulty." The SOAP specification defines many variations and options, only a fraction of which PySOAP 0.95 implements. It's the most important fraction, though, and even the 0.95 release is an adequate base for plenty of useful development.
If you're a consumer of a public SOAP service, like one of those listed on XMethods, you'll need to use SOAP rather than XML-RPC. Moreover, industry heavyweights including IBM and Microsoft have sent clear signals that they've decided SOAP is their long-term preference as a remote-procedure protocol.
Return to the Python DevCenter.