If I understand correctly, you're talking about a pure Remoting example, right? That is, the client creates an org.jboss.remoting.Client?
Remoting 2 doesn't have any built in load balancing facility, so you'd have to write your own. There's a failover facility in the transporter code, if you want to look at that. See section "12.9.5. Transporter sample - clustered" of the Remoting Guide (http://www.jboss.org/file-access/default/members/jbossremoting/freezone/docs/guide/2.5/html/index.html) for a discussion.
Yes Your are correct, but we need the cluster not (only) for failover but for load balancing. Though I can deploy my Remoting service into the cluster, it does only work locally.
Is there a possibility to keep the client more or less as it is and put an EJB-facade in-between to achieve the load balancing?
To tell you the truth, I don't know enough about clustering to give a definitive answer, but I would say that an important consideration is whether the application is stateful. Clustering uses caching to share state among machines, so, if you need to share state, I think you would have a lot of work to reach your goal. In that case, I think you might want to adapt your client to use EJBs, with all of their built in infrastructure, instead of invoking Remoting directly. If you don't have shared state, then I guess you could just start up a Remoting server in each AS instance, but that still doesn't give you load balancing. Again, you might be better off using the built in EJB mechanisms.