[
Lists Home |
Date Index |
Thread Index
]
Hi Fraser,
On Sat, 2006-02-11 at 19:23, Fraser Goffin wrote:
> All of this is exacerbated by a relatively weak versioning model for XML
> schema. We are giving this a lot of thought at the moment (all suggestions
> welcome :-), in combination with trying to protect our internal systems from
> the impacts of changes in the external standards (e.g. an internally managed
> canonical data model - blimey, I've lost count of the times we have tried
> things along the lines of Enterprise data Model - and failed !).
We've also spent quite a bit of time looking at various versioning
strategies for our SOA. I know that some people on the list have seen
an earlier incarnation, but in July, we released an updated rig0006
(http://sdec.reach.ie/rigs/rig0006/), which attempts to provide a
framework for versioning along with some usage guidelines and a worked
example or two. Maybe it will save you some pain... :)
The *extremely* short version (sorry, I tried to think of some other
word, but this is the 3rd time "version" came to my mind, so please just
groan and forgive--no pun intended) is:
- XML schemas are versioned using namespaces
- XML schemas use the "salami slice" model for element definition
- Backwards/forward compatible changes are possible through a defined
extension point & must-understand attribute mechanism and the concept of
a version family of schemas
- Incompatible changes to a schema resulting from structural changes,
but which are determined to still represent the same semantic concept
(e.g. incorporation of previously backward/forward compatible additions
of elements in an extension point into "first class citizens" within the
schema outside the extension point) result in a new major version number
- Incompatible changes to a schema which do not represent the same
semantic concept result in a new message type (in our case, a new
rigXXXX), and its development will follow the version rules in rig0006.
This approach allows both what we term "message types" (complete
business messages) and "data fragments" (reusable parts of a message,
e.g. the address) to be versioned independently, yet still be sensibly
resolved and processed by services performing validation.
Services adhere to the rules specified in rig0006 and can make their own
determination as to which messages they are willing to process and which
ones they reject. It also means that simultaneous support for multiple
versions of particular messages and data fragments are straightforward
to support via transformation or augmentation.
Hopefully, there's something useful for you in the above.
Cheers,
ast
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
|
