cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: SOAP Web Service Versioning
Date Fri, 26 Aug 2011 06:04:20 GMT
Hi Christian,

It's true that JAXB ignores schemas by default, just matching elements
by name and ignoring any extra (or missing) ones. But if you start
developing web services on this basis you're setting yourself up for
problems. You may test code using your sloppy JAXB code and think that
everything is fine, then deploy into production and find that everything
breaks when working with software that actually pays attention to the

The principle of being strict in what you send, open in what you expect,
is what led to the browser wars on the web. Each browser implemented its
own way of handling things which weren't correct, so web sites might
look good with one browser but not with another. We'd all have been much
better off if the browser builders had all agreed to just reject
anything which was not correct. XML is rigidly structured and
unforgiving of deviations in order to avoid this type of problem.

  - Dennis

On 08/26/2011 05:43 PM, Christian Schneider wrote:
> 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] - 
>> WSDL Versioning Best Practise
>> [2] -
>> Web Service Contract Design and Versioning for SOA (Chapters 20-22)
>> [3] - Contract
>> Versioning, Compatibility and Composability
>> [4] - Extensibility, XML Vocabularies,
>> and
>> XML Schema
>> -- 
>> View this message in context:
>> Sent from the cxf-user mailing list archive at

View raw message