 |
|
Рассмотрим, что представляют собой технологии, используемые в MIDAS.
Remote Data Broker позволяет создавать распределенные трехзвенные
информационные системы, состоящие из серверной СУБД, среднего звена и "тонкого"
клиента, при этом среднее звено может в общем случае состоять из нескольких
серверов приложений и функционировать на нескольких компьютерах. Заметим,
что "тонкий" клиент представляет собой приложение, не содержащее бизнес-правил,
а лишь предоставляющее интерфейс пользователя, и по этой причине не требующее
почти никаких дополнительных библиотек (кроме dbclient.dll размером 140
K), используемых обычными "толстыми" клиентами для доступа к данным (таких,
как Borland Database Engine и клиентская часть серверных СУБД) и, соответственно,
практически не нуждающееся в соответствующей настройке. Типичным примером
такого клиентского приложения является исполняемая в Web-броузере форма
ActiveX (созданная с помощью Delphi 3), содержащая интерфейсные элементы
для отображения и редактирования данных, вся процедура инсталляции и настройки
которого заключается в загрузке соответствующей Web-страницы из Internet
или локальной сети.
Источником данных для "тонкого" клиента является сервер приложений,
получающий от клиента запросы на выборку или изменение данных. При получении
такого запроса сервер приложений обращается к серверу баз данных, клиентом
которого он является, со своим собственным запросом. Получив от сервера
результат выполнения собственного запроса, сервер приложений передает данные
клиенту.
Как только клиент получает набор данных от сервера приложений, этот
набор может быть использован компонентом TClientDataset, который, наряду
с компонентами TRemoteServer или TMidasConnection (появившимся в Delphi
3.01 и обладающим по сравнению TRemoteServer большей функциональностью,
в частности, возможностью выбора способа доступа к серверу), а также поддерживающей
их функционирование библиотекой dbclient.dll, составляет клиентскую часть
Remote DataBroker.
Компонент TClientDataSet предназначен для хранения данных, полученных
от сервера приложений, в кэше клиента, и, будучи потомком компонента TDataSet,
обладает, подобно компонентам TTable и TQuery, как навигационными методами,
так и методами, осуществляющими редактирование данных. Кроме того, этот
компонент обладает методами SaveToFile и LoadFromFile, позволяющими сохранять
данные из кэша в файле и восстанавливать их оттуда, реализуя так называемую
"briefcase model" - модель обработки данных, основанную на том, что "тонкий"
клиент осуществляет редактирование данных по большей части при отсутствии
соединения с сервером, используя лишь кэш или локальные внешние устройства,
и лишь иногда соединяется с сервером приложений для передачи ему измененных
данных с целью дальнейшей обработки.
Отметим также, что Remote DataBroker предоставляет широкие возможности
для решения характерных для многопользовательского доступа к данным проблем,
связанных с попытками одновременного редактирования несколькими пользователями
одних и тех же данных. Отметим, что в данном случае механизм блокировок,
используемый в традиционной двухзвенной модели "клиент/сервер", может оказаться
неэффективным или даже неприемлемым, так как промежуток времени между редактированием
записи и сохранением ее в базе данных может быть весьма длительным. Поэтому
при попытке сохранения сервером приложений измененной записи в базе данных
производится поиск изменяемой записи либо по ключевому полю, либо по всем
полям в зависимости от значения свойства UpdateMode ответственного за этот
процесс компонента TDBDataSet на сервере приложений и сравнение всех полей
изменяемой записи с исходными значениями (т.е. теми, которые были в кэше
клиента на момент получения этой записи с сервера до того, как пользователь
изменил в кэше эту запись). Если какие-либо поля за время между получением
оригинала записи клиентом и попыткой сохранить изменения были модифицированы
другим пользователем, запись может быть передана обратно в клиентское приложение
для дальнейшей обработки пользователем.
Отметим также, что удаленные модули данных (объекты Remote Data Module),
входящие в состав серверной части Remote DataBroker и содержащие компоненты
TDBDataSet, позволяют предоставить DCOM-интерфейс для соответствующих объектов,
делая их управляемыми извне и превращая, таким образом, сервер приложений
в DCOM-сервер. Осуществляется такая публикация объектов путем выбора опции
экспорта из удаленного модуля данных из контекстного меню соответствующего
компонента при разработке сервера приложений.
При использовании сервера приложений как DCOM-сервера требуется наличие в реестре компьютера, содержащего сервер приложений, соответствующего описания прав доступа к нему различных пользователей (или групп пользователей) сети, для чего требуется экспорт сведений о пользователях сети с первичного контроллера домена. При этом на тех компьютерах, где эксплуатируются клиентские приложения, требуется наличие в реестре описания сервера приложений с указанием, на каком конкретном компьютере сети этот сервер должен функционировать. Иными словами, при использовании технологии DCOM каждый клиент, нуждающийся в сервере приложений, может взаимодействовать только с одним конкретным компьютером, на котором имеется подобный сервер, сколько бы их ни было в сети. В этом случае информационная система не имеет никакой защиты от сбоев, связанных с перегрузкой сервера приложений или с его отказом по каким-либо иным причинам.
Использование Business ObjectBroker и OLEnterprise (составной части MIDAS) позволяет решить подобную проблему (при этом несущественно, какое средство разработки использовалось для создания сервера приложений, лишь бы это был сервер OLE Automation).
 |
Business ObjectBroker осуществляет для "тонкого" клиента поиск нужного сервера приложений среди опубликованных (то есть доступных извне) частей реестров компьютеров сети (совокупность опубликованных частей реестров иногда называется глобальным реестром - global registry).
Приложение Object Factory, используемое сервером, является клиентом OLE Automation. Оно действует на сервере от имени удаленного клиента, "представляя" его путем воспроизведения его запросов. Со стороны клиента имеется соответствующий "представитель" удаленного сервера приложений - Object Agent, являющийся сервером OLE Automation. Получив запрос к удаленному серверу, Object Agent направляет его к Object Factory, используя механизм вызова удаленных процедур (RPC - Remote Procedure Call).
 |
Утилита Object Explorer (рис.3), входящая в состав OLEnterprise, позволяет
просматривать локальный и глобальный реестры, а также осуществлять экспорт
(публикацию) сведений об объектах из локального реестра в глобальный и
импорт этих сведений из глобального реестра в локальный, осуществляя, таким
образом, межреестровый обмен сведениями об удаленных серверах приложений
в сети. Если в сети имеется несколько компьютеров, на которых установлен
и зарегистрирован один и тот же сервер приложений, при запросе "тонкого"
клиента Object Agent обратится к Business ObjectBroker за сведениями о
местоположении сервера, а тот, в свою очередь, найдет для него в глобальном
реестре один из этих компьютеров. После этого Object Agent обратится к
Object Factory выбранного компьютера, инициируя создание экземпляра удаленного
модуля данных на сервере приложений.
Каков принцип выбора одного сервера приложений из нескольких? В настоящее
время сервер выбирается случайным образом среди компьютеров, доступных
в сети. В случае отказа одного из серверов для соединенных с ним клиентов,
не получивших отклика от сервера, будет автоматически повторена процедура,
описанная выше, и эти клиенты будут соединены с оставшимися серверами случайным
образом без участия пользователя и незаметно для него. В настоящее время
ведется разработка более эффективной технологии выбора сервера, использующей
сведения о загрузке процессоров и сетевом трафике функционирующих в сети
серверов, что позволит более равномерно распределять нагрузку между серверами.
Отметим также, что в глобальный реестр можно включать сведения об RPC-серверах,
функционирующих не только в операционных системах Windows 95 и Windows
NT, но и в других операционных системах.
Еще одной важной составляющей частью MIDAS является ConstraintBroker,
предоставляющий возможность использовать бизнес-правила сервера баз данных
"тонким" клиентом. Обычно при проектировании баз данных бизнес-правила
и правила ссылочной целостности реализуются в виде объектов базы данных,
таких как индексы, триггеры, хранимые процедуры. Такой подход к проектированию
данных позволяет использовать эти объекты различными клиентскими приложениями
без написания дополнительного кода.
В случае классической двухзвенной клиент-серверной информационной системы
при изменении данных клиентское приложение пытается отправить измененную
запись на сервер, а сервер, в свою очередь, пытается сохранить ее в базе
данных, начав соответствующую транзакцию. Если запись не удовлетворяет
условиям ссылочной целостности, определенным на сервере, производится откат
транзакции, и сервер возвращает клиентскому приложению сообщение об ошибке,
после чего пользователь должен будет скорректировать предназначенные для
сохранения данные. Если подобные случаи происходят часто, это приводит
к перегрузке сети и увеличению времени отклика сервера.
Чтобы уменьшить количество отправляемых на сервер некорректных записей,
иногда часть бизнес-правил воспроизводят в клиентском приложении. В этом
случае частичный контроль соответствия записи бизнес-правилам производится
без обращения к серверу, но возможность отправки некорректной записи все
же сохраняется, так как обычно код, содержащийся в хранимых процедурах
и триггерах, в клиентских приложениях не воспроизводится. Кроме того, при
изменении бизнес-правил такое приложение требует внесения в него изменений,
что влечет за собой трудозатраты, связанные с установкой и конфигурацией
новой версии на рабочих станциях.
При использовании ConstrainBroker эта проблема решается по-другому.
В этом случае RemoteDataBroker не только доставляет данные клиентскому
приложению, но и обращается к словарю данных с целью получения ограничений
сервера и передачи их клиенту. Соответственно при попытке передачи записи
на сервер приложений анализ соответствия записи правилам сервера производится
непосредственно в клиентском приложении без обращения к серверу баз данных
и серверу приложений, что снижает загрузку серверов и сети. Отметим, что
при изменении бизнес-правил следует внести соответствующие изменения в
словарь данных, что можно сделать с помощью входящей в состав MIDAS утилиты
SQL Explorer(рис.4), позволяющей вносить серверные ограничения, а также
создавать и изменять таблицы, индексы, триггеры, хранимые процедуры, правила
ссылочной целостности.
 |
Таким образом, использование технологии MIDAS позволяет создавать многозвенные
информационные системы с "тонким" клиентом, не нуждающимся в инсталляции
и настройке, обеспечивая защиту от сбоев в работе серверов приложений,
а также снижение загрузки серверов и сети за счет переноса бизнес-правил
и серверных ограничений в клиентское приложение вместе с данными.
В заключение отметим, что разработка серверов приложений с помощью
Delphi 3 может быть осуществлена с помощью trial-версии MIDAS, входящей
в комплект поставки Delphi 3 Client/Server Suite и имеющей ограниченное
число подключаемых клиентов и объектов, доступных Business ObjectBroker,
а также ограничения на время работы ConstrainBroker. Однако эксплуатация
серверов приложений требует обязательного наличия на компьютерах, содержащих
серверы приложений, полной версии MIDAS (рис.5), не обладающей вышеперечисленными
ограничениями.
 |
Координаты автора:
Учебно-консалтинговый центр Interface Ltd.,
Тел. (095)135-55-00, 135-25-19, 135-77-81,
e-mail: mail@interface.ru,
http://www.interface.ru