Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

11.1.

World Wide Web

701

Клиент взаимодействует с web-серверами при помощи специальной програм-

мы,

называемой браузером

(browser).

Браузер отвечает за правильное отображе-

ние документа. Кроме того, браузер обрабатывает операции пользовательского

ввода, основная из которых

—

выбор ссылки на другой документ, который затем

извлекается из хранилища и выводится на экран. Эта схема приводит нас к обоб-

щенной структуре Web, представленной на рис. 11.1.

Машина клиента

Браузер

ОС

Машина сервера

3. Отклик

Сервер получает

документ

из локального файла

Получение запроса на документ

Рис. 11,1. Обобщенная структура Web

Среда Web значительно изменилась с момента своего создания около 10 лет

назад. В настоящее время она представляет собой целую гамму методов и средств

предоставления информации, которая может обрабатываться как web-клиентами,

так и web-серверами. Далее мы детально рассмотрим, как работает web с точки зре-

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

касающихся собственно создания web-документов, поскольку они обычно не

имеют прямого отношения к распределенной природе Web. Хорошее и основа-

тельное введение в тему разработки приложений для Web можно найти в

[123].

Документная модель

Web базируется на представлении всей информации в виде документов. Сущест-

вует множество способов создания документов. Некоторые документы могут быть

просто текстовыми ASCII-файлами, другие же представляют собой набор сцена-

риев,

которые автоматически выполняются при загрузке документа в браузер.

Однако наиболее важно для нас то, что документ может содержать ссылки на

другие документы. Эти ссылки называются

гиперссылками

(hyperlinks).

Когда до-

кумент открывается в браузере, гиперссылки на другие документы выделяются

особо, чтобы пользователь легко мог их заметить. Пользователь может выбрать

ссылку, щелкнув на ней мышью. Выбор гиперссылки генерирует запрос на полу-

чение документа, пересылаемый на сервер, на котором хранится документ. Отту-

да он возвращается на машину пользователя и открывается в браузере. Новый

документ может быть показан в новом окне или заменить существующий доку-

мент в текущем окне браузера.

Большинство документов в Web описываются с помощью особого языка раз-

метки

гипертекста

(HyperText Markup

Language,

HTML). Слово «разметка» оз-

702 Глава

11.

Распределенные системы документов

начает, что HTML содержит ключевые слова для разбивки текста документа на

отдельные разделы. Так, например, любой HTML-документ имеет разделы заго-

ловка и тела документа. Помимо заголовков HTML позволяет выделять списки,

таблицы и формы. Также в определенные места документа можно вставить изо-

бражения и анимацию. Кроме этих элементов HTML содержит различные клю-

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

Так, например, существуют ключевые слова для выбора определенного шрифта

или разхмера шрифта, для представления текста жирным или курсивным начер-

танием, для выравнивания частей текста и т. п.

Сейчас HTML больше не является тем, чем он был раньше,

—

просто языком

разметки. В настоящее время он включает в себя множество средств для созда-

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

частей документа в форме сценариев. Рассмотрим простой пример HTML-доку-

мента (листинг 1L1).

Листинг

11.1.

Простая web-страница, содержаш,ая сценарий,

написанный на языке JavaScript

<HTML>

<BODY>

<Hl>Hello Worlcl</Hl>

<P>

<SCRIPT type

"text/javascript">

clocument.wr1teln("<Hl>HelIo

World</Hl>");

</SCRIPT>

</P>

<IBODY>

</HTML>

<i -_

—

- -

<i -_

Начало HTML-документа

Начало тела документа

Основной текст

Начало нового абзаца

Назначение языка сценариев

Вывести текстовую строку

Окончание секции сценария

Окончание секции абзаца

Окончание тела документа

Окончание секции HTML

-->

Когда эта web-страница будет обработана и показана браузером, пользователь

увидит текст «Hello World», повторенный дважды в отдельных строках. Первый

вариант этого текста станет результатом интерпретации строки HTML:

<Hl>HeIIo World</Hl>

Второй вариант, в свою очередь, будет результатом работы небольшого сце-

нария, написанного на Java-подобном языке cneii?ipiieB JavaScript Этот сценарий

состоит из одной строки кода:

document.wr1teln("<Hl>HeIIo World</Hl>");

Хотя результат работы этих двух фрагментов HTML-кода абсолютно одина-

ков,

ясно, что между ними имеется существенная разница. В первом случае мы

имеем результат непосредственной интерпретации команд HTML, предназначен-

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

—

это резуль-

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

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

Когда выполняется синтаксический разбор документа, он сохраняется внутри

браузера в виде корневого дерева, которое называют деревом синтаксического

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

11.1.

World Wide Web 703

Чтобы добиться переносимости, представление дерева синтаксического разбора

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

содержал только элементы одного типа из предопределенного набора типов эле-

ментов. Точно так же каждый из узлов должен реализовывать стандартный ин-

терфейс, содержащий методы доступа к его содержимому, возвращать ссылки на

родительские и дочерние узлы и т. п. Это стандартное представление известно

[259] как

объектная модель документа {Document Object

Model,

DOM). Его также

часто называют

динамическим

языком HTML

{dynamic

HTML).

Модель DOM предоставляет стандартный программный интерфейс для web-

документов, прошедших синтаксический разбор. Этот интерфейс определен в язы-

ке IDL системы CORBA и его отображения на различные языки сценариев, та-

кие как JavaScript, стандартизованы. Интерфейс используется для включения

документы сценариев обхода дерева синтаксического разбора, осмотра и моди-

фикации узлов, их добавления и удаления и т. п. Другими словами, с помощью

сценария можно выполнять просмотр и изменение документа, частью которого

он является. Понятно, что это открывает массу возможностей для динамической

настройки документов.

Хотя большинство web-документов, как и раньше, пишутся на HTML, суще-

ствует и другой согласованный с DOM язык [73]

—расширяемый

язык

разметки

{extensible Markup Language, XML). В отличие от HTML XML обеспечивает

только структурирование документа; он не содержит ключевых слов для форма-

тирования документа, например выравнивания текста по центру или изображе-

ния его курсивом. Еще одно его важное отличие от HTML состоит в том, что

XML можно использовать для определения произвольных структур. Другими

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

Определение типа документа требует, чтобы все элементы документа были

сначала объявлены. Так, например, в листинге 1L2 показано определение на язы-

ке XML простой обобщенной ссылки на журнальную статью (номера строк не яв-

ляются частью определения). Ссылка на статью объявляется в строке 1 как до-

кумент, состоящий из трех элементов: title (заголовок), author (автор) и journal

(журнал). Знак плюс (+), следующий за элементом author, означает, что авторов

может быть один или больше.

Листинг 11.2. Определения XML

для

ссылки на журнальную статью

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

(12)

ELEMENT article (title. author+, journal)>

ELEMENT title (#PCDATA)>

ELEMENT author (name. affiliation?)>

ELEMENT name (#PCDATA)>

ELEMENT affiliation (#PCDATA)>

ELEMENT journal(jname. volume, number?, month?, pages. yedf)>

ELEMENT maine (#PCDATA)>

ELEMENT volume (#PCDATA)>

ELEMENT number (#PCDATA)>

ELEMENT month (#PCDATA)>

ELEMENT pages (#PCDATA)>

ELEMENT year (#PCDATA)>

704 Глава

11.

Распределенные системы документов

В строке 2 объявлен элемент title, состоящий из последовательности симво-

лов (соответствующих в XML простому типу данных

#PCDATA).

Элемент списка

авторов подразделяется на два других элемента: name (имя) и affiliation (допол-

нение). Символ вопроса (?) показывает, что элемент affi

iation не обязательный

и не может присутствовать в ссылке на статью в количестве более чем один эле-

мент на автора. Подобным же образом в строке 6 элемент journal также делится

на меньшие элементы. Каждый элемент, который не подвергается дальнейшему

разделению (то есть образует листовой узел в дереве синтаксического разбора),

определяется как набор символов.

Реальная ссылка на статью в XML может быть теперь представлена в виде

XML-документа, приведенного в листинге 11.3 (номера строк не входят в доку-

мент и здесь). Если предположить, что определения из листинга 11.3 хранятся

в файле article.dtd, строка 2 говорит системе синтаксического разбора XML, где

найти определение, соответствующее текущему документу. Строка 4 содержит

заголовок статьи, а строки 5 и 6 содержат имена каждого из авторов. Отметим,

что дополнения пропущены, в соответствии с определениями XML из листин-

га 11.2 это возможно.

Листинг 11.3. XML-документ, использующий определения XML из листинга 11.2

(1) <?xml = version "1.0">

(2) <!DOCTYPE article SYSTEM "article.citd">

(3) <article>

(4) <title>Prudent Engineering Practice for Cryptographic Protocols</title>

(5) <author><name>M. Abacli</name></author>

(6) <author><name>R. Neeclham</name></author>

(7) <journal>

(8) <jname>IEEE Transactions

Software Engineering</jname>

(9) <volume>22</volume>

(10) <number>l</number>

(11) <month>January</month>

(12) <pages>6-15</pages>

(13) <yea r>1996</yea r>

(14) </journal>

(15) </article>

Представление XML-документа пользователю требует задания правил фор-

матирования. Самый простой подход

—

это встроить XML-документ в HTML-

документ и использовать для форматирования ключевые слова HTML. С другой

стороны, существует специальный язык форматирования, расширяемый язык сти-

лей (extensible Style

Language,

XSL), и для определения формата вывода XML-

документа можно использовать и его. Детальное описание того, как это сделать,

можно найти в

[123].

Кроме элементов, которые традиционно наличествуют в документе, таких как

заголовки и абзацы, HTML и XML могут поддерживать также специальные эле-

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

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

и даже интерактивную анимацию. Понятно, что языки сценариев играют важ-

ную роль в мультимедийных документах.

11.1.

World Wide Web 705

Типы документов

Помимо HTML- и XML-документов существует еще множество типов докумен-

тов.

Так, например, сценарий также можно рассматривать как документ. Другими

примерами подобных документов могут быть документы в форматах PostScript

или PDF, изображения в форматах JPEG или GIF, звуковые документы в форма-

те МРЗ. Тип документа часто выражается в виде типа MIME {MIME type). Спе-

цификация MIME расшифровывается как

Multipurpose

Internet Mail Extensions

{многоцелевые расшире7шя

почты Интернета) и изначально разрабатывалась

для передачи информации в виде содержимого тел сообщений, составляющих

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

которые описаны в

[154].

Эти типы также используются и в WWW.

В MIME проводится грань между типами верхнего зфовня и подтипами. Разные

типы верхнего уровня перечислены в табл. 11.1 и включают текст, изображения,

аудио и видео. Специальный тип Application указывает, что документ содержит

данные, которые относятся к определенному приложению. На практике только

это приложение способно преобразовать документ в нечто, воспринимаемое че-

ловеком.

Таблица 11.1. Шесть типов MIME верхнего уровня и некоторые

распространенные подтипы

Тип Подтип Описание

Неформатированный текст

Текст, содержащий команды разметки HTML

Текст, содержащий команды разметки XML

Изображение в формате GIF

Изображение в формате JPEG

Аудио,

8-бит

РОМ, 8000 Герц

Заданный слышимый тон

Видео в формате MPEG

Представление указателя мыши для презентаций

Не интерпретируемая последовательность байтов

Печатный документ в формате PostScript

Печатный документ в формате PDF

Независимые части в заданном порядке

Одновременно просматриваемые части

Тип Multipart используется для составных документов, то есть документов,

состоящих из нескольких частей, причем каждая из частей может ассоциировать-

ся с собственным типом верхнего уровня.

Для каждого из типов верхнего уровня может существовать несколько подти-

пов,

некоторые из них также приведены в таблице.

ТРШ

документа, таким обра-

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

application/PDF. В данном случае указывается, что для обработки документа.

Text

Image

Audio

Video

Application

Multipart

Plain

HTML

XML

GIF

JPEG

Basic

Tone

MPEG

Pointer

Octet-stream

Postscript

PDF

Mixed

Parallel

706 Глава 11. Распределенные системы документов

представленного в виде PDF, необходимо специальное приложение. Обычно

web-страницы имеют тип text/HTML, который отражает тот факт, что они пред-

ставляют собой ASCII-текст, содержащий ключевые слова HTML.

Обзор архитектуры

Комбинация HTML или XML со сценариями образует мощное средство отобра-

жения документов. Однако вряд ли имеет смысл выяснять, где именно обрабаты-

ваются документы и каким образом происходит их обработка. Среда WWW

начиналась с относительно простых систем с архитектурой клиент-сервер (см.

рис.

11.1). В настоящее время эта простая архитектура была расширена за счет

множества компонентов, поддерживающих усложненные типы документов, кото-

рые мы только что описали.

Одним из первых дополнений базовой архитектуры стала поддержка неслож-

ного взаимодействия с пользователями при помощи

обобщенного

интерфейса

шлюзов {Common Gateway Interface, CGI). CGI определяет стандартный способ

выполнения web-сервером программ с данными пользователя в качестве вход-

ных параметров. Обычно данные пользователя вводятся в HTML-форму; она оп-

ределяет программу, которая должна выполняться на стороне сервера, и значе-

ния параметров, введенные пользователем. После того как заполнение формы

закончено, имя программы и собранные значения параметров пересылаются на

сервер, как это показано на рис. 11.2.

3. Запуск программы

получения документа

Машина сервера

Процесс

ввода

Web-сервер

Программа

CGI

5. Созданный

НТМЬ-документ

Локальная ОС

Взаимодействие

с базой данных

Локальная

база данных

6. Посылка ответа

Запрос

на получение

документа,

посланный

на сервер

Рис. 11.2. Принцип использования программ CGI на стороне сервера

Когда сервер обнаруживает запрос, он запускает указанную в запросе про-

грамму и передает ей присланные в запросе параметры. После этого программа

делает свою работу и обычно возвращает результаты в виде документа, который

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

11.1.

World Wide Web 707

Программы CGI могут быть любой сложности. Так, например, как показано

на

рисунке, многие программы работают с размещенными на web-сервере базами

данных. После обработки данных программа создает HTML-документ и возвра-

щает этот документ серверу. Сервер затем пересылает документ клиенту. Инте-

ресно, что сервер как бы запрашивает документ у программы CGL Другими сло-

вами, сервер просто делегирует обязанности по извлечению документа внешней

программе.

Основная задача сервера, используемого для обработки запросов клиента,

состоит в извлечении документа. При наличии программ CGI извлечение доку-

мента может быть делегировано этим программам, так что сервер остается в не-

ведении о том, был ли документ создан «на лету» или его действительно получи-

ли из локальной файловой системы. Тем не менее серверы в наше время тоже

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

Одно из наиболее важных усовершенствований состоит в том, что серверы

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

стности, документ может содержать серверный сценарий

{server-side

script), ко-

торый исполняется сервером при локальном извлечении документа. Результаты

исполнения сценария вместе с другими частями документа пересылаются клиен-

ту. Однако сам сценарий не пересылается. Другими словами, серверный сцена-

рий изменяет документ, заменяя сценарий результатом его исполнения.

Для знакомства с примером подобного сценария рассмотрим HTML-доку-

мент из листинга 1L4 (номера строк не являются частью документа). Когда кли-

ент запрашивает этот документ, сервер выполняет сценарий, описанный в строках

5-12. Сервер создает локальный файловый объект

clientFile

и использует его для

открытия файла /data/file.txt, из которого он читает данные (строки 6-7). До тех

пор пока в файле имеются данные, сервер пересылает эти данные клиенту в виде

части HTML-документа (строки 8-9).

Листинг 11.4. HTML-документ, содержащий сценарий JavaScript,

исполняемый на сервере

(1) <HTML>

(2) <BODY>

(3) The current content of <PRE>/clata/f1le.txt</pRE> is:</P>

(4)

(5) <SERVER type = 4ext/javascript">

(6) ClientFile = new FileCVdatalfile.txt")

(7) if(clientFile.open("r")){

(8) whiledclientFile.eofO)

(9) document.wri

teln(cli

entFi1e.readln()):

(10) ClientFile.closeO:

(11)

}

(12) </SERVER>

(13)

</P>

(14) Thank you for visiting this site.</P>

(15) </BODY>

(16) </HTML>

Сценарий, исполняемый на сервере, опознается при помощи специального

нестандартного тега HTML

<SERVER>.

Серверы разных производителей используют

708 Глава 11. Распределенные системы документов

собственные способы распознавания исполняемых на сервере сценариев. В этом

примере при запуске сценария исходный документ изменяется так, что сервер-

ный сценарий заменяется текущим содержимым файла /data/file.txt. Другими сло-

вами, клиент никогда не видит текста сценария. Если документ содержит сцена-

рии, выполняемые на стороне клиента, они пересылаются клиенту обычным

образом.

Кроме выполнения клиентских и серверных сценариев, клиенту можно также

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

апплет {applet) представляет собой небольшое автономное приложение, которое

можно отослать клиенту и выполнить в пространстве адресов браузера. Наибо-

лее часто используются апплеты в виде программ на языке

Java,

скомпилирован-

ных в интерпретируемый код Java. Так, Java-апплет можно включить в HTML-

документ при помощи следующей строки:

Апплеты выполняются на стороне клиента. Существуют также и серверные

варианты апплетов, которые называются сервлетами {servlets). Как и апплеты,

сервлеты

—

это заранее скомпилированные программы, которые выполняются

в адресрюм пространстве сервера. В современной практике сервлеты в основном пи-

шутся на Java, но никаких фундаментальных ограничений на использование дру-

гих языков нет. Сервлет реализует методы, которые также имеются и в HTTP

—

стандартном коммуникационном протоколе между клиентом и сервером. В под-

робностях мы рассмотрим HTTP чуть ниже.

Когда сервер получает HTML-запрос, адресованный сервлету, он вызывает ме-

тод сервлета, соответствующий этому запросу. Последний, в свою очередь, обра-

батывает запрос и обычно возвращает результаты в виде HTML-документа.

Основное отличие сервлетов от сценариев CGI состоит в том, что последние

представляют собой отдельные процессы, в то время как сервлеты выполняются

сервером.

Теперь мы имеем более полное представление об архитектуре и структуре кли-

ентов и серверов в Web (рис. И.З). Когда пользователь посылает запрос на полу-

чение документа, web-сервер обычно, в зависимости от предлагаемых в докумен-

те задач, делает одно из трех. Во-первых, он может извлечь документ прямо из

локальной файловой системы. Во-вторых, он может запустить программу CGI,

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

данных. В-третьих, он может передать запрос сервлету.

Когда документ будет получен сервером, ему может потребоваться дополни-

тельная обработка, в ходе которой будут выполнены содержащиеся в нем сцена-

рии, исполняемые на сервере. На практике это требуется только для документов,

напрямую извлекаемых из локальной файловой системы, то есть документов, по-

лученных без помощи сервлетов или программ CGL Затем документ пересыла-

ется браузеру пользователя.

После того как документ будет получен клиентом, браузер выполняет кли-

ентские сценарии и, возможно, извлекает и выполняет содержащиеся в докумен-

те апплеты. Результаты обработки документа в виде его содержимого выводятся

на терминал пользователя.

11.1.

World Wide Web 709

Машина клиента

Терминал

пользователя

Машина сервера

Браузер

Требуемая

обработка

Ann лет

Пост-

Ьбработка

Альтернативные пути:

2а - За - 4а

2Ь

ЗЬ

2с -

Зс

- 4с

Рис. 11.3. Подробности архитектуры клиента и сервера

Web

Локальная

база данных

и файловая

система

В описанной архитектуре мы предполагали, что браузер может показывать

HTML-документы и, возможно, XML-документы. Однако существует множест-

во документов в других форматах, таких как PostScript или PDF. В этих случаях

браузер просто просит сервер без всякой обработки извлечь этот документ из

файловой системы и прислать его. В результате такого подхода клиент получает

файл. Используя расширение файла, браузер запускает соответствующее ему при-

ложение, которое позволяет продемонстрировать или обработать его содержи-

мое.

Поскольку подобные приложения помогают браузеру выполнять его рабо-

ту

—

показывать документы, они называются также

приложениями-помощниками

{helper

applications).

Ниже мы рассмотрим, чем можно заменить такие прило-

жения.

11.1.2.

Связь

Любое взаимодействие между клиентом и сервером в Web происходит по

прото-

колу передачи гипертекста

{Hypertext Transfer

Protocoly

HTTP). HTTP

—

это отно-

сительно простой протокол, ориентированный на архитектуру клиент-сервер.

Клиент в нем посылает запросы на сервер и ожидает получения ответа. Следует

отметить важное свойство HTTP

—

этот протокол не фиксирует состояния. Дру-

гими словами, у него нет никаких данных об открытом соединении и он не требу-

ет, чтобы сервер поддерживал какую бы то ни было информацию о своих клиен-

тах. Последняя версия HTTP описана в

[142].

Соединения HTTP

В основе HTTP лежит протокол TCP. Когда клиент посылает серверу запрос, он

устанавливает соединение TCP с сервером и посылает через это соединение свой

запрос. То же самое соединение задействуется и для получения ответа. Исполь-

710 Глава

11.

Распределенные системы документов

зуя TCP в качестве базового протокола, HTTP может не заботиться о потере за-

просов или ответов. Клиент и сервер могут просто допустить, что их сообщения

доходят до противоположной стороны соединения. Если дела идут плохо, напри-

мер соединение разорвано или истек тайм-аут, генерируется сообщение об ошиб-

ке.

Однако обычно попытки восстановления после сбоя не предпринимаются.

Одной из проблем первой версии HTTP было неэффективное использование

соединений TCP. Каждый web-документ собирается из коллекции разных фай-

лов,

хранящихся на одном сервере. Чтобы правильно отобразить документ, все

эти файлы также требуется переслать клиенту. Каждый из них в принципе пред-

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

править отдельный запрос на сервер.

В HTTP версии 1.0 и предыдущих версий каждый запрос к серверу требовал

отдельного соединения (рис. 11.4, а). После ответа сервера соединение разрыва-

лось.

Такие соединения называются

песохранными

(nonpersistent).

Основной не-

достаток несохранных соединений состоит в существенных издержках на созда-

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

со всеми его элементами клиенту, значительно возрастает.

Клиент

Сервер

Клиент

Сервер

Ссылки

it it it

ос

НИН

^ ^ ^

ОС

Соединение TCP

Рис. 11.4. Использование несохранных (а)

и сохранных(б)соединений

Отметим, что HTTP не запрещает клиенту одновременно установить несколь-

ко соединений с одним и тем же сервером. Такой подход нередко используется

для сокрытия задержек, связанных с временем установки соединения, а также

для параллельной передачи данных от сервера клиенту.

Более эффективный подход, характерный для HTTP версии 1.1,

—

использо-

вание сохранных

соединений {persistent

connections),

которые позволяют передать

несколько запросов (и соответствующих им ответов), без установки отдельных

соединений для каждой пары {запрос, ответ). Для еще большего повышения

производительности клиент может посылать несколько запросов одной коман-

дой, не дожидаясь получения ответа на первый запрос. Такая отправка известна

под названием конвейеризации {pipelining). Использование сохранных соедине-

ний продемонстрировано на рис. 11.4, б.