Ben Engber wrote:
> Hello everyone,
>
> I've been working on a framework for a large application here and am
> looking for some advice on how I should implement it.
>
> Currently, we've written a base servlet class that all other servlets
> extend from. The base servlet class performs error trapping,
> authentication, etc., and passes the state of the current request to
> protected methods via our own context class.
>
> But it seems that a cleaner approach might be to have only one servlet
> which loads and instantiates non-servlet classes based on the PATH_INFO of
> incoming request. That would eliminate the need to pass context objects
> around, and might allow for better security.
>
> On the other hand, inheriting from a base servlet might perform better (in
> both cases a new object is instantiated per request, but perhaps the
> servlet engine does some optimizations in this case)?
>
> Does anyone have any suggestions as to which approach is better? We're
> expecting very high traffic (one million page views/day or higher).
>
> Thanks,
> Ben
>
A model that has worked well for me is kind of a hybrid of the ideas you've
described above. It incorporates the following elements:
* A base servlet that uses PATH_INFO to decide what
action to take. The mapping of path strings to action
classes is specified in the initialization parameters. As
needed (see below), an instance of the Action implementation
class will be created dynamically.
* In the servlet engine, I create one servlet per "application"
(where an "application" is loosely defined as "a group of
actions that work together to accomplish a common purpose,
and need to share resources to do so.") Each application uses
the same base servlet class -- it is the initialization parameters
that make the apps distinct.
* The base servlet also offers some convenience public
methods for sharing resources. For example, my apps have
to be internationalized, so the servlet offers a convenient place
to provide access to the resource bundles containing the actual
message strings for that application.
* The base servlet can also be extended on a per-application
basis to provide more shared services (like a connection pool),
common authentication checking, and so on. This makes it
possible to create applications that have unique shared information
requirements, while still taking advantage of the rest of the
features of this framework architecture.
* For actions, I've defined an interface (Action) that has one method:
public void perform(ActionServlet servlet,
HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException;
* The ActionServlet argument to a perform() method provides access
to the shared resources provided by the servlet. The request and
response arguments let it do anything a servlet's service() method
can do, including using request dispatchers in a 2.1-compliant engine.
* To avoid the object creation overhead, I only instantiate an Action class
instance the first time it is used. I maintain a Hashtable in the base
servlet
of previously instantiated actions, and just re-use the existing ones.
* For this to work, your Action classes need to be multithread safe,
and not have any local state information -- pretty much the same
rules as for creating multithread safe servlets. They feel pretty much
like an almost-zero-overhead stateless session bean in an EJB world.
I've found that this framework approach works pretty well in a pure servlet
environment where the servlets create all of the page content dynamically, and
also very well to provide the functional logic in a JSP "Model 2" world (from
the JSP 0.92 spec) where servlets perform the business processing, store
results in the request or session, and forward control to a JSP page that
performs the actual display.
There are also some available frameworks that encapsulate these principles.
It's a little late for me (I have a lot of code based on the above
architecture), but if you haven't started writing code yet I would investigate
using an existing framework as a starting point. My recommendation would be
to stay with one that is open source, and does not rely on proprietary
commercial class libraries, to avoid getting locked in to a particular vendor
in such a quicly changing technical environment.
>
> --
> Ben Engber
> Software Engineer
> The New York Times
> [EMAIL PROTECTED]
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
