Re: Servlets

There are two ways to look at how JSP's can be called.

1) You can access a *.JSP page on the website. The HTTP server will see the
JSP extension (assuming you set it up that way) and pass it to WebSphere.
WebSphere will examine the JSP file (compile it into a servlet if not
already done) and then execute it. You may or may not invoke other servlets
with the JSP. In this scenario, the minimum would be to script the JSP
itself which is HTML with some extensions.

2) When a servlet is invoked, you could use the callPage method to redirect
to a JSP for the output of the servlet. You can make objects available to
the JSP you are going to call, which can access those objects in its code.
In this way, you can program a servlet to perform some functionality, and
then use the JSP to format the output. This keeps the presentation separate
from the fiunctionality, so that an HTML designer can design the output page
with a minimum knowledge of JSP and a Java programmer can program the
functionality of the servlet.

You could of course combine 1 & 2. For example, you might have a JSP page
which displays an HTML Form whose action is a servlet, which performs some
operation, and displays the JSP with output...

I think it can be a bit confusing at first. My recommendation is to jump
right into and try some basic JSPs out. There is some good documentation in
the IBM WebSphere guide. Also, I found that the following sample helped me
to be able to start programming useful JSP straightaway:
http://java.about.com/compute/java/library/weekly/aa062399.htm?terms=Java+an
d+JSP&PM=112_300_T
(the above link all on one line with no spaces)

Luther

----- Original Message -----
From: Richard Dean <rddean@gdi.net>
To: <JAVA400-L@midrange.com>
Sent: Wednesday, 17 November 1999 14:39
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
>
>
> -----Original Message-----
> From: owner-java400-l@midrange.com
> [mailto:owner-java400-l@midrange.com]On Behalf Of Alex Garrison
> Sent: Thursday, November 11, 1999 11:07 AM
> To: JAVA400-L@midrange.com
> Cc: Gade_R_Reddy@consecofinance.com
> Subject: Re: Servlets
>
>
> Gade,
>
> 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 (so url's with 'https' are understood to be servlet requests) and
> to know where '/servlet' maps to in the IFS.  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
>   {
>     ServletOutputStream   os;
>     PrintWriter  pw   = null;
>     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.
>
> Alex Garrison
>
> ----- Original Message -----
> From: <Gade_R_Reddy@consecofinance.com>
> To: <agarrison@logtech.com>
> Sent: Thursday, November 11, 1999 9:31 AM
> Subject: Servlets
>
>
>
> Alex.
>
> I am new to the Servlets concept. Could you please walk me through
servlets
> & how to write them.
>
> Really appreciate your help.
>
> Thanks.
> Gade.
>
>
>
>
>
>
> "Alex Garrison" <agarrison@logtech.com>@midrange.com on 11/11/99 07:19:47
> AM
>
> Please respond to JAVA400-L@midrange.com
>
> Sent by:  owner-java400-l@midrange.com
>
>
> To:   <JAVA400-L@midrange.com>
> cc:
> Subject:  Re: forcing native access with websphere and toolbox
>
>
>
> A personal comment on jdbc:
>
> We used the jdbc drivers from websphere on the as/400 (both  toolbox and
> native) for about 17 months. To make a long story short - the  performance
> just isnt there.
>
> I know others have had a great experience with jdbc. We  brought in
> several such lucky folks as consultants to learn from their  experiences.
> Some techniques do help - stored procedures,  analyzing sql optimizer
> diagnostics, etc. Bottom line, though, is  that we get much better (like
> over 50%) performance using record-level  i/o. I know we lose portability
> by going to record-level access,  but a portable slow-running servlet
> is just no good to  us. We really just got to the point where we had no
> choice.
>
> I am not saying everyone should dump jdbc for record-level  i/o, but I
have
> a feeling there are others out there with the same experience we  had.
> Anyone else go from jdbc to record-level i/o or are unhappy with jdbc
> performance in websphere on an as/400?
>
> ----- Original Message -----
> From:  Luther Ananda Miller
> To: JAVA400-L@midrange.com
> Sent: Thursday, November 11, 1999 4:38  AM
> Subject: Re: forcing native access with  websphere and toolbox
>
> If you use JDBC, you can use the toolbox JDBC drivers to  connect to the
> AS/400 from anywhere. If you are running your servlets on the  AS/400, you
> can configure your servlet to use the native DB2 JDBC drivers  instead of
> the toolbox drivers for faster access. (Not sure how it compares to
record
> level access- I imagine record level performs faster). Another advtange
of
> JDBC is that your servlet will likely run on any java platform and connect
> to any database, depending on the SQL that you use instead.
>
> Interesting about how you must connect as QTMHHTTP to bypass  TCP/IP on
the
> 400 -- I did not know that.
>
> Luther
>
> ----- Original Message -----
> From:  Alex  Garrison
> To: JAVA400-L@midrange.com
> Sent: Wednesday, 10 November 1999  21:36
> Subject: forcing native access with  websphere and toolbox
>
> Tip of the day: IBM Java Toolbox Record Level  I/O from Servlets
> ...
>
>
>
>
>
> +---
> | 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
> +---
>
> +---
> | 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
> +---

+---
| 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
+---