Hi Derek,
I used the xsd:any element for some time. The problem is that it create
a lot of problems parsing the xml. Additionally it adds an unnatural
element to the data types that makes your schemas more difficult to read.
Then I remembered an early principle of the internet. Be strict in what
you send, be open in what you expect. So for services this means when
sending out always make sure you follow the schema of the service version
you implement. When receiving a message try to process it even if it is
not completely correct.
So in the end I went with the easiest way to simply not use validation.
You have to write a set of tests for your services anyway as validation
can not find a big part of the errors. Without validation many of the
problems simply go away.
For example if you have a new element in a type and a newer sender sends
it to an old service provider then cxf will just ignore the unknown
element on the receiver side. So if the rest of the data still forms a
usable request in the old schema then he old impl can simply process it.
So by using this you can make many seemly incompatible changes compatible.
Christian
Am 24.08.2011 23:01, schrieb dstainer:
I know this topic has been broached in various forms over the years. However,
I'd like to compare notes with other folks that have implemented SOAP web
service versioning schemes, see if anything has changed from the earlier
discussions on the topic.
I've read through a number of different resources [1][2][3][4], and I'm
curious to hear about other people's experiences with this topic.
Specifically, I'm curious about the following:
- Code first vs. Contract first and why within the context of versioning
- Use of versioned namespaces to separate operations per [1] recommendations
- How did you design for forward compatibility i.e. use of
<xsd:any>/@XmlAnyElement
- How did you design for backwards compatibility i.e. optional elements
- Did you use strict/flexible/loose versioning [2]
- Any testing of backwards compatibility between minor versions
- How did CXF help/hinder your ability to carry out versioning of services
In addition, to those questions I'm also curious to hear about more general
thoughts on the topic. What worked well and what didn't? Any big gotchas or
lifesavers that I should be aware of?
Thanks
Derek
References
[1] - http://blogs.iona.com/sos/20070410-WSDL-Versioning-Best-Practise.pdf
WSDL Versioning Best Practise
[2] -
http://www.infoq.com/resource/articles/Web-Service-Contracts/en/resources/ERL_WSContractVersioning_013613517X_20-22.pdf
Web Service Contract Design and Versioning for SOA (Chapters 20-22)
[3] - http://www.infoq.com/articles/contract-versioning-comp2 Contract
Versioning, Compatibility and Composability
[4] - http://www.xml.com/lpt/a/1492 Extensibility, XML Vocabularies, and
XML Schema
--
View this message in context:
http://cxf.547215.n5.nabble.com/SOAP-Web-Service-Versioning-tp4731875p4731875.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
