As the names suggest, the Data Producers produce data and the Data Consumers consume data. The exchange of data takes place using a data interchange protocol called the InfoBus. In an InfoBus application, a component may act as a Data Producer, Data Consumer or both. Data between InfoBus components flows in the form of named objects called DataItems. Data Controllers are specialized components that control the rendezvous between producers and consumers.

The InfoBus protocol defines the following steps for data exchange:
1. The components connect to the InfoBus. This is called "joining" the Infobus. After a component has joined the InfoBus, it listens for bus notifications which are generated in the form of known events.
2. Data Producer components announce the availability of new data.
3. Data Consumer components register to listen for named DataItems. Upon retrieving a DataItem that has been published, the Data Consumers can retrieve the encoding of the data values in the form of a String or a Java object.
4. Consumers can attempt to change the value of DataItems. Producers enforce a policy on whether anyone can change data. The data change notifications take place using named events.
5. The components can disconnect from the InfoBus. This is called "leaving" the InfoBus.InfoBus Events
The InfoBus specification 0.04a, which has been used for the example application in this article, defines one event called DataItemChangedEvent. The InfoBus components, i.e., Data Producers and Consumers, access the data by calling methods on the InfoBus. These methods are listed in Table 1.

The InfoBus API
This section provides a brief introduction to the main interfaces of the InfoBus API. For specific API details, please refer to the JavaBeans Web site at http://java.sun.com/beans/infobus/Package-javax.infobus.html

The InfoBus API has two major interface groups. The first is concerned with the rendezvous or brokering mechanism for announcing and locating data items within an InfoBus. The major rendezvous classes are shown in Table 2.

The other group of interfaces includes data items that are exchanged on the bus and their associated classes. These have changed significantly from the earlier releases. The latest versions are listed in Table 3.

An InfoBus Example
In this section we will lead the reader through an example application that illustrates the use of the main entities defined in the Infobus and the interaction between them. The example uses two applets: One is a producer of temperature data items and the other is a consumer of these same data items. Both are displayed on a single Web page and they communicate across a single InfoBus. Figure 2 illustrates the building blocks for the temperature gauge. The source is provided in Listings 1 and 2.

The producer applet simulates a temperature data source. Initially, it announces to the InfoBus the availability of a "temperature" data item. The data item then sends out temperature change notifications to any listeners.The other applet is the data consumer. It is used as a simple control center to display the current temperature along with a color-coded background that indicates the state of the equipment. Green indicates normal temperature, yellow is a warning and red indicates overheating.

The producer applet is implemented by the TemperatureSource class in Listing 1. It implements an InfoBusDataProducer interface which allows it to announce data items on an InfoBus. The applet requires access to both an InfoBusMember and the data item to be produced, so it also needs to implement the InfoBusMember interface and a data item interface. Finally, it also implements Runnable in order to update the temperature value in a background thread.The other applet is the data consumer. It is used as a simple control center to display the current temperature along with a color-coded background that indicates the state of the equipment. Green indicates normal temperature, yellow is a warning and red indicates overheating.

The producer applet is implemented by the TemperatureSource class in Listing 1. It implements an InfoBusDataProducer interface which allows it to announce data items on an InfoBus. The applet requires access to both an InfoBusMember and the data item to be produced, so it also needs to implement the InfoBusMember interface and a data item interface. Finally, it also implements Runnable in order to update the temperature value in a background thread.When the applet's init() method is called, the TemperatureSource joins a new InfoBus, adds itself as a listener for any InfoBus property changes and then adds a Label to display the temperature. In the producer applet, the memberSupport_ data member handles this as follows:

memberSupport_.joinInfoBus(this);
memberSupport_.addInfoBusListener(this);

The InfoBusMember interface is used primarily by TemperatureSource to get a handle to the current InfoBus. The implementation is delegated to the InfoBusMemberImpl class delivered as part of the InfoBus package. As you go through the listing you will notice that there are several other methods that InfoBusMembers delegate to the memberSupport_ variable.

Next, in the applet's start() method, the TemperatureSource adds itself as a producer on the bus that it just joined. This allows it to send notifications to listeners when a data item becomes available.

ib.addDataProducer(this);

At this point, we have a data producer that is ready to announce data items. The run() method of the thread that is spawned in the applet's start() method is used to announce the temperature data item:

getInfoBus().fireItemAvailable("Temperature", this);

"Temperature" is the name of the data item while this (i.e., the TemperatureSource) is passed as the producer of the item. After this, the program enters a loop in which the temperature data item is modified every 2 seconds to simulate changes in the data source. This change occurs in the producer's setInternalValue() method. Modifying the data item causes an itemValueChanged() method to be called on all DataItemChangedListeners (i.e., the consumers).

As mentioned before, the producer implements the ImmediateAccess interface which is a DataItem. Therefore, both interfaces must be implemented. DataItems have methods to get the source of the item as well as methods for adding and removing data item listeners. The interface also includes a getTransferable() method which is used to return a Java Transferable object if other flavors of the data item are available. For our example, we will just return null.

ImmediateAccess data items are standalone (i.e., non-collection) data items. They offer access to the underlying data through getValueAsObject() and getValueAsString() methods which, in our example, will return the value of our underlying temperature value as a Double and String respectively. ImmediateAccess items also have a setValue() interface, but in this example we disallow consumers attempted temperature modifications by throwing an InfoBusAccessException inside setValue. We now have the basic outline of a data producer.

Our data consumer, the TemperatureViewer, will receive notifications of "Temperature" data items and then display the value. Like the producer, the consumer delegates to its InfoBusMemberImpl instance member all InfoBus Member method implementations.. The applet listens for data item changes by implementing the DataItemChangedListener interface. So our consumer/component applet, TemperatureView, is defined to be:

public class TemperatureViewer extends Applet
implements InfoBusMember, InfoBusDataConsumer,
DataItemChangedListener {

Like the producer, the consumer joins the default InfoBus in the applet's init() method and then adds an AWT Label to the applet for visually displaying the temperature data. In the start() method, we add the applet as a data consumer and then request a "Temperature" item. If one is found, we then update the temperature display.

Updates from the temperature data item are sent to the TemperatureViewer, a DataItemChangedListener. This interface consists of itemValueChanged, itemSizeChanged() and itemDeleted() methods. In our example, itemValueChanged() is the only item changed method of interest and is implemented as:

public void itemValueChanged (DataItemChangedEvent e) {
setDisplayValue(e.getDataItem());
}

The TemperatureViewer method setDisplayValue() is used to update our view of the data item. SetDisplayValue() extracts the data from the ImmediateAccess data item and then updates the display. It uses the ImmediateAccess getPresentationString() method as the text for the label.

Program Environment
Figures 3 and 4 show screen captures of the example. To run the example, you will need JDK 1.1 or a later version, an InfoBus implementation and a 1.1-based browser. The example has been tested with the TP2 implementation (i.e., the 0.04a spec) of the InfoBus using JDK 1.1.5 on NT 4.0. It should work with any 1.1 compliant browser and has been successfully tested with the Netscape 4.04 (with the JDK 1.1 patch), HotJava 1.0 and the JDK 1.1 appletviewer.

Beginning with JDK 1.2, the InfoBus will become a standard Java extension. Until then, you will need to download an InfoBus implementation from JavaSoft to run the example locally. An implementation and the specifications are located at http://java.sun.com/beans/infobus

Note that due to space restrictions, comments, exception handling and error handling have been removed. A more detailed explanation of the example and commented example source can be located either at the JDJ Web site or the authors' Web site: http://cambrian.netin.com/jdj-examples/

Current Status
The InfoBus specification is still evolving. At the time of this writing, the latest InfoBus implementation is TP2 which is based upon the 0.04a specification. The latest spec is 0.06 and the TP3 implementation of this spec should be out by the time you read this article. The 0.06 specification is expected to be quite close to the final 1.0 release.

The example here is based upon the 0.04a spec. The newer specs have made some very useful changes to data items which should make for a much more robust environment, so we recommend moving to the newer as soon as possible. The primary differences you'll need to adapt to are:
1. Change method signatures; primarily involves converting DataItem to Object in most interfaces
2. Use JDK 1.2 collections instead of CollectionAccess and keyed Access interfaces.
3. Implement DataItemChangeManager on DataItems where you want to allow listeners, and remove the add/removeListener() methods for the others
4. Check InfoBus and data item naming conventions to make sure they don't conflict with the newer versions' recommendations.
5. Consider whether other new features are useful, such as data controllers, security and new data items

Related Issues
Lotus Development Corporation is using the InfoBus as the basic building block for a suite of desktop applications called eSuite. Sun Microsystems, Inc. is finalizing the specs for the JavaBeans Activation Framework (JAF), which adds data awareness to JavaBeans based components. It will be interesting to see how these technologies evolve and how they supplement each other. More information on these may be found at the following sites:

http://esuite.lotus.com/eSuite/seSuite-site.nsf
http://java.sum.com/beans/glasgow

Conclusion
In this article we've examined a new Java component model called the InfoBus which is based on JavaBeans. We looked at an example application using its main components. The InfoBus can be used to build UI application suites and data-aware architectures and is expected to become a standard framework for the future of the Java enterprise applications.