Possible Solutions:
Solution #1: Talk JRMP from Delphi
Implement the Java RMI JRMP protocol in Delphi. This will be nearly impossible, since it is built on Java object serialization. So there are various approaches you could take.
Solution #2: Java on the Client, use JNI
Run Java on the client as well, and use JNI to communicate between Delphi and Java, then Java to do the client side RMI. This defeated the goal of keeping the client lean, though... a Delphi thin client can run well on an old, slow machine with 32 meg of RAM, Java can't.
Solution #3: RMI-IIOP / CORBA
Some Java application servers can seamlessly (?) expose Java services (like EJBs) as CORBA objects. Borland has CORBA support available for Delphi. This will avoid the overhead of Java on the client, but is too vendor-specific for my tastes.
Solution #4: A Proxy on the server
Use a non-RMI way to communicate between the Delphi client and an extra "tier" at the server; this piece of middleware would communicate with Delphi using any of a number of methods, even a proprietary protocol. Then use JNI or other means to access the Java services on the same (server) machine. This could be done using ASTA or MIDAS, among others.
Solution #5: Web Services with SOAP
Expose the server-side services as web services via SOAP. Choose an application server which will automatically expose your EJBs this way, if possible. Then use any available way to make a Delphi client talk SOAP. PureSOAP and Microsoft's SOAP support are two possible ways. (This is really the most appealing choice to me, as of 2001.)
Solution #6: Homegrown web services
It's really not all that hard to write wrapper code that exposes your server services via HTTP requests with parameters, via XML strings, etc. Such a thing would not be language specific, so the server could be on one language, the client in another. This solution has some appeal in cases where you want the pieces to be tightly "wrapped up" and not exposes in anything as standard as SOAP for some reason.