InfoBus Defines Interoperability between Java Components
Java creator Sun Microsystems Inc. has championed the JavaBeans specification model as a key element in the distributed, componentized application infrastructure that it hopes to create with its Java programming language and operating system platform. Both Sun and others have been acutely aware of the problem of defining interoperability between Java components -- applets or Enterprise JavaBeans -- for some time, and in April 1997, Lotus Development Corp. introduced InfoBus, a specification that provided for reliable data exchange between Java components.
It was during Sun’s JavaOne conference the same month in 1997 that Sun indicated it would integrate Lotus’ InfoBus specification into its Java Development Kit (JDK). "Our adoption of InfoBus is a big step forward for the entire Java community," said Sun CEO Scott McNealy at the time of the announcement. "The more developers that implement InfoBus, the bigger the benefit."
In the year-and-a-half since its introduction, industry observers say the InfoBus technology has matured sufficiently to serve as a much-needed critical underpinning in Java’s componentized application infrastructure.
The need for a standard, interoperable specification for data exchange between applets and JavaBeans is of paramount importance, say many industry watchers who contend that the promise of portability inherent within the Java Virtual Machine (VM) alone isn’t sufficient to make a compelling-enough case for Java. "The services of a VM alone are sufficient only in the simplest enshrinements," writes Yefim Natis, an analyst at Gartner Group (Stamford, Conn.) in a paper entitled "Microsoft vs. ‘the Gang of Four:’ The Battle for the Enterprise," presented at Gartner’s Windows NT: Strategies for Success conference held early this year. "To deliver enterprise quality of service, a VM must be combined with an enterprise application server," Natis added.
According to Sun, the InfoBus technology both complements and extends the JavaBeans specification by adding additional features that enable the dynamic exchange of data and control the flow of information between applets. InfoBus works by defining a set of Java data access interfaces that can be implemented as extensions to any Java applet. Any component that implements the InfoBus API can register as a member of the InfoBus and then provide or consume InfoBus data within a single Java Virtual Machine.
Since April 1997, Sun has shipped several versions of the InfoBus specification, with version 1.1.1 currently available. Many in the development community feel that the InfoBus specification has reached a level of maturity and robustness in this incarnation.
Eric Anderson, development manager with the PeopleTools division of PeopleSoft Inc. (Pleasanton, Calif., www.peoplesoft.com) and president of application development consultancy Binary Productions, believes that the InfoBus specification will go far toward defining interoperability between distributed Java components.
"By providing a standard interface for providing and consuming information, InfoBus will give the Java community a better chance at building interoperable components with less upfront integration work," Anderson concludes.
There are three component types that constitute the InfoBus: the data provider, the data consumer and the data controller. The data provider is simply an applet or JavaBean that supplies data to another applet or JavaBean, which in turn is the data consumer. Each applet can listen for and receive information from other data provider applets on the InfoBus, so that a Sheet applet might receive, or consume, information from a FileReader applet that is embedded in an HTML document. The data controller, the final component in the InfoBus architecture, functions somewhat like an InfoBus traffic cop by regulating and redirecting the flow of data between data producers and consumers.
According to Sun, the architecture of the InfoBus makes it possible to move data at high speed across applets because the InfoBus only has to reference one object to pass that stream of data to another cooperating applet. In this model, the InfoBus doesn’t introduce additional overhead as a piece of middleware, but simply provides a Java interface to a data item or data items.