Re: Protocols

On Mon, Mar 10, 2003 at 10:02:29AM +0900, Ray Capozzi wrote:
> Is there a preferred set of ruby libraries for client/server solutions?  As
> an example, RPC.  The protocol needs to exist for Ruby and Perl, so druby
> wont work.  XML-RPC seems to be the leading candidate, despite my objectives
> to XML.

XML-RPC is nice and simple to understand, but it has limitations in its
marshalling of objects (e.g. no aliasing: if a data structure contains two
references to the same object, you will get two copies of the object at the
receiving side). YAML/OKAY and SOAP both don't suffer from this problem, and
have very rich marshalling semantics. If standards-compliance is your main
driver, then SOAP is probably the way to go.

Using either of these approaches will give you beautiful RPC code, in fact
with a little wrapping you can write it can run on either the local or the
remote side wth no changes: e.g.

  #server = MyServ::connect('dbi:oracle:','foo','bar')  #for local use
  server = MyServ::connect('druby:192.168.0.1')         #for remote use
  data = server.fetch(key)
  ... etc

Just parse the connect string and create an object of the appropriate class.
I have been working on this sort of stuff quite heavily over the last few
days.

But the big caveat: both SOAP and YAML are sloooow. If you're just sending a
couple of strings back and forth they will be fine, but in my case sending a
small collection of objects (about 7K of XML) gave around a 1-second
round-trip time for a single procedure call! The vast majority of this time
is spent just marshalling and unmarshalling objects.

Since I have control of both the back-end and front-end systems, I have
decided to go with DRb for now. It's blindingly fast (I'm getting around 25
RPCs per second, each of which does a DBI query too). This may be just the
excuse you need to rewrite those nasty Perl front-end programs in Ruby :-)

I didn't compare the speed of XML-RPC because its lack of aliasing means
it's not useful to me, but it may be worth trying. Long term I'd expect it
to die out in favour of SOAP though.

Something to beware of with Ruby implementations of both DRb and SOAP server
(and possibly others) is their interaction with threading. In both cases,
you pass a single object to the server, and it listens for requests: but
each time it answers a request, it start a *new thread* for the method call
but on the *same object* whilst continuing to accept new inbound requests.

For any non-trivial object that means you're going to have to mutex it all
over the place, or write a thread-safe facade object which maintains
(perhaps) a pool of server objects and hands out the calls appropriately.

I cheated - I modified DRb itself.

Regards,

Brian.