Forum: Ruby on Rails Rails and Service Oriented Architecture (SOA)

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Rails N. (Guest)
on 2006-03-01 20:48
I've been asked to look into Service Oriented Architecture (SOA) before
we embark on a major re-development (in Ruby on Rails).

Can anyone point me to any resources about SOA in combination with Rails

Concrete examples of how SOA was applied to a particular problem would
be very welcome.

My investigations so far lead me to believe that SOA is really about
gluing together applications from separate organisations (using web
services) or, if not separate organsiations, large divisions within an
enterprise.  I think it's probably less appropriate to the task to hand
which could arguably be described as  a single monolithic application.

I do think that our organisation needs to break down the application
into modules with loose coupling, but I'm yet to be convinced that those
modules should be implemented as separate 'services' linked together
with SOAP (or similar), which seems to be the route we'd be taking if we
went for SOA.

Any thoughts welcome.

David M. (Guest)
on 2006-03-01 22:50
(Received via mailing list)
If you're really building a large monolithic app, then SOA really
doesn't apply - your apply doesn't supply any services to other apps,
and your app doesn't consume services from other apps.

If that's not the case, and e.g. you want to expose interfaces to your
app's data, you can use ActiveWebServices in your Rails code to do so.
 If there's no immediate need to do this, you could retrofit your
Rails app later to support this - it would effectively sit "off to one
side" from your monolithic-style functionality.

Similarly, you could use SOAP or XML-RPC calls from within your app if
it needs to consume a Web service offered by another app.  That's
reasonably straightforward with Ruby.

>From the context of your request, I get the impression that SOA is
something of an acronym-of-the-month in your org.  That's cool - seems
to be a widespread sentiment at present, particularly where there's a
"management by magazine article" focus.  After reading loads of
information on the topic (I'm a consultant, so I need to be across
this stuff), my understanding is that SOA is really about:
- exposing interfaces to apps using a widely-available protocol
(typically SOAP or XML-RPC)
- managing those apps to a service metric (i.e. availability or
responsiveness) in line with defined business requirements

Neither of these are exactly breakthrough ideas, although stuff like
Xen offers new capabilities in allowing you to manage an app to a
service metric via virtualization and failover.  On the first point,
Web services have been around for several years; Rails supports them
very well via ActiveWebServices.

If you can cover off both these deliverables in your architecture, I
would think it'd satisfy any management-level request for "SOA
compatibility".  From your description, I wouldn't think there's a lot
of reason to use SOAP as the means of communicating between tiers of
your app; SOA is about exposing interfaces *where they're useful*,
rather than dictating how the internal functionality of an app should
work.  Maybe you could take the tack that "we *can* build in SOA-style
interfaces where necessary, and Rails supports these" as a way of
getting Rails approved for this project, then only actually create
these interfaces as you see appropriate.

Hope that helps.

Dave M.
Steven Beales (Guest)
on 2006-03-02 11:04
(Received via mailing list)
Ruby is an excellent language for quickly writing web services (see p713
Programming Ruby for SOAP library).  Rails is an excellent framework for
quickly writing web applications that can be wrapped in web services.
Although Service Oriented Architectures are officially language
the fastest way to start building a SOA I believe is to use Ruby (for
distributed servers/services) and Rails (for small web applications),
is the approach our organization is currently taking.

Steven Beales
Chief Software Engineer
Medical Decision Logic
724 Dulaney Valley Road

"rails nut" <removed_email_address@domain.invalid> wrote in
message news:removed_email_address@domain.invalid...
This topic is locked and can not be replied to.