Oh, and I should mention there's another way to get easy extensibility, which is to use attributes for simple values, rather than elements. You can use an xs:anyAttribute as part of your schema definition, and that will allow you to define new attributes in future iterations of the schema without breaking compatibility with existing clients.
Personally I prefer attributes for representing simple values, but some of the web services stacks tend to discourage them (such as .Net/WCF - they'd proposed dropping support for attributes completely at one point, though I doubt they'd ever be able to do this). - Dennis Dennis M. Sosnoski Java SOA and Web Services Consulting <http://www.sosnoski.com/consult.html> Axis2/CXF/Metro SOA and Web Services Training <http://www.sosnoski.com/training.html> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html> On 03/02/2011 01:20 PM, Dennis Sosnoski wrote: > Hi Buddhike, > > As I mentioned in my reply to a separate email on a similar issue, > it's possible to design your schemas with extension points for adding > more data in the future by using the xs:any element. The big > limitation is that if you want to use the same namespace for your > extension elements, the xs:any must be the last item in an xs:sequence > and must follow a required element (this is a somewhat stupid > limitation of XML schema). That's not so bad if you're only adding a > few extensions, but it causes problems when you want to provide an > updated schema that includes the extension elements. > > One way around this limitation is to use a new namespace for each set > of added elements, but this leads to namespace proliferation and a lot > of confusion. Another is to use an optional wrapper element around the > added content, but that also leads to ugliness since a new wrapper > element would be required for each set of extensions. > > So there's no easy way to get the kind of flexibility you want while > staying compatible with XML schema. JAXB will give you the client-side > flexibility, but it does this by basically ignoring the schema and > only processing the elements it understands. Clients using tools which > take the schema more seriously will fail with your added data. > > - Dennis > > > On 03/02/2011 12:09 PM, Buddhike de Silva wrote: >> >> Thanks Josef. I like your idea. But this would be a little >> complicated in terms of what we are trying to achieve. To put more >> context around... We are building a public Web Service. And we >> want to be interoperable with main stream Java stacks. When it comes >> to releasing the next version of the product, we want to ensure that >> our clients don't break regardless of the stack they are using. We >> also want to ensure we have the fastest upgrade path for certain >> things we consider as non breaking changes. >> >> One of them is adding a new optional member to type. We could >> consider that as a breaking change and version our endpoints >> accordingly but given the number of small changes we could >> anticipate, we'd rather avoid going down that path. However, we could >> only do that, if our clients using Java had the option to do lax >> visioning :-). >> >> We could use the dictionary based solution you mentioned. However, >> this would hide the strongly typed/hierarchical view of our data from >> our clients using the subsequent versions. >> >> Cheers, >> >> -Buddhike >> >> On Tue, Mar 1, 2011 at 6:21 PM, Stadelmann Josef >> <josef.stadelm...@axa-winterthur.ch >> <mailto:josef.stadelm...@axa-winterthur.ch>> wrote: >> >> Hi Buddhike >> >> >> >> Denis é all is right, breaking the contract is bad. But you can >> also think about how a collection would be serialized, given a >> collection of strings can be seen as a type. While this >> collection is i.e. a collection of elements and each element has >> name value pairs of type string. If you can serialize and >> de-serialize a collection then you can add as many elements as >> you like. This is our approach to exchange unforeseen amounts of >> screen data from transaction masks with our server up to the >> database tables. The axis2 client is very well in receiving and >> responding with AXIOM OMElement. And an OMElement can consist any >> series of nodes parent with child's and child's with siblings. >> >> >> >> The axis2 examples shows a service, guess one of the echo >> examples, how an OMElement is exchanged from an axis2 client with >> the axis2 server. >> >> Now it is up to you to add more nodes to this OMElement and send >> it to the server, and receive one from the server. If that works >> record what is exchanged an make the same between a WCF Client >> and a WCF Server. Then take a look at the difference using a SOAP >> Monitor or a TCPMONITOR. >> >> >> >> It’s a hard way but it works. >> >> >> >> Cheers >> >> >> >> *Von:* Buddhike de Silva [mailto:buddhike.desi...@geeksdiary.com >> <mailto:buddhike.desi...@geeksdiary.com>] >> *Gesendet:* Dienstag, 1. März 2011 08:33 >> *An:* Dennis Sosnoski >> *Cc:* java-user@axis.apache.org <mailto:java-user@axis.apache.org> >> *Betreff:* Re: Axis Serialization Behavior >> >> >> >> Thanks a lot Dennis. >> >> Cheers, >> >> -Buddhike >> >> On Tue, Mar 1, 2011 at 5:30 PM, Dennis Sosnoski <d...@sosnoski.com >> <mailto:d...@sosnoski.com>> wrote: >> >> Ah, I hadn't realized you were using Axis(1). With Axis2 you can >> select the data binding using a parameter to Wsdl2Java. You >> should be able to see examples included in the Axis2 download, or >> you can try my code from this article: >> http://www.ibm.com/developerworks/java/library/j-jws8.html I >> haven't tried the code from the article with the latest Axis2 >> releases, but hopefully it'll still work correctly. >> >> - Dennis >> >> >> >> >> On 03/01/2011 07:58 PM, Buddhike de Silva wrote: >> >> Thanks Dennis. Do you know of a link with some sample code on how >> to do this? Sorry, I'm not really familier with Axis2. Thanks again. >> >> Cheers, >> >> -Buddhike >> >> On Tue, Mar 1, 2011 at 4:46 PM, Dennis Sosnoski <d...@sosnoski.com >> <mailto:d...@sosnoski.com>> wrote: >> >> Hi Buddhike, >> >> The handling of unexpected XML elements is determined by the data >> binding technique used. JAXB is the sloppiest data binding >> supported by Axis2 (on a par with WCF), and if you change to that >> you should be ok. >> >> - Dennis >> >> Dennis M. Sosnoski >> Java SOA and Web Services Consulting >> <http://www.sosnoski.com/consult.html> >> Axis2/CXF/Metro SOA and Web Services Training >> <http://www.sosnoski.com/training.html> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html> >> >> >> On 02/28/2011 10:17 PM, Buddhike de Silva wrote: >> >> Anyone? (please... :-)) >> >> On Sun, Feb 27, 2011 at 4:28 PM, Buddhike de Silva >> <buddhike.desi...@geeksdiary.com >> <mailto:buddhike.desi...@geeksdiary.com>> wrote: >> >> Hi All, >> >> We are doing some interop tests between Axis and WCF. In our WCF >> service we have a type like this. >> >> [DataContract] >> >> public class CompositeType >> >> { >> >> [DataMemeber] >> >> public bool BoolValue {get; set;} >> >> } >> >> That results in a schema similar to the following. >> >> <xs:complexType name="CompositeType"> >> <xs:sequence> >> <xs:element name="BoolValue" type="xs:boolean" minOccurs="0"/> >> </xs:sequence> >> </xs:complexType> >> <xs:element name="CompositeType" type="tns:CompositeType" >> nillable="true"/> >> >> >> We can generate Axis code with the WSDL/Schema generated by WCF >> service and communicate with the service. However, if we add >> another property to CompositeType class on the WCF server side, >> it breaks the Axis client. It throws an exception saying it's >> reading an element that was unexpected. Our understanding Axis is >> capable of lax processing of XML (that is, if it encounters >> anything that's not recognized, serializer simply discards them). >> Could someone pleasae let us know which settings we should use to >> enable lax processing of messages? Many thanks in advance. >> >> Cheers, >> >> -Buddhike >> >> >> >> >> >> >> >>
