JavaBeans vs. ActiveX: Strategic analysis

If you’re trying to weigh the pros and cons of JavaBeans and ActiveX, you’re not alone. Regrettably, few businesses and developers can afford to wait for a single component framework to emerge as dominant, or the “safe bet.” The good news is that you currently have the freedom to choose; the bad news is that you likely can’t afford to make the wrong choice. What to do?

With this article — and the forthcoming articles in this three-part series — JavaWorld will strive to help you find the answer to this important decision. Before addressing detailed issues such as the user experience and the programmer’s perspective in subsequent articles, we kick off this series with a basic discussion of ActiveX and JavaBeans. Herein we’ll describe the basic technology, philosophy, marketing strategies, and objectives of each component model.

Technology Overview

JavaBeans and ActiveX both serve the same basic function: to facilitate communication among software components within framework “containers.” These containers include Web browsers and other document viewers.

JavaBeans

JavaBeans is an integration technology — a component framework that allows component objects (called beans) embedded within documents to communicate with one another and with the framework. This means that components written to the JavaBeans specification will be able to interact in Web browsers and other environments that support JavaBeans. JavaBeans also will be supported in most visual Java development tools, so developers will be able to make JavaBeans components and combine them into applications. This approach is similar to the component development model Visual Basic has popularized, in which developers create software components that are combined to create custom applications.

Note that JavaBeans is not a version of Java; it is a framework for building documents and applications out of Java components. Java developers may choose to use JavaBeans, ActiveX, or neither when writing their applications.

The Active Platform and ActiveX

Microsoft has christened a set of three core technologies the “Active Platform.” These core technologies are the Active Desktop, the Active Server, and ActiveX. The Active Desktop consists of services that Microsoft says will be integrated into Win95, NT, and other major operating systems, including MacOS and major flavors of Unix. This integration will take place via Microsoft’s Web browser, Internet Explorer. Of course, integration at this level is not the same as integration with the operating system itself. The Active Server is a set of Application Programming Interfaces (APIs) to be provided with Microsoft’s Web server, Internet Information Server 3.0, which runs on Microsoft Windows.

ActiveX essentially extends Microsoft’s existing Object Linking and Embedding (OLE) and Component Object Model (COM) technologies to the Web. Like JavaBeans, ActiveX serves as a component framework; the two are direct competitors.

ActiveX “controls” are components that plug into the ActiveX framework. They are embedded in ActiveX documents such as Web pages in the same way that Beans are embedded in JavaBeans documents. Because ActiveX is a framework, ActiveX and Java do not compete per se. Java does compete, however, with Microsoft’s Visual Basic (VB) and Visual C++ (VC++), because ActiveX controls can be written in Java as well as these more traditional OLE/COM languages. However, Microsoft’s Visual J++ has COM support built in, but Java code that uses COM is only useful under Windows at this time.

Philosophy … and religion

JavaSoft’s stated goal is to support consistent cross-platform “write once, run anywhere” functionality and open standards. Java is a cross-platform success story, even though its uniformity across platforms is still shaky in places. JavaBeans is designed to follow suit by interoperating with CORBA, OpenDoc, Netscape ONE, and ActiveX, although it’s unclear how seamlessly this integration will work in practice. (See the glossary for definitions of key terms.)

The “open standards” issue is bit more fuzzy. Typically, an open standard is described as one that is both publicly available and non-proprietary. Java meets the public-availability condition, but trips over the non-proprietary condition. For a standard to be non-proprietary, it must be turned over to a neutral third-party standards body, such as the IETF, W3 Consortium, or The Open Group. The standards body then maintains the openness of the standard, which is supposed to benefit the marketplace by driving down costs, promoting interoperability, and preventing vendors from pulling any trick moves, such as changing the reference implementation, with the standard.

Despite some pressure from some developers and vendors, JavaSoft has yet to deliver Java to a standards body. JavaSoft maintains that retaining ownership of Java enforces consistency across all platforms by preventing fragmentation of the standard. Nonetheless, JavaSoft is reportedly considering turning about two thirds of the virtual machine over to standards bodies, with more to follow later in 1997. A recent ISO meeting at Sun’s headquarters seemed to yield little progress on the matter. JavaSoft’s official position statement can be found at https://www.javasoft.com/forum/1.0.0.html.

Microsoft Windows is a proprietary system, and Microsoft is famous for not giving away any of its APIs or attendant documentation. Recently, however, Microsoft has changed (reversed, that is) its attitude and now preaches the cross-platform gospel.

Why? Microsoft has realized the importance of the Internet and has moved quickly to adapt by building support for Internet protocols into its products. Recently, Microsoft also voiced support for open standards. In fact, Microsoft has turned parts of ActiveX over to The Open Group (TOG), a standards body formed by X/Open and the Open Software Foundation. Microsoft’s apparent deviation from its long-held proprietary stance is somewhat incomplete, though, as Microsoft failed to release its Windows-based ActiveX services APIs to TOG. These APIs provide much of the useful client functionality that ActiveX supports under Windows. Many observers interpret this as a move by Microsoft to hold onto the desktop by keeping a lid on its proprietary client APIs while simultaneously promoting its DCOM object framework, which is the primary component of the ActiveX core technology.

This leads us to the next issue: How does ActiveX stand up to the cross-platform test? Microsoft has pledged to make ActiveX truly cross-platform, which means that ActiveX must work as well under MacOS and Unix as it does under Windows, without sacrificing functionality. It’s unclear how well this is going to work in practice, and many observers remain skeptical that non-Windows platforms will be promoted to “first-class citizenship.” That is, will Windows version run better while Mac and Unix versions remain undersupported and devoid of features?

Point/counterpoint

The following are official statements issued by spokesmen for JavaSoft and Microsoft regarding philosophies on standards and cross-platform issues, as well as comments on the competition.

Java Evangelist Miko Matsumura of JavaSoft (miko@miko.com) had this to say:

The race is on between ActiveX and JavaBeans. What JavaSoft needs to deliver is a component architecture, which it announced November 6th. Microsoft already has OLE. What Microsoft needs to deliver is cross-platform functionality, which is tantamount to porting every Windows 95 system call to Macintosh and Unix and 16 other platforms. Frankly, I think JavaSoft will get there first.

Cornelius Willis, Microsoft’s group product manager of Internet developer marketing (cwillis@microsoft.com), said:

… It’s been said that Beans is more truly open and more truly cross-platform than ActiveX. The truly open part is a religious zealot thing that I’ll leave to those that have time for it. The cross-platform issue is something that affects both ActiveX and JavaBeans, in that any time you have an application (or Web page) that depends on a platform-specific component like an OpenDoc/Mac component or an ActiveX/Windows component you build that platform dependency into your app. In other words, when JavaBeans is talking to a platform-specific part, it is just as tied to that platform as ActiveX is when it talks to that part. The contrapositive is true too: When ActiveX is managing the interoperability of two (or more) platform-independent parts, such as Java applets, it is just as cross-platform as JavaBeans is.

Commentary

Matsumura’s quote addresses the ActiveX API services issue that bothers many observers. It’s unclear whether Microsoft intends to deliver key ActiveX services APIs, such as database access, to TOG. It is these APIs that give ActiveX the rich functionality Microsoft promotes as an advantage of ActiveX.

Willis correctly notes that using platform-specific components — under any component architecture — makes the application containing those components platform-dependent. Because of this, JavaSoft advocates the use of “pure Java” to create platform-independent applications; JavaSoft then argues that if you’re going to use Java to get cross-platform applications, why not stick with the “100% Pure Java” solution and use JavaBeans? JavaSoft maintains that “100% Pure Java” simplifies development effort and increases the reach of applications by guaranteeing that they will run on any Java-compatible system, not just a particular operating system/hardware combination.

This “100% Pure Java” concept is the center of Sun’s marketing efforts, just as “cross-platform” is at the center of Microsoft’s.

Marketing Strategies

Sun/JavaSoft and Microsoft differ in many ways; marketing is no exception.

Sun and JavaSoft

Sun has long recognized the importance of the network, as evidenced by their slogan “The network is the computer.” And after false starts with embedded electronic devices and interactive TV, the Java group realized that the network of the ’90s — the Internet — was going to be big and that Java could probably be positioned to become its native applications development language. When Java took off, Sun got serious about its opportunity to expand into Internet space and began to allocate resources to promote Java. This effort finally culminated with the setup of Sun’s JavaSoft business unit.

But the road to JavaSoft has been rocky at best, with Sun coming dangerously close to dropping the ball completely on several occasions. In the beginning, Sun more or less stumbled into success with Java and since then the company has taken a piecemeal approach to marketing, spending little to no money on ads, marketing campaigns, staff, and other necessities. Sun executives are rumored to have flinched at the idea of giving Java away, and the first Java Day in NYC was going to be cancelled but was held in the end because so many people had signed up to attend.

Luckily for Sun, the grassroots culture of the Net has allowed it to get away with its “guerilla marketing,” which so far has paid off handsomely. JavaSoft’s budget, staff, trade show presence, marketing efforts, and press relations vs. that of Microsoft’s ActiveX group are still amazingly small, although much better orchestrated.

JavaSoft’s marketing strategy continues to take advantage of Internet culture, which has a tradition of network-oriented free software and decidedly anti-Microsoft sentiment. JavaSoft’s marketing is therefore naturally chock full of Net buzzwords; cross-platform, network-oriented, and secure are some of Java’s major selling points. JavaSoft is using the same language in targeting the corporate intranet market, with the concept of cross-platform, integrated, Java-based solutions. Recently, JavaSoft and Sun have begun extending Java branding to hardware and operating systems with the Java Chip, JavaOS, and the JavaStation.

JavaSoft recently announced the 100% Pure Java initiative, which encourages developers to develop in Java only, including developing to the JavaBeans framework when appropriate. As part of this initiative, JavaSoft announced testing and certification programs and the availability of co-marketing funds for select ISVs who pass the test suites. JavaSoft also is in the process of ramping up developer support programs such as the Java Developer Connection.

Microsoft

Microsoft’s response to the Internet phenomenon has been to publicly admit its mistakes, cut its “losses,” and jump on the bandwagon. Other than the Net community at large, the main target of Microsoft’s message has been its huge developer base, which was beginning to feel left out of the Internet/intranet “gold rush.” Therefore, a primary theme of the ActiveX campaign is to emphasize that ActiveX allows developers to reuse an OLE-based codebase for applications on the Internet and corporate intranet.

In its Internet marketing effort, Microsoft has become markedly more “hip” and user-friendly, and customers in general report a new level of responsiveness. Microsoft’s Web site is comprehensive and contains a lot of documentation and product downloads as well. Microsoft’s ISV developer program also is very responsive, or at least much more so than its counterpart at JavaSoft.

Microsoft also focuses its marketing efforts on the enterprise-wide intranet — a space in which a lot of Windows-oriented codebase resides. The ActiveX security model has received much criticism with respect to its fitness for Internet use, but these concerns do not apply to the same degree on the intranet. As a result of these factors, Microsoft is pushing ActiveX in the intranet market.

Business models and agendas

What business models work on the Internet? There turn out to be a few, but the one we’re concerned with here is the counter-intuitive strategy of giving away your “primary” product to create an installed base and mindshare. Netscape realized that by giving away its Web browser it could get it on every Internet-connected desktop. At some point, Netscape made the further realization that it could practically build a desktop of its own, directly on top of every one of Microsoft’s Windows desktops, as well as Macs and Unix machines. At the same time, Netscape made money by selling servers to support the corporate intranet that it had created with its Navigator giveaway. This strategy worked because Netscape had at its fingertips the best software distribution channel humanity had ever devised: the Internet. Netscape had the chance to make the first move in this new space and take a crack at Microsoft’s software monopoly by leveraging this powerful distribution mechanism.

Sun and JavaSoft

The first step in Sun’s strategy was to follow Netscape’s lead and solidify Java’s place in the Internet sector by “giving it away” — information, development environment, language, and source code — over the Net. This policy, along with leveraging strategic alliances, most notably with Netscape, created a huge installed base of Java runtime and development environments and tremendous mindshare. Of course, Sun still owns Java and its derivatives, but the effectiveness of making it all readily and freely available to potential developers cannot be overemphasized.

The centerpiece of Sun’s strategy was a deal with Netscape to incorporate Java into Netscape’s browsers. This approach simultaneously gave a high-powered value-add to Netscape and launched a preemptive strike against Microsoft, the obvious sleeping giant. Microsoft soon realized the Internet redefined the computer marketplace and posed a threat to its business, but before Gates’ troops could take any effective action, Netscape and Sun had enjoyed several months in which they could essentially operate without contest from Microsoft.

Microsoft

By leveraging its success with DOS, Microsoft has maintained its dominance among desktop OS vendors. Taking advantage of its intimate knowledge of its proprietary APIs, Microsoft has been able to extend its software business beyond operating systems to include a applications software and developer products. The sheer economics of the Windows installed base convinces most software developers to develop to Windows.

Despite successfully protecting its APIs, Microsoft had a couple of threats brewing in cyberspace. Netscape and Sun were threatening to develop a far-reaching software hegemony in what is proving to be the greatest technological frontier since the PC.

As a result, Microsoft responded by “embracing” Netscape Navigator, Java, and other Internet technologies by supporting them. Microsoft then began “extending” these technologies by providing selected Windows enhancements and promoting a framework (ActiveX) that keeps its existing developer base in the fold, undermines JavaSoft’s “write once, run anywhere” objective, protects the attractiveness of Windows to users and developers, and promotes DCOM, Microsoft’s distributed object infrastructure.

Microsoft doesn’t hesitate to give away its browsers and Web/intranet servers for free, because this adds value to Windows and other Microsoft products while undermining Netscape’s business.

Where do they want to go today?

With Java established, JavaSoft wants to rapidly develop Java into a mature, robust programming language. JavaBeans helps mature Java by providing a compound document integration framework, as well as enabling developer tools to treat JavaBeans as first-rate components that can be linked together without manual intervention. Sun can even afford to give away all of this software infrastructure up front, because Sun’s primary business is hardware. The “constellation” of Java-branded hardware products, such as the JavaStation (Sun’s Network Computer), the Java Chip, and Java embedded systems technologies that Sun plans to sell into the “Java” market make sense in this context.

Microsoft, on the other hand, is primarily a software company, and in fact makes most of its revenue from selling applications such as its Office Suite. So its strategy with ActiveX is to “embrace and extend” Java to make it work better on Windows, Internet-enable its existing desktop apps and developer environments, and promote the Windows operating system and its associated apps as much as possible.

Microsoft’s real goal is the promotion of its distributed object technology, DCOM, a competitor to the Object Management Group’s (OMG) CORBA technology. Computerworld recently reported that 24 percent of IT shops have adopted DCOM, 14 percent have chosen CORBA, and the rest have not chosen yet. So Microsoft has a serious incentive to promote DCOM now rather than later: When a development shop commits to DCOM, that shop is committed to Microsoft’s distributed software component architecture “substrate,” locking in the Microsoft solution.

JavaBeans is only partially available at this time. It exists as a final spec and in a limited implementation for the current Java release. JavaBeans will be delivered in full along with Java’s 1.1 API, which by most estimates will be late 1Q97. ActiveX is already here, in the sense that OLE/COM code exists in abundance. Microsoft is working quickly to correct some problems with the technology, such as slow download time and security issues.

Both ActiveX and JavaBeans have broad industry support. JavaBeans has support from key players such as Netscape, Apple, IBM, and even Microsoft. Microsoft has supporting tool vendors and a large, established base of Visual Basic and Visual C++ developers.

Where do you want to go today?

So which framework is best for you? Depending on who you are, this question can be either hard or easy to answer. Let’s take if from the top:

Which framework will prevail?

Unknown. A safe bet is that ActiveX will soon support components written to JavaBeans. This seems to be a natural extension of Microsoft’s core strategy of embrace and extend, and would enable Microsoft to market ActiveX as a comprehensive framework that is compatible with everything. One thing that seems clear is that both sides will play their respective standards pretty close to the chest.

Who are your customers?

Of course, the ultimate determinant of what matters to you is what matters to your customers. If they require “pure Java” solutions, you have to provide JavaBeans. Conversely, if they require conventional binaries or those that support OLE/COM, ActiveX will be the order of the day.

What is your legacy codebase?

If you have a large Windows codebase, you have an incentive to move to ActiveX from OLE/COM. If your codebase is in Java, JavaBeans probably makes more sense.

Another key question — What about the technologies? — will be addressed in part three of this series. Stay tuned.