Which is the best database strategy for a JRuby on Rails + legacy Java code?

We have a medium size Java application that needs some refactoring.

We are considering migrating towards JRuby on Rails. Mainly because of the productivity that Ruby on Rails offers and for the many existing plugins that will reimplement the web logic.

However a large part of the application should stay in 开发者_运维百科Java, we do not want to rewrite all the business logic (specially since it uses many Java technologies such as RMI).

A key point for our refactoring is sanitizing our database management, which is currently a mix of hand coded SQL operations and some objects stored in db4o.

From JRuby we can call any legacy java code. Great!

However many Ruby on Rails plugins asume the use of ActiveRecord to manage the database. Accessing the ActiveRecord data from Java seems non trivial.

Which is best strategy to manage the database between JRuby on Rails and the legacy Java code?

• We could use db4o for everything, but would loose the benefit of some Ruby on Rails plugins, and would need to manage objects "manually" on the Ruby side
• We could use ActiveRecord for everything and define some kind redundant mapping on the Java side. Which would be the best strategy?
• We would use a Java ORM technology (Hibernate, Cayenne?) and then map the model in ActiveRecord. How does this idea compare to the previous one?
• Can we do some magic using Jruby 1.4 become_java!?

What do you think?

JRuby is a great language but it is really Ruby running on the Java Virtual Machine. It is possible to integrate legacy Java code in but it doesn't fit well into the core language.

If you are interested in a new dynamic language with a solid web framework, I would suggest looking at Groovy and http://grails.org/. Groovy is build on the JVM. You legacy classes can be first class citizen in the application. I think this would be much easier to migrate to something new because you can reuse what you have, rewriting the parts you need.

It sounds like you're planning to do a quite a bit of refactoring on the Java side in addition to writing new code in Ruby. That being the case, I'd recommend:

1) decide on a Java ORM: Hibernate or db4o, and use it going forward in all your Java refactorings. As much as I'd like to say, use ActiveRecord for everything, the bottom line here is that it'll be much easier to convince JRuby to work with a Java ORM than it would be to coerce your Java code into working with ActiveRecord objects.

2) There are at least prototype-examples of Ruby interfaces for both Hibernate and db4o. Find one to get you started, and then add on to it as needed to provide the ORM capabilties you need.

3) Don't worry about Rails plugins that expect ActiveRecord. Not all do, and even fewer will in the future as Rails 3 (the merger of Rails and Merb) uncouples ActiveRecord. And even if there's a plugin that you absolutely have to have that does require ActiveRecord, so what? It's just Ruby code. Download it, see what it expects, and throw together a facade class for your ORM to provide the methods that the plugin wants. (Here we see the beauty of Ruby--an object doesn't have to <> a duck as long as it saunters and quacks like one). Alternately, you can monkey patch the plugin to remove the ActiveRecord dependency, or simply implement the functionality that the plugin provides yourself. Your situation will likely dictate which of those approaches makes sense.

It's a tough question to answer without knowing a lot of the detail.

Firstly, it's completely possible to build Rails apps without using ActiveRecord (AR). I have done several - usually I use the controller to run scripts, read/write files, etc and I believe this approach is valid. However, as you definitely have data in a database to deal with, be mindful of keeping the MVC approach, whether or not your M is AR or otherwise.

If your DB is well designed, you could have a hybrid approch. For example, maybe your legacy Java generates reporting data using whatever ORM and writes it to the DB, tables from which could then easily be wrapped in ActiveRecord models for displating the report via your Rails app. It all depends on what functions your Java code does versus what functions your Rails code does (and again, if your DB design lends itself to AR modeling).

If your rails app and the java code need to pass model instances to eachother directly (i.e. as opposed to going via the database), then the hybrid approach may not work.

I suggest a "try it and see" approach. Try a few things out and see how quickly you run into trouble. In cases like this, I feel that trying to architect it all in your mind first is not that productive.

FYI: the O'Reilly book "Enterprise Rails" has some good advice about making your own Rails plugins so you can find / maintain / reuse whatever tricks you come up with. Wild guess: make on O/R plugin that you can optionally use to sit on top of the legacy java code?

Alternately, create some magic in the database to allow old java to magically read results from "new and improved!" ruby processing?!? I'm assuming a DB with views, triggers and access to use such.

Good luck, I don't really have a good answer, but I am very interested in how this works out for you.