Technical CDM model considerations

There were probably already hundreds of discussions about versioning XML schemas and WSDL documents. This Blog considers the strategy described in Thomas Erl's "Web Service Contract Design and Versioning for SOA".
How would you use these practices within a CDM? This Blog considers some options you have when developing XML Schemas out of you logical CDM.
Consider a small CDM in which the following model is used.

LegalEntity <-- NaturalPerson <-- Employee
                  <-- NonNaturalPerson


For these entities you have some possibilities to use namespaces:
1) A group of Entities share the same namespace
Example: http://www.blog/organisation/v1

2) Each Entity gets its own namespace

The advantages of option 1 are
  • Only 1 namespace needed, namespaces are hell as we all know
  • The entities belong together so this seems logical
The disadvantages
  • The CDM entities are used within Service Contracts (WSDL) and when the version of the namespace changes all Services that use one of these Entities is changed. In fact all Service Consumers have to be adapted.
  • When schema elements are "qualified" all data transformations (XSLT and XQueries) have to be changed, because these use the same namespace within the XPath constructions.
So this option leads to a lot of rework when the major version changes.

Lets consider option1 in which each Entity gets its own namespace.
In this case the disadvantages are
  • You will get a lot of namespaces.
But the advantages are
  • When one Entity changes its namespace only those Services that use this Entity changes.
  • Not all data transformations have to be changed, only those that use this Entity.
  • Better governance on the Entities.
Separate XSD files
As also described as a SOA pattern by Thomas Erl, it is best practice to have each Entity within a separate XSD file.
  • Better reuse of Entities
  • Better governance of the Entities
So you have LegalEntity_v1.xsd and NaturalPerson_v1.xsd files.

Entity inheritance relations
As described by the logical model LegalEntity is a base of NaturalPerson.
You have the possiblity to design this as an xml:extension.

When you have an InternalEmployee and ExternalEmployee Entity how would you consider a Service in which an Employee is needed as input. You could consider to use the xml:choice construct within the message (1). Or you could define two different operations: AddInternalEmployee and AddExternalEmployee (2).

The disadvantage of option (1) is that within your Service (or on the ESB) you will have if-constructions to check with which kind of Employee you are dealing with.

This Blog described some options you have when dealing with the technical CDM.
Please leave you comments on how you are dealing with it...

No comments:

Post a Comment