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

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

11.2.

Lotus Notes

731

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

на

рис.

11.17. Система Lotus Notes образована из четырех основных компонентов:

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

клиент или сервер может иметь несколько локальных баз данных. Каждая база

данных формирует коллекцию заметок {notes), которые являются ключевыми

элементами данных в любой системе Lotus Notes. Мы еще вернемся к заметкам

и базам данных из них чуть ниже.

Клиент

Сервер

Приложение Notes

Службы объектов Notes

Локальная ОС

Локальная

база данных

Программа сервера

Службы объектов Notes

Локальная ОС

Network

Рис. 11,17. Общая структура системы Lotus Notes

Совместно используемая

база данных

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

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

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

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

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

Серверы Lotus Notes известны под названием

серверов

Domino

{Domino

ser-

vers).

Сервер управляет коллекцией баз данных. Его главная задача

—

предостав-

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

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

дают запросов, поступающих по сети, поддерживают соединения и сеансы с уда-

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

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

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

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

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

им Lotus Notes хранит и обрабатывает документы посредством баз данных. Это

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

ляет разницу между web-серверами и серверами Domino.

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

ного компонента промежуточного уровня, который называют

службами

объек-

тов

Notes {Notes

Object

Services,

NOS). Этот компонент промежуточного уровня

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

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

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

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

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

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

Основной элемент данных в системе Lotus Notes

—

это заметка (note), которая

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

Элемент

(item)

—

это ячейка,

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

который определяет, какого рода данные могут в нем храниться. Существуют

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

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

для хранения скомпилированных команд Notes, элементы сценария для хране-

ния сценариев и т. д.

Каждая заметка может также иметь список ассоциированных с ней дочерних

заметок. Кроме того, любая заметка может иметь максимум одного ассоцииро-

ванного с ней родителя. Таким образом, мы приходим к иерархии заметок. Эта

иерархия отражает одну из специфических целей систем Notes, а именно созда-

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

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

и ответом на нее поддерживается в виде соотношения родитель—потомок пример-

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

В системе производится разделение заметок на

заметки

данными

(data notes)

и другие типы заметок. Заметку с данными можно сравнить с web-документом:

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

чать в себя различные элементы данных

—

аудио- и видеозаписи, изображения,

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

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

табл. 11.5. Все их можно грубо разделить на заметки конструкции и заметки ад-

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

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

—

для управления базами

данных Notes.

Таблица 11.5. Примеры заметок

Тип заметки Категория Описание

Document

Form

Field

View

ACL

ReplFormula

Данные

Конструкция

Администрирование

Предназначенный для пользователя

документ (как и web-страница)

Структура для создания, редактирования

и просмотра документа

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

в формах и подчиненных формах

Структура для показа коллекции документов

Содержит список контроля доступа

базы данных

Определяет репликацию базы данных

Заметка Form напоминает формы, знакомые пользователям Web или пользо-

вателям традиционных баз данных. Форма определяет, как должен выглядеть

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

11.2.

Lotus Notes 733

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

Эта возможность задается при помощи заметки Field. Также из мира баз данных

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

ляющее, как должна быть показана пользователю коллекция документов. Капри-

мер,

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

деть как таблица с элементами документов в качестве столбцов.

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

заметка

ACL

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

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

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

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

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

перссылок, которые в Notes называются

ссылками

на

заметки

{notelinks).

Ссылка

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

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

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

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

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

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

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

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

заметки (которое определяется ее элементами) и способ ее представления поль-

зователям (который определяется элементами конструкции). Это разделение мож-

но сравнить с обсуждавшимся ранее разделением между XML и XSL.

11.2.2.

Связь

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

зи между клиентами и серверами базовую систему RPC. Система RPC Notes пол-

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

уровня сетевой операционной системы (NOS). Когда сервер получает запрос RPC,

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

вию,

относящуюся к данному вызову RFC, как это происходит в других системах

RFC,

ориентированных на установление соединения.

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

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

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

тем, таких как CORBA и DCOM, большого числа средств взаимодействия меж-

ду процессами на разных машинах в Notes не предусмотрено. В основном связь

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

системы RFC Notes.

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

Почтовые сообщения Notes всегда посылаются в формате MIME, и подсистема

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

SMTF.

Существует также и специальный почтовый протокол Notes.

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

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

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

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

щие с базой данных. Так, например, изменение отдельного элемента в заметке

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

шейся заметки. Точно так же и приходящие сообщения электронной почты мо-

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

зе данных Notes.

11.2.3.

Процессы

Как и в Web, в Notes имеется четкое разделение машин на клиенты и серверы.

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

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

чего,

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

полнения приложений Notes. Эта программа похожа на современные средства

разработки приложений баз данных; она позволяет пользователю создавать за-

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

Программное обеспечение серверов состоит из основной программы и мно-

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

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

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

прос).

Кроме этих встроенных заданий на сервере имеется множество дополни-

тельных заданий сервера

{server

tasks), имеющих вид отдельных процессов, ко-

торые выполняются на одной машине с главным сервером и находятся под

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

(рис.

11.18).

Основная программа

контролирует задания сервера

Сервер Domino j

Основная

программа

сервера

Задание

сервера

Задание

сервера

Службы объектов Notes

Локальная ОС

База данных сервера

Рис. 11.18. Общая структура сервера Domino

Взаимодействие между процессами в сервере Domino осуществляется при по-

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

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

зам данных и управления ими.

11.2.

Lotus Notes

735

Для повышения отказоустойчивости и производительности серверы Domino

могут объединяться в

кластеры

{clusters),

являющиеся коллекциями двух-шести

машин, на которых работают одинаковые серверы с идентичными копиями баз

данных. Кластер Notes похож на кластер web-серверов, но организован несколь-

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

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

запросы.

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

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

которая содержит и ссылку на сервер, связанный с этой базой данных. Когда кли-

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

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

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

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

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

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

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

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

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

Список серверов

кластера

Клиент

3. Запрос

Наименее

загруженный

сервер

Запрос

данных

о серверах

Сервер

Кластер из трех

серверов

Рис. 11.19. Обработка запросов к кластеру серверов Domino

Загрузка сервера W вычисляется для каждого сервера как функция от време-

ни отклика, возвращающая значение от

до 100. Так, если

Tresponse

~ текущее вре-

мя отклика, а

Topt —

оптимальное время отклика, то W^ вычисляется по формуле:

W= тах{0...100 - {Tresponse/Topt)].

Меньшее значение W указывает на то, что этот сервер загружен сильнее, чем

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

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

в обработке, отсутствуют, Сбудет иметь значение, равное 100, указывая на опти-

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

736 Глава

11.

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

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

Поскольку система Notes ориентирована на работу с базами данных, именование

ней

играет иную

по

сравнению

другими распределенными системами роль.

Так, поскольку заметки хранятся

базах данных, для доступа

ним

не

годятся

механизмы разрешения имен. Вместо этого используются либо традиционные для

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

ссылки.

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

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

ет Notes. Помимо

баз

данных

других файлов

Notes имеется немало других

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

ключи

и т. д. Эта

информация содержится

специальной базе данных, которая

называется

каталогом Domino {Domino directory)

и доступ

которой осуществля-

ется

так

же,

как и к

любой другой базе данных Notes.

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

собами. Во-первых, Notes имеет службы различимых имеп

{distinguished

names)

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

ступа

базам данных, но и, как мы говорили

главе 4, для организации иерархи-

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

по-

средством баз данных Notes.

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

зование URL. Этот механизм требуется

для

доступа

серверам Domino через

Web.

Кроме того,

он

необходим для реализации web-серверов

на

базе Notes.

Об-

щий вид URL

заметках приведен

на

рис. 11.20

напоминает URL для CGI.

Имя сервера

Путь

база Операция базы данных над заметкой

UNID

Операция | Параметры

http://domino.cs.vu.nl/lotus/db.nsf/a342bc1975ead20961d56a4c982ad57e?OpenView&start=124

Рис. 11.20. URL для доступа

базе данных Notes

Указатель URL в Notes состоит из трех основных частей. Первая часть

—

DNS-

имя сервера Domino, который обеспечивает обработку запросов HTTP. Вторая

часть

—

путь

базе данных Notes, размещенной

на

этом сервере. Третья часть,

собственно,

реализует доступ

заметке

заданной базе данных. Она состоит

из идентификатора (который

мы

кратко обсудим), имени операции

(необяза-

тельно) параметров этой операции. Сервер Domino отвечает

за

осуществление

указанной операции над заданной заметкой.

Идентификаторы

Хотя имена

виде строк символов

играют

Notes важную роль, большинство

вопросов, относящихся

именованию, решается при помощи машинных иденти-

фикаторов. Notes поддерживает несколько видов идентификаторов (табл. 11.6).

11.2.

Lotus Notes

737

Наиболее важный из них

—

универсальный идентификатор {Universal Ю, UNID),

используемый как глобальный уникальный идентификатор заметок. UNID

—

это

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

ции заметок все реплики имеют один и тот же идентификатор UNID.

Таблица 11.6. Некоторые идентификаторы Notes

Идентификатор Область видимости Описание

Универсальный

идентификатор

Идентификатор

инициатора

Идентификатор

базы данных

Идентификатор

заметки

Идентификатор

реплики

Глобальная

В пределах сервера

В пределах базы

данных

Глобальная

Глобально уникальный идентификатор,

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

Идентификатор заметки, включающий

информацию об истории

Меняющийся со временем идентификатор

базы данных

Идентификатор заметки, зависящий

от экземпляра базы данных

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

идентификации копий одной базы данных

От UNID ведет свое начало идентификатор инициатора {OriginatorID, OID),

который используется для идентификации отдельного экземпляра заметкрь OID

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

товую отметку времени. Он требуется для обнаружения и разрешения тех кон-

фликтов, которые могут возникнуть при одновременном изменении реплици-

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

репликации в Notes.

Идентификатор базы данных {database ID) не является истинным идентифи-

катором; это скорее отметка времени, указывающая на момент создания базы

данных или ее последнего восстановления после сбоя сервера. Его можно рас-

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

него отвечает.

Чтобы однозначно идентифицировать заметку в пределах конкретного экземп-

ляра базы данных, используется идентификатор заметки {note ID). Р1дентифи-

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

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

В каждой базе данных имеется таблица соответствия, в которой идентификатор

заметки отображается на ее физическое местоположение в базе данных. Таким

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

соответствия, в то время как все идентификаторы заметок остаются прежними.

И, наконец, идентификатор реплики {replica ID) используется для идентифи-

кации группы баз данных, участвующих в репликации. Если две базы данных

имеют од1П1аковый идентификатор реплики, значит, все изменения, сделанные

в одной базе данных, будут распространены и на вторую. В принципе идентифи-

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

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

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

738 Глава

11.

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

многих случаях дело обстоит именно таким образом. Идентификатор реплики

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

рые вносятся одинаковым образом.

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

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

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

к базам данных. Кроме того. Notes поддерживает транзакции. Однако эти меха-

низмы синхронизации реализованы нераспределенным образом в том смысле, что

ограничены пределами одного сервера Domino. Поддержка распределенных бло-

кировок или транзакций отсутствует.

11.2.6.

Репликация

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

поддерживалась с самого начала

[229].

В Notes используется слабая форма рас-

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

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

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

образом.

Ключевую роль в репликации играют

связующие документы {connection

docu-

ments),

представляющие собой особые заметки, содержащиеся в каталоге Domino

и описывающие, когда, как и что реплицировать. Каждый сервер Domino имеет

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

ют схему репликации, определенную в связующих документах. Существует че-

тыре возможных схемы репликации, перечисленные в табл. 11.7. Стандартной

схемой считается схема

извлечения-продвижения

{pull-push), в этом случае зада-

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

дает {продвигает) свои изменения на этот сервер. Кроме того, задание на реп-

ликацию считывает {извлекает) изменения, имевшие место на целевом сервере.

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

ния эпидемических алгоритмов, которые мы рассматривали в главе 6. Реплика-

ция в Notes в значительной степени основана на этих алгоритмах.

Таблица 11.7. Схемы репликации в Notes

Схема Описание

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

сервера и передает на него собственные изменения

Двойное извлечение Задание на репликацию считывает изменения с целевого

сервера и отвечает на приходящие от него запросы, передавая

собственные изменения

Продвижение Задание на репликацию передает собственные изменения

на целевой сервер, никак не реагируя на изменения, имевшие

место на этом сервере

11.2.

Lotus Notes 739

Схема Описание

Извлечение Задание на репликацию считывает изменения, имевшие место

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

изменения

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

pull),

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

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

схемы продвижения (push) и извлечения (pull), при работе по которым измене-

ния распространяются в одном направлерпн!, соответственно, к целевому серверу

или от него.

Существует три операции изменения, которые следует различать: модифи-

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

главное

—

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

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

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

и отметки времени в идентификаторе инициатора документа. Предыдущие зна-

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

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

уникального идентификатора инициатора. Чтобы зафрн<сировать факт удаления

документа, на место удаленного документа в базе данных помещается заглушка

удаления (deletion stub). Эта заглушка удаления аналогична свидетельству о смер-

ти в эпидемических алгоритмах. Отметим, что в принципе заглушка удаления не

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

вующего документа.

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

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

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

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

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

тов,

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

наковому универсальному идентификатору (UNID).

Разрешение конфликтов

Фундаментальная проблема метода репликации Notes состоит в том, что этот ме-

тод может (и будет) порождать конфликты. Если копии одного и того же до-

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

двойной записи. При распространении изменений они должны быть разрешены.

Notes обнаруживает и разрешает эти конфликты следующим образом.

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

ния, которую мы обсуждали ранее, с двумя репликами, Л и В. Изменение в В не-

обходимо считать (извлечь) в Л, после чего следует передать (продвинуть) в В

изменения, сделанные в Л. В процессе репликации для каждой реплики создает-

ся список идентификаторов инициаторов.

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

Если список, составленный на сервере В, содержит универсальный иденти-

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

Л,

это, по всей врщимо-

сти,

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

тать.

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

новый документ, появившийся на А. Если оба списка содержат одинаковые иден-

тификаторы рпшциаторов, значит, эти идентификаторы указывают на документ,

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

на сервер какие-ЛР1бо изменения не нужно.

Рассмотрим теперь, что происходит, если заметка N ршеется в списках, со-

ставленных как на Л, так и на В, но соответствующие ей идентификаторы ини-

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

NB,

за-

метки N. Эти две копии имеют одинаковые универсальные идентификаторы, но

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

должно просмотреть журнал рютории каждой из копий. Если одна из историй

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

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

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

но сделать одрп1аковыми.

Однако, если две истории различны и ни одна

Р13

НИХ

не является частью дру-

гой,

следует разрешить возникший между заметками конфликт. Здесь необходимо

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

живанием составляющих заметку элементов. В том случае, если элемент изменя-

ется, последовательный номер, являющийся частью его идентификатора OID,

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

мент был изменен.

Объединенная

Реплика А Реплика В заметка

ОЮА

ilBllili

llililil

illlllll

OID в

OID

.«j^.^uj-v'.-'^'^

ЩТ''"у

Неизме

ненный

лемен

Элеме

нт.

измен енный

в реплике А

Элеме

,..^,,..,,,,^

нт.

измен енный

в реплике В

Рис.

11.21.

Безопасное объединение двух документов с конфликтующими

идентификаторами инициаторов

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

ного номера k. Если все изменения в Лл, имевшие место после последовательно-