Chapter 11 Creating CORBA Java Components

Advanced techniques

After the basic component implementation is in place, you can add code to perform the following advanced tasks:

Issue intercomponent calls

You must use a proxy to issue intercomponent calls. If you call methods in another Java component directly, no server features such are available to the called component, such as transaction control, instance lifecycle management, and security.

Using the CORBA ORB to instantiate proxies

To invoke other components, instantiate a proxy (stub) object for the second component, then use the stub to invoke methods on the component.

To invoke methods in other components, create an ORB instance to obtain proxy objects for other components, then invoke methods on the object references. You obtain object references for other components on the same server by invoking string_to_object with the IOR string specified as Package/Component. For example, the fragment below obtains a proxy object for a component SessionInfo that is installed in the CtsSecurity package.

    java.util.Properties props = new java.util.Properties();
    props.put("org.omg.CORBA.ORBClass",
                    "com.sybase.CORBA.ORB");
    ORB orb = ORB.init((java.lang.String[])null, props);
    SessionInfo sessInfo = 
        SessionInfoHelper.narrow
            (orb.string_to_object(
                "CtsSecurity/SessionInfo"));

Connecting to third-party CORBA servers

Your component may need to invoke methods on a component hosted by another vendor's CORBA server-side ORB. Sybase recommends that Java components use the EAServer client-side ORB for all IIOP connections made from EAServer components. See "Connecting to third-party ORBs using the EAServer client ORB" for more information.

Using the EAServer 1.1 stub interface

Components that were developed for EAServer version 1.1 may use the EAServer 1.1stub interface to instantiate stubs for intercomponent calls. Appendix C, "Creating EAServer 1.1 Java Clients" describes how to instantiate stubs in this client model. For new development, Sybase recommends the CORBA style of instantiation for intercomponent calls.

Manage database connections

If your Java methods connect to remote data servers, you should use EAServer's connection caching feature to improve performance. See Chapter 24, "Using Connection Management" for more information.

EAServer's transactional model works only with connections obtained from the EAServer Connection Manager. Connections that you open yourself will not be able to participate in EAServer transactions.

Return result sets

Using the JDBC API, a Java component can retrieve result sets from a database. Using classes in the com.sybase.jaguar.sql package, Java components can also send these result sets to the caller. A Java component can combine the data from several result sets retrieved from databases and send that data as a single result set to a Java client. A Java component can also forward the original result set retrieved from a database.

To learn how to return result sets, see "Sending result sets with Java".

Access SSL client certificates

Clients can connect to a secure IIOP port using an SSL client certificate. You can issue intercomponent calls to the built-in CtsSecurity/SessionInfo component to retrieve the client certificate data, including:

The distinguished SSL user name
The client certificate fingerprint (MD5 message digest)
The client certificate data
The chain of issuing certificates

This component implements CtsSecurity::SessionInfo IDL interface. HTML documentation is available for the interface in the html/ir subdirectory of your EAServer installation. You can view it by loading the main EAServer HTML page, then clicking the "Interface Repository" link.

The CtsSecurity::UserCredentials interface is deprecated The CtsSecurity::UserCredentials interface, which is implemented by the CtsSecurity/UserCredentials component, has been replaced by the CtsSecurity::SessionInfo interface, which provides additional functionality such as certificate parsing. EAServer supports the CtsSecurity::UserCredentials interface for backwards compatibility. Please use the interface CtsSecurity::SessionInfo if developing new components.

Set transactional state

The transactional state of a component instance determines whether a transactional component's database updates are committed or rolled back.

In components that use the CtsComponents::ObjectControl control interface, each instance receives a CtsComponents::ObjectContext object each time that EAServer calls the setObjectContext method. The object reference is valid until unsetObjectContext is called. For more information on these methods, see the generated HTML documentation in the html/ir directory of your EAServer installation.

In classes that do not implement a control interface, call Jaguar.getInstanceContext() in each method that sets transactional state (do not save the object across method invocations, because it will not be valid if the component instance has been deactivated and reactivated). See the EAServer API Reference Manual for information on this method.

To set transaction state, choose the method that reflects the state of the work that the component is contributing to the transaction, as follows:

If the work is complete and without error, call setComplete.
Call setRollbackOnly if the work cannot be completed. Alternatively, throw the exception org.omg.CORBA.TRANSACTION_ROLLEDBACK. If the error indicates an internal inconsistency in the application, log a description of the error to help debug the problem as described in "Add error handling code".

Transaction control with the ServerBean control interface If you use the deprecated EAServer 1.1 control interface JaguarEJB::ServerBean and Auto demarcation/deactivation option is disabled in the Transactions tab in the Transactions properties for your component, the transaction state specified in the method determines whether the instance is deactivated or remains bound to the client.