Small correction - it is OpenESB not OpenSOA. Sounds like a great project.
Carl Graff wrote: > 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 -~----------~----~----~----~------~----~------~--~---
