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 < [email protected]> 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:[email protected]] > *Gesendet:* Dienstag, 1. März 2011 08:33 > *An:* Dennis Sosnoski > *Cc:* [email protected] > *Betreff:* Re: Axis Serialization Behavior > > > > Thanks a lot Dennis. > > Cheers, > > -Buddhike > > On Tue, Mar 1, 2011 at 5:30 PM, Dennis Sosnoski <[email protected]> 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 <[email protected]> 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 < > [email protected]> 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 > > > > > > >
