Howdy, >In all there will be about 50 commands that can be done to this servlet. If >I put them all in one file it would violate my sense of object oriented >engineering. So I thought of either making the various commands actually be >in different classes and the servlet routing the requests to the proper >command. The alternative is to make individual command servlets that have a >common base class and sit on separate URLs. > >The problem with option two is that the servlet connects to EJB on the back >end and could potentially hold onto allot of resources. The problem with >option two, possibly, is federation. If there are hundreds of requests >coming, will tomcat federate the servlet or pipe everything through one >hole?
1. Take a look at struts. It will handle the direction of the request to the proper resource based on the 50 actions (which you call "commands" above) you define. 2. Simply put: don't worry about federation. Let tomcat worry about how many instances of the servlet it needs, how many request processing threads it needs, etc. Tomcat does a good job at this, and some of the relevant parameters (maxProcessors etc.) are user-tunable as well. We, as well as many other people on this list, run tomcat instances that handle thousands of requests. Also, you can always switch containers if you find tomcat doesn't handle your traffic volume as well as you'd like... Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
