File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes When should Servlet utility classes be Servlets and when ordinary Java classes? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "When should Servlet utility classes be Servlets and when ordinary Java classes?" Watch "When should Servlet utility classes be Servlets and when ordinary Java classes?" New topic
Author

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

Benjamin Weaver
Ranch Hand

Joined: Apr 08, 2003
Posts: 161
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!
Benjamin Weaver
Ranch Hand

Joined: Apr 08, 2003
Posts: 161
I meant of course implement the interface.
R K Singh
Ranch Hand

Joined: Oct 15, 2001
Posts: 5371
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 ??


"Thanks to Indian media who has over the period of time swiped out intellectual taste from mass Indian population." - Chetan Parekh
Gary Mann
Ranch Hand

Joined: Jun 05, 2003
Posts: 37
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."
Benjamin Weaver
Ranch Hand

Joined: Apr 08, 2003
Posts: 161
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?
Benjamin Weaver
Ranch Hand

Joined: Apr 08, 2003
Posts: 161
Thanks for the info, Gary! I was writing a response to R K Singh when you sent in your reply.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: When should Servlet utility classes be Servlets and when ordinary Java classes?