On Friday, August 26, 2011 6:04:20 PM Dennis Sosnoski wrote: > Hi Christian, > > It's true that JAXB ignores schemas by default, just matching elements > by name and ignoring any extra (or missing) ones.
Actually, by default, CXF configures JAXB to NOT ignore any extra elements. Thus, this idea would require you to configure CXF out of defaults. Basically, we got way too many "why are my fields null?" kind of questions and almost all of them were a result of sending SOAP messages where the namespaces on the elements were wrong (qualified vs unqualified usually). By default, JAXB ignored the elements with the wrong namespaces so all the fields ended up null. We added an error handler which now will throw an exception so people know their message is wrong. It's not full schema validation. It has no impact on performance. It just fails for invalid/unexpected data. Dan > 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/resour > >> ces/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 -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
