headerphoto

Time to Cut Some Dead Wood? Relevance of J2EE Patterns in the world of EJB3 and Java EE 5 - Part I

By Pradeep LN

With the introduction of Java EE 5, the Java enterprise landscape has gone through a sea change. EJB3 which is part of Java EE 5 has Ease of Development as its primary objective. The J2EE community, over the years had gotten used to using and reusing a certain number of design patterns. Although there was some debate over relevance of a few patterns in the J2EE Patterns catalog itself, by and large those patterns were well adopted. This article is aimed at practitioners of J2EE who are now trying to design applications using Java EE 5. We’ll attempt to see which of those J2EE patterns are still relevant? And which ones we can consider dead wood to be chopped?

The J2EE patterns catalog categorizes the patterns on the following lines :

  1. Integration tier patterns
  2. Intra business tier patterns
  3. Presentation-to-business tier patterns
  4. Presentation tier patterns

We will look at some of the most widely used J2EE patterns and their relevance in the world of EJB3 and Java EE 5.

Integration Tier Patterns


Data Access Object (DAO) Pattern

DAO pattern is part of the Sun J2EE patterns catalog and is described in the following way (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html) :

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source.

With the introduction of JPA into Java EE 5, the need for this DAO pattern is often questioned. After all, doesn’t JPA shield the application code from the gory details of vendor specific data access? If it does, then why do I need another layer on top of it to do the same job? The answer for that is really two-fold:

Firstly, JPA is explicitly aimed at RDBMSs and not any other type of storage. So, say if some of your application data, moves from an RDBMS to another type of storage (say LDAP) and if business services were directly using the JPA to access data, all those business services will break. I know what some of you may be thinking : Come on man, how often does the data storage change? Have you seen an RDBMS being replaced by something else in the ‘real world’? etc. Agreed that the data storage type changes very rarely. But it does change sometimes, especially for those applications which get ‘productized’. A case in example could be an application I have seen. In its original design, it was envisioned to be a standalone application with its own data in its database (RDBMS). All was well until this application was decided to be ‘packaged as part of a larger suite’ of applications. Most of the data in the new ‘suite’ continued to be in RDBMS except for data about users (names, email, phone etc). In the new suite, all this data was being stored in a LDAP and not RDBMS. And since in the original design, they were using Hibernate persistence, they had done away with the DAO pattern and used Hibernate API directly in business components. So when it came to adapting to LDAP, many business components had to be rewritten.

Secondly, the DAO pattern enforces better application layering. It encourages you to separate out the application logic from the data access logic. Agreed that JPA makes that data access logic look more akin to application logic and is certainly more readable than JDBC code; but having said that, it is still data access logic! Especially in applications where the application logic is large and complex, it’s worthwhile to have a separate DAO layer to improve maintainability and readability.

However, there has been criticism of this pattern as well. The critics of this pattern argue (somewhat convincingly at times!) that this pattern is vague about its goal and sets unrealistic expectations which are impossible to achieve. Writing in their book ‘Building Spring 2 Enterprise Applications’ (ISBN-10 (pbk): 1-59059-918-7) , the authors dedicate a good couple of pages(pg. 159,160) for criticizing the DAO pattern. But that criticism has nothing to do with whether it is J2EE 1.4 or Java EE 5.

So, all in all, with the above criticism in mind, should you use this pattern or not? My answer is simple: If it made sense in J2EE 1.4 for you and benefitted from it, there is no reason why it does not make sense now.


Domain Store Pattern

The domain store pattern was introduced into the second edition of the patterns catalog. It is described as follows (http://www.corej2eepatterns.com/Patterns2ndEd/DomainStore.htm) :

Problem

You want to separate persistence from your object model.

Solution

Use a Domain Store to transparently persist an object model. Unlike J2EE’s container-managed persistence and bean-managed persistence, which include persistence support code in the object model, Domain Store's persistence mechanism is separate from the object model.

In the days of J2EE, J2EE by itself was not offering any full-fledged ORM. So this pattern captured the generic essence of building an OR Mapping framework. But then how many business application developers went about writing their own ORM frameworks? Anyways, this pattern was introduced into the catalog to improve the developers’ understanding of ORM frameworks. JPA is nothing but based on this pattern (as is Hibernate and JDO). Since JPA is part of Java EE spec, an understanding of JPA is sufficient. You can kiss this pattern good bye unless you are writing an ORM framework of your own.

The Service Activator Pattern and the Web Service Broker Pattern are as relevant in Java EE 5 as they were in J2EE 1.4.

About the Author

Pradeep LN is an instructor, author and a consultant. He conducts classes primarily in the areas of Java, Java EE, SOA and Web Services.Click here to know more about him. And click here to view all the courses he teaches.