Content area
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. Many developers following the .NET story assume that Microsoft will port .NET to non-Windows platforms, but no such plans have been announced. A healthy skepticism should be brought to any evaluation of .NET.
* Exploiting Microsoft's enterprise application strategy .NET, should prove a dream for IT managers. The pre-beta version is inherently scalable and easy to build and deploy, saving valuable time and resources
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 Windown NT 3.51 will soon be obsolete.
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 pre-beta edition of .NET.
We've been testing the NET pre-beta (now downloadable from msdn.microsoft.com/net) 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 pre-beta, 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 oftrepeated myth that .NET is built on top of COM. We've even read that .NET is nothing more than a Java-- like 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 pre-beta is restricted to Windows 2000, but the released version of NET should support Windows 95, 98, Millennium Edition, 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 run time 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 run-time software out to client machines, but the run time should not raise client hardware requirements. Any PC that is now capable of running Microsoft Office will have no trouble running the .NET run time.
Not all .NET applications will require installing the run-time 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 pre-beta 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-intime compiled to .NET's IL (intermediate language) and executed by the .NET run time. 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 pre-beta 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++ applications 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 run-time profile is not language-- dependent as it is now.
Internal applications
It is too early to start training inhouse 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 beta, 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 Java 2 Enterprise Edition and Linux developments. We expect all three will have substantial roles in the enterprise application scene of 2002 and beyond.
THE .NET MANAGEMENT INITIATIVE rograms written for NET are called managed applications. IL (intermediate language) executes via NET's Common Language Run time (CLR). The CLR allocates and releases memory, locates and loads external NET objects, handles communication with remote applications, and sets up a number of processor-independent data types.
By managing storage and gating access to system resources, the CLR makes applications safer. A managed application can neither access memory that doesn't belong to it nor manipulate objects that have already been released. This catches the largest category of software failures before they can harm other programs or the operating system. By defining a set of processor- and language-independent data types,the CLR rescues programmers from having to perform tedious and error-prone data conversions. Data transmitted via the network from one managed application to another arrives intact and immediately ready to use.
The NET object model is completely transparent. Programmers define objects using their chosen language's native methods. The CLR automatically registers and publishes these objects for use by other local and remote applications. This is a vast improvement over COM (Component Object Model), the existing Windows object model that was introduced with Windows for Workgroups (Windows 3.11). COM requires manual object registration and data conversion,and remote object access is tricky at best. Once managed Windows applications become the norm, the barriers to Windows' enterprise use may finally come down.
Tom Yager is the East Coast director of info World's Test Center. He's been coding, managing, and architecting Unix and Windows development projects since 1986. He can be reached at tom_yager @infoworld.com.
Copyright Infoworld Media Group Sep 4, 2000