Resource Tier Interoperability
Interoperability solutions using Web services, .NET Remoting, or CORBA are typically synchronous in nature, and occur between two parties (a client and a service). In typical calls, the client calls the service, some data is returned, and the call is finished.

In applications that need to behave in a more asynchronous fashion, interoperability at the resource tier—which implies using either a database or a message queue—may be the answer. Using a database or message queue to connect platforms based on .NET and J2EE can be one of the easiest ways to achieve interoperability between the two. Database solutions typically share a table between the two platforms, and each uses its preferred method for connecting to the database (ADO.NET for .NET, JDBC for the Java platform). Investing in stored procedures at the database tier can also help in reducing duplication of code.

Interfacing with message queues works in a similar way, although each platform will normally have to obtain a driver from the message queue vendor in order to establish a connection. This may be a JMS (Java Message Service) driver for the J2EE platform, or a specific set of classes for .NET. For example, IBM offers WebSphere MQ 5.3 drivers with similar style interfaces for both Java and .NET. Many message queue vendors now also offer the ability to communicate via more standardized interfaces such as Web services.

In addition to providing good support for asynchronous style calls, using the resource tier can prove beneficial for n-n style interoperability, where multiple clients need to communicate with multiple servers. In the majority of the previous interoperability solutions, each client needs to know the location of each server. In a scenario using an intermediary database or message queue, although both sides must agree on the format of the message, the client does not necessarily need knowledge of the service location—which both negates the need for location-based information and can also help provide support for failover and load balancing.

For all the advantages that a database or message queue provides however, they really are designed for asynchronous style communication. Using them in a synchronous style call (for example, where an ASP.NET page required a response before displaying the result to the user) can lead to potential performance issues. In addition, using either a database or message queue introduces yet another piece to the interoperability puzzle. For situations where many machines have a requirement for interoperability, it may be worth the investment in administration and additional machines; but in a scenario where just one client needs to interoperate with a single service, this solution just introduces potential overhead.

In his article, "Java/.NET Interoperability via Shared Databases and Enterprise Messaging," Kyle Gabhart investigates the approach of using either a database or message queue to achieve interoperability between Microsoft .NET and Java.

Compare, then Decide
It is fair to say that there's no universal answer for interoperability today. While Web services offer incredible potential moving forward, applications already in place today may require more of a tactical approach. To help you differentiate between the various approaches, Table 1 lists some of the advantages and disadvantages of each.

Table 1. Interoperability Comparison Matrix: The table shows some of the advantages and disadvantages of each interoperability solution.

	Integrated Platform Support	XML / SOAP Interoperability	Binary Interoperability	Designed for Synchronous Style Calls	Designed for Asynchronous Style Calls	Requires modifications to existing server side components	Extensible without re-compile
Web services	Yes	Yes	No	Yes	No**	Yes***	Yes
.NET Remoting	Partial	Yes*	Yes	Yes	No	Partial	No
CORBA Interoperability	Partial	No	Yes	Yes	No	No	No
Resource Tier	Yes	Optional	Optional	No	Yes	N/A	No

* Uses CLR data types, not XSD
** Assuming HTTP as the transport
*** The majority of modifications are required to ensure the data types exposed are XSD compliant

We hope that this special report offers you some insight into the merits and suitability of the various interoperability approaches.