Online Training Spring Hibernate Training in Delhi R Programming Training Course Big Data and Hadoop Training Java Training

J2EE Tutorial - Session Tracking

Let us now consider a case where the object is not available in the webserver but in another remote machine. This is a typical case of MULTI-TIER Client-Server computing.


J2EE Tutorial - Session Tracking


Let us now consider a case where the object  is not available in the webserver but in another remote machine. This is a typical case of  MULTI-TIER Client-Server computing. The client here is  a  servlet program.Let us call it ''. This  program accepts the data from the  form as before but  passes the data to the remote server. The bean in the remote server uses this data as parameter for its business logic, creates the result and then sends the result to the servlet. The servlet then forwards the result to the client's browser. We will use the standard Socket method.

  It is evident that we are now introducing one more layer.( we have 3 layers now).

   1) The user's browser

   2) The servlet in web-server

   3) The Remote Server housing the bean encapsulating the business logic.

   In this case, no processing is done at the web-server. The servlet simply accepts  the data from the user, forwards it to the remote server where the data is processed by the bean at the remote server and the program sends the result to the servlet , which in turn sends it to the user's browser.



public class socketgreetserver


   public static void main(String args[])




   ServerSocket  server= new ServerSocket(1234);

   System.out.println("server ready..listeneing for client in port 1234!");



   Socket  sock = server.accept();

   System.out.println("client connected");

   DataInputStream  ins=new DataInputStream(sock.getInputStream());

   String s = ins.readLine();

   System.out.println("data received");

   greeter   greeter1 = new   greeter();  //  create instance of local bean

   String  s1 = greeter1.greetme(s);

   PrintStream  ps= new  PrintStream(sock.getOutputStream());



   }catch(Exception e1)  {System.out.println(""+e1);}




Edit the above file in a dos window.

 >set path=c:\windows\command;c:\jdk1.3\bin


>java socketgreetserver

   Now the remoteserver is running and is waiting for connection

request from the client.

(ensure that the bean class is available in the same folder).


 We now see the corresponding servlet.




import javax.servlet.*;

import javax.servlet.http.*;

public class socketgreetservlet extends HttpServlet


  public void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException



   PrintWriter out=response.getWriter();




  String s1=request.getParameter("text1");//  get data from browser

   Socket  client= new Socket("localhost",1234);  // for testing

   System.out.println("server connected!");

   PrintStream  ps= new  PrintStream(client.getOutputStream());

   ps.println(s1); // send data to remote server

   DataInputStream  ins=new DataInputStream(client.getInputStream());

   String s = ins.readLine();  // get the data sent by the remote server

   System.out.println("result obtained from remote server");



  out.println(s);  // send it to browser



  }catch(Exception e1)  {System.out.println(""+e1);}




(Compilation & deployment in Tomcat , as before)

  Can we call this 'Distributed Object 'Technology?  Though , this indeed is a case of Distributed Computing, it does not qualify for being classified as 'Distributed Objects' technology, because

the method on the bean was invoked in the Remote Server and the bean also resided in the Remote Server.


   In the example considered , we assume that at both ends we are having JVM and the remote object also is a java object. What if the remote object is not a java object?

what if the remote object is wriiten in C++ and the author of that code does not care to provide a java wrapper?  Such cases are covered by CORBA  which Sun emulated in graded steps through RMI, IDL,

RMI-IIOP &  finally EJB.


   Another important feature required by most web-applications is Session-Tracking.

HTTP is a stateless protocol. (ie) In a multiform application, the data sent through the first

form will not be remembered and cannot be used in a subsequent form. , unless we make some


  The usual illustration of this problem is the 'Shopping Cart'.

The following  methods  have been proposed. 

   a) Hidden FormFields

   b) URL-rewriting

   c) Cookies

   d) Session object

   e) Application Object

 But , due to various reasons, it is the 'Session '  object method , that is found to be the best solution. Basically, Session-tracking means that any data pertaining to a browser session is retained for about 20 minutes by default, unless  the user closes the session earlier. The data is retained in the webserver's memory and not in the server's hard disk.( This point is important because, EJB entity bean is stored in Enterprise-server's hard-disk., as we shall see shortly). JSP makes it very easy to do session-tracking if we use a bean. We simply declare the scope of the jspbean as 'Session' and we get session-tracking. The following example shows a typical ' shoppingcart' bean.  We will call it  (' Shopping Cart'  is a generic term used for describing session-tracking apps.)


Share on Google+Share on Google+

J2EE Tutorial - Session Tracking

Posted on: December 15, 2008 If you enjoyed this post then why not add us on Google+? Add us to your Circles



Discuss: J2EE Tutorial - Session Tracking   View All Comments

Post your Comment

Your Name (*) :
Your Email :
Subject (*):
Your Comment (*):
  Reload Image