Java Reference
In-Depth Information
force a contract change; they're part of the contract. So regeneration is the least of your prob-
lems. Generation should be part of your build. Don't commit generated objects to a reposit-
ory, and don't grow to rely on implementation-specific features in your services. Starting from
Java can tempt you with generics and other unnecessary language features that don't have a
place in a service contract.
There's no silver bullet here, so don't get too hung up—you are going to have some redund-
ancy or some coupling. Pick your poison and prefer a redundancy over a coupling. You can't
know exactly how requirements and business relationships will evolve and change over time.
Updating the canonical data model
Canonical schema is a weird beast. Some SOA practitioners call it an anti-pattern, which is
good to be aware of. But many others refer to it not only as a pattern in the positive sense
but as one of the most important fundamental aspects of creating a solid SOA. Architects I've
spoken with indicate that one of the first things they do when embarking on an SOA journey
is define their canonical data model up-front. This is ontology and taxonomy work.
The canonical data model shouldn't be an anti-pattern if you do lots of analysis and clarific-
ation of the concepts. Make sure that you are including everything that an entity might need
to be in your enterprise, and keep it general enough to account for this. Use a schema pattern
that allows flexibility in your design.
Then, as you define your entity services, define a schema local to the service. Reuse types
from the canonical model as much as possible, via import.
Any changes to the canonical model must go through SOA governance, and they must be rare.
Services represent business entities. These things don't change every day. You will need to
make changes to the canonical model eventually. But then you can version those schemas ex-
plicitly, and if you indicate the version in the namespace, you will not have to change all of the
services at once. Create a new version of the schema, indicate the version in the namespace,
and then you are free to change only the service that you want to change to use the new version
of the canonical model. Update remaining services as you have time, but be sure to do it soon.
If you have more than two versions of the canonical schema, it isn't canonical anymore: it's
just another messy layer on what is sure to be a doomed SOA. Govern this process, and you'll
be fine.
See Also
