JavaBeans Takes On ActiveX
This week, our focus returns to JavaBeans. If you are just joining us, feel free to skip back and check out our previous, more introductory, issue on the subject.
We have said a lot about component technologies in general; all this background information is important because software components are one of the growing number of phantom software technologies. Although they generate a great deal of activity in the upper-tier development community, practically speaking, they do not exist in the real world.Sun, Microsoft, Netscape, and the other members of the cabal are banking that they will, however, and their conclusions are probably not unfounded. Fly or fail, software components are worth watching--for educational value.
All this general discussion should not, however, distract you into thinking that the products in play are the same. As is typically the case with an as-yet-nonexistent industry, the offerings that are about to comprise it are all surprisingly different from each other. As they're becoming a major endeavor for JavaSoft, for the next few weeks, we're going to start examining JavaBeans in more detail.
We've spoke some time ago about the absurdity of the comparison between Java and ActiveX; these are two really different technologies doing basically different things. Their comparison came about from the entirely visceral source that both Java and ActiveX are being used to embed small programs into Web pages.
JavaBeans, however, is a competitor. It's a part of Java designed to do, among other things, almost everything you could accomplish with ActiveX. Even still, it's disturbing to see the two products so easily compared with one another when they are so separate in capabilities. Most likely it's best to consider these two in separate classes of our thus-far imaginary marketplace. OpenDoc, until recently the third major contender, even further complicates matters because it, too, has different things in mind. For now, however, let's focus on the two former systems.
ActiveX started out as a Microsoft proprietary product, and it has fairly consistently behaved in that fashion. Using it, you can write software components that can be swapped among Windows 95/NT applications that support it (of which there are a few).A calculator, or a graphic-viewing tool, can be quickly and effortlessly (one hopes) transplanted into a variety of applications that have a place for it to go. Once you accept their use, they have complete access to all the facilities of your computer; a time-worn strategy for large-scale applications that Microsoft is now earnestly trying to apply to software components. The boundaries lie around the Microsoft operating system and the Intel architecture; ActiveX is no good for programs that don't run under Windows on your PC.
JavaBeans are fully a part of Java, which is something different. They're loosely tied to a language: Java. They're also tied to a virtual machine specification, which includes a far more realistic security model. It can, in the new incarnation Java, allow very specific control over what capabilities a Bean may request, and what it may get.The boundaries here are different, of course; Beans work anywhere Sun and company take the current Java Virtual Machine (JVM)--now including Window 95, the MacOS, and several flavors of Unix. The obvious benefit is that when you want to make your components work on a new platform, someone else does the work--namely, of porting the JVM properly.
There is open animosity between both camps that percolates through even the darkest depths of their technical documentation. Perhaps understandably, the two software efforts are almost uncomfortably "close" to one another. Sun is currently in mid-development of two software tools (already available in development versions): JavaBeans Bridge for ActiveX, and the JavaBeans Migration Assistant for ActiveX, which allow for use of JavaBeans in an ActiveX environment, and for the partial "translation" of ActiveX components into JavaBeans, respectively.It's interesting to note that the latter product is being developed by IBM and Taligent--further evidence of deep cooperation between major players over this issue.
Microsoft, not to be outdone, made the curious move of licensing Java and allowing for ActiveX components to be written using it. Although perhaps more aimed at appearance than functionality (since ActiveX components written in Java would still be tied to a platform dependent API), this peculiar tit-for-tat illustrates the unusual and recent trend of the competition between software companies by attempting to write a superior product and making it easy to switch to it and use it. We wonder if Microsoft's recent set of run-ins and threatened run-ins with the Justice Department's antitrust division have anything to do with this.
In the final analysis, ActiveX ends up looking like a quick and dirty solution. Developers can produce components exclusively for current Windows operating systems, which may be their only concern. And they may find the lack of security measures and slight-to-moderate increases in efficiency (remember, we're talking about Windows here) compelling. Not to mention the weight of the larger base of C++ programmers trained in the Microsoft "Visual" environment (we're resisting a snide comment here), who will find it quicker to adapt to the ActiveX system.
JavaBeans are clearly a more sensible long-term solution--and we find it quite compelling that, already, writing a Bean is almost the same as writing an ActiveX component. Irrespective of that, Java has the ever-wonderful advantage of representing a far greater part of the population for your money, all with a package containing a fairly respectable set of tools, the best possible security system the component industry could have hoped for, and a superior object-oriented language to boot.The biggest drawback--efficiency--is frequently not as high on the priority list as many of these other concerns, and that's likely to be especially true for small and simple component software.
This is an interesting struggle because it's close; ordinarily in the software business, quick and dirty wins every time. We find it a potentially hopeful indication that in the Web arena, which we consider to be an excellent testbed for component technology, Java has held unquestionable dominance since its release.Next week, we'll be breaking open the new Beans Developer Kit and checking out the contents. Come back and see for yourself.
