I think XML-RPC has the most languages supporting it right now,
and Michael Neumann has written an excellent XML-RPC for Ruby
(see http://www.fantasy-coders.de/ruby/xmlrpc4r/).  It contains
its own HTTP service, but its not a generalized HTTP server.  A
generalized HTTP service has been (recently) released named
WEBrick (see http://www.notwork.org/ipr/webrick/).  WEBrick has a
nice Servlet model with an HTTP 1.1 compliant web server.  I wrote
a Servlet to bind the xmlrpc4r stuff into WEBrick (which is listed
below).  SOAP4R is another approach and they have integrated with
WEBrick as well through writing a Servlet:
(see http://www.jin.gr.jp/~nahi/RWiki/?cmd=view;name=SOAPlet)

---------------------
xmlrpc4r WEBrick servlet:

<code file="xmlrpc/contrib/rpcservlet.rb">

require "xmlrpc/server"
require "webrick/httpstatus"

module XMLRPC

  class Servlet < BasicServer

    def initialize
      super
    end

    def require_path_info?
      false
    end

    def get_instance(config, *options)
      self
    end

    def service(req, res)
      method_name = req.request_method.gsub(/-/, "_")

      unless method_name=='POST'
        raise HTTPStatus::MethodNotAllowed, "unsupported method
`#{method_name}'."
      end
      unless req['Content-type'] == "text/xml"
        raise HTTPStatus::BadRequest
      end
      unless req.body.length > 0
        raise HTTPStatus::LengthRequired
      end

      result = process(req.body)
      raise HTTPStatus::InternalServerError if result.nil? or result.size
<=0

      res.header['Content-type'] = "text/xml"
      res.body = result
    end

  end

end

</code>

---------------------
This is a sample server using it:

<code file="testserver.rb">

require "xmlrpc/contrib/rpcservlet"
require "webrick"

rpcservlet = XMLRPC::Servlet.new
rpcservlet.add_handler("test.echo") { |stuff| return "You said '#{stuff}'" }
rpcservlet.add_handler("test.mul") { |x,y| return "Answer #{x*y}" }

httpd = WEBrick::HTTPServer.new(:Port => 80)
httpd.mount "RPC2", rpcservlet
httpd.start

</code>

---------------------
And now you have an XMLRPC method that you can invoke like this:

<code file="testclient.rb">

require "xmlrpc/client"

server = XMLRPC::Client.new("localhost", "/RPC2", 80)
ok, reply = server.call2("test.echo", "cool")
puts reply if ok # => You said 'cool'
ok, reply = server.call2("test.mul", 5, 6)
puts reply if ok # => Answer 30

</code>

---------------------

-Rich Kilmer

> -----Original Message-----
> From: Michael Sullivan [mailto:mps / blackbird.discomsys.com]
> Sent: Monday, December 17, 2001 3:19 PM
> To: ruby-talk ML
> Subject: [ruby-talk:28818] Best way to do XML-RPC
>
>
> Hi,
>
> I'm trying to promote the use of Ruby on a project I'm working on.
> Since I'm relatively new with the language, I'd like to hear what
> others' thoughts are.  From what I've seen and done, I like the language
> much better than Perl - can do more easier especially when dealing with
> code in an Object Oriented way, too many OOP hoops to jump through to
> force Perl to perform OO.
>
> 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?
>
> Why?
>
> CGI or mod_ruby?
>
> What are the benefits and drawbacks of them?
>
> Should I use SOAP4R?
>
> On a related note, is there any way to have a persistent database
> connection using mod_ruby?  Has anyone done this, or thought about how?
> Global variables?  Shared memory?
>
> Might a persistent database conenction be one reason why I might want to
> use a stand-alone XML-RPC server?  The thought of using threads  for
> multiple incoming connections RPC bothers me a bit, though - I know one
> can do this single threaded, but I'm wondering about load and
> scalability.
>
> Thanks,
>
> Mike
>
> --
> Michael P. Sullivan
> Distributed Computing Systems, LLC                         Cell:
> 516-429-2080
> E-Mail: mps / discomsys.com
http://www.discomsys.com/
    * UNIX Systems and Database Consulting, Architecture and Management *
"Failing to plan, is planning to fail... plan for the worst, hope for the
best"