Java Reference
In-Depth Information
We'll examine XML Schema through the specific lens of SOA, which demands a certain
openness and flexibility. That means, in short, keeping things fairly simple. Now, if you want
to go bananas writing super-complex polymorphic schemas, you're free to do so, but I don't
recommend it. Keeping it simple maximizes interoperability. The more sophisticated your
schema, the more you must buy into vendor- or tool-specific processing habits, which is not
a good place for an SOA programmer/architect to be. But this can seem counterintuitive to
us object-oriented programmers. For example, Martin Fowler has written about the “anemic
model” anti-pattern, which is an object containing only data and no behavior, thereby giv-
ing up one of the chief benefits of employing an object-oriented language. Coming from
an object-oriented world, your first impulse might be to attempt to use schemas to capture
everything that you can capture in a Java model. And there are tools to help you do that. You
can, for instance, find plug-ins to have JAXB generate hashcode and equals implementations
for you, which it doesn't do by default. That sounds really neat at first, and is crucial in design-
ing an object-oriented system. From a straight Java view, you want your stuff to be fully en-
capsulated, and you may think about rounding out your objects with serialVersionUID and so
forth. But within the SOA landscape, these things have little place, as they are not general.
XML Schemas are very powerful, but they are not object-oriented, and are intended to capture
a data model rather than an object model. Schemas do allow designers to create models that
can be made to look very much like objects; JAXB, for example, lets you generate Java 5 enu-
meration types, and there is a degree of polymorphism that you can achieve through schem-
as. But ultimately the whole point is that your services must be general enough that they can
communicate across languages. So I encourage you to be somewhat conservative in your ap-
proach.
Keeping your interface simple will help ensure you don't get painted into a corner later. It en-
courages you to consider your service design at the appropriate level of granularity. But there
are different ways of designing schemas that can help you or hurt you in the long run, so we'll
look at those in this chapter.
And despite the admonition to keep it simple, it is very difficult to read and debug a series
of BPEL orchestrations that invoke multiple WSDLs that import multiple schemas without a
solid understanding of namespaces and schema. XML has been with us now for more than 10
years, and its ubiquity may belie the real complexity that lurks below its simple surface.
The recipes in this chapter will provide you with practical tools for dealing with XML
Schema. But because Schema allows you to represent the same data structure in a variety of
ways, some of the recipes here also focus on design choices that will help ensure that not only
is your data model structured in a way that represents the instances you need, but in a way that
keeps your SOA flexible in the long run.
