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 schema.
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] - >> 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. >> >
