Java Enterprise Best Practices

Expert Tips & Tricks for Java Enterprise Programmers
The O’Reilly Java Authors
Java
Enterprise
Best Practices
TM
Java

Enterprise Best
Practices
The O’Reilly Java Authors
Beijing
•
Cambridge
•
Farnham
•
Köln
•
Paris
•
Sebastopol
•
Taipei
•
Tokyo
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
7
Chapter 2
CHAPTER 2

EJB Best Practices
Sasha Nikolic
The Enterprise JavaBean (EJB) component model provides a very powerful platform
for distributed enterprise computing. In fact,it is one of the most widely used enter-
prise platforms around. Because of this,an enormous amount of developer experi-
ence and practical knowledge has accumulated with EJBs. In this chapter,I’ll present
best practices for a range of EJB topics. Most of these topics cannot be covered com-
pletely in one chapter,so I’ll focus on conventions and techniques that will enable
you to write solid Java 2 Enterprise Edition (J2EE) applications.
Design
Application design is the first step in J2EE application development,as any text on
the topic will attest. The reason for this is simple: changing the design is usually much
more expensive than adding a new feature,or fixing a bug in the application. Design
of the EJBs will also significantly impact the performance of a J2EE application.
Know When to Use EJBs
Even though EJBs are great,they are not always the right solution to the problem at
hand. Developers often refer to this as “using a sledgehammer to crack a nut.”
Whenever you are considering how to implement your application,bear in mind the
following basic guidelines:
Design
The EJB component model,and the J2EE architecture in general,are meant to
solve a particular class of problems. If your application naturally separates into
standard layers (persistence,domain objects,business logic,presentation),you
should consider using EJBs.
Implementation
A proper J2EE application takes time to develop. A typical EJB consists of at
least four files (home,remote,implementation,and deployment descriptor),so
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
8

|
Chapter 2: EJB Best Practices
even a small application requires some work before it can run. If you are proto-
typing an application,consider using only JavaServer Pages (JSPs) and servlets,
and then refactoring and expanding that code to include EJBs.
Performance
Application servers are meant to run applications that need scalability. The ser-
vices that the server provides (i.e.,transaction management and instance and
connection pooling) are very useful for writing scalable applications,but they also
take up a good number of computer resources. If your application does not use
these services to its advantage,EJBs might actually slow down your application
by, for instance, unnecessarily caching objects, or checking security descriptors.
In general,deciding whether EJBs are the right choice for your application comes
from experience. Knowing exactly what you will gain and what you will lose by using
EJBs will also help you make the right decision.
Use Standard Design Architecture
As I mentioned earlier,it is usually a good idea to design most of the application
before implementing it. This is especially true of J2EE applications,which regularly
contain many different components.
Even though every developer or system architect has a unique approach to applica-
tion design,most people follow some general principles. The first of these principles
is the layered structure of a J2EE application:
Presentation layer
This is the UI of the application. It usually contains servlets,JSP files,applets,
and various presentation and display logic. This layer is considered to be a client
of the business logic layer because it exclusively uses that layer to complete its
operations.
Business logic layer
This is the most important layer of the application,at least from the perspective
of an EJB programmer. This layer contains the business workflow and various

services used by the client. It relies on the persistence layer for storing and
retrieving data.
Persistence layer
This layer is obviously used to persist application data. Most of the code here
will comprise entity beans,and possibly some other layers of persistence abstrac-
tion, such as data access objects (which abstract the source of the data).
These layers are by no means set in stone. You might encounter a situation in which
adding an additional logical layer will make the application design cleaner and easier
to implement. Or you might find that you don’t need a presentation layer if your
application is used by another application. In any case,the layout of an application is
flexible,but there are some definite advantages to using this three-layer structure,
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
Design
|
9
given that the J2EE specification encourages it by classloader schemes and packag-
ing rules. Also,different types of components that can be built in J2EE (servlets,
entity beans, session beans, etc.) lend themselves to this type of structure.
The second principle of design has to do with the order in which the application lay-
ers are developed. Even though every programmer has his own philosophy and way
of developing an application,you should follow these rules if you follow the layout
described earlier:
1. Define requirements and use cases. This will help you understand what the
application has to do and how flexible it must be,and it might help you decide
which technologies to use.
2. Clearly define the domain object model (i.e.,your data objects) and business
interfaces that will be exposed to the clients.
3. Possibly write stubs for various components so that development can start.
4. Implement the persistence layer.

5. Define and write services,which are independent components of the system that
are used in the implementation.
6. Implement the business logic layer.
7. Implement the presentation layer.
Writing functional prototype applications is almost as involved as
writing a full application. You have to define and partially implement
most of the components if your strategy will extend the prototype into
a proper application. For this reason,design patterns similar to busi-
ness delegates are commonly used (see “Use Business Delegates for
Clients”),and simple implementations of these can be used in place of
EJB components and layers.
Use CMP Entity Beans
Whenever possible,try to use container-managed persistence (CMP) for entity
beans. Most application servers have highly optimized handling mechanisms for
CMP beans,and even though CMP beans might be a little harder to configure and
deploy properly, they are well worth the effort. Some of the benefits of CMP are:
• Better transaction management
• Configurable database layout
• No SQL or persistence logic in source code
• Container-managed relationships between entity beans
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
10
|
Chapter 2: EJB Best Practices
Use Design Patterns
Learn and use as many EJB design patterns as possible. Most patterns will save you
development time,improve the performance of your application,and make it more
maintainable. It’s fair to say that without patterns,writing solid J2EE applications
would be very hard.

Because this is not a design patterns book,we will not examine in detail the multi-
tude of EJB patterns that exist out there. Instead,we’ll focus on several patterns that
most EJB developers will find useful in their work.
Session façade
A session façade is the most frequently used EJB design pattern. It’s a way to encap-
sulate business workflow logic to get better performance and to have more maintain-
able code. The basic idea is very simple: put all business workflow logic into stateless
session beans,and have clients call those beans instead of calling the different com-
ponents of the application. This concept is shown in Figure 2-1.
Figure 2-1. Session façade pattern
SessionFacade FirstHome FirstRemote SecondHome SecondRemote
findByPrimaryKey()
create()
method1()
method2()
method3()
Client
businessMethod()
After:
Client FirstHome FirstRemote SecondHome SecondRemote
findByPrimaryKey()
create()
method1()
method2()
method3()
Before:
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
Design
|

11
There are many advantages to this pattern. The most significant is that moving all
business logic into its own layer makes the code a lot cleaner and more manageable.
Because each workflow operation corresponds to one business method in the session
bean,all implementation logic for that operation is executed under one transaction.
This means you need to set the transaction attributes for the session bean methods to
“Required” for this aspect of the façade to work correctly.
Having session façades will also enable you to use local interfaces in the persistence
layer, and expose only the remote session bean interface to the client.
Value objects
Value objects,or data transfer objects,are a way to transfer “bulk” data between
remote components,with minimal network traffic. For example,suppose you have a
User
entity bean. To get the user’s first name,last name,address,and other data,you
would usually have to call a
get
method for each piece of data that you need. If you
have to do this through a remote interface,the network overhead will be very large.
The natural solution to this problem is to create an object that can hold all the data
you need,and use that object to transfer the data. This is exactly what a value object
is. Figure 2-2 illustrates this pattern.
Figure 2-2. Value object pattern
After:
Before:
Client BeanHome BeanRemote
findByPrimaryKey()
getAddress()
getZipCode()
getCountry()
Client BeanHome BeanRemote

findByPrimaryKey()
getValueObject()
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
12
|
Chapter 2: EJB Best Practices
A common practice is to use the value object in the entity bean,instead of construct-
ing it every time a client requests it. Another common practice is to expose several
different value objects from a single entity bean so that clients can get only the data
they are interested in. This is ordinarily used when the entity bean contains large
amounts of data, and sending everything over the network becomes impractical.
When the number of value objects is very large and their management becomes
tedious,it might be a good idea to implement a generic
HashMap
value object that can
be used to transfer arbitrary data. Now,a generic value object would have only a
couple of
getField
/
setField
methods,and it would be hard to implement some kind
of validation code to ensure that the right value object fields are being set. In con-
trast,a simple value object has
getXXX
/
setXXX
methods for each field,which makes it
impossible to make that mistake. A compromise is to implement all value objects as
interfaces,and then use a

DynamicProxy
with a
HashMap
to store the value object fields.
Example 2-1 shows a dynamic proxy implementation,and how it’s used in an entity
bean.
Example 2-1. Use of a dynamic proxy implementation in an entity bean
public class ValueObjectProxy implements InvocationHandler, Serializable
{
protected HashMap fieldMap;
protected Class valueObjectClass;
protected ValueObjectProxy (Class valueObjectClass) {
this.valueObjectClass = valueObjectClass;
fieldMap = new HashMap( );
}
public static Object createValueObject (Class valueObjectClass) {
return Proxy.newProxyInstance (
valueObjectClass.getClassLoader( ),
new Class[ ] {valueObjectClass},
new ValueObjectProxy(valueObjectClass));
}
public Object invoke (Object proxy, Method method, Object[ ] args)
throws Exception {
String methodName = method.getName( );
if (methodName.startsWith ("get")) {
// Remove "get" to get the field name.
String fieldName = methodName.substring(3);
// It's a get, so return the value.
if (!fieldMap.containsKey ("fieldName"))
throw new ValueObjectException ("Field " + fieldName

+ " does not exist");
return fieldMap.get(fieldName);
} else if (methodName.startsWith ("set")) {
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
Implementation
|
13
Because local interfaces are implemented in EJB 2.0,there is really no need to expose
entity beans with remote interfaces. However,you still need to handle domain
objects,such as the
User
object in the example,whether the entity bean is directly
available to the client or not. So,in this case,you still have to use value objects in to
transfer this data between application layers.
Implementation
Now, let’s discuss some implementation best practices.
Use Local Interfaces for Entity Beans
As I said before,letting clients access entity beans directly is a bad idea,and this is
why session façades should be used as the intermediate layer between entity beans
and the client. Because all (or most) of your entity beans will be called by session
beans,it makes perfect sense to make these calls use local interfaces. So,if you made
// Remove "set" to get the field name.
String fieldName = methodName.substring(3);
// Put it into the hashmap.
// Assume we received one argument in the set method.
fieldMap.put (fieldName, args[0]);
// It's neither a get nor a set.
} else {
throw ValueObjectException ("Invalid method");

}
}
}
public SomeBean implements EntityBean
{
// Skipping irrelevant methods...
public SomeValueObject getValueObject( )
{
// Create the value object.
SomeValueObject vo = (SomeValueObject)
ValueObjectProxy.createValueObject (SomeValueObject.class);
// Set its values.
vo.setName ("John Smith");
vo.setAddress ("140 Maple Drive");
return vo;
}
}
Example 2-1. Use of a dynamic proxy implementation in an entity bean (continued)
This is the Title of the Book, eMatter Edition
Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.
14
|
Chapter 2: EJB Best Practices
your entity beans expose local interfaces,you would eliminate all network calls occur-
ring between business logic and persistence layers. On the other hand,the session
beans making up the façade would still have remote interfaces,and clients would
access them remotely, which is what you want.
Use Business Interfaces
Because the bean implementation class does not inherit from the bean interface,it’s a
fairly common error to get a mismatch in business method signatures between the

implementation and the interface. Typically,you would have to package and deploy
the EJBs to see the error. Needless to say,this can be very frustrating at times,espe-
cially because most of these errors are simple typos or missed method parameters.
One common practice is to use business interfaces to enforce compile-time checks.
To do this,create a new interface that contains only business methods of your bean,
and let both the remote/local bean interface and the implementation class inherit
from it. However,even though this method will work for all types of beans (CMP,
BMP,local,or remote),there are some inconveniences when dealing with remote
beans. Namely,because remote bean interfaces must throw
RemoteException
,you are
also forced to do this in your business interface. Also,a minor inconvenience is that
all method parameters must be
Serializable
.
Example 2-2 shows the key interfaces for a remote bean.
Example 2-2. The order interfaces and implementation
// Business interface
public interface Order
{
public int getQuantity( ) throws RemoteException;
public void setQuantity (int quantity) throws RemoteException;
public double getPricePerItem( ) throws RemoteException;
public void setPricePerItem (double price) throws RemoteException;
public double getTotalPrice( ) throws RemoteException;
}
// Remote interface
public interface OrderRemote extends Order, EJBObject
{
// All methods are inherited from Order and EJBObject.

}
// Implementation
public class OrderBean extends Order, EntityBean
{