再说spring，spring是什么呢？我没有看到特别明确的定义，不过我想仿照ejb，定义spring为： Spring is a Javabean-based framework that supporting component architecture development.Spring provides lighter context for heterogeneous entrprise
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.
oliverhutchison: 引用: 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. Ollie