Columns
Introducing ActiveX
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.
Defining ActiveX
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
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
similar.
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.
Web-Related Technology
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.
ActiveX Today
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.