Code, aimless meanderings and occasional outbursts from an Australian expatriate living in Singapore.
Sunday, June 22, 2008
Re-Architecting J2EE with REST
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.
Subscribe to:
Post Comments (Atom)
3 comments:
Yeah, i can understand your pain. EJB + Workshop =D
Man, over here(wego.com) we do lovely stuff on java, ruby, erlang. Led by our rails hacker(http://blog.codefront.net/) and erlang god(http://arunthampi.wordpress.com/)
We also got Aussie bosses to bundle in.(http://www.wego.com/team/)
Our Java Architect has recently left to join a bank. Well if you're ever fed up at..and prefer flip-flops 5 days a week + Rockband + Playstation 3 + Boat Quay(http://www.wego.com/contacts/)...i'm sure my bosses are interested.. I know you are the man. =D
Hey Kenny
I love Rails :)
We've got some new projects starting up and I just couldn't stand the pain and slow development speed to do them in Java/J2EE. There are some projects that really do need Java/J2EE, but most projects don't.
I think the team will be pleasantly surprised at how sweet working with Rails is once they've dipped their toes in the water.
Aside from the development speed, the other reason I'm choosing Rails is it totally encourages TDD, which is something I'm trying hard to promote here.
Thanks for the tip, but I'm totally stoked to be with GITC. We've got some cool projects in the works and the team is truly great to work with :)
Cool. So planning to hire rails devs? Pretty hard to find in Singapore though.
Yeah, i'm sure GITC will be rocking with you back at the helm. Probably you have also been thinking abt introducing some SCRUM/XP fun too? It originated from Aussie anw. hah
Anyway Happy Singapore day toml.
Post a Comment