Schema Value Object

原创 2001年09月19日 12:50:00
Schema Value Object


Olivier Brand (


Value Objects must include validation code in order to optimize network traffic and XML features for B2B exchanges.


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.


     The validation of a Value Object is done early on, avoiding Network overheads (similar to the role of Javascript for form validation in web
     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


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):


I highly encourage you to look at 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.


     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)


     SUN patterns:
     GoF Patterns:
     Castor XML:
2 replies in this thread Reply
Read more Schema Value Object threadcorner.gif
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 Reply
Read more Schema Value Object - Options threadcorner.gif
Posted By: Earl Bingham on August 31, 2001 in response to this message.

At there is a project called jvalid that was started last year that does validation with XML Schemas.

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.

I have started a project in to build some J2EE components that can be re-used that leverage the Schematron Stylesheet.

什么是ValueObject (VO 模式)

简单说,ValueObject的值(状态)一旦创建以后就不会改变了。所以可以当基本数据类型用。比如Java中的String, BigDecimal, BigInteger都是ValueObject。S...
  • dac55300424
  • dac55300424
  • 2013年12月24日 17:54
  • 2089

iOS知识小集 第三期 (2015.06.30)

Swift2出来了,还是得与时俱进啊,不然就成老古董了。再者它开源了,又有事情要做了。当个程序猿真是累啊,一直在追,可从来没追上,刚有那么点念想了,人家又踩了脚油门。 一个月又要过去了,说好的一月两...
  • bluewindaa
  • bluewindaa
  • 2015年07月28日 15:24
  • 700


14.4 管理OpenLDAP 启动OpenLDAP服务器程序之后,接下来的操作就是通过客户端程序对目录进行操作,包括添加、修改、删除和搜索数据等操作。能对LDAP进行操作的客户端程序很多,本节简单...
  • baidu_18607183
  • baidu_18607183
  • 2016年04月05日 11:33
  • 807

【设计优化】- 正确使用 Value Object 模式

为了解决这个问题,就可以使用 Value Object 模式。这种模式提倡将一个对象的各个属性进行封装,将封装后的对象在网络中传播,从而使系统拥有更好的交互模型,并且减少网络通信数据,从而提高系统性能...
  • zq602316498
  • zq602316498
  • 2014年09月03日 01:09
  • 2407


  • u013737399
  • u013737399
  • 2016年10月11日 21:47
  • 772

【数据库~】SQL Server中Schema(架构)概念理解

前段时间,重新拿起数据库的教材(《数据库系统概论》王珊等著,高等教育出版社)温习,一年以前学的知识不用还真是忘了【SQL啊哦~】SQL Server中Schema(架构)概念理解 3.3.1...
  • u010376274
  • u010376274
  • 2014年08月19日 22:36
  • 2006


  • fengyinchao
  • fengyinchao
  • 2016年03月03日 22:36
  • 7045


这些都出自极光推送的官方文档上 名词: 1. 别名alias:标识应用程序用户,一...
  • u013929312
  • u013929312
  • 2014年11月06日 22:27
  • 3002

设计模式之Value Object模式

  • angel_babys
  • angel_babys
  • 2016年03月24日 15:02
  • 168

java 对象转换为Map key-value形式

package com.newsoft.datacpl.util;import java.lang.reflect.Field; import java.lang.reflect.Method; im...
  • u012151597
  • u012151597
  • 2017年03月29日 14:37
  • 1727
您举报文章:Schema Value Object