DCOM Server

So far we've looked at how to use COM through a client application. To the client, the mechanics of COM programming are pretty simple. The client application asks the COM subsystem for a particular component, and it is magically delivered. There's a lot of code required to make all this behind-the-scenes component management work. The actual implementation of the object requires a complex choreography of system components and standardized application modules. Even using MFC the task is complex. Most

professional developers don't have the time to slog through this process. As soon as the COM standard was published, it was quickly clear that it wasn't practical for developers to write this code themselves.

When you look at the actual code required to implement COM, you realize that most of it is repetitive boilerplate. The traditional C++ approach to this type of complexity problem would be to create a COM class library. And in fact, the MFC OLE classes provide most of COMs features. There are however, several reasons why MFC and OLE were not a good choice for COM components. With the introduction of ActiveX and Microsoft's Internet strategy, it was important for COM objects to be very compact and fast. ActiveX requires that COM objects be copied across the network fairly quickly. If you've worked much with MFC you'll know it is anything but compact (especially when statically linked). It just isn't practical to transmit huge MFC objects across a network.

Perhaps the biggest problem with the MFC/OLE approach to COM compone nts is the complexity. OLE programming is difficult, and most programmers never get very far with it. The huge number of books about OLE is a testament to the fact that it is hard to use. Because of the pain associated with OLE development, Microsoft created a new tool called ATL (Active Template Library). For COM programming, ATL is definitely the most practical tool to use at the present. In fact, using the ATL wizard makes writing COM servers quite

easy if you don't have any interest in looking under the hood. The examples here are built around ATL and the ATL Application Wizard. This chapter describes how to build an ATL based server and gives a

summary of the code that the wizard generates.

Where's the Code?

One of the things that takes some getting used to about writing ATL servers is that they don't look like traditional programs. A COM server is

really a collaboration between several disparate components:

l Your application

l The COM subsystem

l ATL template classes

l "IDL" code and MIDL Generated "C" headers and programs

l The system registry

It can be difficult to look at an ATL based COM application and see it as a unified whole. Even when you know what it's doing, there are still big

chunks of the application that you can't see. Most of the real server logic is hidden deep within the ATL header files. You won't find a single

main() function that manages and controls the server. What you will find is a thin shell that makes calls to standard ATL objects.

In the following section we're going to put together all the pieces required to get the server running. First we will create the server using the

ATL COM AppWizard. The second step will be to add a COM object and a Method. We'll write an In-Process server because it's one of the

simpler COM servers to implement. An In-process server also avoids having to build a proxy and stub object.