Re: [Freecats-Dev] Dan's API - first remarks

[Michael Roberts]

Henri Chorand wrote:

> If I got it well, you suggest using SOAP as a general RPC (remote procedure
> call) mechanism. I only have a basic understanding of this, and I don't have
> any opinion about which one to choose and implement.
>
> Let me know if there is a not-too-technical description of SOAP somewhere,
> it will interest people like me.
Somehow I think my reply yesterday didn't go to the whole list -- I 
mentioned that I've had a lot of success with SOAP under Python in the 
last couple of months and I'm for this solution.  It's true that it's 
not the most bandwidth-friendly of protocols, but it's easy to use and 
to debug, and it's compatible with other stuff I've done.

Anyway, the upshot of SOAP (over HTTP, which is it's most common form) 
is that it presents arbitrary functions (Web services) in much the same 
way as regular Web functional pages (like CGI and similar form-post 
technologies.)  The difference is that the posting and the answer you 
get back are both XML documents.  On the posting end this doesn't mean a 
lot, but on the receiving end it means that instead of a 
display-oriented page which is difficult to get machine-useful 
information out of, you have a format which was developed to be useful 
for software to read (and not so useful for humans, but who cares?)

Effectively you thus have a way to make functions reside anywhere.  This 
much is true of any Remote Procedure Call tech (RPC), such as CORBA or 
others.  SOAP, though, is simple (that's what the S stands for) -- in 
fact, using SOAPpy under Python, you simply write any old functions, 
register them against the SOAP server, and you're done, you have a SOAP 
server.  This worked for me in August and won me much acclaim and 
brownie points with the customer, since I switched strategies midstream 
and still gave them what they wanted.

The downside of the simplicity is that what goes over the wire has a lot 
of cruft in it which isn't strictly necessary -- it's not a binary 
protocol, it's XML with a lot of superfluous attributes and junk for the 
general case which don't help you in specific cases.  But (1) I believe 
you can compress it, and (2) for a TM server, I don't think bandwidth is 
the choke point.  And (3) there's nothing wrong with supporting multiple 
access protocols (a bandwidth-efficient binary one among them) *later*, 
after the stuff already works, more or less.

Shorter version: SOAP is a good choice in my opinion.

Michael

>  
>
>