Four J2EE Patterns - Will we be able to understand them definitely?

Introduction

The purpose of this document is to explain four important J2EE Patterns that everybody knows and uses frequently but from my technical perspective the most of us do not apply correctly.

The four patterns are the following:

Business Patterns:

§          Application Service Pattern

§          Business Object Pattern

Integration Patterns:

§          Data Access Object Pattern

§          Domain Store Pattern

Application Service Pattern

This pattern provides a central place to put business logic between the service facades and the business objects.

Import Issues to take into account

Business processing logic should usually not be placed in business objects. Business objects represent business data entities. The business processing for a specific use case often involves multiple business objects. If this business processing code is put in the business objects, it can lead to a lot of couplings between the business objects that decrease reusability, maintainability and performance of the business objects.

The amount of use case specific business logic in a business object should be minimized.

Business processing should usually not be placed in service facades. Service facades are a generic term for session facades (EJB applications) or POJOS facades (Non-EJB applications). Service facades provide coarse grained simple interfaces with use case specific methods. Often several uses cases require the same business processing logic. Thus, placing this code in the service façade can lead to code duplication. In addition, service facades with this processing code might have poor cohesion.

Applying a Solution

The ServiceFacade class has very little code. It primarily invokes the appropriate ApplicationService methods. The ApplicationService methods have the primary business processing logic and coordinate the invotactions of the business objects. The ApplicationService components can use business objects, other ApplicationService components, ordinary Service objects or DataAccessObjects.

The participants in the Application Service pattern are:

ServiceFacade – Session façade or POJO façade.

ApplicationService – Usually implemented as POJOs.

BusinessObject – Implement fine grained, use case generic business logic to represent business data entities.

Advantages of pattern include:

§   Encourages reusability of business workflow logic.

§   Avoids duplicating code in service facades.

Disadvantages of the pattern include:

§   It introduces an extra layer that might be unnecessary for smaller applications.

Business Object Pattern
This pattern describes how to organize and separate business data from business logic and workflow. Business objects are the business entities used in the use cases.

Import Issues to take into account

Many business services can require access to the same data, much of the data access and handling code might have to be repeated if it is placed in the business services classes.

Applying a Solution

Separate the business entities into a separate layer of reusable business objects. The business objects primarily hold and manage the business entity data. Business objects can have some business logic in them, but this should be fairly minimal, not use case specific and very data oriented, such as data validation and manipulation. This kind of business logic is usually applicable to multiple use cases that use that data. Data persistence code should be separated into another layer, such as described by Data Access Object pattern or the Domain Store Pattern. The business objects can be persisted in various ways:

§   Implement the business objects as CMP entity beans, in which case the persistence is handled by the server.

§   Implement the business objects as BMP entity beans that use data access objects for persistence.

§   Implement the business objects as POJOs that use a custom data access objects.

§   Implement the business objects as POJOs that use a domain store.

Business objects components are usually invoked by application service components but they might also be invoked by service facades. It is not recommended that the presentation tier components directly access business objects as this increases coupling, violates the tiered architecture approach, and can decrease performance if the client is on a different physical tier. When data is transferred between business objects and client objects on other physical tiers, transfer objects should be used.

Business objects must not have persistence code or invocations.

The participants and responsibilities in the Application Service pattern are:

ApplicationService – The ParentBO component is usually used by ApplicationService component. This role can replaced by a service facace component or a helper component.

ParentBO – Business objects that are accessed directly by client classes such as ApplicationService components.

DependantBO – Business objects that are dependant on other business objects for their lifecycle management. Client classes should not access these business objects directly.

Advantages of the pattern include:

§   Business data can be viewed as object-oriented data by the business services, even if the data is stored in non object-oriented databases such as relational database.

§   The business data logic is separated from the persistence logic.

§   The business service layer is simplified by shielding the business service layer from business data manipulation and persistence issues.

Disadvantage of the pattern include:

§   Business objects can become bloated if too much business logic is placed in them.

§   This pattern introduces an extra layer that might be unnecessary for smaller applications.

Data Access Object Pattern

This pattern encapsulates data access logic and simplifies access to several data sources.

Import Issues to take into account

Accessing different data sources (Relational Database Management Systems (RDMS), Object-Oriented Database Management Systems (OODBMS), and flat files) usually requires different code, different access mechanisms, API frameworks, and features sets.

A J2EE platform component that embeds these database access details in its own logic quickly becomes susceptible to managing the details of a particular database. This creates a risks to future maintainability of the code relies heavily on the database implementation details. If you need to change a persistent store mechanism in the scenario, you must also rewrite the hard-wired components to match the new products.

Finally, the same data access code is often required by multiple parts of the business logic. If the data access code is embedded in the business logic, it can be difficult to reuse it without copy-and-paste techniques.

Applying a Solution

The data access code is factored out of the business objects and placed in a plain Java object called DataAccessObject.

The DataAccessObject keeps a consistent client interface, modifying only the object’s internal details to adapt to changes in the persistent store. When product changes take place, new implementations of the DataAccessObject interface can be added to the system, maintaining transparency to the BusinessComponent object.

The DataAccessObject should be implemented as stateless component that does not cache any results. This allows the DataAccessObject to be lightweight component that avoids potential concurrency and threading issues. The DataAccessObject component should not expose any exceptions or other classes that are a part of data access technology packages, such as java.sql.

The participants and the responsabilities of the Data Access Object pattern are:

BusinessComponent – Uses a DatraAccessObject to access persistent storage to get and store data. A BusinessComponent class can be a JavaBeans component, a session bean, an entity bean, a servlet, a helper object, or another Java object.

DataAccessObject (DAO) – Ecapsulates the access details that the BusinessComponent relies on. The DataAccessObject hides the underlying implementation from the BusinessComponent object so the latter can focus on data manipulation.

DataSource – This represents any persistent storage implementation the system uses.

TransferObject – A simple serializable data structure that can be used to hold a data record.

Advantages of the pattern include:

·          Factoring data access logic out of the business logic.

·          Creating a more flexible system for future migration efforts.

·          Increasing cohesiveness of business objects.

·          Isolating data access to its own tier.

Disadvantage of the pattern include:

·          Pattern adds an extra layer of infrastructure to be developed.

·          Pattern is not useful with CMP entity beans.

Domain Store Pattern

The pattern describes how to create a robust persistence mechanism that is transparent to the business objects without using entity beans. The pattern offers an alternative to BMP entity beans, CMP entity beans, or writing custom, but not transparent data logic as described in the DAO.

Import Issues to take into account

The Data Access Object (DAO) pattern provides a very simple approach for isolating data access code. Although the DAO pattern separates the persistence code from the business objects, this pattern does not make the code transparent to the business objects. That is to say, the business components still need to invoke DAO methods to manage the persistence of the business objects. For many applications, a solution is needed that allows transparent persistence for business objects.

Many enterprise applications have a complex object models that require sophisticated persistence solutions. For many systems, entity beans are an appropriate persistence solution. In particular, container managed persistence (CMP) 2.0 and container managed relationship (CMR) provide powerful tools for persisting complex business object structures.

However, there are several reasons why entity beans might not be an ideal choice in some circumstances:

§   If the other entity bean services, such as security and remote access, are not required, a lighter weight alternative might be preferable.

§   Some applications do not use an EJB container, and thus cannot use entity beans.

§   In some cases, there might be a need for a persistence mechanism that does not place constraints on the business objects. For example, one entity bean business object cannot be a subclass of another entity bean business object.

Applying a Solution

A domain store transparently persist business objects.

Aurelio - The Guru’s  Note: JPA is an implementation of the J2EE Core Pattern called Domain Store, which does pretty much of what DAO does. It hides from you the native and specifics of a legacy system, so you DON’T NEED to shield the client for that. That’s nonsense to shield access to a Domain Store in a DAO.

Also I would say that this specific logic you put in the DAO, could be well placed in the J2EE Core Pattern called Application Service, where you could place the logic to handle that entity and incorporate the business rules behind that.
Note that it also should not be a EJB. After EJB 3.0 many people are overusing EJBs and building bad system that will not scale and will create a number of bottle necks because of the amount of EJBs in Biz and Integration tier all tied and chained together. EJB is cool, but not to be overused this way…

Hope the people read the catalog and use the J2EE platform correctly… Guys, don’t forget to read the original anti-patterns for EJB:

§   Bitter EJB


§   J2EE Anti-Patterns

Advantages the pattern include:

§          Allows many of the persistence and transactional benefits of entity beans, potentially without the overhead of other entity beans services that might not be needed in some applications.

§          Creates more robust and transparent persistence capabilities than the Data Access Object pattern.

§          Separates the persistence from the business objects, allowing developers to focus on the business logic and data without worrying as much about persistence.

Disadvantages of pattern include:

§          This pattern is quite a bit of work to implement from scratch. Thus, implementing it from scratch is only recommended if all other options seem undesirable.

§          A full persistence framework might be overkill for many applications. In the cases, the Data Access Object pattern might be a better choice.

Putting everything together