In-Depth

Can .NET keep cross-platform promise?

• By Tony Baer
• July 1, 2001

With .NET, Microsoft threatens to level the playing field. Although it is still hard-wired to Windows, .NET provides out-of-the-box XML support for interacting with the outside world. More importantly, .NET leverages Microsoft's new Common Language Runtime (CLR), an innovative framework that provides a consistent method for languages to compile and execute. In place of Java's "write [in one language] once, run anywhere" philosophy, CLR reverses the equation by allowing developers to write in almost any language and run it consistently on Windows. ".NET compares very favorably to J2EE," according to Dean Guida, CEO of component marketplace Infragistics in Cranbury, N.J. ".NET makes it easy to use XML to expose component methods through firewalls, while C# is just as productive as Java."

And there is more [see the sidebar, "The shape of Visual Studio.NET,"]. ".NET standardizes access to security, APIs and XML - all in a single development model," explained Robert Green, lead product manager for Microsoft. For example, the visual IDE is made the same for all four Microsoft languages, so that C++ and C# now get the same simplified front end that made VB famous. The brass ring, however, remains the built-in XML support, enabling application objects or components to now be deployed as Web services with a simple check-off in a pop-up dialog box.

"This is the first time that something really new and exciting has come out since Java," pronounced Jay Glynn, development manager for a large insurance company and author of the recent book, Introducing .NET.

Brave new world
.NET has become the catchall to describe Microsoft's new strategy for software as services. For application development, that means incorporating Web services into the development environment, rather than as an afterthought. To make that possible, .NET uses a new, unified hub-and-spoke programming model designed to make different languages interchangeable.

Here is how it would work: If a language generates objects that support the CLR interfaces, it should compile and execute in the same way as any other CLR-compliant language, which will enable development organizations to mix and match languages based on the availability of skills and expertise and the requirements of the particular task.

For example, during the development of a complex e-commerce application that involves integration with legacy systems, the mainframe component could be written using a .NET-compliant version of COBOL, while the commerce engine could be written in C# and the clients could be written in VB or HTML. The entire application, using a mix of languages, could be translated to Intermediate Language (IL), a compiled language at the heart of the CLR framework that performs a function analogous to Java's byte code. Then the IL could be compiled to native code using a Just-In-Time compiler that pre-compiles frequently used code fragments. The developer could then check off whether the application would be deployed as a Web service. If so, the logic would be communicated automatically via SOAP and would be able to use emerging Web services standard APIs such as Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI).

On the face of it, guaranteeing the interoperability and consistent execution of multiple languages sounds like a pretty tall order. Thanks to Microsoft's long track record of third-party support, it has already signed partner agreements ensuring that numerous languages, from COBOL to Python and Perl, will become CLR-compliant. Glynn is pretty bullish that the scheme will work. "We've seen a few demos with COBOL, LISP and Eiffel, and we haven't seen any major glitches," he noted. In the long run, he expects to achieve roughly 98% plug-and-play reliability for dropping in code from different languages.

Among other highlights, the .NET forms designer will support full inheritance—a useful feature for controlling the proliferation and maintenance of front ends associated with various families of applications or components. A new X Copy deployment feature, which provides all the necessary supporting information about a component in the DLL, will eliminate the need to specially enter meta data to the Windows Registry. Additionally, a new concept called namespaces will provide a standard way of grouping related classes and data structures together.

The sleeper, however, is built-in XML support. With Visual Studio.NET, developers can deploy applications or components as Web services by simply marking a check box. Additionally, all programming documentation will be generated as XML documents, making background information and meta data easy to share with other developers, departments or external business partners.

A key building block of .NET's XML strategy is extending Active Data Objects (ADO), allowing them to be expressed as structured XML documents. "With ADO.NET, you can have a service-based approach that is fully transparent," said Chris Keyser, distinguished engineer for Horsham, Pa.-based VerticalNet, who is beta testing .NET.

According to Keyser, transactions performed locally could be run as SQL queries against an internal database, while transactions with business partners could be expressed as XML data objects that can easily pass through firewalls and interact with other applications or databases. Alternatively, ADO.NET XML objects could be used as a building block of an internal Enterprise Application Integration (EAI) strategy as well.

"While we are certainly a Microsoft shop, we know that in the real world we must interact with other systems," said Keyser. "XML is the best way to do that." Naturally, the proof will be in the pudding. As any veteran of EDI, the original form of B2B commerce, will testify, there are always differences in the way that business partners structure their data. "This is an area that we need to prove out," Keyser admitted, noting that with emerging standards such as eXtensible Stylesheet Language (XSL), there might be standard ways of bridging the differences.

Where the rubber meets the road
Adjusting to new syntax or getting accustomed to new features has long been a fact of life for anyone who has lived through the upgrade process. However, the major architectural changes in store with .NET show that the revisions will be anything but incremental.

Obviously, the degree of impact will vary based on your programming background, predicted Keyser. "If you're coming from a C++ background, you have already gotten used to the constraints of OO, so the transition probably will not be that much of a challenge," he said. Of course, the same would apply to C#, Microsoft's Java-like adaptation of C++, which, as a new language, has not yet built a large enough user base to be affected visibly.

It is a different story for the VB community, however. "VB obviously has more changes than any of the other .NET languages," according to Sam Patterson, CEO of Kennesaw, Ga.-based ComponentSource, a component marketplace. "It has morphed from a pseudo- to a pure object-oriented language," he noted.

Since its introduction more than a decade ago, VB became one of the most popular languages because of its simplicity and flexibility. VB pioneered the visual development practices that are taken for granted today, while allowing developers considerable freedom down to the smallest syntax details. "It was so loose on the way you defined variables that you could create almost anything on the fly," according to Guida. For instance, in classic VB, data types did not have to be specified, functions could be called directly by name or through a reference or pointer, and you could number arrays using any convention.

VB also provided hints of advanced productivity, such as inheriting interfaces—as long as you remembered where the parent files were. And it provided the technology base for Visual Basic Controls, which led to the emergence of the first plug-and-play component aftermarket.

However, in the .NET world, VB's ease and flexibility have become double-edged swords. With .NET, development languages have been transformed from islands to spokes around a CLR hub. VB developers will have to change more than a decade of ingrained practices to get with the program. Furthermore, the sheer size of the community will make VB.NET the epicenter for .NET migration. When it comes to gauging the impact of change, VB.NET will be where the rubber meets the road.

"We removed the perceived ceiling on what you could do with the language," explained Dan Hay, lead enterprise product developer for Visual Studio.NET. "There are syntax changes between VB6 and VB.NET, but the semantics will remain the same," added Ari Bixhorn, product manager for Visual Basic.

In many cases, VB.NET will prove easier than its predecessors. For example, a new streaming feature for reading large files eliminates the need to embed separate open, read and close file commands. Other useful additions include reflection, which allows libraries to be opened on remote machines without having to know their location, and stronger, Java sandbox-like security, with which programs are denied access to local file systems on target devices.

But there are also a number of syntax changes for performing tasks that have been changed to comply with CLR standards. For example, functions must now be called by their rightful names, rather than by references or parameters; arrays must start with the number zero; and the names of specific data types, such as "Integers," have been changed. Individually, these changes are the kinds of annoyances that are typical with new releases. However, in the big picture they could translate into death—or more likely, discomfort—by a thousand cuts. According to Manohar Kamath, consultant and a principal behind .netWire, an independent news site devoted exclusively to Microsoft's .NET initiative, these changes could easily touch as many as 50% to 60% of VB programs.

In response, Microsoft has taken several measures to cushion the impact. For example, it is providing VB programmers the option to continue working in VB6, which will remain available as a standalone product. (Microsoft did the same thing when VB6 replaced VB5.) "We won't force anybody to take advantage of VB.NET's new capabilities," said Microsoft's Hay. Bixhorn, in turn, made assurances that Microsoft would support VB6 "for years into the future."

Additionally, Microsoft bowed to VB developer protests and rescinded some of the proposed changes that were initially intended to make VB more consistent with C++ and C#, covering the default value for "True," the behavior of certain Boolean operators and the declaration of arrays. With the rollback, these commands will look like classic VB, rather than the other .NET languages.

Not surprisingly, the VB.NET syntax rollbacks have met with mixed reaction. "I never used the old default true values, so this will not be a big deal," said Kamath. But others like Glynn expect future problems. "You could argue it both ways," he conceded. "But it would have been better to take the hit now. In the long run, it's better that the languages be as consistent as possible," he said, noting that the inconsistencies could be a source of bugs for developers working in VB and the other .NET languages who might get confused about which values to use where.

Microsoft's Bixhorn disagrees on whether any inconsistencies exist, claiming that all languages have their own unique syntax, including those built for .NET. "Consistency in .NET does not mean that all languages have uniform semantics or syntax," he said. Instead, he maintained that .NET's consistency would stem from its common underlying infrastructure.

Nonetheless, the syntax changes are nothing compared to the impact of adopting full-blown object-oriented programming models. Given VB's heritage, much of which was built around modest, standalone departmental applications, the transition could be significant. "With VB.NET, you will not be able to get around OO because CLR deals with objects," said Kamath, adding that means dealing with features like full inheritance and polymorphism. According to ComponentSource's Patterson, that should not prove a huge obstacle. "You will have to learn some new constructs," he said, adding that the bigger issue would be figuring out how to handle reuse.

Waiting for version 3?
Obviously, .NET remains futureware at this point, although with the second beta, the languages and the IDE that comprise it have stabilized. And with the Microsoft's recent announcement, Visual Studio as a product is now a known commodity. But, as of press time, Microsoft had not yet announced definite release dates.

"For enterprise production applications, J2EE is here today while .NET is still beta," noted Infragistics' Guida. When .NET enters formal release, Guida expects to "find positives on both sides." Thanks to J2EE, Java offers an established standard for enterprise deployment supported by multiple e-commerce infrastructure vendors and has a means for shoehorning Java into smaller footprints than are possible with the initial generation of .NET. Yet, because Microsoft has had the luxury of starting later, it was able to build XML support directly into .NET, rather than having to retrofit it.

Like any major upgrade, most development shops are likely to take their time getting their feet wet with .NET. Most expect to continue relying on older technologies, especially for many VB applications. Admittedly, part of the lag stems from the old adage of waiting for version 3 of any Microsoft product, because that is supposed to be the point when things stabilize. The other part is sheer common sense: it takes time to adapt to any new architectural changes of .NET's magnitude.

"People did not see Java's potential right off the bat," recalled Glynn. He added, "When VB came out, it was not until version 3 that it took off." His group, which is responsible for about 430,000 lines of code for a major insurance company, plans to use VB.NET and other .NET technologies, but will not necessarily migrate their entire VB code base. That is also the case for VerticalNet, which has similar ambitious plans for .NET. Although it is a relatively new organization with a young code base, VerticalNet still has backward compatibility concerns like most companies. "There is no way that I'm going to deploy everything under .NET," said Keyser.