• Subject: Fw: Servlets
  • From: "Alex Garrison" <agarrison@xxxxxxxxxxx>
  • Date: Wed, 17 Nov 1999 10:39:12 -0500

Richard,

"my question is to fire all of this stuff off, do you call the servlets on
your web page and then the servlet runs on the host and then it(the servlet)
calls the JSP(which is just an HTML page with special tags that can be used
to pass data into the page)."

Yep, that's it.  Typically you put a link on your webpage to the servlet (or
the submit button of a form on the webpage) like in point 1 below.  The
servlet then runs on the host gathering data from your database or whatever
you want the servlet to do.  The servlet then does a couple of things:
    1.  create the bean to hold information for the jsp.
    2.  add the information to the bean.
    3.  add the bean to the HttpServiceRequest object
    4.  call the jsp from the servlet using the HttpServiceResponse.callPage
method.  (You pass the HttpServiceRequest object to the jsp as a parm in the
callPage method.)

Once the servlet has called the jsp, the jsp can access the bean to extract
the information and display it in html.  Jsp's are funny beasts.  The jsp
file does indeed just look like html with some extra tags.  Websphere takes
the jsp and automatically converts it to a .java source file and then
compiles the .java source to a .class file.  It is this java class file that
actually runs on your server to generate the html stream back to the
browser.  Once you start doing this on your system, take a look at the .java
source file websphere generates from your jsp.  It is very interesting -
sure demystifies how the whole jsp works.

I didnt go into this level of detail before soas not to confuse the issue.
The websphere documentation has a great sample servlet and jsp to illustrate
how easy this can be.  It all sounds harder than it really is.  If you are
interested, let me know and I can email some simple source to get you going
with jsp's.

By the way, I did have an error in the servlet description I originally
sent.  I am grateful to those who pointed it out to me.  Here is a revised
description:

In a nutshell, servlets are java classes that run on a web server.  The best
way I know to explain the concept is to walk through a simple scenario:

 1. Your browser sends a url request to a web server something like:
 https://www.mycompany.com/servlet/myservlet?apple=red&grape=purple

 2. Your web server (like websphere on an as/400) must be configured to
enable servlets and to know when a url request should be passed to a servlet
as opposed to simply serving up an html file.  In our little example in step
one, you would have to set up your http config file on the as/400 to enable
servlets and to know where '/servlet' maps to in the IFS (by adding the
Service, ServerInit, and ServerTerm directives in the right spot in your
http config file).  Anyway, websphere looks at the url request from step 1
and runs the servlet called 'myservlet' passing the parms (and other stuff)
to the servlet in a special HttpServletRequest object.

 3. Your servlet on the as/400 gets the HttpServletRequest object and breaks
out the input parms.  In this case the servlet understands that you have two
parms, apple and grape.  Further you have told the servlet that the value of
apple = 'red' and the value of grape = 'purple'.

 4.  The servlet then goes off and does whatever you do if an apple is red
and a grape is purple.   Here is where things get interesting.  The servlet
could write html directly back to the browser (say reporting how many red
apples you have), or the servlet could call a jsp.  In the latter case, the
jsp would build the html and write the html back to the browser. (There are
other things you could do as well, but these two options are the most
common, I think.)

 5. Finally the resulting html makes it back to your browser and is
displayed to you.

 The advantages of servlets from my point of view are:
     1.  Servlets run entirely on the server.  This is more secure since the
client knows nothing about the servlet code.
     2.  The client browser doesnt need any applets or even java.  This
means people with old browsers and even slow computers can access my web
site just fine.
     3.  I can enhance my servlets on my server and they take effect for all
users immediately.  No downloading new applets
          or classes to the browser.

 The main advantage to using jsp's in conjunction with servlets is that I
can easily divide the duties among various programmers.  The jsp programmer
focuses purely on taking the servlet results and formatting the most
 attractive html.  They dont really even have to know any java - just be
really good at html.  The servlet programmer just has to know java and can
forget about how the results are eventually displayed to the user.  It is
 the classic separation of presentation layer and application layer.

 I really cant walk you through the whole process in an email.  There are
some good documents out there that do this in a couple of thousand pages.
You might want to look at the Sun documentation of servlets and the IBM
websphere documentation.  Anyone else have some good links?


 To give you the flavor of a very simple servlet consider this:

 public class Simple extends HttpServlet
   {
     public void doGet(HttpServletRequest req, HttpServletResponse res)
       {
         PrintWriter  out=null;
         try
          {
            res.setContentType("text/html");
            // Next three lines prevent dynamic content from being cached
            // on browsers.
            res.setHeader("Pragma", "no-cache");
            res.setHeader("Cache-Control", "no-cache");
            res.setDateHeader("Expires", 0);
            out = res.getWriter();
            out.println("<HTML>");
            out.println("<HEAD><TITLE>Simple Servlet</TITLE></HEAD>");
            out.println("<BODY>");
            out.println("<H1>Test Servlet </H1>");
            out.println("</BODY></HTML>");
            out.close();
           }
         catch(IOException e){}
     }
 }

 This servlet is my equivalent of "Hello World."  It will just write some
simple html to your browser directly (no jsp involved).  Notice I only
really had to code one method in this simple servlet, the 'doGet' method.
Servlets can get much more complicated obviously, but I wanted you to see
that at the most basic level servlets are really straightforward.

----- Original Message -----
From: Richard Dean <rddean@gdi.net>
To: <JAVA400-L@midrange.com>
Sent: Wednesday, November 17, 1999 8:39 AM
Subject: RE: Servlets


> Alex,
> This is a great explanation of servlets, thanks for taking the time to
help
> some of us that are still behind the curve on this stuff.  After reading
> your explanation I had an additional question for you.  I am a little
> confused about websphere and JSP's.  I went back and looked at some old
> e-mails about JSP's and I understand that the JSP programmers set up the
> HTML and can receive data from the servlets through some sort of tag, my
> question is to fire all of this stuff off, do you call the servlets on
your
> web page and then the servlet runs on the host and then it(the servlet)
> calls the JSP(which is just an HTML page with special tags that can be
used
> to pass data into the page).
>
> Sorry in advance I know this subject has been beat to death.
>
> Thanks,
> Richard
>
>


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.