You should now understand the techniques for using XML serialization in conjunction with XML Schemas to exchange data between .NET and Java in a common format. This section discusses the recommendations for exchanging data between .NET and J2EE successfully in different enterprise environment scenarios.
In enterprise environments, there are three interoperability scenarios that frequently occur when developing a common format for exchanging data between .NET and J2EE. These are:
Linking new applications.
Linking a new application to an existing application.
Linking two (or more) existing applications.
Unfortunately, the first scenario is the easiest but least common, whereas the last is the most difficult and the most common.
In this scenario, you are developing applications on different platforms that need to exchange data with each other. Here the assumption is that you are building each application from scratch and your developers have decided on a common data format for each application before development.
The best practice recommendations for this scenario are:
Use XSD to define common or shared types and then generate platform-specific code from those shared types.
Create a central XSD repository for your development teams to provide for consistency in generating types across applications.
Avoid exposing elements that XSD does not define — always use types that are published in XSD.
Test data types with test utilities before writing your application.
In this second scenario, you have an existing application on either platform and you need to implement interoperability between this existing application and a new application on the opposite platform.
This scenario assumes you do not have the ability to change the data types in the existing application.
For example, you may have an existing multi-tier J2EE application that uses several defined complex types, such as CustomerData or OrderData. You now have to develop a new ASP.NET Presentation tier that must interoperate with this existing J2EE application. You need to exchange data in the CustomerData and OrderData data types with the new .NET Presentation tier application. However, .NET has no corresponding data types to match the Java CustomerData and OrderData data types.
In this scenario, the best practice recommendations are:
Generate XSDs from the data types that the existing application exposes.
Use these XSDs to generate corresponding data type classes in the new application’s platform.
Follow the recommendations from the first scenario.
This is the most common scenario in enterprise environments, and, unfortunately, the most difficult. Here you have two or more existing applications on different application platforms and you need to implement interoperability between these applications. You also have limited or no ability to change the data types in any of the existing applications. You will have to adapt or convert the data in at least one of the applications into a different format in order to exchange data.
There are several solutions to this scenario. The two most common are:
Use a common format and a single adapter:
Select one application’s data type as a common format for exchanging data.
Implement an adapter layer on the other application to convert its data type to the common format.
Use a common XML Schema and adapters for each application:
Design a common canonical XML Schema based on the business requirements of the exchanged data.
Generate platform-specific types from the common schema.
Implement adapters on all applications to convert their data types to the common data type.
For example, you have an existing .NET Framework application that needs to talk to an existing J2EE application. The applications need to exchange data about customers. The J2EE application has a Customer class and the .NET Framework application also has a Customer class. Unfortunately, neither the .NET nor J2EE Customer classes derive from the same schema. Interoperability was not a factor when the developers created these applications, so the classes are incompatible.
You could design a common XML Schema for CustomerData, and then generate platform-specific CustomerData data types for exchanging data based on that common XML Schema. However, you may not have the ability to replace the platform-specific Customer class used throughout each application with the new CustomerData classes that the common schema generates. This approach would also not be consistent with application best practice.
To resolve this issue, add a new interoperability layer (or adapter) to each application that converts the existing Customer type to the new common CustomerData data type. This adapter copies the field values of the Customer native type into the new CustomerData common type (or vice versa, depending on the direction of data exchange). You can then use the new CustomerData classes in both .NET and Java to exchange data between the two applications through each application’s adapter.