Validation with Java and XML Schema, Part 2 - JavaWorld October 2000
Tutorial Details:
Validation with Java and XML Schema, Part 2
Validation with Java and XML Schema, Part 2
By: By Brett McLaughlin
Using XML Schema for constraining Java data
ith the wealth of application development in Java today, there seems to be an API for almost everything: remote method invocation (RMI), reusable business components (EJB), manipulating XML (SAX, DOM, JDOM, JAXP), and user interfaces (Swing) as well as writing a help system (JavaHelp). Yet programmers still spend hours and even days on each project, working out validation routines. Mind you, those aren't complex business formulas but ensuring that a value is of the correct data type when submitted via an HTML form or checking the range of a shoe size. Somehow, with all the recent focus on enterprise applications, some of a programmer's core tasks have been overlooked.
Read the whole "Validation with Java and XML Schema" series:
Part 1. Learn the value of data validation and why pure Java isn't the complete solution for handling it
Part 2. Use XML Schema for constraining Java data
Part 3. Parsing XML Schema to validate data
Part 4. Build Java representations of schema constraints and apply them to Java data
In an effort to resolve that problem, at least until the powers that be come up with a robust API for validation, this series takes a detailed look at validation in Java. That isn't an explanation on using JavaScript in your HTML or expensive third-party libraries but instead on creating a simple validation framework based on existing standards. The focus is on ease of use and a simple means to add new validation rules into the data constraints without cluttering business and presentation logic with validation details.
The story so far
To get started, you should take the time to read Part 1 in the series. In that article, I looked at several existing options for validation, particularly pure Java options. Both inline validation (such as directly in a servlet or Enterprise JavaBean) as well as helper classes (such as Jason Hunter's ParameterParser class) often still resulted in code that was cluttered and that mixed validation with business and application logic. Additionally, you were left to deal with numerous try/catch blocks and throwing exceptions. It also left the unwanted problem of having to constantly recompile, even for the most minor changes in data constraints (such as changing an allowed range from between 0 and 20 to between 1 and 20).
I also discussed Java property files as a way to handle that problem. First, a small clarification: while Java does allow property files to have multiple period separated keys ( key1.key2.key3 = value ), it does not allow their use in any meaningful way. For example:
ldap.hostname = galadriel.middleearth.com
ldap.port = 389
ldap.userDN = cn=Directory Manager
ldap.password = foobar
It would seem that that sample entry in a Java properties file represents a logical grouping; all the entries start with the ldap key. However, that is not the case with standard Java APIs. That entry set is functionally equivalent to:
hostname = galadriel.middleearth.com
port = 389
userDN = cn=Directory Manager
password = foobar
In other words, there is no means to get, for example, all the keys with an ldap root. That makes using multiple-key values useful for human readability only and essentially a waste of time in actual application programming without custom or third-party libraries. So Java property files, too, are not suitable for large validation rules.
Finally, I briefly explained using XML to store validation constraints. XML Schema was addressed specifically, as it already has a mechanism to constrain an XML document that is type-safe and verbose. It allows range setting, specification of an enumeration of acceptable values, and a simple syntax. In this article, I'll delve deeper into using XML for constraining data in your Java applications, and you'll begin to write some code to put XML to work. First, I'll address your options within the XML realm.
Perusing the options
So now you know you want to use XML Schema for data constraints. So let's start talking specifics. The biggest issue you need to address is that your constraints are in one language, XML, and your data is in another, Java. So some sort of conversion must take place. Should you convert all of your data to XML, and then validate that XML against your schema? Should your XML Schema somehow be converted to Java, and those objects used to validate your data? What's the right thing to do here? Is it some mixture of the two?
Java to XML
The first option, converting Java data to XML, is actually fairly simple. With the rise in popularity of XML Data Binding, there are several frameworks available that convert, or marshal, a Java object to an XML document. One of those, which I wrote (yes, it's a shameless plug!), is discussed in detail in "Objects, Objects Everywhere" (see Resources ). A complete working package is provided for converting between Java and XML. The API is simple, lightweight, and intuitive -- all desirable qualities for your validation solution.
However, data binding is not as perfect as it may seem when you look a little deeper. First, your Java data may often come in four, five, or even more different pieces. Imagine a form that receives 15 input fields, all as separate Java objects ( String s, in this case). Each would have to be assembled into a single object, marshaled to XML, and then validated against the XML Schema. Your code, then, has to include logic for converting multiple objects into one object suitable for conversion to XML. So your once-simple solution is already getting convoluted.
Further, that option does not allow for any optimization. You can't store the XML Schema in memory in your JVM, and the only real advantage you might introduce is caching the actual XML Schema document (as a DOM or JDOM Document object, perhaps). In other words, there is no performance gain over multiple validation calls. While that might seem like icing on the cake, consider that validation, especially of form data, happens hundreds and even thousands of times per page, per day (or hour, or minute!). Caching, or some sort of performance gain, should really be expected over multiple invocations of the validation. Additionally, parsing XML is a costly operation, and even if the XML Schema document is cached, the marshalled Java object, resulting in an XML document, must be parsed at each validation call. Thus, the conversion from Java to XML doesn't seem to be such a good idea.
XML to Java
Since conversion from Java to XML doesn't seem to be a good idea, let's take a look at the flipside: converting XML to Java. In that case, your Java data would stay as is and would not need to be marshaled into XML. You would instead need to convert your XML Schema constraints into Java objects. Those objects can then take in data and return a result, indicating if the data was valid for the constraints that the object and the underlying XML Schema represented. That is a much more natural case for Java developers as well, as it allows them to stay in a Java environment.
Another advantage to that technique is that it effectively isolates XML Schema from the equation. Using schemas, then, becomes a decision tied only to the conversion from XML to Java, and not the use of the resultant Java objects at all. In other words, if the implementation of those validation classes was changed to convert an XML document (not a schema) to a validation object, the developer would still see the same interface for validation; no application code would need to change. Why is that a big deal? Well, there are two reasons. First, XML Schema is still being finalized, and minor changes may occur. Using that design ensures that you can code to the validation classes covered in that series and, even if XML Schema's specification changes and the implementation of the classes changes, your application code stays the same. Second, there is still some widespread concern over the acceptance of XML Schemas. If they did not satisfy your needs, or if they perhaps were overcomplicated for your application, you could switch to a simpler mechanism (such as simple XML documents or Relax) and still have the same code routines work.
Going back to some original concerns, that also means that your XML Schema document only has to be parsed a single time. The schema is converted to Java objects, representing constraints, and then stored in memory. Data can be validated against the objects over and over without any additional parsing ever occurring. That addresses some of the performance issues I discussed in the section on converting from Java to XML. That is even more critical when the XML Schema might be located across a network, requiring network transfer time for each parsing.
So it seems clear that conversion from XML to Java is the right way to go. Additionally, you want more than just a simple object in Java (such as one that might be produced by unmarshaling an XML Schema document to Java, as in data binding); it should take in a piece of data, and then return whether the data is valid for the constraints supplied in the XML Schema.
The game plan
With those basic design decisions in place, it's time to start outlining your classes and decide what they will look like.
Elements and attributes
The first order of business is to decide what sort of XML Schema constructs you need to support. While it might seem logical to try to support everything in the XML Schema specification, that is both an enormous task (certainly more articles than this series can bear!) as well as counterproductive. For example, the minOccurs and maxOccurs attributes, a core part of XML Schema, have no meaning in the context of validation; a value either exists or does not, and cannot appear repeatedly in that context. So already you can see that some schema constructs are not needed for your val
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Validation with Java and XML Schema, Part 2 - JavaWorld October 2000
View Tutorial: Validation with Java and XML Schema, Part 2 - JavaWorld October 2000
Related
Tutorials:
 Java security evolution
and concepts, Part 5
Java security evolution
and concepts, Part 5
|
Use XML data binding to do your
laundry
Use XML data binding to do your
laundry
|
XML documents on
the run, Part 1
XML documents on
the run, Part 1
|
Will Big Blue
eclipse the Java
tools market?
Will Big Blue
eclipse the Java
tools market?
|
Take the sting out of SAX
Take the sting out of SAX
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Jabber away with instant
messaging
Jabber away with instant
messaging
|
XML glossary
XML glossary
|
Business process
automation
made easy with
Java, Part 2
Business process
automation
made easy with
Java, Part 2
|
Sun boosts
Sun boosts enterprise Java
|
The Java Web Services Tutorial
This tutorial is a beginner\'s guide to developing Web services and Web applications using the Java Web Services Developer Pack (Java WSDP).
|
Finally, getting hands in !
Finally, getting hands in !
|
The State of JAXB: Availability, Suitability, Analysis, and Architecture
The State of JAXB: Availability, Suitability, Analysis, and Architecture
When working with XML in OO languages, there is little doubt that objects provide distinct advantages as compared to SAX, DOM, or raw XML. This process of working with XML and obj
|
JXMLPad 2.3
JXMLPad 2.3
JXMLPad is a pure Swing java component/framework for editing XML/XHTML document.
|
XML Document Validation with an XML Schema
This tutorial explains the procedure of validating an XML document with an XML schema.
|
Java validation with dynamic proxies
Decouple validation processes from your business object implementations.
|
JXMLPad 3.1 FC
JXMLPad is a pure Swing java component/framework for editing XML/XHTML document.
|
Generating an XML Document with JAXB
In this tutorial, JAXB is used to generate Java classes from an XML Schema. An example XML document shall be created from the Java classes.
|
Jakarta Struts Interview Questions
Jakarta Struts Interview Questions
Jakarta Struts Interview Questions
Q: What is Jakarta Struts Framework?
A: Jakarta Struts is open source implementation of MVC (Model-View-Controller) pattern for the development of web based applications.
|
Struts Validator Framework Tutorial with Example
Struts Validator Framework Tutorial with Example
Struts HTML Tags
Struts Validator Framework
This lesson introduces you the Struts Validator Framework. In this lesson you will learn how to use Struts Validator Framework to validate the user
|
|
|
|
