HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Components transcend the programming language and support a very high degree of reuse. They greatly simplify the construction of large and complicated software architectures. One of the main reasons why Java promises such a bright future for the computing world is because of its inherent support for component architectures. Some examples of Java's component support are JavaBeans™, Java Foundation Classes (JFC), JavaBeans Activation Framework (JAF) and the InfoBus.

This article introduces the InfoBus, a specification for interconnecting JavaBeans by defining the interfaces and the protocol for their interaction. First, the need for a framework like the InfoBus for current Java architectures is identified. Then the InfoBus, its components and the InfoBus API are briefly described. This is followed by an example that illustrates how to build an application using the basic elements of the InfoBus. The article concludes with a discussion on its current status and future issues.

We assume that you are familiar with Java component architecture concepts in general and with the JavaBeans paradigm in particular. Sources for additional information are listed where required.

JavaBeans and the Infobus
JavaBeans, Java's implementation of the component model, is built mostly using features of the language itself. The JavaBeans model allows developers to construct applications by connecting components programmatically and/or visually. The model consists of an architecture and an API. These combine to provide a framework for writing components. Programmatically, JavaBeans simply enforces a set of design patterns on top of Java's existing event model.

The InfoBus architecture and API were developed by Lotus Development Corporation, Inc. and Sun Microsystems, Inc. to define standards by which a wide range of Java components acting as data producers and data consumers can communicate. The InfoBus facilitates the creation of applications built from JavaBeans that exchange data asynchronously within the same Java Virtual Machine. Hence, the Infobus defines JavaBeans component interaction within a single process.

So Why InfoBus?
JavaBeans uses introspection to discover and learn about other Beans at runtime. This is based on certain design patterns in the names of methods used for interacting Beans. Communication between Beans is achieved via the AWT's event-response mechanism.

The InfoBus is meant for a more specific kind of JavaBeans interaction and its design adds the following constraints to generic JavaBeans interaction:

JavaBeans that are loaded by the same Java class loader can "see" other Beans and can make direct calls between them. However, this involves examining the interface of the other Bean using introspection and, thus, has substantial overhead. In contrast, the InfoBus interfaces form a tightly coupled contract between cooperating Beans. Procedure calls are direct and no inferring is required.

JavaBeans use the standard event/response model, where the semantics of the interaction depend upon understanding Bean-specific events and then responding to these events with Bean-specific callbacks to the event raiser. The InfoBus interfaces, on the other hand, have very few events and have an invariant set of method calls for all components. The semantics of the data flow are based on the contents of data that flow across the InfoBus interfaces, not in the names or parameters from events, nor in the names of parameters or blocks.

Figure 1
Figure 1:  How these components play together in the InfoBus

The InfoBus promotes the notion of data aware components and supports semantics that allow data to be communicated in a canonical format that involves both the encoding of data and the navigation of the data structure.

InfoBus in a Nutshell
The InfoBus applications can contain three types of JavaBeans:

  • Data Producers
  • Data Consumers
  • Data Controllers
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.

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.

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.

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.

Figure 2
Figure 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.

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:


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.


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) {

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.

Figure 3
Figure 3:

Figure 4
Figure 4:

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:



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.

About the Authors
Ajit Sagar is a member of the technical staff at i2 Technologies, in Dallas, Texas. Ajit has 7 years of programming experience in C, 3 years in C++ and 1-1/2 years in Java. His focus is on networking, system and application software development. To reach Ajit, call 214 860-6906 or e-mail him at [email protected]

John Sigler is a member of the technical staff at i2 Technologies, Dallas, TX. He has a B.S. in Computer Science from Texas A&M University. John has 10 years of software development experience and 1-1/2 years in Java.His focus is on UI, system and application development. John can be reached at [email protected]

Download Source Code Assoicated Files (Zip file format - 2.99 KB)


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.