I think this depends somewhat on the scope of the connectivity. In most 
cases you will not be able to dictate or alter the interfaces that you 
want to connect to and therefore will need a solution(s) that can handle 
several protocols.

I also agree that you should look at JRuby and Glassfish along with 
Netbeans and OpenSOA as possible solutions. I have used this combination 
with success.

Rails still has some problems running on JRuby but they are close enough 
IMO - so you could develop the front end in Rails (or alternatively in 
Grails) and create composite apps with OpenSOA (which allows 
connectivity to anything Java) to expose the external systems, then call 
these Glassfish hosted composite apps (via service endpoints) using REST 
or SOAP from your Rails app. Netbeans provides a consistent IDE across 
all these technologies.

In addition the next release of OpenSOA (Fuji) will have a DSL language 
patterned after Ruby for creating the BPEL and composite apps.



Scott Olmsted wrote:
>
> A software architect friend wrote me with a question I can't answer 
> because I don't do Java. I though I would see if any one has any 
> comments on his idea, or links to resources.
>
> Thanks,
>
> Scott
>
> He wrote:
>
> I'm thinking for the start-up that I will be working with of using an 
> architecture with Rails as the web site, but the back end consisting 
> of a cluster of various long-running services and integrations with 
> other financial institutions, to use java.  It seems that all of the 
> enterprise middleware is java-based, so if you want to do something in 
> that area, you kinda have to use java or at least something that 
> compiles down to java byte code.
>  
> The motivation would be to try to take advantage of the productivity 
> gains of RAILS at least for those portions of the site.
>  
> The Ruby front end would function as a client of the business servers 
> using REST or some other API; or it could use the java JMS API to 
> access the queuing middleware, if we use jRuby.
>  
> Do you have any thoughts on this architecture?  Warnings? 
> >


--~--~---------~--~----~------------~-------~--~----~
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
-~----------~----~----~----~------~----~------~--~---

Reply via email to