From: Richard Conroy <richard.conroy@...>
Date: 2010-07-15T11:52:43+09:00
Subject: Re: Ruby best practice for "always on" app/service?

--0003255598f6a228a5048b64316f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 14, 2010 at 11:10 PM, yermej <yermej@gmail.com> wrote:

> I'm building an app that will essentially be a web service client. It
> will listen for requests from our other internal applications and then
> make calls to the proper service, reformatting the data before
> returning it to the requesting application.
>

So the web service client IS a web app? That proxies/intermediates
between (1) a set of back end web services and (2) people or other
services?


> In the past, I've done this by running a web app via WEBrick or
> mod_ruby. Our internal application hits a URL with the data required
> for the service request, the client class is instantiated by the
> server (be it WEBrick or apache), and the request is handled with
> cookies being saved/loaded as needed for session based authentication.
>

Well everything is Rack enabled now. Install Passenger, deploy your
Rack enabled web service proxy (simple sinatra apps are always good
for these kind of things), and put your feet up.

Rack compatible web container + Rack app is pretty much standard
practice for deploying Ruby web based solutions nowadays. Deploying
non-Rack ruby web apps would be considered an architecture smell now.
Only exceptions in my mind would be JRuby specific deployment options
like Warbler. Glassfish and the JBoss option (sorry cant think of it now),
and
some of those are Rack-enabled too.


>
> Is there a more accepted way to handle this? Something where the web
> service client would be always running and somehow listening for a
> request? I may just stick with what we're currently doing, but I'd
> like to know what my Ruby options are and what others are using in
> similar situations.
>

You haven't gone into enough detail on the nature of the participants in
your services. Its pretty important to understand whether the communication
between your back-end web services and your web service client is
bi-directional
first. Another thing to consider is whether there is significant delay in
the execution
of the web services between your client and your back end services.

Note that if this delay is significant (500ms+), you are likely to need a
background job
scheduler too, of which there are many in Ruby (Delayed Job seems to be
getting
very popular now).

-- 
http://richardconroy.blogspot.com

--0003255598f6a228a5048b64316f--