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.