EJB Best Practices: Where data validation is most appropriate

Although data validation is a necessary component of all enterprise applications, the understanding of the data validation process is often superficial and does not perform well. In this EJB best practices column, Brett McLaughlin explains some behind-the-scenes notions of data validation for systems based on EJB technology and shows you how to avoid unexpected or incomprehensible error messages.

You need to perform validation whenever you work with the business logic of your application. The application must have a way to ensure that incoming data is properly formatted and that it must be able to perform business-specific validation, such as checking purchase orders against inventory.

Instead of focusing on the validation process (which is well discussed elsewhere in the Java technology zone), we will discuss where the data validation logic should appear in the EJB application code. In previous tips in this series, we've learned a lot about the components that make up an EJB technology-based application: The underlying session bean and its business interface, the value object that transmits data between the entity bean and its clients, and the various delegation classes that act as a protective layer between the WEB and business tiers. Validation logic is perfect for any one of these components. In fact, you can place validation logic in multiple components, placing it hierarchically throughout the application (although this is undesirable). So the question we ask here is: where is the best place to put validation code in an EJB application?

Types of data validation

The first step in determining where to place the validation code is to understand what type of validation you are dealing with. Data format validation ensures that all data types (integers, floating-point numbers, strings, and so on) are correct. It also confirms that the variables are within the allowable value range and that the actual pattern matches as expected. In essence, data format validation handles any aspect of validation that does not require specific business rules to be applied.

Business-specific validation is based on a set of business rules (for example, to ensure that the ISBN number provided matches the actual book in your database). It almost always requires access to the EJB layer and other business logic components in the application.

Data Format Validation

Once you have determined the type of validation that you are working on, the next step is to determine where to place your code. In your EJB application, the data format validation logic can be placed as follows:

Place the assignment (setter) method on the business delegate.

Place the assignment (setter) method on the bean's remote interface.

Place the assignment (setter) method on the Bean's Message object or Value object.

For this example, we will assume that you are working on an EJB application that includes a business delegate. If so, you should take certain steps to ensure that all application clients (in the WEB layer) are using delegation for bean access, rather than directly accessing the bean. If so, you can safely place all data validation code in the business delegation method, as shown in Listing 1.

Listing 1. Data format validation in business delegation

package com.ibm.library;


import java.rmi.RemoteException;


import Java.util.Iterator;


import java.util.List;


import javax.ejb.CreateException;


import javax.naming.NamingException;


public class Librarydelegate implements Ilibrary {


Private Ilibrary Library;


public librarydelegate () {


init ();


　　　 }


public void init () {


//Look up and obtain we session Bean


try {


libraryhome libraryhome =


(Libraryhome) ejbhomefactory.getinstance (). Lookup (


"Java:comp/env/ejb/libraryhome", Libraryhome.class);


Library = Libraryhome.create ();


} catch (Namingexception e) {


throw new RuntimeException (e);


} catch (CreateException e) {


throw new RuntimeException (e);


} catch (RemoteException e) {


throw new RuntimeException (e);


　　　　　 }


　　　 }


//No validation required for accessor (getter) methods


public Boolean Checkout (book book) throws ApplicationException {


//No validation required here; The object type


//takes care of it


try {


return library.checkout (book);


} catch (RemoteException e) {


throw new ApplicationException (e);


　　　　　 }


　　　 }


public Boolean Checkout (List books) throws ApplicationException {


//Validate list


for (Iterator i = Books.iterator (); I.hasnext ();) {


Object obj = I.next ();


if! (obj instanceof book) {


throw new ApplicationException (


Applicationexception.validation_error,


"Only books are allowed in the input list");


　　　　　　 }


　　　　 }


try {


return library.checkout (books);


} catch (RemoteException e) {


throw new ApplicationException (e);


　　　　　 }


　　　 }


//And so on ...


public void Destroy () {


//In this case, doing nothing


　　　 }


}