SƠ LƯỢC VỀ SERVLET VÀ JSP

Một phần của tài liệu Giáo trình lập trình Web với Servlet và JSP - Đặng Thanh Dũng (Trang 42)

SƠ LƯỢC VỀ SERVLET VÀ JSP

Servlet và JSP là một trong những công nghệ được lựa chọn hàng đầu cho việc xây dựng các ứng dụng web động (ví dụ như các trang web bán hàng online). Để lý giải cho sự phổ biến của công nghệ này, trong chương này, tác giả sẽ cung cấp cái nhìn tổng quan về công nghệ Servlet và JSP.

3.1. SERVLET 3.1.1. Servlet là gì? 3.1.1. Servlet là gì?

Servlet là các chương trình Java chạy trên web server hoặc trên các application server. Servlet hoạt động với vai trò như một tầng trung gian giữa: (1) các yêu cầu gửi tới từ các HTTP client (ví dụ các trình duyệt web) với (2) các CSDL (database) hoặc là các ứng dụng trên HTTP server.

Nhiệm vụ của Servlet là thực thi các tác vụ được liệt kê dưới đây.

Hình 3.1 – Vai trò của Servlet/JSP

3.1.1.1. Đọc dữ liệu tường minh (explicit data) từ client gửi tới

Thông thường, dữ liệu này do người dùng nhập vào một HTML form trên các trang web. Tuy nhiên, dữ liệu cũng có thể đến từ một applet hoặc một chương trình HTTP client bất kỳ.

3.1.1.2. Đọc dữ liệu ẩn từ HTTP request từ browser/client gửi tới

Hình 3.1 vẽ một mũi tên đơn xuất phát từ client tới Web server (Web server là nơi thực thi Servlet và JSP), nhưng thực chất có đến hai loại dữ liệu: dữ liệu tường minh do người dùng nhập vào và các thông tin HTTP ẩn (còn gọi là dữ liệu ẩn). Cả hai loại dữ liệu này đều quan trọng. Các thông tin HTTP bao gồm cookies, thông tin về loại phương tiện (media type) và các chế độ nén (compression schemes) mà browser hiểu được.

Tạo kết quả

Tiến trình này có thể yêu cầu tương tác với CSDL, thực thi một triệu gọi tới RMI /EJB, gọi một Web service, hoặc trực tiếp tạo ra các response (gói thông tin trả về cho client từ server). Tuy nhiên, thường thì hệ quản trị CSDL không hiểu giao thức HTTP hoặc sẽ không trả kết quả dạng HTML, đồng thời vì lý do bảo mật, cho nên Web browser không thể nói chuyện trực tiếp với CSDL. Chúng ta cần tầng Web trung gian này (Servlet/JSP) để giải nén dữ liệu đến từ luồng HTTP và các kết quả nhúng trong một tài liệu nào đó, nói chuyện với các ứng dụng (application).

Gửi dữ liệu tường minh đến client

Tài liệu (document) gửi đến client có thể được gửi dưới nhiều định dạng khác nhau, bao gồm văn bản (HTML, XML, nhị phân (các ảnh GIF), hoặc thậm chí ở định dạng nén như Gzip. Tuy nhiên, cho tới nay thì HTML là định dạng phổ biến nhất, và do đó, Servlet/JSP còn có nhiệm vụ quan trọng là bọc các kết quả bên trong HTML.

Gửi dữ liệu ẩn trong HTTP response

Hình 3.1 vẽ một mũi tên đơn xuất phát từ tầng Web trung gian (Servlet/JSP) tới client. Tuy nhiên, trên thực tế, có đến hai loại dữ liệu được gửi đi: bản thân tài liệu được gửi và thông tin HTTP ngầm bên dưới. Việc gửi dữ liệu HTTP response ẩn liên quan đến việc thông báo cho browser hoặc client khác biết loại định dạng của tài liệu cần gửi lại (ví dụ như HTML), việc cài đặt cookie, bắt các tham số và các tác vụ khác.

3.1.2. Ví dụ về Servlet code

Đoạn code kế thừa lớp HttpServlet.Servlet. Lớp này cung cấp một cơ sở hạ tầng đầy đủ để giao tiếp với HTTP.

Đoạn code cũng ghi đè phương thức doGet(). Servlet có nhiều phương thức khác nhau để đáp ứng các loại lệnh HTTP khác nhau.

Bảng 3.1 - Ví dụ code servlet

import java.io.*;

import javax.servlet.*; import javax.servlet.http.*;

public class HelloServlet extends HttpServlet{

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{

response.setContentType(“text/html”); PrintWriter out = response.getWriter();

String docType=”<!DOCTYPE HTML PUBLIC \”-//W3C//DTD HTML 4.0 “ + “Transitional //EN\”>\n”; out.println(docType+ “<HTML> \n” + “<HEAD><TITLE>Hello</TITLE></HEAD>\n”+ “<BODY BGCOLOR=\”#FDF5E6\”>\n”+ “<H1>Hello</H1>\n”+ “</BODY></HTML>”); } }

Hình 3.2 – Kết quả thực thi đoạn code

3.1.3. Ưu điểm của Servlet so với CGI (Common Gateway Interface) Interface)

Java servlet hiệu quả, dễ sử dụng và rẻ hơn CGI truyền thống và nhiều công nghệ tương tự thay thế cho CGI.

Tính hiệu quả

Với CGI, ứng với mỗi HTTP request sẽ có một process (tiến trình) mới được tạo. Với servlets, máy ảo Java vẫn chạy và xử lý mỗi request bằng một thread Java nhỏ (tiểu trình Java), chứ không phải bằng một

system process lớn. Tương tự, trong CGI, nếu có N request gửi tới cùng một chương trình CGI thì code chương trình CGI sẽ được nạp vào bộ nhớ N lần. Ngược lại với Servlet, sẽ có N thread, nhưng chỉ có một bản sao duy nhất của Servlet code sẽ được nạp vào bộ nhớ. Cách tiếp cận này giúp tiết kiệm bộ nhớ máy chủ và tiết kiệm thời gian do việc tạo thể hiện cho ít đối tượng hơn. Cuối cùng, khi chương trình CGI kết thúc việc xử lý một request thì bản thân chương trình cũng kết thúc. Cách tiếp cận này gây khó khăn cho việc tính toán bộ nhớ cache, duy trì các kết nối cơ sở dữ liệu mở và thực hiện các tối ưu hóa khác dựa trên dữ liệu liên tục. Tuy nhiên với Servlet, code chương trình vẫn còn lưu trong bộ nhớ ngay cả sau khi chúng đã hoàn thành một response, vì vậy sẽ dễ dàng cho việc lưu trữ dữ liệu phức tạp giữa các request của các client khác nhau.

Tính tiện lợi (convenient)

Servlets có nền tảng mở, cho phép tự động parse (phân tích để hiểu nội dung) và decode (giải mã) HTML từ dữ liệu, đọc và thiết lập HTTP header, xử lý các tập tin cookie, lưu dấu session và nhiều tiện ích cao cấp khác. Trong khi với CGI, chúng ta phải tự mình làm những việc này.

Tính mạnh mẽ

Servlets hỗ trợ một số tính năng mà rất khó hoặc không thể thực hiện với CGI.

Servlets có thể nói chuyện trực tiếp với các Web server, trong khi CGI lại không làm được nếu không có một server-specific API.

Tính portable (khả chuyển giữa các platform khác nhau)

Servlets được viết bằng ngôn ngữ lập trình Java và theo một API chuẩn. Servlets được hỗ trợ trực tiếp hoặc thông qua plugin trên hầu hết các Web server lớn. Do đó, các servlets code được viết để chạy trên một application server nào đó, ví dụ như Macromedia Jrun, có thể chạy hầu như không thay đổi trên Apache Tomcat, Microsoft Internet Information Server (với một plugin riêng biệt), IBM WebSphere, iPlanet Enterprise Server, Oracle9i AS, hoặc StarNine Webstar.

Giá thành thấp

Một số Web server mặc dù có giá thành rẻ hoặc miễn phí như Apache Tomcat (chạy độc lập hoặc nhúng trong các Apache Web server bình thường, hoặc nhúng trong Microsoft IIS) nhưng lại rất tốt để cài đặt hoặc triển khai các trang web nhỏ. Như vậy, với Servlet/JSP, chúng ta có thể khởi đầu dự án với một server miễn phí hoặc rẻ tiền, sau đó, khi dự án đã có những thành công ban đầu, chúng ta mới đến với các máy chủ đắt tiền hơn với khả năng hiệu suất cao hoặc có các tiện ích quản trị tiên

tiến (ví dụ Caucho Resin), nhưng code của các servlet và JSP vẫn chạy bình thường mà không cần phải viết lại. Khi dự án trở nên lớn hơn nữa, chúng ta có thể chuyển đến môi trường phân tán (distributed), ví dụ như Macromedia JRun Professional –một Web server hỗ trợ các distributed application (Web farms). Khi một ứng dụng trở nên phức tạp, chúng ta có thể dùng Enterprise JavaBeans (EJB) để đóng gói business logic của ứng dụng. Điều này trái ngược với rất nhiều các lựa chọn thay thế CGI khác, thường sẽ đòi hỏi một sự đầu tư ban đầu lớn để mua một gói phần mềm độc quyền.

Tính an toàn

Một trong những nguyên nhân chính của các lỗi bảo mật trong các ứng dụng được viết theo kiểu CGI bắt nguồn từ thực tế rằng các chương trình này thường được kích hoạt bởi các shell của hệ điều hành. Khi đó, các lập trình viên CGI phải rất cẩn thận để lọc ra các ký tự đặc biệt (như dấu nháy kép, dấu chấm phẩy,…) vốn được các shell xử lý một cách đặc biệt.

Nguyên nhân thứ hai là các chương trình CGI được viết bằng các ngôn ngữ mà không tự động kiểm tra giới hạn của mảng, chuỗi, dẫn đến các lỗi tràn bộ nhớ.

Tuy nhiên, với Servlets, chúng ta sẽ không gặp các vấn đề này. Ngay cả khi một servlet thực hiện một system call (ví dụ bằng cách dùng Runtime.exec hoặc JNI) để kích hoạt (triệu gọi) một chương trình chạy trên hệ điều hành, nó không dùng shell để triệu gọi. Mặt khác, bản thân ngôn ngữ lập trình Java có khả năng kiểm tra việc tràn mảng và có các cơ chế khác để bảo vệ bộ nhớ.

3.2. JSP

3.2.1. JSP là gì?

Một cách đơn giản, chúng ta có thể xem servlet chính là các chương trình Java mà trong đó có nhúng HTML. Tương tự, JSP chính là các trang HTML có nhúng code Java bên trong.

So sánh ví dụ về Servlet trong Bảng 3.1 với ví dụ về JSP trong Bảng 3.2 bên dưới, ta thấy chúng hoàn toàn khác nhau. Servlet giống như một lớp Java thông thường, trong khi JSP giống như một trang HTML bình thường.

Tuy nhiên, mặc dù có sự khác biệt rất lớn, nhưng bản chất cả hai lại giống nhau. Trong thực tế, một trang JSP được xem nhưng một cách cài

đặt khác của servlet. Các trang JSP sẽ được dịch ra servlet, sau đó các servlet này sẽ được biên dịch, cuối cùng, các servlet đã được biên dịch sẽ chạy vào thời điểm được yêu cầu (request time).

3.2.2. Ví dụ về JSP code

Bảng 3.2 - Store.jsp

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML>

<HEAD><TITLE>Welcome to Our Store</TITLE></HEAD> <BODY BGCOLOR="#FDF5E6">

<H1>Welcome to Our Store</H1> <SMALL>Welcome,

<!-- User name is "New User" for first-time visitors --> <%= coreservlets.Utils.getUserNameFromCookie(request) %> To access your account settings, click

<A HREF="Account-Settings.html">here.</A></SMALL> <P>

Regular HTML for rest of online store’s Web page </BODY></HTML>

Mặc dù JSP và servlet về cơ bản là mạnh tương đương nhau, nhưng chúng ta vẫn cần phải suy nghĩ xem nên sử dụng công nghệ nào cho những mục đích khác nhau. Vấn đề là không phải có mạnh hay không mà là sự thuận tiện, dễ sử dụng và bảo trì. Cũng giống như bất cứ điều gì bạn có thể làm trong ngôn ngữ lập trình Java thì cũng đều có thể làm trong ngôn ngữ assembly nhưng bạn vẫn phải cân nhắc nên sử dụng cái nào. JSP tập trung vào việc làm đơn giản hóa việc tạo ra và duy trì trang HTML. Trong khi Servlets lại tập trung vào các khía cạnh business logic và thực hiện các hoạt động phức tạp. Nói cách khác, servlets là tốt nhất cho công việc hướng tới việc xử lý (processing), trong khi JSP là tốt nhất cho công việc hướng tới việc thể hiện (presentation). Đối với một số request, servlets là sự lựa chọn đúng nhưng với một số request khác, JSP là một lựa chọn tốt hơn. Thậm chí, với một số request, sự kết hợp của hai mới là tốt nhất. Và, điểm chính yếu ở đây là chúng ta cần cả servlet và JSP trong toàn bộ dự án: hầu như không có dự án nào mà chỉ bao gồm servlet hoặc chỉ có JSP.

Chương 4

CÀI ĐẶT VÀ CẤU HÌNH SERVER

Chương này trình bày cách tạo môi trường làm việc, bao gồm: tải, cấu hình, kiểm tra và sử dụng các phần mềm miễn phí, sao cho có thể chạy Servlet và các trang Java Server (JSP). Phần cài đặt ban đầu bao gồm 7 bước dưới đây:

4.1.TẢI VÀ CÀI ĐẶT SDK (JAVA SOFTWARE DEVELOPMENT KIT) KIT)

Bước này hướng dẫn tải Java 2 Platform, Standard Edition và thiết lập biến môi trường PATH tương ứng.

Phiên bản Java được chọn phụ thuộc vào việc chúng ta đang dùng Servlet/JSP API nào. Dưới đây là các phiên bản Servlet/JSP và Java tương thích:

 Servlets 2.3 và JSP 1.2 (standalone servers): Java 1.2 hoặc các phiên bản ra đời sau đó.

 J2EE 1.3 (gồm servlets 2.3 và JSP 1.2): Java 1.3 hoặc các phiên bản ra đời sau đó.

 Servlets 2.4 và JSP 2.0 (standalone servers): Java 1.3 hoặc các phiên bản ra đời sau đó.

 J2EE 1.4 (gồm Servlets 2.4 and JSP 2.0): Java 1.4 hoặc các phiên bản ra đời sau đó.

Giáo trình này sử dụng Java 1.4 trong các ví dụ minh họa.

Với các hệ điều hành Solaris, Windows và Linux, tải Java 1.4 tại http://java.sun.com/j2se/1.4/ và Java 1.3 tại http://java.sun.com/j2se/1.3/. Lưu ý là tải SDK (Software Development Kit), chứ không phải JRE (Java Runtime Environment). JRE chỉ dùng để thực thi các tập tin Java class đã được biên dịch cho nên bản thân JRE không có trình biên dịch.

Khi cài đặt Java, cần phải đặt biến môi trường PATH tham chiếu tới thư mục chứa các tập tin java và javac (thường chứa trong thư mục java_install_dir/bin).

Ví dụ, nếu chúng ta đang dùng hệ điều hành Windows và cài đặt SDK trong C:\j2sdk1.4.1_01, thì cần thêm dòng dưới đây vào tập tin

C:\autoexec.bat. (Lưu ý rằng tập tin autoexec.bat được thực thi khi hệ thống được boost).

set PATH=C:\j2sdk1.4.1_01\bin;%PATH%

Có thể tải tập tin autoexec.bat đã cấu hình (đã chứa dòng thiết lập biến môi trường PATH và một số thiết lập khác được đề cập trong chương này) tại http://www.coreservlets.com/.

4.2. TẢI SERVER

Bước tiếp theo là tải server (thường được gọi là “servlet container” hoặc “servlet engine”). Đây là cài đặt của Servlet 2.3 Specification (JSP 1.2) hoặc Servlet 2.4 Specification (JSP 2.0). Chúng ta có thể cài cả 3 servers là Apache Tomcat, Macromedia JRun và Caucho Resin vào máy tính. Cả 3 server này đều miễn phí cho mục đích phát triển, phi thương mại (riêng Tomcat thì hoàn toàn miễn phí). Khi kiểm thử (test) các ứng dụng web (web application), chúng ta sẽ cho chạy trên cả ba server này với mục đích xem xét các vấn đề phát sinh khi triển khai (deploy) website trên nhiều platform.

Việc sử dụng server cài đặt trên cùng máy tính được sử dụng để phát triển ứng dụng sẽ có các ưu điểm sau (ta sẽ gọi các server này là “desktop server”):

 Kiểm thử nhanh chóng. Khi đã cài server rồi, chúng ta không cần dùng FTP hay chương trình upload nào khác (để upload code lên server). Vì thế việc kiểm thử sẽ dễ dàng, nhanh chóng hơn. Việc kiểm thử nhanh chóng sẽ khuyến khích người lập trình thực hiện kiểm thử thường xuyên hơn, vì vậy hạn chế lỗi trong chương trình.

 Dễ gỡ lỗi. Khi chạy trên máy tính dùng phát triển ứng dụng (trong giáo trình này, để cho ngắn gọn, đôi khi tác giả dùng “máy tinh phát triển”), nhiều server sẽ hiển thị output chuẩn trên cửa sổ window thông thường. Trong khi với các deployment servers, các output chuẩn thường sẽ bị ẩn hoặc lưu trong tập tin log. Vì vậy, với desktop server, chúng ta có thể sử dụng lệnh System.out.println để gỡ lỗi.

 Khởi động lại dễ dàng. Trong quá trình cài đặt chương trình, chúng ta sẽ phải khởi động lại server thường xuyên hoặc reload ứng dụng web (tức tải lại ứng dụng web). Ví dụ, server chỉ đọc tập tin web.xml khi khởi động hoặc khi thực hiện lệnh server- specific (tức các lệnh chỉ liên quan đến server) để reload ứng

dụng web. Vì vậy, chúng ta thường xuyên phải khởi động lại server hoặc reload lại ứng dụng web mỗi khi sửa tập tin web.xml. Với desktop server, chúng ta có thể khởi động lại một cách dễ dàng mà không cần phải có sự cho phép của các lập trình viên khác đang sử dụng chung server (trong trường hợp dùng deployment server).

 Mọi việc nằm trong tầm tay của chúng ta: trong trường hợp sử dụng deployment server, nếu không phải administrator, chúng ta cần phải có sự cho phép của admin mỗi khi muốn khởi động lại server. Đôi khi, hệ thống có thể bị tắt do nâng cấp trong khi chúng ta đang trong giai đoạn cài đặt chương trình quan trọng.

 Dễ dàng cài đặt. Hiển nhiên, việc cài đặt và cấu hình server trên máy tính phát triển sẽ dễ dàng và thuận lợi hơn nhiều so với cài đặt và cấu hình một remote server.

Chúng ta có thể tải một số server tại các địa chỉ bên dưới:

 Apache Tomcat: Tomcat 5 hỗ trợ Servlet 2.4 và JSP 2.0 trong khi Tomcat 4 hỗ trợ Servlet 2.3 và JSP 1.2. Cả hai phiên bản có thể được sử dụng như một server độc lập trong quá trình cài đặt và phát triển ứng dụng, hoặc có thể được cắm vào (dưới dạng plugin) một Web server chuẩn để sử dụng trong quá trình triển khai (deploy). Có thể tải Tomcat tại địa chỉ http://jakarta.apache.org/tomcat/, vào phần binaries download và chọn phiên bản Tomcat mới nhất.

 Macromedia Jrun: Jrun chính là một engine bao gồm servlet và JSP. Jrun có thể được sử dụng ở chế độ độc lập (standalone) cho việc phát triển ứng dụng hoặc cắm vào các Web server thương mại phổ biến nhất. Đây là một server miễn phí, tuy nhiên

Một phần của tài liệu Giáo trình lập trình Web với Servlet và JSP - Đặng Thanh Dũng (Trang 42)