Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Superior performance or platform independence? That’s the key question to answer when making the decision whether to build components in the ActiveX or the JavaBeans architecture. If you choose ActiveX, you’ll be limited for now to Windows95 and NT, but that may not represent a limitation for you, and the performance improvement relative to Java may be substantial. With JavaBeans, you’ll be developing components that can be shipped over a network and implemented on virtually any machine, regardless of operating system.
The big question for IT managers is whether ActiveX or JavaBeans will become the standard architecture for component development. After all, the whole motivation behind software components is reusability, and you might not be able to reuse your components if your framework has just become an orphan. Could it be that both ActiveX and JavaBeans will survive? Perhaps, but component architectures have been abandoned before. After all, there was a time when OpenDoc was going to be the next big thing in component architectures.
The battle between Microsoft, the force behind ActiveX, and Sun Microsystems, developer of JavaBeans, may seem to be about a framework for component development, but the underlying issues are much more far-reaching. If ActiveX becomes the standard architecture, it will drive companies to standardize on Windows 95 for desktops and Windows NT for servers, all of which, of course, come from Microsoft. Should JavaBeans take over, a wider range of operating systems could remain in use, including UNIX-based systems from Sun and a range of systems from IBM. Why has the fight over ActiveX versus JavaBeans become so bitter? J.P. Morgenthal, an analyst with NC.Focus, a Hewlett, N.Y., research and analysis firm, sums up the matter concisely: “Whoever owns the infrastructure owns the world.” Across an intranet Component software promises to reduce app dev times and accelerate deployments. But two competing frameworks are vying for control. If you choose the wrong one, will you be able to recover? When BankBoston made the decision to migrate its IT infrastructure from client/server to an intranet-based architecture, the primary issue was functionality. Frank Correra, CEO and founder of the Clarity Group in North Andover, Mass., the systems-integration consultants who implemented the migration, felt that JavaBeans did not offer the richness of functionality that was available in ActiveX controls. Moreover, BankBoston was already committed to Windows95 and NT throughout its IT infrastructure, so platform independence was largely irrelevant.
“Fundamentally, the debate over Java versus ActiveX is about whether you believe in Sun’s vision or Microsoft’s,” says Correra. “We chose ActiveX because there are many functions that are unique to each environment, and we didn’t want to compromise on the lowest common denominator.” The first application implemented for the BankBoston intranet was a customer information screen, which was itself a component made up of other components, especially ActiveX controls. The faster performance of ActiveX components over JavaBeans was also of prime importance for David Linthicum, a senior manager with Ernst and Young’s Center for Technology Enablement in Vienna, Va., which is building a variety of applications for the company’s intranet, beginning with a time sheet update program. E&Y wasn’t too concerned about cross-platform issues because the main elements in the infrastructure were a Windows NT-based SQL server and about 1,000 Windows95 clients. “We had four reasons for choosing ActiveX as our component framework: simplicity, a rich tool set, native look and feel, and performance. Also, we like that we could buy ActiveX controls such as calendars and schedulers,” says Linthicum. “And Java and JavaBeans are just too slow right now.” Linthicum adds that security was not a huge concern because the application is for an intranet, not the Internet. “Since we were building for an intranet application, we didn’t want to be constrained by the Java sandbox. Right now, ActiveX should be used primarily for intranets, because it’s just a matter of time before someone comes out with phony digital signatures. But for our applications, the ability to distribute ActiveX controls over the network was the important part.” Over the Internet It’s when you distribute an application over the Internet–and security and cross-platform issues become major concerns–that JavaBeans comes into its own as a component framework. Just consider a system like the one Jerome Soller is developing in conjunction with the University of Utah. Soller, president of Salt Lake City-based CogniTech and a research instructor at the University of Utah Division of Geriatrics, is helping to construct a decision-support tool for health-care research that will enable researchers to build queries as well as to access other researchers’ queries. The queries are stored on a central database, and must be accessible to any researcher, regardless of platform. “For our application, we can’t enforce any operating system,” Soller says. “We have to assume heterogeneous environments, and JavaBeans enables us to distribute components to anyone. Also, the Java sandbox gives us the security features we need. When a researcher asks to look at someone’s queries, they don’t want to be taking a chance that something could come in and take over their machine.” “Right now, ActiveX has a richer tool set than JavaBeans,” Soller adds. “Beans GUIs are still being developed. But if you can get by with a simple interface, Beans is much easier to work with. And from what I’ve been seeing, I think that, by the Spring of ’98, Java will be comparable to ActiveX in the areas where it is still behind.” The greatest strength of JavaBeans, Soller found, is that the architecture forces you to do the design up front and to use consistent underlying logic. He uses IBM’s VisualAge for Java and Cupertino, Calif.-based Taligent’s WebRunner Toolkit to create the JavaBeans, including some that manipulate data from an IBM DB2 Universal Database. “It gives you a very clean design,” he says. “The object modeling and design are about 90% of the task, and putting the pieces together is no more than about 10%. The basic Beans from Sun’s JDK are sitting right on the IBM palette.” Why not use both? ActiveX appears to be the best choice as a component framework when an application will be run in a 32-bit Windows environment, especially over an intranet. Moreover, Microsoft is moving ActiveX into the UNIX and Macintosh worlds, and continues to enhance the security features. JavaBeans seems to be the best choice today for heterogeneous environments, especially when the Internet is involved and security is a major concern. And Java’s performance is improving as Java Virtual Machines (that is, Java interpreters) continue to be refined. So what should you do? Fortunately, the decision does not have to be cast in stone. JavaBeans can be encapsulated to run with ActiveX, and ActiveX methods and properties can be automatically migrated into Beans. In fact, you could deliberately architect a system so that part of it used ActiveX and part used JavaBeans, if that made sense for your application. The PowerJ enterprise Java application development tool from Emeryville, Calif.-based Sybase takes this concept one step further by delivering Java for different environments, including JavaBeans, ActiveX, CORBA, JDBC, and the Sun and Microsoft Virtual Machines. Conceivably, you could build components in one framework and switch to the other at a later time.
Moreover, many applications need to be maintained in both ActiveX and JavaBeans. For example, Seagate Software’s Barry Parshall, program manager for Seagate Crystal Reports, sees an ongoing need for versions of the popular Crystal Reports that can be interfaced into back-end applications in both ActiveX and JavaBeans frameworks. “We see ourselves as the Switzerland of reporting technology,” says Parshall. “We want to be able to integrate Crystal Reports into any format–stand-alone, over the Web, Java, any Windows application. We’ve written Crystal Reports in 100% Pure Java to ensure that it receives the full benefits of Java, and of course we maintain an ActiveX-based version for our large base of Microsoft developers. The goal is to ensure that we are able to reach the entire business community.” Bottom-line benefits The benefits of ActiveX today are clear– a vast array of prebuilt components that shred development times. But JavaBeans is catching up, and the intrinsic advantage of platform independence could soon overshadow the performance. “I think the performance issue is tremendously overrated,” says analyst J.P. Morgenthal. “Especially with a Pentium 120 or better, the speed penalty for using JavaBeans is negligible.” Where IT shops will see bottom-line benefits from JavaBeans, as Morgenthal points out in his free “State of Java Report” (available on the Web at http://www.itfa.com), is as much in deployment as in portability. “Java and JavaBeans technology let you get the product out the door,” he says. “It makes no sense to look at anything except stable, reusable code. With JavaBeans, it takes almost no time to deploy an application across the Internet and onto multiple platforms, and that’s when the profits will come in.” // Eva Freeman is a freelance high-technology writer based in Bellevue, Wash.
|
|||||||||||||
