Re: Ruby best practice for "always on" app/service?

On Thu, Jul 15, 2010 at 6:35 PM, yermej <[e-mail]> wrote:

> On Jul 14, 9:52 pm, Richard Conroy <[e-mail]> wrote:
> > 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?
>
> At this point, I'm basically writing adapters to SOAP services
> provided by outside companies to allow ordering and other inquiries.
> They're accessed via the public internet so there can sometimes be
> delays in responses, but generally under 2s, I think. Eventually I'll
> be using similar SOAP services from several companies. The adapters
> will be used so that internal apps can access those services via a
> single API. A controller will decide which external company to
> interact with in a given case and the adapter will handle the details
> of that particular company's SOAP implementation.
>

This makes things a bit more challenging. While these kinds of architectures
aren't common, you do tend to see these kind of service broker/proxy adapter
patterns in enterprise systems, to solve the patterns you are describing
(putting a common service interface on a set of 3rd party services).


>
> Communication can be initiated from either end. In some cases my end
> will initiate the SOAP communication (to begin an order, validate
> data, etc.), while in other cases the outside company will initiate
> the communication (provide status updates on an existing order). I.e.,
> the adapters will contain SOAP clients and servers.
>
> So, yes to bi-directional communication and delays. I'll have a look
> at Delayed Job.
>
>
DelayedJob won't help here, or not in the way you might think.
Bi-directional
SOAP communications is a totally different beast to HTTP communication,
so web architectures or web middleware isn't a good fit unless you are
adapting the SOAP interfaces.

By adapting I mean that you are converting a series of SOAP interfaces into
a RESTful one.

You really need to put individual technology pieces aside, and
concentrate on what you need to achieve with your architecture. From the
details you have given me, you have actually described a complex
undertaking.

At the heart of it all, you are going to consume and republish every vendors
SOAP API as your own, standardising it on the way and hope that you
introduce
no new issues or lose fidelity in the vendors API along the way.

There's a ton of work in there, risky too, and not much smell of any
benefit.
I have heard of similar strategies where the standardising API work got
pushed
onto the vendors themselves.


> Going with something Rack-based may be all I need at this point.
>
> A somewhat related question, what's the Ruby way to do communication
> between two apps on the same machine. Is there something like IPC
> sockets? Or should I be looking more at something like DRb
> (particularly since the two apps might not always be on the same
> machine). It seems that there should be something besides web apps for
> that, but maybe I'm just making this harder than it needs to be.
>

The web apps communicate with other web apps that coincidentally happen
to be on the same machine. This is the easiest, and best if the server is
inside your firewall and not performance critical.

There are other ways of doing distributed computing. Besides SOAP/RPC
and RESTful methods, there is also the various Message Queueing protocols,
but they might be even less of a fit that than the options discussed already
here.


-- 
http://richardconroy.blogspot.com