http://java.sun.com/webservices/reference/tutorials/wsit/doc/DataBinding.html
Data Contracts
This chapter describes guidelines for :
A WSIT client/service uses JAXB 2.0 for XML serialization, generating XML schemas from Java classes and generating Java classes from XML schemas. A WCF client/service uses either
XmlSerializer
orDataContractSerializer
for like tasks. JAXB 2.0 and the WCF XML serialization mechanisms differ in two fundamental ways. First, JAXB 2.0 supports all of XML schema. .NET'sDataContractSerializer
andXmlSerializer
support different XML schema sets. Second, WCF'sXMLSerializer
/DataContractSerializer
and JAXB 2.0 differ in their mapping of programming language datatypes to XML Schema constructs. As a result, a XML schema generated from a programming language on one platform and consumed on another platform may result in less than developer-friendly bindings. This chapter discusses some of the common databinding differences between the two systems and recommends ways to address them.
二 论坛:
http://forums.java.net/jive/thread.jspa?threadID=23398
Summary: There are multiple threads related to DataSet in these forums. This is an area that needs some guidelines in general.
First, consider how a DataSet is mapped.[DataContract] public class Foo { [DataMember] public DataSet ds; }
will map to
[ code ]
<xs:complexType name="Foo">
<xs:sequence>
<xs:element minOccurs="0" name="ds" nillable="true">
<xs:complexType>
<xs:annotation>
<xs:appinfo>
<ActualType Name="DataSet" Namespace="http://schemas.datacontract.org/2004/07/System.Data" xmlns="http://schemas.microsoft.com/2003/10/Serialization/" />
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element ref="xs:schema" />
<xs:any />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="Foo" nillable="true" type="tns:Foo" />
[/code]
Notice that <element ref="xs:schema"/> . This will cause wsimport to fail. There is an issue already logged against this. https://jaxp.dev.java.net/issues/show_bug.cgi?id=14 . The generated schema allows the schema to be deferred until runtime ; since a DataSet can be filled at runtime, there is no way of knowing what the schema is at design time.
One way to avoid to this to pass a strongly typed dataset. For example,[DataContract] public class Foo { [DataMember] public BooksDataSet bds; } public class BooksDataSet : DataSet {...}
This will generate a different schema. Notice that <element ref ="xs:schema"/> is no longer generated.<xs:complexType name="Foo"> <xs:sequence> <xs:element minOccurs="0" name="bds" nillable="true" type="tns:BooksDataSet" /> </xs:sequence> </xs:complexType> <xs:element name="Foo" nillable="true" type="tns:Foo" /> <xs:complexType name="BooksDataSet"> <xs:sequence> <xs:any namespace="" /> </xs:sequence> </xs:complexType> <xs:element name="BooksDataSet" nillable="true" type="tns:BooksDataSet" />
The above should be consumable by wsimport. However, the object model is driven by the above schema. So one would get java.lang.Object for xs:any.
In short, DataSets work well in MS specific environment but not cross platform.
Other suggestions on the forum and/or elsewhere indicate that other types could be used instead of a strongly typed DataSet - e.g. arrays, XmlNode, or XmlDataDocument.
This is an area where we could use guidlines. Please post your feedback on this thread and I will incorporate it into a future version of the DataContracts chapter
(go to http://weblogs.java.net/blog/sekhar/archive/2007/02/jaxb_and_wcf_da_2.html ; follow the link to Data Contracts chapter).
Message was edited by: sekhar
----------------------------------------
The suggestion was not to expose DataSet to from the .NET service. Instead, map DataSet to another .NET type and expose that datatype. For e.g in your .NET service,
1. Use a strongly typed dataset instead of DataSet (above example).
2. Map DataSet to a jagged array ( e.g. object[][] )
3. Map DataSet to a System.Xml.XmlNode . For e.g.DataSet ds; //... fill in dataset XmlNode xmlnode = new XmlDataDocument( ds );