A CORBA Bean Framework

David is a senior designer/developer for The Technical Resource Connection, and can be contacted at david.houlding@ trcinc.com.

The OMG's Common Object Request Broker Architecture (CORBA) has become the de facto standard middleware for developing mission-critical distributed object systems. CORBA provides many architectural and implementation features, including location and implementation transparency with respect to language, operating systems, or hardware. With CORBA, you can focus on the added value of your particular system, rather than low-level networking and communications issues. Furthermore, with the growth of the Internet and World Wide Web, CORBA is gaining mainstream appeal. For example, CORBA is currently incorporated in the Netscape Navigator browser, and will be incorporated in the Java Development Kit Version 1.2 (JDK 1.2).

On the other hand, CORBA's powerful functionality presents complexity that must be mastered before its benefits are fully realized. Until users and organizations develop a competency with this technology, hurdles such as slow adoption, and an increase in time required and costs for both training and development will be the norm. Furthermore, the obstacles associated with CORBA adoption are compounded by its numerous implementations. This usually means that an organization's first experience with CORBA is dominated by time-consuming and costly research, evaluation, and comparisons just to select the right implementation.

To address these problems, I present in this article a framework based on the JavaBeans standard (http://java.sun.com/beans/) that provides a layer of abstraction over CORBA -- and in particular the CORBA Dynamic Invocation Interface (DII) -- to encapsulate its complexity and facilitate visual rapid application development (RAD). This makes the CORBA API more intuitive for new users and developers. With this framework, CORBA requests can be visually composed and tested for any operation, including those with signatures consisting of complex nested user-defined types that can exist on any CORBA server.

This approach lets organizations unfamiliar with CORBA accelerate adoption, while lessening the negative scheduling and cost impacts typically associated with new technologies. This framework lets developers new to CORBA or Java participate in CORBA system development, testing, and maintenance, and it decouples the organization from a particular CORBA implementation, allowing the benefits of the technology to be leveraged without first having to go through costly and tedious evaluations and comparisons. The framework and associated GUIs that illustrate this concept are available electronically from The Technical Resource Connection (http://www.trcinc.com/ corbabeans/) and DDJ (see "Resource Center," page 3). The framework encapsulates the VisiBroker for Java 3.2 CORBA implementation from Inprise (http://www.inprise.com/), but can be altered to encapsulate any CORBA 2.0-compliant implementation without changing its external interface.

A Framework of CORBA Beans

The framework I'll present here provides a layer of abstraction over CORBA and DII, thereby encapsulating its complexity and providing its benefits via a more intuitive interface. Furthermore, it serves to decouple users from a particular CORBA implementation, allowing implementations to change without any effects on components using the framework. Finally, it facilitates visual RAD since it is implemented as JavaBeans and is in compliance with the JavaBean standard. The core of the framework concept is the DynamicRequest bean. Figure 1 shows the class hierarchy associated with the DynamicRequest bean. The ServerLocator class is an abstract class, and is subclassed by classes that implement specific means of locating CORBA servers. Similarly, the Parameter class is an abstract class subclassed by various classes that implement the state and behavior associated with various types of parameters, including both base Interface Definition Language (IDL) types such as double and string, as well as container IDL types such as sequence, array, and struct. Last, the Flag class is an abstract class subclassed by various classes implementing the state and behavior associated with various argument parameter modes. These flags serve to indicate the direction of information flow between the CORBA client and server.

Figure 2 shows the class hierarchy that implements the CORBA server locator. These classes are first initialized by the DynamicRequest class through the ServerLocator. Instances of the CORBA ORB and server object reference are then retrieved by the DynamicRequest class via get methods on the ServerLocator class. The VisibrokerServerLocator and VisibrokerGateKeeperServerLocator are responsible for locating servers using the VisiBroker "ORB Smart Agent" and VisiBroker GateKeeper, respectively, while the UrlIorServerLocator and FileIorServerLocator classes are responsible for locating servers using an Interoperable Object Reference (IOR). This IOR is comprised of a "stringified" reference that is portable between CORBA-compliant implementations and specifies the type and location of the CORBA server from which it was generated. The IOR may be stored in a file that is retrieved as illustrated, using either a URL or an absolute file path. Similar classes could be developed to locate servers using any other method, for example CORBA Naming or Trader services, IORs from databases, or other daemon processes in other CORBA implementations analogous to the VisiBroker locators in the implementation presented here.

Figure 3 depicts the Parameter class hierarchy, where the Parameter class is subclassed directly by the LongParameter and StringParameter classes that implement the IDL "long" and "string" types. Similar classes exist for all other base types but are not illustrated here. The ContainerParameter class also subclasses the Parameter class directly and implements the state and behavior common to container type parameters. The ContainerParameter class in turn is subclassed by various container type parameters including ArrayParameter, SequenceParameter, and StructParameter that implement the user-defined array, sequence, and struct IDL types, respectively. These container types support the nesting of complex user-defined types to an arbitrary level. The Parameter class implements the Abstract Factory design pattern, allowing users to instantiate parameters of various types through static create methods on the Parameter class, and then use these parameters through the common abstract Parameter class interface.

Finally, Figure 4 illustrates the Flag class hierarchy. The InFlag, OutFlag, and InOutFlag classes implement the state and behavior of the in, out, and inout IDL argument parameter modes. These flags serve to indicate the direction of information flow between CORBA clients and servers. For example, the in direction indicates information flow from the client to the server. Similar to the Parameter class, the Flag class implements the Abstract Factory design pattern, letting users instantiate flags of various types through static methods on the Flag class, and manipulate these flags through the common abstract Flag class interface.

IDL Talk

IDL is the implementation-neutral specification of the services a CORBA server provides. For example, Listing One (at the end of this article) shows what the IDL might look like for a simple CORBA Inventory Server.

As illustrated, the IDL can define user typed data, as well as the attributes and signatures of the operations for the services the server provides.

To dynamically compose a request on a CORBA server, the IDL is first required. The CORBA Interface Repository (IR) is a server that is responsible for sharing with clients the IDL of other servers. This lets a CORBA client that wants to dynamically compose a request on a CORBA server automatically acquire the IDL for the server from the IR, and then use it to configure and then invoke a request on that server. This powerful dynamic mechanism allows CORBA objects to discover and talk to each other at run time, without having to first share any code stubs. To visually compose a request on the InventoryServer, start the GUI customizer for the DynamicRequest bean either from the command line or a JavaBean Editor IDE (the BeanBox from http://java.sun.com/beans/, for example). The customizer may then be used to edit the ServerLocator component of the DynamicRequest bean to specify the location of the InventoryServer, as illustrated in Figure 5.

The server is then "inspected" from the customizer to determine the methods it provides. This procedure uses the CORBA IR to retrieve a list of operations available for the specified server, and presents this list to users as in Figure 6, letting users select the method to invoke.

Once a method is selected, the bean imports the IDL signature for the selected method from the IR and automatically configures the bean accordingly. Figure 7 shows the DynamicRequest bean customizer GUI after the bean is automatically configured with the signature of the getItems() method of the InventoryServer.

This GUI is then used to set the values of the attributes of the various elements of the request by first selecting the attribute in the customizer and then clicking the Edit button. The editor GUI that appears depends on the attribute type; for example, a Boolean parameter editor such as that in Figure 8.

Finally, the request may be tested by clicking the Test button of the DynamicRequest customizer GUI, then inspecting the results using the same procedure as for editing the parameters. Figure 9 shows the main GUI after such a test is invoked.

In some systems, the CORBA IR is either not running, or is not loaded with the IDL of the particular server on which the user wants to compose a request. In this case, users can acquire the IDL manually using other means, and configure the dynamic request using the Add and Edit features of the same customizer GUI. This lets requests be configured for any server and operation as long as one knows how to locate the server, and what interface it provides.

Once satisfied that the request is configured correctly, the DynamicRequest bean may be archived, either using the customizer in Figure 9 or directly from the JavaBean Editor IDE. The bean may then be integrated into applets, applications, or proxies either visually using a JavaBean Editor IDE, or at the software level. In Listing Two, for example, all records for items with a year of 1997 are retrieved from the CORBA Inventory Server and printed to the standard system output stream.

The framework accommodates visual configuration of the DynamicRequest bean. Additionally, however, the DynamicRequest bean may also be configured completely at the software level using the same framework. This lets you also harness the benefits of CORBA and DII at the software level without dealing with the associated complexity.

To this point, I've shown how a bean is visually configured, interactively tested, archived, and later instantiated for use in Java clients, for example applets, applications, or proxies/gateways. This paradigm (which has been adopted by the JavaBean standard) is particularly powerful for system components that are likely to change either during development or over the lifetime of the system -- for example, components that couple remote systems such as the DynamicRequest bean. To illustrate the advantages of this approach, if you developed a CORBA client that used services provided by a CORBA server, and the interface of that server changed at some point over the lifetime of the client, the client source code would normally need to be updated and recompiled to reflect the changes in the server interface. However, with the JavaBean approach, the bean can be visually reconfigured rapidly, then archived to replace the old bean archive. Software changes and recompilations would not be required for the client to use the new server interface.

Conclusion

With the ever-increasing complexity and availability of new technologies, and the ever-quickening pace of software development, it is imperative that the hurdles to rapidly adopting and realizing the benefits of these technologies are lowered. One approach to effectively achieve these goals involves providing a layer of abstraction over the APIs of these new technologies, thereby encapsulating their complexity and bringing the API closer to the business domain. Furthermore, developing this layer of abstraction with JavaBeans facilitates visual rapid application development, increasing productivity, and allowing new developers and even nonprogrammers to participate in system development, testing, and maintenance.

DDJ

Listing One

module StoreServer {    struct ItemDescription {
        long year;
        string manufacturer;
        string model;
        string description;
    };


</p>
    struct ItemRecord {
        ItemDescription description;
        double cost;
    };


</p>
    typedef sequence<ItemRecord> ItemSequence;


</p>
    interface InventoryServer {
        ItemSequence getItems( in long year, 
                               in boolean includeBefore, 
                               in boolean includeAfter );
        long inventory( in ItemDescription itemDescription );
    };
};

Back to Article

Listing Two

// Load the DynamicRequest bean.DynamicRequest request = (DynamicRequest) 
    Beans.instantiate( null, "corbabeans.myRequest" );


</p>
// Set the input values of the request.
request.setArgumentParameterValue("year",new Integer(1997));
request.setArgumentParameterValue("includeBefore",new Boolean(false));
request.setArgumentParameterValue("includeAfter",new Boolean(false));


</p>
// Invoke the request and check the completion status.
request.invoke();
if( request.getStatus() != DynamicRequest.STATUS_OK ) {
    handleError( request );
}


</p>
// Process the results of the request.
int numItems=((SequenceParameter)request.getReturnParameter("return" ))
    .getLength();
for( int i = 0; i < numItems; ++i ) {
    System.out.println( request.getReturnParameterValue(
        "return[" + i + "].description.manufacturer" ) );
}

Back to Article