Hello.

One of the more common design patterns for JSP/Servlets is the MVC, whereby all HTTP requests are pushed through one (or more) Servlets that in turn pass control to other servlets and JSPs. A major advantage of this approach is that common utilities such as security can be included easily in the central controller servlet. My questions:

1) Will the new Servlet Filter feature of Servlets2.3 replace the need for an MVC or central controlling servlet?

2) Many Serlvet engines support a proprietary feature called Servlet Chaining -Could servlet chaning be used instead of a central controller? What pros/cons does the group see with this approach?

3) Is a central Servlet not a bottleneck? Most Servlet Engines will instantiate only one instance of a servlet - if all requests need to go through this one servlet, surely we have a bottlneck?


Thanks for your help

Paddy

I've briefly looked over the new Servlet spec, so take my opinions with a grain of salt.

1. I think MVC has more uses than just centralizing common functionality. MVC also separates presentation out, so that you can easily change how you represent your data. I think fileters will eliminate the need to create a heirarchy of controller servlets to centralize common functionality.

2. I think the big problem with chaining is that you combine servlets in a way that they weren't designed for. For example, only one servlet, usually the last one in the chain, should write directly to the output stream.

3. I don't think a central servlet is a bottleneck. Even though there's only one instance of the servlet in memory, multiple threads can be running through it at the same time. This is one of the biggest advantages of servlets/jsps vs. other types of CGI frameworks. As long as your central servlet does not implement the SingleThreadModel, and it's thread safe, it won't be the bottleneck. The central servlet may use something like a database or LDAP server to perform its tasks, but then those other items become the bottleneck, not the servlet.

Andy