I was facing a similar problem recently - we are forced to use 4-tier architecture, where presentation and business logic are hosted in different containers from different vendors (SAP Enterprise Portal on SAP Web AS and IBM WebSphere, respectively).
There are several ways to call EJBs from standalone Java clients (that are also applicable to calling EJBs from presentation logic residing in a different container). Some of them are:
1. Over RMI, if your CORBA implementation classes are compatible on both calling and server sides. This can be done from a standalone client running in a J2EE application client environment provided by your EJB container vendor.
If you don't have a luxury of running your client code in a J2EE application client environment (we didn't), you might be able to achieve interoperability using recent versions of JDK on client and server sides. In our case, a J2SE application working on top of Sun JDK 1.4 (not 1.3!) was able to call EJBs hosted in WebSphere 5.1 using standard Sun RMI/CORBA implementation classes (com.sun.jndi.cosnaming.CNCtxFactory).
Performance-wise, of course, RMI is better than HTTP - if you can use it (we couldn't, since SAP Enterprise Portal uses its own CORBA implementation classes that do not interop with those of IBM).
2. CORBA is definitely possible, but I don't think it is a very natural approach to communicate between client and server side when both are Java-based.
3. Over HTTP, Web Services (possibly with JAX-RPC) will obviously work, but present a certain overhead. I believe you have rejected this solution.
4. Another way to call EJBs over HTTP is a servlet bridge. It works nicely, especially if you use dynamic proxies on the client side (clients can call remote services and get application exceptions transparently) and dynamic EJB invocation (via reflection) on the server side - this allows you to have a single "gateway" to any EJB in your application that you never have to recompile. Also, unlike with RMI, you don't have to have any EJB-specific stubs on the client side, just the remote interface.
The full solution for a generic servlet bridge is given in the "Bitter EJB" book by Bruce Tate, Mike Clark, Bob Lee and Patric Linskey: See it on Amazon.com
There is also a relevant thread on TSS discussing EJB dynamic invocation: Strategy: Using reflection to invoke EJB
Note, however, that if you are not running your stand-alone client in a J2EE application client environment, you are not going to be able to keep transactional and security contexts initiated on the client. This might not be a concern for you, otherwise there are always design walkarounds.