EJB

Do we façade? The decision to have a façade as a gateway for your other EJB components should be considered well ahead of time. It cannot be an afterthought. Once the decision has been made to have a façade, you can design the façade to return objects that are aggregations of values. The fine-grained access will be handled by the façade and is effective because it is generally within the container. This way we can reduce the number of round trips to the remote server.

Ok. We façade. But how good is our facade? When designing EJB interfaces the crucial points are that, for the purposes of designing remote interfaces, state should be avoided where possible and remote interfaces should be sufficiently coarse grained. Coarse graining interface design does not necessarily mean bundling all of the methods of your EJB layer inside one façade. Most often it is good to have multiple facades serving as gateways to your EJB components. When designing EJB-based architecture the safest approach is to find a balance between an object-oriented domain model and the procedural remote service layer.

Effective Exception Handling
Exception handling is another of the most muddled areas of EJB development. Exceptions are basically a breakaway from the expected behavior. These breaks are very common in distributed architectures because there are too many heterogeneous environments involved that are all connected by the network. A single network failure can trigger a catastrophe. Handling exceptions in EJB is particularly complex, and EJB involves two types of exceptions. The following are some guidelines for handling exceptions.

• Refractor Logic out of Exception Handling Blocks. Having application logic inside exception handling code is a bad practice that often leads to code that is difficult to understand, change, and debug. The particular case in EJB programming where logic is deliberately pushed into exception handling code is transaction rollbacks. Rolling back transactions when there is an exception confuses program flow. Also, rolling back a container-managed transaction is not a straightforward task. EJB specification recommends use of EJBContext.setRollBackOnly() instead. Second, transaction rollback during an exception is not always appropriate. Third, transaction rollback falls outside of the transaction implementation. If an application throws an exception when running inside an EJB with notSupported transaction attribute, there is confusion as to whether to roll back the suspended enclosing transaction or not.
• Don't Swallow Exceptions. Exception logging is an important part of any component design. One of the most common mistakes made by developers is to just print the exception and continue as if nothing has happened. Whenever there is an exception, it is an indication that something has gone wrong. The error could be on part of the container or in your application code itself. Simply logging exceptions without much detail makes debugging very difficult. Java provides an elegant way of logging the complete exception trace. In most cases, the exception trace would provide all of the information that is required to debug a problem. It is also better to have a custom verbose attached to the exception trace to help make understanding the situation easier.
• Throw the Right Exception. Always. One bad practice in many EJB implementations is the tendency to wrap application exceptions into Container exceptions and throw them at the client. This practice stems from the misconception that the container handles all things for you when you are developing an EJB. However, container exceptions are specialized cases where there is a failure on part of the container, while the application exceptions are a run-time application failure. An example of application exception is invalid credit card number. This should not be wrapped inside a container exception like EJBException. The application exceptions are to be gracefully handled as in any other normal Java class.
• Look for Hot Potatoes. A hot potato is a particular situation where a MDB repeatedly receives a same message and throws an exception while handling the message. When a JMS server does not receive an acknowledgement for a message delivered to a consumer, the server's only recourse is to resend the message. This sets the stage for repeated delivery of the same message indefinitely when the consumer that is processing the message does not handle an exception condition properly.

When developing MDBs care should be taken to identify potential areas of code that cause the hot potato situation. The solution for this is to break the acknowledgement and message processing into two execution paths. Acknowledge the message immediately once received. When an exception occurs during message processing, you may possibly write the exception to an error queue.

Effective EJB Persistence
The EJB specification addresses the persistence services through a special class of beans called entity beans. Entity beans are aimed at abstracting the domain data model. As such, they represent rows in a database table if the underlying datasource is an RDBMS. Initial specifications sparked a lot of controversy about entity beans and their usage. Henceforth, the persistence API has been rewritten twice in 1.1 and 2.0 specifications.

Because persistence is a fine-grained service it does not fit naturally into the coarse-grained nature of EJB services. This brings in a lot of confusion about how best to use entity beans. Before the decision to use entity beans has been made, a careful evaluation of alternate persistence models is advised. If a decision has been made to use entity beans, the following problems should be carefully considered and evaluated.

Exposing Entity Beans Directly to the Client Through Remote Interfaces
Due to their fine-grained nature, entity beans provide fertile grounds for antipatterns when exposed directly to the client. One of the most popular problems that is likely to be encountered is the n + 1 problem. This means you will require n + 1 remote calls to retrieve n attributes of a business entity. The extra call is to obtain the remote stub from the EJB container. Addressing the same retrieval function through a plain POJO DAO is much easier. All you will require is a JDBC call to retrieve the rows.

A more subtle problem associated with exposing entity beans is the loss of transaction integrity. Consider an entity bean with three mutator methods. Further assume that a client needs to update two columns of the entity represented by two mutator methods in a transaction. How does the client ensure that transaction integrity is maintained between two successive update methods on the entity bean? The only way out is to use a session façade to wrap the entity bean.

Avoid Application Joins
Managing entity relations within the application code will cause serious performance issues. Java is not optimized for database lookups. It is a bad programming practice to emulate application joins inside Java code. Databases use sophisticated technologies to optimize query access plans and consequently minimize the number of data comparisons. For example, the act of looking up for a Person entity when given an address entity within the application does not scale. These types of relations are best expressed in terms of a CMR field (from EJB 2.0). The number of comparisons that an application makes inside a loop construct in an attempt to simulate a relational join will have a severe impact on application performance.