I have never done this but imagine some general pitfalls: - long socket processing would probably time-out the browser client. - socket-processing is usually multi-threaded. HttpServletResponse objects must not be used in separate threads if the original request thread already committed a response. - Establishing a socket-listener in each ServletRequest is certainly not what you intend to do. You probably want to establish it in the servlets 'init()' Method or in static initalization. - A servlet container may unload a servlet unexpectedly (not only on servber shutdown). You should catch these events in the 'destroy()' or 'finalize()' method respectively. Due the restricted lifecycle of servlets i don't see much sense in a servlets socket processing so far (beside some kind of remote monitoring). What do you want to do exactly? Wolfgang
Joined: Jan 31, 2001
I am developing a system. There only one entry and exit point to the system ie via DMServlet. Its recieves 2 variables thru the url. Depending on the value of these variables, DMServlet calls other servlets (sub-servlets) which do some processing. The data obtained by these servlets has to be sent back to DMServlet which in turn will understand what has to be sent to the user. Since the DMServlet and the various sub-servlets are loaded on diffrent m/cs/JVMs, the HttpSession class cannot be used to pass the information. The problem how data is to be sent from subservlets to DMServlets. Hence I was wondering if DMServlet could listen and wait for data coming from sub-servlets by opneing a ServerSocket. Any ideas?
Hence I was wondering if DMServlet could listen and wait for data coming from sub-servlets by opneing a ServerSocket.
Well, yes, you can do it.The process is called Http Tunnelling.This is a method of writing serialized objects using HTTP connection.You are creating a sub-protocol inside the HTTP protocol- that is "tunneling" inside another protocol.This relieves you from the hassles of dealing with the actual transport layer. Some pros of this technique: 1. It is simple to use because of Serializable interface. 2. It is very fast for lightweight objects 3. It sheilds you from the communicating layer 4. Most important, it provides you a method of "tunneling" through firewalls Some cons : 1. You need to make sure that all your objects and nested objects implement the Serializable interface 2. You typically use this in Applet-Servlet communication, and this could pose security issues to limit you to connect to the applet originating server. 3. It would give you a performance hit, if you try to pass larger objects using this technique As far as the code goes, you would need to use the java.net.* package. You may open the connection using :
Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java Scored 56 out of 59
IBM Enterprise Connectivity with J2EE Scored 72 per cent
Enterprise Development on the Oracle Internet Platform Scored 44 out of 56
Joined: Mar 26, 2001
Sachin, to access your servlet use a URLConnection as Desai suggested. There is also a java.net.HttpURLConnection class, but i didn't use it so far. You don't have to communicate serialized objects necessarily. For simple text or html responses of the subservlet you can read the InputStream directly using 'getInputStream()' on the open URLConnection. Object serialization might be the appropriate approach regarding a clean architecture or complex information exchange. It might fail if your are not the author of the subservlet or your boss prefers quick solutions :-) Good luck, Wolfgang
Joined: Apr 02, 2001
Hi Sachin, Wolfgang is right!You donot need to use serialization, if you have simple text/html responses. However, going by what you have said
Since the DMServlet and the various sub-servlets are loaded on diffrent m/cs/JVMs, the HttpSession class cannot be used to pass the information.
I assume, you would want to store some objects in the HttpSession class, and use the same in your sub-servlets located on the different machine/JVM's.In that case, you have 2 options : 1. Use Serialization 2. Store the HttpSession Object in the DB, and retrieve it, for later use. The second option is preferable, if your objects are quite large in size and you have a complex CS in place The first option is OK for transporting small objects (certainly not image files,etc.), which may not clog your networks. There are trade-offs, in both the design and you have to choose judiciously. Regards,