J2EE Pitfalls

During my last couple of years as architecting J2EE applications, I have come across certain do's and don'ts, during the design of a Enterprise Application.

1. Use of EJB's
Many projects use EJB's because that is the "in thing" or because this is an enterprise application, using EJB's is a must. My experience says use EJb's where it makes sense. Places where you need to utilise the EJB Container services - like transaction, security. In case, the application does not require all this, then the application should look at POJO's as a viable alternative.

2. Validations
Another issue is the deciding which validation need to be done at client side and what all need to be done at server side. We tend to segregate the validations between client and server. It works fine, as long we are the only clients for our server objects. The movement, another client(Rich Client Application, Mobile Applications) wants to utilise the services of our server objects, our server objects start bombing, because the new client is not conforming to the client side validations expected from him. The best practice is to make sure that our server objects does all kinds of validations so as to avoid any bombs later on.

People might question, on why do we do perform simple checks like field length validations twice. I say, you are not doing twice. Look from the Responsibility angle, the serve object needs to be self sufficient to perform all validations for the data the object deals with. The server object should not fail because the client did not gave correct data or all the data. Validation on the client side are more from Presentation layer perspective, where the client can restrict the user from entry garbage data or insufficient data.

3. Application Security
When starting the design of the enterprise application, the application security is the most ignored aspect. It is usually added as an add-on the application during the fag end of the application development. But it might be too late by this time. Security needs to be thought through and implemented as a vertical layer in your application.

Once, I worked on an application, where the application had almost 10 different types of security requirements. Privileges needed to be captured at multiple layers. Presentation layer had different set of security privileges. Business layer had different, Data Layer different. Even the data going into database needed to be encrypted, even the DBA was not supposed to see that data.
There is a nice book Core Security Patterns: Best Practices and Strategies for J2EE™, Web Services, and Identity Management on the same subject.

4 Internationalization and Resource Bundles
Another pitfall is the non-use of resource bundles. The common excuse is, our application is a extranet application or meant for one particular customer target or country, where the requirement is English only. Internationalization is the underlying theme today for all applications. The application should from day one take internationalization into account. Here,just moving the text for labels, or messages does not make the job complete. Things like menu items text, application header and footer and also how does the language effects lay out of the page need to be accounted for.
In the old client-server days, I remember we were working on a MFC based windows applications where we needed to support 2 languages - English and German. So the mandate was the length of each field label needs to be 25% extra as what we had for English label.
Check out J2EE Internationalization and Localization

5 Improper Use of MVC model
MVC is a presentation layer model. Adding business logic to the model class leads to wrong usage of the MVC model. The model class should call a business delegate class and that business delagate class should invoke the business objects. The Business Delegate acts as a client-side business abstraction; provides an abstraction for, and thus hides, the implementation of the business services. Using a Business Delegate reduces the coupling between presentation-tier clients and the system's business services.

These are some of the big ticket guidelines. I will try to blog down another set soon. Watch out for the same.

Filed in:
0 Comments To ' J2EE Pitfalls '

Post a Comment