SpiderLogic.com

Spider Architecture Series

Application Validation Strategies

By Mike Dietz

Abstract

This article discusses a strategy for data validation within a software application. It addresses the complex interactions often required between the UI and business (domain) layers of an application. The decision of whether to use a Rule Engines is also discussed.

Overview

The validation of data within an application is a broad-ranging topic. Validation encompasses everything from the data type checking for a single field to highly complex business rules crossing multiple fields and records. Simple field-level validation can be relatively trivial to implement, but the more complex validation processes are far from trivial.

Current best practices for application development advocate layered applications. User interface, business logic, and persistence should be separate. Clearly, business rules fall within the context of the business logic. At the same time, in all but the simplest software applications, validation impacts the user interface as well. It is the user interface that must notify the user about invalid input. In many cases, the application requirements dictate that the interface must guide the user to prevent the entry of invalid data, avoid the entry of unnecessary data (data that is not required, based upon earlier selections / data entered by the user), and to streamline the correction of invalid data when it is entered. In those situations, retaining the integrity of the application layers can be difficult and, in many projects, fails, resulting in the maintenance issues that application layering is intended to prevent.

The software implementation and execution of business rules has received a significant amount of attention. Mature tools for rule encoding and processing have been available for a number of years. In addition, there is now a Rule Engine API for Java, as well as open source implementations. The use of a rule engine can simplify the implementation of complex business logic, and can help ensure the separation of the business logic from the rest of the application. Despite the advantages, the use of a rule engine does not address the complex issues of interaction between the business rules and the user interface.

One solution to these issues will be discussed here. This solution entails the use of the rules engine to facilitate the isolation and simplify the implementation of the business rules, along with the definition and use of “Concept” objects to encapsulate the complex interactions with the user interface.

Validation Scope

This discussion will focus on more complex validation scenarios. These scenarios include:

Form Validation
Business Rule Validation

Form Validation is typically specific to a single panel or form on the UI, and is often constrained to a single domain and its related sub-domains. The validation process is triggered by changes to the current UI panel.

Business Rule validation includes the rules that govern the business and often involve multiple domain objects. This type of validation is also ultimately triggered by changes in the UI, which change the state of the domain objects. When a business rule engine is utilized, it must be configured to be triggered by changes to the current domain state.

Due to their relative simplicity, these types of validations will be excluded from this discussion:

UI Enforced Validation, where the nature of the UI itself enforces the validity of the data. For example, a drop down box will only list, and allow selection of, valid values.

Field Validation, where the entire validation rule is within the scope of a single field. For example, a required zip code field must have 5 or 9 numeric characters to be considered valid, and the UI may prevent the user from leaving the field while the value is not valid.

To further define the scope under consideration, the situations of interest include cases where a change in the user interface may affect one or more business rules and/or form validations. In addition, the change in state of any business rule or form validation (from valid to invalid, or vice versa) may cause one or more changes (error indicators displayed or cleared) to the user interface. In effect, this creates a many-to-many relationship between the validation elements and the user interface elements.

Business Concepts

To encapsulate this complex set of relationships between the validation elements and the user interface elements, Concept objects were introduced. Concepts reflect the changing state of a set of business rules and domain validations as the user navigates the application. Based upon the current state from the user interface, each of the rules and validations associated with a given Concept will “vote” on the validity of the concept. The voting for the Concept must be unanimous – if any of the rules or validations is invalid, then the Concept as a whole is invalid.

For each of the UI widgets that is dependent on a given Concept, the renderer must register itself as a listener on the Concept. When the validity of a Concept changes, it notifies each of its listeners. Those listeners then do the appropriate rendering of the UI components. Some examples of UI components which can be controlled by Concepts include:

A text field’s label may be tagged with an error icon and a float over tip based on an invalid concept.

A button may be disabled until a concept is valid. For example, the next button on the account panel will be disabled until all required fields are entered.

A tree node will be disabled until a concept is valid.

A text field will become disabled when its concept is valid to enforce a UI rule that once state is valid, the user may not make changes.

The following diagram illustrates the relationships described above:

Rule Engines

Before completing this discussion, it will be worthwhile to review the basics of rule engines, and the reasons for considering the use of a rule engine within an application.

The fundamental building block when using a rule engine is, not surprisingly, a rule. The rule is a unit of conditional logic, not unlike a conditional statement in most computer languages. Each rule is comprised of one or more conditions and, typically, a “conclusion”, “consequence”, and/or a set of actions to be taken if the rule is evaluated to be true.

One of the main advantages of using a rule engine is that each of the rules retains a higher level of independence than would be the case in most programming languages. The rules engine determines when to evaluate each rule, based upon the information required for that rule and the conclusions made from the evaluation of previous rules. There is no need to procedurally specify the appropriate order and dependencies of the rules.

Also, as mentioned earlier, the use of a rule engine can help ensure the separation of the business logic from the rest of the application. However, as described the earlier sections, a feedback mechanism is typically required, to transfer the business rule results back to the user interface. The use of a separate rules engine can add complexity to the integration effort.

The format and syntax for defining the rules varies based upon the rules engine being used, as do the tools available for implementing and maintaining the rules. This is another point of consideration in deciding whether the use of a rule engine is justified for a given application. The developers building the system will have to understand the operation of yet another tool, as will those who must maintain the system.

Thus, as with any other tool, the decision of whether to incorporate a rule engine into an application must be based upon the cost versus the benefit. The costs must include the learning curve for both the development and maintenance staff, and the additional effort required to develop the interface between the application and the rules engine. The benefits include the abstraction of the rules, their isolation of the rules from the rest of the application, and the ability to allow the rules engine to control the execution and evaluation of the rules.

Summary

For all but the most trivial applications, much of the complexity is due to the business logic. Implementation and maintenance is simplified by using a layered architecture, keeping the business logic separate from the user interface. Although separate, the two must interact, and that interaction can be complex. One strategy for managing that interaction, using Concept objects, was discussed.

After some background information on rules engines, there was a discussion of some of the decision criteria for evaluating the cost / benefit of incorporating a rules engine into an application.

The validation framework described in this article has been successfully implemented using the Drools object-oriented rule engine for Java. For more information visit drools.org.