Running .NET apps at the speed of accelerated Java

Running .NET apps at the speed of accelerated Java

Summary: 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).

SHARE:
TOPICS: Software
12

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.

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

12 comments
Log in or register to join the discussion
  • Why not just use mono if you're going to code in .NET

    If you're going to code in .NET, it's already been shown that .NET runs faster than J2EE systems. If you want cross platform, stay away from Windows calls in .NET so that it can run in MONO.
    georgeou
    • And how many do you think will do that?

      Reviewing history of Java and its use on windoze do people not
      care much about cross-platform programming.

      The mass of people are like children, they need to be encouraged
      or preferably forced to do the right thing or they will abide by the
      law of least resistance by default.
      Mikael_z
      • And thus...

        ... the reason why people are writing applications in .Net or Java that have no business being run in either of those environments. Writing .Net or Java code is easy; running it in a highly scalable environment is nearly impossible. Both frameworks, as well as their respective applications servers, do way too much work and processing on each and every request compared to what the application actually needs at any given time. Anything this big should be written in natively compiled bytecode, or a very fast interpreted language such as Perl. To write something this big in .Net or Java is just plain lazy. If your hardware budget is running into multi-millions or dollars merely for an an XML processing server, there is not reason why you cannot afford some quality "old school" programmers who can write good C/C++ code.

        J.Ja
        Justin James
      • Is this elitism that turn people off

        "The mass of people are like children, they need to be encouraged or preferably forced to do the right thing or they will abide by the law of least resistance by default"

        This is exactly why people are turned off to the cross-platform cult. Their needs and requirements don't matter, they should be treated like children.
        georgeou
    • Mono is C sharp

      There is a lot of confusion about .Net , as well there should be.

      .Net is really 2 programs from MS;

      The first is C# and the .Net Framework. This part is very simular to Java and is what Mono does.

      The other is compiler project that allows you to write in any language you want using MS tools and the compiler converts it all to common runtime even if parts were written in 2+ seperate programing languages. VB programers thus won't have to learn the very C/C++ like languages such as Java or C# but can still work on projects with the other programers. For example if you have Visual Studio Express you can write programs in KPL (Kids Programing Language) and the tool will both compile your works and could also convert your code to C# so that C# programers can also work on your project.

      The marketing department also got a hold of .Net, using it as Buzz word, and started renaiming things .Net so they sound new and cool (Even though its was just another 1/2 to 1 version up of what it was).
      Edward Meyers
    • Not an option

      [i]
      If you're going to code in .NET, it's already been shown that .NET runs faster than J2EE systems. If you want cross platform, stay away from Windows calls in .NET so that it can run in MONO.[/i]

      Mono can only run things that have compatibility with Mono implemented libraries. And you can guess how quickly you can break that chain. It just won't work with anything but the simplest of applications. You will not get near of the performance either.

      I don't even bother commenting on the J2EE slower than .NET. Obviously people choose to believe MS sponsored marketing FUD.
      tero_t_vaananen@...
  • 96 procs? And you're running Java or .Net?

    That is pretty silly! If your budget is so big, and your application is so critical, and speed of execution is so important that you're building out 96 CPU machines just to handle .Net/Java translation, I have a news flash: you should not be using either language!

    As is painfully clear from this article, both .Net and Java just do not scale well and are painfully slow. If someone came to me and said, "we are planning on building a megalithic appliction to handle a few hundred thousand people at a time, do we want .Net or Java?" I would say to them, "you want to be running natively compiled bytecode." C/C++ in a CGI environment will run circles around either of those languages. Perl will run circles around either of those languages, and it is an interpreted language.

    One of the biggest problems with using .Net or Java for a big application is that the frameworks are incredibly wasteful, and the application servers are even more wasteful. The "everything but the kitchen sink" mentality makes coding for them easy and quick. But if you take a look at the Tomcat source code (obviously, I can't look at the IIS source code, but I would imagine that it is about the same), what you see is something that is doing an awful lot of work that is not needed for every page view. Session creation and tracking, checking for user input via GET, POST, and more, etc. A custom crafted solution built from the ground up does not do these things, it allows the programmer to check what is needed and do what is needed only when it is actually needed. Plus, it is written in a much faster language to begin with, and it has the advantage of being natively compiled bytecode.

    You can also write a much more optimized system this way. For example, instead of having this monster server just processing these XML requests, you can have load balanced, commdity servers handling the front-end processing (parsing the request, constructing the HTML response, etc.) and making an RPC request to a giant parallel processor machine on the backend that handles session tracking, database lookups, etc.

    Anyone using XML over HTTP or SOAP obviously does not care about performance. Anything riding on top of HTTP for a "chatty" communication simply will not be fast. Like I said, if you're building servers that big, you would be much better served by hiring better programmers and custom crafting something, instead of taking "the kitchen sink" frameworks and throwing hardware at them.

    J.Ja
    Justin James
    • I think you forgot something

      In the world of being paid, of coding solutions to business problems, your solution doesn't work.

      Yesterday we custom built a unique solution to every problem. We used C++, didn't reuse much code. Performance was a lot more critical, because the hardware didn't perform so well. This is why most companies have a few legacy apps they need to run through a command prompt and output DBF files they later feed into a database.

      Today, we trade off a little bit of performance in order to (1) reuse as many components as possible, and (2) write software that can be updated easily as the underlying business processes change.
      jdsal989
      • What makes Java or .Net so unique?

        [i]"Today, we trade off a little bit of performance in order to (1) reuse as many components as possible..."[/i]

        What makes Java or .Net so special that they encourage code reuse more than C++? They are all object oriented. I have been eharing this code reuse stuff for years and years and years. C++ code is just as reusable as Java or .Net, when it is written correctly.

        [i]"Today, we trade off a little bit of performance in order to ... (2) write software that can be updated easily as the underlying business processes change."[/i]

        I can understand where you come from on this. C++ is quite less readable and is harder to manage than either Java or .Net, so yes, maintenance and upkeep of C++ is much more unpleasant than Java or .Net.

        But at the end of the day, I think the payoff is worth it. If the OSS crowd can manage, maintain, and update all of the C/C++ code that makes up UNIX and many other open source projects, I would imagine that a corporation can do it as well.

        J.Ja
        Justin James
        • Easy question, easy answer.

          What makes Java and the .NET languages so special? That?s an easy one but it has to be answered from two perspectives: first the languages, then the libraries.

          From the standpoint of the languages alone, Java and C# are way more limited. Only C++ has true templates, meta-programming (the new Generics in .NET are so restrictive they provide very little additional power), and a dozen other features. But power on the wrong hands is dangerous and Java and C# are good preventing not-so-smart programmers from filling the code with unnecessary macros and the exceedingly complex object models cloudy minds seem to love.

          From the standpoint of the languages is where Java and .Net both excel. The Standard C++ Library is impressively ugly and not very intuitive. Years ago it took me minutes to create a TCP viewer in Java, and that was the first time I used Java?s socket APIs!
          Writing it in .Net was even easier since I didn?t have to spend any time with Java?s GridBagLayouts and its cousins. WinForm?s layouts are managed more intuitively.
          But try doing that in C++!

          Don?t get me wrong I love the C++ language, I just don?t agree everybody knows how to use it without abusing it and I think the .Net Framework and the Java Libraries have not match in the C++ world (maybe Trolltech?s Qt? No idea).
          royalstream
        • Easy question, easy answer (CORRECT)

          What makes Java and the .NET languages so special? That?s an easy one but it has to be answered from two perspectives: first the languages, then the libraries.

          From the standpoint of the languages alone, Java and C# are way more limited. Only C++ has true templates, meta-programming (the new Generics in .NET are so restrictive they provide very little additional power), and a dozen other features. But power on the wrong hands is dangerous and Java and C# are good preventing not-so-smart programmers from filling the code with unnecessary macros and exceedingly complex object models cloudy minds seem to love.

          From the standpoint of the libraries is where Java and .Net both excel. The Standard C++ Library is impressively ugly and not very intuitive. Years ago it took me minutes to create a TCP viewer in Java, and that was the first time I used Java?s socket APIs!
          Porting it to .Net was even easier since I didn?t have to spend any time with Java?s GridBagLayouts and its cousins (WinForm layouts are managed more intuitively).
          But try doing any of that in C++!

          Don?t get me wrong I love the C++ language, I just don?t agree everybody knows how to use it without abusing it and I think the .Net Framework and the Java Libraries have not match in the C++ world (maybe Trolltech?s Qt? No idea).
          royalstream
  • Too simplistic

    This is too simplistic, bordering on FUD.
    (1) Use of GC is not limited to .NET/java and often yields same or better performance as manual memory management in practice. (2) .NET code is always compiled before it is loaded, not interpreted or run "in containers". That is why .NET does not have a "virtual machine" as the java VM. Java can be fairly easily compiled and run in this fashion as well, afaik.
    mawi