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
Namespaces
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
Example:
http://www.blog/organisation/legalentity/v1
http://www.blog/organisation/naturalperson/v1
The advantages of option 1 are
Lets consider option1 in which each Entity gets its own namespace.
In this case the disadvantages are
As also described as a SOA pattern by Thomas Erl, it is best practice to have each Entity within a separate XSD file.
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...
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
Namespaces
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
Example:
http://www.blog/organisation/legalentity/v1
http://www.blog/organisation/naturalperson/v1
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 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.
Lets consider option1 in which each Entity gets its own namespace.
In this case the disadvantages are
- You will get a lot of namespaces.
- 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.
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
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...
Reacties
Een reactie posten