Jun 10 2007
Stuff your Java model into your Rails project
The upcoming, and now recent, release of JRuby 1.0, along with some conversations with various friends has left me thinking a lot recently about how to integrate a Java project with a Ruby (on Rails) project. If you have an existing domain model written in Java then the reasons you might want to do this become obvious. Rails is designed using the MVC architecture, and if you can get it talking to your java domain model, then the M is already written for, you just have to write the views and controllers. Views especially can be painful in Java.
The standard answer for integartion between languages is currently web services: Write a simple XML wrapper round the Java domain objects allowing methods to be called on them, then use that API from within your Rails models. It doesn’t really matter if you use SOAP, REST or your own “standard” (although REST lends itself nicely to having a toXML() and a setXML() method on your java classes and using ActiveResource to GET and SET instances).
However, XML has never been a major contender for speed, and the chances are that your API isn’t designed to minimize the number of calls you make. So you have to pay that overhead more often than you need to. Of course you could add a remote facade, but now things are maybe starting to get more complex than you need…
JRuby provides a much more integrated way of solving the problem. It works like this: JRuby lets you import Java classes into your Rails code. Your controllers do not need to know (or care) that they are not Rails models. They can just find a new User instance, set the password on it, and move on to the next one.
Of course, I’m not suggesting that it’s that simple. Rails expects the models to be ActiveRecord instances. You are likely to suffer from code expecting to find an ActiveRecord method, like User.find and it not being there. I imagine the solution to this would be a library that loads all of your Java classes, and then changes them (as Ruby can do that) to add methods normaly provided by ActiveRecord. You can add the validation methods, then you can add the persistence methods like save, and find. How you do this is going to be dependent on how your Java persistence is done (ok, I’m assuming your Java code has a persistence model - I probably should have mentioned that earlier). If you have used the DAO pattern, the find method could instance a DAO object, load an instance though it, and return that. If you don’t use DAOs, then you map the methods to whatever you do use.
Finally you need to wrap all your code up into a library that runs when rails starts, automatically loads all your java classes, and decorates them. Hey presto, your old legacy Java domain model has a new lease of life as a trendy Rails application. If anyone has the time to write this library, let me know - I would love to have a play with it.
Unlike the rest of the Rails system, this integration won’t be solved by convention over configuration. Potentially it could be, but I think there are just too many different designs; different persistence models and different ways of locating your domain model out there…
This is a very interesting post. You imply that this would be used to add a ruby driven front end to a pre-existing project. I find myself wondering, however, what design drivers would make you want to implement your domain model in java and the remainder in Ruby from the outset?
You’re right that I was thinking about legacy projects when I wrote this, however even in new projects there are a number of reasons you might want to work in Java.
JRuby promises some big performance improvements, but Java is still faster. If your domain model does some heavy work, then you going be better off in Java. I don’t think any Ruby code will ever be quite as fast as Java, though it will get closer and closer With the speed of processors moving up, we are likely to care less and less as network, memory and IO bounds become more of an issue.
Java code is (in my opinion anyway) inherently more maintainable. Many of the techniques that I use to maintain my code are hard in Ruby. I spend a lot of time doing fairly extensive refactorings, for example using rename method, inline method and others. Java’s static nature makes it easy to write tools to do this for you, while Ruby’s dynamic nature makes this very hard. Without these tricks I find it much harder to maintain a codebase in a logical structure. As an aside, the root of this being hard in Ruby is also the reason why its hard to write a ruby IDE.
Ruby has a pretty pore threading model. If your in need of doing some threading in your application, then Java is a much nicer place to be. Though this is less of a clear reason than it should be, as its often at the controller or web server layer that you will do, if not most, then at least a significant part of your threading.
I also want to point out that its currently a lot easier to find Java programmers than it is to find Ruby programmers. So given that most of your logic is going to be in your domain model, it makes sense to write it in a language which allows you to easily get extra developers . You are also quite likely to find that your existing developers are more comfortable in Java than Ruby. While thats not a good computational reason to choose a language, its a very good business reason.