Jakarta Servlet: История и Современное Состояние

Введение

Класс языка программирования Jakarta EE

Jakarta Servlet, ранее Java Servlet, — это программный компонент Java, расширяющий возможности сервера. Хотя сервлеты могут обрабатывать различные типы запросов, они чаще всего используются для реализации веб-контейнеров, предназначенных для размещения веб-приложений на веб-серверах, и таким образом являются веб-API сервлетов, работающим на стороне сервера. Такие веб-сервлеты являются аналогом Java для других технологий динамического веб-контента, таких как PHP и ASP.NET.

Введение

Jakarta Servlet – это Java-класс в Jakarta EE, который соответствует Jakarta Servlet API, стандарту для реализации Java-классов, отвечающих на запросы. Сервлеты могут в принципе взаимодействовать по любому протоколу клиент-сервер, но чаще всего они используются с HTTP. В принципе, любой сервлет может расширять класс ; однако, фактически, все сервлеты расширяют класс . Таким образом, "сервлет" часто используется как сокращение для "HTTP-сервлет". Сервлеты могут использоваться для добавления динамического контента на веб-сервер с использованием платформы Java. Создаваемый контент обычно представляет собой HTML, но может быть и другим, например, XML и, чаще всего, JSON. Jakarta Servlet API в некоторой степени был вытеснен двумя стандартными Java-технологиями для веб-сервисов: Jakarta RESTful Web Services (JAX RS 2.0), полезным для AJAX, JSON и REST-сервисов, и Jakarta XML Web Services (JAX WS), полезным для SOAP Web Services. – это объект, который получает запрос и генерирует ответ на его основе. Базовый пакет Servlet определяет Java-объекты для представления запросов и ответов сервлетов, а также объекты для отражения параметров конфигурации сервлета и среды выполнения. API Servlet, содержащийся в иерархии пакетов Java, определяет ожидаемые взаимодействия веб-контейнера и сервлета. Примерно через два месяца после объявлений на конференции первая публичная реализация была доступна на веб-сайте JavaSoft. Это была первая альфа-версия Java Web Server (JWS, тогда известная под кодовым названием Jeeves), которая в конечном итоге была выпущена как продукт 5 июня 1997 года. В своем блоге на java.net ветеран Sun и лидер GlassFish Джим Дрисколл подробно описывает историю технологии сервлетов. Джеймс Гослинг впервые задумался о сервлетах в первые дни Java, но концепция не стала продуктом до декабря 1996 года, когда Sun выпустила JWS. Это было до того, как нынешний Jakarta EE был оформлен в виде спецификации. Спецификация Servlet1 была создана Павни Диванджи во время работы в Sun Microsystems, версия 1.0 была завершена в июне 1997 года. Начиная с версии 2.2, спецификация разрабатывалась в рамках Java Community Process. + История API Servlet Версия API Servlet Дата выпуска Спецификация Платформа Важные изменения Jakarta Servlet 6.0 31 мая 2022 6.0 Jakarta EE 10 Удаление устаревших функций и реализация запрошенных улучшений Jakarta Servlet 5.0 9 октября 2020 5.0 Jakarta EE 9 API перемещен из пакета в Jakarta Servlet 4.0.3 10 сентября 2019 4.0 Jakarta EE 8 Переименован из товарного знака "Java" Java Servlet 4.0 Сентябрь 2017 JSR 369 Java EE 8 HTTP/2 Java Servlet 3.1 Май 2013 JSR 340 Java EE 7 Неблокирующий ввод/вывод, механизм обновления протокола HTTP (WebSocket) Java Servlet 3.0 Декабрь 2009 JSR 315 Java EE 6, Java SE 6 Расширяемость, простота разработки, асинхронный сервлет, безопасность, загрузка файлов Java Servlet 2.5 Сентябрь 2005 JSR 154 Java EE 5, Java SE 5 Требуется Java SE 5, поддержка аннотаций Java Servlet 2.4 Ноябрь 2003 JSR 154 J2EE 1.4, J2SE 1.3 web.xml использует XML Schema Java Servlet 2.3 Август 2001 JSR 53 J2EE 1.3, J2SE 1.2 Добавление фильтра Java Servlet 2.2 Август 1999 JSR 902, JSR 903 J2EE 1.2, J2SE 1.2 Входит в состав J2EE, внедрение независимых веб-приложений в WAR-файлы Java Servlet 2.1 Ноябрь 1998 2.1a Не указана Первая официальная спецификация, добавлены RequestDispatcher, ServletContext Java Servlet 2.0 Декабрь 1997 JDK 1.1 Часть Java Servlet Development Kit 2.0, выпущенная в апреле 1998 года Java Servlet 1.0 Декабрь 1996 Часть Java Servlet Development Kit (JSDK) 1.0, выпущенная в июне 1997 года

A Jakarta Servlet is a Java class in Jakarta EE that conforms to the Jakarta Servlet API, a standard for implementing Java classes that respond to requests. Servlets could in principle communicate over any client–server protocol, but they are most often used with HTTP. In principle, any servlets can extend the class; however, realistically speaking, all servlets extend the class. Thus "servlet" is often used as shorthand for "HTTP servlet". Thus, a servlet can be used to add dynamic content to a web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML and more commonly, JSON. The Jakarta Servlet API has, to some extent, been superseded by two standard Java technologies for web services:
the Jakarta RESTful Web Services (JAX RS 2.0) useful for AJAX, JSON and REST services, and
the Jakarta XML Web Services (JAX WS) useful for SOAP Web Services. A is an object that receives a request and generates a response based on that request. The basic Servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The Servlet API, contained in the Java package hierarchy , defines the expected interactions of the web container and a servlet. About two months after the announcements at the conference, the first public implementation was made available on the JavaSoft website. This was the first alpha of the Java Web Server (JWS; then known by its codename Jeeves) which would eventually be shipped as a product on June 5, 1997. In his blog on java. net, Sun veteran and GlassFish lead Jim Driscoll details the history of servlet technology. James Gosling first thought of servlets in the early days of Java, but the concept did not become a product until December 1996 when Sun shipped JWS. This was before what is now the Jakarta EE was made into a specification. The Servlet1 specification was created by Pavni Diwanji while she worked at Sun Microsystems, with version 1.0 finalized in June 1997. Starting with version 2.2, the specification was developed under the Java Community Process. + Servlet API history Servlet API version Released Specification Platform Important Changes Jakarta Servlet 6.0 May 31, 2022 6.0 Jakarta EE 10 remove deprecated features and implement requested enhancements Jakarta Servlet 5.0 Oct 9, 2020 5.0 Jakarta EE 9 API moved from package to Jakarta Servlet 4.0.3 Sep 10, 2019 4.0 Jakarta EE 8 Renamed from "Java" trademark Java Servlet 4.0 Sep 2017 JSR 369 Java EE 8 HTTP/2 Java Servlet 3.1 May 2013 JSR 340 Java EE 7 Non blocking I/O, HTTP protocol upgrade mechanism (WebSocket) Java Servlet 3.0 December 2009 JSR 315 Java EE 6, Java SE 6 Pluggability, Ease of development, Async Servlet, Security, File Uploading Java Servlet 2.5 September 2005 JSR 154 Java EE 5, Java SE 5 Requires Java SE 5, supports annotation Java Servlet 2.4 November 2003 JSR 154 J2EE 1.4, J2SE 1.3 web. xml uses XML Schema Java Servlet 2.3 August 2001 JSR 53 J2EE 1.3, J2SE 1.2 Addition of Filter Java Servlet 2.2 August 1999 JSR 902, JSR 903 J2EE 1.2, J2SE 1.2 Becomes part of J2EE, introduced independent web applications in war files Java Servlet 2.1 November 1998 2.1a Unspecified First official specification, added RequestDispatcher, ServletContext Java Servlet 2.0 December 1997 JDK 1.1 Part of April 1998 Java Servlet Development Kit 2.0 Java Servlet 1.0 December 1996 Part of June 1997 Java Servlet Development Kit (JSDK) 1.0

Жизненный цикл сервлета

Три метода играют центральную роль в жизненном цикле сервлета. Это init, service и destroy. Они реализованы каждым сервлетом и вызываются сервером в определенные моменты времени. Во время этапа инициализации жизненного цикла сервлета, веб-контейнер инициализирует экземпляр сервлета, вызывая метод init и передавая объект, реализующий интерфейс javax.servlet.ServletConfig. Этот объект конфигурации позволяет сервлету получать доступ к параметрам инициализации в формате "имя-значение" из веб-приложения. После инициализации сервлет может обрабатывать запросы клиентов. Каждый запрос обрабатывается в отдельном потоке. Веб-контейнер вызывает метод service сервлета для каждого запроса. Метод service определяет тип запроса и направляет его в соответствующий метод для обработки. Разработчик сервлета должен предоставить реализацию этих методов. Если запрос поступает на метод, который не реализован сервлетом, вызывается метод родительского класса, что обычно приводит к возврату ошибки клиенту. Наконец, веб-контейнер вызывает метод destroy, выводя сервлет из эксплуатации. Метод destroy, как и init, вызывается только один раз в течение жизненного цикла сервлета. Рассмотрим типичный сценарий использования этих методов. Предположим, пользователь запрашивает URL. Браузер генерирует HTTP-запрос для этого URL и отправляет его на соответствующий сервер. Веб-сервер получает HTTP-запрос и перенаправляет его в контейнер сервлетов. Контейнер сопоставляет запрос с конкретным сервлетом. Сервлет динамически извлекается и загружается в адресное пространство контейнера. Контейнер вызывает метод init сервлета. Этот метод вызывается только при первой загрузке сервлета в память. Можно передать параметры инициализации сервлету для его настройки. Контейнер вызывает метод service сервлета. Этот метод вызывается для обработки HTTP-запроса. Сервлет может считывать данные, переданные в HTTP-запросе, и формировать HTTP-ответ для клиента. Сервлет остается в адресном пространстве контейнера и доступен для обработки любых других HTTP-запросов от клиентов. Метод service вызывается для каждого HTTP-запроса. В какой-то момент контейнер может решить выгрузить сервлет из памяти. Алгоритмы принятия этого решения зависят от конкретного контейнера. Контейнер вызывает метод destroy сервлета, чтобы освободить выделенные для сервлета ресурсы, такие как дескрипторы файлов; важные данные могут быть сохранены в постоянном хранилище. Память, выделенная для сервлета и его объектов, затем может быть освобождена сборщиком мусора.

Three methods are central to the life cycle of a servlet. These are init , service , and destroy They are implemented by every servlet and are invoked at specific times by the server. During initialization stage of the servlet life cycle, the web container initializes the servlet instance by calling the init method, passing an object implementing the javax. servlet. ServletConfig interface. This configuration object allows the servlet to access name value initialization parameters from the web application. After initialization, the servlet instance can service client requests. Each request is serviced in its own separate thread. The web container calls the service method of the servlet for every request. The service method determines the kind of request being made and dispatches it to an appropriate method to handle the request. The developer of the servlet must provide an implementation for these methods. If a request is made for a method that is not implemented by the servlet, the method of the parent class is called, typically resulting in an error being returned to the requester. Finally, the web container calls the destroy method that takes the servlet out of service. The destroy method, like init , is called only once in the lifecycle of a servlet. The following is a typical user scenario of these methods. Assume that a user requests to visit a URL. The browser then generates an HTTP request for this URL. This request is then sent to the appropriate server. The HTTP request is received by the web server and forwarded to the servlet container. The container maps this request to a particular servlet. The servlet is dynamically retrieved and loaded into the address space of the container. The container invokes the init method of the servlet. This method is invoked only when the servlet is first loaded into memory. It is possible to pass initialization parameters to the servlet so that it may configure itself. The container invokes the service method of the servlet. This method is called to process the HTTP request. The servlet may read data that has been provided in the HTTP request. The servlet may also formulate an HTTP response for the client. The servlet remains in the container's address space and is available to process any other HTTP requests received from clients. The service method is called for each HTTP request. The container may, at some point, decide to unload the servlet from its memory. The algorithms by which this decision is made are specific to each container. The container calls the servlet's destroy method to relinquish any resources such as file handles that are allocated for the servlet; important data may be saved to a persistent store. The memory allocated for the servlet and its objects can then be garbage collected.

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

Спецификация технологии Servlet была реализована во многих продуктах. Список реализаций можно найти на странице веб-контейнера. Существуют и другие типы контейнеров сервлетов, например, для SIP-сервлетов, такие как SailFin.