Remote DataBroker
Business ObjectBroker
ConstraintBroker
MIDAS глазами программиста

Сформированная несколько лет назад концепция многоуровневых (multi-tier) приложений оказалась настолько удачной, что на ее основе немедленно стали готовить многие успешные решения, связанные с сетевой передачей данных и удаленными вычислениями. Становясь все более и более изощренными, многоуровневые системы не перестают удивлять своим изяществом.

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

С ростом значения сетевой обработки данных произошел качественный скачок программного обеспечения и средств разработки. Так, при создании приложений в среде пакета JBuilder компании Borland ваше приложение может выполнять обработку данных через один из выбранных вами нескольких промежуточных слоев. А в настоящий момент этой же компанией обнародована еще одна технология создания промежуточного программного обеспечения под названием MIDAS - по имени мифического царя, который превращал в золото все, к чему прикасался.

MIDAS - это аббревиатура, переводящаяся как "набор сервисов для многоуровневых распределенных приложений". За этим длинным названием скрываются компоненты, серверы и ключевые технологии для реализации многоуровневых приложений, расширяющие технологию Microsoft DCOM, впервые реализованную в операционной системе Windows NT 4.0. Технология MIDAS позволяет развертывать в вашей информационной системе распределенные бизнес-объекты, обладающие следующими характеристиками:

  • высокая скорость доступа к серверу при высоком уровне отказоустойчивости;
  • равномерная нагрузка на ресурсы сети;
  • высокоскоростное подключение к базам данных;
  • автоматическая публикация ограничений параметров БД.
В настоящий момент MIDAS является дополнением к пакету Borland Delphi 3 Client/Server и состоит из трех основных частей:
  • удаленного брокера данных (Remote DataBroker);
  • брокера бизнес-объектов (Business ObjectBroker);
  • брокера ограничений параметров (ConstraintBroker).
Способ их объединения между собой и другими уровнями понятен из рис. 1.

Рисунок 1.


Рассмотрим составляющие MIDAS.

Remote DataBroker

Удаленный брокер данных - это средство создания распределенных приложений для доступа к информации. Создав подобное приложение с помощью MIDAS, вы поразитесь его размеру - настолько оно будет маленьким. Это происходит потому, что ваша клиентская часть системы является "тонким клиентом", т. е. программой, не перегруженной выполнением сервисных функций. По сути дела ваше приложение - лишь интерфейс пользователя, тесно связанный с транспортными системами нижнего уровня (TCP/IP, Microsoft DCOM или Borland OLEnterprise), и Remote DataBroker, выполненным как динамическая библиотека размером в 140 Кбайт. При этом развертывание готового приложения упрощено до предела, так как нет необходимости в дополнительных настройках.

Модуль Remote DataBroker работает следующим образом. Запрос, посланный (обычно через транспортный протокол DCOM) программой-клиентом, принимает брокер, обрабатывает и отсылает (по специальному протоколу DataPacket) серверу. Сервер делает выборку данных, отсылает их модулю Remote DataBroker, который в свою очередь перебрасывает данные программе-клиенту.

Там они сохраняются в специально отведенном блоке памяти ClientDataset - одной из составных частей модуля Remote DataBroker. ClientDataset оснащен всеми необходимыми средствами для навигации, сортировки, фильтрации и редактирования данных, более того - можно сохранить выбранные данные на диске локального компьютера, с которого был послан запрос. При повторном запросе тех же данных Remote DataBroker поступает по-умному и загружает из БД лишь ту порцию данных, которая была изменена.

Business ObjectBroker

Брокер бизнес-объектов существует для выполнения весьма важной задачи - распределения вычислительной нагрузки по нескольким серверам. Конечно, вы можете сказать, что стандартные средства DCOM и так позволяют делать то же самое. Разумеется, но Business ObjectBroker делает лучше: в сотрудничестве с Borland OLEnterprise он добивается сбалансированной равномерной загрузки серверов и отслеживает отказы в распределенной среде.

Business ObjectBroker состоит из четырех утилит: 

  1. Business ObjectBroker - предоставляет глобальный реестр объектов серверам приложений, чтобы они могли найти подходящий сетевой сервер для подключения;
  2. Object Factory - одновременно клиент удаленных вызовов RPC и сервер автоматизации OLE, выполняющий роль удаленного клиента (proxi client). При удаленном вызове OLE запрос передается в виде удаленного вызова процедуры (RPC) от Object Agent клиентской машины к Object Factory;
  3. Object Agent - одновременно клиент удаленных вызовов RPC и сервер автоматизации OLE, выполняющий роль доверенного сервера (proxi server). Получая запрос, Object Agent трансформирует его так, чтобы он подходил по формату Object Factory, и пересылает ей полученный запрос;
  4. Object Explorer - утилита для просмотра и получения информации о сервисах и объектах, а также для экспорта объектов. Эта утилита обладает средствами поиска объектов как в локальном, так и в удаленных реестрах, загружая информацию о выбранном объекте в локальный реестр и делая объект доступным для использования.
Посмотрим на небольшом примере, как работает Business ObjectBroker. Допустим, у нас имеются два сетевых сервера, на каждом из которых установлен и зарегистрирован некий сервер приложений, выполненный как сервер автоматизации OLE. Когда программа-клиент запрашивает информацию о загрузке сервера приложений, Object Agent пытается обнаружить местоположение такого сервера, посылая запрос Business ObjectBroker, который просматривает реестр зарегистрированных серверов и возвращает адрес сервера обратно Object Agent. Последний связывается с выбранным сервером приложения и просит создать экземпляр. Если потребуется еще один экземпляр сервера приложений, то процесс поиска и связывания будет повторен, но теперь уже Object Agent получит ссылку на тот сервер, который имеет меньшую закрузку.

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

ConstraintBroker

Какую бы базу данных вы ни создавали, вопрос целостности данных остается актуальным. Особенно важно, чтобы все правила проверки информации были централизованы, а не разбросаны как бисер по всем базам данных и сети. MIDAS оснащен специальным брокером ограничений - ConstraintBroker, тесно работающим вместе с Remote DataBroker. Получив запрос от программы-клиента, Remote DataBroker проверяет, разрешено ли модулем ConstraintBroker дальнейшее движение, и если - да, то делает дополнительный запрос к словарю данных. Словарь данных представляет собой специальную таблицу, в которой кроме данных хранятся правила их представления и проверки; таблица может быть сохранена в любой базе данных, поддерживаемой библиотекой методов доступа к БД (Borland Database Engine - BDE).

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

При желании пользователь может настроить словарь данных собственными параметрами проверки и сообщениями об ошибке. А для того чтобы делать это было удобнее, можно применять утилиту SQL Explorer - своеобразный "центр управления" таблицами, ссылками, хранимыми процедурами, триггерами и правилами проверки данных.

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

MIDAS глазами программиста

Хотя технология и называется многоуровневой, компания Borland остановилась на трех уровнях:
  • сервере баз данных;
  • сервере приложений;
  • программе "тонкий клиент".
В качестве программы первого уровня могут выступать любые серверы БД: InterBase, Oracle, Sybase, MS SQL Server и т. д. Программное обеспечение двух других уровней строится с применением Delphi. Кроме того, сервер приложений оснащается средствами доступа к данным типа Borland Database Engine (BDE).

Delphi реализует технологию MIDAS с помощью компоненты. Эти компоненты образуют распределенный набор данных. В дополнение MIDAS использует продукт под названием OLEnterprise - систему для распределения вычислений и равномерной нагрузки на сеть, являющуюся в некотором роде альтернативой Microsoft DCOM. OLEnterprise не только выполняет транспортные пересылки, но и, в случае отказа одного из серверов, переключает поток запросов на работающие серверы, что обеспечивает общую "непотопляемость" системы.

С точки зрения программиста, использующего Delphi, система MIDAS - это четыре ключевых инструмента реализации распределенных наборов данных. Первые два располагаются со стороны сервера:

  • удаленные модули данных - весьма похожи на стандартные модули данных Delphi, но делающие данные доступными не только локальному приложению, но и в рамках всей сети. Для этого модуль данных превращается в COM-объект, позволяя к себе доступ через DCOM;
  • компонент TProvider - этот компонент располагается в удаленном модуле данных и включается в качестве свойства (property) в стандартные компоненты TTable и TQuery. Его назначение состоит в предоставлении физического доступа к таблицам баз данных по всей сети.
Со стороны клиентского приложения задействованы два компонента:
  • TRemoteServer - компонент, через который программа-клиент соединяется с сервером, а если конкретнее - с удаленным модулем данных на сервере. Именно TRemoteServer знает, как найти в реестре свободный сервер для подключения и производит само подключение;
  • TClientDataSet - компонент, подключающийся к TRemoteServer; играет ту же роль, что и компоненты TQuery и TTable, но для удаленных данных.
Рассмотрим процесс создания удаленного набора данных. Сначала создается простое Delphi-приложение, которое стандартным образом подключается к источнику данных, и сохраняется на диске. Затем командой File?New создается удаленный модуль данных, в который помещается один или несколько компонентов TProvider. Этот компонент присоединяется к объектам TTable или TQuery. Щелчком правой кнопки мыши на TProvider вызывается меню, из которого выбираются методы для доступа к удаленной машине. Достаточно запустить сервер, чтобы он зарегистрировал себя в реестре.

Теперь необходима настройка клиентской части системы. Для простоты предположим, что мы запускаем и сервер, и клиента на одной и той же машине. Сначала в контейнер кладется компонент TRemoteServer, причем его свойство ServerName устанавливается так, чтобы оно указывало на нужный нам сервер. После чего свойству Connected присваивается значение True. На следующем шаге добавляется компонент TClientDataSet и настраивается так, чтобы его свойство RemoteServer указывало на только что подключенный сервер, при этом свойство ProviderName настраивается на серверный компонент-поставщик набора данных. В заключение компоненты базы данных настраиваются на TClientDataSet. Все! Приложение готово к запуску. После запуска серверной части в реестре Windows под ключом HKEY_ CLASSES_ROOT появляется запись, ссылающаяся на имя сервера и удаленный модуль данных.

Итак, что предлагает нам использование многоуровневой технологии MIDAS компании Borland? Во-первых, отсутствие конфигурации на машине-клиенте. Во-вторых, получаемая система делится на логичные блоки, каждый из которых может выполняться на отдельном компьютере, разгружая сеть. В-третьих, получаемая архитектура надежна сама по себе и, кроме того, имеет встроенные средства обработки ошибок и сообщений о них. И наконец, пользователи переносных компьютеров могут синхронизировать данные на своих дисках с данными на серверах, используя известную всем пользователям Windows технологию "портфеля" (briefcase). Не исключено, что со временем MIDAS вытеснит ту модель баз данных, которая была принята с появлением пакета Delphi 2.0.

1129