![]() |
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:
rmic -idl
on
the Enterprise JavaBean's home and remote interfaces.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:
The client marshals data into an opaque octet stream and passes it to the IDL wrapper. The IDL wrapper demarshals the data, inflating java objects by value if necessary, and passes data on to the target server object. For a target Enterprise JavaBean, 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, storing them as CORBA::Any data types. This mode of access can be useful in the following cases:
rmi:
prefix.Related concepts... | |
Parent: General CORBA interoperation considerations | |