Schema Value Object
Author
Olivier Brand (obrand@yahoo.com)
08/23/2001
Context
Value Objects must include validation code in order to optimize network traffic and XML features for B2B exchanges.
Problems
While implementing a three tier application using J2EE Core Patterns, a usual design will involve at least some Value Objects, some Session Facades, a few
Entity Beans and Data Access Objects for the underlying persistence logic.
A Value Object is the representation of a business data. Therefore it contains attributes and associated business methods.
A Value Object can be initialized by the Enterprise Java Bean layer (in the case of reads) or by the Client (in the case of creations or updates).
Usually the Value Object does not need to be validated when being created in the Enterprise layer since we assume that the data has already been
constrained by the persistent store.
A problem occurs when creating or updating these Value Objects (mutable Value Objects) in the Client layer.
For instance an attribute representing the email address of a customer in the Value Object can be tied to a specific column in a database with additional
constraints such as the length of the column and its format following a specific pattern (regular expression driven, ...).
Now the developer needs to make a decision where to add the validation code on this field.
The most common solution is to rely on the underlying datastore which will reject the insert or update if a field does not conform to a specific constraint.
The problem of relying on the datastore to check the data constraints is expensive in term of network overhead.
Another problem is that the implementation is more complex since the eventual thrown exceptions need to traverse multiple layers and be interpreted by the
client layer.
B2B data exchange must be realized through the HTTP protocol to overcome firewall restrictions. Standards such as SOAP, eBxml, ... are already defined.
Multiple implementations of these standards allow to wrap Enterprise Beans in a Web Service. Since the Enterprise Bean layer plays the role of a Value
Object Factory, the reulting data needs to be transformed at one point as XML to be encapsulated into SOAP or eBxml packets.
Forces
The validation of a Value Object is done early on, avoiding Network overheads (similar to the role of Javascript for form validation in web
applications)
Simplify the three tier layer in term of exception handling
Can rely on W3C specifications such as XML Schemas (or DTDs) for documenting and generating (see solution) data constraints.
XML aware Value Objects can be easily included in B2B exchanges
Solution
Use an existing XML framework to express data constraints and automate the process to unmarshal XML documents to Java Objects and to
marshal Java Objects to XML documents.
There are many XML frameworks available. Some are relying on DTDs, others are relying on the newest XML Schema (aka XSD) specifications.
I chose to rely on the XML Schema specification in order to express the Value Object constraints.XML Schemas are defined in XML (as opposed to
DTDs), therefore can be created using any XML aware tools, documentation can also be generated using XSL transforms (output HTML, ....).
XML Schemas are "object oriented friendly" since they allow for complex types creation and extension.
The framework of choice used for implementing this pattern is Castor from Exolab. This framework is on its way to support the final W3C specification, but
it showed in any projects that its Schema support is enough for implementing this pattern. This framework is also Open Source.
The main idea is to write an XML schema corresponding to the structure of the final Value Object (in term of attributes and types), and add the constraints
as defined in the database (length, format, .....). Some constraints such as uniqueness cannot be expressed, but typically, you want the underlying database to
reject the record if such constraint is violated.
Then you can use the Castor source generator class to generate the Java classes associated with the XSD Schema. Each complex type is sually defined as a
Class. Each element, attributes are defined as properties (class variable) and corresponding setter/getter methods are automatically generated.
Relying on a source generator prevents coding complex validation rules in a language that cannot be understand by non Java developers. For instance a
Database modeler and an Architect (or Senior Developer) can be involved early on in order to define those schemas. This will be the starting point for the
DDL and the Schema Value Objects generations. This is a nice approach to bring 2 different teams together on a design and implementation phases.
Then the Schema Value Objects need to be created. At this stage there are 2 possible choices:
The Schema Value Object extends the generated Java class from the XSD schema.
The Schema Value Object encapsulates (wraps) the generated Java class from the XSD schema.
I prefer the second solution for 2 reasons:
The Castor framework (or any other Schema aware framework generators) defines new types which correspond to the richer XSD Schema definition
(compared to Java types). Therefore, you might want to hide these "proprietary" classes allowing later on (if needed) to replace the Java Schema
generator with another one (for instance, when Javasoft will provide a Schema module for its JAXB framework).
You might want to validate field by field (when each setter is being called) and add some dirty flag support in the same methods. Wrapping the
generated setters with your own setters make then more sense.
When generating the Java classes from the XSD Schema using Castor, special classes called Descriptors are created.
These classes are handling the validation part (the constraints defined in the XML Schema are showing in this classes).
Do we want to validate field by field or the entire document ? Once again this is an implementationd ecision mostly driven by the client's implementation.
In my implementations, we decided to validate field by field (the validation is done in each setters).
To perform a field level validation, the Castor XML API offers a class to perform validation at the field level (as opposed as the entire document):
FieldValidator.
I highly encourage you to look at castor.exolab.org in order to get familiar with the possibility of the product.
The second part of the pattern is trivial since any Schema (or DTDs) aware code generator, Castor included, include marshaling and unmarshaling facilities.
These methods allow to transform Java to XML and XML to Java.
Castor offers 2 classes to perform such transformations: Marshaller and Unmarshaller.
The Marshaller class can transform a Java object to XML. Some methods allow to marshal the object directly in a W3X DOM Node object.
This method is highly optimized when dealing with SOAP where you want to include a fragment (therefore the generated Node) in a SOAP enveloppe.
This method is also preffered when dealing with XSL (in frameworks like Apache Cocoon, ....) since the DOM tree is already built.
This method also works with the W3C SAX API.
The Unmarshaller class can transform any XML sources to the Castor generated Java object.
One of my projects included this pattern and was successfully implemented using the Apache SOAP framework with a WSDL extension we had to write.
WSDL is an XML document containing the definition of the operations exposed as web services. Any complex types are referred to an XML Schema.
This is one of the reason why this pattern perfectly applies to B2B exchanges by bringing the J2EE and B2B worlds together.
Consequences
Takes advantage of the Value Object pattern
Therefore it reduces network traffic.
Uses W3C standards to express data constraints
Schemas or DTDs can be understood by non java developper and is the common ground for B2B exchanges (see WSDL, SOAP, UDDI, ...)
Allows for automated code generation
Once the XSD Schema written, a Java Binding framework like Castor, can be used to generate the Java classes.
Includes an XML framework to serialize/deserialize Java object to and from XML.
This fits perfectly in the Web Services world. This can also be used in Web Applications driven by JSPs and XSLT processing.
Related patterns
Value Object (Sun)
Proxy (GoF)
Links
SUN patterns: http://developer.java.sun.com/developer/restricted/patterns
GoF Patterns: http://www.hillside.net/patterns/DPBook/DPBook.html
Castor XML: http://castor.exolab.org
2 replies in this thread
Posted By: Olivier Brand on August 25, 2001 in response to this message.
This pattern could (and should) be renamed: Schema Data Object.
This approach applies to a lot of scenarios and schemas are a good complement to add constraints to languages.
The Value Object could be one implementation of this pattern.
0 replies in this thread
Posted By: Earl Bingham on August 31, 2001 in response to this message.
At sourceforge.net there is a project called jvalid that was started last year that does validation with XML Schemas.
http://sourceforge.net/projects/jvalid/
Also, there is a XSLT Stylesheet called Schematron that is designed to allow validation of XML Documents to be done with a definition of the validation in XML.
http://www.ascc.net/xml/resource/schematron/schematron.html
I have started a project in sourceforge.net to build some J2EE components that can be re-used that leverage the Schematron Stylesheet.
