Sunday, June 22, 2008
I'm investigating re-architecting parts of an existing client's application. I prefer not to re-architect existing applications of non-trivial size but the current application has outgrown its current lack of architecture. Because of it's size (not to mention the development environment being used!), development work on the application runs at a snails pace, fear of breaking code is high, and deployment is a long, painful process. The state of the project is at least partly my responsibility, as I have worked with this project in the past. My previous attempts to get client buy-in on improving the architecture failed. I am planning to use other methods and tactics to try and illustrate to the client just what they are getting out of this. But I digress... I have become a big a fan of REST over the last few years with success on various projects built using REST. I looked at the Restlet project about a 6-9 months ago, but the documentation was inadequate for me at that stage. This isn't surprising because Restlet was quite early in the development at that time, so I'm not having a go at the Restlet team here in any way, they've been doing some really good work with their REST implementation. But on having the need for REST in Java again, I've taken another look at Restlet. The documentation has improved a lot. The examples, tutorials and explanations of the Restlet implementation are now at a stage where you can quickly evaluate Restlet, and decide if it can work for you. I would of course rather do all of this in Ruby or Python, but with the existing application in Java/J2EE the Restlet implementation of REST will mean the current team can still use Java, and means I have one less hurdle to try and negotiate. As I have experienced on other large applications, when you move components out into discreet services you end up with a nice SOA application that naturally enforces separation of layers. I am expecting to see large improvements in development speed, quality of code, and deployment. I'll blog about how the proof of concept goes in a later post.