Abstract

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.

Introduction

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
 

• everything is written in 100% pure java
• the smallest unit of design is a component, or more specifically a Java Bean
• only standard protocols (HTTP, IIOP) and APIs (java APIs, CORBA services) are used
• the product is an Internet native: the client code can run in the browser( as an applet), the server can run under existing Web server (as a servlet). Scalability is a primary concern throughout.
• the client is scalable down to appliances and smart cards
• "develop locally, run remotely". Full,  or best-effort distribution transparency with usual trade-offs like performance and flexibility compensated at system configuration time
• the product is easy to use, with intuitive user interface design. The user is able to "learn and forget" quickly and not feel locked forever into this technology after spending months reading thick manuals
• the look-and-feel resembles the widely known products people are used to like Windows Explorer or Netscape Navigator
• separation of concerns: the aspects of distribution,  transactions, security, persistence, tracing etc. would ideally be developed, debugged and tested separately from application logic and from each other
• open implementation - components of the product have metalevel interfaces

        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.

Persistence

        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.

Tracing

        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.

JDBC

        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.