Could certainly use remoting instead of RMI directly. I think the API might be easier for you (but am biased of course ;) ). The real benefit would be if think might want to change protocols one day, say to http. Would only need to change configuration and not code.
You do need to take care of synchronization in your handler code. We did not want to limit performance by forcing it to be single threaded.
As for versions, can find the matrix at http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_versions. I don't think you'll have any problems using the latest remoting release within JBossAS 4.0.1sp1, but have not tried it.
Thanks for the reply, you mentioned that API might me easier, I didn't understand what that means, is there any RMI related API available with JBOSS? Could you please direct me or to some documentation on how to use API.
You could always use RMI directly by writing the client and server code to use RMI. Then deploy the server code within JBoss. There are also several components within JBoss that use RMI for their transports by default (JNDI calls, EJB invocations, etc.), but they do not expose the RMI API (meaning the component code that uses RMI). JBoss Remoting is no different. It is possible to select RMI as the transport you want to use for remoting (or socket, http, etc.), but you won't have direct access to the code making the RMI calls. Instead, you'll have a JBossRemoting API that you would call on (which then calls on RMI code).