ActiveX Controls vs. JavaBeans
David Chappell - January
If component-based development is the next great wave in software
engineeringand I believe it isthen who controls the
dominant component architecture will be crucial. While components
on the server are likely to get more important over the next few
years, as products like IBMs Component Broker and the Microsoft
Transaction Server (MTS) become more widely used, the action in
components today is largely on the desktop. And at the moment, two
companies are competing to see who will create the dominant architecture
for desktop components: Sun with their JavaBeans technology, and
Microsoft with ActiveX controls.
An ActiveX control is just a COM object that follows certain rules
in the interfaces that it supports. A JavaBean is very similarits
a Java object that implements specific standard interfaces. Despite
their similarities, however, which architecture you choose to use
in your own development will likely make a big difference in your
ultimate success. Accordingly, its both interesting and vitally
important to understand the issues and the probable outcome of this
Whats a Component?
Everybody has his or her own definition of components. If we restrict
ourselves to looking at just ActiveX Controls and JavaBeans, though,
its not hard to come up with a consistent definition that
fits these two technologies. In both, a component is a discrete
chunk of software that:
- runs inside some kind of container, such as Visual Basic or a
web browser (in other words, the component is a library of some
kind, not a standalone executable);
- provides a user interface, and can typically be manipulated visually
by a developer;
- is distributed in an executable form;
- can expose a group of methods and properties to its container;
- can send events to its container.
Given this fairly restrictive definition as a start, its
useful to look at the component world a little more broadly, beginning
An ActiveX control is generally defined as a chunk of software
that meets the criteria just laid out. Software that meets all of
those criteria but doesnt provide a user interface is sometimes
called an ActiveX component, or just a COM object (these two terms
are essentially synonymous today). Components that run on servers
rather than the desktop (and so never have user interfaces) are
also called ActiveX components or, if the container they're running
in is the Microsoft Transaction Server, MTS components or MTS objects.
The Java nomenclature is simpler. Desktop components are called
JavaBeans, while components that target the server are called Enterprise
JavaBeans. The original JavaBeans specification has been available
since late 1996, but as of this writing, the spec for Enterprise
JavaBeans isn't yet available (although it may be out by the time
you read this).
The Desktop Decision
ActiveX controls and JavaBeans have a great deal in common. In
fact, its not too challenging to map the interfaces provided
by one into those defined by the other, and both Microsoft and Sun
offer software today that does this. The most important distinction
between them is that ActiveX controls are nearly always Intel binaries
running only on Windows and Windows NT, while JavaBeans can potentially
run on many systems.
At first glance, this looks like an obvious plus for JavaBeans.
After all, isnt the ability to run the same code on lots of
different boxes bound to be a good thing? The reality is a little
colder, however. First of all, the ability to run the same code
on any combination of operating system and processor necessarily
implies some kind of translation. For JavaBeans, these translations
are provided by the Java Virtual Machine and the various packages
that comprise the Java environment. But providing a generic operating
environment implies inefficiency, both in performance and in the
ability to exploit the full functionality of the system. To remain
portable, JavaBeans cant use the specialized services of any
particular operating system, which means theyre always limited
to the lowest common denominator of what all systems provide.
It might be worth paying this price to achieve portability for
clients if not for the second big problem faced by JavaBeans: as
everyone knows, the overwhelming majority of desktop machines are
Wintel boxes. In fact, many organizations have entirely Wintel desktops.
Given this, why use a component architecture that both limits functionality
and introduces overhead, all to solve a problem you dont have?
Especially for organizations that have all or virtually all Wintel
desktops, JavaBeans components make little sense.
The state of the component market today reflects this reality.
Thousands of ActiveX controls are currently available from hundreds
of vendors, while the JavaBeans market is much smaller. This is
due in part to the relative newness of JavaBeans, but it also reflects
the coldly profit-oriented calculations of independent software
vendors. Most appear to believe that making their components run
less well in 90% of their market just to acquire that last 10% isn't
Hope for JavaBeans
But there must be some hope for these guys, mustnt there?
Is Redmond fated to completely rule the world? The answer to the
second question is "Probably", but the answer to the first
is "Yes". There are two situations where JavaBeans can
potentially offer some clear advantages over ActiveX controls: the
public Internet and (maybe) on servers.
On the public Internet, servers can make fewer assumptions about
their clients than on internal company intranets, and client diversity
is much more likely. Here, a platform-independent component architecture
makes more sense. And theres another reason why JavaBeans
are attractive for public Internet-based apps, as well: security.
Much has been written about the security problems of ActiveX controls,
but the fundamental issue comes down to signing vs. sandboxing.
Java can support both, while ActiveX controls are focused on signing.
While there are plenty of cases where signing is the right solution
(which is why JavaSoft added this capability), downloading arbitrary
components into your web browser isn't one of them. Only someone
with the desktop equivalent of a death wish will download a component
signed by someone they don't know and trust. Sandboxing is a necessary
restriction in this case, which is why JavaBeans have an advantage
over ActiveX controls for some kinds of Internet-based applications.
The Java forces also have a potential advantage on the server with
Enterprise JavaBeans. Unlike clients, servers still exhibit a good
deal of operating system diversityWindows NT is growing in
popularity, but there are still plenty of Unix boxes, mainframes,
and AS/400s out there, too. The advantages of Sun's trademarked
phrase "Write Once, Run Anywhere" are very real here.
If (or perhaps when) Windows NT dominates the server world, ActiveX
components will become the dominant component model there, too.
But for now, at least, Enterprise JavaBeans has a shot at success.
If, that is, the competing vendors pushing Enterprise JavaBeans
can follow the advice of the estimable Rodney King and just get
along. Like components for the client, server-side components need
containers to run in. What better choice could there be for a server
container than a transaction monitor? IBM, Oracle, Sybase, BEA,
and others have all reached this conclusion, and all have made some
kind of supportive statement about Enterprise JavaBeans. But ultimately,
each of these vendors wants you to be committed to its product,
and so each will probably do its level best to create proprietary
elements. While this approach may succeed in hog-tying whatever
customers that vendor captures, it's unlikely to allow the creation
of a serious third-party market. What ISV creating server-side components
will choose to write for what's likely to be a proprietary component
architecture promoted by a single vendor? ISVs like to minimize
risk, so if forced to bet on a single vendor, most of them will
bet on Microsoft. Building server-side components for MTS is bound
to be a safer bet than trying to pick a single winner out of the
assorted other competitors. If all of Microsoft's competitors can
truly get behind a single, fully specified Enterprise JavaBeans
standard, JavaBeans on the server has a reasonable chance of success.
If not, Enterprise JavaBeans is likely to suffer the same fate that
awaits desktop JavaBeans today: a small market that dwindles into
What are the chances of these competing vendors supporting the
exact same standard? We've seen this movie before: it was called
"CORBA". If the standardization of CORBA-based products
is any indication, the chances for true standardization of Enterprise
JavaBeans aren't good. The same basic group of vendors are involved,
and the market forces are much the same. The only thing that may
have changed is that these vendors are now much more afraid of Microsoft
than they were five years ago. But sequels are rarely even as good
as the original, much less better. I'm not optimistic.
Do you hate Microsoft? Are you on a holy quest against the forces
of the Dark Side? If so, please do your best to commit your entire
organization to JavaBeans. Given that JavaBeans are likely to have
a much smaller component market to draw from and many fewer native
containers, this is probably an irrational and ultimately damaging
thing to do. But if some organizations dont take this probably
self-destructive but emotionally satisfying (for them, anyway) path,
ActiveX seems likely to completely dominate the component world.
Having only one viable component architecture is not an attractive
proposition. Competition among vendors is obviously a good thing
for customers. Whats less obvious, perhaps, but no less true,
is that competition is also a good thing for Microsoft. If the company
completely crushes all opposition, even its future will be much
less interesting, to say nothing of ours.
design and development by kmcreative.
KMCREATIVE is a Silicon Valley based graphic design firm specializing
in corporate collateral, web design, web development, identity,
medical illustration and product illustration.