 |
|
The Component Object Model (better known simply as COM) is Microsoft’s response to the increasing need for a solid foundation onto which modular software components can be built and upon which they can interact. Centered on the principle of separation between interface and implementation, COM achieves truly effective component-based management and language independence by defining not only a binary standard, but also a set of mandatory rules and design/implementation idioms that allow components to expose their functionality in a consistent manner. The paradigm abstracts the physical location of the objects; thus, with DCOM (Distributed COM), clients and servers can almost transparently reside in any nodes of a network.
Starting from the progressive definition of an informal set of requirements for modular software architectures, the first chapter of Essential COM highlights how, by itself, the C++ language is not capable of satisfying many of them, even when associated with DLLs. Several possible design alternatives are then evaluated, and the final decision leads to the rough engineering of COM. This is perhaps the most vaporware-free introduction to the subject I have ever read because it explains through facts and not conjecture how and why the C++ object model maps well to COM.
The following chapter dives straight into the core of COM by clearly explaining the key notion of interfaces (including the root of all of them, IUnknown), the rules to which they must adhere, and the way they should be described in IDL (Interface Definition Language). The subsequent chapters focus on the other fundamental aspects of the paradigm: coclasses, monikers, object identity, marshaling, apartments, security. Although DCOM is not cited explicitly in the title, the presentation of object activation and of the apartment models takes into account the distributed case from the beginning, instead of delegating such discussion to a final chapter as many other books not specifically focused on distributed architectures do.
As the book proceeds, more and more room is given to complex technical issues and useful (while not trivial) COM programming idioms, such as tear-off interfaces for saving memory as the number of interfaces climbs significantly but not all of them happen to be constantly in use. In all cases the solutions make use of only the raw COM API and interfaces at the C++ level. Neither the theory, nor any of the numerous code snippets sprinkled throughout in the book, mention high-level frameworks such as ATL or MFC. The dissertation on multithreading issues and marshaling are very detailed and betray the vast experience of the author in the implementation of nontrivial COM systems.
Let me state clearly that this is not an easy read. The density of the book (calculated as actual information per page) is incredibly high and, while a rare quality in today’s books, it requires particular concentration to be digested. The editing is overall of good level, although the writing style in certain parts becomes a little heavy and academic, which does not help overcome the toughest conceptual barriers of certain topics. Additional diagrams would have aided comprehension, too.
In the preface the author himself admits he took the style of the notorious book, The C++ Programming Language (authored by the equally notorious Bjarne Stroustrup) as inspiration. Although one covers a single object-oriented programming language and the other a language- independent object-oriented paradigm, I believe the comparison is apt. Just as Stroustrup’s text is widely considered the definitive reference for C++ for its depth and completeness, so Essential COM deserves to be elected the definitive reference for COM due to the same outstanding quality.
The emphasis is on amassing a solid ground on the so-called COM lifestyle and on understanding how and why to opt for certain techniques rather than the other possible approaches to both common and advanced problems. If you are looking for a book that exposes up front to the reader ATL or MFC code snippets to cut and paste into his or her ongoing ActiveX project, look elsewhere. When you have read this however, rest assured that you will be able to benefit from such other hands-on books immensely more.
Also, following up the previous observation, just as I would be reluctant to suggest Stroustrup’s book to someone who is going to meet C++ for the first time, I wouldn’t suggest COM illiterates to begin their explorations from this one, unless they knew C++ and another distributed model like CORBA quite well. Other books on the marketplace take a milder approach while attempting to explain basically the same subject. They generally fall short of deep technical details and advanced facets, nonetheless they can offer a somewhat more progressive path to the complexity of the argument. One such book that I would suggest is Inside COM, written by Dale Rogerson and published by Microsoft Press.
Unfortunately other COM/DCOM correlated topics, such as MTS and COM+, are not even touched. It could be objected that it is not the goal of this book to offer quick-and-dirty overviews of anything, but an indication of where those new acronyms integrate in the big picture would have been interesting in my opinion.
-- Davide Marcato (marcato@programmers.net )
From Chapter 1 (“COM as a better C++”), page 7
Once one overcomes the issues related to linking, one now has to deal with the far more problematic area of incompatibilities related to the generated code. For all but the simplest language constructs, compiler vendors often elect to implement language features in proprietary ways that render objects "untouchable" by code generated by any other compiler. Exceptions are a classic example of such a language feature. A C++ exception thrown from a function compiled with the Microsoft compiler cannot be caught reliably by a client program compiled with the Watcom compiler. This is because the DWP does not mandate what a language feature must look like at runtime, so it is perfectly legal for each compiler vendor to implement a language feature in a unique and innovative manner. For building a stand-alone single-binary executable, this is a nonissue, as all of the code will be compiled and linked using a common development environment. For building multibinary component- based executables this is a tremendous issue, as each component could conceivably be built using a different compiler and linker. The lack of a C++ binary standard limits what language features can be used across DLL boundaries. This means that simply exporting C++ member functions from DLLs is not enough to create a vendor- independent component substrate. […]
From Chapter 1 (“COM as a better C++”), page 35
This chapter started with a simple C++ class and examined the issues related to exposing the class as a reusable binary component. The first step was to deploy the class as a Dynamic Link Library (DLL) to decouple the physical package of the class from the packaging of its clients. We then used the notion of interfaces and implementations to encapsulate the implementation details of the data type behind a binary firewall, allowing the object's layout to evolve without requiring client recompilation. When using the abstract base class approach to define interfaces, this firewall took the form of a vptr and vtbl. We then examined techniques for dynamically selecting different polymorphic implementations of a given interface at runtime using LoadLibrary and GetProcAddress. Finally, we used an RTTI-like construct for dynamically interrogating an object to discover whether it in fact implements a desired interface. This construct gave us a technique for extending existing versions of an interface as well as exposing multiple unrelated interfaces from a single object. In short, we have just engineered the Component Object Model. […]
From Chapter 3 (“Classes”), page 102
When an object is activated in process, the DLL that implements the object’s methods is loaded into the client process and all of the object’s data members reside in the client’s address space. This makes method invocation extremely efficient, as no process-switch is required. In addition, the client’s thread can be used to execute the method code directly, provided the object’s threading requirements match those of the client. If the client and the object have compatible threading requirements, then no thread-switch is required either. When method calls can execute using the client’s thread, no intermediate runtime is involved after the object is activated and the method invocation cost is simply that of making a virtual function call. This makes in-process COM especially well suited for performance-sensitive applications, as method invocation is no more expensive then a normal global function call in a DLL. […]
From Chapter 5 (“Apartments”), page 102
In COM, a proxy is an object that is semantically identical to an object in another apartment. In a sense, a proxy represents another object’s identity in a different apartment. A proxy exposes the same set of interfaces as the object it represents, however the proxy’s of each of the interfaces’ methods simply forwards the calls to the object, ensuring that the object’s methods always execute in the object’s apartment. Irrespective of whether the client receives a pointer to an object or a pointer to a proxy, any interface pointer that a client receives from an API call or a method call is valid for all threads in the caller’s apartment. Object implementors decide the types of apartments in which their objects can execute. As is discussed in Chapter 6, out-of-process servers explicitly decide their apartment type by calling CoInitializeEx with the appropriate parameter. […]
Foreword by Charlie Kindel xi
Foreword by Grady Booch xvii
Preface xix
Chapter 1 COM as a Better C++ 1
Chapter 2 Interfaces 37
Chapter 3 Classes 95
Chapter 4 Objects 155
Chapter 5 Apartments 199
Chapter 6 Applications 261
Chapter 7 Miscellanea 313
Appendix A The Evolution of Objects 377
Appendix B Selected Code Fragments 385
Index 421
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.