JavaBeans is jumping -- ADTmag

JavaBeans is jumping

By Jason J. Meserve
July 6, 2001

The coming months should see ActiveX, Microsoft's popular entry in the component arena, challenged by the JavaBeans component architecture. The much-touted Beans edged closer to reality with the release late last year of the JDK 1.1 specification from JavaSoft, a Mountain View, Calif.-based subsidiary of Sun Microsystems Inc. JavaBeans is the component architecture for Java, as ActiveX is a major part of the component architecture for Windows development.

The question is how much success will JavaBeans have compared with the already popular ActiveX architecture? Developers may soon decide, especially if the given application is an internal-only app which will run on Windows-based machines only, that ActiveX is the way to go at the current moment. For those looking to do more cutting edge, business-to-business development, Java and JavaBeans could be more suitable because of cross-platform capabilities.

In theory, JavaBeans allows use of pre-built and third-party components to build applets and, in the case of Enterprise JavaBeans, full business-critical applications that run in a thin-client environment. Java and JavaBeans may reach the goal C++ enthusiasts have been trying to attain for over a decade: true object-orientation and code reuse.

While ActiveX controls already provide component-based development and third-party support for Windows developers, it is not widely accepted on platforms other than those offered by Microsoft. That is where JavaBeans has an in: Because it is tied to the Java platform, Beans can be written once and run on any platform that supports the Java Virtual Machine (JVM).

There's desire to see JavaBeans provide a simplified framework for object component programming. The overhead for learning and executing JavaBeans is lower, maintains Onno Kluyt, JavaSoft's senior project manager overseeing JavaBeans. "There are no extra language features to learn; if you know Java programming you can build Beans," Kluyt said. "There's a relatively small number of guidelines to follow for creating a [reusable] JavaBean."

Kluyt asserted a higher learning curve exists with ActiveX. It is easy-to-use, but it does not scale to the enterprise level, requiring developers to employ the more scalable, but harder-to-learn C++ language. In addition, Kluyt added, there is no performance issue associated with running Beans in an application, since there are no additional function calls needed to execute Beans. Of course, Java is still a relatively new technology and has performance issues of its own, that JavaSoft will hopefully address in the release of JDK 1.2 sometime this summer.

A new JavaBean specification, code named "Glasgow," is also in the works. According to Kluyt, Glasgow will have an Extensible Runtime Containment and Services Protocol that will enable an individual JavaBean component to ask for certain services from the container in which it "lives." Also, Glasgow features the new Java Application Framework, which is being designed to address data binding. Lastly, Glasgow will feature native drag-and-drop capabilities to facilitate quicker development at the component level.

Clearly, the success of Beans is tied to the success of its base, the Java language. "I think JavaBeans are an indistinguishable part of Java," said Rob Zeitch, director and general manager of languages for Sybase Inc., Emeryville, Calif., one of the growing number of vendors that supports Java-Beans in its development tools. "Anyone doing Java wants to do components."

Currently, JavaBeans enjoys a 17% adoption rate, according to a 1998 survey of Fortune 1000 companies recently completed by SPG Analyst Services, Natick, Mass. The same survey indicates that JavaBean adoption will more than double in two years. At the same time, Java support will jump from 40% to over 60%, according the the survey.

Success is also dependent on Enterprise JavaBeans (JavaBeans that can talk to one another across a network) becoming widespread. Enterprise JavaBeans are lagging behind plain JavaBeans at the moment. "Enterprise JavaBeans is an unbelievable opportunity to unite development across multiple platforms," Zeitch said. As with much in the Java world, this is a work in progress. Microsoft representatives are sure to point this out. Said Microsoft's Joe Malone, Object-ActiveX group manager,
"'JavaBeans for the Enterprise is total vapor. It's a case of writing an API and declaring victory." Sun made the Enterprise JavaBeans spec available on its Web site in mid-December for a 60- to 90-day public review.

IBM is one of the heavy hitters in the marketplace pushing Beans. "We see Java-Beans as a key architecture for deploying our 'E-business' tools," said Scott Hebner, program director, application development marketing. "With an open Internet becoming the medium to do business over, it is becoming apparent that we need a standard programming environment."

As for the future, it will be interesting to see how the two technologies play out with the two competing middleware strategies. This could be where the war is won, if a true winner is possible. ActiveX is closely tied to Microsoft's COM/DCOM architectures, while it seems that the Object Management Group is leaning Corba towards the JavaBean model, according to Nick Evans, technical director of Cooper's & Lybrand's Dallas-based National Internet Practice. "Like ActiveX, COM and DCOM, [JavaSoft] needs to make JavaBeans talk to each other in the most efficient manner," Evans said. "They need to evolve that stuff for a distributed object model to work."

Added Evans: "I think Enterprise Java-Beans are viable, but we may have to wait a while for them to shake out and such."