Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schema Evolution
 In principle you are correct, but in practice this requires control over all end points, and appropriate skillsets / tools at those endpoints. This is at best hard, and for an environment such as ours (developing in Java and C#/.NET, but also Cobol, raw assembler, PL/1 ... ), well nigh impossible. This would become worse in a truly 'loosely coupled' web world, where you don't even know who is consuming your service, or how they are consuming it. Ian Guillaume Lebleu wrote: > I agree, there is no magic silver bullet. > > But there are technologies/tools that can make it easier to analyze the > impact of changes of WSDL/XML Schema on Web Service's implementation. > > Of course, the catch is to start this implementation with a language that > supports static type checking based on the XML Schema type system. XDuce, > Xstatic, Xen (Microsoft), CDuce, BXPL (Brixlogic, based on Java) are > languages that have such a feature. The same way a Java compiler warns the > user that a wrong type (i.e. not subtype) is passed/returned to/from a > method, and say which statement breaks the required type, these languages > will guarantee that the WS returns at all time an XML that matches the > output XSD, as long as an XML that matches the input XSD is sent to the WS, > and if not, will pinpoint to the statement that breaks the contract. > > Now, if you can keep the implementation, change the WSDL/XSD definition, and > re-check, you have a pretty cool way to expedite evolutions. This becomes > even more interesting in composite services, which produce services from > other services or XML data. > > Guillaume > > ----- Original Message ----- > From: "Ian Graham" <ian.graham@u...> > To: "Chiusano Joseph" <chiusano_joseph@b...> > Cc: "Andrew Wheeler" <akwheel99@h...>; <xml-dev@l...> > Sent: Tuesday, October 26, 2004 6:29 PM > Subject: Re: Schema Evolution > > > >>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@h...] >>>>Sent: Tuesday, October 26, 2004 2:12 PM >>>>To: xml-dev@l... >>>>Subject: 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> >> >>----------------------------------------------------------------- >>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> 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
