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 > > > > > > > >
