[
Lists Home |
Date Index |
Thread Index
]
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@utoronto.ca>
To: "Chiusano Joseph" <chiusano_joseph@bah.com>
Cc: "Andrew Wheeler" <akwheel99@hotmail.com>; <xml-dev@lists.xml.org>
Sent: Tuesday, October 26, 2004 6:29 PM
Subject: Re: [xml-dev] 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@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>
>
> -----------------------------------------------------------------
> 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>
|
