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

Previous | Table of Contents | Next

## Chapter 19
In Summary

Like all summary chapters in books, this is the one place where you will tend to see what the author really thinks about their subject matter. This chapter is no exception, so if you don’t want to be bombarded by my opinions, stop reading here!

Let me start with the good things.

Figure 19.1 Summary of services

### The Strengths of DCOM

Visionary-There is no doubt that what Microsoft has produced with DCOM is visionary stuff. They have provided middleware—an infrastructure for building distributed systems—that can be used with components, is accessed using a common interface based on the same component model, and that encompasses a vast range of services.

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

All the other vendors provide a particular type of middleware—DTPM, RPC, MOM product. If you want to use messaging with distributed transaction processing you usually have to use a MOM product with a DTPM. With DCOM you have no need to do this—practically all the services you need are built into DCOM and provided using the same interface.

What this means from the developer’s point of view is that he or she only has to learn one product and one approach. After mastering the concepts in the COM model, the notion of interfaces and methods invocation, and the service interfaces that do exist, the developer is well on the way to being able to build most types of application with the one product.

Cheap-And DCOM is cheap—perhaps we should say that DCOM is free with Windows NT, but nothing really comes free. The cost of Windows NT is being adjusted to reflect the increased functionality, so in fact it is being paid for in a different way. But comparatively speaking, DCOM is exceptionally good value when compared to other middleware products.

Good services-Some of the services in DCOM are also particularly well thought out and compare very favorably with other middleware products. I particularly like MSMQ, which is a very well thought through product and uses exceptionally novel ways of achieving guaranteed delivery services, deferred delivery services, polling, pushing, and routing that are highly advanced. Transaction Server also shows considerable promise. The transaction services themselves are very good.

Microsoft-I am now seeing the little phrase “no one gets fired for buying IBM” changed to “no one gets fired for buying Microsoft.” What any purchaser wants is a stable base on which to build systems, and a stable product comes from a stable company—a big successful company—with lots of money, massive revenues, and many customers. Microsoft isn’t going to disappear (not within many programmers’ career lifetimes anyway), and use of any Microsoft products does ensure a relative measure of stability.

### The Weaknesses of DCOM

Complex-I have tried to simplify things in this book to help in the understanding of DCOM and to provide you with an idea of what you can do with the services it provides. What I have not done at any stage is expose you to the actual interfaces you’ll have to use or the sequence of exchanges needed to perform various tasks.

The point is that DCOM and its interfaces are complex—perhaps unnecessarily so. It may be a function of the fact that object/component-based communication is being used, I’m not sure, but the calls are very low level and also high in number.

I have given you some idea of the complexity. The description on triggers, for example, should have given an inkling that triggering from the programmer’s point of view was error prone. You should also come away with the impression that multithreading was not for the fainthearted. Furthermore, you should also have gained a feeling for the complexity of the Directory service interfaces as I explained the need for class factories.

But why is DCOM so complex?

If we take a product like MQSeries (with only four basic commands) or BEAmessageQ (with perhaps only 20-30) and compare them with DCOM (which has literally hundreds of service interfaces), you start to wonder what has gone wrong. All these products use a function-based API, not object-based invocations.

CORBA is actually worse than DCOM. Some CORBA ORBs have over 500 sets of interfaces for service invocation that provide only very basic functionality—nowhere near the functionality of DCOM.

I have yet to decide whether it is a weakness of object technology itself—that is, object technology creates complexity and results in low-level invocation—or whether it is because the DCOM or CORBA developers are themselves used to low-level programming and are unaware for the need to hide the complexity from the average programmer. Perhaps it is both. Certainly a function-based API seems to be able to capture in only one simple call what in an object-based world often takes several invocations.

Does the low level of the interfaces matter?

If low-level interfaces are used or a complex command set, in the first place applications become harder to program and productivity suffers. In other words, it will take longer to build an application based on DCOM than one based on many of the other non-CORBA or -DCOM middleware products.

In the second place, the more commands there are, the easier it is for the programmer to make a mistake. A third, and perhaps less obvious problem, is that by using a low-level set of interfaces, DCOM itself will be difficult for Microsoft to evolve and enhance—programmers will have used services exposed to them rather than hidden from them, so any change to the services will necessitate either considerable work by the programmer or an upgrade path from Microsoft that preserves the old service interfaces. The more interfaces are provided, and the lower level they are, the more opportunity there is for them to be misused too, which means that any upgrade to the interfaces Microsoft applies could have completely unforeseen consequences in your programs because the programmer used them in an unusual way.

One of the major middleware vendors recently said to me that there is only one way to provide reliable, high performance, available middleware—middleware that could be enhanced easily—and that is to hide everything from the developer and automate all the services: automatic multitasking, automatic security, automatic failover, automatic restart, automatic Directory services, and automatic error handling. All the programmer should need to do is send a message and get a message. I think he was right.

Previous | Table of Contents | Next