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.
Andy
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.
Ruby is an excellent language for quickly writing web services (see p713
of
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
agnostic,
the fastest way to start building a SOA I believe is to use Ruby (for
small
distributed servers/services) and Rails (for small web applications),
which
is the approach our organization is currently taking.
Steven Beales
Chief Software Engineer
Medical Decision Logic
724 Dulaney Valley Road
Towson
Maryland
21204
410-828-8948
“rails nut” [email protected] wrote in
message news:[email protected]…