The .NET and Java Interoperability Message Is Starting to Get Out

  • Article

When it comes to web services interoperability between .NET and Java, the choice used to be limited to SOAP over HTTP. This became even more limited with introduction of .NET 3.0 because only BasicHTTP binding in .NET provides direct interoperability with Java Web Services.

[via https://www.infoq.com/news/2008/03/wmq-activemq-interop]

I love to see that folks are still talking about .NET and Java interoperability despite the more recent focus and fanfare around RIA and Silverlight.  I actually heard someone during a recent RIA presentation say that ".NET and Java interop is an old story".  Really?  Tell that to the vast number of companies faced with this situation every day and see how satisfied they are to hear that the problem has been "solved".

The WS-* stack has gone a long way towards solving some of the inherent issues between platforms.  Focus on schemas, not contracts, and resist the urge to share types over the wire.  Remove the dependency on the protocol and move the interesting capabilities into the message as a protocol.  Get rid of HTTP header based activation and move towards WS-Addressing.  Quit trying to get COM+ to talk to a Java based TP monitor, move the transactional semantics into the message via WS-AtomicTransactions.  Instead of trying to figure out MSMQ and MQ bridging (and licensing), move reliability and durability capabilities into the message itself so that secure, reliable, and transacted messaging can happen over any transport protocol.

Despite the promise, the truth is that most people still seem focused on transport interoperability (using HTTPS to secure the pipe instead of encrypting the soap:Body, for instance).  The lure of the cockroach of all protocols (HTTP) is that everyone understands HTTP and everyone knows how to transmit UTF-8 encoded text streams with angle brackets.  Hopefully, by now, the mass majority understands that the interoperability between .NET and Java is not limited to just SOAP over HTTP.  Sure, this was the easiest and most notably touted route, but certainly not the only one. 

Fast Infoset was implemented and demonstrated 2 years ago at Sun One and TechEd 2006.  There are several implementations of Fast Infoset for .NET. 

Even if you don't focus on the message shape, you can still focus on the transport itself.  There are WCF channels for FTP, SOAP, UDP, and other protocols.  You can see a list of various writings at that link about building custom channels as well as samples for various protocols.  But we all agree that HTTP is now the cockroach of protocols... not even a nuclear war could kill it off at this point.

Admittedly, .NET and Java interop has trended towards SOAP over HTTP for years, but there has always been the interest in tighter coupling between the platforms. To this end, JNBridge has done a fantastic job of bridging the divide between the 2 camps.  My favorite example to point out is what JNBridge has provided in their JMS adapters.  I was priveleged to do an interview with Wayne Citrin of JNBridge to see their .NET and BizTalk adapter implementations for JMS connectivity. 

Great to see that there is further discussion and research behind interoperability between .NET and Java... this is an area that is still very much needed and is still very much in its infancy.