If a client Object Request Broker (ORB) does not support a data type required by a server object, such as an enterprise bean 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 Object Request Broker (ORB) does not support a data type defined in the Interface Definition Language (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:
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 implement the wrapper as a CORBA object to avoid the various extraneous valuetypes generated by the EJB-to-IDL compiler.
A wrapper provides an alternate interface, a 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:
Note: For Session Beans, you can manage the wrapper's lifecycle by unexporting and destroying the wrapper when the bean is removed. Because not all beans, for example, entity beans, are eventually removed, the unexport and destruction of the wrapper might have to be explicitly exposed to the client's programming model.
In this situation, it is better to put CORBA wrappers in a CORBA server and enterprise beans in a different EJB server.The client marshalls data into an opaque octet stream and passes it to the IDL wrapper. The IDL wrapper unmarshalls the data, inflates Java objects by value if necessary, and passes the data onto the target server object. For a target enterprise bean, this can be done in a session bean, which is free to use RMI-IIOP and valuetypes while interacting with entity beans.
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 and storing them as CORBA::Any data types. This mode of access can be useful in the following cases: