You have now seen how you can use XML serialization to serialize objects into an XML format on one platform, and then de-serialized them back into the original object type in the alternate environment. However, XML serialization alone does not solve the issue of exchanging data between .NET and Java.
A major consideration when using serialization techniques is to ensure that when you generate an XML document from one platform, the document is compatible with the other. You should not take this compatibility for granted. The XML Schema provides the interoperability contract that specifies the format for XML documents. It is this component that provides the template for successfully linking .NET and Java.
By itself, an XML document does not define the data types within the document. Hence a value of 4.56 could be a string, a double, or a float. This makes it difficult for the receiving platform to import the value correctly. Similarly, both platforms could implement the type OrderData, but the .NET version could be totally unrelated to the identically named type in Java.
For example, if you serialize the OrderData object on the .NET platform into an XML document and pass it to the Java application for consumption, you need to answer the following questions:
How will the Java application know how to de-serialize the OrderData object?
Is there an OrderData data type in Java equivalent to the OrderData data type in .NET?
What if the OrderData data type in Java has nothing in common with the OrderData data type in .NET?
These questions all point to data type compatibility issues that you need to resolve to enable the exchange of data between .NET and J2EE.
The XML Schema provides a linking framework through the XML Schema Document (XSD) that assists in exchanging data between .NET and J2EE by defining the format of an XML document. An XSD file specifies an XML Schema, and the XSD file itself is simply another XML document with a set structure. Nodes and elements within the XSD define the elements and data types in the related XML document(s). An XSD also contains any constraints for each element with the XML document.
Within the XSD file, you can specify the definition of a data type stored in the XML format. For example, when defining the OrderData data type in an XSD, you can specify the names and number of fields within the object, such as orderID, itemDescription, and price. You can also specify that the value of the price field (4.56) in your OrderData object is of type double.
XSDs allow you to define XML namespaces. XML namespaces allow you to declare unique types and also let you identify different data types that may have the same name.
One essential component in the XSD is the common namespace. This lets you declare elements such as xs:complexType as unique for the document. For more information about the XSD namespace, see the W3Consortium Web site.
Visual Studio .NET includes an XML Designer tool that allows you to design XML schemas easily. The XML Designer lets you switch modes between a graphical representation of your schema or the XSD document that represents that XML Schema. XML Designer creates platform independent XSDs that conform to the W3C standards. For more information about generating schemas in Visual Studio .NET, see Visual Studio .NET Help.
IBM Websphere Studio Application Developer 5.0 also contains a tool that allows you to design XML Schemas easily. The XSD designer allows you to switch modes between a graphical representation of the schema you are designing to the actual XSD document representing the XML schema. XSDs designed in IBM WebSphere Studio Application Designer are also platform independent and conform to the W3C organization’s XSD standards.
You saw in the previous section how you can implement an XML Schema in an XSD to define the format of an XML document. You can use this knowledge to complete the final piece of the data exchange puzzle.
The fact is that the .NET and Java platforms are highly unlikely ever to agree on data types. However, using XSDs, the two platforms can agree on the format of an XML document. If interoperability was like international diplomacy, this would be hailed as a major milestone toward world peace.
Both .NET and Java have tools that allow you to map a class to a defined XML Schema and vice versa. When you map a class to an XML Schema, the XML document that you generate by serializing an instance of that class matches the XML format that the XSD defines. By mapping classes on each platform to a common XML Schema, you can ensure that each platform can exchange XML data with the other.
For example, you map a CustomerData class in both .NET and Java to a common XML Schema file, CustomerData.xsd. You should then be able to serialize an instance of the Java CustomerData class into an XML document, and de-serialize it back into an instance of the .NET CustomerData class.
With the XML Schema mapping tools in .NET and Java, you have two main approaches for developing a common format for exchanging data:
Start with a common XML Schema, and then generate data type classes on both platforms. This approach guarantees that you build data types and a schema in a platform independent format.
Start from an existing data type class (from either platform), generate an XML Schema from it, and then generate a corresponding data type class for the other platform from the resulting XML Schema.
The first technique is best if the classes do not already exist on either platform. If they do exist on one or other, then you must use the second method.
For each of these approaches, the technique differs, depending on whether you are working on the Java or .NET platform.
The .NET Framework provides an XML Schema Definition tool, Xsd.exe, which you can use to map .NET classes to XML Schemas and back again. Using this tool, you can:
Generate a .NET class from an XSD.
Generate an XSD from a .NET class.
For example, if you define an XML Schema document ProductsData.xsd for a data type named ProductsData, you can use Xsd.exe to generate a serializable .NET class named ProductsData. Serializing an instance of the .NET ProductData class produces an XML document that matches the XML format defined in the XML Schema document, ProductsData.xsd.
Alternatively, if you define a serializable ProductsData class in .NET, you can use Xsd.exe to generate an XML Schema, ProductsData.xsd defining the format of an XML document containing a serialized version of the ProductsData object.
Xsd.exe only allows you to manipulate XML Schemas that follow the World Wide Web Consortium’s implementation of the XML Schema definition language.
For more information about the XML Schema Definition tool, see XML Schema Definition Tool on MSDN.
For additional examples of how to use the XML Schema Definition tool, see Chapter 3 of Simon Guest’s book Microsoft .NET and J2EE Interoperability Toolkit.
On the Java platform, there are multiple tools you can use to map Java classes to XML Schemas and vice versa. Examples are:
schema2java and java2schema from Electric XML
Java Architecture for XML Binding (JAXB)
Most of the XML serialization tool vendors produce equivalent utilities to schema2java and java2schema. However, the examples in this book use the Electric XML versions.
The schema2java and java2schema tools provide functionality very similar to Xsd.exe in .NET. With Electric XML tools you can:
Use schema2java to generate a Java class from an XSD.
Use java2schema to generate an XSD from a Java class.
You can use the schema2java tool with the same XML Schema file, ProductsData.xsd that you defined for a data type named ProductsData in the.NET example to generate a serializable Java class named ProductsData. Just as in .NET, serializing an instance of the Java ProductData class generates an XML document that exactly matches the XML Schema from the ProductsData.xsd document.
The java2schema tool allows you to perform the reverse process. If you define a serializeable ProductsData class in Java, you can use java2schema to generate an XML Schema, ProductsData.xsd. This document defines the format of an XML document containing a serialized version of the Java ProductsData object.
You can only generate XSDs from compiled classes, not source code.
For more information about schema2java and java2schema, see Package electric.xml.io.tools in the References section at the end of this chapter.
For an example of how to use the Electric XML tools to map Java classes and XML Schemas, see Microsoft .NET and J2EE Interoperability Toolkit, Chapter 3, pages 70–80.
In both the .NET and Java examples in the earlier section, because the same ProductsData.xsd is the source for both the Java ProductsData class and the .NET ProductsData class, both classes serialize into the same XML format. Hence you can serialize an instance of the ProductsData class on one platform into an XML document, then de-serialize it back into an instance of the ProductData class on the other platform.
Generating types using XSDs is very powerful, and it goes a long way to providing cross-platform interoperability. XSDs are also a foundation element in WSDL. Understanding the structure of XSDs is very helpful when looking at data type transportation in XML Web services.
The previous section described how to map classes and XSDs in both .NET and Java. However, there are limitations when using this technique to create a common format for exchanging data. In most cases, the complex data types you use to store data in both .NET and Java consist of primitive types. Unfortunately, not all primitive types have a direct mapping between .NET and Java.
The XSD common namespace defines a set of data types that XML can represent. Both .NET and Java have mappings to the XML data types defined in the XSD common namespace.
When designing complex data types, you are recommended to use only the platform data types that map directly to XML data types.
Table 3.1 shows the mapping between XML data types, .NET data types, and J2EE data types using the serializer in Electric XML.
|XML Data Type||.NET Data Type||Electric XML Data Type|