I need to write Bridge application in .NET and the client is Java RMI. I trying to find the right way to implement the server in .NET if it possible.
It's not impossible, but almost certainly not worth the trouble to develop the bridge in pure .NET. If you can't change the client to a more interoperable technology (some multi-language RPC or REST), consider how to incorporate the Java server side of the RMI into the bridge application.
For example, you can host a JVM in a "native" process you develop in C/C++, or you can load a DLL of native code into a JVM process. In either case you use JNI to communicate from the Java to the C/C++. And you can develop the C/C++ side in C++/CLI to make the transition to .NET. (This leads to the interesting scenario of both a JVM and a CLR running in the same process, which I've never personally used.)
Alternately, you could separate the server-side Java and .NET into distinct processes, and have them communicate, again, using a multi-language RPC or REST (note this does not require changing the client). If the interface you are bridging is large, you might prefer this approach to writing the native side of a large JNI interface, which I find tedious and error-prone.