Trong chủ đề này, tôi muốn thẳng thắn nói về hiểu biết của mình về servlet, servlet container là gì, hầu hết, nếu không phải tất cả, web front-end framework là gì, đồng thời cũng đề cập đến chủ đề mối liên hệ giữa servlet container và máy chủ ứng dụng. lẫn nhau, các thùng chứa servlet và máy chủ web. Trước khi bắt đầu cuộc trò chuyện, tôi muốn lưu ý rằng tôi thực sự mong đợi rằng sẽ có một cuộc thảo luận, bởi vì... Ở đây tôi không muốn đưa ra một đoạn mã nào mà chỉ muốn đề cập đến bản chất, điều luôn có thể diễn đạt bằng lời. Tôi sẽ cố gắng phác thảo tất cả những điểm mà tôi chưa rõ ràng khi mới bắt đầu. Khi tôi đặt câu hỏi trên nhiều diễn đàn khác nhau về chủ đề bộ chứa servlet Tomcat khác với bất kỳ máy chủ ứng dụng nào, chẳng hạn như WebSphere hay Geronimo, những người duy nhất dám trả lời là những kẻ khốn nạn không thể nói gì khác ngoài “hãy nhìn vào Wikipedia” hoặc “ thật khó để nói, các ứng dụng máy chủ - đây là cơ sở hạ tầng phức tạp dành cho các ứng dụng của công ty, mà..." blah blah blah. Tôi không thể chịu đựng được những người như vậy và tôi đoán hầu hết các bạn cũng vậy. Chúng ta sẽ sửa chữa sự bất công lịch sử. Đi…
Servlet
Bất kể ai nói gì, servlet là một trang web được viết bằng Java. Một số người sẽ nói rằng tôi sai và servlet là một ứng dụng web và có sự khác biệt trong các khái niệm này, nhưng thực tế không phải vậy. Bây giờ không có sự khác biệt và các trang web được viết bằng PHP cũng có thể được gọi là ứng dụng web một cách an toàn. Bây giờ điều này là hoàn toàn tự nhiên, bởi vì... php hỗ trợ đầy đủ OOP và các CMS như Joomla tích cực sử dụng tính năng này. Một servlet ở cấp độ mã là gì? Đây là lớp có một số phương thức ngủ và xem liệu có ai đó truy cập chúng thông qua các yêu cầu HTTP GET hoặc POST hay không. Những thứ kia. Chúng tôi đã nhập một số yêu cầu GET trong trình duyệt, phương thức tương ứng của lớp servlet chấp nhận nó và sau đó tạo phản hồi cho nó dưới dạng trang HTML. Theo nghĩa cổ điển của một servlet, như Sun đã nghĩ ra, trang này được gửi đến máy khách theo từng dòng, bắt đầu bằng dòng <!DOCTYPE htm>> và kết thúc bằng dòng </html>. Vì vậy, trong Java có một lớp servlet cơ bản được gọi là Servlet. Ngoài ra, còn có một loạt các lớp khác kế thừa từ lớp cơ sở này và do đó mở rộng chức năng của nó. Đó chính là một servlet - không có gì hơn. Nó chỉ là một dạng tương tự Java của mã PHP, cũng được thực thi trên máy chủ và chỉ phản hồi yêu cầu của trình duyệt web dưới dạng trang web mới được gửi đến máy khách. Tất cả.
Các framework giao diện người dùng web
Phụ đề phức tạp và thường họ chỉ viết front-end framework hoặc thậm chí web muzzle , nhưng tôi quyết định nhấn mạnh ở đây rằng khi nói về front-end framework, chúng ta đang nói về GUI để làm việc với Java thông qua trình duyệt web. Những thứ kia. ở đây một lần nữa chúng ta đang nói về các trang web bằng Java, tức là. về servlet. Hầu hết mọi framework giao diện người dùng đều là gì, chẳng hạn như Apache Struts. Nó chỉ đơn giản là một tập hợp các lớp mở rộng lớp cơ sở Servlet. Chỉ có bấy nhiêu thôi. Những thứ kia. đó chỉ là một cách khác để tạo cùng một servlet thông thường. Chỉ là các nhà phát triển của khung này (hay nói cách khác là các nhà phát triển công nghệ này) cho rằng việc họ bổ sung lớp cơ sở Servletvới một số phương thức sẽ thuận tiện hơn cho lập trình viên so với chức năng ít ỏi mà servlet cổ điển của Sun/Oracle có.
trang JSP
Gần như ngay lập tức, một ý tưởng khác nảy ra trong đầu các nhà phát triển khái niệm servlet Java. Vì chúng ta đang viết một servlet, nhiệm vụ của nó là gửi một trang html đến máy khách, nên sẽ đúng hơn nếu viết ngay trang html này và nếu bạn cần một số loại logic trong Java, thì bạn chỉ cần chèn nó trực tiếp vào html. Nếu nó không trở nên rõ ràng hơn, thì cụm từ này có thể hữu ích: trang jsp tương tự như trang php. Khó? Sau đó tôi sẽ giải thích lại. Chúng ta phải làm gì khi viết một trang bằng PHP? Chúng tôi có html tĩnh và khi chúng tôi cần chèn bất kỳ logic nào vào PHP, chẳng hạn như vòng lặp và điều kiện, chúng tôi sẽ chèn nó vào phần thân của thẻ <?php … ?>. Với jsp mọi thứ đều giống nhau, chỉ có logic được viết bằng Java thuần túy, mã của nó được chèn vào phần thân của thẻ <% … %>. Hãy quay lại khái niệm về servlet một lần nữa. Về bản chất, trang JSP là một servlet nhưng được viết hơi khác một chút. Trong một servlet thông thường, chúng ta viết một phương thức thực hiện một số logic và dựa trên kết quả của nó, tạo ra một trang HTML cho máy khách. Chỉ là sau một thời gian, các nhà phát triển servlet bắt đầu nghĩ: điều gì sẽ xảy ra nếu phương thức này thực tế không có logic và hầu như chỉ xảy ra việc hình thành một trang html, thì việc viết ngay một trang html vào sẽ không dễ dàng hơn sao? cách nào để thực hiện các phần chèn Java tối thiểu? Vâng, một điều cuối cùng về các trang jsp. Lần đầu tiên một trang như vậy được truy cập, nó sẽ được biên dịch thành một servlet và sau đó được thực thi. Các yêu cầu tiếp theo tới trang jsp này sẽ nhanh hơn vì nó sẽ được biên dịch sẵn và chỉ cần được thực thi.
thùng chứa servlet
Vì vậy chúng ta đã viết một lớp servlet hoặc một trang JSP. Cái gì tiếp theo? Làm cách nào để đẩy chúng vào một máy chủ web, chẳng hạn như apache, để nó có thể gửi chúng đến trình duyệt web của người dùng? Máy chủ web chỉ có thể gửi html và nếu trang của chúng tôi có mã php, thì trước tiên, máy chủ web sẽ chuyển trang đó thông qua trình thông dịch dịch php sang html và chỉ sau đó kết quả mới được gửi đến máy khách. Điều tương tự cũng xảy ra với các servlet - trước khi gửi, chúng cần được thực thi để trang HTML được tạo và bộ chứa servlet chính xác là thứ chịu trách nhiệm thực thi các servlet và mã trang jsp. Những thứ kia. Bộ chứa servlet cho java tương tự như mô-đun trình thông dịch php trong máy chủ web. Do đó, khi người dùng nhập địa chỉ vào trình duyệt web, yêu cầu sẽ được gửi đến máy chủ web, máy chủ web hiểu rằng một servlet đang được yêu cầu và chuyển yêu cầu đến thùng chứa servlet. Sau đó, bộ chứa servlet sẽ thực thi servlet, gửi trang HTML kết quả đến máy chủ web, sau đó máy chủ web sẽ trả về nó cho máy khách. Một thùng chứa servlet có thể tự chạy được không, tức là không có máy chủ web? Một cái gì đó giống như Tomcat chắc chắn có thể làm được. Và nếu chúng ta muốn tạo một trang web không có bất kỳ trang html nào khác ngoại trừ những trang dựa trên servlet, thì một thùng chứa servlet là khá đủ đối với chúng ta. Nhưng nếu chúng ta muốn kết hợp một trang web từ các servlet và các trang PHP chẳng hạn, thì chúng ta sẽ phải cài đặt một máy chủ web. Hơn nữa, không phải tất cả các máy chủ web đều có bộ chứa servlet theo mặc định, nhưng hầu như tất cả đều cho phép bạn cài đặt nó dưới dạng plugin. Do đó, nếu chúng tôi muốn khởi chạy trang web của mình trên một số máy chủ lưu trữ trên Internet, nơi có nhiều khả năng chạy Apache nhất, thì chúng tôi sẽ phải hỏi nhà cung cấp xem thùng chứa servlet có được kết nối hay không.
Java EE
Có cái gọi là JavaSE (Phiên bản tiêu chuẩn Java). Khái niệm này bao gồm tất cả các lớp java, để sử dụng chúng ta chỉ cần nhập chúng (ví dụ: java.util.Date) hoặc thậm chí không cần thực hiện việc này (ví dụ: Stringvì nó nằm trong gói java.lang). Và có Java EE (Phiên bản Java Enterprise). Các lớp này cũng thuộc về Sun/Oracle, nhưng điểm khác biệt duy nhất là chúng khó bắt đầu sử dụng hơn trong một dự án. Một dòng đơn giản import…sẽ không đủ, bởi vì... dự án sẽ không biên dịch. Để khắc phục tình trạng này, bạn cần tìm tệp thư viện javaee.jar và đưa nó vào dự án. Điều này có thể được thực hiện thông qua các thuộc tính của dự án trong môi trường phát triển. Người ta thường nói quá trình kết nối này được gọi là: đăng ký biệt hiệu jar trong đường dẫn xây dựng hoặc đường dẫn lớp của dự án.
Máy chủ ứng dụng
Bây giờ hãy tưởng tượng rằng chúng tôi đã biên soạn dự án servlet sử dụng Java EE. Mọi thứ đều tuyệt vời, nhưng bây giờ chúng ta cần đặt các lớp đã biên dịch của mình vào một thùng chứa servlet. Hãy nói rằng họ đã làm điều đó. Ứng dụng của chúng tôi có hoạt động không? Câu trả lời là không. Khi truy cập servlet, các ngoại lệ sẽ được đưa ra cho biết rằng không tìm thấy một số lớp. Tại sao? Bởi vì chúng ta đã “đánh lừa” trình biên dịch bằng cách trượt javaee.jar в classpath, tức là trình biên dịch thấy rằng các lớp từ Java EE đã được đặt đúng chỗ và ổn định lại, nhưng bộ chứa servlet không nhìn thấy các lớp này, nhưng nó nhìn thấy các liên kết đến chúng từ servlet của chúng tôi. Tình huống này có thể giải quyết được trong vùng chứa servlet không? Tất nhiên là có, bạn chỉ cần thêm tệp thư viện javaee.jar vào thư mục chứa servlet của chúng tôi trong thùng chứa servlet . Bây giờ hãy tưởng tượng rằng sẽ có nhiều dự án như vậy và tất cả chúng đều chạy trong một thùng chứa servlet Tomcat. Điều này có nghĩa là bạn sẽ phải sao chép file jar này vào thư mục của từng servlet. Điều này thật bất tiện và sai trái. Tình huống đã được giải quyết bằng cách đưa ra khái niệm về máy chủ ứng dụng, trong đó tệp này từ lâu đã ở dạng một bản sao duy nhất và tất cả các máy chủ đều có thể truy cập nó mà không cần có bản sao riêng. Theo tôi, nó rất thuận tiện và hợp lý. Đương nhiên, tất cả sự ồn ào không phải do một tệp jar (tôi đưa ra làm ví dụ) - có rất nhiều tệp như vậy. Nhưng đó không phải là tất cả những gì máy chủ ứng dụng cung cấp cho chúng ta. Bản thân các máy chủ ứng dụng có thể duy trì kết nối với nhiều tài nguyên, ví dụ như cơ sở dữ liệu. Trong trường hợp này, servlet của chúng tôi có thể không tự mở kết nối như vậy mà chỉ cần lấy nó từ máy chủ ứng dụng. Trong một thùng chứa servlet, điều này là không thể, bởi vì... ở một mức độ nhất định, một container là một máy chủ ứng dụng đơn giản. Trong một thùng chứa, một servlet phải luôn tạo các kết nối tới cơ sở dữ liệu. Một cái gì đó như thế này... war-archive Kho lưu trữ chiến tranh là gì? WAR là kho lưu trữ web. Trên thực tế, nó chỉ là một tệp zip, giống như bất kỳ tệp jar nào. Về cơ bản, đây chỉ là một cách để nhồi nhét trang web của chúng ta, bao gồm nhiều trang web, trang jsp và các lớp servlet vào một tệp zip. web.xml web.xml được gọi là bộ mô tả triển khai. Đây là một tập tin mô tả một cách ngu ngốc yêu cầu dòng trình duyệt web nào sẽ gửi đến lớp servlet nào để xử lý, để thùng chứa servlet không bị nhầm lẫn, servlet nào chịu trách nhiệm về việc gì. Nói chung, trong Java việc mô tả các cài đặt trong tất cả các loại tệp xml là rất hợp thời, nhưng gần đây đã có xu hướng rời xa truyền thống này. Làm thế nào, bạn hỏi? Và thông qua chú thích. Bản thân các lớp chú thích không làm gì cả; chúng được tạo ra chỉ để mô tả tất cả các loại cài đặt (siêu dữ liệu) không phải trong một tệp xml riêng biệt mà trực tiếp trong mã. Rất thoải mái. Tuy nhiên, hiện tại có một giai đoạn trung gian nhất định, khi một số cài đặt được chỉ định bằng chú thích và một số cài đặt bằng xml và điều này có thể gây nhầm lẫn, bởi vì Bạn nhìn vào xml và thấy một cài đặt, nhưng theo chú thích thì có một cài đặt khác. Cái nào có mức độ ưu tiên cao nhất? Ai biết…
Phần kết luận
Viết xong tôi nghĩ rằng việc đánh giá nhanh như vậy sẽ không giúp được ai, bởi vì... không chứa bất kỳ chi tiết cụ thể và không có ví dụ, nhưng mặt khác, không xóa những gì đã viết, vì vậy hãy để nó.
GO TO FULL VERSION