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