Глобальные информационные сети

Однако особое место среди программного обеспечения WWW занимают программы-интерфейсы, с которыми непосредственно работает множество пользователей этой международной компьютерной сети. Mosaic и Netscape, Line Mode Browser и Arena, Web Explorer и Lynx - вот далеко не полный список тех средств, которые используются для входа в "паутину". В данной статье речь пойдет об основных принципах построения этих программ и их использовании в Сети. Проведенные в Internet различными организациями опросы пользователей сети выявили, что за последние полгода наиболее популярными программами для доступа к сети стали программы доступа к World Wide Web. Объяснений этому феномену много: это и опережающие темпы установок WWW серверов (по некоторым данным их число удваивается каждые 53 дня) и бурная коммерциализация этого информационного ресурса, и чрезвычайно удобный интерфейс для доступа к ресурсам Internet, и широкое распространение персональной техники, на которую интерфейсные программы устанавливаются без особого труда и многое другое.

Пальму первенства по числу инсталляций программных продуктов этого типа безоговорочно занимает компания Netscape Communication. Различные продукты этой фирмы используются в 83 случаях из ста, и эта цифра последние полгода остается достаточно стабильной. Вслед за Netscape с большим отрывом от лидера идет Mosaic. На долю этого интерфейса приходится только 3% всех установок интерфейсов для WWW. Остальные программы используются еще реже. Однако это не означает, что все, установившие на своем компьютере Netscape, купили ее. Обычная практика в сети - использовать бета-версии программных продуктов и менять их по мере появления новых версий и расширения возможностей интерфейсов.

При общении с Web можно использовать несколько различных интерфейсов. Для работы с ПК хорошо подходят 16-разрядная версия Mozilla (вариация Netscape Navigator) или Mosaic, требующая предварительной установки 32- разрядного расширения для Windows 3.1. При существовании возможности использования машины с операционной системой Unix и графическим интересом X Window очень неплохо выглядит Arena, которая разрабатывается как тестовая программа для реализации возможностей HTML 3.0. Если нет возможности работать с графикой или доступ к сети осуществляется через сессию telnet, можно рекомендовать Lynux или Line Mode Browser. В первом случае пользователь получает полноэкранный алфавитно-цифровой интерфейс с возможностью работы с меню и формами. Если возникают проблемы с настройками терминала и нужно надежное простое средство для просмотра сети, то самым простым решением является Line Mode Browser. Несмотря на такой богатый выбор интерфейсов, все они устроены приблизительно одинаково. Проще и нагляднее всего архитектура такого сорта программ представлена в описании публичной библиотеки кодов, которую рекомендует World Wide Web Consortium для написания приложений, рассчитанных на работу с WWW.

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

В терминах прикладного ПО интерфейса Web различают ядро и прикладную задачу. И это не чистая абстракция. Вообще, интерфейс может состоять из нескольких программ, которые взаимодействуют друг с другом только через механизм обмена данными. Прикладными задачами могут быть и алфавитно-цифровой Line Mode Browser, и графическая Arena, и поисковое средство типа World Wide Web Worm - одним словом, любые прикладные задачи, предполагающие работу с WWW-серверами. Если быть более точным, под прикладной задачей подразумевается часть программы, которая разрабатывается программистом без использования общей библиотеки кодов WWW. Состав модулей библиотеки напоминает стек протоколов, в котором существуют общие модули, модули ядра, надстраивающиеся над общими модулями, и три набора функционально-ориентированных модулей: модули доступа, обеспечивающие доступ к данным посредством различных протоколов, модули обработки и преобразования потоков данных (потоковые модули), обеспечивающие конвертирование потоков данных из одной формы в другую, и модули приложений, реализующие такие функции, как поддержка стека данных для отката по нему при просмотре документов, история, встраивание объектов, обработка событий (например, ошибок) и т.п.

Все эти модули взаимодействуют между собой по определенной схеме, обеспечивающей правильную и эффективную обработку запросов на получение данных от WWW-серверов или других серверов информационных ресурсов Internet. Функционально модули библиотеки делятся на систему обработки и управления сообщениями (Event Manager), систему управления доступом к информационным ресурсам (Access Manager), систему управления протоколами обмена (Protocol Manager), систему управления буферизацией (Cache Manager) и систему форматирования (Format Manager). При этом предполагается, что прикладная часть, написанная программистом, должна обеспечивать управление событиями (по крайней мере генерировать запросы и прерывать выполнение требований на данные). При этом реализуется следующая схема взаимодействия вышеуказанных компонентов и прикладной задачи: система управления сообщениями ожидает запроса от прикладной части; когда запрос получен, вызывается система контроля доступа; система контроля доступа сначала проверяет наличие запрашиваемого документа в системном буфере. Для этой цели вызывается система управления буферизацией, и, если документ, точнее объект данных, содержится в буфере, запрос в сеть не отправляется, в противном случае, вызывается система управления протоколами и документ получают из Сети по специфицированному в запросе протоколу. После того, как документ получен, он передается системе форматирования, которая производит необходимые преобразования над данными, преобразованные данные передаются прикладной задаче для последующей обработки.

При анализе потоков данных следует обратить внимание на то, что запрос на данные может порождаться не только прикладной задачей, но и самими модулями библиотеки. Так, система управления буфером может обращаться в сеть за данными, срок хранения которых закончился и которые, следовательно, подлежат обновлению, либо при реализации режима Referer из протокола HTTP, позволяющего организовать демонстрационные ролики, использует режимы перенаправления запросов и обновления WWW страниц. В данном случае одно обращение вызывается системой управления буфером, а другое - системой управления протоколами без запроса на данные со стороны прикладной задачи. Следует отметить, что при генерации запроса системой управления протоколами, запрос сначала направляется системе управления доступом, а уже потом снова попадает на модуль управления протоколами. При форматировании данных может возникнуть ситуация, когда на их преобразование потребуется определенное время. Для того, чтобы обработка была эффективной, управление передается системе управления событиями, что позволяет на время подготовки данных освободить другие компоненты системы от непроизводительного ожидания. Когда данные будут готовы, система управления событиями сама вызовет систему управления протоколами для передачи данных по сети. Здесь хотелось бы обратить внимание на два момента: во-первых, данные преобразуются как при получении их из сети, так и при передаче в сеть, и, во-вторых, система управления событиями оказывается чрезвычайно полезной при реализации систем, работающих в качестве посредников (proxy), которые могут обслуживать одновременно более одного запроса на данные. Для реализации такого обслуживания в системе обычно поддерживаются "нити" запросов, являющиеся по сути стеками состояния каждого из элементов системы относительно каждого из выполняемых запросов. Остановимся на каждом из компонентов системы более подробно.

Система управления доступом является ключевым модулем всей библиотеки общих кодов. Именно здесь происходит интерпретация URL (см. CW N6) и диспетчеризация запроса между системами управления протоколами и системой управления буфером. Кроме запроса на данные, система управления доступом способна генерировать запросы и на отправку данных (метод PUT или POST см. CW N4). Когда прикладная задача запрашивает ресурс, то система управлением доступа преобразует URL по правилам схемы доступа к ресурсу и выбирает систему доступа к ресурсу (буфер, локальный доступ или удаленный доступ). Если ресурс локальный, то включается в дело система проверки прав доступа к локальным информационным ресурсам. При прерывании запроса на выполнение доступа к ресурсу система управления доступом буферизует полученные до прерывания данные для того, чтобы при повторном обращении выполнить только досылку данных, а не полное повторение обращения.

Система управления протоколами предназначена для доступа к удаленным информационным ресурсам не только по HTTP, но и по различным протоколам. В настоящее время, кроме HTTP, поддерживаются протоколы: FTP, Gopher, NNTP, WAIS и SMTP. Из документации по библиотеке общих кодов явствует, что система поддерживает и протокол TELNET, но в программах, написанных с использованием библиотеки общих кодов, обычно вызывается внешняя программа для работы по протоколу TELNET.

Система форматирования предназначена для преобразовывания данных из формата передачи по сети в формат отображения прикладной задачей и обратно. Система реализована по модульному принципу. В настоящее время возможно преобразование данных из форматов MIME, SGML, HTML и LaTeX.

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

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

Здесь хорошо видна разница между двумя версиями протокола HTTP: 0.9 и 1.0. В заключение хотелось бы еще раз обратить внимание на тот факт, что большинство интерфейсных программ WWW построены по схеме, представленной выше, хотя их реализации могут базироваться и на других программных наработках, отличающихся от библиотеки общих кодов. Работая с Netscape или Mosaic, обратите внимание на последовательность обработки запросов. Всегда элементы данных загружаются в одной и той же последовательности: фон, текст, графика. При анализе дампов запросов можно легко убедится в том, что сессия взаимодействия с сервером может состоять не из одного, а из нескольких запросов на данные, а в случае, когда документ находится в буфере, запрос по сети не отправляется вообще.

Тем, кто самостоятельно хочет попробовать свои силы в разработке программного обеспечения World Wide Web, рекомендую ознакомится с руководством WWWC по использованию библиотеки общих кодов и разобрать исходные тексты программы Line Mode Browser, которая написана с использованием этой библиотеки.