The JavaBeans API

Sun's Proposed Component Architecture Goes up Against ActiveX

The idea of a universally accepted, machine-independent standard component architecture for software development has never quite caught on--but not for lacking of trying. The idea is certainly inviting. Software tools vendors talk about the software equivalent of Lego building blocks, the ubiquitous children's toy from Scandinavia, where children select from an assortment of interlocking plastic pieces to create everything from trucks to Ferris wheels. A component architecture, they say, has the same allure. You connect preassembled software components together into a completed application, building at the component level, while eliminating, or at least reducing, line-by-line coding.

A universally accepted component architecture would revolutionize application development by enabling companies and programmers to reuse their software investment. And it would spawn a new industry in which third party vendors sell the components on the open market, with the architecture itself assuring inter-compatibility. Two of the most visible component architectures are being promoted by Sun and Microsoft: Sun's JavaBean API and Microsoft's ActiveX.

Sun views the JavaBeans architecture as a building block environment for the "thin client" model, in which applications live in the server and are downloaded to an inexpensive client: the much discussed Network Computer (NC). With their limited memory, NCs can only handle applications of a limited size--and besides, there is network traffic to consider. Hence, Sun argues, any component architecture must be small, efficient, and work on a variety of platforms. According to the JavaBean specification written by Sun's JavaSoft division, the JavaBean API is relatively simple, enabling developers to learn the basic concepts quickly so they can start writing and using simple components. Later, they can move up to the more sophisticated features of the API and perhaps write full-blown applications.

By contrast, ActiveX has its roots in Visual Basic Controls (VBX). In the 16-bit world, VBX has spawned a small industry in reusable code. It now remains to be seen whether its 32- bit extension, ActiveX controls (formerly called OLE Controls, or OCX), will have the same impact. In any case, ActiveX has been around longer than JavaBeans--which is still in the planning stages. But as a portable standard, JavaBeans--which relies on the almost universally implemented Java Virtual Machine--stands to be more successful at running on a variety of computers than ActiveX, which is Windows based.

Sun announced the completion of the JavaBean API specification last October. The company's partners in this venture seemed to include almost every software company besides Microsoft: IBM, Borland, Lotus, Netscape, Silicon Graphics, relational database developers Oracle and Informix, Novell, Symantec, and Corel Corp, among others. Indeed the move to counter Microsoft is so strong that it has made allies out of companies that usually compete. Silicon Graphics, of course, competes directly against Sun. Apple and IBM, who both support OpenDoc, are working with JavaSoft to insure two-way interoperability between JavaBeans and OpenDoc applications. And Informix is a rival to Oracle.

Meanwhile, Microsoft has countered by pointing out that it is both a Java licensee--having adopted Java for its Internet Explorer browser--and a competitor, as well.

"Java is a bundle of several things," wrote Cornelius Willis, group product manager for Microsoft's Internet Platform and Tools Division--in an August 1996 e-mail reposted to Microsoft's Web site. "It's a language, it's cross-platform byte code, and it's a safe-subset environment delivered on several platforms. ActiveX is none of these things: it is not a language, not a byte code, not an operating system, not a platform, and not a safe-subset. Nor is it intended to be." In Microsoft's view, ActiveX complements Java by giving Java developers the option to extend their Java programs using a third party library of components. ActiveX treats Java applets like first class ActiveX components, allowing them to be scripted and hosted in any ActiveX container. (As their name implies, containers hold a group of related components-- providing a context for components to be arranged and to interact with one another.)

Willis also points out that "ActiveX is the only software development model which has a vibrant industry of third-party developers behind it actually making money." Microsoft says that $240 million worth of components will be sold in 1996. The company projects that number to grow to $1 billion by 2000, and says that while ActiveX only works on Windows now, it will support it on UNIX and Macintosh platforms before the end of this year." (At this writing, Microsoft maintains that those deadlines will be met.) But of course, as Microsoft well knows, the race is not always won by the first horse out of the gate.

The JavaBean API

At the heart of the JavaBean API are Java Beans, which JavaSoft defines as "a reusable software component that can be manipulated visually in a builder tool." Java Beans can be almost anything from a GUI widget to an application in its own right. But unlike Java applets, Java Beans will be able to communicate with each other--an attribute known as "event handling." These events can include system events, such as a mouse click, as well as component-defined events: stock prices coming off a live data feed or troubleshooting data from a telemetry application. These events can be handled by a variety of other components to sound an alarm, change a visual display, or start another process.

Other areas covered by the JavaBeans API--and other component models as well, include :

Persistence: a mechanism for storing the state of components in a non-volatile place.

Layout control, including the means for a component to control its visual appearance within its own space and the mechanisms and services for a component's layout in relation to other components inside a container. For most applications, layout requirements in the context of a container are straight forward: each component is simply assigned a non-overlapping rectangular space.

Application Builder Support, or introspection: the ability of components to convey their properties and behaviors to application development tools. Such an interface enables tools to determine the properties (events) and behaviors (methods) of arbitrary components. The tools can modify the state and appearance of components, as well as establish relationships between components.

Ultimately, the universal adoption of a single component API is the key to the building-block vision for component development. Different programmers in different parts of the world, who have never met each other, and are working completely independently, can build Java Beans that nevertheless work together.

Java Beans on Web pages

In fact, Sun makes the case that non-programmers will eventually be able to take these Java Bean components and use them for their own purposes. The company's Project Studio technology, which is still in development, would create a new job description for Web page designers--who would be able to populate a Web page with a wide variety of Java Beans.

"Consider a bank who wants to present online account information to its customers," said Larry Weber, vice president, general manager, Sun WorkShop Products. "The bank development team could build a Java Bean whose role in life is to extract this information from an account database. To retrieve the appropriate information, the development team might produce another custom Java Bean in the form of a fill- in-the-blank sheet for a customer to fill in his or her name and ID number. Another Java 'Form' Bean could display this information in an easy to understand format."

According to Weber, the form and function of Java Beans is limited only by the imagination. You could have a Java Bean that plays audio, that displays the time, or that runs an animation. Moreover, all of these components can communicate with each other, so that the 'Clock Bean' could communicate with a display Bean to show a sun in the morning and a moon at night.

Weber believes that the concept of Java Beans and Project Studio technology suggest the birth of a new business, in which cottage industries and large corporations alike create Java components that other people can assemble.

"A few years from now, we envision Project Studio technology being viewed not as a specialized application, but as a commonplace productivity tool--as common as spreadsheet, word processor, and slide presentation packages are today. At some point, Web-based content could become as ubiquitous as the printed page is now."

Microsoft--a reluctant Java licensee

Microsoft's dual role as a Java licensee and competitor has already lead to some skirmishes over the JavaBean API. The issue is over "containers"--an essential part of any component architecture. While Java Beans can be nested within other Java Beans, at the top level, a root Java Bean is nested inside a platform-specific container, such as Microsoft Word, Visual Basic or Netscape Navigator. At that point, the JavaBeans API must be integrated into the platform's local component architecture.

In the case of Microsoft, Sun proposes that JavaBeans APIs be bridged to COM (Component Object Model) and ActiveX. Specifically, JavaSoft is developing a bridge that will allow a Java Bean to ride inside of any COM/OLE/ActiveX container, enabling a JavaBean to act as a first class component inside of Visual Basic, Visual C++, Word, Excel and Internet Explorer. This bridge will convert Bean events and properties into COM events and properties and will allow the Bean to act as a server for OLE automation calls.

Similarly, the JavaBean API is ultimately supposed to support several such component models, most notably Netscape's LiveConnect, and OpenDoc, and well as such OLE containers as PowerBuilder and Borland's Delphi--using Java libraries to bridge the JavaBean API to these component model implementations. The idea is to keep the environment 100 percent "Java pure," and thus, fully portable.

But while Netscape, IBM and Borland are more or less Java allies, Microsoft is not. Yet Microsoft is required by its licensing contract with Sun to support JavaBeans even when they conflict with Win32 APIs. But reluctant support is quite different than enthusiastic promotion. "We are required to offer the Java APIs, but that does not mean that we have to ship them in every version of Internet Explorer," said Robert Muglia, vice president of development tools at Microsoft, in an interview with the publication PC Week.

The Willis e-mail put it more directly: "We don't see how JavaBeans add value over and above ActiveX support already in Java....As a Java customer, we are deeply disappointed by the way Sun has managed the introduction and development of JavaBeans. There has been no design review, no open process, not even a private technical briefing, and certainly no spec [specification]--only a press release and a marketing white paper. We certainly can't make any commitments to support and ship it until Sun provides us with an actual specification for it."

JavaSoft's Jon Kannegaard, vice president of software products, replied: "This could be a case of Bob [Muglia] and I having to have a talk," Kannegaard contends that none of the JavaBean APIs will create problems for Windows. "This is a case of much ado about nothing," Kannegaard said, "especially given that Java Beans already can run inside of an ActiveX container."

Hedging their bets

For many developers, the JavaBean/ActiveX schism means hedging their bets until a standard emerges. But the hope seems to be that the two companies will find accommodation, rather than fighting until only one technology is left standing.

"The major advantage I see in a hybrid technology is that you can leverage your existing code," said Mini Srivathsa, a system architect for ARI Network Services, in Milwaukee, Wisconsin. "If I have written an OLE server or OLE component in Visual C++, I don't want throw it all away and rewrite it if I don't have to." She says that her main concern is not functionality between the two technologies, but performance degradation from too much overhead.

Srivathsa is particularly interested in JavaBeans portability for applications like the one she is now building, which combines components running on both Mac, Windows and Sun machines. She doubts that Microsoft will deliver a truly standards-based implementation of Java with respect to ActiveX interactivity. "Given Microsoft's track record with HTML standards, I am skeptical about [possible] nuances that would make ActiveX-to-Java bridges Microsoft-specific. Sun, on the other hand, had been able to successfully integrate Java Beans with IBM's OpenDoc standard."

Srivathsa is not alone in her suspicions. Microsoft is still regarded as an outsider when it comes to Internet standards-- at least among people who are not fully married to Windows. But just because Microsoft seems to be teaching its old technology new tricks doesn't the company won't become the dominant player in Internet development. With Windows the de facto standard desktop environment and NT coming on strong, Microsoft is in a good position to make ActiveX the default component standard in all-Microsoft environments. The real race is for mixed environment, or at least those that have a non-Windows component. As usual, Microsoft will accommodate where it must, and displace its competitors where it can. With Java, Microsoft has so far done the former, and is working hard to do the latter. The competition is healthy. Both technologies--JavaBeans and ActiveX--are likely to improve, as a result.

An interview with Larry Weber, vice president, general manager, Sun WorkShop Products

ActiveX has a substantial head start as a component architecture. JavaBeans is still a spec. Is that a problem?: It's a small problem. But you have to understand that ActiveX doesn't solve the problems that JavaBeans solves. ActiveX is fundamentally a Windows/Intel binary library, written in C and C++. It is implemented using the Windows API. Because it's a binary implementation, it presents all the maturity and reliability concerns that you have about shipping any binary. And ActiveX components don't have the reliability and security safeguards that Java components have.
You're saying there are potential reliability problems that don't exist In Java?: Absolutely. For example, there are no pointers in Java, so you must write to specific locations--and can't point to bad memory locations. You get the functionality of pointers because you get objects that get created and destroyed. Think of it as a higher level abstraction that would normally be implemented by lower-level, machine-dependent methods.
Sometimes bad technologies win out over good ones simply because they end up with the market share. Don't you need developers to start writing to the API?: There are a lot of people developing JavaBeans today, and even as the spec was getting written. The spec is complete now so people can write to it.; You're right in that better doesn't mean that you're a winner. But the fact is that if you allow components to flow across an insecure network like the Internet, ActiveX just doesn't have the capability to ensure they are secure. It's easy for them to contain viruses, and it's also easy to have bad code. One of the solutions that Microsoft is proposing is digital signing of components. For example, if you send me a component, I know it comes from you. If you crash my system, at least I know it was you that crashed my system, and not someone else. That's an advance, but it's not a significant advance. And of course, ActiveX components will only run on a Windows machine.
What about Apple and UNIX? Microsoft said they will support those two environments by the end of 1996.: They are saying that something which is like the Windows ActiveX will be available on UNIX and the Mac. But it's still the wrong code--just as being compatible with the Solaris SVR4 ABI binary standard doesn't help when running those same programs on Intel.
So you are arguing that the Java Realtime Machine makes the Java Bean more portable?: That's right. A Java Bean written in Java can run in any Java machine, anywhere. ActiveX components written for Intel can only run on Intel, and ActiveX components written for Mac can only run on Mac. So if you were an ISV, if you want to run on both Mac and Intel, you are going to have to produce your ActiveX components in both flavors. And your users are going to have to know which flavor to pick. Therefore, you can't really be sure of putting them on Web pages unless you have Web pages for your Mac users, and different Web pages for your Intel users. This is not what we or our customers want.
How do Java Beans compare with CORBA and Joe as a distributed environment?: The JavaBeans specification describes the object itself, not how you connect components across a network. JavaBeans is comparable to a DLL--it's the library, while CORBA is comparable with OLE and DCOM. [Distributed Component Object Model].
If you run JavaBeans over a distributed environment, can the container of components be on different nodes?: They always execute on your local machine because it is a virtual machine. But there's no reason why Java can't come from different nodes. However, when you run things like HTML, the only things you can get to on that HTML page are what the server supplied to that page. You can't have one page with GIFs from two different machines.
Is the communications mechanism a part of the JavaBeans spec?: No.
Aren't there Java remote procedure calls.: Yes, there's an RPC mechanism called "remote method invocation" or RMI. In fact, there are several different ways of connecting up Java across the network.; We decided while designing JavaBeans that we couldn't afford to tie it to a single communications architecture such as RMI or CORBA IDL--because different customers have different needs. So we leave it up to individual Bean developers to decide what communication mechanism is appropriate for their Bean.; For example, if you are writing a "Bean pair" and delivering both a client-side GUI Bean and an invisible server-side Bean, then you might well decide to use Java RMI, as it's a very convenient way of connecting Java clients to Java servers.; But we also think that CORBA IDL is a natural fit for programming with the JavaBeans API. After all, JavaBeans is a platform-independent component model, while CORBA is a vendor- neutral, heterogeneous, distributed computing model. That looks like a great match to us--allowing you to run your JavaBean components on arbitrary client machines and connect to CORBA servers written in arbitrary languages on arbitrary servers.; Another choice is JDBC [Java's answer to ODBC--Open Database Connectivity], if you need to communicate directly with the database through SQL.
Is Web pages where you see this technology being implemented first and foremost?: Initially it will be used in Web pages. We are coupling Java Studio with a WYSIWYG (what you see is what you get) HTML editor, so you can develop to HTML and the JavaBeans in a single environment and put them together.
Do you see going on the Web pages as a limitation, or Web pages becoming the universal background, so to speak?: Not universal, but it will be a highly popular background.
What's beyond that?: The opportunity to build standalone applications using Java Beans. Without the Web or networks, there is no need to invent another set of tools like Java. But with the Web, you need the additional features and functions that Java gives. And so we are seeing that a lot of people who want to do all their programming in Java--even things that they could have done in C and C++. We have requests now to build high performance compilers for Java that act and taste and look like C++ compilers.; When you think about it, that's not so surprising. Say you are a Java programmer using the Internet, and someone comes to you and says I need you to write me an application to do, say, data reduction. If you already have all the tools in place to do Java and you are already an expert at Java, why do you want to change languages? It's not that you couldn't do it in something else. It's just easier.
Are you predicting that Java could supplant C++ over the long term as the application development language of choice?: Not supplant it, but it will take away some of it's growth.
Will you have to enhance or extend the language to do that?: We probably do have to increase the libraries, and JavaSoft is actively doing that right now.