David Chappell - January 1997
Let's begin with a show of hands: how many of you hate Microsoft? And whether or not you hate Microsoft, how many of you believe that the company doesn't know the first thing about object technology, that, in fact, it has in some ways done damage to the entire concept of objects?
On the first point, I can't help you (although I might point out
that letting your feelings about a company, especially one that's
so unquestionably important, dominate your thinking is unlikely
to lead to good decisions). The second point, though, while a widely
held belief, is simply untrue. Microsoft's overarching approach
to objects, embodied in the Component Object Model (COM), in fact
hews much more closely to the standard conventions of objects than
many people believe. And where it departs from those conventions,
the departure results from COM's specific goals, not from the ignorance
of its designers.
There is an area related to objects, however, where I believe it's quite justified to criticize Microsoft: terminology. Judging from the evidence, Microsoft doesn't seem to care much about the labels it assigns to things. Exhibit A here is the company's mutable names for COM-based technologies. The broad set of technologies that are built using COM were originally given the label "OLE", and Microsoft spent several years trying to convince us that OLE meant more than just Object Linking and Embedding, the compound documents technology from which the acronym was derived. In early 1996, however, Microsoft changed terminological direction, and the name "OLE" was deemed to once more refer only to compound documents. A new label, ActiveX, was introduced as an umbrella term for COM-based technologies, and several technologies under that umbrella were also renamed.
It's just not possible to give a clear technical definition of what the term ActiveX means. The reason for this is simple: ActiveX is a marketing label, not a technical term. The clearest way to think about it is to view ActiveX as a brand name, like, say, Chevrolet. General Motors assigns the Chevrolet brand to a varied collection of cars, and what that collection includes changes over time. Still, all Chevrolets have some common elements, and assigning them all a common name makes GM's marketing task easier. Over the years, GM has built brand recognition and loyalty to Chevrolet in their customers' minds.
Microsoft is trying to do the same thing with ActiveX. There are many technologies grouped under this label, and exactly what those technologies are changes over time. Still, all of them have something in common--they all use COM--and Microsoft has been doing their level best to build equity in the form of customer recognition and loyalty around the ActiveX brand name.
It's tempting to define ActiveX as the set of all technologies that use COM. Sadly, this definition doesn't really work. The reason is that most Microsoft software today uses COM in some way, including Word, Excel, and even Windows 95 and Windows NT. Nobody is willing to argue that all of these products fall under the ActiveX umbrella.
When the term was first introduced in early 1996, it was used to refer to technologies that were somehow associated with the Internet and the World Wide Web, and the label still retains much of that flavor. Today, though, Microsoft includes COM itself as part of ActiveX, and there's nothing at all Internet-centric about COM. Once again, the only accurate perspective is to think of ActiveX as a flexible brand name. This generality notwithstanding, it's still possible to group today's most visible ActiveX technologies into four broad categories: fundamental technologies, component software support, middleware, and Web-related technologies.
Fundamental ActiveX Technologies
This first category includes COM itself, together with various COM-based building blocks. COM defines conventions and provides basic services for creating and working with software abstractions called COM objects. It's possible to implement COM objects in C++, Java, Delphi, and many other languages. Each COM object provides services to its clients through methods (of course), grouped together into one or more interfaces. COM objects exhibit the traditional characteristics of object technology: encapsulation, polymorphism, and even, counter to a widespread misconception, inheritance (although COM supports only interface inheritance, not inheritance of an object's actual implementation).
Other fundamental COM-based technologies include:
monikers, a way to identify and instantiate specific object instances;
support for object persistence;
automation, which is really nothing more than another way for a COM object to expose its methods (if you're familiar with CORBA, automation is quite similar to CORBA's Dynamic Invocation Interface);
type libraries, typically files containing a description of an object's interfaces (again, for the CORBA-literate, the idea is much like CORBA's Interface Repository);
uniform data transfer, a standard way to move data between objects;
connectable objects, standard interfaces for exchanging the information required to let an object talk back to its client.
Component Software Support
The second of our (somewhat arbitrary) categories is embodied in the idea of ActiveX Controls. Originally known as OLE Controls or OCXs, an ActiveX control is just an ordinary COM object that follows certain rules. To create reusable binary components, it's useful to define standard ways to do common things. For example, many objects will want to present their own user interface, send events, and expose their methods to other software. The ActiveX Controls specification defines standard interfaces for doing all of these things and more. To qualify as a control, a COM object must use the standard ActiveX Controls interfaces whenever it performs a function supported by those interfaces. For example, all controls must expose their methods via automation, and controls that provide a user interface must do so using the standard ActiveX Controls conventions.
Any piece of software that knows how to load and use ActiveX controls is an ActiveX control container. Popular ActiveX control containers include Visual Basic, PowerBuilder, and Microsoft's web browser, Internet Explorer. There is a large third-party market in this technology, with hundreds of companies building and selling reusable components packaged as ActiveX controls.
Middleware is typically defined as protocols that provide generally useful services for a variety of applications. Today's CORBA-based products are middleware, as are many other offerings from many sources.
In its initial incarnation, COM had nothing to do with middleware-in fact, it defined no distributed capabilities at all. Although COM was designed from the start to support distribution, this capability didn't actually appear in products until the release of Distributed COM (DCOM) in mid-1996. Even when DCOM did appear, it initially ran only on Windows NT and, a few months later, Windows 95. DCOM won't be available on a range of non-Microsoft operating systems until later in 1997, and even then, it will be primarily Software AG, not Microsoft, who provides it.
DCOM is similar in many ways to CORBA-based products. Both provide the support required for communication between objects on different systems. CORBA calls this support an Object Request Broker, or ORB, while Microsoft just calls it DCOM. Whatever it's called, the functionality is quite
DCOM accomplishes remote method invocation using Microsoft's RPC protocol, which was itself borrowed from the Open Software Foundation's Distributed Computing Environment (DCE). DCOM also provides distributed security services, originally based on those provided with Windows NT. DCOM does not provide a directory service, although Microsoft promises to ship one "soon". Shipping a general-purpose directory has proven hard for the Redmond behemoth, but it's a safe
bet that they'll eventually get something out there. Since the great majority of CORBA-based products don't have directories either, this isn't too much of a competitive deficit at the moment.
The fourth category of ActiveX offerings is Web-related technology. Microsoft's web browser makes heavy use of COM, and as mentioned earlier, it's also an ActiveX control container. Using a web browser as a control container allows downloading ActiveX controls from a web server, then running them inside the browser. In this way, controls can function somewhat like Java applets, allowing a web page to load not just data, but also code.
There are some obvious differences between Java applets and ActiveX controls in this regard. For one thing, applets ship a machine-independent bytecode to the client, while controls transfer a machine-specific binary. Still, the kind of machine for which this binary is intended, a Windows/Intel box, is, well, fairly common, so building downloadable components as ActiveX controls isn't as limiting as it might initially seem. Applets and controls each have strengths and weaknesses, and each has a place in the world of downloadable components.
Microsoft's competitors are fond of saying that ActiveX is just a new label for OLE, a five year old technology. In the nefarious world of cross-vendor insults, this charge has a rare attribute: it's largely true. It's interesting that Microsoft's competitors see this as a negative, since one might imagine that most users would prefer stable, tested technologies. But whatever its history, ActiveX is clearly here to stay. The reason is simple: Microsoft says so and, like it or not, Microsoft owns large parts of the software world.