Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии разработки Internet-приложений. Учебное пособие
.pdf
Надежность Web-приложений обусловлена устойчивостью
работы программно-аппаратных средств сети Internet,
устойчивость к сбоям которых испытана в течение многих лет.
Масштабируемость Web-приложений для сетей Intranet
обеспечивается использованием многоуровневой архитектуры,
позволяющей одно и тоже Web-приложение практически без
переконфигурирования выполнять для Intranet-приложений с
различной архитектурой.
Открытость архитектуры Intranet-приложений основывается
на гибкой многоуровневой архитектуре и стандартизированных
протоколах и форматах документов, доступных для модификации.
Простота изучения и использования Intranet-приложений
обусловлена стандартизацей пользовательского интерфейса на основе применения однотипного клиентского приложения – обозревателя со стандартным пользовательским графическим интерфейсом.
Достаточно освоить принципы работы одной программы обозревателя, чтобы можно было работать с любыми Intranet-приложениями.
Кроме того, использование Intranet-приложений характеризуется значительным снижением денежных затрат (в де-сятки и
сотни раз) на обслуживание, модернизацию и наращивание сети
Intranet по сравнению с традиционными корпоративными сетями,
построенными на основе архитектуры «клиент-сервер». Важным
достоинством сетей Intranet является возможность развертывания
на существующей инфраструктуре корпоративных локальных и
глобальных сетей. Для построения сети Intranet допускается
простое встраивание в существующие корпоративные сети с
использованием существующего аппаратного обеспечения.
При использовании Web-приложений в сети Intranet может
использоваться архитектура, показанная на рис. 1.2.
Сеть Intranet в общем случае имеет различную внутреннюю
структуру, построенную на принципах Internet, причем сеть
Intranet может и не иметь выход в Internet.
Сеть Intranet строится на основе архитектуры распределенных
приложений БД и архитектуры Web-приложений. Напомним, что
взаимодействие между распределенными компонентами такой
сети осуществляется на аппаратном уровне на базе протокола
11
TCP/IP, а на логическом уровне – на принципах, заложенных в
протоколе HTTP.
Рисунок 1.2. Схема функционирования Web-приложения с использованием
модулей расширения
В архитектуре Intranet-сети сегменты могут иметь развитую
структуру, обеспечивающую разграничение доступа и конфиденциальность информации. Такая структура реализуется с помощью
маршрутизаторов (устройств-коммутаторов, используемых для
поиска необходимого узла сети), распределенных в пределах
группы клиентов сети, либо путем использования центрального
маршрутизатора и многочисленных коммутаторов.
В качестве клиентских приложений в этой архитектуре
выступают Web-обозреватели, которые обращаются с запросами к
серверу БД или к серверу приложений через Web-сервер. В зависимости от используемой архитектуры Web-сервер может
находиться на сервере БД или на сервере приложений.
В функции Web-сервера в сети Intranet входит обработка
запросов Web-обозревателей на получение информации из
разделяемых БД, преобразование этих запросов (может
выполняться модулями расширения Web-сервера) в SQL-запросы
12
или другие форматы, понятные для сервера БД или сервера
приложений.
Intranet-приложение предоставляет следующие дополнительные возможности:
1) реализация концепций удаленного доступа и управления.
Концепция удаленного доступа подразумевает возможность
удаленного подключения к Intranet-сети, то есть подключение к
сети Intranet из любого компьютера сети Internet. Под удаленным
управлением понимается подключение к локальной сети и
выполнение функциональных операций по управлению ресурсами
локальной сети с удаленного компьютера. Для реализации
дистанционного управления необходимо наличие специального
сервера удаленного доступа и специального программного обеспечения на удаленном компьютере;
2) обеспечение доступа в Internet клиентов сети. При этом
становятся доступными услуги, предоставляемые сетью Internet,
связанные с возможностью получения свежей информации в
различных сферах, становятся доступны услуги электронной почты, возможность обмена информацией с внешними информационными и деловыми источниками, а также использование
приложений, находящихся в Internet, использование Internet для
рекламы и т. д.
Простота создания и наращивания сети Intranet позволяет
быстро создавать локальные, защищенные сетевые системы на
основе архитектyры «клиент-сервер», доступные для быстрого
освоения. Сеть Intranet может быть построена на основе
использования Web-сервера в локальной сети или на основе услуг,
предоставляемых внешним Web-сервером, находящимся в сети
Internet. Такие услуги, как правило, предоставляет провайдер,
обеспечивающий возможность использования функций своего
Web-сервера. Многие компании используют совмещенную
структуру Web-серверов.
При этом сама локальная сеть строится с использованием
собственного Web-сервера, а выход в глобальную сеть
осуществляется через Web-сервер провайдера, публикующий
маркетинговую информацию компании.
13
Современные сети Intranet имеют различное назначение и
особенности конкретной реализации. При этом выделяют
следующие принципы построения сетей Intranet:
- иерархическая архитектура Intranet-приложений. При такой
архитектуре информация размещается иерархически сверху вниз.
Для этого создают узловые серверы, на которых размещается
наиболее важная информация, используемая совместно
несколькими отделами или подсетями. При этом серверы могут
составлять иерархическую структуру. На верхнем уровне
находится сервер с информацией, необходимой для клиентов всей
сети, а на нижних уровнях иерархии находятся специализированные серверы, содержащие информацию, используемую для
групп клиентов сети. Таким образом обеспечивается максимально
быстрый доступ к любой внутрисетевой информации и снижаются
затраты на обновление корпоративной информации;
- использование «двусторонней обратной связи» с клиентами
сети для обработки их запросов. При этом процесс восстановления
при сбоях или перерывах в работе происходит с использованием
механизма транзакций. Intranet-приложения, построенные на
основе этого принципа, называют транзакционными Web-приложениями. Их целесообразно использовать, к примеру, при
создании Internet-магазинов с помощью промышленных СУБД.
При этом можно эффективно отслеживать осуществление всех
операций цикла продажи товара (заказа товара, оплаты и доставки
товара);
- использование группового способа общения. В этом случае
объединяются группы новостей с возможностью прямого обмена
информацией между различными членами группы клиентов и
разграничение доступа к информации для пользователей вне
группы.
Применение архитектуры Web-приложений в сетях Intranet по
сравнению с традиционными архитектурами локальных сетей
имеет следующие преимущества:
1) стандартизация пользовательского интерфейса –
использование обозревателя в качестве универсальной клиентской
программы позволяет упростить процесс обучения пользователей
и обслуживания клиентских компьютеров;
14
2) более удобное администрирование и конфигурирование
заключается в том, что в сети Intranet вносимые в серверах
приложений и серверах БД изменения не затрагивают клиентский
уровень, то есть не надо вносить изменения в огромное количество
компьютеров пользователей сети при изменений конфигурации БД
(достаточно изменить текст сценария, хранящийся на Web-
сервере);
3) удешевление установки и лицензирования клиентских
компьютеров пользователей сети Intranet.
Для расширения возможностей клиентской части (обозре-
вателя) и серверной части разрабатывают модули расширения
обозревателя и сервера, используемые для динамического
управления интерфейсными объектами (компонентами) Web-
документа.
1.5. Web-приложения с модулями расширения клиентской
и серверной части
1.5.1. Web-приложения с модулями расшинения сервера
Архитектура Web-приложений с модулями расширения
сервера может включать стандартные модули расширения – DLL-
библиотеки, реализующие, например, технологии ASP, IDX/HTX,
объекты ActiveX. Кроме того, могут подключаться
дополнительные модули, разработанные с использованием
интерфейсов CGI, ISAPI и др.
В этом случае в функции Web-сервера входят обработка
запросов программ-браузеров сети, вызовов (загрузка)
соответствующего модуля расширения сервера и передача ему
параметров запроса. В результате обработки запроса модулями
расширения сервера формируется Web-документ с использованием различных HTML-шаблонов. Готовый HTML-документ
отсылается в браузер в формате протокола HTTP.
Web-сервер формирует динамически Web-страницы
различными способами и отсылает готовые Web-страницы в
формате протокола HTTP. На рисунке 1.3 приведена архитектура
Web-приложения с модулями расширения сервера.
Различают пассивное и активное состояние Web-сервера. Так,
Web-сервер находится в пассивном состоянии, если формируемый
им документ содержит статическую информацию, то есть на Web-
15
странице отсутствуют средства ввода и обработки запросов к
серверу.
В активном состоянии Web-сервер находится при
динамическом создании Web-документов в ответ на запрос
пользователя (рисунок 1.3) или в случае, когда в обозреватель
загружены различные интерактивные элементы формы.
Для публикации БД основной интерес представляет активный
Web-сервер, реализуемый с помощью модулей расширения Web-
сервера.
Рисунок 1.3. Архитектура Web-приложения с модулями расширения
сервера
Для организации связи программных расширений Web-
сервера с БД используются также современные интерфейсы
доступа к данным OLE DB, ADO и ODBC. Эти интерфейсы
являются промежуточным уровнем между источником данных и
приложением, в качестве которого выступают программные
расширения Web-сервера.
Для создания модулей расширения Web-сервера могут
использоваться интерфейсы CGI, WinCGI или интерфейсы
программирования API.
Интерфейс CGI является стандартным протоколом
взаимодействия между Web-сервером и модулями расширения,
которые могут применяться для выполнения дополнительных
16
функций, не поддерживаемых сервером. Например, такие модули
используются для обработки получаемой от пользователя
информации, динамического формирования Web-документа,
публикации БД на Web-странице и т. д.
Следует отметить, что интерфейсу CGI соответствуют
обычные консольные приложения операционной системы DOS.
Обмен информацией между сервером и модулем расширения
осуществляется с помощью стандартного потокового
ввода/вывода, передача управляющих параметров может
организовываться через переменные окружения операционной
системы или через параметры URL-адреса модуля расширения.
Для написания CGI-программ подходит практически любой
язык программирования, обеспечивающий доступ к переменным
среды и ввод-вывод через стандартные потоки STDIN и STDOUT.
Для написания CGI-программ подходят среды разработки
C++Builder, Delphi, Visual C++ и Java. Кроме того, для этих целей
можно использовать интерпретаторы языков Perl, PHP, предназначенные для различных интерфейсов Web-серверов.
Для запуска CGI-модуля обозреватель должен сформировать
запрос к серверу с указанием адреса URL этого модуля.
После передачи запроса обозревателя CGI-приложению
сервер передает ему также данные из командной строки запроса.
CGI-приложение формирует ответ и помещает его в выходной
поток (на стандартном устройстве вывода), затем сервер посылает
этот ответ с использованием протокола HTTP обратно браузеру.
В случае параллельной обработки нескольких запросов сервер
запускает отдельный процесс для обработки каждого запроса.
Причем для каждого процесса создается копия модуля расширения
в памяти компьютера, на котором находится Web-сервер. Поэтому
недостатками этого протокола является невысокая скорость
обработки запросов и повышенная загрузка Web-сервера.
При большом размере исполняемого CGI-файла сильно
увеличивается время отклика сервера на запрос обозревателя,
поскольку потребуется время для загрузки модуля CGI с диска в
память. Причем, если CGI-программа является интерпретируемой,
в частности, написанной на языке РНР или Perl, она будет
выполняться еще медленнее, так как в этом случае, кроме загрузки
модуля CGI, загружается интерпретатор РНР или Perl и произ-
17
водится интерпретация команд. При наличии сотен или тысяч
обращений к серверу произойдет запуск сотен или тысяч CGI-
программ соответственно, каждая из которых будет обрабатывать
соответствующий запрос обозревателя.
Отметим, что в некоторых операционных системах, в
частности Unix, могут повторно использоваться уже загруженные
программные коды модуля CGI первого процесса, создавая для
каждого нового обращения только свой экземпляр данных.
WinCGI протокол отличается от протокола CGI тем, что
управляющие параметры передаются через INI-файл, а входной и
выходной поток данных перенаправлены в специальные файлы.
Сервер передает данные CGI-программам через INI-файл Windows
в формате «параметр-значение». Программа WinCGI читает этот
файл и получает все данные, передаваемые ей из формы и
автоматически генерируемые обозревателем.
INI-файл Windows состоит из нескольких специальных
секций, в которых находятся различные параметры в виде
текстовых строк. В системных секциях, которые автоматически
генерируются обозревателем, находится информация о типе
доступа, составных элементах URL-запроса, с помощью которого
WinCGI-модуль был загружен. Там же находится информация для
настройки работы WinCGI-модуля, информация о сервере, путь к
файлу, в который помещаются данные, отсылаемые сервером
клиенту после выполнения WinCGI-модуля, «дополнительные»
параметры, которые включены в URL-запрос. В остальном
функционирование этого интерфейса аналогично интерфейсу CGI.
Более перспективными интерфейсами для разработки
дополнительных модулей расширения Web-сервера являются
интерфейсы ISAPI/ NSAPI. При использовании этих интерфейсов
модули расширения реализуются в виде библиотек DLL.
Рассмотрим принципы функционирования модулей ISAPI.
Запуск модуля расширения выполняется сервером в ответ на
первый запрос обозревателя (в случае CGI-интерфейса загрузка
осуществляется каждый раз) на загрузку URL-адреса этого
модуля. Загрузка модулей ISAPI осуществляется теми же
способами, что и загрузка модулей CGI. Обмен информацией
между сервером и модулем расширения осуществляется с помощью специальных объектов Request и Response. Сервер
18
передает параметры запроса модулю расширения с помощью
объекта Request и получает сформированный Web-документ с
помощью объекта Response.
В многопользовательском режиме работы сервера при
обработке сервером последующих запросов к модулю расширения
сервер использует уже загруженный экземпляр динамической
библиотеки. Такой механизм взаимодействия сервера и модуля
расширения обеспечивает экономию ресурсов сервера и
увеличение скорости обработки запросов.
Однако использование интерфейса API требует от
разработчика модуля расширения соблюдения особых мер по
обеспечению устойчивости этого модуля к сбоям. При
возникновении катастрофического сбоя потребуется перезапуск
Web-сервера.
Интерфейс ISAPI может применятся также для создания
ISAPI-фильтров, которые в отличие от модулей ISAPI, могут
использоваться для контроля всего потока данных между сервером
и обозревателем на уровне протокола HTTP. ISAPI-фильтры
можно применять для динамической перекодировки, шифрования,
сбора статической информации о работе сервера.
Для уменьшения нагрузки на Web-сервер часть функций,
связанных с предварительной обработкой запросов и введения
данных, целесообразно выполнять на стороне клиента, то есть в
браузере. Эту задачу решают модули расширения клиентской части.
1.5.2. Web-приложения с модулями расширения клиентской
части
В случае модулей расширения клиентской части (активность
на стороне клиента) используют апплеты, подключаемые
программы, ActiveX-объекты и сценарии. Эти технологии могут
использоваться для создания динамических эффектов при
просмотре Web-страницы. Архитектура Web-приложения с
модулем расширения клиентской части приведена на рис. 1.4.
Элементы управления ActiveX представляют собой вид модулей
расширения, которые могут использоваться на стороне клиента или
на стороне сервера. Они реализуются с помощью динамических
библиотек DLL и могут быть встроены в Web-документ как
дополнительные интерфейсные элементы. Механизм работы
19
элементов управления ActiveX позволяет из программного кода этих
объектов получать неограниченный доступ к локальным ресурсам
компьютера пользователя. Из элемента управления ActiveX имеется
возможность предавать на сервер любую информацию с компьютера
пользователя. С точки зрения обеспечения безопасности локальных
данных пользователей использование элементов управления ActiveX
не всегда оправдано.
Р
исунок 1.4. Схема Web-приложения с использованием модуля расширения
обозревателя
Исполняемые программы являются первым поколением
клиентских расширений. Для организации работы такой
программы в Web-приложении необходимо предварительно
устанавливать такую программу и конфигурировать обозреватель.
Поэтому при использовании механизма исполняемых программ
очень трудно обеспечить совместимость такого Web-приложения
для различных обозревателей. Кроме того, использование такой
технологии нарушает принцип стандартизации клиентского
интерфейса.
Апплеты Java применяются для создания динамически
формируемого интерфейса пользователя. Апплет представляет
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]