Java Reference
In-Depth Information
▪ Design schemas separately from service design.
▪ Apply enterprise standards to all schema design, and closely guard the governance sur-
rounding the canonical model. Do not attempt to centralize core business entity types such
as Customer or Invoice unless you have a governance structure in place to manage schema
changes.
▪ Keep canonical schemas in an enterprise repository. You can make this an LDAP server,
or a web server to start if you're on a budget. You can graduate to document control soft-
ware or, ideally, an SOA-specific product that accounts for all of your SOA artifacts. The
schemas should be available at runtime on a network.
▪ Consider defining certain “fundamental” types that are centrally used in their own
namespace, and in their own schema. For example, a U.S. phone number, a Social Security
number, or other data structures that are not defined by your business make fine candid-
ates for centralized types that are reused throughout many schemas.
▪ Do not require your canonical schemas to be a frontend to any database. They exist to
define concepts and act as ideal mediators.
▪ Pattern restrictions are better to use in service schemas than canonical schemas. They can
play an important role in validation.
▪ Avoid using certain advanced schema constructs such as polymporphism, choice, or uni-
ons. These will seriously damage interoperability. The tool support for generated code on
many platforms is either non-existent or poor at best.
Be strict with yourself regarding the point about fundamental types, and do not allow yourself
a wide definition of them. For example, while an address seems like something that is defined
by the post office and is not specific to your business, this is not generally the case in actual
practice. A new shipping service may need a different degree of granularity or type restriction
from what your point of sale has used for the last 20 years. It is a non-trivial undertaking to
get all of that legacy data into compliance just so you can define a single address type that
both systems use, with little profit potential for the business.
In this topic, I advocate starting from the data model and using that to compose the idea of the
service contract as a facilitator of document exchange. Delay writing code as long as possible.
After the schemas are clear, the contract can fall out from it, and both can be refined in an
iterative process. Then you can generate Java code for your services to use, or give them to
developers to implement. This helps ensure that you are not tightly bound to an implementa-
tion because it mimics what your clients will have to do.
Of course, you are now bound between your schema and your Java code, and a schema change
requires new code generation. But there are two points here: any schema change means per
