Data Exchange Challenges

Three immediate data exchange challenges exist when connecting any two disparate platforms, all of which revolve around type compatibility. These challenges are primitive data type mappings, nonexistent data types, and complex data types, and they all can hinder the flow of data between the two platforms.

Note

What is a primitive data type? In this context, a primitive data type is data based on the underlying type system of either .NET or Java ”for example, a string, an integer, a double, and so forth.

These three challenges can be defined as follows :

• Primitive data type mappings The string data type exists in both the common language runtime (CLR) and Java. But does this mean that the java.lang.String class in Java is the same as the System.String class in the CLR? If you create your own interoperability sample that exposes types of java.lang.String , how do you map these types to the equivalent types in .NET?

• Nonexistent data types Assuming that you've defined mappings for primitive data types (strings, integers, and so forth), what do you do about data types on one platform that don't exist on the other? Many data types in the CLR don't exist in Java and vice versa. For example, you might not find an appropriate counterpart for the System.Collections.Specialized.HybridDictionary type in Java. So how would you expose data of this type?

• Complex data types Many applications expose complex data types ”custom data types that are made up of primitive data types. An example of this data type is a stock record that contains the company name , current share price, and previous share price. In addition, complex data types can be nested. For instance, imagine a shopping cart that contains multiple Item data types. In this cart, the Item type might also be a complex data type. The challenge lies in exposing the structure of this complex data type so that it can be consumed by a component on another platform.

Fortunately, a number of options discussed throughout this chapter can be used to help exchange data types between applications in .NET and J2EE and vice versa.

Our Sample Scenario

Before we look at these options in detail, let's use the business requirements discussed at the beginning of this chapter. Figure 3.2 repeats Figure 3.1 for simplicity's sake.

Figure 3.2: Requirement for a new ASP.NET presentation tier for an existing J2EE application.

Imagine that the application depicted in Figure 3.2 is a stock-trading Web site. Until now, the application has been based entirely on J2EE technology, but with the release of ASP.NET, the company that operates the site decided that there could be potential for improving the user experience.

In this example, a development team was assigned the task of creating a new look and feel for the site by using ASP.NET, but the challenge of connecting the new portal to the existing EJB infrastructure remains. To start, let's look at the types of data that are potentially exposed by the EJBs that will be called.

Our example application passes stock information to the user from a database populated by another system, or in the language of Chapter 2, from the business tier to the presentation tier. This information might be recommendations for purchases or sales or might simply be a quote for the user's current portfolio. In all these cases, a stock data type is used, as shown in Table 3.1.

Table 3.1: Our Sample's Stock Data Type

Data Field	Type	Example
Ticker	string	FTHC
Name	string	Fourth Coffee
Price	double	3.02
Previous	double	3.23
Volume	integer	1330

The stock type defines five elements: a ticker symbol to uniquely identify the stock, the name of the stock, the current trading price, the previous trading price at the last close, and the volume (in thousands) of this stock that's been traded since the last close. This basic example gives us a realistic data type to work with. As you can see, the Ticker and Name fields are both strings, the Price and Previous fields are doubles, and the Volume field is an integer.

Now that we have defined the complex type that we need to pass from an EJB to a calling ASP.NET page, let's look at the two available methods of data exchange we can use to do this: binary serialization and XML serialization . Given that both involve serialization, let's also define the term .

What Is Serialization?

Serialization is the process by which an object or class can be encoded into a form that can be persisted and/or transported. This can prove useful in many scenarios because it allows complex data types to be encoded, saved, transferred, and decoded, potentially by a different process.

As mentioned, two general types of serialization exist: binary serialization and XML serialization. In binary serialization, a data type is serialized into a stream of bytes. In XML serialization, a data type is serialized into an XML document. The resulting binary stream or XML document can then be stored in memory or a file, or it can be passed across the network as required.

For binary serialization in both the CLR and Java, any type that will be serialized must be appropriately modified. In the CLR, this is done by either annotating the type with the [Serializable] attribute or implementing the ISerializable interface. In Java, a class must implement the java.lang.Serializable interface in order to be serialized.

For XML serialization, the rules are slightly different. Data types in .NET don't necessarily have to be labeled with an attribute, although it's still a good idea. Also, a .NET data type must have a valid default public constructor. (We'll look at this concept in more detail when we examine the sample code in the "Using XML Serialization" section.)

The process of restoring a serialized object to its original form is known as deserialization . The rule of thumb is that objects must be deserialized into the same type that they were serialized from. For example, if I serialize a myStock data type into a stream of bytes or an XML document, I need to deserialize it into the same data type ”I can't deserialize it into a type of yourStock .

Note

A few exceptions to the rule of deserialization exist. For binary serialization, these include writing your own custom serializer and using a process in Java known as evolution , which allows versioning of serialized objects. For XML serialization, you can use XML Schema to define a new type for a document, provided you adhere to the data transformation rules defined by the W3C in the XML Schema recommendation.

Let's look at both binary and XML serialization in action.