Rails - Mar 2006 - Rails and Service Oriented Architecture (SOA)

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


-- 
Posted via http://www.ruby-forum.com/.

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 02/03/06, rails nut <rails_nut@hotpop.com>
wrote:
> 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
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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" <rails_nut@hotpop.com> wrote in 
message
news:743fa90f2583c2bb94aad0425c1e6c65@ruby-forum.com...
> 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
>
>
> -- 
> Posted via http://www.ruby-forum.com/.