Введение

Это руководство посвящено идентификации сервлетов. Дополнительное руководство о сервлетах находится в разделе Руководство: Сервлет

Идентификация сервлетов

Сервлеты - это классы сервера, взаимодействующие web-клиентами. Они преимущественно идентифицируются от классов управления (см. Руководство: Класс анализа) в архитектурах web. Они могут использоваться для генерации Web-страниц в целях представления, но в общем случае для этого больше подходят страницы JSP (см. Руководство: Страница JSP (Java Server Page)). Их также можно использовать для взаимодействия с базами данных, как в конфигурации развертывания, ориентированной на Web, что описано в разделе Концепция: Конфигурации развертывания J2EE. Также, начиная с J2EE 1.4, сервлеты можно использовать для реализации Web-служб, как это определено в спецификации JAX-RPC.

Однако, для приложений с важной бизнес-логикой, или для приложений, требующих возможностей объектов EJB, более подходит многоуровневая конфигурация развертывания (см. Концепция: Конфигурации развертывания J2EE). В этом случае, обычно применяются сервлеты для координации логики оформления и обеспечения моста к бизнес-логике и данным, предоставленным объектами EJB.

Типичное применение сервлета - это Передний контроллер. Передние контроллеры предоставляют приложению единственную точку входа, что облегчает и унифицирует поддержку защиты, состояния приложения и оформления.   Передний контроллер получает доступ к запросу пользователя, обрабатывает его и определяет подходящий компонент оформления, которому перенаправляется запрос. Более подробная информация находится в разделе Базовые шаблоны проекта J2EE - Передний контроллер ([ALU01]).

Если проект содержит большое количество страниц JSP с похожим управляющим кодом, то стоит создать сервлет для объединения этой логики в одном месте.

Моделирование сервлетов

В RUP сервлеты представляет Рабочий продукт: Класс проекта, и они моделируются как классы. Сервлеты, управляющие запросами HTTP, имеют стереотип <<HTTPServlet>>. Сервлеты, управляющие другими протоколами, имеют стереотип <<GenericServlet>>.

Можно думать о каждом сервлете как о способе предоставления одинакового интерфейса, одной операции, которая обслуживает запросы и обеспечивает стандартную информацию контекста сервлета, сеанса и клиента. Таким образом, моделирование сервлета не касается определения операций интерфейса, но определяет его ответственность и способ его взаимодействия с другими элементами проекта, такими как клиенты, страницы JSP, вспомогательные классы, объекты EJB и так далее.

Конечная точка Web-служб

Как мы видели ранее, сервлет может использоваться для реализации Web-службы и должен удовлетворять следующим требованиям:

• Он должен иметь конструктор типа public по умолчанию.
• Он должен реализовывать все методы, объявленные Интерфейсом конечной точки службы, а его бизнес-методы должны иметь тип public, а не final или static.
• Он должен быть без сохранения состояния.
• Класс должен иметь тип public, но не final, и не abstract.