InformIT: Sams Teach Yourself Visual Studio .NET 2003 in 21 Days

Windows of the Past

In the past, millions of applications were developed for Windows-based systems using a variety of development tools and languages. Visual Basic, C++, Delphi, Java, and Access provided a great toolset that enabled you to write applications for Windows. The problem that crept up again and again was how these applications communicated with each other and how they could communicate with data beyond the departmental server. Because each language has its own runtime environment, they all run essentially inside their own box, using their own way to communicate with core system services. There was no way to get outside the box. When a new feature to a language had to be added, it would be bolted somewhere on to the runtime environment through a new set of API calls. If you wanted to access the new features, each language had its own way of doing so. And, as was the case with Visual Basic, many features were simply not available because the runtime environment of Visual Basic couldn't support them. This problem seemed to have been solved with the Windows Distributed Internet Applications (DNA) architecture, which was based on Component Object Model (COM) components moving data between different types of distributed applications.

Windows DNA and COM

Writing distributed Internet applications became easier as the model of COM services that Windows servers could provide became more stable and widespread. You could write an Active Server Pages (ASP) application and access methods, properties, and events through the object model of components running inside of COM+ services on remote machines. Figure 1.2 shows the flow of a DNA/COM application.

Figure 1.2 DNA and COM in action.

Windows DNA became more accepted because of the ease with which a Visual Basic 6 developer could write components that could be accessed from any other type of application, as long as he had access to the Windows 2000 server that the COM+ services were running on. This is where the problems begin.

If you provide data to outside vendors in an application, you must write the user interface and code to allow them access to what they need. There's no simple way to expose methods, or allow other applications to call methods, on your servers. You have to open up security and give them the keys to the farm, which isn't what IT managers are likely to do. If you want to maintain multiple versions of a component, you are in a very bad way with COM. Because COM makes heavy use of the Registry and doesn't allow for a simple versioning policy, you're essentially maintaining the same component forever. You're constantly adding new features to it, but leaving the old stuff in. This is one of the big rules of COM: Thou shall not change any interfaces to your components. Doing so makes for a huge headache in deployment. If you change an in or out parameter on a method, you've broken the functionality of the component. That means all the components must be recompiled to restore the correct interfaces that the caller expects. After a component is deployed, how do you easily scale it across machines while maintaining any state data that the code expects? This isn't a trivial problem, and companies have spent millions of dollars writing state machines to handle the scalability problems that come with COM.

All these issues are solved with the .NET Framework. The services provided by the .NET Framework enable us to expose methods over HTTP and SOAP through XML Web services. The Windows Registry is not used in .NET, which eliminates the DLL Hell of the past and gives us a strong versioning policy. There are many ways to maintain state data, so we can scale applications across processors and across servers with no worry about crashing the applications running on those servers. This all starts with the common language runtime and the base class libraries.

The Common Language Runtime | Next Section

Previous Section