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.The Benefits of a System Object Model
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.What COM+ Brings
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:
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.Conclusions
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.