What's really lacking (or impossible, depending on how you prefer to see it) in the EJB to CORBA mapping (rather than the Java-to-IDL reverse mapping) is a decent alternative to support pre-CORBA 2.3 clients in a uniform way across vendors (things like Java String maps to IDL 'string', serializable objects map to IDL 'struct' types where possible, etc.). Of course, it is not trivial to come up with a Java-to-IDL mapping that doesn't require OBV.

Now Java programmers (including EJB programmers) tend to fully exploit the Java features. Expect lots of Java objects, collection classes etc. in remote interfaces. For all these cases it's going to be difficult anyway. If you want to design for cross-language, you may start with IDL, generate Java from it, and use the Java signatures in the remote interfaces.

One alternative is to implement a CORBA-to-EJB adaptor. That is a middle layer that takes CORBA calls and delegates to respective EJB beans. Here is a customer story …

Our CORBA IDL interface is a meta-data driven interface. That is, we use tags/value pairs to indicate the session bean to be called, the method on the session bean, and arguments. Really cool stuff, as we no longer have to change IDL when there is a change in a session bean interface or even CORBA client interface. The interface is data driven, just like XML. If you are coming in from a CORBA client, then define a simple IDL with tag/value structures for commands and responses. And establish a contract between client and server on what is expected on those tags (maybe something like an XML dtd). Develop a parser on the server side to honor the contract and have the parser delegate calls to respective beans. Some of your tags could be a hint to what bean and method is going to be called. We have made some of our tags to be the same as the fully-qualified session bean class name so that we can use introspection in the CORBA-to-EJB adaptor.