COM Frameworks

[Previous] [Next]

Some tools are already available to help reduce the frustration induced by OLE and COM. For example, the Microsoft Foundation Class (MFC) framework is designed to make it as easy as possible for C++ developers to write applications and components that take advantage of OLE by providing a set of classes that encapsulate its use. Microsoft Visual Basic, the most popular Microsoft development tool, distances developers even further from the complexity of OLE. However, only with the release of the Visual Basic Custom Control Edition was it possible to develop COM objects using Visual Basic. Until then, Visual Basic had been a tool only for COM consumers, not for COM developers.

Certainly, developing COM objects using MFC and Visual Basic is much easier than trying to create them using raw C or C++. In fact, for all but the most advanced developers, attempting to face the wrath of COM without the shelter of a framework can be tantamount to developer suicide; those frameworks have been the only feasible approach. Along with the benevolent level of abstraction they provide, however, MFC and Visual Basic carry a fairly stiff penalty: they both saddle applications and components with a large run-time dynamic-link library (DLL). This extra freight inherent in MFC and Visual Basic has created a chasm between "lean and mean" COM development using straight C and C++ and the "fat, dumb, and happy" approach taken by those frameworks.

Galileo

A few years ago, in an attempt to provide solutions to the problems facing COM developers within Microsoft, several members of the Visual C++ development team were formed into a new team created to design the Enterprise edition of Visual C++, code-named Galileo. The new team determined that internal corporate developers were adopting a multitiered strategy wherein application logic is divided into roughly three layers: user services, business services, and data services, as described in the following sidebar.

Standard Three-Tier Client/Server Architecture

The three-tier architecture shown in Figure 1-1 has recently received a great deal of well-warranted publicity. Because this architecture is particularly applicable to COM and the Active Template Library (ATL), it is worth describing in some detail here. Basically, a client/server system can be divided into three basic architectural parts, or tiers. Although these tiers don't necessarily correspond to separate physical locations on a network, they represent a logical separation of functionality that gives developers a great degree of flexibility, scalability, and performance.

Figure 1-1. The standard three-tier client/server architecture.

• The client tier provides the graphical user interface (GUI) for presenting and gathering information from the user. This tier, which resides on a local machine connected to the Internet, an intranet, or a LAN, is generally implemented using a custom front-end application or, increasingly, a set of Web pages displayed in a browser. Traditional COM-based technologies—Microsoft ActiveX controls, Microsoft Active Documents, and OLE servers and containers—reside almost exclusively in this tier. Development tools such as MFC, Visual Basic, Microsoft Visual FoxPro, and Microsoft Office are especially well suited for the client tier because of their rich support for user interfaces and OLE.
• The middle tier is a set of components that encapsulate the application logic and business rules of the system. These components respond to user requests by performing specific business tasks. This tier, which typically resides on one or more Microsoft Windows NT Server and Microsoft Windows 2000 Server machines, is the home of Microsoft Internet Information Server (IIS), Microsoft Active Server Pages (ASP), Microsoft Internet Server application programming interface (ISAPI) DLLs, lightweight COM objects, Microsoft Component Services—formerly known as Microsoft Transaction Server (MTS)—components, out-of-process COM servers, and Distributed COM (DCOM) servers. In our opinion, the middle tier is where the power and beauty of COM really shine! Not coincidentally, the middle tier is also the tier best suited for development with ATL.
• The data source tier defines, stores, and manages access to the system data. This tier, which may reside on a combination of servers and mainframe computers, is typically implemented using a database management system (DBMS) such as Microsoft SQL Server. By separating the services of the data source from the other components in the system, the structure and access to the data can be modified, scaled, or even rearchitected with minimal effect on the client and middle tiers.

 

Naturally, the Galileo team decided that COM would be the most instinctive method of communication between the layers of logic. However, they concluded that the COM objects developed for the business services layer—the middle tier—would need to be built with size and speed (rather than ease of development) in mind, even if it meant an increase in the time required to develop those objects. Furthermore, the objects would need to be capable of supporting access from many clients simultaneously. Keep in mind that at that time the Microsoft tools for COM development were entirely focused on simplicity rather than performance. In other words, when it came to addressing the COM needs of multitiered, multithreaded business applications (to say nothing of the even stricter needs of Internet applications), MFC and Visual Basic simply couldn't cut it.

To provide a middle-ground solution between lethargic OLE-centric frameworks and no framework at all, the Galileo team designed and created a small C++ library that would simplify COM development without sacrificing component size and speed.

The BaseCtl Framework

As tends to happen whenever developers on different teams strive to find better ways to solve the same sets of problems, another Microsoft team was simultaneously making similar inroads toward a lightweight C++-based COM framework. Specifically, members of the Visual Basic team were developing an in-house set of C++ classes for creating tight, quick OCXs (now known as ActiveX controls). Although their framework—eventually known as the ActiveX BaseCtl framework—was quite a bit more difficult to use than MFC (partially because BaseCtl wasn't really designed and documented for external use), it was still much easier to use than raw C++. Furthermore, its performance gains over MFC were impressive enough to warrant a great deal of excitement. Indeed, in early 1996, the BaseCtl framework was considered significant enough that it was released to the world as an undocumented (and unsupported) set of sample code.

The Active Template Library

The Galileo team incorporated many of the aspects of the BaseCtl framework into their own C++ library and named the resulting code the Active Template Library (ATL). Actually, at one time ATL was called the ActiveX Template Library, but rumor has it that the "X" rating was removed to make ATL suitable for young developers!

At first, ATL was available only to a lucky few within Microsoft. After a short time, however, so many internal developers were asking for permission to use the code and providing suggestions for future enhancements that Microsoft decided to make ATL available to everyone. ATL 1.0 was released to the Visual C++ Web site at the end of April 1996, and ATL 1.1 (which included a number of bug fixes and an improved set of documentation and sample code) was made available shortly thereafter. Eventually, after further enhancements—including support for developing various flavors of ActiveX controls—ATL became the tool of choice for developing lightweight COM objects. In fact, ATL 2.1 was made an officially supported part of Visual C++ 5.0, and wizard support for it was added to Microsoft Developer Studio. As of this writing, the most recent release of ATL is version 3.0, which ships with Visual C++ 6.0.