You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Buddhike de Silva <bu...@geeksdiary.com> on 2011/02/27 07:28:32 UTC
Axis Serialization Behavior
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
Re: Axis Serialization Behavior
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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.stadelmann@axa-winterthur.ch
>> <ma...@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.desilva@geeksdiary.com
>> <ma...@geeksdiary.com>]
>> *Gesendet:* Dienstag, 1. März 2011 08:33
>> *An:* Dennis Sosnoski
>> *Cc:* java-user@axis.apache.org <ma...@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 <dms@sosnoski.com
>> <ma...@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 <dms@sosnoski.com
>> <ma...@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.desilva@geeksdiary.com
>> <ma...@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
>>
>>
>>
>>
>>
>>
>>
>>
Re: Axis Serialization Behavior
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 03/02/2011 07:54 PM, Buddhike de Silva wrote:
>
> Thanks Dennis.
>
> We thought about providing a xs:any element for extensibility.
> However, this poses a few other problems as you mentioned below. I
> wonder whether it's possible to do xs:any with maxOccurs="unbounded"
> as a way of providing multiple arbirerary elements without violating
> XML schema.
>
Yes, xs:any with maxOccurs="unbounded" is fine - but the problem is that
it only works for one extended schema, unless your extended schema ends
with a new required element. So you could go from schema1:
<xs:element name='a' type='xs:string'/> <!-- required element -->
<xs:any maxOccurs='unbounded'/>
to schema2:
<xs:element name='a' type='xs:string'/> <!-- required element -->
<xs:element name='b' type='xs:string' minOccurs='0'/>
...
<xs:element name='c' type='xs:string' /> <!-- required element -->
<xs:any maxOccurs='unbounded'/>
to schema3:
<xs:element name='a' type='xs:string'/> <!-- required element -->
<xs:element name='b' type='xs:string' minOccurs='0'/>
...
<xs:element name='c' type='xs:string' /> <!-- required element -->
<xs:element name='d' type='xs:string' minOccurs='0'/>
...
<xs:element name='e' type='xs:string' /> <!-- required element -->
<xs:any maxOccurs='unbounded'/>
all while maintaining compatibility (providing the new required elements
were always present in the server response). But you have to add a new
required element with each update.
Attributes are a much cleaner solution for working with simple values.
> /<quote>/
>
> /"So there's no easy way to get the kind of flexibility you want
> whilestaying compatible with XML schema. JAXB will give you the
> client-sideflexibility, but it does this by basically ignoring the
> schema and onlyprocessing the elements it understands. Clients using
> tools which takethe schema more seriously will fail with your added
> data."/
>
> /</quote>/
>
> Very true. This is why we started investigating whether all mainstream
> stacks have an option to do lax versioning.
>
It's not a good idea to count on users working with stacks which ignore
the schema message description. If you take this approach it will work
ok with WCF or JAXB developers, but you're likely to run into groups
using other tools - and when they point out you're violating your own
schema they'll be correct, which might be hard to explain to your
management.
- Dennis
Re: Axis Serialization Behavior
Posted by Buddhike de Silva <bu...@geeksdiary.com>.
Thanks Dennis.
We thought about providing a xs:any element for extensibility. However, this
poses a few other problems as you mentioned below. I wonder whether it's
possible to do xs:any with maxOccurs="unbounded" as a way of providing
multiple arbirerary elements without violating XML schema.
*<quote>*
*"So there's no easy way to get the kind of flexibility you want
whilestaying compatible with XML schema. JAXB will give you the
client-sideflexibility, but it does this by basically ignoring the schema
and onlyprocessing the elements it understands. Clients using tools which
takethe schema more seriously will fail with your added data."*
*</quote>*
Very true. This is why we started investigating whether all mainstream
stacks have an option to do lax versioning.
Cheers,
-Buddhike
On Wed, Mar 2, 2011 at 10:20 AM, Dennis Sosnoski <dm...@sosnoski.com> 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.stadelmann@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.desilva@geeksdiary.com]
>> *Gesendet:* Dienstag, 1. März 2011 08:33
>> *An:* Dennis Sosnoski
>> *Cc:* 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 <dm...@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 <dm...@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.desilva@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
>>
>>
>>
>>
>>
>>
>>
>
>
Re: Axis Serialization Behavior
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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.stadelmann@axa-winterthur.ch
> <ma...@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.desilva@geeksdiary.com
> <ma...@geeksdiary.com>]
> *Gesendet:* Dienstag, 1. März 2011 08:33
> *An:* Dennis Sosnoski
> *Cc:* java-user@axis.apache.org <ma...@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 <dms@sosnoski.com
> <ma...@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 <dms@sosnoski.com
> <ma...@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.desilva@geeksdiary.com
> <ma...@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
>
>
>
>
>
>
>
>
Re: Axis Serialization Behavior
Posted by Buddhike de Silva <bu...@geeksdiary.com>.
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.stadelmann@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.desilva@geeksdiary.com]
> *Gesendet:* Dienstag, 1. März 2011 08:33
> *An:* Dennis Sosnoski
> *Cc:* 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 <dm...@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 <dm...@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.desilva@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
>
>
>
>
>
>
>
AW: Axis Serialization Behavior
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
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.desilva@geeksdiary.com]
Gesendet: Dienstag, 1. März 2011 08:33
An: Dennis Sosnoski
Cc: 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 <dm...@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 <dm...@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 <bu...@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
Re: Axis Serialization Behavior
Posted by Buddhike de Silva <bu...@geeksdiary.com>.
Thanks a lot Dennis.
Cheers,
-Buddhike
On Tue, Mar 1, 2011 at 5:30 PM, Dennis Sosnoski <dm...@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 <dm...@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.desilva@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
>>>
>>
>>
>
Re: Axis Serialization Behavior
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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 <dms@sosnoski.com
> <ma...@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.desilva@geeksdiary.com
>> <ma...@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
>>
>>
>
Re: Axis Serialization Behavior
Posted by Buddhike de Silva <bu...@geeksdiary.com>.
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 <dm...@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.desilva@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
>>
>
>
Re: Axis Serialization Behavior
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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.desilva@geeksdiary.com
> <ma...@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
>
>
Re: Axis Serialization Behavior
Posted by Buddhike de Silva <bu...@geeksdiary.com>.
Anyone? (please... :-))
On Sun, Feb 27, 2011 at 4:28 PM, Buddhike de Silva <
buddhike.desilva@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
>