× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.