Файл содержит простой HTML с парочкой дополнений. Вот она, прелесть JSP в сочетании с JSTL и JEL. Обратите внимание на то, как легко проверить наличие ошибок валидации, используя такие стандартные теги, как <с:if> и .

Атрибут формы регистрации action указывает на следующий URL: ${pageContext.request.contextPath}/processcustomer . Это значит, что каждый раз, когда клиент пытается зарегистрироваться, данные будут отправляться в processcustomer независимо от URL, по которому доступна форма. Это достигается за счёт функциональности объектов, доступных из JSP-файла, таких как request .

Скоро мы увидим, как сервлет связывается с URL processcustomer и как он взаимодействует с введёнными данными. А пока давайте посмотрим на JSP-файл, который отвечает за страницу приветствия:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Спасибо за регистрацию!

Ваши введённые данные:

Имя: ${firstname}

Фамилия: ${lastname}

Email: ${email}

Теперь, когда мы разобрались с отображением страниц, следующим шагом будет создание сервлета, ответственного за сбор данных клиента из POST-запросов и подтверждение данных простым способом.

Пишем контроллер

Написать сервлет, способный получить данные из формы регистрации, проще простого. Всё, что нам нужно сделать, - это написать подкласс для класса HttpServlet и реализовать его методы doGet() или doPost() (или оба, если надо). В данном случае сервлет будет взаимодействовать с данными, поступающими из POST-запросов.

Вот как он выглядит:

@WebServlet(name = "CustomerController", urlPatterns = "/processcustomer") public class CustomerController extends HttpServlet { @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { RequestCustomer customer = RequestCustomer.fromRequestParameters(request); customer.setAsRequestAttributes(request); List violations = customer.validate(); if (!violations.isEmpty()) { request.setAttribute("violations", violations); } String url = determineUrl(violations); request.getRequestDispatcher(url).forward(request, response); } private String determineUrl(List violations) { if (!violations.isEmpty()) { return "/"; } else { return "/WEB-INF/views/customerinfo.jsp"; } } private static class RequestCustomer { private final String firstName; private final String lastName; private final String email; private RequestCustomer(String firstName, String lastName, String email) { this.firstName = firstName; this.lastName = lastName; this.email = email; } public static RequestCustomer fromRequestParameters(HttpServletRequest request) { return new RequestCustomer(request.getParameter("firstname"), request.getParameter("lastname"), request.getParameter("email")); } public void setAsRequestAttributes(HttpServletRequest request) { request.setAttribute("firstname", firstName); request.setAttribute("lastname", lastName); request.setAttribute("email", email); } public List validate() { List violations = new ArrayList<>(); if (!StringValidator.validate(firstName)) { violations.add("Имя является обязательным полем"); } if (!StringValidator.validate(lastName)) { violations.add("Фамилия является обязательным полем"); } if (!EmailValidator.validate(email)) { violations.add("Email должен быть правильно сформирован"); } return violations; } } }

Первое, на что здесь стоит обратить внимание, - использование аннотации @WebServlet(name ="CustomerController", urlPatterns = "/processcustomer") . Она говорит контейнеру сервлета использовать класс CustomerController для обработки HTTP-запросов по адресу /processcustomer . Того же эффекта можно достичь путём добавления директив сопоставления сервлетов в web.xml , как , но так как мы используем Servlet Specification 3.1 нам нет необходимости прибегать к такому способу.

Здесь мы назвали сервлет CustomerController , так как считается хорошей практикой использовать имя класса сервлета в качестве значения атрибута name аннотации @WebServlet . В противном случае некоторые контейнеры не смогут выполнить сопоставление, что приведёт к ошибке 404.

Сам класс CustomerController выполняет несколько простых задач. Во-первых, он собирает введённые в форму данные, используя реализацию интерфейса HttpServletRequest , который содержит значения, соответствующие полям firstname , lastname и email формы. Затем он устанавливает эти значения в качестве атрибутов запроса, поэтому их можно повторно отобразить либо в форме, либо на странице с результатами. Наконец, валидаторы проверяют правильность введённых данных.

Валидаторы - это простые классы, которые проверяют определённые свойства, например, является ли строка пустой и выглядит ли email как email. На GitLab автора можно посмотреть на их реализацию.

Результат валидации влияет на дальнейший ход событий: если данные не валидны, клиент перенаправляется через объект RequestDispatcher на страницу регистрации, где отображаются соответствующие ошибки. Если всё в порядке, то отображается страница приветствия.

Итак, мы создали целое веб-приложение на Java, которое позволяет зарегистрировать клиентов с помощью HTML-формы, базового сервлета и нескольких JSP-файлов. Пора его запустить.

Запускаем приложение

Для запуска приложения нужно проделать следующие шаги:

IntelliJ IDEA). Когда вы развернёте проект и запустите его, должен запуститься бразуер по умолчанию с окном регистрации.

Заключение

Итак, вы приобрели все навыки, необходимые для создания собственного веб-приложения на Java без необходимости прибегать к сложным фреймворкам. Всё, что вам нужно, - Servlet API , технология вроде JSP для отображения и встроенные средства Java. Здорово, правда?

Стоит отметить, что реализация класса CustomerController подчеркивает достоинства и недостатки сервлетов: с одной стороны, он вкратце показывает, насколько легко обрабатывать параметры запроса и отправлять ответы клиенту в разных форматах. Но эта функциональность имеет свою цену: обе реализации интерфейсов HttpServletResponse и HttpServletResponse являются обычными локаторами служб. Нельзя сказать, что это плохо, поскольку локаторы просто содержат данные. Однако нужно помнить, что эти реализации будут всегда привязаны к сервлету.

Сервлет - это Java-nporpaMMa, которая в качестве своего суперкласса использует класс HttpServiet. Сервлет используется для того, чтобы расширить возможности существующего сервера, в частности, Web-сервера. Как правило, сервлет работает на специальном сервере. Такие серверы носят название серверов Java-приложений (Java Application Server). В состав сервера Java-приложений в качестве составного блока входит Web-сервер (иногда не один, а несколько), а также серверы, работающие с серверными компонентами, серверы вспомогательных служб и т. п. Сервлет работает в окружении, которое предоставляет ему сервер. Часть сервера, предназначенная для работы с сервлетами, называется контейнером сервлетов. Спецификация сервле- тов предполагает наличие в классе сервлета стандартных методов, выполнение которых происходит на том или ином этапе жизненного цикла сервлета. Вызов этих методов осуществляется контейнером сервлетов. Имплементация спецификации сервлетов входит в набор стандартных пакетов языка Java.

В данной книге рассматривается сервер Java-приложений под названием Blazix. Сервер Blazix предоставляет полный набор возможностей для работы с сервлетами. Помимо создания класса (или классов) сервлета, а также для конфигурирования созданной программы-сервлета, установления ее на сервер, необходимо изменить файл конфигурации Web-сервера. Основные значения указываются в файле конфигурации в следующем виде: servlet.name: myservlet

servlet.myservlet.className: mypackage.MyServletClass servlet.myservlet.url: /mysrvlet

У каждого сервлета должно быть задано имя (servlet.name), по которому он идентифицируется на сервере. Это имя используется для задания свойств сервлета, в частности, для указания имени класса, в котором хранится программа сервлета (следующая строка), а также адреса, по которому происходит обращение к этому сервлету (третья строка).

Клиент запрашивает у Web-сервера адрес, по которому расположен сервлет (адрес должен быть указан в качестве значения servlet.myservlet.url в файле конфигурации Web-сервера). Сервер передает запрос и данные (если они есть) сервлету, получает ответ от сервлета и направляет его клиенту.

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

Особенно важно иметь в виду, что путь к классу сервлета должен быть указан в переменной ciasspath или же его можно поместить в каталог C:\Blazix\classes или в каталог, который указан в файле конфигурации Web- сервера в качестве значения server.ciassDir. После того как файл конфигурации был изменен и в него вставлена информация о новом сервлете, сервер должен быть остановлен и запущен вновь. Сервлет может быть размещен и на работающем сервере при помощи утилиты администрирования, но для этого сервлет должен быть упакован в файл Web-архива WAR. Если файл класса сервлета был изменен, то останавливать сервер и запускать его вновь необязательно. По умолчанию сервер сконфигурирован так, что вызов сервлета по адресу http://localhost:81/_reload приводит к тому, что все классы будут перезагружены и измененный класс сервлета станет доступен для клиентских запросов (рис. 4.1). Посетите эту страницу после того, как будет изменен файл класса сервлета. Остановка сервера попросту не нужна.

Если читатель уже имел некоторый опыт работы с сервлетами, то он оценит ту простоту, которая свойственна серверу Blazix в сравнении с другими Java- серверами, например, с сервером Tomcat.

Чтобы сразу приступить к делу, рассмотрим простой пример, сервлет some- Servlet (листинг 4.1).

Листинг 4.1. Сервлет SomeServlet.java I

import java.io.*; import javax.servlet.*; import javax.servlet.http.*;

public class SomeServlet extends HttpServlet { public void doGet(HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException { Printwriter out = response.getWriter(); out.println("Hello World");

В файле конфигурации Web-сервера запишем следующее:

servlet.name: first

servlet.first.className: SomeServlet

servlet.first.url: /dofirst

Тогда обращение к сервлету из браузера примет вид http://localhost:81 /dofirst (рис. 4.2).

Сервлеты Java предоставляют платформонезависимый метод создания Web- приложений (это не бесспорно, однако мы не будем рассматривать этот вопрос глубже, поскольку тогда нам потребуется определиться с тем, что понимать под Web-приложением, что не входит в перечень рассматриваемых тем), причем многие приложения отличаются быстротой в работе и лишены тех ограничений, которые имеются у CGI-приложений. Сервлет работает под управлением Web-сервера и, в отличие от апплета, не требует графического интерфейса пользователя. Сервлет взаимодействует с сервером, обмениваясь с ним запросами и ответами. Клиентская программа обращается к серверу с запросами. Запрос обрабатывается сервером, передается сервлету, сервлет посылает ответ через сервер клиенту. На сегодняшний день сервлеты весьма популярны при создании интерактивных Web-приложений. Существует множество Web-серверов, способных работать с сервлетами, среди них такие серверы, как Tomcat, iPlanet Web Server (ранее Netscape

Enterprise Server), Blazix. J Builder Enterprise использует сервер Borland Enterprise Server (BES), входящий в состав пакета, а также поддерживает работу с серверами Web Logic, WebSphere и iPlanet. J Builder Enterprise Server включает в себя сервер Tomcat, который используется "по умолчанию".

Рис. 4.2. Обращение к сервлету

Одним важным преимуществом сервлетов является скорость их работы. В отличие от приложений CGI сервлеты загружаются в память лишь один раз и затем выполняются непосредственно из памяти. Сервлеты по существу являются многопоточными приложениями. К тому же они платформонеза- висимы, поскольку написаны на языке Java.

Технология JSP, которой посвящена глава 3, является расширением технологии сервлетов, в JSP особое внимание уделяется работе с HTML- и XML- документами. В составе HTML- и XML-кода JSP-фрагменты находят свое наиболее частое применение. Как сделать выбор и решить, что использовать: сервлеты или серверные страницы? Сервлеты более подходят для решения задач низкоуровневого программирования и менее приспособлены для решения задач создания логики представления приложения. Серверные страницы JSP, наоборот, в основном сконцентрированы на том, как представить результат пользователю в наиболее удобном виде. Серверные страницы создаются встроенными в HTML-код, используя стиль создания HTML-документов. Технология JSP предоставляет гораздо более богатые возможности, чем простой HTML. Страницы JSP могут предоставлять возможности реализации логики приложений с использованием простых компонентов Java, а также серверных компонентов EJB, путем создания пользовательских библиотек ярлыков. Сами по себе серверные страницы Java могут являться модульными, многократно используемыми компонентами, работающими с логикой представления, которые можно использовать совместно с различными шаблонами и фильтрами. JSP-страницы преобразуются в сервлеты, поэтому теоретически можно пользоваться исключительно сервлетами. Однако технология JSP создана для того, чтобы упростить процесс создания Web-документов, отделив логику представления приложения от содержания документа. В большинстве случаев отправляемый клиенту ответ состоит как из шаблонов представления документа, так и из данных, которые генерируются автоматически, заполняя шаблон. В таких ситуациях оказывается много легче работать с JSP, чем с сервлетами.

Servlet - это java-программа, которая выполняется на серверной стороне Web-приложения. Точно так же, как апплеты динамически расширяют функциональные возможности Web-браузера, сервлеты динамически расширяют функциональные возможности Web-сервера.

Работу servlet "а можно описать следующим образом: при приходе запроса от клиента Web-сервер с помощью специального конфигурационного файла может определить, какой сервлет необходимо выполнить. После этого Web-сервер запускает JVM, которая в свою очередь выполняет сервлет. Servlet обрабатывает запрос и передает содержимое Web-серверу (возможно в виде HTML-страницы). Web-сервер отправляет клиенту ответ (сформированную сервлетом HTML-страницу).

WEB-сервер по сути является неким контейнером, который загружает servlet "ы, выполняет их, и, получив от них результат, отправляет его клиенту.

Servlet в архитектуре Web-приложения

Из-за своей мощности и гибкости, servlet "ы могут играть значительную роль в архитектуре системы. Они могут выполнять прикладные задачи, предназначенные для промежуточного уровня, работать как прокси-сервер для клиента и даже улучшать функциональность промежуточного уровня, добавляя поддержку новых протоколов и других функций. Промежуточный уровень выполняет функции сервера приложений в так называемой трехуровневой системе клиент-сервер и расположен между "легковесным" клиентом, таким как Web-браузер, и источником данных.

Servlet как прокси-сервер

Для поддержки апплетов сервлеты могут выполнять функции их прокси-серверов. Это может быть важно, поскольку система безопасности Java позволяет апплетам соединяться только с сервером, с которого они были загружены. Если апплет нуждается в соединении с сервером баз данных, расположенном на другой машине, servlet может создать это соединение для апплета.

Временные и постоянные servlet "ы

Сервлеты могут запускаться и останавливаться для каждого клиентского запроса. Также они могут запускаться при старте Web-сервера и существовать до его остановки. Временные servlet "ы загружаются по требованию и предлагают хороший способ сохранения ресурсов сервера для редко используемых функций. Постоянные сервлеты загружаются при старте Web-сервера и существуют до его остановки. Сервлеты устанавливаются как постоянные расширения для сервера в том случае, если затраты по их запуску очень велики (например, установка соединения с базой данных), если они предлагают постоянную функциональность на стороне сервера (например, служба RMI), или в случаях, когда они должны отвечать на запросы клиента как можно быстрее. Не существует специального кода для назначения servlet "а постоянным или временным; это функция настройки Web-сервера.

Жизненный цикл сервлета, javax.servlet.Servlet

Сервлеты выполняются на платформе Web-сервера как часть того же процесса, что и сам Web-сервер. Web-сервер отвечает за инициализацию, вызов и уничтожение каждого экземпляра сервлета. Web-сервер взаимодействует с сервлетом через простой интерфейс: javax.servlet.Servlet .

Интерфейс javax.servlet.Servlet включает три главных методов:

• init()
• service()
• destroy()

и два вспомогательных методов:

• getServletConfig()
• getServletInfo()

Сходство между интерфейсами servlet "а и апплета Java очевидны. Именно так и было спроектировано! Java сервлеты являются для Web-серверов тем же самым, чем являются апплеты для Web-браузеров. Апплет выполняется в Web-браузере, выполняя действия по его запросу через специальный интерфейс. Сервлет делает то же самое, работая на Web-сервере.

Инициализация сервлета, метод init()

При первой загрузке сервлета вызывается метод init(). Это дает возможность сервлету выполнить любую работу по установке, например, открытие файлов или установку соединений с их серверами. Если сервлет установлен на сервере постоянно, он загружается при запуске сервера. В противном случае сервер активизирует сервлет при получении первого запроса от клиента на выполнение услуги, обеспечиваемой этим сервлетом.

Гарантируется, что метод init() закончится перед любым другим обращением к сервлету – таким как, например, вызов метода service() . Обратите внимание, что init() будет вызван только один раз; он не будет вызываться до тех пор, пока сервлет не будет выгружен и затем загружен сервером снова.

Метод init() принимает один аргумент – ссылку на объект ServletConfig , который содержит аргументы для инициализации сервлета. Этот объект имеет метод getServletContext() , возвращающий объект ServletContext , который содержит информацию об окружении сервлета.

Ядро сервлета, метод service()

Метод service() является сердцем сервлета. Каждый запрос от клиента приводит к одному вызову метода service() . Этот метод читает запрос и формирует ответное сообщение при помощи своих двух аргументов ServletRequest и ServletResponse:

Таким образом, существуют два способа передачи информации от клиента к сервлету. Первый – через передачу значений в параметрах запроса. Значения параметров могут быть вставлены в URL. Второй способ передачи информации от клиента к сервлету осуществляется через InputStream (или Reader).

Работа метода service() по существу проста – он создает ответ на каждый клиентский запрос, переданный ему с сервера. Однако необходимо помнить, что могут существовать несколько параллельных запросов, обрабатываемых в одно и то же время. Если метод service() требует каких-либо внешних ресурсов, таких как файлы, базы данных, то необходимо гарантировать, чтобы доступ к ресурсам являлся потокозащищенным.

Выгрузка сервлета, метод destroy()

Метод destroy() вызывается для освобождения всех ресурсов (например, открытые файлы и соединения с базой данных) перед выгрузкой сервлета. Этот метод может быть пустым, если нет необходимости выполнения каких-либо завершающих операций. Перед вызовом метода destroy() сервер ждет либо завершения всех обслуживающих операций, либо истечения определенного времени. Это означает, что метод destroy() может быть вызван во время выполнения какого-либо продолжительного метода service() .

Важно оформить метод destroy() таким образом, чтобы избежать закрытия необходимых ресурсов до тех пор, пока все вызовы service() не завершатся.

Конфигурация сервлета, метод getServletConfig()

Метод getServletConfig() возвращает ссылку на объект, который реализует интерфейс ServletConfig . Данный объект предоставляет доступ к информации о конфигурации сервлета, т.е. доступ к параметрам инициализации сервлета и объекту контектса сервлета ServletContext , который дает доступ к сервлету и его окружению.

Информация о сервлете, метод getServletInfo()

Метод getServletInfo() определяется программистом, создающим сервлет, для возврата строки, содержащую информацию о сервлете, например: автор и версия сервлета.

Интерфейс ServletRequest

ServletRequest предоставляет клиентскую информацию о параметрах HTTP запроса сервлету, т.е. обеспечивает данные включая название параметра и значения, атрибуты, и входной поток. Эта информация передается в метод service() .

Следующий servlet пример показывает, как получить информацию из параметра request метода service() :

BufferedReader reader; String param1; String param2; public void service(ServletRequest request, ServletResponse response) { reader = request.getReader(); param1 = request.getParameter("First"); param2 = request.getParameter("Second"); }

Дополнительная информация о запросе доступна сервлету через методы, основные из которых приведены в следующей таблице:

Интерфейс ServletResponse

Интерфейс ServletResponse - это инструмент для отправки данных клиенту. Все методы данного инструмента служат именно для решения этой задачи:

Public java.lang.String getCharacterEncoding() public void setLocale(java.util.Locale loc) public java.util.Locale getLocale()

Первый метод возвращает MIME тип кодировки (к примеру - UTF8), в которой будет выдаваться информация. Вторые два метода тоже работают с charset. Они указывают на язык используемый в документе (например - русский).

Public ServletOutputStream getOutputStream() throws java.io.IOException

Метод getOutputStream возвращает поток вывода данных для сервлета. Этот поток используется, к примеру, для вывода бинарных файлов. Текстовые данные можно выводить с помощью java.io.Writer:

Public java.io.PrintWriter getWriter() throws java.io.IOException

Метод getWriter() автоматически конвертирует строки в тот charset, что указан в методе getCharacterEncoding() и getLocale().

Public void setContentLength(int len)

Методом setContentLength устанавливается значение поля HTTP заголовка "Content-Length"

Public void setContentType(String type)

Метод setContentType используется для отправки MIME типа содержимого документа. Поле HTTP заголовка "Content-Type".

Поток вывода данных является буфферизованным. Это означает, что порция данных будет выдана клиенту только после заполнения буфера.

Public void setBufferSize(int size) public int getBufferSize() public void flushBuffer() throws java.io.IOException public void resetBuffer()

Приведенные выше 4 метода позволяют, соответственно, установить размер буффера отправки, получить его размер, инициализировать отправку содержимое буффера клиенту, не дожидаясь его заполнения, а так же очистить этот буффер от данных.

Public boolean isCommitted()

Методом isCommitted можно получить флаг, начата ли уже отправка данных клиенту. Флаг будет положительным, если HTTP заголовок ответа был уже отправлен.

Public void reset()

Если HTTP заголовок ещё не отправлен, то метод reset "сбрасывает" HTTP заголовок к значениям "по умолчанию".

Диаграммы JFreeChart в сервлетах

Графическая библиотека JFreeChart может быть использована в сервлетах для создания диаграмм и их отображения на страницах сайтов в виде изображений. Подробности описания и примеры использования JFreeChart в сервлетах представлены .

Сервлет с графической библиотекой Chart.js

JNI в сервлете

В ряде случаев может потребоваться использование JNI в WEB-приложении. Пример использования JNI в сервлетах представлен .

JMS сообщения в сервлете

Сервлет может быть использован для обмена JMS сообщениями между приложениями. Пример использования сервлета для отправки и чтения JMS сообщений в контейнере JBoss представлен .

Что такое сервлеты? Сервлеты, фактически, это модули обработки HTTP и FTP запросов, используемые для построения порталов (web gates).

Основой этих порталов является собственно WEB сервер - программа, которая держит сокет сервера, принимает и передаёт данные. Чаще всего, для ускорения работы, сервер бывает написан не на Java, а на каком-либо другом языке программирования (например на C++).

В связке с сервером работает базовый сервлет. Именно ему отправляет сервер данные и от него же получает ответ, отправляемый клиенту. Фактически, базовый сервлет является "мозгом" сервера. Основная функция этого сервлета - прочитать запрос клиента, расшифровать его и, в соответствиии с расшифровкой, передать работу сервлету, отвечающему за этот тип запрашиваемой информации. Зачастую, для достижения скорости, роль базового сервлета играет сам сервер. Именно по такой схеме работает, скажем, Jacarta Tomcat.

На рисунке изображена схема передачи вызовов (request) и ответов (response) между сервером и сервлетами. Данная схема изображает работу HTTP сервера, который имеет несколько JSP страниц и два ресурса "/sample1" и "/sample2", за обработку которых отвечает два сервлета - "Sample1 Servlet" и "Sample2 Servlet" соответственно.

Разберём пошагово то, что изображено на рисунке:

1. клиент подсоединяется к серверу
2. сервер передаёт запрос (request) базовому сервлету ("Basic Servlet")
3. базовый сервлет вычеленяет из запроса URI ресурса
   • если URI указывает на "/sample1", то запрос целиком (без изменений) передаётся сервлету "Sample1 Servlet", который, в дальнейшем, и обрабатывает этот запрос
   • если URI указывает на "/sample2", сервер передаёт запрос сервлету "Sample2 Servlet"
   • во всех остальных случаях запрос передаётся модулю "JSP Servlet"
4. сервлет, которому было передано управление, обрабатывает данные, создаёт ответ (response), после чего ответ отсылается обратно базовому сервлету.
5. базовый сервлет, не обрабатывая полученные данные, тут же пересылает их обратно серверу
6. сервер выдаёт данные клиенту

Таким образом достигается разбиение задачи обработки запроса на логические части, за каждую из которых отвечает свой модуль, свой "програмный кирпичик". На самом деле, ступеней в обработке запроса может быть гораздо больше. К примеру за методы "GET" и "POST" могут отвечать разные модули.

Интерфейс Servlet

Объединяет все эти модули то, что они сквозным образом связанны между собою с помощью интерфейса javax.servlet.Servlet

Посмотрим на этот интерфейс. В нём указано всего 5 методов:

Public void init(ServletConfig config) throws ServletException Этот метод вызывается, чтобы проинформировать сервлет о том, что он включён как модуль для обслуживания запросов клиента. Параметр config разделяет интерфейс javax.servlet.ServletConfig, несущий информацию об окружении сервера, имени сервлета, начальных параметрах и прочих плюшках. Об интерфейсе javax.servlet.ServletConfig будет рассказано чуть далее. Предполагается, что после вызова этой функции, сервлет аккуратно сохранит этот config у себя в переменной и будет выдавать его с помощью другого метода: public ServletConfig getServletConfig() Получив системную информацию с помощью "getServletConfig()", сервер может захотеть узнать имя автора, дату создания, прочую информацию о сервлете, что и достигается вызовом public String getServletInfo()

Чтобы обработать запрос и получить результат его обработки, используется функция

Public void service(ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException В этой функции коду, который будет обрабатывать данные, передаются два инструмента: один - для получения данных от сервера, другой - для отправки результата работы сервлета. Соответственно это параметры request и response, разделяющие интерфейсы javax.servlet.ServletRequest и javax.servlet.ServletResponse Вся работа с данными ведётся именно через эти интерфейсы, так что далее поговорим о них подробнее.

После того, как сервер перестал нуждаться в этом модуле вызывается метод

Public void destroy() который и завершает все операции с объектом сервлета.

Интерфейс ServletConfig

4 метода, имена которых говорят сами за себя, составляют суть интерфейса javax.servlet.ServletConfig:

Public String getServletName() public ServletContext getServletContext() public String getInitParameter(String name) public java.util.Enumeration getInitParameterNames()

Думаю, назначение всех функция понятно, кроме

Public ServletContext getServletContext() Этот метод возвращает ссылку на очень полезный инструмент для работы с сервером:

Интерфейс ServletContext

ServletContext - интерфейс, определяющий доступ к следующим полезнейшим функциям:

Public Object getAttribute(String name) public java.util.Enumeration getAttributeNames() public void setAttribute(String name, Object object) public void removeAttribute(String name) Четыре метода для работы с аттрибутами. Роль аттрибутов выполняет любой объект любого класса. Цель данных функций - пересылать между несвязанными друг с другом сервлетами разные объекты. public String getInitParameter(String name) public java.util.Enumeration getInitParameterNames() Доступ к параметрам, с которыми был запущен сервер. Тут же могут лежать имя хоста, порт и прочие полезности. public int getMajorVersion() public int getMinorVersion() Возвращает версии Servlet API. public String getMimeType(String file) Возвращает MIME тип ассоциированный с файлом, путь до которого указан в переменной file. Вспомните, как пришлось определять MIME в программе SimpleWEBServer и оцените удобство! public java.util.Set getResourcePaths() public java.net.URL getResource(String path) throws java.net.MalformedURLException public InputStream getResourceAsStream(String path) Возвращает пути к доступным для сервера ресурсам и сами ресурсы в виде URL и в виде потоков данных. public RequestDispatcher getRequestDispatcher(path) public RequestDispatcher getNamedDispatcher(name) RequestDispatcher - это инструмент для того, чтобы переслать запрос другому ресурсу. Эти функции нужны, чтобы получить объект этого инструмента для указанных ресурсов. То бишь, скажем, для того, чтобы перенаправить запрос сервлету "sample1" из тела сервлета, можно сделать так: getServletConfig().getServletContext().getNamedDispatcher("sample1").forward(request, response);

Собственно класс RequestDispatcher включает в себя лишь два метода:

Public void forward(ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException public void include(ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException Причём первый - для перенаправления запроса, а второй - для включения результата работы вызываемого сервлета в результат работы текущего. К примеру, сервлет 1 печатает слово "test 1", потом вызывает include для сервлета два, после чего печатает слово "test 2". Сервлет 2 же просто печатает слово " and ". Результатом работы сервлета 1 будет строка "test 1 and test 2". public void log(String msg) Записать что-то в лог сервера. public void log(String message, Throwable throwable) Определить исключение и фразу, которая будет записываться в лог по получении этого исключения. public String getRealPath(String path) Переводит путь типа "/index.html" в "http://host/contextPath/index.html" public String getServerInfo() Возвращает имя сервера. public ServletContext getContext(String uripath) Этот метод позволяет обмениваться ServletContext между разными ресурсами одного и того же сервера. public String getServletContextName() Возвращает имя сервлета, которому принадлежит данный объект интерфейса ServletContect.

Интерфейс ServletRequest

Интерфейс ServletRequest - это инструмент для получения параметров HTTP запроса. Этот интерфейс имеет некоторые методы, идентичные по названию и назначению с ServletContext:

Public Object getAttribute(String name) public java.util.Enumeration getAttributeNames() public void setAttribute(String name, Object o) public void removeAttribute(java.lang.String name) public String getServerName() public RequestDispatcher getRequestDispatcher(String path)

Оставшися методы позволяют с удобством работать с HTTP заголовком запроса:

Public String getCharacterEncoding() public void setCharacterEncoding(String env) throws java.io.UnsupportedEncodingException Работа с кодировкой символов в полях HTTP заголовка. Функции задают метод расшифровки CGI запросов из формы %NN в обычные символы. К примеру, какой стандарт - KOI8-R, windows-1251 или UTF-8 нужно применить для расшифровки кириллических символов. public int getContentLength() public String getContentType() Читает поля "Content-Length", "Content-Type" из HTTP запроса. public jString getParameter(String name) public java.util.Enumeration getParameterNames() public String getParameterValues(String name) public java.util.Map getParameterMap() Функции для получения поля из HTTP заголовка и его значения. public ServletInputStream getInputStream() throws java.io.IOException public java.io.BufferedReader getReader() throws java.io.IOException Получить входящий поток данных или его "читатель". Reader применяется для чтения текстовой информации - он автоматически расшифрует строки в соответствии с заданным charset. Внимание! В версии J2EE 1.3 имеется существенный баг: при расшифровке символа %25 (символ % в Post и Get запросах) Reader выдаёт ошибку (баг замечен на серверах Tomcat 4 и Resign). Возможно, что схожий баг есть и с другими символами. public String getProtocol() Получить версию HTTP протокола запроса (к примеру - "HTTP/1.1"). public String getScheme() Возвращяет имя схемы запроса. Например "http", "https", или "ftp". public int getServerPort() public String getRemoteAddr() public String getRemoteHost() public boolean isSecure() Порт сервера, IP адрес клиента, имя хоста клиента и является ли соединение скретным (по протоколу HTTPS) public java.util.Locale getLocale() public java.util.Enumeration getLocales() Предпочитаемый клиентом язык документа (результат обработки поля "Accept-Language")

Интерфейс ServletResponse

Интерфейс ServletResponse - это инструмент для отправки данных клиенту. Все методы данного инструмента служат именно этой цели:

Public java.lang.String getCharacterEncoding() public void setLocale(java.util.Locale loc) public java.util.Locale getLocale() Первый метод возвращает MIME тип кодировки (к примеру - UTF8), в которой будет выдаваться информация. Вторые два метода тоже работают с charset. Они указывают на язык используемый в документе (например - русский). public ServletOutputStream getOutputStream() throws java.io.IOException Возвращает поток вывода данных для сервлета. Этот поток используется, к примеру, для вывода бинарных файлов. Текстовые данные можно выводить с помощью java.io.Writer: public java.io.PrintWriter getWriter() throws java.io.IOException Этот метод автоматически конвертирует строки в тот charset, что указан в методе getCharacterEncoding() и getLocale(). public void setContentLength(int len) Этим методом устанавливается значение поля HTTP заголовка "Content-Length" public void setContentType(String type) Метод для отправки MIME типа содержимого документа. Поле HTTP заголовка "Content-Type". public void setBufferSize(int size) public int getBufferSize() public void flushBuffer() throws java.io.IOException public void resetBuffer() Дело в том, что поток вывода данных является буфферизованным. Это означает, что следующая порция данных будет выдана клиенту только после заполнения буфера. Указанные методы позволяют, соответственно, установить размер буффера отправки, получить его размер, инициализировать отправку содержимое буффера клиенту, не дожидаясь его заполнения, а так же очистить этот буффер от данных. public boolean isCommitted() Этим методом можно получить флаг, начата ли уже отправка данных клиенту. Флаг будет положительным, если HTTP заголовок ответа был уже отправлен. public void reset() Если HTTP заголовок ещё не отправлен, то этот метод "сбрасывает" HTTP заголовок к значениям "по умолчанию".

Предопределённые типы сервлетов

Java Servlet API, кроме собственно интерфейсов, так же содержит несколько классов сервлетов, которые могут служить основой для ваших программ.

Базовым для всех этих классов является абстрактный класс javax.servlet.GenericServlet:

Public abstract class GenericServlet implements Servlet, ServletConfig, java.io.Serializable

Как видно из определения этого класса, он имеет все методы интерфейсов Servlet и ServletConfig. Не реализованным методом остался только

Public abstract void service(ServletRequest req, ServletResponse res) throws ServletException, java.io.IOException который и был объявлен абстрактным.

На базе этого класса был создан другой абстрактный класс - javax.servlet.http.HttpServlet:

Public abstract class HttpServlet extends GenericServlet implements java.io.Serializable

Создан этот класс был в соответствии с концепцией "ещё больше удобств для программиста" и имеет много полезных методов:

Protected void doDelete(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doHead(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doOptions(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doPut(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void doTrace(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException protected void service(ServletRequest req, ServletResponse res) throws ServletException, java.io.IOException Различные варианты service(ServletRequest req, ServletResponse res) для разных HTTP методов от DELETE и GET до PUT и TRACE. А чтобы с удобством получать данные по CGI интерфейсу не расшифровывывая заголовок были созданы классы HttpServletRequest и HttpServletResponse, входящие вместе с HttpServlet в пакет javax.servlet.http protected long getLastModified(HttpServletRequest req) Этот метод возвращает время последней модификации объекта HttpServletRequest. Значение времени он берёт из поля "Date" HTTP заголовка запроса. Если же поле не обнаружено, то возвращает -1.

Соответственно разберём и интерфейсы HttpServletRequest и HttpServletResponse. Они являются наследниками соответственно ServletRequest и ServletResponse.

HttpServletRequest помимо методов, унаследованных от ServletRequest, имеет так же следующие полезнейшие методы:

Cookie getCookies() Возвращает набор куков, пересланных клиентом серверу.

Класс Cookie, входящий в тот же пакет javax.servlet.http, содержит всю возможную информацию о куке. Важнейшими методами этого класса являются

Int getMaxAge() String getName() String getValue() выдающие, соответственно, сколько ещё времени этому куку осталось жить, имя кука и его значение. Так же Cookie(String name, String value) void setValue(String newValue) void setMaxAge(int expiry) для создания кука, установки его значения и максимального возраста. long getDateHeader(String name) Возвращает дату из HTTP заголовка, если таковая есть. int getIntHeader(java.lang.String name) Возвращает численное значения поля с именем name из HTTP заголовка запроса String getMethod() Возвращает метод HTTP запроса. String getQueryString() String getRequestURI() StringBuffer getRequestURL() Возвращает строку, содержащуюся в URL документа после символа "?", URI документа и полный URL. HttpSession getSession() HttpSession getSession(boolean create) boolean isRequestedSessionIdFromCookie() boolean isRequestedSessionIdFromURL() boolean isRequestedSessionIdValid() Функции. позволяющие работать с таким важнейшим механизмом передачи данных, как сессии.

Сессии необходимы для того, чтобы таскать за пользователем данные из страницы в страницу. К примеру, пользователь заходит на страницу (1), где ему отправляются некоторые данные для страницы (2), а та сохраняет ещё какие-то вещи для страницы (3).

Впринципе, на странице (1) можно выслать данные пользователю, потом получить их на странице (2), добавить что-то, выслать пользователю... Подобным образом придётся постоянно пересылать весь набор данных от клиента серверу и обратно, причём много раз. Кроме того, что такая пересылка не всегда удобна, она ещё и пожирает траффик.

Можно так же поступить иначе - использовать механизм сессий. Механизм этот работает следующим образом: данные, присланные пользователем, сервер сохраняет в отдельном файле - файле сессии. С содержимым этого файла и будет производиться вся работа по изменению данных. Клиенту же выдаётся "ключ сессии" (он же Session key, он же Sesseion ID) - уникальный указатель на файл, содержащий данные конкретно для этого пользователя. Теперь для того, чтобы получить все данные, касающиеся этого клиента, серверу необходимо знать лишь ключ сессии. Достоинством этого метода является удобство и скорость его использования.

Вот и все основные методы интерфейса HttpServletRequest. Полный список методов читайте в документации к Java Servlet API.

Теперь об интерфейсе HttpServletRequest. Основное отличие классов, разделяющих данный интерфес, в том, что данные выводятся не сразу. Вначале происходит компановка всех данных в HTTP ответ. Ответ отправляется только после завершения работы HttpServlet.service().

И так, о методах:

Void addHeader(String name, String value) void addIntHeader(String name, int value) void addDateHeader(String name, long date) Методы добавляют в HTTP заголовок параметры. Последний метод устанавливает параметр "Date". void addCookie(Cookie cookie) Метод добавляет cookie в заголовок boolean containsHeader(String name) Позволяет узнать, содержит ли уже заголовок указанный параметр. String encodeURL(String url) String encodeRedirectURL(String url) Первый метод кодирует символы с помощью замены %NN. Второй метод делает то же самое и вызывает void sendRedirect(String location) void setStatus(int sc) void sendError(int sc) void sendError(int sc, String msg) Первый - устанавливает код возврата, вторые два - посылают сообщение об ошибке. В интерфейсе заданы следующие возможные ошибки для параметра sc, соответствующие кодам возврата протокола HTTP: SC_CONTINUE - Status code (100) SC_SWITCHING_PROTOCOLS - Status code (101) SC_OK - Status code (200) SC_CREATED - Status code (201) SC_ACCEPTED - Status code (202) SC_NON_AUTHORITATIVE_INFORMATION - Status code (203) SC_NO_CONTENT - Status code (204) SC_RESET_CONTENT - Status code (205) SC_PARTIAL_CONTENT - Status code (206) SC_MULTIPLE_CHOICES - Status code (300) SC_MOVED_PERMANENTLY - Status code (301) SC_MOVED_TEMPORARILY - Status code (302) SC_SEE_OTHER - Status code (303) SC_NOT_MODIFIED - Status code (304) SC_USE_PROXY - Status code (305) SC_BAD_REQUEST - Status code (400) SC_UNAUTHORIZED - Status code (401) SC_PAYMENT_REQUIRED - Status code (402) SC_FORBIDDEN - Status code (403) SC_NOT_FOUND - Status code (404) SC_METHOD_NOT_ALLOWED - Status code (405) SC_NOT_ACCEPTABLE - Status code (406) SC_PROXY_AUTHENTICATION_REQUIRED - Status code (407) SC_REQUEST_TIMEOUT - Status code (408) SC_CONFLICT - Status code (409) SC_GONE - Status code (410) SC_LENGTH_REQUIRED - Status code (411) SC_PRECONDITION_FAILED - Status code (412) SC_REQUEST_ENTITY_TOO_LARGE - Status code (413) SC_REQUEST_URI_TOO_LONG - Status code (414) SC_UNSUPPORTED_MEDIA_TYPE - Status code (415) SC_REQUESTED_RANGE_NOT_SATISFIABLE - Status code (416) SC_EXPECTATION_FAILED - Status code (417) SC_INTERNAL_SERVER_ERROR - Status code (500) SC_NOT_IMPLEMENTED - Status code (501) SC_BAD_GATEWAY - Status code (502) SC_SERVICE_UNAVAILABLE - Status code (503) SC_GATEWAY_TIMEOUT - Status code (504) SC_HTTP_VERSION_NOT_SUPPORTED - Status code (505)

Вот и всё, что можно рассказать о HttpServletResponse

Использование сервлетов в WEB приложениях

Поговорим теперь об использовании сервлетов в WEB приложениях. Для этого я приведу два полезных примера, которые могут на практике пригодиться.

Первый пример показывает методы работы с HttpServlet и вывод содержимого HTML страницы в сжатом виде. По идее, HTML страница в ответе браузера выводится прямым текстом, но, чтобы сократить объём пересылаемых данных, можно использовать сжатие GZIP. Современные браузеры (по крайней мере браузеры 4 поколения и выше) поддерживают такой метод пересылки текстовой информации и выведут страницу так, как будто бы её и не сжимали.

Второй пример показывает, как средствами сервлета можно осуществить непрерывный вывод страницы. Такой тип вывода страниц может использоваться, например, в чатах: чтобы прочитать новые сообщения, не нужно будет каждый раз обновлять страницу, новые сообщения будут просто со временем докачиваться. Нужно учесть, что некоторые прокси-серверы не поддерживают такой вид пересылки данных, но с этим - увы - ничего сделать нельзя.

Осталось сказать, что механизм сервлетов очень пластичен и позволяет творить такие вещи, которые могли бы потребовать написания отдельного WEB сервера (как, например, в случае сервлета докачки). Минусом работы сервлетов является низкая скорость первого запуска (сервлет просто компилируется JIT машиной), высокое поребление памяти и недостаток всех программ на Java - низкая скорость работы со строками. Последнее обстоятельство становится заметно при работе сервлетов, принимающих текстовые данные в POST запросах. POST запрос в HttpServlet размером в 50 кб при парсинге с помощью HttpServletRequest.getReader() может на пару минут парализавать работу сервера. То же относится и к другим программам на java.

Приведу два небольших примера:

Если взять небольшие строки - до 2-3 кб, то отличия в работе примеров несущественны, если же взять строку text размером хотя бы в 10 кб, то в первом случае программа будет работать со строкой значительно медленнее. Это является особенностью java и является проблемой реализации функций класса String. Так что если вы хотите написать быстрый сервлет, избегайте работу с длинными строками посредством класса String, используйте, к примеру, класс StringBuffer. Это предупреждение относится прежде всего к получению больших текстов из сети и к обработке локальных файлов (к примеру, в случае текстовой базы данных для гостевой книги при большом количестве сообщений).

Ещё одна проблема касается мультизадачности WEB системы. Не забывайте, что ваш сервлет могут одновременно запросить сразу несколько пользователей. Часто возникают проблемы синхронизации данных, обмену сведениями между разными вычислительными потоками одного и того же сервлета, а самая часто встречающаяся проблема - это проблема синхронного доступа к файлам и другим именованым ресурсам системы. К примеру, одна программа открыла файл на чтение, а другая тем временем пытается туда что-то писать. В результате вторая программа либо получает исключение, либо ждёт, пока файл освободится для записи. В связи с этим хочу обратить ваше внимание: не оставляйте за собою незакрытых потоков и закрывайте потоки, как только в них отпала необходимость. Поток, конечно, закроется позже автоматически, но это произойдёт только тогда, когда "мусорщик" до него доберётся, а меж тем вторая программа всё так же не будет иметь доступа к файлу на запись.

Дополнительно к мультизадачности хочу отметить, что с помощью методов "Object getAttribute(String name)" и "void setAttribute(String name, Object object)" интерфейса ServletContext вы можете обмениваться между сервлетами данными, в том числе и синхронизирующими.