Gregory Blank and Gene Vayngrib
Information Builders, Inc.
1250 Broadway, New York, NY 10001
November 20, 1997
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.
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.
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
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.
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
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.
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.