Компьютер в бухгалтерском учете и аудите 1999'4
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Центр информационных технологий “Ост-Ин”

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

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

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

Приведем всего один пример из реальной жизни.

Крупное производственно-торговое объединение имеет сеть региональных торговых представительств по всей России, суммарный объем продаж через которую составляет существенную часть общего торгового оборота. Некоторые из представительств так или иначе компьютеризированы, однако сведения о продажах и движении денежных средств могут попасть в корпоративную БД только после доставки бумажных копий документов на головное предприятие. Для бухгалтерии это означает затяжной аврал в начале каждого месяца и массу ошибок при ручном вводе данных. Для менеджеров же отсутствие актуальной информации о состоянии рынка в том или ином регионе приводит к тому, что планы продаж, поставок, дистрибуции и, в конечном счете, производства зачастую составляются и корректируются не самым оптимальным образом, хотя используемая на головном предприятии корпоративная информационная система (КИС) в принципе поддерживает парадигму гибкого планирования.

Данный пример описывает именно тот случай, когда не требуется “реального времени” при обмене данными, однако степень актуальности информации должна быть достаточно высокой.

Разумеется, все эти проблемы далеко не новы, и задачи тиражирования данных так или иначе решаются в большинстве современных СУБД. Так надо ли открывать Америку ?

Если речь идет о вновь проектируемой системе или вся ваша корпоративная система, включая удаленные подразделения, выполнена на однородных, хорошо масштабируемых программных средствах, то в этом случае вам, пожалуй, удастся решить задачу репликации, используя штатные средства производителя СУБД.

Гораздо типичнее, однако, обратная ситуация: вам предстоит интегрировать унаследованный “зоопарк”, состоящий не только из различных платформ, но и из различных систем хранения-обработки данных. При этом у вас, как и у других сотрудников, будет желание не переделывать того, что уже давно хорошо и устойчиво функционирует.

система объектной репликации, разработанная специалистами ЦИТ “Ост-Ин”, представляет собой именно тот механизм, который позволяет решить задачи поддержки логической целостности данных при их тиражировании в разнородных системах.

Для разработки системы была использована комбинация Java/CORBA. Данный выбор был обусловлен именно теми штампами, которые неизбежно приводятся при упоминании об этих технологиях: настоящей “объектностью” и независимостью от платформ (Java) и настоящей “объектностью” и нейтральностью к языкам программирования (CORBA). Имели место и чисто прагматические соображения: ориентация на грандов компьютерной отрасли (Oracle, Sun, IBM), без продуктов которых не обходится ни одна — действующая в масштабе предприятия — информационная система.

И Java, и CORBA — открытые системы, описанные достаточно подробно и внятно, имеющие предсказуемую линию развития, что, безусловно, позволяет выполнять проекты на их основе так, чтобы создаваемый программный продукт не превратился в поделку-однодневку.

Репликационное приложение — это Java-код, который устанавливается во всех филиалах, где требуется репликация объектов местной базы данных в головное предприятие. Установка (загрузка) репликационного приложения в филиале должна быть произведена на одну из машин в рамках локальной сети, имеющей доступ к локальной базе данных, с одной стороны, и имеющей периодический либо постоянный доступ к репликационному приложению, находящемуся на головном предприятии, с другой. В минимальном варианте все программное обеспечение, включая коммуникационные программы, репликационное приложение и БД, может быть размещено на одном компьютере.

Репликационное приложение может работать в двух режимах: режиме ожидания репликационных соединений (сервер) и режиме, при котором производятся периодические попытки соединения с другими репликационными приложениями, работающими в режиме сервера (клиент). Для каждой из баз данных можно запускать одновременно два экземпляра репликационного приложения в разных режимах. Если на связь с сервером выходят одновременно несколько удаленных узлов, то сервер осуществляет взаимодействие с каждым из них в рамках отдельного потока выполнения, запускаемого в виртуальной машине Java.

Рисунок 1

На рис. 1 показаны взаимодействия репликационных приложений между собой и с базами данных при передаче объектов между базами данных. Цифрами помечены следующие процессы.

• Поизводится попытка соединения с локальной базой данных.

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

• Сервер производит попытку соединения с его локальной БД.

• Производится сеанс репликации объектов клиентской базы данных в серверную базу.

• Клиент, ранее занимавший активную роль в репликации собственных объектов, передает эту роль серверу.

• Производится сеанс репликации серверных объектов в клиентскую БД.

В процессе сеанса репликации из одной БД в другую происходит следующее.

• Производится выявление и исправление потенциальных ошибок, возможных при разрывах сеансов связи.

• Передаются объекты, которые были созданы, но еще не переданы в конкретную БД.

• Передаются изменения содержимого ранее переданных объектов.

• Производится удаление объектов в БД дальнего узла, которые были удалены в локальной БД и были ранее переданы в дальний узел. Удаление объектов в БД дальнего узла производится в порядке регистрации их удаления в локальной.

Для передачи каждого объекта или действий над объектами используются две параллельных транзакции — одна в удаленной БД, другая в местной. Перед передачей очередного объекта (действия) они открываются, при этом инициатором открытия транзакций является передающая сторона, то есть передающая сторона управляет обеими транзакциями. После завершения факта передачи объекта и окончания всех регистрационных действий передающая сторона производит попытку фиксации (commit) транзакции на удаленном узле. В случае неудачи (неполучения от удалённой СУБД подтверждения) локальная транзакция откатывается. После получения положительного ответа об окончании фиксации транзакции на удаленном узле производится фиксация местной. При возникновении какой-либо ошибки в процессе репликации производится откат обеих транзакций и завершение сеанса репликации. Протекание процесса репликации документируется в LOG-файлах на приемной и передающей сторонах.

В качестве реплицируемой единицы может выступать любой набор байтов, нужно лишь описать и организовать процесс формирования этого набора на передающей стороне и процесс осмысленной манипуляции с этим набором — на принимающей. Безусловно и то, что наиболее вероятным применением системы репликации является тиражирование информации, содержащейся в таблицах реляционных баз данных.

Для того чтобы “заставить” систему объектной репликации передавать информацию в соответствии с принятыми бизнес-правилами, необходимо:

• описать реплицируемые бизнес-объекты и сохранить это описание в том или ином виде;

• создать Java-классы, отвечающие за манипуляции с этими объектами;

• поставить экземпляр бизнес-объекта, подлежащий тиражированию, в очередь на реплицирование в конкретный удаленный узел (узлы);

• запустить репликационное приложение.

К описанию бизнес-объекта необходимо подходить прагматично и использовать характерные особенности формирования структур данных того хранилища, в котором этот объект создается, эволюционирует и прекращает свое существование. Так, при описании объекта, хранящегося в реляционной БД, целесообразно использовать следующие исходные понятия:

• во-первых, объект может обладать собственными данными или характеристиками, например, номер заказа, адрес партнера;

• во-вторых, могут существовать объекты, без которых данный объект не может появиться на свет. Например, объект “договор” не может существовать без “партнера”, аналогичная жизненная зависимость существует между накладной и подразделением, из которого опущен товар по накладной. По отношению к таким объектам описываемый объект считается подчинённым;

• в-третьих, некоторые объекты могут считаться необходимыми для своих главных объектов, например, пункт заказа считается необходимым для объекта, описывающего общие характеристики заказа (“шапка”).

На рис. 2 показана экранная форма, которая используется для описания бизнес-объектов и их связей. Обратите внимание на поле “Keeper Class” (на Рис. 2 обведено кругом). В этом поле прописывается имя класса, отвечающего за основные манипуляции с объектами данного репликационного типа. В данном примере этому классу дано имя SimpleRplTable не зря: в 99 % случаев он справится с любым репликационным типом и может поэтому считаться универсальным для данной реализации. В общем случае нестандартные классы приходится создавать, если БД приемника и источника информации имеют различные логические структуры данных, с которыми соотносится реплицируемый бизнес-объект, в частности, если вы обмениваетесь информацией между информационными системами разных производителей.

Рисунок 2

Следующий момент — постановка конкретного экземпляра бизнес-объекта на реплицирование. В связи с этим представляет интерес еще одно поле на форме (на рис. 2 указано стрелкой), где указываются узлы, в которые явно тиражируется объект данного репликационного типа при его создании или изменении.

Если объект помечен как неявно тиражируемый, то при его создании он вообще не будет поставлен в очередь на репликацию! Возникает вопрос: каким тогда образом удаленная БД получит, например, описание нужного ей товара (компонента, ингредиента)? И вот здесь начинают явственно проявляться преимущества правильно построенной объектной модели ваших бизнес-процессов. Если объекты и их взаимосвязи описаны аккуратно, вы можете рассуждать примерно так: “Для того чтобы торговое представительство могло отпускать товары клиентам, оно посредством репликации должно получить прайс-лист на товары. Это означает, что если прайс-лист после его формирования в БД головного предприятия будет поставлен на репликацию явно, с ним “уедет” введенный в прайс-лист товар, товары, которые входят в него (если это составной товар), свойства этих товаров, значения этих свойств, типы объектов учета, все раскрученные по иерархии номенклатурные группы, имеющие отношение к этому товару, и т.д.”. Построенная подобным образом логика передачи данных означает, что будут переданы только нужные данные, причем тогда, когда они действительно станут необходимыми для нормальной работы удаленного подразделения.

При перестройке по какой-либо причине уже готовой объектной модели все действия системного администратора головного предприятия будут сведены к нескольким щелчкам мыши в соответствующей экранной форме (см. рис. 3). После этого новые бизнес-правила будут автоматически реплицированы в соответствующие удаленные подразделения.

Рисунок 3

И в заключение необходимо добавить: когда тиражирование данных начинает активно использоваться, да еще при этом в качестве коммуникационной среды используется глобальная сеть Internet, вы неизбежно столкнетесь с суровой реальностью, имя которой — качество линий связи. Связь может отсутствовать или быть неустойчивой, и при разработке репликационных приложений это приходится учитывать. В описываемой системе объектной репликации принят ряд мер, позволяющих бороться со связью:

• во-первых, с помощью внешних настроек вы можете задать пакетный режим передачи объектов, опытным путем подобрав, какой размер буфера (в объектах!) является оптимальным в вашем случае. При этом вы уменьшаете объем служебной информации, передаваемой по линиям связи при обмене объектами;

• во-вторых, вы можете, опять же с помощью настроек, задать режим так называемой неконсистентной фиксации транзакций. В этом случае вы разрешите, например, частичную запись в БД-приемник передаваемых пунктов прайс-листа. С помощью специальной утилиты или настроек репликационного приложения вы впоследствии можете “докачать” оставшиеся непереданными после разрыва связи объекты;

• наконец, одно из фирменных блюд Java — задав (настройками!) использование базовых классов языка, предназначенных для компрессирования/декомпрессирования потока выходных/входных данных, вы можете добиться существенного уменьшения трафика.

Copyright © 1994-2016 ООО "К-Пресс"