Related Web Works

Java(tm) Beans: A Component Architecture for Java

July 1996

----------------------------------------------------------------------------

Over the past few years, constructing applications by assembling re-usable software components has emerged as highly productive and widely accepted way to develop custom applications. First generation products such as Microsoft's Visual Basic, with its VBX components and "forms-based" application assembly process proved to be very useful in building a broad spectrum of applications. Visual Basic has since been followed by other products such as Borland's Delphi which further enhanced the basic component assembly application development model by adding more powerful data access components and object-oriented component extension capabilities.

Java Beans take the component software assembly paradigm to a new level. Java Beans is an architecture and platform neutral API for creating and using dynamic Java components. Java Beans build on the strengths of the component assembly development model established by these pioneering products, and extends the power further. Application developers will be able to use a variety of development tools to assemble custom applications from fully portable Java Beans. This document is a brief overview of Java Beans and its functional capabilities. It discusses:

* How Java Beans extend and enhance the capabilities of the portable Java Platform

* The key elements that make up a software component model

* Highlights of Java Bean functional capabilities

* How to prepare for Java Beans

* How Java Beans Extend the Java Platform

----------------------------------------------------------------------------

Building on Java Strengths

Java has quickly established itself as the industry standard platform for building fully portable Internet and Corporate Intranet applets and applications. The Java platform provides a number of advantages to developers for these types of applications:

áFully portable platform: language, libraries and virtual machine pervasive presence of the Java platform in Browsers, and soon within Operating Systems themselves, allows developers to write application functionality once and deploy the application broadly on a wide variety of OS and hardware platforms.

áPowerful and compact environment: The Java platform provides developers with the full power of an object-oriented language while eliminating the complexity, housekeeping and heavier weight object creation and registration processes required by other language and programming model environments. The lightweight runtime can be incorporated in chips for embedded systems, in PDAs as well as client and server class PC's and workstations where Java is becoming increasingly pervasive.

áNetwork aware: From its inception, the Java platform has been network aware. TCP/IP support is built in. Security mechanisms which allow full protection from applet interference with client-side data are built-in. Finally, the platform was designed to allow applets to be built from self-describing classes which can be easily downloaded to the client-environment without the need for heavy weight installation or registration processes.

Java Beans build on all of these strengths and extends the Java platform further.

----------------------------------------------------------------------------

Extending the Java Platform

Today Java applets provide a simple static component model. Applets can be placed on Web pages; however, they cannot interact with the page or with other Java applets on the page.

Java Beans enhance the Java platform by allowing richer, more dynamic interaction. Java Beans allow developers to define independent components that can be used and re-used in a variety of combinations to compose new applications inside a variety of Browser and non-Browser environments. (e.g., HotJava, Netscape Navigator, Internet Explorer, Visual Basic forms, and Claris Works).

Java Beans components can be GUI widgets, non-visual functions and services, applets and more full scale applications. Each of these components can be built by different developers at separate times. Java Beans components do not need to be part of the same application build. Instead, they communicate dynamically.

For example, let's look at a web site which provides on-line banking services. The web site might start out allowing a user to view historical interest rate data using a graph format. This web page would include two Java Beans components: an interest rate data retrieval component and a charting component. The interest rate retrieval component retrieves data on interest rates. It then interacts dynamically with the charting component to make a graph of the data.

At some point in the future, the web site developer could add a new component that lets customers retrieve historical account balance information. The account balance data in turn can be charted by re-using the existing charting component. The developer does not need to re-build a new application that combines all three elements as one whole. Instead, the developer only needs to add the new account balance retrieval component. Since Java Beans is part of the Java platform, the new component will be able to communicate with the older chart component dynamically as needed. Note that the charting and interest rate retrieval components could be provided by commercial software developers, and the account retrieval component might be custom built for the particular bank.

Thus, Java Beans further enhance the Java platform by adding new levels of dynamism, flexibility and re-use.

----------------------------------------------------------------------------

The Power of Java Beans

In keeping with the design philosophy and strengths of Java, Java Beans will be easy to build and use, compact for network deployment, and of course fully portable.

Java Beans will enable tool vendors to build more powerful, highly productive Java assembly tools. Java Beans will empower application developers to add even more exciting levels of interactivity and richer functionality to their Internet and Intranet applications.

Finally, developers will be able to re-use Java Beans in a number of popular environments, thus extending their usefulness. Java Beans will be re-usable in a variety of components assembly tools and containers such as HotJava, Netscape Navigator, Borland's Delphi, Microsoft's Internet Explorer, Visual Basic, Word, and Claris Works.

Since Java Beans are fully portable across all Java enabled platforms and can be used in the widest variety of development tools and containers, commercial developers of Java Beans will have the broadest possible customer base to target.

The Java Beans API section of this document outlines in more detail the key functional elements and capabilities of Java Beans.

----------------------------------------------------------------------------

Component Model Overview

Before describing the services provided by the Java Beans API, it is useful to have a high level understanding of the key elements and services provided by component models in general.

Component Model Elements

A component model is an architecture and set of APIs that allow developers to define software components that can be dynamically combined together to create an application. A component model consists of two major elements: components and containers.

Components can range in size and capability from small GUI widgets like a button, to applet size functionality such as a tabular viewer to a more full sized application such as an HTML browser of a text layout application. Components can have a visual appearance such as a button, or can be non-visual, such as a data feed monitoring component.

Containers are used to hold an assembly of related components. Containers provide the context for components to be arranged and interact with one another. Containers are sometimes referred to as forms, pages, frames or shells. Containers can also be components, i.e. a container can be used as a component inside another container.

Component Model Services

A component typically provides five major types of services:

* Component Interface Publishing and Discovery

* Event Handling

* Persistence

* Layout

* Application Builder Support

These are described in greater detail below.

Runtime Component Interface Publishing and Discovery

This is the mechanism for components to "publish" or "register" their interfaces so that they can be "driven" dynamically by calls and event notifications from other components or application scripts. In our on-line banking example above, this publishing and discovery mechanism is what allows the account balance component to ask the charting component to draw a graph of its data. Since the charting component has "registered" its interfaces to the component environment, the charting component does not need to be of the same application "build" as the account balance component. Instead, even though they were built separately, they can interact in a dynamic way using the services provided by the component environment.

Event Handling

Event Handling is the mechanism for components to "raise" or "broadcast" events and have those events delivered to the appropriate component (s) that need or want to be notified. Notified components in turn typically perform some function. For example, if the developer of the on-line banking application provided a button for the user to select between a bar chart or a line graph, the event handling systems would notify the charting component when the user clicked on the button component.

In addition to system events such as clicking the mouse, components can define their own events. For example, a component that monitors a live data feed such as stock ticker information or the power status of a change in stock price or a change in the power level of the machine. The "data changed" event could be handled by a variety of other components to sound an alarm, change a visual display or start another process.

Persistence

Persistence is the mechanism for storing the state of components in a non-volatile place. Component state is stored in the context of the container and in relationship to other components. For example, if the user wanted to save the on-line banking web page with their account information and chosen chart type, the persistence mechanism would support this.

Layout

There are two major types of layout control which component models support. First, they provide a way for a particular component to control its visual appearance within its own space. Second, component models provide mechanisms and services for a component's layout in relation to other components inside a container. This includes services for handling appropriate behavior when the component is activated. For some types of components this may include such things as menu bar merging.

For the great majority of applications, layout requirements for components in the context of a container are straight forward. Most component layout requirements are satisfied by giving each component a non-overlapping rectangular space. Developers control the lay out the components (buttons, viewers etc.) in a logical, easy to use manner that supports the application's functionality. End users do not rearrange the components at runtime.

Application Builder Support

Application Builder Support interfaces enable components to expose their properties and behaviors to Application Builder Development tools. Using these interfaces, tools can determine the properties and behaviors (events and methods) of arbitrary components. The tools can the provide mechanisms such as tool palettes, inspectors, editors which the application developer uses to work with the various components to assemble an application. Through these mechanisms the application developer can modify the state and appearance of components application developer can modify the state and appearance of components as well as establish relationship between components.

For example, let's look at the button and charting components from our on-line banking example. Recall that when the end-user presses the button the chart switches from a bar chart to a line graph. When assembling this application, the application developer uses property editors to specify the appearance (size, color, label) of the button and the default type of chart (bar chart) to display. The developer uses other application development tool mechanisms to specify the relationship between the button's "click" event and the chart component's "chart type" property.

----------------------------------------------------------------------------

Distributed Computing

In addition to these five major services, component models often provide a strategy for using the components in a distributed computing environment. For example, a component that monitors the status of a factory floor machine may run on a server attached to that machine. If a data value changes, the server component may raise an event which gets delivered over the network to another software component running on a desktop machine. The desktop component could then respond appropriately, perhaps posting a message, or changing the shape of a graph.

Clearly, there is a big difference between software components interacting on a single computer and components interacting over a network. Besides needing to take into consideration the slower speeds of a network, the developer and distributed computing infrastructure also need to provide appropriate recovery and re-synchronization mechanisms should either component or machine fail in some fashion.

Attempting to simply extend a single machine desktop component model to encompass all the requirements demanded by complex heterogeneous networked computing environments is fraught with problems and trade-offs. The desktop component model will either become burdened with more complex APIs and heavier weight execution environments, or the distributed computing capabilities will be less than robust.

Consequently, component models that are serious about providing full distributed computing capabilities will leverage robust established distributed computing technologies such as CORBA. This way the single machine component model can be kept compact and light weight, while also providing access to rich functionality that may be required by distributed applications.

The next section of this document discusses Java Beans in the context of the elements and services that comprise a software component model.

----------------------------------------------------------------------------

Java Beans API Highlights

Java Beans is an architecture and platform neutral API for building and using dynamic Java component and container functions, and provides assess to the five major component model services outlined above, namely:

* Component Interface Publishing and Discovery

* Event Handling

* Persistence

* Layout

* Application Builder Support

Java Beans component model services can be implemented by bridging to specific component models, including Microsoft's OLE/COM, CI Lab's OpenDoc, Netscape's Live Connect. In addition Java Beans will run on JavaSoft's embeddable JavaOS. Libraries bridge the Java Bean API to the various component model implementations.

Thus, a developer can build components completely in Java using fully portable Java Beans APIs. Developers will not have to intersperse non-portable platform or component model specific calls in their portable Java code. The Java platform (which will include the Java Beans APIs) allows component developers to write both the functional capabilities and component behavior aspects of a component completely in Java.

Java Beans components raise the Java notion of "write once, use anywhere" to a new level. Java Beans integrate in a high quality way into a variety of containers, including Netscape (using Javascript and LiveConnect), in HotJava and other Java containers, and Microsoft containers (such as Explorer, Visual Basic, Windows Shell, and Word), OpenDoc containers, and OLE containers such as PowerBuilder, Delphi and other visual builder tools that support OLE/COM.

Java Beans services will be part of the Java platform. This means that developers will not need to distribute any extra libraries in order for applets and applications built using Java Beans to work. In addition, Java Beans will be able to be used outside of containers as independent Java applets which can communicate dynamically.

The Java Beans platform and architecture neutral API in combination with the fact that a Java component's full functional implementation is also fully portable make Java Beans highly re-useable. Unlike with other component models, Java Beans are not bound to a particular platform or container or component model. Consequently, commercial developers of Java Beans will be able to target the broadest possible market.

Consumers of components will get the highest leverage from the purchase and time spent learning to use a Java Bean component. They will be able to re-use Java Beans in a wide variety of Internet, Intranet and even proprietary client/server applications.

Details of the Java Beans API will be described in a future document when the APIs are finalized. In the meantime, the following section provides some insight into the design goals and characteristics developers can expect to see in the Java Beans API.

----------------------------------------------------------------------------

Design Goals

The major design goals of the Java Beans API and implementation approach are:

Java Beans is compact and easy to create and use.

Java Beans can be very compact and simple to create. In particular the simple components will be very easy. Building more complex components in Java will be possible as well. By fully leveraging the Java platform's functionality they can also be kept very compact.

Existing component model APIs have emerged by scaling down from complex heavy weight application size component to include lighter weight widget size components. In contrast, Java Beans APIs have been designed by scaling up from simpler lighter weight widgets and applets towards more full function applications. Consequently, the Java Beans API will not overburden the smaller widget and applet size components with complexity and weight. Since these smaller sized components are most prevalently used, Java Beans' compact design will be advantageous to both component builders and component consumers.

Java Beans is fully portable.

Java Beans are fully portable through the platform neutral Java Beans API and bridging libraries that will be part of the standard Java platform. As a result, developers will not need to include non-portable code or be concerned with including platform-specific libraries with their Java applets.

Java Beans leverage many of the inherent strengths of the Java Platform.

Java Beans takes advantage of the existing class discovery mechanism already built into the Java platform. This mechanism uses Java's unique introspection and reflection technology. This means that Java does not need to introduce additional, heavier weight registration mechanisms to the runtime to support interface publishing and discovery.

In addition, consistent with Java's overall design center of using light weight and easily understandable mechanisms, many Java Beans will not require any additional programming by the developer. For example, AWT components will be Java Beans automatically.

The Java Beans libraries will also provide default component behaviors for simple components. For example, automatic persistence will be handled using Java serialization. In addition Java Beans will provide automatic generation of property editors by examining a component's get and set methods. Of course, component developers will be able to override the default behavior as may be required by more complex components or a desire to provide richer component editors.

Finally, Java Beans components will also benefit from the new AWT desktop intergration capabilities such as cut-copy-paste and drag-and-drop.

Java Beans leverages robust distributed computing mechanisms.

Java Beans component model APIs and implementation are focused on components interacting in a single virtual machine. Rather than over complicating the Java Beans API or burdening the Java platform with heavier weight distributed computing mechanisms, Java developers will be able to chose among several distributed computing approaches. For example, developers will be able to add distributed component interaction to their Java applications by using Java's Remote Method Invocation, by using industry standard CORBA IDL interfaces for remote object access, or by other distributed computing mechanisms. Developers will be able to chose the mechanism that best suits their portability, performance and legacy integration requirements.

Flexible build-time component editors.

Java Beans will allow component developers to specify a broader variety of build-time property sheets, inspectors and editors for their components. This will allow developers to provide the most productive way for component users to reap the full value form component capabilities. For example, a data base connection component provider might want to provide more than a long, complicated property sheet for the developer to use at build time. Instead the component provider might want to organize the various properties in tabbed sections or perhaps allow the component user to visually specify table joins at build time. The Java Beans Application Builder Tool APIs will support a way for component developers to create the best type of property editor for their component type.

----------------------------------------------------------------------------

Implementation Progress

At the JavaOne Conference in May, key industry leaders announced their commitment to support and leverage the power of Java Beans.

JavaSoft has prototype Java Beans components working today as part of the design review process. JavaSoft is working closely with partners to ensure first class bridges can be built to existing component models such as OLE/COM, OpenDoc, and Live Connect. It is very important to these partners to have high performance implementations of all aspects of the Java platform, including JavaBeans. This way Java licensees ensure the best possible end user application experience.

In addition, several component builders and creators of Java developer tools are actively involved in the API early review process.

JavaSoft intends to provide additional details as we rapidly move toward public review of the Java Beans API this fall. An SDK will follow finalization of the Java Beans API and will be posted on the JavaSoft server for downloading.

----------------------------------------------------------------------------

Preparing for Java Beans

In anticipation of Java Beans, developers should continue their Java development efforts. Developers should take advantage of Java AWT, as these will become Java Beans with no additional developer effort. In addition, developers should make use of Java serialization capabilities. Developers planning or building more complex distributed Java applications should continue to design those applications with all Java applications. Developers can take advantage of Java's Remote Method Invocation (RMI) or use CORBA standard IDL.

----------------------------------------------------------------------------

Conclusion

Java Beans further enhance the portable Java platform by adding new levels of dynamism, flexibility and re-use. Java Beans take the component assembly model of application development to a new level. Java Beans are compact, easy to build, fully portable, and re-useable in the broadest number of containers and environments.

Java Beans will enable powerful and exciting new types of corporate Intranet applications and Internet interactivity.

Java Beans Write Once Run Anywhere Re-Use Everywhere

---------------------------------------------------------------------------- Copyright © 1996 Sun Microsystems, Inc. All rights reserved.