ActiveX Controls vs. JavaBeans

David Chappell - January 1998

If component-based development is the next great wave in software engineering—and I believe it is—then 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 IBM’s 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 similar—it’s 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, it’s both interesting and vitally important to understand the issues and the probable outcome of this battle.

Everybody has his or her own definition of components. If we restrict ourselves to looking at just ActiveX Controls and JavaBeans, though, it’s 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, it’s useful to look at the component world a little more broadly, beginning with ActiveX.

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 doesn’t 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).

ActiveX controls and JavaBeans have a great deal in common. In fact, it’s 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, isn’t 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 can’t use the specialized services of any particular operating system, which means they’re 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 don’t 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 worth it.

But there must be some hope for these guys, mustn’t 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 there’s 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 diversity—Windows 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 irrelevancy.

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 don’t 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. What’s 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.

Website 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.