Skip to main content

Form Validation in an SOA context

Posted by johnreynolds on December 3, 2005 at 9:04 AM PST

This blog continues the classic client-side versus server-side validation discussion, but now adds another layer - web service "side" validation. How can you share validation logic across client-side JavaScript, Java within the web application, and Java within underlying web services?

Validation of user input has always been an important aspect of user interface programming. You have to make sure that the values a user provides to your program are of the right type, in the right range, etc. and you should provide meaningful feedback to help users correct any errors.

I have often blogged my opinion that validation rules are business logic, and that they should not reside in the presentation layer. The presentation layer may apply validation rules, but developers should not have to modify presentation layer code (including JSPs) when validation rules change.

Please note that when I use the terms “validation rules” or “validation logic”, I am incorporate all of the following:

  • Field level validation: rules applied to a field based solely on the contents of that field
  • Form level validation: rules applied to fields of a form based on the contents of other fields on the form
  • Application level validation: rules applied to fields of a form based on data that is external to the form

I am now embarking on an SOA migration effort, and that has raised new questions about the care, feeding and delivery of validation logic within an enterprise (and to external partners).

Assume that you craft a business service called ProcessLoanApplication. This is a coarse-grained service that provides a few service methods to achieve a specific business goal, and the service involves the exchange of large document-oriented parameters.

ProcessLoanApplication is designed for B2B integration with an external partner. Our assumption is that a “LoanApplication” document is generated by the partner’s systems, and transmitted to ProcessLoanApplication when complete. Obviously, we’re going to have to apply our validation rules to the incoming documents, and we will have to provide document-oriented feedback if any rules are violated.

So far so good, but now assume that that our own company wants to provide a browser-based application that allows users to create “LoanApplications” and submit them for processing (via the ProcessLoanApplication service).

Using an IDE such as Java Studio Creator, it is fairly straight-forward to create a browser-based application to front-end a web service. We can easily configure JSF controls to gather the necessary input data, prepare an appropriate document, and invoke the ProcessLoanApplication service. If ProcessLoanApplication detects any errors, they will be returned in a document to the JSF application. The response can then be parsed and we can display appropriate error messages to the user.

If you are not already shaking your head at this description, then you probably have not done much user-interface development. It is generally considered as “bad form” to defer all input validation until after a form is submitted. The consensus view is that you should detect invalid input data as soon as possible and prompt the user to correct the mistake.

Assuming that we want to provide timely feedback to the user, and that we don’t want to duplicate input validation logic in our JSF application, we will need a service interface to apply (or obtain a copy of) the validation rules that are used by the ProcessLoanApplication service.

The need to obtain a copy of our validation rules becomes more apparent if we also encounter an external partner that wants to apply our rules to their documents prior to invoking the ProcessLoanApplication service. Within our own enterprise, invoking a validation service as the user inputs data works fairly well (sort of an AJAX approach), but constraining 3rd parties to operate in that manner may not be acceptable (for example, they may want to minimizes transmissions through their own firewall).

This is one of those cases where I really do not want to roll-our-own solution. I want proven tools and templates to insure that the business oriented tasks (writing business logic, writing validation rules, defining workflow, etc.) do not get intertwined with infrastructure development and configuration. I know that all of the pieces of the puzzle exist, but I am still looking for a holistic solution that addresses the client, the web application, and the web service.

Are there widely-used blueprints, best-practices, frameworks or products that address the scenarios that I have outlined in this blog? Are there de-facto standards for creating validation services that are intended for use both by coarse-grained web services, and by JSF-centric web applications? Are there de-facto standards for exchanging validation rules with external partners (particularly application level validation rules)?

If you have any suggestions (besides changing careers) I would love to hear them.

Comments

Infrastructure stubs

The only way out I see by now is to use model driven tools that will generate all infrastructure code for you. There are quite decent out-of-the-box tool chains which implement true or alike MDD paradigm, or if none of these fit your needs you can either use DSM tools like Jetbrains MPS (AST builder + velocity/freemarker), Eclipse xText/EMF or create your own customized solution.