Now for what we've all been waiting for. Hands up who thinks DCOMcnfg is a really cool tool. Uh-uh. And hands up if at some point during this chapter you thought, "Hey! Wouldn't this Active Directory thing be a great place to store details of how to find objects?" Everyone? Well, the good news is that Microsoft is doing the hard work for you.
At the time of writing, the Class Store is very much an emerging feature, which may or may not appear with NT5.0. However, what we can be sure of is that it will be implemented as an Active Directory container. By the use of new class definitions to completely describe COM objects (including key attributes, such as location of executables), this class store will permit systems administrators to install COM components once, but run everywhere. No longer will we have to configure every single interested registry. If required, on-demand installation can be specified instead, so that the COM component is downloaded to the client machine if required and installed correctly there.
To me, this is what Active Directory is really all about. Once the Class Store is in place, we can start to develop truly distributed COM systems, without having to worry about the hassle of deploying them to our end-users. Nirvana, indeed.
We're going to change direction a little in the next few chapters, and take a look at the Microsoft Transaction Server, which is revolutionizing the way in which we structure COM clients, and which forms the central plank of Microsoft's thrust into the Back Office.