In-Depth

.NET builds on best of COM

• By Russell Lewis
• August 1, 2001

In 1995, Microsoft and DEC published the Component Object Model (COM) specification and it has been the keystone of development using Microsoft platforms ever since. Creating a chart in Excel and pasting it into a Word document, using Outlook to send an E-mail and developing an application in Visual Basic all require COM.

COM separates the definition of what a component can do, which is exposed as an interface, from how it actually does it. This separation makes a powerful case for COM and creates several benefits. It allows component code to evolve without affecting client applications through versioning. It provides language neutrality by making components "black boxes." It encourages component reuse. It gives developers flexibility in choosing the location of components and the ability to build large complex systems from small self-contained units. And it allows developers to create three-tier architectures with components as the middle or business tier.

Because the mechanisms COM requires are built in to the Windows operating system, Windows developers can build applications without worrying about building infrastructure services first. This has caused more applications to be developed on Windows platforms, and those applications are being developed faster than ever. This speed is good for Microsoft and good for Windows developers, but where does that leave non-Windows developers?

In theory, COM is available on Macintosh and Unix platforms. But COM requires a registry, which is built in to Windows and is merely emulated on other systems. So, in practice, COM has become a Windows-only solution. In one sense, this can be seen as good news for Microsoft because it encourages developers to adopt the Windows platform. On the other hand, not every organization chooses to adopt a Windows platform, so this factor limits wider adoption of COM.

This limitation becomes clearly evident in building Internet applications. ActiveX controls are COM components that can be embedded into a window or into a Web page. There is a huge third-party market of controls providing functionality such as grids, graphs, calendars, 3D viewers, sockets and so on. This market is so large that Visual Basic's original rise to popularity is often credited to the abundance of this type of product. Of course, Internet Explorer supports ActiveX controls, because it is a Microsoft product. But Netscape Navigator does not, because of issues with cross-platform compatibility and security, among others. Consequently, the use of ActiveX controls is mostly limited to intranet and extranet sites where it is possible to mandate the browser type and operating system that site visitors use. From an IS perspective, this is a shame, because COM is aimed at using programming resources more efficiently by reusing components that have already been developed.

DCOM and COM+
Enterprise computing is all about distributing the processing load, and COM has mechanisms to help achieve this. Distributed COM (DCOM) extends COM to allow components to be registered on one machine and called securely from a client program on another computer. DCOM is a connected architecture in which the client computer "pings" the object every 120 seconds to inform the server process that the client is still running. It uses ports that are normally blocked by firewalls so that, in practice, it is of limited use where the Internet separates the client from the object. This limitation can be a major problem for developers who want to use Microsoft technologies to build distributed applications that use the Internet.

Because most COM components are written as Dynamic Link Libraries (DLLs), the components are usually hosted or run in either Microsoft Transaction Server on NT4 platforms or in COM+, which is built in to all Windows 2000 platforms.

Figure 1 shows the three-tier architecture and the two main client types—Active Server Pages (ASP) for Internet access and a choice of Visual Basic, C++, FoxPro and so on for building LAN- or WAN-based Windows client applications. This architecture forms the basis of the Microsoft Windows Distributed interNet Application architecture (Windows DNA). Data access and system services play a part in DNA, too.

Figure 1

Active Server Pages for Internet access, along with Visual Basic, C++ or FoxPro for building LAN-or WAN-based Windows client apps, form the basis for the Microsoft Windows DNA architecture.

Through sophisticated object management services such as caching and Just-In-Time activation, COM+ enables components to be scaled to support a few, several hundred or even a thousand clients. As the number of clients increases, additional COM+ servers can easily be added to accommodate the client requests. In theory, doubling the number of servers should double the number of clients that can be accommodated; in practice, however, there are several limiting factors, including the database, that create diminishing returns.

COM is dead, long live COM
The .NET platform represents an evolution of COM. It is built on a component object model, and it will be used to create software components that are completely object-based. It is tempting to refer to component development in the future as "COM.NET." After all, Microsoft has named ADO's replacement ADO.NET and ASP's replacement ASP.NET.

Between COM and "COM.NET" Microsoft has come up with replacements for the registry and DCOM. All the current features and benefits of COM remain, but the mechanics have been redesigned to address some of the major weaknesses apparent in COM today.

Moreover, COM is still part of the enterprise. Any company that has built COM components will want to continue to use them but may call them from .NET clients. After all, COM promotes the concept of developing components to be reused by language-independent clients. But if the .NET framework does not use the registry, how can it access a registry-bound COM object?

.NET is designed to be able to interact with COM. It needs to do this anyway to provide support for COM+, which is considered part of the .NET framework, and may be used to host .NET as well as COM components.

This facility is provided by the .NET framework's "COM InterOp" layer, which provides access between what .NET calls "managed" code (code that is running within the .NET framework) and "unmanaged" code (such as COM). This is two-way access, so a COM client could also access a .NET component.

IS departments that want to sample the .NET development experience may choose to start by exploring ASP.NET, because doing so only requires that the .NET platform be installed on a server machine and, even in early beta versions, the platform itself is very stable. (The platform is stable, but the Visual Studio 7 development environment is less so.) In Figure 2, the code behind the ASP.NET page accesses an existing COM component that is hosted in COM+. ("Code behind" is a Microsoft term to describe the language page that coexists with the HTML page. It may be written in any of the .NET languages including C# and VB.NET.) The existing COM component could be a production component because the ASP.NET page is treated as just another client. ASP.NET pages can be introduced onto an existing site without any disruption to the existing ASP pages. The Web server simply looks at the file extension of the requested page—if the extension is .aspx, the request is treated as an ASP.NET request.

Figure 2

The code behind the ASP.NET page accesses an existing COM component that is hosted in COM+. ASP.Net pages can be introduced onto an existing site without disrupting the existing ASP pages.

Figure 2 also shows a thick client accessing the component via HTTP. Thick clients can be sophisticated applications that often have a rich user interface and are typically built using Java, C++, VB and so on. Since .NET supports remote procedure calls over HTTP, it is possible to connect thick clients over the Internet.

One of the main reasons that applications built today are not normally built as Web applications is that Web browsers offer a limited user interface—as the name suggests, they are good for browsing documents. Additionally, browser versions behave differently and are difficult to control from a programming perspective.

.NET client applications can connect to a component that is on the Internet, in a COM+ server on the LAN, in a custom-built host application or on the local machine. This flexibility in .NET has the potential to win the support of many software architects. For many people, the ability to call components over the Internet plugs a hole that always existed in Windows DNA.

Remoting in .NET
Traditionally, DCOM was automatically invoked whenever remote access was required between a client and COM object. This allowed developers to get on with the business of making the calls rather than worrying about details of how those calls would be transmitted and received.

The .NET platform introduces remoting as a concept that demands attention. Specifically, the transport mechanism and channel for communication must be specified. Channels use "pluggable" serialization formatters that convert call data into a format that can be transported down a wire.

The SOAP formatter, for example, converts the call into an industry-standard XML format for remote procedure calls. This format, SOAP, is intended primarily for use over HTTP, because it is text-based and it is unlikely to be blocked by corporate firewalls. Another way of using HTTP transport is via the Web server, which can host either an ASP.NET listener application or a Web service.

Table 1 shows how the different remoting options are likely to be used in practice. The transport and serialization format may be specified either within the application or externally via a configuration file. The latter is preferable because it does not involve modifying program code.

The binary formatter, when it is used over the TCP channel, is likely to give the best performance within a WAN or LAN environment. This is not an option for the Internet, because it requires an open port for the TCP socket, but it is the default mechanism for .NET-class library applications and it requires no special configuration.

HTTP via IIS using SOAP is the most flexible and is used automatically by ASP.NET and Web service applications. The Web server handles security, communication with COM+ services is straightforward, and it requires no additional configuration. On the other hand, it delivers the poorest performance.

No more registry?
.NET classes are packaged in self-describing assemblies (DLL and .exe files). The assembly contains the program code and a description of what that code does—somewhat like an interface does in COM. The result is that there is no longer any need to register the interface and consequently Microsoft claims an end to "DLL hell" as we now know it. It also paves the way to running .NET on operating systems other than Windows.

Bearing in mind that a DLL component always requires a host process (memory space) in which to run, there are a lot of component configurations that are now made possible using the .NET framework (see Table 2).

Components that are used by a single client do not have to be registered. Instead, the client application looks for the class in its own directory. This means that for many applications, installation will become a simple matter of copying the .exe and the DLL files to the same directory on the target computer. It also means that the potential for name clashes is reduced. For example, a PC may have three applications installed, each with its own built-in tax calculator. In COM, a call to New TaxCalculator would result in the creation of whichever tax calculator object was last registered—not necessarily the right one. Under .NET, the call would simply create the right tax calculator from the TaxCalculator class in the current directory.

Shared components are intended for use by several client applications. They are typically deployed on the client side because it needs to interact with users. One example of this is the type of application that completes a postal address when a zip or postal code is entered. In this case, the component needs to be deployed in a virtual directory called the Global Assembly Cache (GAC). The GAC, like the registry, acts as a central database of component registrations, but it does far more. Shared components must have a Strong Name, which includes a public/private key pair to allow clients to verify the authenticity of the component.

One of the GAC's neatest tricks is its ability to house different versions of the same component, even running those different versions side-by-side. Administrators can configure client applications to use specific versions or ranges of versions. Suppose an update to the address completion component is installed, and it works well with most of its client applications, but it occasionally causes one client to crash. In this case, the affected application could be configured to use the previous version of the component while the other clients used the latest version.

Web services
One of the most exciting features of the new platform is the concept of exposing components over the Internet. Web Services components are just like any other middle-tier, business-rules objects except that the methods can be accessed by calling a Web server. This means that the same consistent functionality offered would be available 24x7, from anywhere in the world, using any device that can access the Internet.

Imagine a company that processes credit card payments offering a Web service that allows the following data to be posted securely to its Web server: merchant ID, card number, expiration date, amount, customer name and billing address.

Upon receiving this call, the Web service validates the data and credits payment to the company's account based on the merchant ID. It then responds securely by returning a SOAP XML block containing the authorization code and a transaction number.

Data is returned by such a Web service when a client asks for its Web Service Description Language (WSDL). WSDL is an XML-based standard, that has been agreed upon by the industry, that lists the methods available from the Web service with their arguments and return types. Web services are therefore self-describing.

Web services may be accessed by other Web services or accessed directly by user interfaces. Since the data is sent using Get or Post and XML, clients do not have to be Windows-based or even .NET-based. A client application for this service could be an e-commerce site or it could be a handheld device with a card reader to swipe the credit card and a keypad to enter the amount.

Offering Web services either as a revenue stream or as a way of disseminating specific information—such as the information that would be held in a database—is a common goal for the 36 founding member companies of Universal Description, Discovery and Integration (UDDI) of Business for the Web. This organization is responsible for WSDL and two of the leading members, IBM and Microsoft, host UDDI Business Directories of available Web services.

There are other project types that can be built using .NET, but in many ways these represent the next version of the programming language. For instance, in Visual Basic, VB.NET offers features that are new and improved over the previous version. However, to deploy applications of this type, developers will need the .NET framework installed on the target machines when using current versions of Windows (see Table 3). (In Table 3, project types that require the .NET framework to be installed on the host machines are marked with a * symbol.)

Of course, by the time the .NET framework becomes commonplace, the notion of browsers being the best form of Internet client may be out of date. Apart from their ability to communicate using HTTP, browsers are currently valued because they eliminate application developers' installation concerns. Developers can safely assume that a browser is available on the user's machine. Because .NET eliminates reliance on the registry and allows programs to be installed by simple file copy, it seems likely that installing a sophisticated client application will be trivial.

Conclusion
COM delivers real benefits to enterprise developers through binary interoperability and abstracted interfaces. The increased importance of the Internet has highlighted the limitations of Microsoft's Windows DNA.

ASP solved part of the problem by bringing the client into the same physical tier as the middle-tier components and only using the Internet to deliver a user interface in the form of HTML. But ASP is just a script, performance is unremarkable and the user interface is just a Web browser.

The .NET platform is an exciting evolution that builds on the best aspects of COM. COM+ is still the host for remote objects, components are still accessed via interfaces, and existing COM components—even existing ActiveX controls—are still part of the big picture. Microsoft is keen to point out that .NET is not only about multi-tier development, but there can be no doubt that .NET's impact will be felt most by those developing distributed enterprise applications.

Developers following the component model are going to reap rewards in productivity as they start to integrate .NET into the development portfolio. Investments made in building COM business objects and ActiveX controls will be protected and leveraged as developers discover the wide capabilities of the .NET platform.

Nobody wants to be the only adopter of a new technology, but nobody wants to be left too far behind, either. The .NET platform will ship as a built-in part of the next versions of Windows, but for corporations that are standardized on Windows NT or 2000, deployment of the .NET platform is likely to be restricted to Web servers. This deployment will allow those corporations to build and profit from Web Services and ASP.NET applications.

Microsoft now has a platform that delivers a complete distributed architecture, augmented by new features such as Web Services. Even cross-platform interoperability is a reality using the remoting features of .NET. It may take a year or more for developers to work out how best to use the diverse features of .NET and for those features to become part of the technological landscape.