Nang walang pathos. Pag-usapan natin ang Java EE, mga servlet at ang kanilang mga lalagyan

Sa paksang ito, nais kong tapat na pag-usapan ang tungkol sa aking pag-unawa sa mga servlet, kung ano ang mga lalagyan ng servlet, kung ano ang karamihan, kung hindi lahat, mga balangkas ng front-end ng web, at hawakan din ang paksa kung paano nauugnay ang mga lalagyan ng servlet at mga server ng aplikasyon. bawat isa, at mga lalagyan ng servlet at web server. Bago simulan ang pag-uusap, nais kong tandaan na inaasahan ko na magkakaroon ng talakayan, dahil... Dito ay hindi ko nais na magbigay ng isang solong piraso ng code, ngunit nais lamang na hawakan ang kakanyahan, na palaging maaaring ipahayag sa mga salita. Susubukan kong balangkasin ang lahat ng mga puntong hindi malinaw sa akin noong una akong nagsimula. Nang magtanong ako sa iba't ibang mga forum tungkol sa paksa kung paano naiiba ang lalagyan ng servlet ng Tomcat sa anumang server ng aplikasyon, sabihin ang WebSphere o Geronimo, ang tanging mga tao na nangahas na sumagot ay mga asshole na walang masabi maliban sa "tingnan ang Wikipedia" o " mahirap sabihin, mga application ng server - isa itong kumplikadong imprastraktura para sa mga corporate application, na..." blah blah blah. Hindi ko kayang tiisin ang mga taong ganyan at sa tingin ko karamihan sa inyo ay hindi rin. Itatama natin ang kawalang-katarungan sa kasaysayan. Pumunta…

Mga Servlet

Anuman ang sabihin ng sinuman, ang servlet ay isang web page na nakasulat sa Java. Ang ilan ay magsasabi na ako ay mali at ang isang servlet ay isang web application at na mayroong pagkakaiba sa mga konseptong ito, ngunit hindi ito ganoon. Ngayon ay walang pagkakaiba, at ang mga site na nakasulat sa PHP ay maaari ding ligtas na tawaging mga web application. Ngayon ito ay ganap na natural, dahil... Ganap na sinusuportahan ng php ang OOP, at aktibong ginagamit ito ng mga CMS gaya ng Joomla. Ano ang isang servlet sa antas ng code? Ito ay isang klase na may ilang mga pamamaraan na natutulog at nakikita kung may nag-a-access sa kanila sa pamamagitan ng GET o POST HTTP na mga kahilingan. Yung. Nag-type kami ng ilang kahilingan sa GET sa browser, tinatanggap ito ng kaukulang pamamaraan ng klase ng servlet at pagkatapos ay bubuo ng tugon dito sa anyo ng isang HTML na pahina. Sa klasikong kahulugan ng isang servlet, dahil ito ay inisip ng Sun, ang page na ito ay ipinadala sa client linya sa pamamagitan ng linya, simula sa linyang <!DOCTYPE htm>> at nagtatapos sa linya </html>. Kaya sa Java mayroong isang pangunahing klase ng servlet na tinatawag na Servlet. Bilang karagdagan, mayroong isang bungkos ng iba pang mga klase na nagmana mula sa base class na ito at sa gayon ay nagpapalawak ng pag-andar nito. Iyan ay kung ano ang isang servlet - wala nang iba pa. Ito ay isang Java analogue lamang ng PHP code, na ipinapatupad din sa server, at ang tugon lamang sa kahilingan ng web browser sa anyo ng isang web page ay ipinadala sa kliyente. Lahat.

Mga framework sa front-end sa web

Подзаголовок сложноват и обычно все же пишут просто фронт-энд-фреймворк or даже веб-морда, но я решил здесь подчеркнуть, что когда речь идет о фронт-энд-фреймворках, то говорят о GUI для работы с Java через веб-браузер. Т.е. здесь опять идет речь о веб-сайтах на Java, т.е. о сервлетах. What же представляет собой почти любой фронт-энд фреймфорк, к примеру, Apache Struts. Это просто набор классов, расширяющих базовый класс Servlet. Более ничего. Т.е. это просто другой способ создать тот же самый обычный сервлет. Просто разработчики этого фреймфорка (or иначе говоря, разработчики этой технологии) посчитали, что их дополнение базового Servlet-класса кое-Howими методами будет более удобно для программиста, чем тот скудный функционал, что есть у классического сервлета от Sun/Oracle.

JSP-pages

Практически сразу же в голову разработчиков концепции Java-сервлетов пришла еще одна идея. Раз уж мы пишем сервлет, задача которого – это отправка клиенту html-pages, то может правильнее сразу написать эту html-page, а уж если понадобится Howая-то логика на Java, то просто вставлять ее непосредственно в html. Если понятнее не стало, то может поможет фраза: jsp-page – это аналог php-pages. Сложно? Тогда еще поясню. What мы делаем при написании pages на php? У нас идет статический html, а когда нужно вставить всякую логику на php типа циклов и условий, то мы вставляет ее в тело тега <?php … ?>. С jsp все тоже самое, только логика пишется на чистой Java, code которой вставляется в тело тега <% … %>. Еще раз вернемся к понятию сервлета. По сути jsp-page – это и есть сервлет, но записанный несколько иначе. В обычном сервлете мы пишем метод, который выполняет некоторую логику и по ее результатам формирует для клиента html-page. Просто через Howое-то время разработчики сервлетов задумались, а что, если в методе не будет практически ниHowой логики, а будет идти почти одно лишь формирование html-pages, то не проще ли будет писать сразу html-page, в которую делать минимальные вставки Java codeа. Ну и последнее по поводу jsp-страниц. При первом обращении к такой странице она компorруется в сервлет и после этого выполняется. Последующие requestы к этой jsp-странице будут идти быстрее, т.к. она уже будет скомпorрована и ее нужно будет только выполнить.

Контейнер сервлетов

Вот написали мы класс сервлета or jsp-page. What дальше? Как их запихнуть в веб-server, скажем apache, чтобы тот смог их отправить пользовательскому веб-браузеру? Веб-server может посылает только html, а если на нашей странице есть, скажем, php-code, то веб-server сначала пропускает page через интерпретатор, переводящий php в html, и только потом результат отправляется клиенту. С сервлетами происходит примерно тоже самое – перед отправкой их нужно выполнить, чтобы сформировалась html page, а контейнер сервлетов How раз та самая штука, которая отвечает за выполнение сервлетов и codeа jsp-страниц. Т.е. контейнер сервлетов для java - это аналог модуля php-интерпретатора в веб-serverе. Таким образом, когда пользователь в строке веб-браузера вводит address, этот request отправляется веб-serverу, веб-server понимает, что запрашивается сервлет, и передает request контейнеру сервлетов. После этого контейнер сервлетов выполняет сервлет, полученную html-page отправляет веб-serverу, а тот, в свою очередь, возвращает ее клиенту. Может ли контейнер сервлетов работать сам по себе, т.е. без веб-serverа? Такой How Tomcat – определенно может. И если мы хотим создать сайт, у которого не будет ниHowих других html-страниц, кроме How основанных на сервлетах, то контейнера сервлетов нам вполне достаточно. А вот если мы захотим комбинировать сайт из сервлетов и скажем php-страниц, то придется ставить веб-server. Причем не все веб-serverа имеют контейнер сервлетов в своем составе по умолчанию, зато почти все позволяют поставить его в качестве plugin. Поэтому если мы захотим запустить наш сайт на Howом-нибудь хостинге в интернете, где, скорее всего, работает apache, то нам придется поинтересоваться у провайдера, подключен ли контейнер сервлетов.

Java EE

Есть, так называемый, JavaSE (Java Standard Edition). К этому понятию относятся все классы java, для использования которых нам достаточно их просто импортировать (например, java.util.Date) or даже этого делать не надо (например, String, т.к. он располагается в пакете java.lang). А есть Java EE (Java Enterprise Edition). Эти классы тоже принадлежат Sun/Oracle, но разница лишь в том, что их сложнее начать использовать в проекте. Простой строки import… будет недостаточно, т.к. проект компorроваться не будет. Для того чтобы исправить ситуацию, нужно будет найти файл библиотеки javaee.jar и подключить его в проект. Сделать это можно через свойства проекта в среде разработки. Часто говорят, что этот процесс подключения называется – прописать jar-ник в build path or classpath проекта.

Сервер приложений

Теперь представьте, что мы скомпorровали наш проект-сервлет, который использует Java EE. Все замечательно, но нам теперь нужно разместить наши скомпorрованные классы в контейнере сервлетов. Допустим, сделали. Будет ли наше приложение работать. Ответ – нет. При обращении к сервлету полетят исключительные ситуации, что Howие-то классы не найдены. Почему? Потому что компилятор-то мы «обманули», подсунув javaee.jar в classpath, т.е. компилятор увидел, что классы из Java EE на месте и успокоился, а вот контейнер сервлетов этих классов не видит, зато видит ссылки на них из нашего сервлета. Разрешима ли данная ситуация в рамках контейнера сервлетов. Конечно да, нужно просто в контейнере сервлетов в папку с нашим сервлетом добавить файл библиотеки javaee.jar. А теперь представьте, что таких проектов будет много и все они запущены в одном контейнере сервлетов Tomcat. Это значит, что в папку каждого сервлета придется копировать этот файлик jar. Это неудобно и неправильно. Ситуация разрешилась путем ввода понятия serverа applications, в котором этот файлик уже давно лежит в единственном экземпляре, и все сервлеты могут к нему обращаться, а не иметь свою копию. На мой взгляд, очень удобно и логично. Естественно, весь сыр бор не из-за одно jar-file (его я привел для примера) – таких файлов много. Но это не все, что дают нам serverа приложений. Сервера приложений могут сами держать соединения со многими ресурсами, например, с базой данных. При этом наш сервлет может сам такое соединение не открывать, а просто брать его из serverа приложений. В контейнере же сервлетов – это невозможно, т.к. контейнер – это, в определенной степени, урезанный server приложений. В контейнере сервлет должен всегда сам создавать коннекшены к базе. Как-то так… war-архив What такое war-архив? WAR – это web-archive (веб-архив). На самом деле, это просто zip-файл, How и любой jar-ник. По сути, это всего лишь способ, чтобы наш веб-сайт, состоящий из множества веб-страниц, jsp-страниц и классов сервлетов запихать в один файлик формата zip. web.xml web.xml – это, так называемый, дескриптор развертывания. Это файл, в котором тупо описано, Howой request строки веб-браузера на обработку Howому классу-сервлету отправлять, чтобы контейнер сервлетов не запутался, Howой сервлет за что отвечает. В целом, в Java очень модно описывать настройки во всяких xml-fileх, но в последнее время наметилась тенденция ухода от этой традиции. Как, спросите вы? А через аннотации. Классы-аннотации сами ничего не делают, они How раз и созданы только для того, чтобы всякие настройки (мета-данные) описывать не в отдельном xml-файле, а прямо по codeу. Очень удобно. Однако сейчас наблюдается некая промежуточная стадия, когда часть настроек задана annotationми, а часть через xml, и это может запутать, т.к. смотришь xml и видишь одну настройку, а по annotationм стоит другая. Какая из них имеет высший приоритет? Кто знает…

Заключение

Написав сиё, я задумался, что такой беглый обзор никому не поможет, т.к. не содержит ниHowой конкретики и ниHowих примеров, но с другой стороны не стирать же написанное, поэтому пусть будет.