Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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

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.


advertisement

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.



Wayne Citrin is the CTO and co-founder of JNBridge, makers of Java and .NET interoperability tools. He has been engrossed in Java and .NET interop issues since .NET's earliest days and is an expert on interoperability issues regarding connecting the two platforms. Previously, he was a leading researcher in programming languages and compilers at the University of Colorado, Boulder and a researcher at IBM's lab in Z�rich, Switzerland. Citrin holds a Ph.D. from the University of California, Berkeley, in Computer Science.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap