| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### OLEMSGing

We have not included a lot of detail about this service in this book, as it is probably of lesser interest than the other more powerful services. OLEMS-Ging, however, provides component-based access—access using the DCOM style of invocation of methods on an interface—to the services of Microsoft’s mail products. It means that a developer can access data, for example, and then compose an e-mail message using the data, from the same program, and all using the same interface and programming paradigm.

### In Summary

Perhaps key to the understanding of DCOM is that Microsoft does not provide a set of completely disparate and unconnected set of products, but one integrated solution with multiple capability. Thus, for example, Transaction Server and MSMQ are in fact just services that are part of one integrated architecture—DCOM.

This is an enormously powerful concept. It is worth pointing out that no other middleware products on the market are integrated in this way with all the services a developer may need to build a distributed system integrated within one product and with one interface.

In general, if the developer is using other products and wants to build applications that need distributed transaction processing capability, for example, he or she uses a Distributed Transaction Processing Middleware (DTPM) product like Tuxedo or TOP END. If he then needs to send messages using store and forward capability, he uses a message queuing product such as MQSeries, BEAmessageQ, or VCOM.

If our developer uses DCOM, however, he or she does not have to choose a product or more than one product to support applications, nor does he or she have to learn different product approaches or philosophies—our programmer uses one set of services (which are already available if he or she is using Windows NT), one common interface, and uses the needed services. If messaging capability is needed, our programmer uses the Messaging services in DCOM; if transaction services are needed, our programmer uses Transaction Server in DCOM; if database connectivity is needed, he or she uses OLE DB; if security services services are needed, he or she uses the security API, and so on.

One might assume that such a powerful and all-inclusive “product” was developed using some grand strategy—where Microsoft devised the complete architecture of the product with all its services before they started to build the parts. In fact, the architecture has evolved and grown as much out of pragmatism and customer demand than as a result of some grand preconceived strategy.

Certainly a strategy does underpin all development that is the use of components, the use of a common interface to access services, and the use of a common model—COM. But DCOM was built on Windows NT because it made more sense for Microsoft engineers to reuse what they already had. Similarly, Transaction Server and MSMQ were built using COM and Windows NT because it was the most pragmatic and cost-effective route.

Perhaps equally surprising, given the integrated nature of DCOM, is the fact that development of the various products described in this report is not the responsibility of one particular group within Microsoft. In practice, the development has been distributed over the whole organization, with COM and DCOM being the responsibility of the OLE group based in Redmond; the networking components of DCOM being the responsibility of the networking group; the Directory being the responsibility of the Windows NT group; and Falcon being the brainchild of Jim Allchin. The DCOM architecture was designed by Bob Atkinson and Kraig Brockschmidt—both long-serving Microsoft employees.

So what you are seeing described in this book is something of a phenomenon. An integrated middleware product based on Windows NT, which was developed by a number of separate teams within Microsoft but which remains an integrated product, and a product which is unique on the market in covering the services it does—messaging, database and data connectivity, distributed transaction processing support, object/component-based access (ORB-like services), RPC services, plus other middleware services.

Previous | Table of Contents | Next