Contents: Types of data validation Data-format validation Business-specific validation Conclusion Resources About the author Rate this article Related content: EJB best practices series Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Brett McLaughlin (mailto:brett@oreilly.com?cc=&subject=The fine points of data validation)
Author and Editor, O'Reilly and Associates
1 December 2002

Although data validation is a necessary component of all enterprise applications, data validation processes are generally poorly understood and badly executed. In this installment of EJB best practices, Brett McLaughlin explains some of the concepts behind data validation on EJB technology-based systems, and shows you how to avoid unexpected or incomprehensible error messages.

Anytime you're dealing with the business logic of an application, validation will become a factor. Your application must have a way to ensure that incoming data is in the right format, as well as to perform business-specific validation such as cross-checking purchase orders against inventory.

Rather than focus on validation processes (which are well-covered in other areas of the Java technology zone), we'll examine where data validation logic should occur in your EJB application code. In previous tips in this series, we've learned quite a bit about the components that make up an EJB technology-based application: the underlying session bean and its business interface; the value objects that transfer data between an entity bean and its clients; and the various delegate classes that act as a protective layer between the Web tier and the business tier. Validation logic could fit quite comfortably in any one of these components. In fact, you could place validation logic in multiple components, layering it throughout the application (although that wouldn't be advisable). So the question we're asking here is, Where is it most beneficial to place validation code in your EJB applications?

Types of data validation
The first step to figuring out where to place your validation code is knowing what type of validation you're dealing with. Data-format validation ensures that all data types (integers, floating point numbers, strings, and so on) are correct. It also confirms that variables are within the range of allowed values and that patterns match as they should. Data-format validation essentially deals with any aspect of validation that doesn't require the application of specific business rules.

Do you know the difference? The ability to clearly distinguish between the two types of data validation is critical to good application design. Deliberate or unintentional mixing of the two types of validation can result in horribly architected classes and inefficient application performance.

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

Data-format validation
Once you've determined the type of validation you're working with, the next step is to figure out where to place the code. Data-format validation logic can be placed as follows in your EJB apps:

• The mutator (setter) methods on your business delegate.
• The mutator (setter) methods on your bean's remote interface.
• The mutator (setter) methods on your bean's info or value object.

For the purpose of this example, we're going to assume you're working with an EJB app that includes a business delegate. If that's so, you should be taking steps to ensure that all of your application clients (in the Web tier) are using the delegate for bean access rather than accessing the bean directly. And if that's the case, you can safely place all your data validation code in the business delegate methods, as shown in Listing 1.

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 our 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, do nothing
      }
}

When it comes to data-format validation, you want to keep your validation logic as close to the client as possible. Data-format validation often triggers error pages or requires the client to re-enter incorrectly formatted data. In these cases you want to provide feedback to the client quickly, and with minimal cost to your processing overhead. By placing the validation logic in the business delegate, you've created the most natural error-handling scenario. When a client tries to query the delegate with data that is incorrectly formatted, an error is triggered and the request is sent directly back to the client, alerting the user of the problem.

Placing the validation logic in the bean implementation would create a much less efficient validation process. Rather than going directly from the delegate to the client, error messages would be passed from the bean implementation to the delegate, most likely as a RemoteException rather than an application exception. In addition to the cost of the remote exception, the delegate would have already paid the price of JNDI lookups, RMI traffic, and (possibly) additional business logic -- far too much processing power to spend on a single validation error!

Business-specific validation
Business-specific validation is a different case altogether. Business validation errors are generally more complex than data validation errors, and are rarely resolved by client interaction. Resolving business-specific errors requires the use of additional entity and session beans, as well as database access, all of which must be processed through JNDI and RMI transactions. That's a lot of overhead to put on a business delegate. A much better idea is to move this validation back into the EJB layer, specifically into the bean's implementation class.

When placed in that layer of the application, all of your RMI traffic should be local; most application servers will use in-VM optimizations to make bean-to-bean interaction extremely fast. You may also avoid JNDI access, since many beans will already have looked up related beans' home interfaces. Furthermore, your business delegate will already have handled any necessary data-format validation.

Conclusion
When deciding where to place your validation code, it's important to be able to distinguish between the two validation types. Data validation is a much simpler type of validation than business validation, and the general rule of thumb is to keep it as close to the client as possible. Business-specific validation is more complex and often requires several different transactions to complete. This type of validation should be located in the EJB layer, where it can piggy-back on existing processes as much as possible.

In the next tip, we'll look at additional ways to enhance your application's validation processes, and isolate the validation from your business delegates completely. Until then, check out the further reading in the Resources section, and I'll catch you online!

Resources

• Check out the complete EJB best practices series by Brett McLaughlin.
  
  
• The "Enterprise JavaBeans fundamentals" tutorial (developerWorks, March 2001) is a great way to get started with EJB technology.
  
  
• Eric Allen's Diagnosing Java code column is a storehouse of tips to help you manage common errors in your Java code.
  
  
• In his article "Best practices in EJB exception handling" (developerWorks, May 2002) Java architect Srikanth Shenoy demonstrates how to code for faster problem resolution on EJB technology-based systems.
  
  
• Sun Microsystems's EJB technology home page is a good starting place for information on EJB technology.
  
  
• Another great resource, TheServerSide.com, offers articles and information pertaining to J2EE.
  
  
• See the developerWorks Java technology tutorials page for a listing of free J2EE- and EJB technology-related tutorials from developerWorks.
  
  
• Find hundreds more Java technology resources on the developerWorks Java technology zone.
  
  

About the author Brett McLaughlin has been working in computers since the Logo days (remember the little triangle?). He currently specializes in building application infrastructure using Java and Java-related technologies. He has spent the last several years implementing these infrastructures at Nextel Communications and Allegiance Telecom, Inc. Brett is one of the co-founders of the Java Apache project Turbine, which builds a reusable component architecture for Web application development using Java servlets. He is also a contributor of the EJBoss project, an open source EJB application server, and Cocoon, an open source XML Web-publishing engine. Contact Brett at brett@oreilly.com.

What do you think of this document? Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1) Comments?

developerWorks > Java technology