Application servers, RPC stacks and more

Tim Anderson at ITWriting interviewed me on various subjects related to Mono: the Novell/Mainsoft collaboration on Mono; the application server space and Mono's plans in terms of Indigo.

I would like to expand on what I said on the interview as am afraid that the relation between Mainsoft and Novell was not clear.

Mainsoft collaboration: Mainsoft's product Grasshopper is a solution that allows .NET ASP.NET applications to run on a J2EE server by doing code translation from CLI bytecodes into JVM bytecodes. Mono allows the same, but instead of running on a J2EE server we provide an ECMA CLI execution system to execute the code.

Although we both use different virtual machines to provide this feature, the class libraries that are used to provide the functionality are shared between Mainsoft's Grasshopper product and Novell's Mono. As of a few weeks ago we finally merged both codebases into a single tree. There are some small differences in the hosting environment which we cope with by using a number of defines: TARGET_JVM, TARGET_J2EE and in some cases a completely different implementation of the class exists (XXX.jvm.cs) which is compiled instead of the XXX.cs equivalent.

As part of this work to integrate the and we are also integrating their build process into our continous build infrastructure to ensure that we do not accidentally break the build of the Java-version of the Mono class libraries.

On Indigo: A lot of folks are curious about Mono's plans regarding Indigo and I have not really had an answer in the past because I had not investigated Indigo in depth.

There are a number of issues with Indigo: the first one is that am not very well versed on all the things that Indigo has to offer, but I lament certain things about its design. In particular, in this hyped world of Services Oriented Architecture where the contract must be precisely spelled out instead of adopting an IDL-like language a meta-language built on top of sprinkling attributes left and right to decorate classes, methods and so on. This meta-language created by the sprinkling of attributes is likely more obfuscated than any possible IDL incaranation of the same idea. The fact that now interfaces are the thing to describe should have been a warning to the designers that it was probably time to look at IDL again.

My second issue with Indigo (and in general with many of the new WS-* protocols) is that the more they evolve, the closer they look and feel like the complex high-level CORBA services. Those services that got CORBA the reputation it has today.

In the interview I point out that Indigo is not available today as a released product and that it will take a few years before we see Indigo-based applications.

In the meantime, ZeroC is a startup founded by some ex-CORBA people who wanted something simpler. They have a fairly interesting OO RPC system called Ice which has many of the features that application developers need today and is available on a wide range of languages: Python, PHP, C++, Java and .NET languages. You can read about how it compares to CORBA and SOAP, it is available today and its dual licensed: free for free software applications and you can obtain a commercial license for your commercial applications.