Tangled in the Threads

Jon Udell, December 12, 2001

.NET Development, Java Deployment

Will IL-to-Java mapping give us the best of both worlds?

.NET development can be really sweet. But it's no fun upgrading and maintaining Windows production boxes. Is there a way to have our cake and eat it too?

Last week I installed and test-drove the near-final versions of VisualStudio.NET and the .NET Framework. The test machine was running last year's beta 1, not this year's beta 2, but I don't think that was the only reason the upgrade seemed daunting. Windows OS upgrades have, over the years, grown less pleasant and more anxiety-producing for me. In this case, as with beta 1, the end-game -- to install a software-development toolkit, VisualStudio.NET -- required at least two, and possibly three, different OS upgrades, depending on how you count. These upgrades are packaged into a multi-reboot procedure called Windows Component Update. In my case, for a machine already running Windows 2000 Server, the components turned out to be:

Thankfully all this software now comes on a DVD-ROM, eliminating the CD shuffle. And as before, in acknowledgement of the multi-reboot requirement, the procedure optionally takes an administrative password that you can use to automate logins across reboots. I opted out, though, because I really didn't expect this entire procedure to run to completion unattended. And it didn't. The upgrade wizard complained:

This machine is not a Web server.

Say what? You could have fooled me. It had been happily running IIS 5 for over a year. But the wizard went on to explain that, for the purposes of this Windows Component Upgrade, IIS 5 alone didn't qualify as a web server. The Windows 2000 Front Page Extensions must also be present, so that VisualStudio.NET can create web projects on the server. I found and installed the Extensions, and then ran through the Component Update. This step cost me a third reboot, because I'd neglected to uninstall the existing version of the .NET Framework.

OK, I probably should have read the instructions and saved myself that last reboot. But two reboots would have been scary enough, considering that each lays down a swath of code -- Win2K SP2, IE 6 -- which you might want to give some serious thought to before applying to a production machine. Then there's the issue of cluttering up that production server with client components such as IE 6 and FrontPage. People from non-Microsoft environments find it weird that an IE install is required for a server deployment. Why, they wonder, can't the needed components bundled with IE, such as the XML parser and XSLT engine, be unbundled for server-only deployment?

Installing .NET is, finally, an experience that does not leave you feeling serene and confident about the state of your system. Once it's done, though, the results are wondrous. Everything about the .NET Framework -- the supported languages, the use of web services protocols, the server-side controls and events, the deep appreciation of XML, the close integration with transactional services -- has been carefully thought out and beautifully executed. For those of you who haven't drunk the Kool-Aid, I'll sketch out some of the more appealing aspects of .NET.

For starters, I've been pleasantly surprised to find how productive you can be using just the tried-and-true basic tools: emacs and the command line. Like Java, and unlike C or C++, the .NET languages (C#, VB, JScript) can be used very effectively from the command line, even when you go at things directly without the support of makefiles. You do have to compile your code down to IL (intermediate language) .EXEs or .DLLs, and you do have reference DLLs using the compiler's /r switch, but it's nevertheless very simple to write web apps, web services, or Win32 apps that use the Framework.

Dealing with Data in .NET

It's also very convenient to work with file-based, as well as server-based, data. This can be a huge productivity boon. When I'm working in Perl, for example, I'll very often prototype my data by creating Perl data structures, persisting them to files with the help of the Data::Dumper module, and then tweaking the contents of those files -- by hand or with a script -- in order to explore the effects of changing data on my application. In .NET there's a wealth of support for serializing data to and from XML. The equivalent of Perl's Data::Dumper, in .NET, is the serialization support in the System.Runtime.Serialization namespace, which can be used to persist objects in binary form, or as XML (specifically, SOAP). Separately you can use the System.Xml.Serialization namespace to serialize objects as XML, along with the XML Schema metadata to make those objects portably self-describing.

The XML serialization plays out to great effect when used with the ADO.NET Dataset. This object, unlike the recordset supported in the current ADO, can include multiple tables and encode relationships among them. In ASP.NET applications, it's the Dataset that you bind to controls, such as lists and grids, in order to create a web UI to the data. As always in this situation, it's handy to be able to bypass the database server machinery and go straight at your test data with a text editor. And that's trivial to do. Suppose you've loaded up a dataset with a table from some SQL server. Saving an editable version of this data is as easy as: 

ds.WriteXml("dataset.xml");

or, to include an XML Schema: 

ds.WriteXml("dataset.xml", System.Data.XmlWriteMode.WriteSchema);

Incidentally, if you are working in VisualStudio.NET, you won't have to look very hard for methods and arguments. Typing the period after "ds" brings up a dropdown list of Dataset's properties and methods. Typing "W" takes you straight to WriteXML. Typing a left parenthesis pops up another window that shows you all eight variations of the first argument: filename-as-string, XmlWriter, TextWriter, Stream, and so on. Typing the comma after "dataset.xml" brings up another window asking for a System.Data.XmlWriteMode. Typing a period after "System.Data.XmlWriteMode" brings up another window that knows about the available modes. I'm a command-line kind of guy, and still prefer to use emacs for most things including C# programming in .NET, but this kind of deeply-woven documentation is seductive enough to make me switch frequently to the built-in VisualStudio.NET editor.

Once you've written out that dataset, and possibly read and altered the file in a text editor (or with a script), you read it back in and bind it to a grid control just as easily: 

ds.ReadXml("dataset.xml");
DataGrid1.DataSource=ds;
DataGrid1.DataBind();

In production, of course, you're going to be sourcing the data from a real database. Here too, though, it's handy to be able to generate XML views of data for debugging and inspection. For example, you might package up the database access code as a web service, like so: 

using System.Data;
using System.Data.OleDb;
using System.Web;
using System.Web.Services;

namespace MyDS
    {
    [WebService(Namespace="http://udell/DS/")]
    public class MyDS : WebService
        {
        private static string sConn = 
            "provider=sqloledb;server=(local)\\MyDB;database=MyDB;";

        [WebMethod]
        public DataSet GetDS()
            {
            DataSet ds = new DataSet();
            OleDbDataAdapter odb = 
                new OleDbDataAdapter("select * from myTable", sConn);
            odb.Fill(ds)
            return ds;
            }
        }

Now, if you add a web reference to your project that points to this service, you can bind a data grid to the Dataset returned by that service like so: 

localhost.MyDS ws = new localhost.MyDS();
ds = ws.GetDS()
DataGrid1.DataSource=ds;
DataGrid1.DataBind();

As a bonus, you can call that web service directly, using SOAP or, even more convenient, just good old HTTP GET, like so:

http://localhost/MyDS/Service1.asmx?op=GetDS

This returns the same stuff -- the XML Schema, and the raw XML data -- to a browser or other HTTP client.

The seamless declarative way in which you make arbitrary methods SOAP-callable, and WSDL-discoverable, is of course one of the key benefits of .NET. It's not intrinsically hard to do these things, with or without .NET, but when the support is implicit and baked into the platform, it becomes much more likely that people will choose to do things this way. And that, in turn, makes it more likely that we'll all benefit from the network effects that arise from widespread adoption of this style.

Development versus Deployment

There's lots more to like in .NET. For example, in ASP.NET, the successor to ASP, many of the classic burdens of web programming are lightened. With server-based controls, interactions among objects on the page can be handled in a much more robust and more portable way than with client-side DHTML-style programming. Managing state across page invocations is greatly simplified, and there's support for decoupling that state from an individual server and floating it across a server farm. It's also very appealing to be able to compose server-side controls from simpler primitives. The approach reminds me a lot of Apple's WebObjects -- you can build event-driven, object-oriented things which express their behavior in the form of vanilla HTML that's consumable by any browser.

So what's not like? In terms of .NET itself, I'm very impressed. It's the foundation on which .NET rests that worries me. The reliability of Windows is certainly improving, but I feel much more comfortable deploying web applications and services on non-Windows platforms. Until recently, I've assumed that would be possible only when (or if) a robust non-Windows implementation of the .NET CLR (Common Language Runtime) and .NET Framework becomes available. Such efforts are underway, notably Ximian's Mono, and I hope they'll succeed.

Recently, I got to wondering again about the possible role of Java in all this. There was a flurry of interest, a few months ago, in Microsoft's effort to recast its (rather outdated) Visual J++ as a .NET language. This, to me, seems not particularly interesting. If you want to develop for .NET, it's the framework that you need to master. Viewing that framework through the lens of Java, rather than C#, may be somewhat helpful, but in the end I've got to believe that anyone competent to master the framework will have little trouble mapping from Java to C# syntax.

A Different Slant on Java and .NET

There is, however, a whole different take on Java and .NET. The folks at Halcyon Software have long been in the business of enabling Windows-style web software to run on non-Windows platforms, using Java as a foundation. Their InstantASP product, for example, will run ASP software on Linux, Solaris, and most exotically, the IBM S/390 mainframe. Now, the company is working on a plan to run .NET software on these platforms, again by way of Java. The strategy hinges on two components -- a language module that translates IL into Java, and a runtime module that, Halycon says, will be a cleanroom Java implementation of the .NET Framework.

Naufal Khan, Halcyon's VP of Engineering, admits that this is a hugely ambitious effort. He points out, though, that because .NET is in many respects a Java clone, many concepts are straightforwardly mappable. What about those things which lack analogues in J2EE? Here, Khan says, Halcyon's experience implementing ASP and ADO for Java give it a foundation it can now build on to recreate ASP.NET and ADO.NET. In theory, what this means is that you'll be able to build a .NET web application or service, and then deploy it on any platform, using any webserver with a servlet interface.

Does this idea make sense? The pros include the maturity of the JVM, broad acceptance of Java, and keen interest in bypassing the cost, reliability, and security concerns of Windows deployment platforms. There are significant cons, of course. Compatibility is the major issue in any kind of emulation scheme such as this. Performance might be too, since you'd trade execution of compiled IL for interpretation of Java bytecodes (though, in practice, this hasn't been a showstopping issue for server-side Java). Still, it's a fascinating project. I've always thought portable .NET meant a portable CLR and Framework. But when you think about it, IL is an extremely rich and well-specified representation of code, data, and metadata -- just the things that a successful emulator would need. Maybe IL emulation will let some people develop .NET-style on Windows, but deploy elsewhere. In other words: have their cake and eat it too.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He is the author of Practical Internet Groupware, from O'Reilly and Associates. Jon now works as an independent Web/Internet consultant. His recent BYTE.com columns are archived at http://www.byte.com/tangled/

Creative Commons License
This work is licensed under a Creative Commons License.