Chapter Summary

< Free Open Study >

Chapter Summary

This chapter gave you the lowdown on COM's location transparency. We began by reviewing the three relationships a client and server may take: in-proc, local, and remote. From here, we discovered that stubs and proxies are the keys to making a server's physical location an unnecessary detail in a client's mind. We dug into the stub/proxy architecture, and discovered a set of new COM interfaces and the associated managers that help stubs and proxies communicate with the RPC layer.

Next we examined COM's marshaling options. Custom marshaling allows you to have complete control over the process of moving data between processes using the IMarshal interface. Standard marshaling is almost free when you write your interfaces in IDL, leaving you to the task of creating the DLL for this stub/proxy. Universal marshaling is as free as you can get, as you have no need to worry about a separate DLL to distribute; however, you must constrict all your interfaces to use variant compliant parameters, and configure each interface to point to the CLSID of the universal marshaler .

We examined how to create a local server. As you have seen, this requires a new way to work with server lifetime management, as class factories must remain active as long as there is a connected client. We then examined the AppID, and saw the various ways that we can configure security contexts for our servers. Finally, you learned how to use the dcomcnfg .exe utility to configure and access remote servers, and wrapped up by examining remote access on the programmatic level using the COM library.

< Free Open Study >

Part III: Core ATL

Chapter List

Chapter 6: An Introduction to the Active Template Library
Chapter 7: ATL COM Objects and COM Exceptions
Chapter 8: COM Object Identity and ATL
Chapter 9: Component Housing and ATL

< Free Open Study >

Chapter 6: An Introduction to the Active Template Library

Objectives:

Generate component housing with the ATL COM AppWizard.
Insert coclasses using the ATL Object Wizard.
Understand ATL's registry scripting language.
Populate your interfaces with methods la ATL.
Learn to add properties to a COM interface.
Leverage ATL's support for COM text manipulation.
Understand ATL's debugging options.

So far, this book has focused on the development of COM DLLs and EXEs using IDL and the C++ programming language. As you may have noticed, writing your COM servers without framework support is a "labor of love" and is often not the best approach for a large-scale COM project, given the sheer amount of repeat code. On the upside, however, ATL is of little use to developers who lack a firm understanding of the underpinnings of COM, which you have gained during the previous five chapters. The purpose of this chapter is to get you up and running with ATL and the common CASE tools used during the development process. In this chapter we will not be diving in too deeply into the underlying internals of ATL, leaving that task for the remainder of the book.

< Free Open Study >

The Need for ATL

Up until this point in your COM journey, you have been writing every line of source code from scratch. Chapters 3, 4, and 5 were devoted to illustrating what can be done with "raw COM" using C++ and IDL. I hope you have found that although COM can be a bit much to swallow in one session, it can eventually be digested into fairly clear pieces. However, I would also imagine you noticed the following points about implementing COM servers "in the raw":

Implementing component housing requires similar code for every DLL server. In essence, what really changes is the code behind DllGetClassObject(). Based on a CLSID, create the correct class factory and return an interface pointer to the client. EXE servers are just about the same in this regard. Call CoRegisterClassObject() n times for n number of class factories, revoking them when WinMain() is shutting down.
COM class factories are all very similar. A class object basically requires modifying IClassFactory::CreateInstance() to specify the name of the coclass you are creating.
All COM objects implement IUnknown, which basically means two lines of code for every interface supported by the object, as well as hooks for reference counting.
Adding the correct registry entries for a COM server is (to put it kindly) a pain. Typically, servers register AppID, ProgID, CLSID, TypeLib, and interface information.

In short, COM requires lots of boilerplate code. These days, no sane developer would begin a new COM project from scratch-unless you need to learn the basic building blocks of COM. After that point, you really should adopt a component framework to help you with the repeat code demanded by COM.

The Active Template Library (ATL) supplies the help you have been longing for. This collection of C++ templates, macros, and classes is aimed at helping you develop very small and very fast COM servers. ATL contains code to assist you when developing traditional COM objects, ActiveX controls, Automation servers, MTS components , and MMC Snap Ins as well as full-blown Windows executables. As an added bonus, ATL 3.0 has extended the number of CASE tools, giving you just about as much flexibility and support as MFC developers have grown accustomed to.

Much like MFC, ATL projects begin by accessing CASE tools to provide a minimal and complete code base for the project at hand. The ATL COM AppWizard is used to create the component housing for your COM server and is typically followed by using the ATL Object Wizard to insert any number of coclasses into their new home.

Unlike MFC, ATL has much slimmer support for Windows application development. This does not imply you could not use ATL to build the next version of Microsoft Word or a high-profile graphics application. What this does imply is that ATL does not offer you the full set of wizards, data structures, and helper classes found in a Windows application framework such as MFC.

For example, there is no Dialog Data Exchange (DDX) support in ATL. You do not have utility classes (such as CPoint, CRect, CPen, and so forth) wrapping Windows drawing primitives. ATL is a component framework aimed at helping you build robust COM servers. To this end, if you are a C++ developer, ATL is the absolute best choice around. Specifically, ATL is here to help you with the following aspects of your COM server development (among others):

ATL supplies all necessary component housing code for DLL and EXE COM servers.
ATL provides support for IUnknown using a table-driven implementation of QueryInterface().
ATL provides a default class factory for every ATL coclass. If you require a more sophisticated class object, ATL will help you develop your own.
ATL provides server self-registration, avoiding messy REG file maintenance.
ATL also offers support for a number of COM services we have yet to discover: rich error information, dual interfaces, and connection points, as well as support for COM threading models and object aggregation.

I'm sure this partial list has you sold already, so let's begin to get our hands around the Active Template Library.

< Free Open Study >