of the Beans, by the Beans and for the Beans:
The Enterprise Component Broker

Gregory Blank and Gene Vayngrib
Information Builders, Inc.
1250 Broadway, New York, NY 10001
email:(pgmgfb, pgmglv)@ibi.com

 November 20, 1997


        Enterprise Component Broker (ECB), a new product announced by IBI in October, 1997 is a Java Beans application development environment implemented as a collection of Beans connected via events and interfaces. On the other hand it is also a CORBA 2.0 compliant Object Request Broker with all non-application logic pushed to the metalevel and made transparent to the end application. The Beans  are connected either manually via the Visual Configurator - a browser based server administration program - or programmatically. ECB allows developers/administrators to add extra capabilities, both attributes and executable policies to any Bean registered with the Naming Service. This is done in a very scalable manner, by implementing dynamic inheritance via delegation.

All Beans on the server are client-callable and are dynamically downloaded to the client upon request, but depending on their attributes,  could either be downloaded as a class, stub or by-value.
The server is designed to be protocol-independent: there are pluggable (via usual JavaBeans methods) HTTP, IIOP, APPC and MQSeries "dispatcher Beans". One can easily achieve IIOP/HTTP tunneling  by connecting the correspondent dispatchers one after another.

Much effort went into the development of high-performance thread and connection management schemes to achieve the scalability - up to the OLTP and down to appliances and Network Computers.


        Information Builders Inc. is a privately owned company incorporated in 1975. The IBI's Enterprise Data Access line of software provides access to over 65 database types such as DB2, Oracle, Informix, Sybase, Microsoft, VSAM and IMS on 35 platforms including UNIX, NT, and MVS over most standard communications protocols including TCP/IP, LU2, LU6.2, etc.
The Enterprise Component Broker was intended to be a foundation for the next generation of the EDA software line.

We set out to "humanize" CORBA, make it user-friendly and simplify the development.
During the first "design sessions" about a year ago we defined a set of guidelines that we have faithfully followed ever since


        The server supports a variety of network and application protocols and allows easy addition of the new ones. For each supported protocol the server has a sequence of interconnected beans, each configurable separately : Connection Manager, Dispatcher and Invoker. The HTTP component can operate as a Web server or a servlet within the existing Web server. If the client ClassLoader requests a class that is marked as remotely callable then the client and server stubs are generated on the fly according to the attributes and policies defined.  In the case of IIOP the Connection Manager would accept the connection, execute some particular connection and thread management policies, and fire a connection event to IIOP Dispatcher. The dispatcher parses the request, queries the Naming Services to get the Invoker(in this case a server stub) for this request and fires event to the Invoker.

Naming Service

        The Naming Service is implemented as an architecture of Java Beans in compliance with the JavaSoft's Glasgow containment specification. On the other hand it follows the CORBA Naming model, which allowed us to view the other vendor's Naming Services as an extension of ours, presented as a subtree of the Naming Tree in the Visual Configurator.

Acquisition of Beans

        Rather than building a new Trading Service we decided to use the power of the Internet Search Engines to discover Beans scattered around the enterprise that meet a certain criteria. JAR (java archive) files or individual beans have an HTML page that describes the bean in free text format and/or exposes a string of keywords. The developer/administrator typically searches the Internet or Intranet, finds the beans and bookmarks their HTMLs. Visual Configurator displays the Bookmarks as its subtree. Alternatively, the developer uses the search engine API to do the search at runtime.
The enterprise would also likely to have a Yahoo style subject hierarchy of the beans, so that the beans are discovered by traversing the subject tree.

Visual Configurator

        The Visual Configurator is a browser based tool that displays the ECB hierarchies and allows a variety of operations on the nodes and leafs. It displays the Server Naming tree, Bookmark tree, Project tree (uninstantiated Beans and JARS) , the Naming trees of other servers (both ECB based and other ORBs) etc. and allows copying, pasting, renaming and deleting of the nodes and the attached Beans; connecting Beans via events and interfaces etc. It also allows to inspect the databases via attached JDBC driver Beans. It allows you to test run (and in the future, debug) the freshly configured server.
In other words it is an integrated server management tool, remote console and application development environment.

We would like to demonstrate it in action at the Workshop.

Enterprise Beans

        The Beans deployed in the ECB environment are transparently connected via events and interfaces across different  network nodes.

As compared to JavaSoft's RMI the complete java object model is supported: constructors, static methods, static variables etc. The specifics of bean-to-bean interactions (copying by value or reference, shallow or deep, in/out parameters, call batching etc.) are defined via the Attribute Management Component. Each class, method and parameter can be assigned attributes and policies that control its behavior. Policies can be coded by the application developer to collect the call and access statistics and optimize the behavior of any Bean or a group of Beans.
The transaction and persistence policies interact with the CORBA Transaction Service to provide a dynamic modifiable transaction environment.


        The ECB Persistent State Component maintains the state of the beans registered in the Naming Service and all the inter-bean connections. Implemented independently of the underlying Persistent Store it maps the Naming tree to the directory structure and enables the fast restart of the ECB server.


        The Distributed Trace Management Component allows to trace the execution of the client requests that may span several servers. The client can manipulate a wide range of trace options to define the particular path it wants to trace: specific server components, packages or classes, thus minimizing the output to achieve greater scalability in the enterprise environment. The trace output from all the servers the request traveled through can then be viewed live in a separate browser window or Java frame.


        The JDBC drivers for CICS, IMS transactions and EDA (providing access to some 65 databases on a network of servers) are the extra applications that IBI supplies for the ECB. Though not different from any other application a user can deploy, these drivers are natively integrated into the ECB environment and use most of the services it provides. The use of JDBC drivers require no extra client or server code: only JDBC stubs are downloaded. The drivers supplied by IBI can run both over TCPIP and LU6.2 protocols. A range of other vendors' JDBC drivers have been tested with the ECB.

Interoperability and Language bindings

        The ECB based applications can communicate to CORBA objects on the other vendors' ORBS via the JavaSoft's JavaIDL component supplied with JDK 1.2. In this case the stubs are generated offline by the IDL-to-Java compiler, which is a part of JavaIDL. So far this approach has been shown to work with Visibroker for Java 3.0 .

To enable objects from other ORBs call Java Beans in ECB we are planning to provide the Java-to-IDL and Java-to-C++ compilers.