Spring Declarative Rules-based Validation

Authors

Keith Donald

Spring 1.1 will introduce declarative validation to enhance upon and compliment the existing validation support found in today's org.springframwork.validation package.

What is it?

Rules-based data validation is about validating the syntax and semantics of your business objects using rules. "Declarative" simply means you declare what the rules are, either programatically using our API or externally through some configuration source (xml, metadata, groovy), and the system is responsible for enforcing those rules and reporting descriptive validation results at runtime automatically. To tweak new rules, you simply go to once place and edit configuration information.

Why are you doing this?

Our survey of currently available, open-source rules-based validators leaves us "wanting more". Specifically:

• We want a framework that focuses on validating business objects, not one that is coupled with the presentation tier or any view, form, or controller technology.

• We want a framework that makes it easy to define new rules, and makes rules top-level-objects that can be reused in other contexts (and are not tightly coupled with the framework.)

• We want a framework which supports expressions using relational operators (<,>,<=,>=,==,!), logical operators (and/or), and conditionals to allow for the creation of semantic business rules in addition to simple syntax checks.

• We want a framework that is capable of reporting rich, internationalized validation results on rule evaluation.

• We want a framework that is capable of generating typing hints and other visual indicators for rules that constrain bean property values to enhance an application's usability and overall user experience.

• And for the Swing crowd, we want something that works just as well in a web-app environment as it does in a rich-client environment.

What are the design goals?

• The design should make it extremely easy to define new rules and integrate those rules into the rest of the framework.
  • To facilitate this, the design should decouple rule evaluation from results reporting.
• The design should cleary decouple the validation of values from how those values are retrieved. This allows the value checks to be more easily reused.
  • For example, the act of retrieving a bean property value should be decoupled from taking that value and testing it against one or more constraints. The constraints should have no knowledge of how the value was obtained.
• The design should provide pluggable rules sources. Initially we plan to support programatically defined sources and commons-attributes sources, but others such as xml-based or scripting based should be possible.
• The design should leverage Spring's existing infrastructure where appropriate and should in general not re-invent the wheel.
• The framework should provide a library of out-of-the-box rules and regularly integrate back community contributions over time.