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

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

11.1.

World Wide Web 721

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

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

время переключатель уведомляется, что ему следует пересылать все последую-

щие сообщения TCP данного соединения на выбранный сервер.

11.1.4. Именование

в Web для ссылок на документы используется единая схема именования [44]

под названием унифицированный идентификатор ресурса {Unifoim Resource

Identifier, URI). URI существуют в двух формах.

Унифицированный указатель

ре-

сурса

{Uniform Resource

Locator,

URL) идентифицирует документ и содержит ин-

формацию о том, как и где можно получить к нему доступ. Другими словами,

URL

—

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

ность ещ

унифицированное

имя

ресурса (Uniform Resource

Name,

URN) представ-

ляет собой правильный идентификатор, как он был описан в главе 4. URN ис-

пользуется как глобальная уникальная и не зависящая от местоположения

сохранная ссылка на документ.

Реальный синтаксис URI определяется ассоциированной с этим идентифика-

тором схемой (scheme). Имя схемы является частью URI. Было определено мно-

жество различных схем, и сейчас мы рассмотрим некоторые из них, вместе с при-

мерами соответствующих идентификаторов URI. Лучше других известна схема

http,

но она не единственная.

Универсальные указатели ресурсов

URL содержит информацию о том, как и где можно получить доступ к докумен-

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

торая является частью URL, как, например, http, ftp или telnet. Местонахождение

документа часто присоединяется к URL при помощи DNS-имени сервера, к кото-

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

IP-адрес. Номер порта, который выделен на этом сервере для отслеживания по-

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

стандартный адрес. И наконец, URL содержит также имя документа, который

следует искать на сервере. Все это приводит к общей структуре URL, представ-

ленной на рис.

11.11.

1 Схема

http

1 Схема

http

1 Схема

1 Имя сервера

:// www.cs.vu.nl

1 Имя сервера

:// www.cs.vu.nl

1 Имя сервера

Имя файла |

/home/steen/mbox

Порт| Имя файла |

: 80 /home/steen/mbox

Порт| Имя файла |

http :// 130.37.24.11 : 80 /home/steen/mbox

Рис.

11.11.

Характерные структуры URL. Использование только DNS-имени (а). Комбинация

DNS-имени и номера порта (б). Комбинация IP-адреса и номера порта (в)

722 Глава

11.

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

Разрешение указателей URL, подобных приведенным на рис.

11.11,

прово-

дится напрямую. Если сервер указан в виде DNS-имени, это имя следует разре-

шить в IP-адрес сервера. Используя номер порта, содержащегося в URL, клиент

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

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

В табл. 11.4 представлено несколько примеров URL. URL со схемой http ис-

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

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

токолу FTP.

Таблица 11.4. Примеры URL

Название Назначение Пример

http

ftp

file

data

telnet

tel

modem

HTTP

FTP

Локальные файлы

Непосредственная

передача данных

Удаленный вход

в систему

Телефон

Модем

http://www.cs.vu.nl:80/globe

ftp://ftp.cs.vu.nl/pub/minix/README

file:/edu/book/work/chp/11/11

data:text/plain;charset=iso-8859-7,%e1%e2%e3

telnet://flits.cs.vu.nl

tel:+31201234567

modem:+31201234567;type=v32

Непосредственная отправка документов поддерживается при помощи URL со

схемой data

[284].

В таком случае к URL присоединяется сам документ, подоб-

но присоединению данных файла к индексному узлу

[307].

В качестве примера

в таблице показан указатель URL, содержащий простой текст из греческих

букв аРу.

Помимо ссылок на документы URL часто применяют для других целей. Так,

URL со схемой telnet используется для организации сеанса telnet с сервером.

Существуют также указатели URL для связи при помощи телефонных каналов,

как описано в

[468].

Пример URL со схемой tel, приведенный в таблице, содер-

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

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

телефон. Пример URL со схемой nnoclenn можно использовать для организации

модемного соединения с другим компьютером. В этом примере URL указывает,

что удаленный модем поддерживает стандарт связи V32 ITU-T.

Универсальные имена ресурсов

в противоположность URL имена URN представляют собой не зависящие от ме-

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

URN можно выделить три части

[299].

Отметим, что имена URN образуют под-

множество всех идентификаторов URI и имеют схему urn. Однако правила син-

таксиса третьей части URN определяет идентификатор пространства имен.

11.1.

World Wide Web 723

I "urn" I Пространство имен| Имя ресурса |

urn : ietf rfc:2648

Рис. 11.12. Обобщенная структура URN

Типичными примерами имен URN являются имена для идентификации книг

по их номерам ISBN, например urn:isbn.O-13-349945-6

[276],

или имена для иден-

тификации документов по их номерам IETF, например urn:ietf:rfc:2648

[300].

IETF —

это сокращение от имени организации, отвечающей за подготовку стан-

дартов для Интернета, Internet

Engineering Task Force

{целевая группа

инженерной

поддержки

Интернета).

Хотя определить пространство имен URN относительно просто, разрешить

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

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

зом, вводя новое пространство имен, следует задать для него механизм разреше-

ния имен. К сожалению, ни одно из созданных в настоящее время пространств

имен URN не содержит подсказок на механизм разрешения имен.

11.1.5. Синхронизация

Синхронизация

—

не самый важный вопрос в Web в основном по двум причинам.

Во-первых, жесткая организация Web, в которой серверы никогда не обменива-

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

ми),

означает, что синхронизировать практически нечего. Во-вторых, Web может

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

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

та двойной записи.

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

стной работы над web-документами. Другими словами, теперь и в Web требуют-

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

тающих пользователей или процессов.

По этой причине было создано расширение HTTP

[490],

протокол WebDAV

{Web

Distributed

Authoring and

Versioning —

распределенная

подготовка

докумен-

тов

в Web с

контролем

версий), который поддерживает простые средства блоки-

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

ния документов, находящихся на удаленных web-серверах. Мы кратко опишем

способ синхронизации, принятый в WebDAV. Дополнительную информацию

можно найти в

[489].

Подробная спецификация WebDAV содержится в

[171].

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

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

типа блокировок записи. Блокировка исключительной записи может быть пре-

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

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

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

но.

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

724 Глава

11.

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

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

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

ной записи самостоятельно.

Блокировка осуществляется путем отправки маркера блокировки запросив-

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

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

ру HTML-запрос post вместе с маркером блокировки. Маркер удостоверяет тот

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

нить запрос.

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

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

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

когда пожелает послать HTML-запрос.

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

дит отказ, сервер должен так или иначе восстановить блокировку. WebDAV не

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

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

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

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

11.1.6.

Кэширование и репликация

Кэширование на клиенте, применяемое для повышения производительности

в Web, всегда играло важную роль в структуре web-клиентов. Такое положение со-

храняется и поныне [39]. Кроме того, в попытках разгрузить перегруженные web-

серверы общепринятой практикой является репликация web-сайтов с размеще-

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

гия репликации в Web, и кэширование понемногу стало отходить на второй план.

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

Кэширование с помощью web-заместителя

Кэширование на клиенте обычно осуществляется в двух местах. Во-первых, боль-

шинство браузеров оснащены простейшими средствами кэширования. Когда до-

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

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

изводить проверку его непротиворечивости. Мы еще коснемся этого вопроса чуть

ниже.

Во-вторых, клиент часто запускает web-заместитель. Как мы говорили ранее,

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

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

щество такого подхода состоит в том, что заместители могут кэшировать резуль-

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

web-заместитель может реализовывать разделяемый кэш.

Кроме кэширования в браузерах и заместителях можно также создать кэш,

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

11.1.

World Wide Web 725

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

снижения трафика, но проигрывают неиерархическим схемам из-за больших за-

держек. Увеличение времени ожидания вызывается частой необходимостью об-

ращаться к нескольким кэширующим серверам, в то время как в неиерархиче-

ских схемах достаточно лишь одного.

В Web введены различные протоколы поддержания непротиворечивости

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

ствительности, некоторые web-заместители сначала посылают серверу HTML-

запрос get с дополнительным заголовком запроса

If-Mod1

fled-Since, определяя

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

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

web-заместитель просто возвращает локальному клиенту его кэшированную вер-

сию.

Если следовать терминологии, которую мы ввели в главе 6, это соответству-

ет протоколу извлечения.

К сожалению, эта стратегия требует, чтобы заместитель связывался с серве-

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

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

Squid [91] устанавливает срок устаревания документа

Техрье,

зависящий от того,

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

Tiastjnodi/ied —

вре-

мя последней модификации кэшируемого документа (записанное владельцем),

Tcached —

время кэширования, то:

expire ~ ^\^ cached "~ J-lastjmodified) ~'" J-cached'

Здесь а, равное 0,2,

—

это значение, полученное эмпирическим путем. До мо-

мента

Texjnre

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

связывается. После момента

Texpire

заместитель просит у сервера свежую копию,

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

стратегия оказывается той же са-

мой, что и в предыдущем обсуждавшемся случае.

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

дификацию так же часто, как документ, изменявшийся недавно. Такая стратегия

впервые была предложена в файловой системе Alex [87]. Очевидный недостаток

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

мент, то есть документ, более старый, чем версия, находящаяся на сервере. Еще

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

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

Альтернативой протоколу на основе извлечения является схема, при которой

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

ние о недействительности хранящегося в кэше документа. Недостаток такого под-

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

лей, а это неминуемо приведет к проблемам масштабируемости. Однако в [83]

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

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

Одной из проблем, с которыми сталкиваются разработчики кэшей web-заме-

стителей, состоит в том, что кэширование на заместителе имеет смысл, только

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

726 Глава

11.

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

оказывается, что коэффициент кэш-попаданий не превышает значения 50

и то,

если кэш достаточно велик. Один из способов построения очень больших кэшей,

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

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

11.13.

3. Передача запроса

web-серверу

Web-сервер

Просмотр

локального кэша

Web-

заместитель

Опрос кэшей соседних заместителей

Web-

заместитель —fSr-"^

Клиент Клиент Клиент]

Запрос HTTP Get

Web-

заместитель

Клиент Клиент Клиент

Рис. 11.13. Кооперативное кэширование

При

кооперативном кэшировании {cooperative

caching),

когда бы ни случился

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

ко соседних заместителей на предмет того, не содержит ли один из них иско-

мый документ. Если эта проверка не дает результатов, заместитель пересылает

запрос на web-сервер, на котором находится этот документ

[455].

В [495] показа-

но,

что кооперативное кэширование может оказаться эффективным для относи-

тельно малых групп клиентов (от десятков до тысяч пользователей). Однако эти

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

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

Другая проблема с кэшем web-заместителя состоит в том, что его можно ис-

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

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

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

жет привести к другим результатам.

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

с сервера в кэш заместителя [82], что в результате дает так называемый

активный

кэш

{active

cache).

При таком подходе сервер возвращает не генерируемый доку-

мент, а апплет, который кэшируется заместителем. После этого за генерацию от-

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

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

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

нен на сервере.

11.1.

World Wide Web 727

Для активных кэшей существует несколько приложений. Так, например, если

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

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

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

В качестве другого примера рассмотрим документ, содержащий список рек-

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

мента. В этом случае при первом запросе документа сервер пошлет заместителю

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

дующем запросе документа заместитель может сам обработать этот запрос и сфор-

мировать ответ, вернув на этот раз другой баннер.

Репликация серверов

в Web используются два основных способа репликации серверов. Во-первых, как

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

клика используют кластеры web-серверов. Как правило, этот вид репликации

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

зрачный вид репликации, заключающийся в создании точной копии web-сайта на

другом сервере, которая называется

зеркалом

(jniiror).

Клиент при этом получает

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

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

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

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

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

реплицированных на серверах копий, в которых учтены характеристики доступа

клиентов. Коллекция таких серверов называется сетью доставки

содержимого

{Content Delivery

Networky

CDN), или (реже)

сетью

распределения

содержимого

{content distribution

network).

В CDN задействуют разные технологии репликации и распределения доку-

ментов. Мы представили в главе 6 одно из решений, используемое в службе web-

хостинга RaDaR

[366].

В RaDaR сервер отслеживает число запросов, приходя-

щих от клиентов отдельного региона. Если запросы представляют собой значи-

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

КОПР1Ю

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

Другой популярный подход реализован в системе Akamai

[260].

Основная

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

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

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

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

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

цировать.

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

мощи указателя URL (см. рис. 11.11). В CDN Akamai этот URL изменяется так,

чтобы он ссылался на виртуальный образ

{virtual

ghost),

представляющий собой

ссылку на реальный сервер CDN. Измененный указатель URL разрешается так,

как показано на рис. 11.14.

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

4а.

Получение внедренных документов

из локального кэша или с сервера,

если они еще не кэшировались

Сервер

CDN

3. Запрос

внедренных

документов

5. Внедренные

документы

Клиент

Запрос основного документа

46.

Внедренные

документы

Реальный

сервер

Документ со ссылками

на внедренные документы

Рис. 11.14. Принцип работы сети CDN Akannai

Имя виртуального образа включает в себя DNS-имя ghosting.com, которое

разрешается стандартной системой именования DNS в DNS-сервер CDN, бли-

жайший к клиенту, пославшему запрос с разрешенным DNS-именем. Выбор бли-

жайшего DNS-сервера CDN выполняется путем нахождения IP-адреса клиента

в базе данных, содержаш.ей «карту» Интернета. Разрешение имен, производимое

на DNS-сервере CDN, позволяет получить адрес одного из обычных серверов

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

риям, например текуш;ей загрузке.

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

ный сервер CDN. Если этот сервер не содержит запрошенного документа, он

получает его с исходного web-сервера (шаг 4 на рисунке), локально кэширует

и передает клиенту. Если документ уже находится в кэше сервера CDN, он воз-

вращается клиенту немедленно.

Важный момент в работе CDN Akamai и некоторых других сетях CDN

—

это

обнаруженрхе ближайшего сервера CDN. Один из возможных подходов предпо-

лагает использование службы локализации, подобной описанной в главе 4. Толь-

ко что описанный подход сети CDN Akamai предполагает наличие службы DNS

и поддержку «карты» Интернета. Альтернатргоный подход, описанный в [И], пред-

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

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

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

путР1.

11.1.7.

Отказоустойчивость

Отказоустойчивость в Web в основном реализуется путем кэширования на кли-

енте и репликации серверов. В HTTP нет никаких специальных средств повыше-

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

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

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

11.1.

World Wide Web

729

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

на запрос о разрешении имени несколько адресов.

11.1.8.

Защита

с учетом открытости Интернета понятна важность разработки системы защиты,

которая могла бы оградить клиентов и серверы от разнообразных атак. Большин-

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

клиентом и сервером. Основным механизмом организации защищенного канала

в Web является

уровень защищегшых сокетов (Secure Socket

Layer,

SSL), изначаль-

но предложенный компанией Netscape. Хотя SSL никогда не был формально

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

серверов Web. Не-

давно измененный вариант SSL, известный как протокол

защиты транспортного

уровня

(Transport

Layer

Secuiity,

TLS), был официально зафиксирован в виде спе-

цификации RFC 2246

[125].

Как показано на рис. 11.15, TLS

—

это не зависящий от приложения протокол

защиты, который логически располагается поверх транспортного протокола. Для

простоты реализации TLS (и SSL) обычно основаны на TCP. Как мы увидим да-

лее,

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

HTTP. Так, например, используя TLS, можно реализовывать защищенные вари-

анты FTP или Telnet.

HTTP FTP Telnet

TLS

Транспортный уровень

Сетевой уровень

Канальный уровень

Физический уровень

Рис. 11.15. Положение TLS

стеке протоколов Интернета

Сам по себе протокол TLS организован в виде двух уровней. Ядро протокола

образует уровень

протокола

записей TLS (TLS

record protocol

layer),

который реа-

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

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

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

сти и конфиденциальности сообщений.

Организация защищенного канала выполняется в два этапа, как показано на

рис.

11.16. Сначала (это первые два сообщения на рисунке) клиент уведомляет

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

мых методах сжатия. Итоговый выбор всегда остается за сервером, который со-

общает о нем клиенту.

730 Глава

11.

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

Лпвпдлохоииягтшитп! Ь

|редложения клиента ^

г-1 ^ ^ 1

|редпочтения сврверэ

lif

|1'^SJCA|

1 [ '^с JcA 1

•

l-if^/r

R 1 \

'^su г<

с)

СО

Рис. 11.16. Протокол TLS со взаимной аутентификацией

На втором этапе происходит аутентификация. Сервер всегда требует аутенти-

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

крытый ключ, подписанный сертифицирующей организацией (СА). Если сервер

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

слать серверу сертификат (сообщение 4 на рисунке).

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

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

руя его открытым ключом сервера. Кроме того, если необходима аутентификация

клиента, клиент также подписывает это число своим закрытым ключом (сообще-

ние 5 на рисунке). В действительности посылаются отдельные сообщения с шиф-

рованным и подписанным вариантами случайного числа, что имеет тот же эффект.

После этого сервер может идентифицировать клиента и установить защищен-

ный канал.

11.2.

Lotus Notes

Рассмотрим теперь абсолютно другую распределенную систему документов. Lo-

tus Notes

—

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

рацией Lotus Development, но в настоящее время продажами и разработкой этой

системы занимается компания IBM, которая купила Lotus Notes в конце 1990-х

годов. Система работает под управлением различных платформ семейств Win-

dows и UNIX. Большая часть внутренней структуры Lotus Notes является корпо-

ративной тайной, и открытая документация по этой теме отсутствует. Не так дав-

но руководства и справочники, а также материалы по архитектуре этой системы

были опубликованы в Интернете (по адресу http://www.notes.net/doc). Обзор сис-

темы Lotus Notes можно найти в

[272].

11.2.1.

Обзор

Как и Web, система Lotus Notes представляет собой систему (потенциально

очень большую) с архитектурой клиент-сервер. Lotus Notes изначально разра-

батывалась для работы в локальных сетях, но в настоящее время может работать