Javasoft's Latest Specification Extends Java to Support Cross-Platform Object Technology.
Using object technology in real mission-critical solutions has been predicted for over a decade. Although the market has been pioneered by Microsoft Corp.'s VBX technology, few companies design and deploy their own objects or distribute objects over a network. The recent release of distributed Microsoft ActiveX controls and JavaSoft (a division of Sun Microsystems Inc.) JavaBeans will most likely bring objects into everyday use in many organizations. JavaBeans promises to be a powerful, cross-platform object technology. Java, the platform-independent language, has garnered a great deal of excitement and press coverage in the last year. However, without a component model, Java does not compare with the robust platform of Visual Basic and C++ with OCX/ActiveX plug-ins. JavaBeans brings a component model to the Java framework, allowing programs to be built from small reusable controls. JavaSoft created the JavaBeans specification to support either visible or nonvisible components. Therefore, JavaBeans technology can be used in almost any solution. There are certainly competing object frameworks for JavaBeans. The equivalent of JavaBeans in the Windows world is the ActiveX/OCX/VBX controls. In the Unix world, a rough parallel can be found in toolkits and widgets. Depending on your deployment goals, JavaBeans may be the best cross-platform object technology available.
Before JavaBeans and the ability of introspection, there was no way for Java applets to run simultaneously and share information. JavaBeans support a dynamic hookup model that is included with the new AWT model. Multiple JavaBeans can be used in a single environment to interoperate and communicate. For example, a JavaBean could monitor a stock on the market. When the value of the stock reaches a certain point, it could notify an email JavaBean that sends a message to a favored customer.
The structure of a JavaBean is really just a Java class that adheres to certain property and event conventions. By constructing a class to support introspection, that JavaBean can be used by a development environment, a program, or other JavaBeans. Because the creation of a JavaBean only requires certain guidelines to be followed, a JavaBean can be an applet as well. To be used as a traditional applet, it must subclass itself from the java.applet.Applet class. After the correct members have been added to the class and exposed to other classes, current applets can be quickly converted to JavaBeans for reuse.
You can use JavaBeans as applets or placed within another application in the same way that you can use OCX or ActiveX controls. To place a JavaBean within an application, that application must support container capabilities that are required by the JDK 1.1 specification. In addition to standalone use, JavaBeans can be embedded within one another.
To make the entire JavaBeans technology effective over the Internet, a JavaBean can be split into two separate parts, a design part and a runtime part. This division lets a JavaBean have a full-featured design-time environment that might include wizards and help but can jettison these items for final JavaBean distribution. The Customize interface for the JDBC JavaBean lets you examine tables and select fields to set the properties of the JavaBean and construct the correct SQL Select statement. This Customize Wizard would not be present in the final compiled JavaBean.
JavaBeans can be made robust and easy to use during design, but you can still keep the download size fairly small. Given bandwidth and time issues, small download size is extremely important for use over the Web and especially over the public Internet.
Unlike Java applets, JavaBeans also have persistence, allowing them to be saved to hard disk or network drive. They can be stored with all of their current properties intact, allowing the creation of a dynamic data environment. These storage routines are known as object serialization, which is one of the routines that all JavaBeans are required to support. Providing persistence for JavaBeans should address the significant barrier to full application deployment that Java has so far faced.
JavaBeans may be stored in JAR (Java Archive) files. These files use standard PKZIP-compatible ZIP compression and are used to store all of the classes needed for a particular applet or JavaBean to function. A JavaBean JAR may contain a file known as a Manifest that describes all of the files within the JAR, including the icon files, design components, and runtime classes.
The JavaBeans technology provides excellent object features that have a very small footprint. However, JavaBeans do have some significant limitations at this time. To begin with, JavaBeans have serious limitations in a runtime environment. Users cannot move or resize a JavaBean within its container. This type of manipulation can only occur at design time. Also, new instances of the button cannot be added to the container at runtime. This makes the JavaBeans technology limited for the types of dynamic documents (such as embedding a button in your word-processing document) that many vendors such as Apple Computer Inc. (with OpenDoc) and Microsoft Corp. are promoting. These missing features, along with Java's lack of drag-and-drop features, can limit the scope of user interface available to your client application.
More problematic than some of its usability shortcomings is the lack of provided distributed computing functionality. Although JavaBeans can use the Java Remote Method Interface (RMI) to talk to each other, they cannot exchange objects or use a standardized object distribution protocol. To address this shortcoming, JavaSoft intends to make the JavaBeans compliant with the CORBA specification. However, many of the CORBA systems themselves are incompatible with each other. Therefore, multiple pieces of middleware will most likely be needed (and debugged). In other words, JavaBeans supplies no out-of-the-box solution such as the one provided by ActiveX and DCOM.
Most important to client/server system developers is the JDBC interface, allowing access to database information. JavaSoft includes a sample JDBC access JavaBean to demonstrate the power of client software development. Also included is a JDBC-to-ODBC bridge so that you can access any typical ODBC data source.
To let you test this JavaBean and other samples included, the BDK includes something called the BeanBox. The BeanBox lets you test components by providing a simple testbed environment. Within the BeanBox window, JavaBeans can be resized and properties can be edited, and you can connect a JavaBean event source to a JavaBean event handler, save and restore sets of JavaBeans, and add new JavaBeans from JAR files.
Java, already fairly slow when compared against other technologies (such as C++, Delphi, or Visual Basic), is further hampered by an additional framework. In my testing with the JDBC-to-ODBC bridge, most data-retrieval functions were fairly slow on all but the highest-powered machines. This sluggishness is not unexpected, considering that Java is already interpreted before JDBC is called, which in turn calls ODBC when an ODBC data source must be accessed. As more native JDBC drivers become available, I expect speeds to improve.
The most difficult barrier faced by JavaBeans is availability of client environments. JavaBeans are fully supported in JDK 1.1. This means that there are currently few places to run JavaBeans components outside of the new Java Virtual Machine. Neither Netscape Communication Corp.'s Navigator 3.0 nor Microsoft's Internet Explorer 3.0 supports the 1.1 release. Therefore, JavaBeans cannot be used on most current browsers. Version 4 of both of these products promises to include JDK 1.1 compatibility. This is problematic, because even when Microsoft and Netscape release the new versions of these browsers, the installed base for older versions will be staggeringly large and will remain so for quite a long period of time.
The most promising development environment I examined -- currently named Jato but slated for release later this year under the name PowerJ -- is brought to you by the creators of PowerBuilder. Powersoft Corp.'s Jato uses the development environment the company created for Optima++, so the Jato environment is visual, fast, and fairly solid. Particularly compelling is the integration within Jato of support for both ActiveX and Java components. Solutions can therefore be written in Java and take advantage of the object technology most suitable to your application.
The environment itself allows easy additions of components to the project palette. Coming from Powersoft, Jato emphasizes database access, including three components to provide a session to a JDBC data source. The controls -- a data navigator control, a query control, and a transaction control -- all provide access to databases that seem to maximize the abilities of JDBC.
Visual Café Pro (the successor to the original Café environment) from Symantec Corp. lets you use any one of its approximately 100 included components. It also lets you create JavaBeans from scratch. Visual Café Pro actually extends the JavaBeans specification to permit additional attributes and descriptions to be added to a component. These extensions do not in any way affect deployment of your JavaBeans creations, but they may lock you into the Café environment.
Borland International Inc.'s JBuilder has received praise from many of the people who have seen a demonstration. Unfortunately, at the time of this writing, the beta was still unavailable, but the product promises full support of the JavaBeans specification. On the strength of the Delphi development system, JBuilder would certainly be worth a look.
IBM Corp.'s Visual Age development environment should provide one of the most full-featured JavaBeans environments based on IBM's commitment to Java technology, integration with current OpenDoc systems, and ownership of the distributed object technology DSOM. In fact, in early February, IBM launched a round-the-clock development effort to create JavaBeans for the Visual Age environment (called Visual Age PartPaks). IBM is planning an open beta of Visual Age for Java, so check the company's Web site for more information.
IBM has also announced the creation of DataBolts, which should be of great interest to database developers. These components (to be available as either JavaBeans or ActiveX controls) provide database access and encryption for Internet applications. Some of the planned DataBolts include the Query and Retrieval DataBolt and the Cryptolope DataBolt.
Microsoft's Visual J++, a principal environment for Java development, does not yet support the JDK 1.1 specification. Microsoft has announced its intention of providing full implementation but has released no dates for its inclusion in Visual J++. Only time will tell how Microsoft will support a technology that competes with the company's own ActiveX.
In addition to development systems that can be used to create JavaBeans, JavaSoft has released the beta of a JavaBeans-to-ActiveX bridge. Essentially, an ActiveX control has been created that can host one or more JavaBeans. Therefore, environments that support ActiveX (such as Microsoft Word or Excel) can execute JavaBeans from within an ActiveX control. This control is available free through the JavaSoft Web site. This control was made with the intention of enabling people currently developing in ActiveX environments to use JavaBeans.
The Object Management Group has created an object standard known as CORBA (Common Object Request Broker Architecture), which is meant to be a cross-platform open standard for object creation and communication. For its distributed object environment, JavaSoft has chosen to support CORBA in order to leverage CORBA's presence in the Unix community. This choice should enable the JavaBeans component to interoperate with objects and systems already deployed.
JavaSoft has created an interface called Joe that lets Java programs interface with Sun's CORBA-based NEO server. Sun promises to extend Joe to enable it to talk to other Object Request Brokers (ORBs) such as those produced by DEC, Visigenic Software Inc., and Iona Technologies Inc. Meanwhile, these vendors are releasing their own ORB-Java interfaces. Iona is demonstrating a connectivity driver between Java and its DataBroker ORB. Borland will integrate JBuilder with Visigenic's VisiBroker for Java object connectivity. These and other vendors could provide a robust, mix-and-match middleware market for JavaBeans connectivity.
On the desktop front, JavaSoft plans to use the OpenDoc technology to establish a presence. Apple and Sun have announced a planned integration of JavaBeans and OpenDoc. The announced strategy will position OpenDoc as an ideal desktop object technology (used for desktop application such as word processors and spreadsheets) and JavaBeans as the perfect network object technology (for instant download of small components and the creation of client applications). The usefulness of this agreement will depend on the strength of the OpenDoc deployment, which so far has been fairly weak.
The most successful desktop object technology is the Microsoft ActiveX and DCOM standards. JavaSoft is pushing hard to create a bridge between Microsoft's ActiveX and JavaBeans. The JavaBeans to ActiveX Bridge is the first step in this direction, allowing Java Beans to be inserted into an ActiveX environment. The technology, on first look, is fairly impressive. A JavaBean may be placed on a Visual Basic form, for example, and receive events. It seems to function almost as a standard ActiveX control. There are some rough edges on the creation system, but the technology is significant.
However, this technique is not as simple or efficacious as it first appears. Because ActiveX controls must be registered in the OLE Registry, the JavaBean must essentially be created with a wrapper to enable it to function in an ActiveX system. This means that the deployment of a JavaBean in such an environment requires an extra utility that creates the ActiveX control from the JavaBean. This creates a far-from-transparent deployment process and may lead to compatibility problems, which often occur when an additional piece of middleware is added.
JavaSoft is also focusing attention on the vendor that did the most to promote the Java technology, Netscape. Netscape is trying to make a play for the enterprise market and create its own desktop metaphor with the Netscape Communicator product and appropriate servers. JavaSoft and Netscape already have an agreement that provides for JavaBeans to run inside LiveConnect containers on this environment.