Running .NET apps at the speed of accelerated Java

When most people talk about the integration of .NET and Java, the first thought that comes to mind is the XML-based services oriented architecture that Microsoft and IBM first had in mind when they formed the Web services Interoperability Organization (the WS-I).  The idea, which is old hat for most by now, was to use XML as a lingua franca through which .NET-based components and Java-based components could exchange instructions (very remote procedure call-esque) and data (the return from the those instructions) with little or no concern as to what type of application server (.NET or Java) was hiding under the hood at either end. 

From the customer's point of view, The final benefit? Well, your .NET programmers don't have to learn an ounce of Java programming. a standardized XML-based RPC architecture means greatly simplified and cost-reduced integration of dissimilar systems (be they internal, with partners, customers, or whatever) when compared to the old, highly customized way of doing things.  On the vendor side, the abstraction was taken to just the point that it makes it easier for companies like IBM and Microsoft to steal customers from each other.  After all, if the outward facing interfaces of the systems needing integration only need to be XML-based and it doesn't matter what's under the hood, then Web services make it possible for a completely Java-based back-end to be cloned with .NET (and vice versa) as long as the outward facing XML APIs are the same.  Good for customers.  Good for vendors.

But that's what comes to mind when most people talk about .NET and Java.  When Mainsoft's sales and service vice president Ron Johnson and Azul's chief marketing officer Shahin Khan talk about integrating the two, the end result may be the same (a substitution), but the way they'll go about doing it as a result of an partnership  the two companies will be making this coming Monday is very different.

In order for runtimes like .NET and Java Virtual Machines to be the middleware that they are without grinding to a halt, the code that developers must feed to them must be half-way between a source code state that might normally be associated with such interpreters and a machine code state that's native to the host operating system or microprocessor.  For .NET, the level of code is called Microsoft Intermediate Language  (MSIL) and for Java, it's known as Java bytecode.  But the problem with the convenience of middleware for many has always been the performance penalty that one must pay to have it.  The brute force of processors can only get you so far in overcoming the problem.  What you really need, if you trust the instincts of some innovative thinkers, is hardware that's been customized, tuned, and optimized to speed up very very specific types of software operations.  In other words, we're not talking about generalized PCs or servers that can handle all sorts of tasks.  We're talking about supercomputers that are basically designed to handle one task.  Pumps if you will.  Dedicated hardware based XML accelerators like the one built by Eugene Kuznetsov and team at DataPower (eventually acquired by IBM) are a good example.

In Java land, where code tends to run rather non-deterministically (in other words, unpredictable performance where IT departments prefer predictability), some problems can be tackled in the software.  For example, in a recent podcast interview, BEA's Developer Relations vice president Franz Aman and its chief technology officer Rob Levy said they had made improvements in the JRockit JVM that were akin to suddenly realizing your car had dual exhaust pipes that it wasn't taking advantage of.  Improvements that allowed for Java code to continue to run while garbage collection (a periodic and necessary memory sweep-up process that normally gums up the works) takes place.  But according to Azul's Khan, software only gets you so far and that's when you need a pump like the one with custom silicon that Azul makes: an "network attached processor" with 96 cores or more designed to do nothing but turn heavy Java loads into featherweight runs.

Whereas the old-school (I can't believe I'm calling it old school) XML integration basically puts a layer of XML-based abstraction between the two normally incompatible code-bases, the new school a la Mainsoft and Azul's partnership takes .NET source code, turns it into Java bytecode (that's Mainsoft's job) and then runs that code on Azul's network attached processor.  The result, say the two men, isn't just a new form of Java/.NET integration, it also is a way of taking .NET applications that still run out of gas after being put on the most powerful systems, and squeezing even more peformance out of them. 

The final benefit?  Well, your .NET programmers don't have to learn an ounce of Java programming.  If all your developers know how to do is VB.NET, that's apparently not a problem.  The idea sounds cool, but, in the  is available as an MP3 that can be downloaded or, if you’re already subscribed to ZDNet’s IT Matters series of audio podcasts, it will show up on your system or MP3 player automatically (see ZDNet’s podcasts: How to tune in), I challenged Khan and Johnson with as many questions as I could in an attempt to find a weakness it what is their partnership is looking to accomplish.  Were there any? Well, you'll just have to listen.