Java Reference
In-Depth Information
no requirements ever change for just one service. If something happens to cause a schema
change, you could find yourself needing to rebuild, retest, and redeploy lots of services. I
know of one company with 2,500 web services. As Sponge Bob Square Pants says, good
luck with that.
▪ Maximize service flexibility and minimize interdependence. Define Customer and
Product and Invoice separately for each service. You have a contract totally customized
for each service, with no compromises. This might mean a lot of redundancy (also known
as “schema denormalization”), but it allows services to evolve independently. It also al-
lows a more fully encapsulated service. For example, if you have defined a Customer ser-
vice that is to serve as the gateway to all customer-related operations, it makes sense that
the service is the owner of the schema, and that its dependencies do not leak outside of
it. Of course, depending on the number of services you have or plan to have in your en-
terprise, this could mean a lot of redundancy. Just cross your fingers that no requirements
ever change for a core type that's defined in lots of different schemas because you will
then have a significant amount of error-prone, manual work ahead of you.
Neither of these choices is particularly attractive.
Perhaps there is a way that you can have the best of both worlds by using one of the funda-
mental principles of computer science, the layer of abstraction. You can apply it here as the
canonical data model, sometimes called the canonical schema pattern.
Defining the canonical data model
Canonicaldatamodelrefers to the practice of defining single schemas to represent types glob-
ally, and reusing those types by reference in the schemas locally designed for the service. In
the way that an enterprise service bus acts as a mediator, allowing any number of web services
to talk to one another without having to create a specific point-to-point relationship between
each one, a canonical data model allows you to define gold copy schemas for the types in your
enterprise; any service that needs to talk types can use the service bus or some like mechanism
to translate its version into the canonical version.
The canonical schema is your gold standard. It is capable of representing everything about an
entity. Every service that refers to an entity may need to customize it in some way to perform
its local work. But those differences are specific to the schema for that service, and any spe-
cific schema can always get to the canonical schema. Because the entity service schema and
the canonical schema are two distinct documents, you can maximize both freedom and reuse.
Of course, you don't want to have designed your schema as only a bunch of strings just so that
it's flexible enough to accommodate any data. Your entity service is probably going to rep-
resent a real database that requires a field to be a certain length, for example. You want your
Search WWH ::




Custom Search