Читайте также:
|
Контекст
Для web-программиста контекст приложения – это, прежде всего, информация, характеризующая само web-приложение и среду в которой оно работает. Эту информацию можно разделить на две части: статическую и динамическую. Статическая часть описывается в дескрипторе развертывания и в других конфигурационных файлах web-контейнера. Эта информация не чувствительна к перезагрузке сервера. Динамическая часть информации может быть добавлена, изменена или удалена с помощью специальных методов контекста и перезагрузка web-сервера приводит к ее разрушению.
Наиболее часто web-программист сталкивается с необходимостью использовать параметры инициализации (статический элемент контекста) и атрибуты контекста (динамический элемент контекста).
Сеанс связи (сессия)
Протокол HTTP является stat less протоколом, т.е. протоколом, не сохраняющего информацию о своем состоянии. Это означает, что каждый запрос и ответ имеют свой жизненный цикл, никак не связанный с предшествующими им запросами и ответами. Поэтому управление сеансом связи с пользователем является важной и нетривиальной задачей.
Объект Session ( сеанс связиили с ессия) реализует интерфейс HttpSession ислужит для представления пользователя, работающего с клиентской частью web-приложения. Объект сессии создается, как правило, web-контейнером и становится доступным в сервлете или JSP с помощью метода getSession объекта Request.
Время существование сессии зависит от параметра Session timeout, который может быть установлен в дескрипторе развертывания или в конфигурационных файлах сервера и может быть изменено динамически, например, в сервлете. Этот параметр устанавливает максимальное время между запросами одного клиента. Превышение этого значения приводит к удалению объекта Session.
В принципе, объект сессии может разрушить и изнутри, выполнив метод invalidate интерфейса HttpSession.
Во время сеанса связи любой объект, связанный с сеансом связи доступен любому сервлету или JSP, находящемуся в этом же контексте и недоступен для сервлетов и JSP другого контекста. Состояние сеанса позволяют отследить два специальных механизма: cookies и URL rewriting. В первом случае информацию о сессии записывается в специальном файле на компьютере клиента, во втором случае такая же информация записывается непосредственно в URL каждого вызова.
Запрос
При http-запросе информация передается от клиента к серверу в виде http-заголовков и тела сообщения запроса. Web-контейнер получив запрос создает объект типа HttpServletRequest, который затем передается методу service сервлета в качестве параметра или представляется как неявный объект request в JSP.
Объект типа HttpServletRequest инкапсулирует базовый http- запрос и предоставляет методы позволяющие определить тип запроса, используемую кодировку, MIME-тип, ip-адрес клиента, номер порта и т. п., обработать параметры, атрибуты, заголовки, тело сообщения запроса.
Ответ
Ответ – это объект типа HttpServletResponse, который инкапсулирует информацию, передаваемую от сервлета или JSP клиенту. В качестве клиента может выступать, как web-браузер, так и любой другой компонент web-приложения, поддерживающий http-протокол. Объект ответа создается web-контейнером после получения запроса. В сервлет ответ передается в виде второго параметра метода service, а в JSP он представлен в виде неявного объекта response.
Объект Request создается контейнером при получении http-запроса к компоненте web-приложения и инкапсулирует всю необходимую информацию о запросе клиента. Этот объект существует и доступен только в рамках обработчика запроса (в нашем случае сервлета или jsp-страницы).
Объект Response создается контейнером тоже при получении запроса. Методы этого объекта позволяют инкапсулировать всю информацию необходимую контейнеру, для того чтобы сформировать и передать ответ клиенту. Этот объект существует и доступен только в рамках обработчика запроса.
Объект Context создается контейнером при его инициализации на основе дескриптора развертывания приложения. Помимо общего контекста создаются контексты для каждого сервлета и jsp-страницы.
Объект Session создается контейнером при получении первого запроса клиента. Объект существует до тех пор, пока интервал времени между последовательными запросами клиента не превысит установленное пороговое значение. Для обозначения каждой сессии используется специальный уникальный идентификатор, позволяющий разделить запросы разных клиентов.
22. Дескриптор развертывания web-приложения. Параметры инициализации web-приложения: назначение, принципы применения.
Дескриптор развертывания является важной частью web-приложения, предназначенный для хранения его основных параметров.
Дескриптор развертывания приложения представляет собой xml-файл, корневым элементом которого является тег <web-app>. Дескриптор приложения может содержать достаточно много различных и повторяющихся элементов. Порядок элементов внутри <web-app> и их синтаксис определяется схемой XML, с которая, как это видно из параметров тега <web-app>, находится по адресу http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd.
В самом простом случае дескриптор развертывания состоит только из одного тега <web-app>, внутри которого ничего нет. В нашем случае, имеется еще три тега: <display-name>, <welcome-file-list> и <welcome-file>.
Тег <display-name> не является обязательным, но если есть, то не может повторяться более одного раза. Этот тег предназначен для указания имени web-приложения, которое потом может быть использовано в графическом интерфейсе. Для этого имени не требуется уникальность и его значение не оказывает влияния на работу приложения.
Тег <welcome-file-list> тоже не является обязательным и предназначен для указания списка стартовых страниц web-приложения. Имена файлов странниц указываются внутри тега <welcome-file-list> с помощью одного или более тегов <welcome-file>. В нашем примере в качестве стартовой страницы используется файл index.html. В общем случае, может быть указано несколько стартовых страниц для одного web-приложения. В этом случае поиск их осуществляется в указанном порядке. Если ни одного файла не было найдено, сервер возвращает сообщение об ошибке HTTP Status 404. Пусть, например, для вызова приложения ANaive используется адресная строка http://xxx:8080/ANaive, где xxx – разрешаемое символическое имя компьютера. Тогда первой отобразится страница index.html, т.к. именно она указана в списке стартовых страниц дескриптора развертывания. При отсутствии тега <welcome-file-list> (и соответственно тегов <welcome-file>) имена стартовых страниц Tomcat определяет с помощью списка в теге <welcome-file-list> конфигурационного файла Tomcat 6.0/conf/web.xml. На рис.2.8 отображен фрагмент этого файла, содержащий список стартовых страниц.
Дескриптор развертывания web-приложения содержит информацию необходимую web-контейнеру для взаимодействия с приложением. По мере изложения материала сведения о структуре и составе этого файла будут постоянно уточняться и дополняться.
Параметры инициализации могут использоваться для открытия файлов, создания подключений базы данных или выполнения других действий. К этой информации можно обращаться двумя способами:
· Метод init(), объявленный интерфейсом Servlet, принимает объект ServletConfig в качестве его параметра;
· Метод getServletConfig(), объявленный интерфейсом Servlet, возвращает объект ServletConfig.
Манера, в которой параметры инициализации предоставляются сервлету, зависит от сервера. 
Дата добавления: 2015-09-11; просмотров: 97 | Поможем написать вашу работу | Нарушение авторских прав |