ng system) provides can all be exposed in a common way, regardless of the language they're written in.
It Don't COM Easy
This is exactly what Microsoft's Component Object Model (COM) does. It defines a language-independent notion of what an object is -- how to create objects, how to invoke methods, and so on. This allows development of components that programmers can use (and reuse) in a consistent way, regardless of which languages they use to write the component and its client.
COM has been very successful. Today, it underlies a great deal of what all of us do when we use Windows. Something as routine as double-clicking on a file icon to open the associated applicati
on, for example, actually relies on COM under the covers. Yet, despite its success, a good number of developers see COM as more than a little challenging to understand and use. The reason for this is simple: Using COM's language-independent objects in any real programming language requires understanding a new object model -- the one defined by COM. For example, a C++ programmer knows that creating a new object requires using the language's
new
operator, while getting rid of that object requires calling
delete
. If that same C++ programmer wants to use a COM object, however, she can't do things in this familiar way. Instead, she must call the standard COM function CoCreateInstance (or one of a few other choices) to create the object. When done with this COM object, she doesn't delete it explicitly, as in C++, but instead invokes the object's Release method. The object relies on an internal reference count that it maintains to determine when it has no more clients, and thus when it's safe to de
stroy itself.
COM is not prohibitively difficult to learn and use -- if it were, it wouldn't be the popular technology that it is today -- but it does require extra effort by developers. While this would likely be true of any language-independent object model, it would be ideal if that effort were minimal. Achieving this ease of use is a primary motivation for Microsoft's next generation of COM, dubbed COM+.
Making the Tools Do More
Making a software technology easier to use often means changing the tools we use to work with that technology. This is exactly what COM+ will do. It will make the tools do more, so the developer is free to do less.
COM has always been relatively straightforward to use from some languages. Visual Basic programmers, for example, must make some COM-specific calls, but VB itself hides many of the details. Microsoft's implementation of the Java virtual machine makes COM's integration with Java even simpler -- it allows Java programmers to write ordinary Java
code, then silently performs any necessary translations. But for C++ developers, using COM means understanding a significant number of COM-specific rules and API calls (see the figure
"Classic COM"
). While COM+ will bring some changes to developers working in VB, Java, and other higher-level languages, it's C++ programmers who will most appreciate it. Because COM+ relies on the C++ compiler to do much of the work of translating between this language-independent object model and the C++ object model, the developer's life becomes easier.
In "classic" COM, objects and their clients make calls on a standard COM library. In languages like Visual Basic and Java, some or all of these calls are hidden, but C++ programmers use this library directly.
COM+ still provides a standard library, and objects and their clients still use it. But in contrast to COM, COM+ hides calls to this library beneath the equivalent native functions in the programming language. C++ programmers, for example,
can use the standard
new
operator rather than CoCreateInstance to create a COM+ object. In doing so, they are relying on a C++ compiler that is aware of COM+ to generate the correct code to call the COM+ library (see the figure
"COM+"
).
To accomplish this, the compiler uses the COM+ library at compile time, then embeds calls to this same COM+ library in the generated binary. Microsoft will provide this library, and any language tool that wants to use COM+ must rely upon it. Unlike classic COM, where only COM objects and their clients use the COM library, COM+ also requires compilers (or interpreters, such as those for Visual Basic, and scripting languages, like JavaScript) to rely on a standard library to produce the correct code. Microsoft's competitors in the tools market, already accustomed to working on top of their competitor's operating system, now face the prospect of depending on yet another Microsoft-supplied component for key functions. The benefit, however, is
that doing this will make using Microsoft's language-independent object model easier for their customers, too.
Metadata's Importance
Today, a COM object defines the methods it supports in some number of interfaces, each of which can be described using COM's interface definition language (IDL). A tool (the MIDL compiler) then compiles an object's IDL to produce a type library, commonly stored in its own file. Clients of the object can (but don't have to) read this library to learn how to make calls on the object's methods.
In COM+, developers no longer need to define interfaces using IDL. Instead, they can just use their programming language's syntax to define the object's interfaces. The compiler for that language then works with the COM+ library to generate metadata for the object. Metadata -- essentially a superset of the information in today's type library -- goes in the object's same binary file. And unlike optional type libraries, every COM+ object must have metadata.
Even more
interesting, COM+ object metadata will be accessible through the generic data access interfaces defined by OLE Database (more commonly called OLE DB). This lets clients of the object issue SQL queries against its own metadata, in order to search for methods or parameter types.
One obvious problem: Not relying on the current IDL might mean adding syntax extensions to programming languages to accomplish the same function. Microsoft can use whatever interface definition syntax it chooses for Visual Basic, since it owns the language. Java already has standard language constructs for specifying interfaces. But C++, which will benefit most from COM+, currently has no standard way to specify interfaces. Although plans are not yet finalized, Microsoft says it intends to extend the language syntax by implementing an interface definition scheme in its widely used Visual C++ compiler.
Since every COM+ object has metadata, it's also possible to approach marshaling consistently. Marshaling is packaging a meth
od call's parameters in some standard way, allowing these parameters to move effectively between objects written in entirely different languages or running on entirely different machines. COM today provides two very different solutions to perform marshaling.
If an object exposes its methods using a vtable interface (also called a custom interface), its client typically relies on a proxy and stub to marshal and unmarshal the parameters for calls to those methods. A stub and proxy can be automatically generated from an interface's IDL definition using the same MIDL compiler that produces type libraries.
The other way is for a COM object to expose its methods using a dispatch interface (or
dispinterface
). In this case, a client need not rely on a proxy and stub for marshaling and unmarshaling. Instead, the client can read an object's type library, then dynamically perform marshaling as required. This is a more flexible system; however, since not all COM objects have type libraries, it's not al
ways possible in practice today.
But every COM+ object has metadata, the new equivalent of a COM type library. So COM+ can potentially get rid of proxies and stubs altogether, allowing a single consistent type of marshaling. COM+ also does away with the distinction between vtable interfaces and dispinterfaces, an inconvenient artifact of the way COM grew. While Microsoft has indicated that the first release of COM+ might still need proxies and stubs, the intent is clearly toward dynamic marshaling as the standard approach.
COM+ addresses yet another important but challenging problem in creating a language-independent object model: data types. Different languages support different data types, which causes problems when passing parameters between objects written in different languages. C++, for example, supports structures, while Visual Basic does not. Today, COM supports one set of data types for vtable interfaces (defined with C++ in mind) and yet another more limited set of data types for dispint
erfaces (created with Visual Basic in mind). COM+ gets rid of this historical distinction by defining one common set of data types that is usable across all interfaces and then relying on the COM+ library to perform any translations that are necessary.
Other COM+ Features
COM+ brings many other changes to the COM we know and use today. One of the most important: COM+ eliminates the need for clients to call Release when they are done using an object. Instead, the COM+ library automatically handles reference counting -- always one of COM's most error-prone areas. And while COM has always supported interface inheritance, COM+ also allows implementation inheritance between COM+ objects running in the same process. Despite years of arguing that this was not a desirable feature for a component model, Microsoft appears to have yielded to the demands of at least some of their customers and added this feature.
COM+ also changes COM's persistence model. Today, the creator of a COM object must typic
ally implement one or more of a fairly large set of interfaces related to persistence. A client of this object then calls various methods in those interfaces to have the object load or save its persistent state. But the COM+ library provides standard support for persistence, removing much of the burden from the COM+ object implementor. And by representing an object's properties in a standard way ("serialization"), COM+ lets you pass objects by value. All that's required is to send this serialized representation of an object's data to another object of the same class.
Constructor Support
Another interesting change, support for constructors, makes COM+ objects more like objects in a typical object-oriented programming language. Languages like C++ and Java can define a constructor method that runs when first creating an object. The creator of the object can then pass parameters as needed to this constructor, allowing easy initialization. COM objects do not support constructors, but COM+ objects do
. COM+ constructors even allow passing parameters, better integrating COM+ objects and the objects used by today's most popular object-oriented languages.
Changing the world's most widely used system object model will not succeed if it breaks the millions of lines of existing COM-based code. But Microsoft has not ignored interoperability. A client will be able to treat a COM+ object like a COM object, and COM+ clients will be able to use COM objects. Further, COM+ does not change the wire protocol that Distributed COM (DCOM) uses, so network communication will stay unchanged.
COMplications
By making it so central to Windows and Windows NT programming, Microsoft has all but forced developers to use COM. This has not been a bad thing. Making COM easier to use, especially for C++ developers, is also not a bad thing. But COM+ is not without its share of potential drawbacks.
For one thing, it appears that, like the Microsoft Transaction Server (MTS), COM+ will be available only on Micros
oft platforms. This weakens Microsoft's already limited multiplatform COM and DCOM story. While ports to Unix and other operating systems are beginning to appear -- from Software AG and other companies -- they will support only classic COM, not COM+. Classic COM objects will still interoperate with COM+ objects, but programmers in multiplatform environments will need to learn and use both the old and the new approaches.
Perhaps a more important concern with COM+, however, is the dislocation this change implies. It's very hard to argue that the rate of change in the software industry is too slow. Indeed, it's fair to say that most Windows developers have only recently acquired solid knowledge of COM. And while COM+ unquestionably will make it easier to use COM, it also will bring changes in the way objects behave.
Changing a basic part of the infrastructure can create legacy support nightmares, especially for groups building long-living, mission-critical applications. Those customers aren't necessa
rily interested in the newest, coolest technology. Instead, they want technology they can use to run their businesses effectively.
COM+ will affect core enterprise software like MTS (see the sidebar "Interceptors Add Object Functionality"), which Microsoft shipped only a year ago. Changing MTS so soon means that the skills necessary to maintain MTS applications built today could be scarce in 10 years. But those MTS-based applications may well still be in use, challenging those programmers responsible for maintaining them. If Microsoft wants to capture the hearts and minds of the enterprise -- and it does -- the company must understand that for many users of computing technology, stability matters more than state of the art.
Making It Real
Microsoft announced COM+ in September and says it plans to release the COM+ library in the second half of 1998. But this is only the first step. Using COM+ effectively will require that development tools, such as C++ compilers, change to use the COM+ li
brary. This will take some time. For most of us, COM+ probably won't be a standard part of the tools we use until 1999.
Given that COM+ is so far in the future, Microsoft is encouraging developers to continue using COM today. And since the software giant assures us that COM and COM+ will work together effectively, it appears that investments in COM today won't be a waste. But given how fundamental COM has become to software development on Microsoft platforms, anything that makes using it easier and more effective is unquestionably progress.
Where to Find
Microsoft
Redmond, WA
Phone: 206-882-8080
Internet: http://www.microsoft.com
COM+: The Next Generation
