September 15, 1997

Component Wars Developers are asked to choose between ActiveX and JavaBeans By Don Kiely he operating system wars are dead and the browser wars were quickly rendered moot. With luck, the conflict shaping up over component standards will prove to be just as inconsequential. Microsoft and Sun Microsystems are asking developers to decide whether to code Windows applications using Microsoft's ActiveX and its related Component Object Model, or to write platform-independent applications using the Java programming language and JavaBeans component model. ActiveX components are based on COM, a specification for exposing an application's properties for manipulation by other applications. ActiveX components are a special form of a dynamic link library. They implement COM-small units of code that can't run outside of a container application-and provide a specific set of features such as connection to a remote database or a display of a grid on a form. When Microsoft reinvented itself to embrace the Internet, it redefined the OLE control specification to better fit the Internet model of distributed computing. The biggest change Microsoft faced was the vast number of interfaces an OLE control had to support, which often resulted in code bloat. Now, an ActiveX component only has to support one interface, ensuring slimmer controls that can be quickly downloaded over the Internet. Microsoft has also beefed up Internet Explorer's support for components through Visual Basic Script, JScript, and the Object tag in HTML. Sun's JavaBeans specification is the new kid on the block, but its acceptance has been meteoric, evolving lately far more quickly than ActiveX. The original JavaBeans specification, released early this year, had a number of deficiencies that limited a bean's usefulness. But Sun recently released a preliminary set of upgrades called the Glasgow specifications. The draft covers four new strategies that address earlier shortcomings. The original spec made no provision for a container application to interrogate a component to determine the services provided by the run-time environment. The Extensible Runtime Containment and Services Protocol defines extensible run-time containment and services that allow a bean to discover attributes or services available in its environment. The protocol also lets users nest beans within other beans. Java now supports only single-implementation inheritance, but multiple inheritance provides a much more powerful programming model. The Object Aggregation and Delegation Model proposal implements an aggregation-delegation model, which is a synthesis of multiple-implementation inheritance. You can create a bean as an aggregate object that supports single inheritance but exhibits the traits of multiple objects-similar to Visual Basic class objects. Other JavaBeans shortcomings include the lack of services to determine data types, encapsulate data access, discover available operations, and instantiate the appropriate component. The JavaBeans Activation Framework Specification describes a component registry similar in operation to the Windows registry with the added benefit of being available on any platform. The Native-Platform Capable Drag and Drop Specification will let container applications expose drag-and-drop capabilities if the underlying operating system and development environment support it. These changes to JavaBeans add capabilities that make it functionally more similar to ActiveX components while making beans usable on different platforms. The draft specifications are available at JavaSoft's Web site . Tactical Differences Even though each camp is quick to adopt the innovations of the other, there are still radical differences between the rival component architectures. Deciding between the two involves far more than guessing which company will prevail. The architectures have fundamental differences that affect what you can do with a distributed application. Security is the most fundamental difference between ActiveX and JavaBeans. JavaBeans take advantage of Java's innate security. Java uses a "sandbox" scheme-keeping component code in a safe area where it can be easily watched and get just a little rowdy without causing lasting damage. In this environment, components are protected from system services. The safety of this approach, however, is likely to erode as Sun yields to pressure from developers to give them access to the underlying operating system APIs. This is a growing problem for Sun as it promotes its 100% Pure Java initiative. If you use underlying operating system APIs, your code won't be portable or 100% Pure Java. ActiveX uses what I call a tattletale model of security-"You can do anything you want anywhere, but if you're naughty, I'm gonna tell on you!" As a result of this security model, you have greater flexibility in building and using an ActiveX component. Microsoft recently released J/ Direct-an option that lets developers bypass the Java APIs and directly access 32-bit Windows APIs, exacerbating potential security problems and making Windows-only applets possible in Java. These differences may be moot as soon as Sun implements code signing in Java and Microsoft provides ways to limit what an ActiveX control can do in a container. Each side keeps making noise about adapting the other's security features, but it hasn't happened yet. Portability Issues Once you get past the security issues, the biggest problem with ActiveX is that it's a Win32 Windows specification. An ActiveX control is compiled to native code. It has no intermediate layer, such as the Java Virtual Machine. An ActiveX component runs between the code and the operating system. With three major versions of Windows in wide use, including 16-bit Windows 3.1, chances are pretty strong that an application won't run on all versions of Windows. Adding to the complexity, Microsoft has released its ActiveX developers' kit for the Macintosh and promises support for Unix as its partners implement it. It will likely be some time before ActiveX components will run everywhere. Or even in the same places Java code will run. JavaBeans, on the other hand, are written only in Java and run anywhere that Java runs. You'd be hard-pressed to find a widely used operating system without a Java VM, which means that beans will run almost anywhere. The portability that Java offers is a good thing, but it limits what you can do with JavaBeans because Java takes the lowest common denominator approach across all host operating systems. The more a component takes advantage of operating system-specific features, the less portable it is. Language Options JavaBeans is language specific. Beans can be written only in Java. ActiveX, on the other hand, is language independent. Microsoft's COM specification was designed with language and vendor independence in mind. You can create ActiveX components in C, C++, Visual Basic, and Java. I was quite surprised recently when Netscape Communications announced that its Netscape One products would expose multiple languages as JavaBeans. Upon further investigation it appears that Netscape is providing services for encapsulating components written in other languages within a JavaBean wrapper. You can write a Netscape plug-in in C or C++ and create a JavaBean out of it. Handy, but it doesn't exactly break the barrier. Strictly speaking, you have to use Java to write JavaBeans, which then call other code modules as needed. Sun offers a JavaBeans Bridge for ActiveX that lets legacy ActiveX containers host JavaBeans. Sun also has a JavaBeans Migration Assistant for ActiveX to help you move existing components to JavaBeans. Microsoft's COM specification is a complex set of interfaces that are so hard to learn and use that some programmers have spent years working to understand them. The COM interface is a group of functions that expose information or services to the container application. The only required interface is IUnknown, which provides a way to determine what other interfaces, if any, the component has available. Tools such as Microsoft's Visual Basic and Borland's Delphi make creating components far easier but expose less than the full capabilities of ActiveX components. Microsoft has just announced plans to update the COM spec, with the stated goal of making it easier to implement in various languages, including Java. The JavaBeans interface is simpler than COM, partly because it's based on a single language and partly because it was designed that way. A JavaBean has two ways of letting the world know what it can do: reflection and introspection. Reflection means that the bean conforms to design patterns, a form of nami ng standards implemented in standard ways. The other method, introspection, is vaguely similar to an ActiveX IUnknown interface, so that a bean can provide information about itself. Despite Microsoft's and Sun's rhetoric about providing open standards, both ActiveX and JavaBeans are proprietary. Deciding between these architectures isn't easy, especially for companies that don't have the resources to straddle both. The dual standards will make it difficult for Web developers to build sites that are equally useful to all users. Hopefully, market forces will guide the development of interchangeable technologies, making the component wars moot as well. Back to News in Review Send Us Your Feedback Top of the Page

---