Saturday, March 13, 2010

My Review on Spring-Roo

So I gave a presentation about Spring Roo recently. Hopefully this means I'll get a kangaroo.  I felt it went pretty well. I decided to share some of my remarks as I think I learned more by presenting than by trying it. As I can not put a presentation on my document (yet), I'll show the text of my slides and will explain some of the things I discussed while presenting.


Describing Roo
  • Rapid Prototype tool for the Java Platform.
  • Non-Invasive approach to development.
  • Proper use of open source frameworks.
  • Handles Infrastructure configuration
  • Intelligent Code Generator (Active vs. Passive Generators)
I basically defined Roo as a tool that can help you learn (if you are new), refresh (if you are Spring savvy), or simply complement your current skills.  Although Spring has made a tremendous job in keeping us away from traditional J2EE development (EJB, xDoclet, Ant, etc), managing Spring configuration is extremely easy with Roo. No need to understand a complete Transaction Strategy in the beginning. No need to understand how to setup i18n configuration, nor how to setup a JPA provider. I also took time to explain about Roo's powerful shell and how it synchronizes with changes you can make with the IDE (managed asset).

Installing Roo
  • JDK 5.0 or greater
  • Maven 2.0.9 or greater
  • Spring Roo Binaries
In this slide (very short) I essentially emphasized how wonderful I managed to work with Roo at home in a machine where I didn't have admin privileges. This opened some eyes as I sensed some of my audience had the same problem. Furthermore, the idea of the shell was very compelling to some folks. Also, I noticed that hitting the "Tab" for hints was a nice feature to have. I could immediately tell most of the folks in attendance would prefer command prompt whenever possible.

Roo Concepts
  • Under the covers, Roo uses AspectJ and Java
  • Changes are done at the byte-code level
  • Strong use of Inter-Type Declarations (ITD)
  • Leverage the power of Privileged Aspects
  • Annotations are defined with Source-Only Retention Policy
I felt that this is where I spent most of my time (aside from the Demo I gave). I explained the concept of ITD as it was fairly new to some of the audience. Also, I had to explained a bit about Privileged Aspects. I had sensed (from the previous presenter) that the audience was not well versed in AspectJ (nor AOP), so I took my time here to help the audience understand that a "cross-cutting" concern does not necessarily apply to business logic. It was a good discussion. After answering some of the questions I had, I turned to build an application which some of us have been talking about building, of course this time it was a lot faster. 

Value Proposition
  • No vendor Lock-In
  • Zero performance/memory overhead
  • Zero deployment footprint
  • Consistent applications across teams
  • Leverages investment in the Java Ecosystem
  • Small learning curve, great to learn proper usage of Spring.
I felt I needed to present why is the "Roo" proposition a good one. As a convert to Roo, I liked the lack of vendor lock-in. I also appreciate the great "use-case" for AspectJ in the context of this tool. It makes complete sense. I also stressed the point of how to help "entry" level Engineers to learn powerful concepts which could take days to read on their own.

Further Topics
  • Dynamic Finders
  • Integration with JMS and Email
  • Integration with Webflow
  • Integration with Spring Security
  • Custom Add-on's
  • Roo Architecture Patterns
As my presentation took longer than anticipated, I didn't have the chance to discuss these, however I had purposely left it in case I would have finished early. I suggested a future discussion of this topics, particularly about "Dynamic Finders" and some of the architectural choices which Roo encourages (e.g. No DAOs, Optional Service Layers, etc).

I sensed good feedback, and once again I learned the obvious: One learns more by sharing than by reading.


2 comments:

twicet said...

Much as I develop exclusively in Spring/grails I can't seem to understand your "No vendor lock-in" statements. I haven't yet developed in ROO but from what I've gathered, it's a Spring Based tool/framework and this means SpringSource (despite the apache license).So under what context does the "No Vendor Lock-in" apply?

Alberto A. Flores said...

Good point. Perhaps I should have expanded a bit more on this.

Fundamentally, my understanding of "No vendor lock-in" means any type of "lock-in" to a specified Vendor tooling or framework (in this case, to Roo). In other words, if you choose not to use Roo after you started, it's possible you continue work as there is nothing more than a maven structure with proper use of Spring/AspectJ under the hood. Now, granted there are Annotations specific to Roo, but these are defined as RetentionPolicy.RUNTIME annotations and the Roo dependencies as "provided", so there's no overhead. Furthermore, these can be removed completely after some refactoring. I'd refer you to the section in the Spring Roo documentation for further discussion of removing Roo from your project.

What I find interesting about this feature is that I can develop a quick prototype for an application using Roo, meet my deadline way early, and my manager(s) will not necessarily be upset that I introduced new technologies as I haven't imposed anything new to my deliverables. Furthermore, other developers can continue work without using Roo (hence the no vendor "lock-in" statement).