COM+

David Chappell - April 1998

Let me begin by putting my cards on the table: I think COM+ is the most important thing to happen in the COM world since, well, COM's inception. First announced in the fall of 1997, all of the new features COM+ brings probably won't be available in full until sometime in 1999. Still, it's not too early to start understanding the big changes it brings to today's most popular component technology.

After spending years as something of a niche technology, objects today have gone mainstream. The great benefit of this is that the concepts of objects are embodied in most popular development environments. C++, Java, Delphi, Visual Basic, PowerBuilder, and many more tools all support objects to at least some degree. The drawback of this popularity, though, is the diversity it has engendered. While all of these tools endorse the notion of objects, their notion of just what an object is varies quite a bit. And while modern development tools have all bought into objects, the environments they run in remain a bit more retro. The native programming interfaces to Unix, Windows NT, and other mainstream operating systems are still procedural, defined using traditional function calls. What's needed is something that can both provide a common notion of objects across multiple tools and give us some way to expose system services as objects. What's needed, in other words, is a system object model.

This, of course, is exactly what COM offers. While COM provides lots of other benefits--support for component software, distributed object computing via DCOM, and more--it also acts as a standard, cross-language object model. By providing one common definition of what an object is, how an object's life cycle is managed, and how an object's methods are invoked, COM makes a developer's life more consistent.

But still, COM can be a little hard to use. For a developer steeped in a particular approach to objects, such as that defined by C++ or Java, thinking about and using a different kind of objects, such as those COM defines, can be challenging. To create an object in C++, for example, a developer uses the new operator. Creating a COM object, by contrast, requires calling COM's standard CoCreateInstance function or one of its brethren. And C++ programmers can indicate that they're done using a COM reference by calling Release--there's no standard way to explicitly delete a COM object, as there is in C++.

Some languages make using COM much easier. In Visual Basic, for example, calls to Release are hidden from the developer, as are many other details of using COM. And in perhaps the most extreme case, Microsoft's implementation of the Java Virtual Machine hides COM completely. The programmer can use Java's new operator to create either Java objects or COM objects, and the Microsoft Java VM just does the right thing, calling CoCreateInstance when required. Similarly, the VM's garbage collector notices when a COM object is no longer being referenced and automatically calls Release--the developer never has to worry about reference counting.

Why can't every language tool be this smart? How come C++ programmers are exposed to all the details of COM, while Java developers can use COM so easily? The answer, of course, is that different environments provide different levels of built-in support for COM, ranging from Microsoft's Java VM, which does it all for you, to C++, which leaves most of the burden on the developer. A major goal of COM+ is to remedy this inequity by making every language tool do more work. If the tools do more, developers can do less. (Since nobody ever complains that writing software is too easy, this is an undeniably attractive prospect.)

To accomplish this, COM+ provides a runtime library for applications to use, just as COM does today. But COM+ also requires tool vendors to use this library. A COM+-aware C++ compiler, for example, will allow developers to use the new operator to create both C++ and COM+ objects, much as the Microsoft Java environment does today. Because the compiler will have built-in knowledge of COM+, it can bear much more of the burden. The result is that the developer's life is made simpler.

But COM+ does more than just make COM easier to use. It also includes a host of new features, including:

• hiding reference counting from developers. With COM+, reference counting is no longer the developer's concern, no matter what language they're working in;
• storing meta-data with every COM+ object. Meta-data is essentially a superset of today's type libraries, but with a more consistent definition across all kinds of COM+ objects;
• a common set of types supported by all COM+ objects. One problem in creating a system object model that can be used across many languages is that different programming languages support different data types. There are no real pointers in Visual Basic, for example, while there are in C++. Today, a COM object can expose methods via vtable interfaces, which are oriented toward C++, or dispinterfaces, which are Visual Basic-oriented, but the set of allowable parameter types is different in each case. COM+ breaks down this artifact of COM's development, providing a rational set of common types.
• adding the notion of interceptors, which are essentially COM+ objects that can be automatically inserted between a client and another COM+ object. Calls the client thinks it's making directly on the COM+ object can in fact be intercepted and processed in some way. This is exactly how the Microsoft Transaction Server (MTS) works today, and in the COM+ era, Microsoft tells us that MTS will be re-implemented using interceptors (although they promise that current MTS applications will continue to work). Interceptors allow automatically performing all kinds of useful functions, so I expect to see Microsoft's marketing machine pick up the "auto" prefix the way it once latched on to "visual" and "active".
• largely hiding COM's Interface Definition Language (IDL) from developers. IDL is a non-trivial thing to learn and use correctly. Rather than make developers rely on it to define interfaces, COM+ aims to allow developers to define interfaces in whatever language they happen to be using.

Making COM easier to use means having programming tools do more. But since tools such as Visual Basic and Microsoft's Java VM already do quite a bit to hide COM, it may well be C++ developers who benefit most from the innovations COM+ brings. COM was originally designed with C++ in mind, so it's only fair that its next generation should make life easier for users of this language.

But in spite of its role as the foremost language in the minds of COM's original designers, C++ isn't ideally suited for use with COM. In particular, C++ doesn't have built-in language support for the notion of interfaces. Of course, an abstract base class does a reasonable job of acting as an interface, and using inheritance, a C++ object can support multiple interfaces. But unlike, say, Java, there's no inherent language support for defining interfaces using C++. And since COM+ tries hard to de-emphasize IDL, this is a problem.

If you are the owner of the world's most popular C++ compiler, however, it's less of a problem than one might think. Microsoft plans to add syntax to Visual C++ that allows defining interfaces directly. While this will certainly help bring C++ into the modern era of interface-based programming with objects, it may also raise a few objections among people who believe that significant language changes like this are the exclusive province of standards committees. Of course, if Microsoft waits for the ANSI C++ committee's approval, we're unlikely to see this part of COM+ become available anytime in this millenium.

It's nice to see that the COM team at Microsoft isn't resting on their laurels. Innovation and improvement, especially in such a fundamental software technology, is a good thing. And making COM easier to use is unquestionably progress. At the same time, however, one might legitimately wonder about the rate of change Microsoft maintains. Easier is better, certainly, but making anything different implies at least some pain. I'm especially worried about the legacy problem. If an organization creates enterprise applications using COM and MTS today, as Redmond encourages them to do, then finds that the way in which you write COM code changes, this could cause problems. Even if the changes make things easier, those old applications will need to be maintained. Enterprise applications might have a lifetime of ten years or more. If the core technologies have changed, who exactly is going to have the skills to maintain those apps? COM+ is upward compatible with today's COM (and the DCOM wire protocol remains unchanged), so nothing will break, but the knowledge of how to do bare COM may well be lost. The result could be mission-critical applications that can't be effectively maintained.

Still, change is an integral part of what we all do. My father sold toilets all his life, and things he learned at 25 were still valuable when he retired at 65 (hey, some of those toilets were still in use). Things I learned at 25 were hopelessly out of date by 30, and will be ancient history by the time I'm 65. If we can't handle change, we shouldn't be in this business.

Website design and development by kmcreative.
KMCREATIVE is a Silicon Valley based graphic design firm specializing in corporate collateral, web design, web development, identity, medical illustration and product illustration.