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 chúng ta phải mua bản quyền trước khi muốn triển khai ứng dụng web lên Internet. Có thể tải Jrun tại địa chỉ http://www.macromedia.com/software/jrun/.
Caucho’s Resin: Resin cũng là engine cho servlet và JSP có tốc độ nhanh và được hỗ trợ XML mở rộng. Cùng với Tomcat và Jrun, Resin được xem là một trong ba server phổ biến nhất. Có thể tải Resin tại địa chỉ http://caucho.com/products/resin/.
4.3. CẤU HÌNH SERVER
Sau khi đã cài đặt Java Platform và server có hỗ trợ Servlet và JSP thì chúng ta cần tiến hành cấu hình server.
Lưu ý rằng giáo trình này hướng dẫn cấu hình một standalone Web server, sử dụng cho việc phát triển các ứng dụng web trên desktop (tức máy tính của nhà phát triển phần mềm, chứ không phải là server chuyên dụng).
Bước 1: Cần xác định thư mục cài đặt SDK. Để biên dịch trang JSP, server cần biết nơi lưu các Java class (được sử dụng bởi một Java compiler như javac hoặc jikes). Đối với hầu hết các server, hoặc là wizard cài đặt server dò tìm thư mục cài đặt SDK (trong khi cài đặt server), hoặc là chúng ta phải thiết lập biến môi trường JAVA_HOME tham chiếu tới thư mục SDK.
Bước 2: Chỉ định port. Hầu hết các server được cấu hình trước để sử dụng port không chuẩn nếu đã có một server sử dụng port 80 rồi. Nếu chưa có server nào sử dụng port 80, thì chúng ta cần thiết lập một server mới sử dụng port 80.
Bước 3: thực hiện tùy chỉnh máy chủ cụ thể. Các thiết lập này khác nhau trên các server khác nhau.
4.4. CẤU HÌNH APACHE TOMCAT
Với hầu hết các cỗ máy Servlet và JSP (Servlet and JSP engine) phổ biến thì Tomcat là server khó cấu hình nhất. Tuy nhiên Tomcat cũng là server được nhiều người dùng nhất vì các phiên bản của nó thường xuyên được cập nhật, và với mỗi phiên bản thì luôn có các chỉ dẫn cài đặt và cấu hình riêng.
Điểm đặc biệt ở Tomcat là nó sẽ tạo các tập tin tạm khi nó chạy. Vì thế, Tomcat phải được cài đặt ở thư mục nào mà người dùng Tomcat có phân quyền ghi (write acess) trên thư mục đó. Sau khi tải về và giải nén các tập tin Tomcat, chúng ta tiến hành cấu hình server theo các bước sau:
Bước 1: Thiết lập biến môi trường JAVA_HOME. Đặt biến này chỉ vào thư mục cài đặt JDK cơ bản.
Bước 2: Xác định các port của server. Sửa tập tin install_dir /conf /server.xml và thay đổi giá trị thuộc tính port của phần tử
Conector từ 8080 thành 80.
Bước 3: Reload lại server. Thêm phần tử DefaultContext vào tập tin install_dir /conf /server.xml nhằm mục đích thông báo với Tomcat phải tải lại servlet vì servlet đã được nạp vào bộ nhớ của server và mà các tập tin class của những servlet này đã thay đổi trên ổ cứng sau khi chúng đã được load.
Bước 4: Bật ROOT context lên. Bước này là để sử dụng Web application mặc định. Ta thực hiện bước này bằng cách uncomment (bỏ chuỗi “//” ở đầu dòng) dòng sau trong tập tin
install_dir/conf/server.xml:
<Context path="" docBase="ROOT" debug="0"/>
Bước 5: Bật servlet invoker. Để có thể chạy servlet mà không dùng đến tập tin web.xml, một số phiên bản của Tomcat yêu cầu phải uncomment phần tử /servlet/*servlet-mapping trong tập tin install_dir/conf/web.xml
Bước 6: Tăng giới hạn bộ nhớ DOS. Trong các phiên bản Windows cũ hơn, cần thông báo với hệ điều hành là phải có không gian lưu trữ nhiều hơn cho các biến môi trường.
Bước 7: Thiết lập biến CATALINA_HOME. Đặt biến CATALINA_HOME tham chiếu tới thư mục cài đặt Tomcat. Bước này là tùy chọn, không bắt buộc.
Lưu ý rằng trên đây chỉ là hướng dẫn cấu hình một Tomcat server