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
on 2006-03-01 20:48
on 2006-03-01 22:50
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.
on 2006-03-02 11:04
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" <firstname.lastname@example.org> wrote in message news:email@example.com...