Forums Register Login

When should Servlet utility classes be Servlets and when ordinary Java classes?

+Pie Number of slices to send: Send
I'm new to Servlets. 1. What motivations are there to make utility classes Servlets themselves? Life-cycle might be one, HttpServlet interface might be another. But, in the latter case, why not just inherit the interface?
For example, forwarding a request. Why not instead just pass the HttpRequest object to the utility object and have that object return to the calling servlet?
2. Utility classes, including servlets, are allowed to make calls outside the container, can they not? Say as a socket client?
Your perspectives are appreciated!
+Pie Number of slices to send: Send
I meant of course implement the interface.
+Pie Number of slices to send: Send
 

Originally posted by Benjamin Weaver:
2. Utility classes, including servlets, are allowed to make calls outside the container, can they not? Say as a socket client?


Can you elaborate this ??
+Pie Number of slices to send: Send
Benjamin,
My take is that the number of servlets should be minimized for performance reasons and that code that may be reused should be in utility classes. Generally, servlets are good for servicing requests (usually HTTP) and for control logic related to a web application. If the function of some code is not one of the these two, then consider moving it out of the servlet. Examples are business logic and database access.
Presentation should usually be in JSPs (for HTML) or could be in the servlet if JSPs are not used.
This approach enables common logic to be independent of the request protocol (HTTP). e.g. business code in a utility class could be reused directly by a Java application or via RMI.

Note that this means HTTP concepts such as the request, session and response should not usually be passed to utility classes. The exception is when the utility class is really a helper class for the servlet (control, request parsing, HTML generation...).
Your example of passing the HttpRequest to the utility object is widely used in frameworks such as Struts that employ a "Front Controller" servlet that handles all requests and routes them to various utility objects (Struts Actions). This means that only one instance of the servlet is required for the whole application and each request is handled by a lightweight thread - a very efficient approach.

GMann (SCJP, SCJD, SCWCD, SCBCD)
"I'd rather have a bottle in front of me than a frontal lobotomy."
+Pie Number of slices to send: Send
For example, you might want, in your business logic, to connect via socket to a remote server, retrieve from that server certain data, then post that information to the web. It would be natural to delegate that socket activity to one or more business-logic classes. One technique would be to subclass a Command object (let's assume we are not using Struts), let's call it MakeSocketConnectionToServerCommand. The Command superclass would import the java.servlets package and include at least one abstract method: execute(HttpRequest). But it would not need to be a servlet. (I'm thinking of an working example of this in our product line).
Such a Command class hierarchy exemplifies the use of non-servlet classes to perform business functions.
Another way to put the question is, why, if ever, would business logic utility classes be servlets?
For that matter, why do we ever need more than 1 servlet per application?
+Pie Number of slices to send: Send
Thanks for the info, Gary! I was writing a response to R K Singh when you sent in your reply.
Oh the stink of it! Smell my tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1642 times.
Similar Threads
HttpServletRequestWrapper?
Running an Applet in Tomcat 4.0
Front controller and DAO, design question!
Servlet Redirection
Clarification of underlying code.
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 10:06:00.