JavaBeans and ActiveX go head to head

Don't choose until you've considered these 5 issues crucial to developers

One area of intense software investment is in the creation of rapid-application-development (or RAD) packages. A RAD package consists of a programming language, a component model for connecting together interaction elements (called "controls"), and a customization environment (called "resource editors"). One of the most successful RADs on the PC has been Borland's Delphi; however, the first RAD to see widespread use was Microsoft's Visual Basic. Borland's product used a proprietary version of Pascal (Object Pascal) and Microsoft's product used a proprietary version of Basic. Because of Java's strengths as a robust, secure programming language, it seems a natural fit as the base language for a killer RAD environment; until now, however, Java has lacked a fundamental technology: components.

Software components are simply a convention for writing user-interface controls so that the application development tools and runtime environment can manipulate them. Visual Basic's component model, "VBX" (for Visual Basic eXtensions), is a variation of Microsoft's DLL (dynamic-link libraries) architecture. Delphi defined a component architecture around Borland's "OWL" (Object Window Library) architecture.

Not content to sit idly by and watch the action, JavaSoft has thrown its hat into the ring with a component architecture called JavaBeans.

You might think that this is simply the tale of three different RAD environments, each with their own language. You'd be right in one sense, but you know as well as I do that nothing is quite so simple. The Java language has injected a significant kink into the way programmers are taught to think. That kink was felt most strongly at Microsoft, which saw another competitor to its Visual Basic on the horizon. It was with this in mind that Microsoft took some existing work on generalizing VBXs for its other programming languages and created ActiveX -- a component architecture allegedly suitable for all languages. To reinforce this point, Microsoft has provided support in its newest development tools to invoke ActiveX controls from Java and to invoke Java from ActiveX controls.

Software component models

Let's begin with a simple definition: A software component model is a specification for how to develop reusable software components and how these component objects can communicate with each other.

With that said, we can now focus on how component models work in a general sense.

Developers of software components must deal with the low-level details of implementing a component and its associated classes. Users of software components (developers in their own right) can then simply hook together existing components in a visual development environment. This is what we call rapid application development -- existing codebase can be easily reused (or purchased from an independent vendor) and integrated in a third-party development environment. Component developers also benefit from this type of environment: They can reuse existing components, obtaining a consistent object-interface to many standard system facilities during the development of their own components.

In effect, software development with a component object model is like building with Legos building blocks. Instead of building an entire application from scratch, you build an application by hooking together your existing building blocks. This approach not only saves time, money, and effort, but it produces more consistent, reliable applications. And your mother told you playing with toys wouldn't get you anywhere!

In the context of GUI components, developing software with a component object model allows you to purchase or develop software components, such as font selectors and database viewers, and then put them together in a graphical development environment as easily as you would the native GUI components of your chosen environment. Configuring these components is then accomplished via graphical control panels that list the accessible properties of the components (color, font, etc.) and allow for easy modifications. I must stress, however, that components do not have to be solely graphical in nature. An alarm is an example of a typical non-graphical component: When you add it to an application you can graphically choose how frequently the alarm goes off and can easily edit the alarm code, but when your application is run the alarm component consists of a thread with no visual appearance.

Getting down to the nitty gritty:

Understanding the software components themselves

In order for a software component model to work, each software component must provide several features:

  • The component must be able to describe itself. This means that a component must be able to identify any properties that can be modified during its configuration and also the events that it generates. This information is used by the development environment to seamlessly integrate third-party components.

  • The component must allow graphical editing of its properties. A RAD environment is intensely graphical; the configuration of a software component is done almost exclusively through control panels that expose accessible properties.

  • The component must be directly customizable from a programming language. Because components also can be connected by scripting languages or other environments that can only access the components from a code level, this feature also allows software components to be manipulated in non-visual development projects.

  • The component must generate events or provide some other mechanism that lets programmers semantically link components. This means that the programmer can easily add the appropriate action code to buttons so that button clicks will properly affect other components.

In theory: scrutinizing the frameworks

Now that we understand the features a good software component should support, we can apply what we've learned to the JavaBeans and ActiveX frameworks specifically. We'll start with JavaBeans.

The JavaBeans way

JavaBeans supports autodescription through an introspection mechanism, graphical component editing through a customization mechanism, and linking through an event model. Let's look at how each of these features works.

JavaBeans supplies the Introspector class to perform introspection of a component (in this case, a "bean") automatically. A JavaBean can be studied to determine its properties and events in one of two ways: through the Reflection API or through the BeanInfo class. The Introspector class uses the BeanInfo class if it is supplied; otherwise, it uses the Reflection API.

With the Reflection API, one class can examine the methods provided by another class. If the bean author follows the JavaBeans design patterns specification, the behavior of the bean can be determined automatically from its method names. Alternatively, the bean author can provide a BeanInfo class that describes the bean. This class must implement the BeanInfo interface, and its name must be formed by adding "BeanInfo" to the end of the bean's class name. The various descriptor classes that are returned by this interface are then used to determine the bean's features.

When a bean is added to an application, the development environment will allow users to configure the bean through a property sheet. The bean's properties are determined through the introspection mechanism, and then presented in a graphical form as a property sheet. Changes that the user makes to the bean's properties will then be applied through the appropriate bean methods.

Alternatively, bean designers can include their own customization class, which can provide a configuration wizard to guide the user's initialization of the bean. Custom configuration classes are created by implementing a Customizer class and returning the appropriate information from the bean's BeanInfo class. This allows for a much greater level of sophisitication in the customization of a bean, which can be important for complex beans such as database accessors.


Different beans are linked together through events. Every bean declares the events that it can fire. When a bean's application is assembled, the programmer registers listeners for these events. When an event occurs, all of the registered listeners are notified.

For example, a button bean can generate Action events. A class that is interested in this event must implement the ActionListener interface and register with the button bean. When the event occurs, the button will notify all of its listeners through ActionListener interface, allowing the appropriate action(s) to occur.

The ActiveX way

ActiveX is Microsoft's retooling of its existing component object model for the Web environment. Essentially, ActiveX provides the glue for components to communicate with each other, regardless of their implementation language and platform. This is not to say that a given ActiveX control binary is portable; rather, it means that the specification allows for communication between controls on different platforms that support ActiveX. ActiveX is built from several core Microsoft technologies:

DCOM, Microsoft's distributed component object model, provides the low-level, object-binding mechanism that lets objects communicate with each other and remote objects. An extension of DCOM represents the ActiveX core technology. Like Java's remote method invocation (RMI), DCOM provides transparent message-passing between objects that may reside on different machines and different operating systems.

OLE (which Microsoft says "used to be" an acronym for object linking and embedding, but "has progressed far beyond compound documents") uses DCOM to provide high-level application services, such as linking and embedding, to let users create compound documents. Built on the foundation of Microsoft's component object model (COM, the predecessor to DCOM), OLE is optimized for end-user usability and integration of desktop applications.

ActiveX, as an improvement on OLE, provides a substantially "slimmed down" infrastructure that enables controls to be embedded in Web sites and respond interactively to events.

ActiveX controls describe themselves through a binary description file that lists the properties, methods, and events that should be exposed. Creating this interface from Visual Basic or Visual C++ is done through an ActiveX wizard that visually steps users through the process. Currently if an ActiveX control is developed in Java, then all of the public methods of the class are exposed by COM. It is likely, however, that Visual J++ 1.1 will introduce a wizard to refine this process.

Similarly, an ActiveX property page is visually created by a property page wizard that steps through the process of creating a graphical property editor. Currently, Java controls do not support a property page, but Visual J++ 1.1 should remedy this limitation.

As I mentioned earlier, ActiveX controls communicate through the low-level DCOM mechanism that allows controls to access each other's exposed methods, regardless of whether the controls reside in the same container, in the same machine, or on different machines. DCOM makes it possible for designers to develop applications that operate across heterogeneous networks, providing it has been ported to the respective platforms.Microsoft has released the DCOM technology to The Open Group, formed in early 1996 by the consolidation of two open-systems consortia: X/Open Company Ltd. (X/Open) and the Open Software Foundation (OSF). The Open Group (TOG) will oversee the DCOM standardization process.

ActiveX controls are linked through events; the development environment allows developers to create methods that are called when events are initiated by any components being used. If an event includes parameters (such as x and y coordinates) then these are included in the signature of the method that is called.

Blessing or curse?: Microsoft's automated approach

The maturity of Microsoft's development tools really shows in the context of ActiveX development. There is a vast amount of work that goes on behind the scenes when the wizards effortlessly guide you through developing and interoperating ActiveX controls; for example, the controls must be assigned unique identifiers, they need to be inserted in component registries, and so on.

If details in this section appear to be lacking, it is because they are hidden. Microsoft's development tools are intensely visual and intensely automated. So much work is done automatically that it is easy to develop with little knowledge of the internals of ActiveX, but it is a painstaking process to uncover the real details; even Microsoft's development documentation admits to this problem. Suffice it to say that without an advanced Windows IDE it would be practically impossible for a newcomer to develop an ActiveX control from scratch, but with such an IDE the tedium is automated away and a very powerful mechanism is exposed.

In practice: How the ActiveX and JavaBeans cope in the real world

JavaBeans and ActiveX are new technologies, and both are targeted at Web-based applications, which opens a huge can of worms when it comes to security -- developers must consider the treat of executing potentially dangerous code from arbitrary Web sites. These and other practical considerations between the two technologies are discussed in the following sections.


1 2 3 Page 1
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies