Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4E57326E.3000907@die-schneider.net>
Date: Fri, 26 Aug 2011 07:43:10 +0200
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: SOAP Web Service Versioning
References: <1314219663687-4731875.post@n5.nabble.com>
In-Reply-To: <1314219663687-4731875.post@n5.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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