Joseph Ottinger

It's with continued amusement that I constantly read about how Java should be defended from .NET, and how .NET will destroy Java. I understand the invective used by both sides, but the shine is starting to wear off; it's time to stop hurling insults, and examine what the future really holds. In my opinion, Java and .NET don't truly compete on a meaningful technological front - because both include easy hooks that allow for convenient interoperability.

.NET marshals information transfer through the use of formatters, sort of like interceptors that translate data into an internal format. If this sounds easy to do in Java as well, you should get a cookie - it is, and it's something some SOAP providers for Java do already. The concept is very similar to aspect-oriented programming, in which an interceptor sits in front of the method call, accepts the parameters, converts them into a format appropriate for the method, and then when the method has finished execution, translates the method results back into a format appropriate for the caller.

The similarity in the process is a critical factor. .NET may not be the grail - or the dragon - but it's not difficult to see how it's done from a conceptual standpoint. The process of enabling formatters for .NET method calls is fairly simple, only slightly more difficult than The Mind Electric's GLUE product (www.themindelectric.com); when you author your remotable components, you specify the capability to marshal by copy. Then, set up your endpoints with "Channels," at which point you can decide whether or not to expose the service with SOAP. In contrast, with GLUE (in the simplest case) you define an interface, then implement the interface with a concrete class, then tell the GLUE server you wish to publish the implementation as a service. Enterprising minds can see how both approaches can work.

The key for me is that both processes can be used with little knowledge on the caller's part. With GLUE, there's a slight registration process for the caller; it's not quite transparent. With .NET, you do much the same: acquire a handle to a remote service at runtime (including the type of connection), then call the object.

Thus, it's safe to say that there can be a direct equivalency between using a language-neutral remote service API in both Java and .NET. As such, as developers, our horizons are broadened by the existence of both technologies; a service is just a ser- vice, and we no longer really care if it's hosted on .NET or not; all we need to do is establish an endpoint, call the service, and process the result. Competition is a moot point when the technology is roughly equivalent, and interoperability is easily accomplished.

However, there are still differentiators. .NET is still provided by primarily one vendor, which means being subject to the whims of that vendor; I know of a few excellent programmers who have experience in COM, COM+, and DCOMŠshifting focus everytime as Microsoft discovers a "new and better" way to accomplish late binding. Java has had late binding built into its core since its inception, and that's one of its strengths.

Note that not all Java APIs for SOAP are created equal: JAXM does not provide the same clean API that GLUE does, which is a pity; JAXM follows Apache SOAP's model of exposing the underlying transport to the programmer, which is a grand failure in my opinion. The unfortunately named SAAJ (as implemented by Apache Axis) is better than JAXM, in this regard, but still requires a lot of code compared to GLUE. Hopefully, as the JCP matures the XML services for Java, they will follow GLUE's excellent example.

The result of all this is that Java and .NET compete, but primarily in mind share, not in technology. The marketing drive for both continues to escalate, but the interoperability between the two continues to improve; that is a huge win for implementers, as we can now visualize even operating environments as commodities. The goal should not be to dominate the market to the exclusion of other solutions, but to make implementation easier than it is using the available technology. If the implementation is as easy to use as GLUE's is, then the technology will be adopted.