[
Lists Home |
Date Index |
Thread Index
]
Ian,
I suppose the harsh realities of life impact on the ideal .... there’s no
silver bullet. We would like components to understand any version
(backwards, forwards or non-backwards compatible), but the reality seems
like we won’t be able to guarantee they can understand what they get. I
guess I always knew this, just wondered what strategies people had adopted
in order to reduce the cost of change.
Cheers.
---
Andrew
>From: Ian Graham <ian.graham@utoronto.ca>
>To: Chiusano Joseph <chiusano_joseph@bah.com>
>CC: Andrew Wheeler <akwheel99@hotmail.com>, xml-dev@lists.xml.org
>Subject: Re: [xml-dev] Schema Evolution
>Date: Tue, 26 Oct 2004 21:29:13 -0400
>
>My own experience, on a large enterprise Web services project, is that
>elegant schema / WSDL evolution is not possible. There is simply no way to
>constrain the schema changes such that all existing applications are
>guaranteed to work with the new versions. So we will create new services
>(and keep the old) if anything needs to change. We hope that governance
>will help limit/control this revving process.
>
>The situation is likely similar for other environments -- if you want to
>guarantee that all previous apps dependent on the schema work, then you
>can't change it.
>
>If you think a schema change is idiot proof, you likely just haven't found
>a suitably qualified idiot :-(
>
>Ian
>
>Chiusano Joseph wrote:
>>>-----Original Message-----
>>>From: Andrew Wheeler [mailto:akwheel99@hotmail.com] Sent: Tuesday,
>>>October 26, 2004 2:12 PM
>>>To: xml-dev@lists.xml.org
>>>Subject: [xml-dev] Schema Evolution
>>>
>>>Hello All,
>>>
>>>I have an open-ended question which I don't expect a definitive answer
>>>to, nor solutions, but your experiences or pointers to useful information
>>>would be invaluable.
>>>
>>>How do enterprise architectures expect to cope with "Schema evolution"?
>>
>>
>>Sorry for my pickiness here: I'm not certain how you are using the term
>>"enterprise architecture here", but I do not believe that this very
>>important issue is related to an enterprise architecture in the
>>traditional sense of the term enterprise architecture. One may have an
>>*application* that is used to support the requirements described below,
>>that would be mapped to the Application Layer of an enterprise
>>architecture.
>>
>>In terms of SOA - that is, if the schema defines the payload of a
>>message that is associated with a service - this could be accomplished
>>through a governance body and their associated policies and procedures.
>>
>>Kind Regards,
>>Joe Chiusano
>>Booz Allen Hamilton
>>Strategy and Technology Consultants to the World
>>
>>
>>>I know this is a very generic question and doesn't just apply to XML
>>>Schema's (nor enterprise architectures) . I've read a number of papers
>>>that have been referenced here on XML-Dev ([1], [2], [3], [4], [5]) but
>>>would like more information in order for me to understand potential
>>>solutions. Having read the papers I feel they discuss extensibility as
>>>oppose to versioning (I might be wrong as it's just a feeling). One can
>>>think about extensibility as a bilateral agreement between a single
>>>producer and a single consumer where as versioning has enterprise wide
>>>implications, you've no idea who might be consuming. (I have no real
>>>experience on this scale of coping with such an issue, nor do most people
>>>by the sounds of it).
>>>
>>>Just to amplify the problem ... Each change cycle we release a version of
>>>a
>>>language** with new capabilities, rectifying earlier errors, etc. We do
>>>not, nor believe we can, guarantee backwards compatibility between
>>>versions. Therefore our enterprise contains mixed, non-backwards
>>>compatible versions. We have versioning and extensibility issues,
>>>controlled evolution through versioning, uncontrolled user defined
>>>evolution through extensibility. For the moment, due to particular
>>>circumstances, we are able to cope with change but the future will be
>>>somewhat different (as take up of the language grows within the maturing
>>>enterprise).
>>>
>>>Sorry for the waffle and sorry if this has been asked a thousand times
>>>before. Many thanks in advance.
>>>
>>>Andrew
>>>
>>>It's like trying to arrange deckchairs on the Titanic.
>>>
>>>[1] XML Schema Libraries and versioning: The UBL case.
>>>http://www.idealliance.org/papers/dx_xmle03/papers/03-04-03/03
>>>-04-03.pdf
>>>[2] Versioning XML Vocabularies.
>>>http://www.xml.com/pub/a/2003/12/03/versioning.html
>>>[3] Providing Compatible Schema Evolution.
>>>http://www.pacificspirit.com/Authoring/Compatibility/Providing
>>>CompatibleSchemaEvolution.html
>>>[4] Designing Extensible, Versionable XML Formats.
>>>http://www.xml.com/lpt/a/2004/07/21/design.html
>>>[5] Reach Interoperability Guidelines (RIGs).
>>>http://sdec.reach.ie/rigs/rig0006/pdf/rig0006_v0_3.pdf
>>>
>>>
>>>** The model we have is actually defined in UML (pure UML - not a marked
>>>up XML version) for which we automatically generate an XSD. We have fine
>>>granularity of configuration control in the logical UML model, but as yet
>>>do not take advantage of this in the physical XML model. We have looked
>>>at using namespaces (or hard coded attributes) within the physical XML
>>>schema to indicate version granularity but are looking for experience to
>>>guide us. To give you an idea of scale the auto generation creates 1100
>>>complex types and 250 simple types, which knit together 2100 distinct
>>>elements and 60 distinct attributes We know the scale won't necessarily
>>>dictate the strategy we choose.
>>>
>>>_________________________________________________________________
>>>Express yourself with cool new emoticons
>>>http://www.msn.co.uk/specials/myemo
>>>
>>>
>>>-----------------------------------------------------------------
>>>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>>>initiative of OASIS <http://www.oasis-open.org>
>>>
>>>The list archives are at http://lists.xml.org/archives/xml-dev/
>>>
>>>To subscribe or unsubscribe from this list use the subscription
>>>manager: <http://www.oasis-open.org/mlmanage/index.php>
>>>
>>>
>>
>>-----------------------------------------------------------------
>>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>>initiative of OASIS <http://www.oasis-open.org>
>>
>>The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>>To subscribe or unsubscribe from this list use the subscription
>>manager: <http://www.oasis-open.org/mlmanage/index.php>
>>
>
>--
>Ian Graham
>H: 416.769.2422 / W: 416.513.5656 / E: <ian . graham AT utoronto . ca>
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
|
