Table of contents:
JSR 303 (Bean validation) is making its way into being approved by the Java Community Process. The goal of this series of post is to give you a quick introduction about this specification.What is the problem with validations?
This specification, citing the official JSR 303 Request, tries to solve a common problem. Validations are commons steps executed during the business logic of the application, although often the validations algorithm are a characteristic of the data structure being validated, rather than the bussiness logic flow they're executed within. That's why validations aren't tier dependent operations and validation algorithms might span almost all of the tiers into your system, from the front end down to the backend. Reimplementing or redistributing the same validation classes to all of the applications layers and components is error prone and adds a complexity you must deal with. Bundling validation into the data structure being validated, on the other side, generate couplings and clutters the affected types with algorithms and structures which are not part of the class.
How does this specification solve this problem?
This specification tries to solve this problem recognizing the fundamental flaw we often encounter in validation implementations inside enterprise applications:
- The process of validating data is part of the business logic of an application.
- The logic executed during the validation process might not be part of the business logic. Rather, it's a characteristic of the data structure itself.
- Hence, validations should be considered metadata of a class and...
- ... validations should be orthogonal to both business logic and tiers in the applications.
- Validation logic may change over time.
- Being an API specification, validation frameworks should be pluggable and interchangeable.
The solution boils down to recognizing that validation is a process that must be driven by class metadata. By providing a sufficiently flexible metadata model and a validation API, the specification defines how to associate validation metadata to a class either by using Java annotations or XML descriptors.
The proposed solution only leverages the JavaBeans object model: therefore, it can be used in whichever application tier without being tied to a specific programming model. Furthermore, this API is suitable to be used as a component of other APIs thus enabling JSR 303 bean validation into, for example, the persistence layer (with JPA), the bussines layer (with EJBs), and so forth.
Why do you need this spec?
I would restate this with a more general question: do you need specs? This blog post isn't about why standards (and specs) are good. While designing and implementing there aren't just standards and specs. There are algorithms (your business logic is not a standard, it's just as unique as your fingerprint), patterns, best practices and unique application requirements. There's common sense, too (sometimes). The value of standards and specs is the value of having a standard solution to a well stated class of problems. If it fits your requirements, it's generally good: someone else, probably more skilled than you in that particular field, would have produced an implementation you can just take and use.
Being the JSR 303 a service provider standard (also) sort of guarantees you that you may choose the implementation that works best for you and that integrates best with the environment you have. There won't only Hibernate Validator after this specification is approved. It's very likely you could choose between a bunch of implementations which, because of this spec's characteristics, will fit into the other frameworks and APIs you use, such as EJB, JPA, JSF, Bean Bindings, put-your-favorite-here. Indeed, the JSR 303 will be required by JSR 316: the upcoming Java Enterprise Edition version 6.
The lack of a standard validation API, or even well established validation patterns, had as an effect that many application reinvented a validation framework: this process usually starts providing a solution to the first identified requirements, which seem too few or simple to require another validation framework, and then, as development proceeds, starts to grow according to the new requirements. There you ends with your own validation framework which, I bet most of the case, will not be a state-of-the-art, encapsulated and reusable solution. If the validation framework isn't carefully designed, you usually end up polluting your application layers and even pollution your class definition, to avoid the deployment problems cited above.
One thing more about specifications
One thing more about specifications. Although we should, I think many of us Java architects and programmers don't usually dive into a specification. At most, we know that it exist and then rely on the capabilites of the framework-of-the-day. Either under pressure, or because of a lack in the design of our application, or because we're struggling to get the job done and Google seems the saviour, or simply because the human being is lazy, not only may we end up reinventing the wheel: we may end up copy-and-pasting the wheel.
That's the fundamental flaw.
Specifications are there because groups of experts recognized a problem (usually before we do), study it and provide a general solution to it. Either in form of APIs, programming models and sometimes with even more complex technological solutions (such as EJB containers). It's up to you, Java architects, analysts and programmers, recognize if your problems belongs to such a class, evaluate the viability of using a standard and evantually choosing an implementation. Also, don't be blind in the name of a specification. Solutions require a problem to exist and it might also be the case that your problem doesn't perfectly fit in and that a simpler solution will satisfy your requirements. It's up to you deciding if ignoring a standard solution is an advantage for the design and the overall cost of your application.
These are just examples and speculations but that's the kind of choice an architect must do. Nevertheless, as far as it concerns this specification, I'm pretty confident that its flexibility will make the JSR 303 a common guest in our Java enterprise applications.
No comments:
Post a Comment