Version 1.3 of the Java platform saw the introduction of the dynamic proxy facility. Dynamic proxies offer many interesting solutions to Java developers, including a validation scheme that easily decouples validation logic from an application’s core business logic. In this article, Java developer Eric Olson shows you how dynamic proxies can keep your core application code free of validation routines and focused solely on business logic.

Validation is an essential aspect of many enterprise applications. Most business methods contain validation logic to ensure that pre-conditions are met before carrying out business logic. Code that deals with values entered through a user interface employs validation logic to ensure that the values entered by a user are valid before carrying out actions that may affect other areas of the application or other users. Validation is an especially important component of applications that employ and interact with other loosely coupled components, as well as services that may not be strict in their assertions.

As important as it is to the safety and functionality of your business applications, core application logic is often cluttered with validation routines. Validation processes are often scattered throughout method calls, making it difficult to tell the difference between validation logic and core business logic. In most cases, business objects and methods must know some details of the validation process and deal with them directly in their implementation — for example, a business object may throw a validation exception directly from the business method (either coded directly in the method, or as a result of calling some validation service). The validation exception in this case is really a byproduct of the validation process, however, and would ideally be hidden from the business object implementation.

In this article, I’ll show you a more decoupled and centralized approach to validation, using the dynamic proxy facility introduced to the Java platform with version 1.3. Working with a single example throughout the article, I’ll demonstrate the weaknesses of both tightly coupled and loosely coupled validation schemes, and then show you how dynamic

This article assumes that you have some basic knowledge of SAX and DOM. If you’re new to XML parsing, you might want to read up on SAX and DOM first through online sources or skim through my book (see Resources). You don’t need to be fluent in callbacks or DOM Nodes, but you should at least understand that SAX and DOM are parsing APIs. It would also help to have a basic understanding of their differences. This article will make a lot more sense once you’ve picked up these basics.

A high-level programming language developed by Sun Microsystems. Java was originally called OAK, and was designed for handheld devices and set-top boxes. Oak was unsuccessful so in 1995 Sun changed the name to Java and modified the language to take advantage of the burgeoning World Wide Web.

Java is an object-oriented language similar to C++, but simplified to eliminate language features that cause common programming errors. Java source code files (files with a .java extension) are compiled into a format called bytecode (files with a .class extension), which can then be executed by a Java interpreter. Compiled Java code can run on most computers because Java interpreters and runtime environments, known as Java Virtual Machines (VMs), exist for most operating systems, including UNIX, the Macintosh OS, and Windows. Bytecode can also be converted directly into machine language instructions by a just-in-time compiler (JIT).

Java is a general purpose programming language with a number of features that make the language well suited for use on the World Wide Web. Small Java applications are called Java applets and can be downloaded from a Web server and run on your computer by a Java-compatible Web browser, such as Netscape Navigator or Microsoft Internet Explorer.