Protocol Independent Servlets

Question

Hello All,
It is a known fact that the Servlet API is protocol independent and Additional classes like HttpServlet provide facility to use HTTP protocol for communication.
I was just wondering, how to use the protocol independent feature of the Servlet API and use it for my own protocol. Is there any other pratical and simple example where Servlets are used with other protocols other than HTTP. I am really interested to have a look at it.
Thanks in advance!
Regards,
Giridhar Manepalli

Answer 1

Disregard my earler email :-) I somehow managed to
forget few words!
Thanks Steve!
Even before implementing classes which extend
ServletRequestWrapper etc, we need to have certain
protocol specific methods implemented by the web
container.No. The container only cares abuot the general request-response theme. There is the one exception of the HTTP protol. Since the HTTP protocol is the most often used, interfaces for that protocol are defined as part of the J2EE spec (HttpServlet, HttpServletRequest, HttpServletResponse, HttpSession) and implementations provided by the container to fullfill the spec (HttpServlet is a class, no implementation needed. Tomcat uses CoyoteRequest and CoyoteResponse to implement the HttpServletReuest and HttpServletResponse interfaces).
You would be responsible for any protocol except HTTP. But the idea is to follow the same format.
1) Extend GenericServlet to ProtocolServlet.
2) Extend ServletRequest and ServletResponse to ProtocolServletRequest and ProtocolServletResponse
3) Create implementations of the ProtocolServletRequest and ProtocolServletResponse.
-- Best bet is to extend ServletRequestWrapper and ServletResponseWrapper for these classes, since they will need to wrap around the original ServletRequest/ServletResponse.
-- You can follow the basic model provided by the HTTP implementation and never show the name of the implementing classes, just the interfaces ProtocolServletRequest and ProtocolServletResponse
4) Use the ProtocolServlet to read the ServletRequest's input stream and
-- Generate a ProtocolServletRequest and ProtocolServletResponse out of the ServletRequest and ServletResponse provided (along with pertinent information from the request's input stream).
-- Determine the best course of action based on the contents of the input stream
-- Dispatch the ProtocolServletRequest and ProtocolServletResponse to an appropriate method.
I was going through the code of tomcat, I came to
know that CoyoteRequest class which implements
HttpServletRequest, HttpServletResponse interfaces,
is actually the one that is passed to the service
method of the servlet as ServletRequest object.
Now, CoyoteRequest as part of the container contract
implemented HTTP Protocol specific code like "Method
of HTTP Request viz., GET, POST etc" and some more
protocol specific methods.
I think, when J2EE specification says Servlets are
protocol independent, it means that the containers
can implement whatever protocols they want, thereby
the application components deployed in the container
can use that protocol services.It means that the Serlvet container CAN handle any protocol (in theory). The J2EE specs. require a non-specific servlet handling mechanism (GenericServlet, ServletRequest, and ServletResponse). It also requires the container to handle the HTTP protocol because that is the most likely to be used (and is required for JSP. So HttpServlet, HttpServletRequest, and HttpServletResponse, HttpSession).
Servlets can still handle other protocols, but the container will not do it automatically. You will be forced to implement the details which sit on a layer above the generic handling.
You may want to look around the web and see if there is a servlet implementation of the protocol you want to handle. I would be surprised if there is not an FTPServlet suite hanging around. Other protocols are less likely.
If you do have to implement it yourself, make sure you read the specs on the protocl thoroughly. Your implementation will need to flawlessly parse incoming requests and send out responses in a well formed protocol-dependent manner.
>
Any thoughts?
Regards,
Giridhar Manepalli