Friday, 16 December 2011

Enterprise Application Development using Spring Roo 1.2

Spring Roo is an open source Rapid Application Development tool for Java developers. Spring based applications performing CRUD (Create, Read, Update, Delete) on Entities can be easily auto generated using Roo. It is not an IDE or a runtime. It is just a programming methodology combined with a code generation tool. This post describes the features of Spring Roo briefly and analyses its applicability in building enterprise applications where simple CRUD functionality and auto generated screens may not be sufficient.

Spring Roo Features
It is very easy to kick start a Spring Roo project. You just need to give few commands and the project will be ready for you. Then you can provide information about your entities, their fields and constraints. Spring Roo can generate end to end code for all CRUD operations. The generated components include JSP pages, MVC Controller classes, Entities with their persistence logic and database tables. Roo can also create custom finders with filter fields of your choice. From version 1.2 onwards, you can also generate service layer and repository layer if you wish. 

Other key aspects are as follows:
  • Roo has excellent round trip handling. Most of the auto generated code is at your disposal to edit. Roo accommodates your changes even when it recreates the code. This ensures that most of the NFRs required for an Enterprise application are available off the shelf. 
  • Roo generates application on top of robust Spring framework. 
  • It has integration with many of the industry standard frameworks like Hibernate, Spring MVC, log4j, Google Web Toolkit, Solr search engine, EclipseLink, OpenJPA etc
  • Application runtime is independent of Roo. Role of Roo ends in development cycle.
  • Supports Database Reverse Engineering. 
You may read more about Roo features in my older post

What else you need for an Enterprise Application? 
If an application is being developed for internal use of an enterprise, you may be able to use auto generated application as such with some tweaks. But, if the scope of the application is beyond that, you will have additional requirements.
  • There will be complex business logics to be performed. 
  • Even for simple CRUD functionality, you may need custom screens to improve aesthetics and usability. 
  • You may have strict NFR requirements in terms of performance, security, transaction management, logging, audit, internationalization, maintainability etc. Your application will require a robust architecture to support all these. 
So the key requirements here are customizability to the customer needs and adherence to NFRs. We will see each of these in detail.

Architecture Analysis
Following diagram describes the architecture of a typical Roo based application, when service and repository are enabled. 
High Level Architecture of a Spring Roo based application (Click to enlarge)
You may notice that the architecture is robust with appropriate layers and proven technology components. 
Note: In most of the cases business services and repository will not be doing anything other than delegating the call to underlying layer. But presence of these layers can provide great peace of mind to 
a) an architect, because of the flexibility it provides for any future requirements.
b) a manager, because the architecture resembles any other proven enterprise architecture he would have already seen.

For any auto generated application, the extent of customizability will be a major concern. Let’s now look into the customizability of Spring Roo based applications.
Depending on the requirements, Spring Roo applications can be customized to different extents, and there are side effects for some of the customizations, especially when we try to modify the data model after customization. For example, when you add a field after doing the customization, some times, you may need to tweak the code a bit.

UI Customization
Look and Feel: User interface is the area where maximum customization is required, because the end user directly interacts with it. You may change the overall look of the application by modifying its stylesheets, images and template files. You can also modify the property files to change labels, titles and messages. All these changes are completely non-invasive and Roo will keep these changes intact even when it updates these files. 
UI Components: All the html fields are represented as tagx components in Spring Roo. If there is a requirement to change the behavior of a field, it can be done at the component level, so that all the pages will be changed automatically.
Additional Client Side Logic: It is possible to add custom Javascripts to perform client side logic like doing a specific validation. 
Page Layout: Roo generated pages will have a normal two column layout. But we can modify the layout by including table or div tags around the fields without touching the field definition. This gives us complete flexibility in page layout.
When new fields are added to the screen, Roo will update the file we have modified. But it will keep our layout tags intact. Once it is re-generated, we may need to properly place the newly generated fields in our layout infrastructure, because Roo doesn’t understand our layout logic. Similarly, when a field is removed, we may need to readjust the layout of other fields.

Business Customization
In some cases we may need to add additional business logic, other than simple validation and persistence.  With the help of newly added service layer, this is very easy to achieve. By default, the service implementation class will be empty and the actual implementation will be in ITD file (Click here, if you are not familiar with ITD). You can define the same method in the implementation class with additional logic, and Roo will automatically remove the default method from the ITD file.  

Introducing New Functionality
There could be certain functionality which are complex and will not match to any CRUD operations. Eg. A flight availability search. You may need to create the entire layers for such functionality without the help of Roo and update the menu generated by Roo to give link to the new functionality. Depending on the modularity requirement, new functionality can be implemented as new classes or as additional methods in existing controller and service classes. In some cases, it will be possible to reuse the auto generated persistence logic itself and we just need to create the screen and business logic. If we need to update persistence logic as well, we may modify the entity (if we are using active record pattern) or add a new dao class. It is absolutely ok to mix Roo and “non Roo” functionality in a single application. However it is recommended to use a technical architecture which matches with Spring Roo architecture, ie and architecture based on Spring and Spring MVC. 

NFR Support
Adherence to Non Functional Requirements is important for any enterprise application. Let us investigate how the well the NFRs can be addressed in a Roo based application.

Security can be easily incorporated to Roo based application using Spring security. Intercept-url tag in spring security can be used to enforce authorization at presentation layer. As the URL for all CRUD operations of an entity are same, you may need to use http method also to enforce fine grained access control. But if service layer is used, authorization can be easily enforced at service layer by adding MethodSecurityInterceptor using AOP. 

Roo does all the work during compilation. Once the Roo based application is compiled and deployed, it is just like any other web application. So there will not be a performance impact due to auto generation. 
The architecture uses Spring MVC at presentation layer and Spring at business layer and they are well known light weight components. 
The only area where we can have some performance concern is the persistence layer. As the entire persistence layer is ORM/JPA based, there could be performance issues in bulk retrievals, especially when dealing with entities with children. You may mitigate this issue, by updating service class to invoke a separate DAO which invoke JDBC calls for performance critical reads. 

If we opt to have a service layer, transaction is enforced at service layer. Otherwise, transactions are enforced at the domain layer. As normal CRUD functionality generated by Spring Roo deals only with one entity and its children, transaction enforcement at domain layer is sufficient. When we add a functionality which deals with multiple entities, we need to have a service layer which interacts with these entities and the transaction can be enforced at service layer.

Spring Roo has off the shelf support for Log4J and it could be used for any logging requirement. Interceptors can be put into service and persistence layer to introduce generic entry/exit logging.

The recommended approach is to use Entity listeners to perform audit. Alternatively custom implementation can be provided using interceptors. 

All the labels and messages in the application are externalized to property files. So the application can be easily localized for any language. 

Roo based application has excellent maintainability due to the ITD approach. In all the Java classes from presentation controller to entity, auto generated code is separated into ITD files. So, by default, Java files will not have much code. We will be adding our custom logic in these Java files and even after that they will be lean, as normal setters, getters, persistence logic, delegation etc. will not be present in them. It is easy to maintain these classes as they contain just enough code that a developer has to see. Any other code which does not need a human brain to maintain are separated and thus maintainability of a Roo based application will be better than a normal Java application. 

Scalability & Availability
As already stated, Roo does not have any role at run time. A Roo based application will be just like any other application based on Spring and Spring MVC. As we all know, Spring and Spring MVC are most light weight and stateless frameworks and they can be scaled to any level. By providing a proper deployment architecture, any level of availability can be guaranteed for a Roo based application.

Recommended Approach
For an enterprise application "generate and forget it" approach will not be sufficient. The approach should be "generate -> tweak -> enhance -> deploy"
Steps could be as follows.
  1. Decide on the functionalities for which Roo will be used.
  2. Finalize the domain model as far as possible.
  3. Auto-generate the functionality using Roo, enabling service and repository layers.
  4. Make customizations in styles, images, labels, top level layout etc.
  5. Modify the UI components wherever required. 
  6. Modify the .jspx file to change the layout of the pages, if required.
  7. Add additional Javascripts if required.
  8. Customize Service and repository classes by overriding the auto generated methods.
  9. Add new manual webpages, controller methods and entity methods for custom functionality  wherever required.
Spring Roo is a robust and reliable mechanism to perform Rapid Application Development. Roo acts during compile time and this ensures that auto-generated application will be highly customizable. As the application is Spring based, it can leverage all the strengths of Spring framework. 
Spring Roo can surely improve the productivity in development of normal CRUD functionality, without compromising the flexibility and NFRs. Complex functionality in the enterprise application can still be developed without using Roo. Roo based functionality and other functionality can coexist well in an enterprise application.
Features provided by Roo 1.2 made it more favorable for enterprise application development. 

Saturday, 3 December 2011

Are we ready for HTML 5?

As we all know HTML 5 is the web specification which focuses on rich internet application development. It will surely change the way we look at web now. The "thin client" will not be thin any more. This post tries to analyse whether it is the right time for us to start development in HTML 5.

The post is very much similar to my previous post, although the title is entirely different. Last time I talked about dropping IE 6 support. This is about embracing HTML 5. But the concerns in both topics are identical.

To know whether we can use HTML 5, we need to see which all browsers supports this. Sites like will give you a clear idea about HTML5 support in various browsers. Here we can see that latest released versions of all browsers (except IE) supports most of the features of HTML 5 even though the specification is still in draft stage.
Last sentence is a positive statement but there are three negative points in it.
1. Specification is still in draft stage
2. Browsers supports Most of the features of HTML 5 (Not All)
3. All browsers except IE.
We will see each of these points one by one.

The Draft Specification
"The specification is still in draft state. So how can I develop something on top of HTML5 today? If the specification itself changes tomorrow what will happen to all my codes?"
If you look at W3C process, we can see that draft itself has various levels. So draft is not just daft. In May 2011, W3C announced that HTML 5 is going to "Last Call". So what is this last call? According to W3C, (  "Ideally, after a Last Call announcement, a Working Group receives only indications of support for the document, with no proposals for substantive change". This means there will not be any substantive change any more and we are safe. Hold on. There is one more statement. "In practice, Last Call announcements generate comments that sometimes result in substantive changes to a document". So there are chances for substantive changes. It is something like a bug report which result in change of functionality. But, we need to assume that the impact of such changes will be minimum. And as of now, there are only a limited set of issues and objections in the W3C list. There are many areas in the specification where all the browsers already have stable implementations (Eg: Canvas).  I don't think we need to expect any changes in such areas.

Feature Support in Browsers
"There is no consistency in the features supported by browsers. So how will I ensure browser compatibility"
Yes, features supported by various browsers are not consistent as of now. But final destination of all browsers are same, even though the path taken by them are different. At some point of time all will reach the target, ie full HTML 5 support. So if we adhere to HTML 5 standards, it will work in all browsers after some time, even if it is not working now. But that day is not "today" or "tomorrow". So time to market has to be a major consideration while deciding to go for HTML5. In my opinion, If your target application needs to be released before mid of next year, HTML5 may be a risky business. But if you have enough time and if you are designing a system which is expected to sustain for the next ten years, going with HTML5 will be a better bet.

Internet Explorer - Headache
"When will HTML 5 be supported in Internet Explorer"
As of now support of HTML 5 on Internet Explorer is very less. There was huge expectation on IE 9 for its HTML 5 support. But, as per, support in IE 9 is not at all in acceptable range. HTML 5 support score for IE 9 is 141 where as all other browsers has score around 300. In short we cannot consider IE 9 as an HTML 5 compatible browser.
However there is something promising about Internet Explorer 10. IE 10 platform preview 3 scored 300 points in By the time it is released, we may have an even better score. But there is a bad news. IE 10 is supported only on Windows 7 or later. This means more than half of the current computer users in the world will not be able to experience HTML 5 on IE. Just like we talked about IE 6 support, this will be an even painful issue for any public facing sites. For corporate applications, corporate can influence the users to use a particular browser. But for any public site, the vendor will not have this option. If they need to go for HTML 5, they may still need to have a fully functional (less user friendly) non-HTML5 basic version of the site to support legacy IE versions or older versions of any other browser. (Eg. Basic version of Gmail)

If your target application needs to be released before mid of next year, going for HTML5 may be a risky business as browser support is yet to stabilize. But if you are designing a system which is expected to sustain for the next ten years, HTML 5 will be the ideal option. For public facing sites which require near 100% market penetration, you may still need to have a fully functional (less user friendly) non-HTML5 basic version for older browser support