[
Lists Home |
Date Index |
Thread Index
]
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@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>
>
>
>
> -----------------------------------------------------------------
> 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>
|
