From: Sean Russell <ser@...>
Date: 2001-12-19T23:46:17+09:00
Subject: [ruby-talk:28904] Re: Best way to do XML-RPC

Michael Sullivan wrote:

> I was wondering what the various opinions of doing XML-RPC are.  I may
> have non-Ruby applications connecting to my XML-RPC server such as Perl,
> or Java.  So a couple of questions/thoughts:
> 
> Should I use a "stand-alone" server or CGI server?

I generally have used a stand-alone server; the XML-RPC package for Ruby is 
fairly small and easy to use.  Using a separate server also aids in 
debugging, and allows you to distribute the application without a 
dependancy on a web server.

> CGI or mod_ruby?
....
> What are the benefits and drawbacks of them?

mod_ruby.  It is more light-weight.  The idea is that mod_ruby only loads a 
fixed number of Ruby interpreters, and it preloads them.  CGI launches a 
new interpreter every time.

I'm not sure that you'd use CGI with XML-RPC.  AFAIK, XML-RPC uses CGI 
syntax to formulate messages to the server, but the problem domains are 
different.

As I understand it, CGI is a syntax by which clients send messages to the 
server.  How the server responds is mostly undefined, and the server-side 
process is also freely defined; there isn't a specific servlet API.  
mod_ruby (and other technologies, like Jakarta) have the interpreter 
already loaded, so that the server-side processes run more quickly.  Things 
like Jakarta also specify an API that the servlets have to follow.  This in 
turn makes writing servlets a little easier, since many of the server 
processes, such as cookie management, are handled by the servlet engine.  
I'm not sure how mod_ruby works, but I'd guess it is similar.  The 
information returned by the server, like CGI scripts, is basically 
undefined.

XML-RPC (and SOAP) is another beast altogether.  XML-RPC defines how 
methods are called, and how to format the arguments.  It also defines how 
servers return information.  These definitions make it easier to write 
applications.  Also, XML-RPC pretty much requires both a client app and a 
server app, whereas CGI/mod_XXX are oriented towards Web Browsers as the 
client.

I've always thought that CGI was best for single question/response 
interactions, like searches and other form-submission apps.  mod_XXX are 
better because of performance issues, but those engines also tend to have 
support that make more complex communications easier, such as webmail and 
such.  These are all situations where you're using web forms to submit the 
HTTP requests.  XML-RPC is for providing communication between two 
applications, and although you could generate requests with a web form, I'm 
not sure why you'd want to.

> Should I use SOAP4R?

Personally, I don't like SOAP.  I believe the standard is overly complex.  
On the other hand, with M$ behind it, SOAP is being pushed as the standard. 
However, I recommend you go look at the SOAP spec and the XML-RPC spec and 
make up your own mind.

-- 
--- SER