Microsoft’s .Net impact
Find out what’s behind Microsoft’s so-called Java killer
By now you’ve read and heard plenty about .Net, Microsoft’s new enterprise application strategy. A nuts-and-bolts rundown of .Net’s features may leave you asking, “Does this have anything to do with me?” If you run Windows on desktops, .Net’s impact will be minimal, and if you operate Windows servers, .Net could require making a few changes. But if you specify, design, develop, or implement enterprise software or Web applications, keep in mind that .Net drastically changes Windows’ profile. You can’t use the old rules to determine Windows’ suitability for an enterprise task. The assumptions, design models, and development techniques that have worked since Windows NT 3.51 will soon be obsolete.
Note: For more on .Net, see this article’s sidebars, “The End of Native Code?” and “The .Net Management Initiative.”
TEXTBOX:
TEXTBOX_HEAD: The Bottom Line
Microsoft .Net software development kit
Business Case
Software written for .Net is inherently more scalable, distributable, and safe than Windows COM; .Net applications are much easier to build and deploy, reducing time to market and post-deployment support costs.
Technology Case
Microsoft has co-opted much of Java’s appeal but in a way that allows Visual Basic, C++, and JavaScript developers to take part. Developers can focus on functional code rather than arcane facilities such as COM and the 32-bit Windows API.
Pros
- Simplifies access to enterprise services
- New object model coexists with COM
- Stable and complete in prebeta form
- Shifts responsibility away from programmers
Cons
- Portability to Unix and Linux not announced
- No published road map for implementation or pricing
:END_TEXTBOX
In contrast to the poorly defined Windows DNA (Distributed Internet Architecture), .Net is a tangible and easily defined software product. It is an application framework, meaning that it provides applications with the system and network services they require. The .Net services range from displaying graphical user interfaces to communicating with other servers and applications in the enterprise. It replaces Windows COM (Component Object Model) with a much simpler object model that is implemented consistently across programming languages. This makes sharing data among applications, even via the Internet, easy and transparent. .Net also substantially improves application scalability and reliability, with portability being a stated but not yet realized objective. These are clear benefits demonstrated by the prebeta edition of .Net.
We’ve been testing the .Net prebeta (to download, see Resources) for several weeks. Attendees of Microsoft’s Professional Developers Conference (PDC) 2000 in Orlando, Fla., ourselves among them, received a stack of CDs with the .Net preview, plus a good deal of software not yet released. The combination of the .Net components adds up to a strikingly complete picture of what .Net will be on its release. With an uncharacteristically stable and feature-rich prebeta, relationships already in place with third-party tools suppliers, and even books on .Net topics, Microsoft could drive .Net to market with head-spinning speed. But until Microsoft publishes its schedule for .Net’s release, it’s best to plan for a debut that’s months rather than years away.
Secrets and lies
To weigh .Net’s likely impact on your enterprise, begin by understanding how .Net fits with Microsoft’s current and planned Windows architectures. Much of the consternation generated by .Net comes from IT and IS people who fear it will disrupt existing servers and applications and from developers who are concerned that their software will quit working or that existing technologies are marked for extinction. Although it’s true that .Net will replace the creakier elements of Windows’ enterprise software architecture, .Net promises to coexist with established Windows facilities. In fact, until .Net is integrated into a version of Windows (expected to occur with Whistler, the successor to Windows 2000), .Net will be optional. If you don’t plan to use .Net, you don’t need to install it.
The cloak of secrecy that Microsoft wrapped around .Net prior to PDC 2000 gave rise to all kinds of rumors, many of which still persist. One shocker making the rounds is that Microsoft is abandoning COM and Windows 2000’s COM+. Strangling COM and COM+ would be astonishingly boneheaded, and naturally Microsoft officials say the company has no such plans. Instead, Microsoft is migrating key COM+ middle-tier services, including messaging and transactions, to .Net. Applications that access these services via COM+ should continue to run. According to Microsoft officials, the development teams handling the migration are the same ones that created COM+.
A paradoxical companion to the “death of COM” rumor is the oft-repeated myth that .Net is built on top of COM. We’ve even read that .Net is nothing more than a Javalike wrapper for COM. This is not so. The services supplied by COM, including object data representation and remote execution, are implemented independently (and better) in the .Net framework. It will take time to move all Windows facilities, particularly media-related COM services such as DirectX, to .Net. Therefore, many .Net applications will contain calls to COM interfaces, although .Net itself does not make use of COM.
Another popular rumor is that .Net applications will run only on Windows 2000 or later, the logic being that Microsoft wants to force users to upgrade. This is also false, according to Microsoft. The prebeta is restricted to Windows 2000, but the released version of .Net should support Windows 9x/Millennium Edition, Windows NT 4.0/2000, and future Windows releases.
Finally, we’ve read that Microsoft is abandoning Active Server Pages (ASP), its current server-side Web application framework. The .Net runtime does include a new version of ASP called ASP+, but ASP and ASP+ run in tandem. Web applications that use ASP will continue to use existing facilities; no code or configuration changes are required.
From the bottom up
Your planning for the advent of .Net can start at the bottom, with your organization’s client systems. Windows clients won’t need any updates until you start hosting .Net applications on your servers. When that time comes, you may need to push the .Net runtime software out to client machines, but the runtime should not raise client hardware requirements. Any PC that is now capable of running Microsoft Office will have no trouble running the .Net runtime.
Not all .Net applications will require installing the runtime software on client machines. ASP+ applications can do all of their work on the server. As long as your PCs are updated with the latest version of Internet Explorer, end users will have all they need to tap into server-based Web applications.
Depending on the applications you’ll be running, .Net may require changes to your network configuration. Because .Net uses HTTP to transport data and to give clients access to server applications, desktop PCs listening for incoming HTTP connections from .Net servers may be identified as Web servers by network analyzers.
Server planning
Microsoft warns against using the prebeta of .Net on production systems. When .Net ships, you should be able to install it on any Windows NT or Windows 2000 server without disrupting existing applications. The only potential issue we can see is .Net’s replacement of Windows’ Visual Basic Script (VBScript) and JavaScript (JScript) interpreters.
.Net makes substantial changes to Windows’ scripting environment. The VBScript interpreter has been phased out. All Visual Basic and VBScript code will be just-in-time compiled to .Net’s IL (Intermediate Language) and executed by the .Net runtime. If you run Web applications that use server-side VBScript code, you could experience minor problems.
The JScript interpreter is gone, too, replaced by a JScript/ECMAScript (European Computer Manufacturer’s Association Script) compiler written from scratch in C# (Microsoft’s new programming language). Users of the .Net prebeta are reporting compatibility problems with existing server-side JScript. Microsoft officials claim that the company is squashing these bugs quickly, but be watchful of server-side JScript code after you upgrade a server to .Net.
Some shops should plan for rising CPU and memory utilization as applications migrate to .Net. If you currently use Visual Basic or Java applications on your servers, migrating them to .Net should improve their performance and resource efficiency. Hardware requirements for services and applications currently written in C++ could take the biggest hit. The .Net framework supports C++ and gives developers the option of generating native code or IL. If the developer opts for IL, the C++ application’s CPU and memory utilization will increase sharply.
There is no pat formula for determining how much additional memory and CPU power you’ll need to move applications to .Net. If you can, run your first crop of .Net server applications in a closely monitored environment. Once you measure the impact of one .Net application, you can project those metrics to all .Net software. All .Net programming languages compile to IL, so the runtime profile is not language dependent as it is now.
Internal applications
It is too early to start training in-house developers on .Net, at least in any organized way. Your technical leads should download the prebeta and prepare to pass their knowledge to staff developers. Be explicit about keeping prerelease tools off production servers and workstations. If extra workstations are scarce, you can safely run .Net in a separate partition.
Enterprise application designers and architects need to factor .Net into their planning for applications that are at least 12 months away from initial coding. .Net’s most significant effect on Windows enterprise architecture is its encapsulation of enterprise services. Instead of designing solutions based on a specific language, such as Java or Visual C++, architects can focus their efforts on the suite of enterprise services exposed by .Net.
Curiously, .Net does not expand Windows 2000’s collection of enterprise services. Every copy of Windows 2000 ships with strong middleware (e.g., transaction and messaging services) and database services, but they have gone largely unnoticed thanks to COM+ and outdated development tools. COM+ presents developers with a confusing programming interface that changes depending on the language and tools used to develop the code. .Net presents a unified, consistent services interface, in much the same way Java does, but .Net does not restrict you to a particular language.
Many developers following the .Net story assume that Microsoft will port .Net to non-Windows platforms, but no such plans have been announced. For this reason, if your project will immediately require running on non-Windows servers, .Net is not yet a player. If portability is a design goal, you might throw the dice. Any application written solely to .Net that forsakes the use of COM+, direct access to DLLs, and other Windows-specific facilities should run outside Windows. Overall, the risk is the same as the one you take when you base a design on any emerging technology.
You should schedule the migration of existing Windows server code to .Net not because you have to but because the effort will be rewarded in the form of applications that are safer, more scalable, and easier to maintain. A .Net application flies at a much higher altitude, so it is less susceptible to changes in the underlying architecture. Dependency issues that plague current Windows development efforts are gone, so deployment should be streamlined.
Healthy skepticism
You should bring a healthy skepticism to your evaluation of .Net. We are watching .Net unfold with a critical eye, and so far, .Net looks like Microsoft’s most clued-in endeavor since Windows NT 4.0. It now falls to Microsoft to stay this course, to remain active in the evolution and implementation of industrywide standards, and to see that the final .Net is as bulletproof as its design objectives dictate. Thanks to the public prebeta, there are thousands of professional snoops looking for flaws in .Net. Whatever your bias, you should track the .Net buzz as closely as you follow the Java 2 Platform, Enterprise Edition and Linux developments. We expect all three will have substantial roles in the enterprise application scene of 2002 and beyond.
