Tik-76.270, Research Seminar: Java-based Software Technologies

Java and component technology

Osmo Vikman 16601S

Contents

"Componentware"
JavaBeans component model
What do you need to create a JavaBean?
Java applets vs JavaBeans
JavaBeans and Java APIs
JavaBeans development environments
JavaBeans future
Other software component technologies
Conclusions
Demonstration of a JavaBean

References

"Componentware"

Here are a few software component (model) definitions:

Gartner Group (August 9, 1995, Software Management Strategies):

"Componentware, also known as component software, is a term used to describe applications built from components and the enabling system software infrastructure. Componentware and Distributed Objects are similar and are examples of object-based computing. Both are more evolutionary than revolutionary and are extensions of structures such as RPCs and DLLs. The focus of componentware is largely initially desktop- and document-oriented, gradually bubbling up into workgroup and enterprises.

Semantics refers to the protocols or rules governing the conversation between any two pieces of software. Any software will enable only semantically consistent communication. Two cooperating pieces of software need to agree on the semantics of the "conversation" for it to be meaningful.

Containers and servers: A container is the controlling client application in the requester/server relationship between the container and the server application. A server is an implementor (i.e. creator, owner and manager) of an object. It is visually embedded in the container application."

DARPA component software glossary [3]:

"A component is a software (sub)system that can be factored out and has a potentially standardizable or reusable exposed interface. Components in a SW architecture can be identified at different levels of abstraction, and the components identified at these different levels may not be in one-to-one correspondence. For example, viewing an architecture at one level of abstraction, object services may be identified as components. Viewing the same architecture at a more detailed level, a given service may be implemented by several distinct software modules, which may be individually identified as components."

Javaworld 03-1997/Merlin Hughes [4]:

"A software component model is a specification for how to develop reusable software components and how these component objects can communicate with each other.

In order for a software component model to work, each software component must provide several features:

The component must be able to describe itself. This means that the component must be able to identify any properties that can be modified during its configuration and also the events that it generates. This information is used by the development environment to seamlessly integrate third party components.
The component must allow graphical editing of its properties. A RAD environment is intensely graphical; the configuration of a software component is done almost exclusively through control panels that expose accessible properties.
The component must be directly customizable from a programming language.
The component must generate events or provide some other mechanism that lets programmers semantically link components."

It seems that there are as many definitions of a software component (model) as there are parties involved in specifying, designing, implementing and deploying software components and the containers where the components are combined into applications.

Many of the "componentware" concepts stem from the compound document environments (Microsoft OLE, CILabs OpenDoc, etc.) and from the GUI development environments (e.g. Microsoft VBX/OCX/ActiveX controls, Motif widgets etc). Distributed objects (i.e. distributed SW components) have expanded the SW components to include almost any piece of (even "legacy", i.e. non-object-oriented) software which can be "wrapped" into an object wrapper and connected to other components by "middleware" (like CORBA/ORBs or Microsoft DCOM).

In [3] there is an attempt to create a glossary for reusable software components, mainly for US military software applications.

JavaBeans component model

Conceptually, JavaBeans are functionally discrete objects, software components with which you can construct complex, Java-based applications. In order for the components to work together, they all must support a standard set of behaviors, regardless of the functions they provide. This set of behaviors is referred to as "component services" [2].

Component Services

All software-component models provide varying degrees of support for component services. These services allow a component to perform event handling, customization, introspection, and persistence.

Event handling. Event handling is the ability to send and receive event notifications. In the JavaBeans architecture, event handling is based on the classes and methods defined in the:

java.util package. Event handling comprises the event itself, its source, and its target. An event must be derived from the java.util.EventObject class and can be initiated either programmatically or by user action. A source Bean detects an event and notifies one or more target Beans, which receive event notifications as relevant events occur. Target beans must be derived from the java.util.EventListener class and must implement the EventListener interface.

Customization. Beans must be as reusable, or customizable, as possible; to that end, JavaBeans provides two specific customization classes:

java.beans.PropertyEditor and java.beans.Customizer. Application developers can customize Beans using either or both.

A property editor is a graphical control that provides edit access to property values of a given type. Each property type represented in a bean should be associated with a corresponding property editor. Property editors for built-in Java types:

(integer, long, and so on) are provided as part of the Bean Development Kit; it's up to developers to provide property editors for each new data type they create. For complex beans, a conglomeration of property editors (collectively known as a "property sheet") may not be sufficient. In these situations, developers can implement the Customizer interface and define customization access for the bean as a whole.

Introspection. Determines what properties, methods, and events the bean supports. Introspection is implemented by method calls on the:

java.beans.Introspector class. When a method is called, the Introspector first searches for an implementation of the BeanInfo interface associated with the bean. If one is found, it constructs an accurate picture of a bean from the BeanInfo details; if not, it uses the built-in classes and methods associated with java.lang.reflect to make intelligent guesses about a bean's properties, methods, and events based on standard member-naming conventions. Introspection can be divided into interface publishing and interface discovery. Interface publishing provides a way to describe explicit details about a bean's members, such as whether or not a property is bound or constrained or whether an event is unicast or multicast, and is implemented via the java.beans.BeanInfo interface. Interface discovery allows application-building tools to query the details defined via BeanInfo.

Persistence. Although JavaBeans persistence isn't fully mature, it is fairly flexible. Flat-file persistence can be achieved through serialization, which by default flattens objects so they can be streamed to a file and subsequently reconstituted, or externalization, which provides complete control over writing, storage, and retrieval of bean data.

To activate the built-in, bare-bones serialization mechanism, a bean class simply implements the:

java.io.Serializable interface. It can, however, include calls to input and output methods such as ObjectInputStream.readObject() and ObjectOutputStream.writeObject(). Custom input/output methods can be provided by implementing the readObject() and writeObject() methods. The java.io.Externalizable interface has no default input/output methods; beans that implement it must implement the abstract Externalizable methods writeExternal() and readExternal().

Persistence for industrial-strength relational databases can be achieved via the Java database-connectivity API (JDBC). Implemented in the java.sql package, JDBC defines interfaces for drivers, connectors that map Java API calls into data base-specific calls. Such drivers have been announced by close to 50 database vendors, including Borland, IBM, Oracle, and Sybase, and some are available already [2].

What do you need to create a JavaBean?

Creating a Minimal Bean

In this section you will continue learning some BeanBox fundamentals by

Creating a minimal Bean

Compiling and saving the Bean into a Java Archive (JAR) file (by using a makefile)

Loading the Bean into the ToolBox

Dropping a Bean instance into the BeanBox

Inspecting the Bean's properties, methods, and events

Generating an introspection report

See the details in [14]

Writing Advanced Beans

This section contains lessons that illustrate more complex bean capabilities.

Implementing bound properties describes how to cause a property change in one Bean to affect other Beans.

Implementing constrained properties tells you how to let other outside Beans exert veto power on your Bean's property changes.

Implementing Indexed properties introduces properties that are best represented as arrays.

Customizing Beans introduces you to property editors and the Customizer interface.

Using BeanInfo describes the details of Bean information classes: Separate classes used to provide Bean information to builder tools.

See details in [15]

Complete Java(Beans) tutorial in [16]

A collection of ready made beans can be found in [17]

Java applets vs Javabeans

JavaBeans components are reusable software components that can be manipulated visually in a builder tool. JavaBeans components can be combined to create traditional applications, or their smaller web-oriented btrehren, applets. In addition applets can be designed to work as reusable JavaBeans components.

Java applets can be considered components but applets are designed to be displayed on web pages. They must subclass the java.applet.Applet class and they typically get configured by parameters to the HTML "applet" and "object" tags and they have a "lifecycle" (init-method for creation/start-method for making visible/stop-method for making invisible/ destroy-method for deleting) [10].

JavaBeans components are reusable software components which are designed to be self-describing and to be visually manipulated in application builder tools. Typically JavaBeans components are configured by having their properties set in visual tools. JavaBeans supports the new AWT model in JDK 1.1 which allows dynamic hookups between different Beans.

JavaBeans and Java APIs

The Java Beans APIs are also closely related to other new Java core APIs which are described in separate documents.

"The Java Core Reflection API". This describes reflection APIs being added to Java to support analyzing the fields and methods of objects.
"Java Object Serialization". This describes the Java Object Serialization APIs.
"JDK 1.1 - AWT Enhancements". These web pages describe extensions that are being added to AWT, notably for uniform data transfer.
"Remote Method Invocation". This describes the Java Remote Method Invocation (RMI) mechanisms for distributed programming.
"Java IDL". This describes the Java mapping to the industry standard CORBA IDL system.

Manifest file specification. A JAR file consists of a normal ZIP format file that can optionally contain a decriptive manifest file.

JavaBeans development environments

Many major vendors of programming tools have announced plans to support JavaBeans as soon as JDK 1.1 is released (early 1997). Among them [13]:

Asymetrix Corp.'s SuperCede for Java will include JavaBeans in the release that follows version 1.0.
Borland International's Open Builder 1.0 (formerly code-named Latte) will include an extensive library of JavaBean components.
IBM's Visual Age for Java 1.0 will support the building and scripting of Javabeans components.
Lotus Development Corp. has announced full JavaBeans support in Domino 5.0 servers and Lotus Notes 5.0 clients.
Microsoft Visual J++ will include support for both Javabeans and ActiveX in a future version.
Sybase will support JavaBeans in the next release of Optima++.
Symantec Corp.'s Visual Café 1.0 is now shipping with JavaBeans support based on preliminary version of the Sun JDK, version 1.02.

The problem with commercial JavaBeans development tools is that they lack one or two versions of JDK and the "real" JavaBeans component capability always seems to be "just around the corner". Javasoft is trying to make the next versions of Java/JavaBeans specifications available for public review as early as possible so that the tool developers can get a head start, but this seems to create an adverse effect of "selling the future features" rather than tools based on existing specifications. Javasoft is also trying to convert ActiveX users to JavaBeans users by providing an ActiveX migration tool so that you can start using JavaBean components which have been converted from the existing ActiveX components. On the other hand Javasoft has created a "bridge" for converting JavaBeans into ActiveX components, so they seem to hedge their bets on whether the world prefers JavaBeans or ActiveX component technology in the long run.

JavaBeans future

By all accounts, JavaBeans has a way to go before it's ready for mission-critical application deployment [2].

For example, there's currently no standard way for a bean contained within another bean to query its context; that is, to interrogate its containing bean or its peers (other contained beans). There's also no consensus yet, much less implementation, for container logic within the JavaBeans model. For example, how should a container bean handle standard requests such as "save" and "print"? Should a container bean's menu change when individual containing beans are activated, and if so, how?

The next release of JavaBeans, code named "Glasgow," takes a first step at support for a containment model and is already available for public comment at [5]. Glasgow is expected to include four new services that should help move JavaBeans closer to prime time:

An extensible runtime-containment model, to define a model for nested JavaBeans.
An object aggregation and delegation model, to enhance existing Java support for multiple inheritance.
A data-typing and object-registry mechanism, to define a standard way for developers to decouple bean data from bean behavior.
Enhanced drag-and-drop services, to support data exchange between Java and non-Java applications.

Other Developments

Any containing application that embeds multiple beans needs to have a standard way of managing their visual display. Not only that, but each individual embedded bean needs to be able to participate in a consistent activation model. For now, the JavaBeans layout-management model is still under consideration by JavaSoft.

Recently (Dec 1997), JavaSoft announced the PROJECT JAVA ACTIVATOR [6] which replaces the default Java Virtual Machine (JVM) of the Netscape Navigator 3.0 or later and the Microsoft Internet Explorer 3.02 or later with the Sun's Java Runtime Environment (JRE), thereby enabling the JDK 1.1 capabilities on those browsers (as Microsoft and Netscape have not upgraded their browser JVMs from JDK 1.02 support to JDK 1.1 support). The early access release version 2 (i.e. a beta) of Project Java Activator is now available at [6].

January 23, 1998 San Jose Mercury News [7] told that: "Netscape pulling back from Java commitment". The article told about the scaling back of Netscape's Java efforts (mainly the porting and maintenance effort of Java Virtual Machine in Netscape browsers on 17 different platforms plus development of enhanced Java compilers). People working on Java projects at Mountain View-based Netscape are hardest hit in the current round of layoffs, due to the loss of $89 million in its most recent quarter.

Not all component-based development is for new applications. Many more developers are interested in extending legacy applications to the Internet than in recreating them. The upcoming Enterprise JavaBeans API is aimed at large-scale development efforts and is expected to provide robust, transparent support for transaction processing. The initial specification (version 1.01) has been published in the second half of 1997. The specification is available at [1]).

Professional-level programming tools are just beginning to hit the market for JavaBeans. To date, there are few well-constructed, nontrivial examples to which to refer, but as development picks up, third-party example beans are appearing at places like javabeans.developer.com.

Finally, speeding the JavaBeans evolution are a handful of companies that have thrown their hats in the ring to ensure that new features are implemented as quickly as possible. These include Lotus which has announced the integration of its InfoBus data-exchange technology into the JavaBeans model; the Object Management Group (OMG), which has now formally adopted the JavaBeans model into its standard CORBA (Common Object Request Broker Archictecture) specification; and IBM and Netscape, both of which have recently announced their intent to incorporate JavaBeans into their entire client/server tool suites.

Other software component technologies

There are two component technologies which started out as compound document standards rather than general software component standards:

Microsoft OLE (Object Linking and Embedding) & COM (Component Object Model)
Component Integration Laboratory OpenDoc

IBM has developed the SOM (System Object Model) for building "system objects" to overcome the major obstacles in using the object class libraries. The general problem SOM was supposed to solve can be stated as follows [8]:

"System object" can be distributed and subclassed in binary form.
"System objects" can be used, including full subclassing, across languages
A "system object" which can be supplied either as part of an operating system, a vendor tools product, or an application, provides for the subsequent updating (fixes or enhancements) of these components without having to recompile existing clients that use them (upward binary compatibility).

Distributed object support for SOM is provided by DSOM which is a set of SOM classes shipped with the SOMObjects toolkit). DSOM is compatible with OMG's CORBA specification. In [8] there is a comparison between IBM SOM and Microsoft COM.

As the IBM and Apple sponsored Components Integration Laboratory, which was the "guardian" of OpenDoc standard, SOM and LiveObjects validation and branding kit, was dissolved [9], OpenDoc and SOM returned to their owners (IBM and Apple) who will be providing access to the technologies to anyone interested.

Borland have developed their own component standard VLC for Delphi development environment, based on their old component architecture OWL (Object Window Library). Borland has cooperated with JavaSoft in the specification of JavaBeans

Latest web-component technology from Microsoft, ActiveX is part of the so called "Active Platform". This platform consists of three core technologies [11]:

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 with the operating system itself.
Active server is a set of Applications 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 provides the glue for components to communicate with each other, regardless of their implementation language and platform. This is not to say that a given ActiveX control binary is portable; it means that the specification allows for communication between controls on different platforms that support ActiveX.

Conclusions

Despite all the hype about a huge number of Java developers and the potential of JavaBeans as the best(?) software component model, there are a very few reported cases of commercial strength software packages which have been developed as "100% Pure Java" or which are based on JavaBeans. That should not be very surprising as both the Java language and JavaBeans specifications have been under constant development over the past couple of years. JavaBeans was first announced in May 1996 and the JavaBeans specification version 1.01 has been available at [1] since the beginning of 1997. JavaBeans development support became available from Sun Microsystems with the JDK 1.1 but even that version of JDK has been evolving during 1997 and there are already two new versions of JavaBeans specifications under development: Glasgow and Edinburgh (see [5]).

Most of the early Java "component" development was based on Sun's Java specification version 1.02 and the corresponding Java Development Kit 1.02, which had only rudimentary support for JavaBeans. JDK 1.1x contains the JavaBeans 1.01 specification support but it seems that neither the JDK nor JavaBeans specifications versions will stabilize in the foreseeable future (see Glasgow and Edinburgh specifications in [5]). There was a radical rewrite of the Java AWT event model in version 1.1 and some developers are afraid that JavaSoft will be breaking the backward compatibility again in the future [12].

The rapid succession of new versions of Java APIs, early access releases (of JAF, for example), ActiveX bridge and migration tools and the Beans Development Kit 1.0 plus a number of white papers on several related software component issues (like Enterprise Javabeans) make it very hard to distinguish the Java hype from realistic assessment of the long term stability and real added value of JavaBeans compared to the competing technologies.

Demonstration of a JavaBean

Option 1:

If the Lotus eSuite DevPack is available for a trial period I would like to experiment with the InfoBus by building a JavaBean component which will connect to the InfoBus and monitor the bus traffic of the existing eSuite components and display the data exchanges between a "producer" and "consumer".

Option 2:

If the DevPack is not available I have to use the BDK 1.0 and BeanBox to build a "year 2000" compatible digital clock Bean (year/day/month hours:minutes).

References:

[1] http://java.sun.com/beans/ (Information on JavaBeans specifications & development tools)

[2] Web Techniques Magazine (Web Techniques Magazine October 1997 Volume 2, Issue 10)

[3] http://www.objs.com/survey/ComponentwareGlossary.html (DARPA SW reuse survey)

[4] http://gee.cs.oswego.edu/dl/html/javaCodingStd.html

[5] http://splash.javasoft.com/beans/glasgow.html (Glasgow specification)

[6] http://java.sun.com/features/1997/dec/activator.html (Project Java Activator)

[7] http://www.sjmercury.com/business/center/netscapejava012498.html (Netscape pulling back...)

[8] http://www.software.ibm.com/ad/somobjects/library/somvscom.html (SOM vs COM)

[9] http://www.cilabs.org/ (CILabs dissolution)

[10] http://sunsite.auc.dk/DJUK/BeanNotes/BeansApplets.html (Beans vs Applets)

[11] http://www.javaworld.com/javaworld/jw-02-1997/jw-02-activex-beans.html (Active platform)

[12] http://www.webweek.com/970512/software/java.html (Java developers may sit this one out)

[13] http://www.zdnet.com/pcmag/features/beans/bean5.htm (JavaBeans tool support)

[14] http://www.javasoft.com/docs/books/tutorial/javabeans/beanbox/creatingBean.html (Minimal bean)

[15] http://www.javasoft.com/docs/books/tutorial/javabeans/advancedbean/index.html (Advanced bean)

[16] http://www.javasoft.com/docs/books/tutorial/TOC.html#JAVABEANS (Complete Java(Beans) tutorial)

[17] http://www.javadomain.com/java_bean_product.html (JavaBean products)

[18] http://www.npac.syr.edu/users/gcf/summary0.html (Foilset of Syracuse University: diverse material)

[19] http://www.npac.syr.edu/users/gcf/uccjavabeansaug97/index.html#local10 (Foilset of Syracuse University: JavaBeans)

[20] http://vega.info.isbiel.ch/~hrm/SwingCourse/crashcourse.html (Tutorial on GUI development kit Swing)

[21] http://java.sun.com/products/jdk/awt/swing/ (Specification of GUI development kit Swing)