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.

Customizability
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
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. 

Performance
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. 

Transaction
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.

Logging
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.

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

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

Maintainability
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.
Conclusion
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 http://html5test.com/ 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, (http://www.w3.org/2005/10/Process-20051014/tr.html#last-call)  "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 html5test.com, 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 html5test.com. 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)

Conclusion
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

Wednesday 16 November 2011

IE 6 Support Dilemma

Often there is a dilemma among web developers whether they need to support Internet Explorer 6 or not.
Problem with supporting IE 6 is that, it is very complex, especially if you are building rich interactive web sites. Many functionality may not work and many other functionality will have extremely sluggish performance.
There are many campaigns running on behalf of dropping IE 6 support. Eg. http://idroppedie6.com/ , where you can register your website and declare Independence from IE 6.

Before dropping IE 6 support, we need to see whether any one uses it. Yes, many use it. If you check  browser market share statistics from various sources, you will see that around 5 to 10 percentage of the users are still using IE 6.
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
http://en.wikipedia.org/wiki/Internet_Explorer#Market_adoption_and_usage_share
So question is whether you need to support (or rather, get business from) these 10 percentage of the users or not.
But why all these people are still using IE 6? My assumption is as follows. Almost 50% of the computer users are still using Windows XP. It may have shipped along with their computer and there are only a very few users who upgrade the OS. Default browser shipped with XP was IE 6. Among this XP users, there is a section who may not have enabled Windows Update and so they are not upgraded to IE 8. And there will be yet another section who may be using pirated Windows XP and so they don't have an option of windows update. But from a business perspective, can we say that we don't need business from those who are using pirated softwares?

The million dollar question is still open - "Do I need to support IE 6?".
In my opinion, if you are developing a public website whose usage will impact your revenue, you should support IE 6. Now the problem is that, if you develop a rich web screen, it will always have issues in supporting IE 6. My suggestion is to have a highly user friendly web application, targeting the newgen browsers such as firefox and chrome. And in addition to that have a fully functional but less user friendly version of the same application to support IE 6.
But if you are targeting corporate users, you may need to support only new generation browsers. Here the advantage is that corporate can instruct the users to use free newgen browsers like firefox or chrome.
You can also check the usage pattern of your website and find out the browser usage share, Using this data you may take appropriate decision.

Tuesday 15 November 2011

Spring Roo - An excellent RAD tool

Recently, I had a look at Spring Roo,  http://www.springsource.org/roo 
Roo is part of Spring family and it 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 built using Spring Roo. It is not an IDE or a runtime. It is just a programming methodology combined with a code generation tool. 
To set up an application using Spring Roo, you may need to enter a few commands on the Roo shell. After that you can create your entities and add fields to it. Roo shell running in the background will create all the artifacts required. The application will be ready to run with full CRUD operations for the entity. 
Generated artifacts include 
• A listing screen which lists the entities in a table with pagination. Delete and update can be triggered from this screen 
• A create/update screen to create/update one entity. 
• A view screen to view one entity. 
• Spring MVC Controller class for performing the operations on the entity 
• Java bean setters and getters for entity. 
• Persistence logic for all CRUD operations for the entity. 

Finder Generation 
If there is a requirement to filter the listing based on a few parameters, finders can be generated. You just need to add an annotation to the entity and Roo will create the screen and corresponding logic for the same. 


Excellent Roundtrip handling 
Most of the Roo generated codes can be edited manually. Roo shell will automatically detect that and adjust the application accordingly. Even when Roo updates those files later, the manual changes will not be overwritten. 


It is nothing but Spring 
This is one of the unique features of Roo. The generated application is nothing but a normal Spring application. It gets the entire strength of the robust Spring framework. It is easy to build all the NRFs into the application. For example, authentication and authorization can be performed using Spring Security.  This makes Roo a strong candidate for developing enterprise applications, without compromising on NFRs.

Maven Dependency Management 
Dependency management in Roo is very easy as it is handled by Maven. As and when new features are added to the application, roo will automatically update the pom.xml and maven will download the dependencies. 

JSR-303 Bean Validation 
Spring Roo performs data Validation based on JSR-303 annotations. 

Integration with industry standard frameworks 
Other than spring, it has off the shelf integration with industry standard frameworks like Hibernate, Spring MVC, log4j, Google Web Toolkit, Solr search engine, EclipseLink, OpenJPA etc. 

Roo independent runtime 
The role of Roo ends in development cycle. The runtime of your application does not have a dependency with Roo. Spring Roo even provides a guideline on how to remove Roo from the application without affecting the functionality. 

Eclipse Based IDE 
Easiest way to develop in spring roo is to use STS (Spring Tool Suite) which is nothing but eclipse with a few extra plugins. 

Flexibility 
An important advantage of Spring ROO is that it gives you maximum flexibility. Once you do the automated generation, almost entire code is at your disposal, and you can do any modification to that as you wish. The generated code is very clean and easy to understand. So even though you are working with generated code, you will not have any restrictions of generated code. 
And it is not mandatory that you following Roo based approach for all screens. You can use Roo to build your simple CRUD functionality and use a normal Spring MVC-Spring-Hibernate architecture to build complex functionality. As the technology stack is generally same, they can easily coexist. 


In any enterprise application, a large amount of functionality is simple CRUD. Spring Roo can surely improve productivity in developing such applications.