[Enterprise Extensions only]

Resolving unsupported CORBA data types

If a client ORB does not support a data type required by a server object, such as an Enterprise JavaBean or C++ servant object, you can use a variety of techniques to resolve this, including the following:

Removing a data type that is not needed from the IDL for a server object

If a client ORB does not support a data type defined in the IDL file for a server object, and the client does not need to use the associated feature, you can remove the data type from the IDL used to create the client. For example, you can use the following steps to enable the client to use a version of the IDL file to access the server object:

  1. Generate the IDL file that represents the server object. For example, to generate IDL for an Enterprise JavaBean, run rmic -idl on the Enterprise JavaBean's home and remote interfaces.
  2. Make a copy of the IDL file to use with the client.
  3. Edit the IDL for the client to remove all references to unsupported data types. This can involve removing exceptions, objects, attributes, and methods (but not individual parameters or return types).
  4. Compile the IDL, and link the client with the generated bindings.

Using a wrapper to hide an unsupported data type

You can use a wrapper to hide unsupported data types needed by a server object behind a thin intermediate server object. The wrapper can be a CORBA object or a session bean. If a wrapper is being used to resolve an ORB that does not support valuetypes, then the wrapper should be implemented as a CORBA object to avoid the various extraneous valuetypes generated by the EJB-to-IDL compiler.

A wrapper provides an alternate and supported interface, and delegates its implementation to the original server object. The CORBA client accesses the intermediate wrapper, and the wrapper is deployed on a server that can directly access the target server object. The wrapper interface must be designed such that it provides access to the target object's interface without using valuetypes (for an EJB server) or other unsupported data types.

A wrapper may be the only way to get client access working for some vendor ORBs.

When using wrappers, consider the following points:

Using the dynamic invocation interface to call the server

As a last resort, the CORBA Dynamic Invocation Interface (DII) enables a client to make a call to a server without using IDL. Instead, the client makes a call by constructing the method parameters dynamically, storing them as CORBA::Any data types. This mode of access can be useful in the following cases: