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