It really comes down to where you want to do your load balancing.
You could write a Java-based distributor to do it, maintaining a list of target beans on different servers and their current load, bouncing long-running requests through to each.
Or you could use a load balancer (as Olivier suggested) which does the same thing, but instead of at a Java level it works at the HTTP level. Load balancers can distribute traffic in various configuration patterns based on round-robbin and even based on individual server load. They tend to offer quite sophisticated options as well, such as the target server being able to work at the MAC address level and respond directly to the client rather than directing the response back through the load balancer. Load balancers are a mature technology backed by a lot of R&D and real-world deployments. To give you some idea, see "Three Ways to Load Balance" at http://www.linux-mag.com/2003-11/clusters_01.html.
The nice thing about a dedicated load balancer is you don't have to write it. A Java-based distributor will be time-consuming as you need to poll target beans (to determine their present load/availability) or otherwise track the volume of outstanding requests for each target bean. For all the effort, it will probably be comparatively inefficient unless you spend lots of engineering time. It really isn't the sort of thing you want to be developing if a standard load balancer will meet your needs. Of course many application servers will load balance for you, but then you're adding a layer of software and typically RMI which would probably still not be as efficient as the web services clients being directed by a proper load balancer at a nice low OSI layer to an available web container.
Another option would be to look at writing your "job" processing system using a message driven approach. ActiveMQ has recently added support for message driven POJOs which could be exactly what you're after. See: http://sourceforge.net/mailarchive/message.php?msg_id=9896311. A great thing about JMS is that if you don’t need a distributed system you can run the message producers/consumers all "in process" with very little overhead but if/when you do need to add servers you are insulated from a lot of the mechanics of this process.
You're spoilt for choice on this one, but don't forget, (as Ben often says;)) KISS (keep it simple stupid), before you start creating a super distributed architecture with all the bells and whistles it's worth spending a bit of time to analyze whether this is really something you need.
首先声明一点，普通的POJO并不意味着要写比EJB更多的代码，POJO的核心概念是“don't call me, I will call you"，从这点来说，如果把POJO脱离一个管理他们的容器来讨论是显得毫无意义的。 POJO的特点是通过轻量级容器解耦了组件间具体类之间的依赖，使得接口依赖成为可能，而IOC/AOP越来越完善的规范，使得我们切换基于POJO的应用在不同的容器成为可能，如果要给这些容器置上一个大致的前提规范：至少应该提供IOC实现，至少应该提供声明性配置，至少应该提供事务管理。