Архитектура Web-приложений

Стр 1 из 7Следующая ⇒

Xx (успешно)

Xx (переадресация)

4xx (ошибка запроса)

5xx (ошибка сервера)

Каждое HTTP-сообщение состоит из трёх частей:

· Стартовая строка — определяет тип сообщения;

· Заголовки — характеризуют тело сообщения, параметры передачи и прочие сведения;

· Тело сообщения — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

Метод URI HTTP/Версия протокола

Пример запроса:

GET /web-programming/index.html HTTP/1.1

Стартовая строка ответа сервера имеет следующий формат:

HTTP/Версия КодСостояния [Пояснение]

Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:

HTTP/1.1 200 Ok

http://www.4stud.info/web-programming/protocol-http.html

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.

HTTPS (Hypertext Transfer Protocol Secure) — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

2. HTML. Структура HTML-страницы. Каскадные таблицы стилей (CSS). Модель DOM.

HTML (от англ. Hypertext Markup Language — «язык разметки гипертекста») — это стандартный язык разметки документов во Всемирной паутине. Практически все веб-страницы создаются при помощи HTML.

CSS (англ. Cascading Style Sheets — каскадные таблицы стилей) — формальный язык описания внешнего вида документа, написанного с использованием языка разметки. Преимущественно используется как средство описания, оформления внешнего вида веб-страниц, написанных с помощью языков разметки HTML и XHTML, но может также применяться к любым XML-документам, например, к SVG или XUL.

Регистр, в котором набрано имя элемента и имена атрибутов, в HTML значения не имеет (в отличие от XHTML). Элементы могут быть вложенными. Например, следующий код:

<!DOCTYPE html>

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<link rel="stylesheet" type="text/css" href="mysite.css">

<title>HTML Document</title>

</head>

<body>

Этот текст будет полужирным,

а этот - ещё и курсивным

</body>

</html>

DOM (от англ. Document Object Model — «объектная модель документа») — это не зависящий от платформы и языка программный интерфейс, позволяющий программам и скриптам получить доступ к содержимому HTML, XHTML и XML-документов, а также изменять содержимое, структуру и оформление таких документов.

Модель DOM не накладывает ограничений на структуру документа. Любой документ известной структуры с помощью DOM может быть представлен в виде дерева узлов, каждый узел которого представляет собой элемент, атрибут, текстовый, графический или любой другой объект. Узлы связаны между собой отношениями «родительский-дочерний».

Подробнее: https://ru.wikipedia.org/wiki/Document_Object_Model

3. JavaScript. Основные стандарты. Типы данных. Программные структуры. Принцип применения. Понятие DHTML.

JavaScript — объектно-ориентированный скриптовый язык программирования. Является диалектом языка ECMAScript.

JavaScript обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам.

Основные архитектурные черты: динамическая типизация, слабая типизация, автоматическое управление памятью, прототипное программирование, функции как объекты первого класса.

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

Стандарт языка:

По инициативе компании Netscape^[17]^[18] была проведена стандартизация языка ассоциацией ECMA. Стандартизированная версия имеет название ECMAScript, описывается стандартом ECMA-262. Первой версии спецификации соответствовал JavaScript версии 1.1, а также языки JScript и ScriptEasy^[7]^[13].

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

С его помощью можно динамически управлять отображением и содержимым HTML-документов. Можно записывать в отображаемый на экран документ произвольный HTML-код в процессе синтаксического анализа загруженного браузером документа. С помощью объекта Document можно генерировать документы "с нуля" в зависимости от предыдущих действий пользователя или каких-либо иных факторов.

Есть 5 «примитивных» типов: number, string, boolean, null, undefined и 6-й тип – объекты object.

DHTML — это способ (подход) создания интерактивного веб-сайта, использующий сочетание статичного языка разметки HTML, встраиваемого (и выполняемого на стороне клиента) скриптового языка JavaScript, CSS (каскадных таблиц стилей) и DOM (объектной модели документа).

4. Методология Ajax. Структура Ajax-приложения, принципы разработки и применения.

Ajax – технология для взаимодействия с сервером без перезагрузки страниц.

Методология Ajax описывает способы разработки страниц сайта, которые могут динамически изменяться на основе данных поступающих с сервера, но без полной перезагрузки страницы.

В основе методологии Ajax лежат следующие технологии: язык HTML, язык JavaScript, язык XML, модель DOM, протокол HTTP, протокол JSON, объект XMLHttpRequest.

HTML –гипертекстовый язык разметки. Интерпретируется браузером. В Ajax динамически изменяется содержимое html-документа.

JavaScript – скриптовый язык, предназначенный для создания сценариев поведения браузера. Интерпретируется браузером. В Ajax html-документ динамически изменяется на стороне клиента с помощью сценариев написанных на языке JavaScript.

DOM – объектная модель, позволяющая сценариям JavaScript получить доступ (читать и изменять содержимое) к элементам html-документа (к атрибутам и содержимому тегов). В Ajax ответ сервера “встраивается” с помощью JavaScript-сценария в загруженную ранее браузером страницу. При этом доступ к элементам html-документа осуществляется а соответствии с моделью DOM.

HTTP – сетевой протокол передачи гипертекста. Используется для обмена данными между двумя приложениями (клиентом и сервером). В Ajax обмен данными между JavaScript-сценарием на клиенте и серверным приложением (например, сервлетом) осуществляется по правилам HTTP.

XML – расширяемый язык разметки данных. Предназначен для структуризации данных с целью хранения или/и передачи. В Ajax язык XML является одним из форматов, который используется для структуризации данных пересылаемых между JavaScript-сценарием и серверным приложением.

JSON ( JavaScript Object Notation ) - текстовый формат обмена данными, применяемый обычно в сценариях JavaScript. В Ajax формат JSON является одним из форматов, который используется для структуризации данных пересылаемых между JavaScript-сценарием и серверным приложением. Формат JSON основывается на функции eval () языка JavaScript.

XMLHttpRequest – специальный API (предопределенный объект), используемый в языке JavaScript для обмена данными между сценарием на JavaScript и серверным приложением по протоколу HTTP. В Ajax методы объекта XMLHttpRequest используется для отправки и получения данных между JavaScript-сценарием и серверным приложением. Данные могут получены в виде XML-документа и виде обыкновенного текста (в частном случае могут быть представлены в формате JSON).

5. Web-приложение. Архитектура web-приложения. Особенности реализации web-приложения. Web-сервер и web-клиент

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

Архитектура Web-приложений

Все Web-приложения можно условно разбить на три составные части: серверная часть, клиентское приложение и интерфейс.

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

Клиентское приложение (браузер) последовательно запрашивает страницы с сервера, используя Dynamic HTML для управления интерфейсом и частичной обработки информации на компьютере клиента.

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

Другая серьезная проблема в разработке Web-приложения -отслеживание сессии конкретного пользователя. Дело в том, что по определению HTTP-протокол не имеет понятия текущего состояния (stateless), т.е. очередной запрос страницы абсолютно не зависит от предыдущих запросов и потому не требует уникального идентификатора. Для отслеживания последовательных запросов и идентификации пользователя используются так называемые cookies.

6. Спецификация Java Platform Enterprise Edition (Java EE). Состав технологий. Понятие Application Server (сервер приложений).

Java Platform, Enterprise Edition, сокращенно Java EE — набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий.

В основе технологии Java EE лежит четыре основных документа:

- Java EE Platform Specification (спецификация платформы Java EE);

- Java EE Reference Implementation (образцовые реализации платформы Java EE);

- Java EE Blueprints (модель приложений Java EE);

- Java Compatibility Test Suite (набор тестов на совместимость платформы Java EE).

Спецификация Java EE Platform определяет компонентную структуру Java EE-приложения и содержит минимальный набор свойств, которыми должен обладать сервер приложений (Application server), поддерживающий эту платформу. Сервер приложений – это сервер, умеющий исполнять прикладные программы, специальным образом установленные на нем. Если говорят о Java EE-сервере приложений (далее просто Java EE-сервер), то подразумевается, что он соответствует некоторой версии спецификации Java EE и может исполнять Java EE-приложения. Существует достаточно много различных Java EE-серверов: Sun GlassFish Enterprise Server (ранее Sun Java System Application Sever), IBM WebSphere Application Server, Oracle Application Sever, JBOSS, BEA WebLogic и т. д. Важным является, то что, если любые два сервера приложений соответствуют спецификации Java EE Platform, то любое Java EE-приложение которое может быть исполнено на одном сервере без перекомпиляции может быть исполнено и на другом (с учетом соответствия версий спецификаций). Разница может заключаться только в процедурах установки и настройки приложения. При этом приложение остается нейтральным относительно программно-аппаратной среды, в которой работает сервер приложений.

Составной частью любого сервера приложений является web-сервер (его часто называют web-контейнером). В некоторых случаях это может быть отдельный продукт, который встраивается в сервер приложений (например, в JBOSS используется web-сервер Apache Tomcat), в других случаях web-сервер может являться неотделимой составной частью сервера приложений (например, GlassFish) или вообще могут использоваться, как несколько различных web-серверов, так и собственный встроенный (WebSphere).

Образцовые реализации платформы Java EE – это практические указания по разработке программных продуктов соответствующих спецификации этой платформы, а также сами действующие программные продукты, которые могут быть использованы в качестве образца. Компания Sun Microsystems Inc. предлагает в качестве образцовой реализации платформы Java EE свой продукт – сервер приложений Sun GlassFish Enterprise Server, который поддерживает весь спектр технологий, описанных в спецификации Java EE. С помощью этого модельного сервера, разработчики серверов приложений могут проверить переносимость приложений между собственной реализаций сервера и образцовой реализацией, а разработчики Java EE-приложений для разработки прототипов приложений.

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

Набор тестов на совместимость платформы Java EE, предназначен, в основном, для разработчиков серверов приложений, реализующих платформу Java EE. С помощью, предложенных здесь тестов, можно проверить, разработанный продукт на соответствие спецификациям (иногда говорят стандартам) платформы Java EE. Перечень программных продуктов, успешно прошедших проверку на наборе тестов и получивших от Sun Microsystems Inc. сертификат соответствия публикуются на сайте компании.

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

В этом пособии, рассматривается только некоторая часть технологий, входящий в состав платформы Java EE, которые применяются для разработки web-приложений. Основными web-технологиями являются технологии JavaServlet (технология сервлетов) и Java ServerPages.

Сервер приложений (англ. application server ) — это программная платформа (software framework), предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (Интерфейс прикладного программирования), который определен самой платформой.

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

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

Примеры реализации

· Под сервером приложений в случае Java EE подразумевается комплекс программ, реализующих концепцию Java EE и позволяющих запускать в себе Java EE приложения. К классу серверов приложений относятся такие продукты как Sun GlassFish, IBM WebSphere, RedHat JBoss Application Server, Apple WebObjects (англ.) и др.

· Zope, развитый сервер web-приложений.

· Терминальные серверы, например поставляемые компанией Citrix

7. Java EE: спецификация Servlet, назначение, основные возможности, принципы применения. Структура Servlet. Жизненный цикл Servlet.

Сервлет – это web-компонент, расположенный в серверной части web-приложения.(Сервлет должен расширять класс HttpServlet и реализовать интерфейс Servlet)

Сервлеты выполняются в специальной среде – контейнере сервлетов, который является составной частью web-контейнера.

Среда, в которой может работать web-контейнер определяется его спецификацией – обычно это web-сервер или сервер приложений.

Все сервлеты должны реализовать интерфейс javax.servlet.Servlet (далее просто Servlet). Этот интерфейс предполагает три основных метода (реализация их представлена на рис. 3.1) и два вспомогательных, которые будут рассмотрены ниже.

Метод init вызывается сервером при инициализации сервлета. Этот метод позволяет программисту выполнить некоторые действия перед началом работы сервлета. В качестве параметра метод получает объект, реализующий интерфейс ServletConfig. Методы этого интерфейса реализуются сервером, они позволяют сервлету получить информацию о своей конфигурации.

Метод destroy тоже вызывается сервером, но при его выгрузке. Этот метод используется разработчиком сервлета для выполнения действий, связанных с окончанием работы, – освобождение ресурсов, закрытие соединений с сервером базы данных и т. п.

Метод service предназначен для обработки запроса клиента. Метод вызывается сервером при получении запроса клиента на вызов сервлета. Сервер формирует два параметра. Первый реализует интерфейс HTTPServletRequest и используется для того, чтобы получить информацию о http-запросе. Второй параметр, реализующий интерфейс HTTPServletResponse, дает возможность сервлету формировать http-ответ клиенту. В данном примере в функции service используется вызов метода getMethod интерфейса HTTPServletRequest. Функция getMethod позволяет определить тип http-запроса (get, post, put, delete, options и т. д.).

import java.io.IOException; // исключения ввода/вывода

import javax.servlet.*; // интерфейсы и классы общего типа

import javax.servlet.http.*; // расширение javax.servlet для http

public class Sss extends HttpServlet implements Servlet {

public Sss() {

super();

System.out.println("Sss:constructor");

}

public void init(ServletConfig sc) throws ServletException {

// инициализация сервлета

super.init();

System.out.println("Sss:init");

}

public void destroy() {

// перед уничтожением сервлета

super.destroy();

System.out.println("Sss:destroy");

}

Sss:constructor

Sss:init

Sss:service:GET

----------------------после первого вызова

Sss:service:GET

----------------------после второго вызова

Sss:destroy

----------------------после остановки веб-сервера

В спецификации Java Servlet предусмотрена следующая функцио-

нальность сервлета:

1) прием и чтение данных, посылаемых клиентом в качестве запроса;

2) получение любой информации о запросе (свойства запроса, имя хоста-отправителя, свойства браузера и т. п.);

3) генерация и форматирование ответа на запрос; установка необходимых параметров ответа;

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

5) отсылка сформированного ответа клиенту.

8. Java EE: спецификация Java Server Page (JSP), назначение, основные возможности, принципы применения. Структура JSP. Компоненты JSP. Жизненный цикл JSP.

Технология Java Server Pages ( JSP ) предназначена для создания специальной серверной компоненты web-приложения, называемой jsp-страницей и обладающей одновременно свойствам html-страницы и сервлета. В самом первом приближении jsp-страница – это html-странница с вкраплениями java-кода. Как и в случае с сервлетом для исполнения jsp-страницы требуется специальный контейнер (JSP Engine), который отвечает за разбор (parsing) страницы JSP и преобразование ее в сервлет, генерирующий при исполнении html-код.

Директивы JSP

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

<% @ директива имя_атрибута_1= “значение” имя_атрибута_2= “значение” … %>

Существует три типа директив: page, taglib и include.

<%@ page language=”java” contentType=”text/html; charset=ISO-8859-1” %>

Директива page определяет свойства страницы JSP. Значение атрибута language директивы page определяет язык (в примере – Java ) используемый в скриплетах (фрагментах программного когда), в выражениях или других включаемых файлах. Значение атрибута contentType устанавливает MIME-тип ответа и кодировку страницы.

Директива taglib, указывает на то, что в странице JSP будут использоваться библиотеки тегов. В связи с тем, что разработка и применение библиотеки тегов будет рассматриваться отдельно, отложим детальное описание этой директивы до соответствующего раздела главы.

Директива include позволяет вставлять текст и код в процессе трансляции jsp-страницы. На рис. 4.4 приведен пример jsp-страницы (пусть для определенности это страница с именем jsp - directives . jsp) с директивой include. Директива здесь используется для вставки одного файла с инструкциями JavaScript (далее js-файл) и двух html-файлов.

Объявления JSP

Тег JSP применяемый для объявлений имеет следующий синтаксис:

<% ! декларации переменных | декларация методов %>

Объявления не производят никакого вывода в выходной поток. Переменные и методы, декларированные в объявлениях становятся доступными для скриплетов и других объявлений в момент инициализации страницы JSP.

Выражения JSP

Тег JSP применяемый для выражений имеет следующий синтаксис:

<% = исполняемое выражение на языке скрипта %>

Выражение в jsp-странице – это исполняемое выражение, написанное на языке скрипта, указанного атрибутом language в директиве page (в нашем случае это язык Java). Результат выражения автоматически приводится к типу String и выводится в стандартный поток. Если выражение не может быть преобразовано к типу String, то возникает ошибка выполнения.

Скриплеты JSP

Скриплеты должны содержать фрагменты кода на языке скрипта, который указывается в атрибуте language директивы page (в нашем случае это язык Java).

Тег JSP применяемый для скриплетов имеет следующий синтаксис:

<% скрипт на языке Java %>

<%@ page language="java"

contentType="text/html; charset=ISO-8859-1" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html;

charset=ISO-8859-1">

<title>IS&T-2009 </title>

</head>

<body>

<h2>JSP-directives</h2>

</body>

</html>

9. Java EE: библиотека JSP-тегов, компоненты, назначение и основные возможности.

Библиотеки тегов

С точки зрения разработчика web-приложения библиотека тегов (Tag Library) – это технология позволяющая создавать собственные теги (будем их далее называть tdl-тегами), которые потом можно использовать в jsp-страницах.

Для того чтобы воспользоваться этой технологией необходимо выполнить следующее:

1) создать дескриптор библиотеки тегов (Tag library descriptor, TDL) и поместить его в директорий приложения;

2) создать обработчики тегов (Tag handler) – java-классы, генерирующие html-текст, замещающий tdl-теги, в выходном потоке jsp-страницы;

3) поместить на jsp-странице директиву taglib, указывающую на месторасположение дескриптора библиотеки тегов и задающую префикс (пространство имен) для имен tdl-тегов в данной странице;

4) добавить tdl-теги в jsp-страницу.

Изложенная здесь технология библиотеки тегов соответствует спецификации JSP 1.2. На сегодняшний день существует более поздняя версия – JSP 2.0.

Дескриптор библиотеки тегов

Дескриптор библиотеки тегов представляет собой текстовый файл, выполненный в формате XML. Он содержит описание библиотеки тегов и элементов библиотеки.

Тег <taglib> открывает описание библиотеки, которое располагается до закрывающего тега </taglib>. Описание библиотеки состоит из пролога и описаний tld-тегов библиотеки.

Пролог содержит теги <taglib-version> для установки версии пользовательской библиотеки (в нашем случае установлена версия 1.0), <jsp-version> для указания применяемой спецификации JSP (в примере 1.2), <short-name> для символического обозначения (наименования) библиотеки (в примере – StaffTag) и <uri>, содержащего идентификатор ресурса библиотеки тегов (в примере – StaffTag.tld).

Описание каждого tld-тега библиотеки начинается с тега <tag> и заканчивается закрывающим тегом </tag>. В примере приводится описание двух различных тегов.

Для первого tld-тега с именем surname (указывается элементом name), используется класс-обработчик с именем stafftag . Surname . class (значение элемента tag-class). Этот tld-тег не содержит тела (значение EMPTY элемента body-content), но имеет один необязательный (значение false элемента required) атрибут с именем value (значение элемента name) строкового типа (значение java . lang . String элемента type).

Второй tld-тег с именем dossier допускает использование тела и имеет один обязательный атрибут action тоже строкового типа.

Если необходимо описать несколько атрибутов для tld-тега, то внутри тега <tag> необходимо поместить несколько тегов <attribute> с соответствующим описанием.

Контекст

Объект Context (контекст web-приложения) – структура, хранящая информацию о самом web-приложении, его компонентах и среде, в котором оно работает.

Для 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 создается контейнером при получении первого запроса клиента. Объект существует до тех пор, пока интервал времени между последовательными запросами клиента не превысит установленное пороговое значение. Для обозначения каждой сессии используется специальный уникальный идентификатор, позволяющий разделить запросы разных клиентов.

12. Java EE: дескриптор развертывания web-приложения. Параметры инициализации web-приложения: назначение, принципы применения.

Дескриптор развертывания является важной частью web-приложения, предназначенный для хранения его основных параметров.

Дескриптор развертывания приложения представляет собой xml-файл, корневым элементом которого является тег <web-app>. Дескриптор приложения может содержать достаточно много различных и повторяющихся элементов. Порядок элементов внутри <web-app> и их синтаксис определяется схемой XML, с которая, как это видно из параметров тега <web-app>, находится по адресу http :// java . sun . com / xml / ns / j 2 ee / 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.

Манера, в которой параметры инициализации предоставляются сервлету, зависит от сервера.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

version="2.5">

<display-name>ANaive</display-name>

<welcome-file-list>

<welcome-file>index.html</welcome-file>

</welcome-file-list>

<servlet>

<servlet-name>Hhh</servlet-name>

<servlet-class>Hhh</servlet-class>

<init-param>

<param-name>fhtml</param-name>

<param-value>male.html</param-value>

</init-param>

</servlet>

</web-app>

Получить значение параметра инициализации в сервлете можно с помощью метода getInitParameter интерфейса Servlet. На рис. 3.35 приведен фрагмент сервлета, считывающего значение параметра fhtml.

public class Hhh extends HttpServlet implements Servlet {

IsPostBack – это

1. Перешли по адресу сайта. Это GET запрос. Сейчас IsPostBack = false.

2. На загрузившейся страничке нажали какую-нибудь кнопку (input, button). На сервер посылается POST запрос c данными всех элементов упарвления. Сейчас IsPostBack = true. А этот запрос и называется PostBack.

Используется в основном для того чтобы выполнить какие-то действия при первой загрузке страницы и не выполнять их при нажатии на кнопки.

Пример:

private void Page_Load(){ if (!IsPostBack) { // Валидация не выполняется при первоначальном запросе страницы. Validate(); }}

17. ASP.NET: web-форма, структура и жизненный цикл web-формы, основные события web-формы, состояние (viewstate) web-формы, автоматическая обратная отправка данных.

Web-форма: часть web-приложения

Web-форма: интерпретируется сервером; результат интерпретации: html и js-код.

Жизненный цикл:

1)Инициализация структуры страницы

На этом этапе ASP.NET создает страницу. Генерируются все элементы управления, определенные в дескрипторах внутри веб-страницы .aspx. Более того, если страница запрашивается не впервые (иначе говоря, если это обратная отправка), ASP.NET десериализирует информацию о состоянии представления и применяет ее ко всем элементам управления. На этом этапе запускается событие Page.Init.

2) Инициализация кода пользователя

На этом этапе запускается событие Page.Load. Большинство веб-страниц обрабатывают это событие для выполнения любой необходимой инициализации, подобной заполнению динамических текстовых полей или конфигурирования элементов управления.

Событие Page.Load запускается всегда, независимо от того, запрашивается страница впервые или же как часть обратной отправки. К счастью, ASP.NET позволяет программистам различать события первой загрузки страницы и все последующие загрузки. Определить текущее состояние страницы можно, проверив ее свойство IsPostBack, которое при первом запросе страницы будет иметь значение false.

3) Обработка событий

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

События, требующие немедленного ответа. К числу таких событий относится щелчок на кнопке отправки формы (Submit) или на какой-то другой кнопке, области изображения или ссылке в многофункциональном веб-элементе управления, который инициирует обратную отправку данных вызовом JavaScript-функции __doPostBack().

События изменения. К числу таких событий относится изменение выбора в элементе управления или текста в текстовом поле. Эти события запускаются для веб-элементов управления немедленно, если свойство AutoPostBack установлено в true. В противном случае они запускаются при следующей обратной отправке страницы.

4) Очистка

В конце своего жизненного цикла страница преобразуется в HTML-разметку. После этого начинается реальная очистка и запускается событие Page.Unload. В этот момент объекты страницы все еще доступны, но окончательная HTML-разметка уже сгенерирована и не может быть изменена.

Вспомните, что у .NET Framework имеется служба сборки мусора, периодически запускаемая для освобождения памяти, занятой объектами, на которые уже нет ссылок. Неуправляемые ресурсы должны освобождаться явно на этапе очистки или, что лучше, перед ним. Когда сборщик мусора уничтожает страницу, запускается событие Page.Disposed. На этом жизненный цикл веб-страницы завершен.

Autopostback – автоматическая отправка состояния элемента управления на сервер.

Состояние серверных компонентов хранится прямо на странице в скрытом поле ViewState.

Можно отключить ViewState на уровне страницы, поставив в теге Page атрибут EnableViewState="false". Тогда скрытое поле ViewState вообще исчезнет со страницы, а все контролы перестанут хранить данные о своем состоянии.

Viewstate делает следующее:

 Сохраняет данные элементов управления по ключу, как хэш-таблица

 Отслеживает изменения состояния серверных компонент

 Сериализирует и десериализирует сохраненные данные в скрытое поле на клиенте

 Автоматически восстанавливает данные на postback'ах

Web.config — это файл, определяющий параметры для ASP.NET web-приложения. По сути, файл web.config — это XML-документ. В нем хранится информация о параметрах поставщиков состояний сеансов, членства, определяются ссылки на страницы ошибок. Также web.config содержит строки соединения с базами данных, средства управления трассировкой.

<asp:Button ID="Button1" runat="server" Text="Button" />

Обратите внимание на атрибут runat="server". Он означает то же, что и для формы: элемент управления, для которого использован такой атрибут, становится доступным из программного кода в файле codebehind, а на события этого элемента управления реагирует сервер. Если этот атрибут убрать (а также, возможно, избавиться от атрибутов, которые допустимы только для серверных элементов управления), элемент управления станет обычным элементом управления HTML.

18. ASP.NET: публикация ASP.NET-приложения, структура и параметры узла IIS, реальный и виртуальный каталоги, процедура настройки web-узла.

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

Html-элементы управления

Это классы, в которых содержатся стандартные HTML-элементы. За исключением атрибута runat="server" объявление серверных элементов управления HTML ничем не отличается от объявления других элементов управления.

ScriptManager

Все элементы управления ASP.NET AJAX нуждаются в ScriptManager. Если их разместить на странице, которая не содержит ScriptManager, работать они не будут и приведут к генерации исключения InvalidOperationException.

UpdatePanel

UpdatePanel - удобный элемент управления, который позволяет взять обычную страницу с серверной логикой и обеспечить ее обновление в лишенном мерцания стиле Ajax.

Структура проекта MVC 4

Справа в окне Solution Explorer (Обозреватель решений) мы можем увидеть структуру проекта MVC 4. Тот, кто раньше работал с предыдущими версиями MVC, заметит некоторые отличия. Итак, пройдемся по папкам и файлам проекта.

App_Data

В этой папке хранятся все необходимые файлы и ресурсы, например, базы данных, используемые приложением. После развертывания приложения только непосредственно приложение может работать с этой папкой, доступ же простых пользователей в эту папку запрещен.

Файл Global.asax и папка App_Start

В mvc 4 была добавлена папка App_Start. Она включает весь функционал конфигурации приложения, который в предыдущих версиях содержался в файле Global.asax, а теперь перенесен в набор статичных классов, вызываемых в Global.asax. Эти статичные классы содержат некоторую логику инициализации приложения, выполняющуюся при запуске.

Файл Web.config

Файл конфигурации приложения, который находится в корневой папке приложения

Content

Содержит некоторые вспомогательные файлы, которые не включают код на c# или javascript, и которые развертываются вместе с приложением. В частности, здесь могут размещаться файлы стилей css. Так, в этой папке вы увидите файл Site.css, который содержит стили приложения, а также папку с темами, включающую стили css и изображения для определенных тем.

Controllers

Содержит контроллеры - классы, отвечающие за работу приложения. По умолчанию здесь находятся два контроллера - HomeController и AccountController.

Папки Images и Scripts

Папки Images и Scripts содержат соответственно изображения и скрипты на JavaScript, используемые в приложении. По умолчанию эти папки уже содержат файлы, в частности, в папку Scripts уже помещены файлы библиотеки jQuery.

Models

Содержит модели, используемые приложением. По умолчанию здесь определена одна модель - AccountModel, которая представляет отдельную учетную запись.

Views

Здесь размещаются представления. Представления группированы по папкам, каждая из которых соответствует одному контроллеру. После получения и обработки запроса контроллер, отправляет одно из этих представлений, заполненных некоторыми данными, клиенту. Кроме того, имеется папка общих для контроллеров представлений - папка Shared

Итак, мы посмотрели на некоторые базовые части проекта и теперь создадим первое приложение.

Модель — это часть приложения, отвечающая за базовую прикладную логику, также называемую бизнес-логикой. Объекты модели обычно получают данные из постоянного хранилища, например SQL Server, и выполняют над ними бизнес-логику. У каждого приложения своя модель, поэтому платформа не ограничивает создаваемые модели. Например, можно использовать объекты ADO.NET DataSet или DataReader, либо же использовать специализированный набор доменных объектов. Для работы с данными также можно использовать комбинацию типов объектов.

Модель — это не какой-то конкретный класс или интерфейс. Класс относят к модели не потому, что от реализует какой-то интерфейс или является наследником определенного базового класса. Класс считается частью модели по роли, которую он играет в MVC-приложении ASP.NET, и его расположению в структуре папок приложения. Класс модели в MVC-приложении ASP.NET не обрабатывает ввод из браузера напрямую, как и не создает HTML-вывод в браузер.

Платформа MVC для ASP.NET сопоставляет URL-адреса с классами, называемыми Контроллерами . Контроллеры обрабатывают входящие запросы, вводимые пользователями данные и их действия, а также реализуют необходимую логику приложений. Класс контроллера обычно вызывает отдельный компонент представления, который создает в качестве ответа HTML-разметку.

Базовый класс для всех контроллеров — это ControllerBase, реализующий общую обработку MVC. Класс Controller наследует от класса ControllerBase и является реализацией контроллера по умолчанию. Класс Controller отвечает за следующие этапы обработки:

· Поиск метода действия, который нужно вызвать, и проверка допустимости его вызова.

· Получение значений, используемых как аргументы метода действия.

· Обработка всех ошибок, которые могут возникнуть при выполнении метода действия.

· Предоставление используемого по умолчанию класса WebFormViewEngine для отображения различных типов страниц ASP.NET (представлений).

Хотя работа приложения MVC управляется главным образом контроллерами, но непосредственно пользователю приложение доступно в виде представления, которое и формирует внешний вид приложения. В ASP.NET MVC 4 представления представляют файлы с расширением cshtml/vbhtml/aspx/ascx, которые содержат код с интерфейсом пользователя, как правило, на языке html. Несмотря на то, что представление в основном состоит из кода html, оно не является html-страницей. При компиляции приложения на основе требуемого представления сначала генерируется класс на языке C#, а затем этот класс компилируется.

Маршрутизация ASP.NET позволяет использовать URL-адреса, не сопоставляемые с определенными файлами на веб-узле. Поскольку URL-адрес не обязан быть сопоставлен с файлом, можно использовать URL-адреса, описывающие действия пользователя, что делает их более понятными. В маршрутизации ASP.NET можно определять шаблоны URL-адресов, сопоставляемых с файлами обработчиков запросов, но включать имена этих файлов в URL-адрес не обязательно. Кроме того, в шаблон URL-адреса можно включить заполнители, чтобы можно было передавать переменные данные в обработчик запроса без использования строки запроса для этой цели.

Чтобы отобразить представление, используется метод View контроллера. Для передачи данных представлению используется свойство ViewData класса ViewPage. Это свойство возвращает объект ViewDataDictionary, содержащий учитывающие регистр строковые ключи. Для передачи данных в представление можно записывать данные в словарь, Если метод View вызывается без параметров (как в предыдущем примере), свойство ViewData объекта контроллера передается в представление, имеющее то же имя, что и метод действия.

На странице представления можно обратиться к свойству ViewData, чтобы получить данные, переданные представлению. Свойство ViewData — это словарь, поддерживающий индексатор, принимающий ключи словаря.

29. ASP.NET: MVC4 Web API, структура Web API-приложения; назначение основных компонентов приложения, маршрутизация.

Цель создания веб-службы Web API - рефакторинг примера приложения, чтобы операции над данными приложения могли выполняться с применением запросов Ajax, результаты JSON которых будут использоваться для обновления HTML-разметки в браузере. Общая функциональность приложения останется той же самой, но не будут генерироваться полные HTML-документы для каждого взаимодействия между клиентом и сервером.

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

Для одностраничных приложений в Microsoft приспособлена библиотека Knockout, которая создает JavaScript-реализацию шаблона MVC (или, точнее, шаблона MVVM, настолько близкого к шаблону MVC, что я собираюсь трактовать их как одно и то же). В последующих разделах мы возвратимся к стороне ASP.NET MVC Framework примера приложения и применим библиотеку Knockout с целью создания простого приложения SPA.

http://professorweb.ru/my/ASP_NET/mvc/level8/8_3.php

30. WCF-сервисы: WSDL, хост, прокси, модели взаимодействия клиента и сервера, порядок разработки, принципы применения.

WCF-приложение: приложение сервис-ориентированной архитекуры (SOA).

SOA: модульный подход к разработке программного обеспечения основанный на использовании сервисов (служб) со стандартизированными интерфейсами.

Host: WindowsForms-приложение (C#, VB.NET), консольное-приложение (C#, VB.NET), IIS-сервер, WAS (Windows Activvation Services).

Stub/Proxy: класс, генерируемый VS, для связи с сервисом.

Протоколы связи: HTTP, TCP/IP, Named Pipe, MSMQ, можно написать собственный протокол.

Прокси – программа -"посредник", выступающая и как клиент, и как сервер одновременно с целью создания запросов от имени других клиентов.

WSDL: Web Services Description Language – XML-язык описания сервисов.

1. Модели WCF

Однонаправленный вызов

вопрос/ответ

дуплекс

поток

подписчик/издатель

Модели сервера:

PerCall - сервис на один вызов (не помнит своего состояния, хорошо масштабируется);

Single – один экземляр сервиса, программист обеспечивает многопоточность;

PerSession - сервис на один сеанс, экземпляр создается для каждого подключения (помнит свое состояние, Timeout).

Windows Azure: серверная операционная система, предоставляющая инфраструктуру для разработки и размещения в облаке интернет-сервисов.

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

Xx (успешно)

Xx (переадресация)

4xx (ошибка запроса)

5xx (ошибка сервера)

Каждое HTTP-сообщение состоит из трёх частей:

· Стартовая строка — определяет тип сообщения;

· Заголовки — характеризуют тело сообщения, параметры передачи и прочие сведения;

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

Метод URI HTTP/Версия протокола

Пример запроса:

GET /web-programming/index.html HTTP/1.1

Стартовая строка ответа сервера имеет следующий формат:

HTTP/Версия КодСостояния [Пояснение]

Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:

HTTP/1.1 200 Ok

http://www.4stud.info/web-programming/protocol-http.html

2. HTML. Структура HTML-страницы. Каскадные таблицы стилей (CSS). Модель DOM.

<!DOCTYPE html>

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<link rel="stylesheet" type="text/css" href="mysite.css">

<title>HTML Document</title>

</head>

<body>

Этот текст будет полужирным,

а этот - ещё и курсивным

</body>

</html>

Подробнее: https://ru.wikipedia.org/wiki/Document_Object_Model

3. JavaScript. Основные стандарты. Типы данных. Программные структуры. Принцип применения. Понятие DHTML.

JavaScript — объектно-ориентированный скриптовый язык программирования. Является диалектом языка ECMAScript.

Стандарт языка:

Есть 5 «примитивных» типов: number, string, boolean, null, undefined и 6-й тип – объекты object.

4. Методология Ajax. Структура Ajax-приложения, принципы разработки и применения.

Ajax – технология для взаимодействия с сервером без перезагрузки страниц.

5. Web-приложение. Архитектура web-приложения. Особенности реализации web-приложения. Web-сервер и web-клиент

Архитектура Web-приложений

6. Спецификация Java Platform Enterprise Edition (Java EE). Состав технологий. Понятие Application Server (сервер приложений).

В основе технологии Java EE лежит четыре основных документа:

- Java EE Platform Specification (спецификация платформы Java EE);

- Java EE Reference Implementation (образцовые реализации платформы Java EE);

- Java EE Blueprints (модель приложений Java EE);

- Java Compatibility Test Suite (набор тестов на совместимость платформы Java EE).

Примеры реализации

· Zope, развитый сервер web-приложений.

· Терминальные серверы, например поставляемые компанией Citrix

import java.io.IOException; // исключения ввода/вывода

import javax.servlet.*; // интерфейсы и классы общего типа

import javax.servlet.http.*; // расширение javax.servlet для http

public class Sss extends HttpServlet implements Servlet {

public Sss() {

super();

System.out.println("Sss:constructor");

}

public void init(ServletConfig sc) throws ServletException {

// инициализация сервлета

super.init();

System.out.println("Sss:init");

}

public void destroy() {

// перед уничтожением сервлета

super.destroy();

System.out.println("Sss:destroy");

}

12 3 4 5 6 7 Следующая ⇒

Последнее изменение этой страницы: 2019-04-19; Просмотров: 300; Нарушение авторского права страницы