RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


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

Mixing .NET and Java technologies with web services is often easy, but for many tasks web services are not the solution for Java/.NET interoperability.

eb 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.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date