Java/.NET Interoperability: Web Services Aren't Always the Answer

Web services can be very useful for integrating standalone components that communicate across a network. When used with straightforward call/return scenarios involving a very limited number of data types, setting them up and getting them to work is trivial. Because web services are standards-based, mixing .NET and Java technologies with them is also easy, which leads some people to believe that web services are the answer to the question of Java/.NET interoperability. They often are not.

A simple web search on "Java .NET interoperability" will return many different approaches, but anyone who heard the Microsoft keynote at JavaOne 2009 this past June may have come away believing web services were the best way. This is unfortunate, because for many tasks, web services are not the ideal Java/.NET interoperability solution. For some tasks, using web services is simply impossible. In this article, I identify three scenarios involving Java/.NET interoperability for which web services would be an unwise choice.

For many tasks, web services are not the ideal Java/.NET interoperability solution.

First, let me define precisely what I mean by Java/.NET interoperability. Admittedly, it's a high bar, but a true .NET/Java interoperability mechanism should allow you to substitute something written in Java anywhere you might ordinarily use something written in a .NET language. In other words, it would allow you to access any Java-based entity (such as an object, class, or method) from .NET code, or vice versa. For many scenarios where developers and architects could not use web services, Java/.NET interoperability as I define it would be very useful.

Scenario 1. Embedding .NET UI Controls Inside Java Apps

Consider a situation where you'd like to employ a Windows Forms control inside an AWT-based Java application. The standard way to do this is to obtain a handle to the peer (the underlying Windows object) of the surrounding AWT container, and then use that handle to set the parent object of the Windows Forms control to be the AWT container's peer. (There's more to it than that, but this is the main requirement for getting the embedding to work.) You can't use a web service to implement this kind of interoperability.

Web services are loosely coupled; the service and the client run in separate processes. With separate processes, you can't exchange window handles; the handles are valid and meaningful only in the same process. In other words, this is an interoperability scenario that must be tightly coupled, a situation that web services cannot accommodate. A developer who wanted to embed .NET-based controls inside a Java-based GUI application (or vice versa) would have to use a different approach.

Scenario 2. Calling a .NET Library from a Java App

What if you had a .NET-based library that you wanted to use in an otherwise Java-based application? Any number of factors could lead to this scenario. For example, suppose you:

1. Already use the library in .NET development, and you want to make use of the expertise you've developed.
2. Paid a lot for that library and don't want to pay more for a Java library.
3. Determined the library is simply the best available, regardless of platform.

In this case, you could use a web service to access the .NET code from Java, but that seems like overkill. It doesn't make sense that one would have to set up a server to simply access a library. Web services are much more appropriate for facilitating communications between larger standalone components, not for integrating a library into a larger system. It's also overkill to create a web service to allow access to a library from an application, if the library resides on the same machine. In such a case, it would make much more sense to be able to run the .NET-based library inside the Java application's process, which is impossible with a web service.

Scenario 3. Registering a .NET Listener with a Java API

Suppose you have a JMS (Java Message Service) infrastructure and you want to create a .NET component that will send messages to, and receive messages from, that infrastructure. Ordinarily, you send messages to JMS by calling various send methods in the JMS API, and you receive messages by registering listeners with the JMS infrastructure. The listeners execute when messages arrive.

You can do this with web services, but they aren't very good at handling asynchronous communications. If you want to implement asynchronous communications using web services, you have two options:

1. Implement a polling mechanism, in which the client repeatedly polls the service for a result. When the result is available, the service places it in a location where the polling operation will find it.
2. Implement a callback mechanism, in which the client leaves a return address. The service calls this return address when a result is available.

Unfortunately, both of these mechanisms require implementing a significant infrastructure. In the case of polling, you need both a polling mechanism and a mechanism for the service to place a return value where the polling mechanism can see it. In the case of callbacks, you must embed an entirely new "reverse" web service inside the client, so that the original service can contact it and return the asynchronous result.

Both options suffer from a lack of proportionality. As in the scenario where you want an application simply to call a library, web services require implementing mechanisms that are totally out of proportion with the task at hand. Registering a listener that will execute when a certain action occurs is a prime example. There have to be better ways to do this, and there are.

Scenario 2. Calling a .NET Library from a Java App

What if you had a .NET-based library that you wanted to use in an otherwise Java-based application? Any number of factors could lead to this scenario. For example, suppose you:

1. Already use the library in .NET development, and you want to make use of the expertise you've developed.
2. Paid a lot for that library and don't want to pay more for a Java library.
3. Determined the library is simply the best available, regardless of platform.

In this case, you could use a web service to access the .NET code from Java, but that seems like overkill. It doesn't make sense that one would have to set up a server to simply access a library. Web services are much more appropriate for facilitating communications between larger standalone components, not for integrating a library into a larger system. It's also overkill to create a web service to allow access to a library from an application, if the library resides on the same machine. In such a case, it would make much more sense to be able to run the .NET-based library inside the Java application's process, which is impossible with a web service.

Scenario 3. Registering a .NET Listener with a Java API

Suppose you have a JMS (Java Message Service) infrastructure and you want to create a .NET component that will send messages to, and receive messages from, that infrastructure. Ordinarily, you send messages to JMS by calling various send methods in the JMS API, and you receive messages by registering listeners with the JMS infrastructure. The listeners execute when messages arrive.

You can do this with web services, but they aren't very good at handling asynchronous communications. If you want to implement asynchronous communications using web services, you have two options:

1. Implement a polling mechanism, in which the client repeatedly polls the service for a result. When the result is available, the service places it in a location where the polling operation will find it.
2. Implement a callback mechanism, in which the client leaves a return address. The service calls this return address when a result is available.

Unfortunately, both of these mechanisms require implementing a significant infrastructure. In the case of polling, you need both a polling mechanism and a mechanism for the service to place a return value where the polling mechanism can see it. In the case of callbacks, you must embed an entirely new "reverse" web service inside the client, so that the original service can contact it and return the asynchronous result.

Both options suffer from a lack of proportionality. As in the scenario where you want an application simply to call a library, web services require implementing mechanisms that are totally out of proportion with the task at hand. Registering a listener that will execute when a certain action occurs is a prime example. There have to be better ways to do this, and there are.

For complex, yet still relatively simple, Java/.NET interoperability requirements, web services force you to reinvent the wheel.

Additional Tools Needed for Java/.NET interoperability

For complex, yet still relatively simple, Java/.NET interoperability requirements (such as calling a .NET library from a Java application or registering a .NET listener with a Java API), web services force you to reinvent the wheel. You have to create elaborate infrastructures—exchanging XML through sockets—to accomplish tasks that should be very simple. This is just silly. And for other tasks, such as embedding .NET UI controls inside Java applications, using web services is simply impossible.

The developer and architect toolbox should hold more than just web services for Java/.NET interoperability solutions. They're fine for some things, but for many interoperability tasks, you need a different tool. A Java/.NET bridge will work well in situations where web services are inappropriate or just don't work, and may well be more efficient or easier to use even in those situations where you can use web services.

If you understand the limitations of web services for interoperability and familiarize yourself with other solutions, you can make the best use of both Java and .NET technologies in your applications.

by Wayne Citrin