В данной статье описывается система объектной репликации, основанная на комбинации Java/CORBA/Internet.

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

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

2. Снабженческое подразделение крупнейшего горно-металлургического комбината управляет поставками оборудования, сырья, материалов через перевалочные пункты - порты: речные, морские и аэропорты для обеспечения непрерывного производственного процесса. Это - десятки тысяч контейнеров, которые могут накапливаться, теряться, повреждаться в промежуточных пунктах доставки. При срыве ритмичности поставок необходимо принимать экстренные меры (если, конечно, не идти по простому, но экономически невыгодному пути накопления «запаса» на конечных складах). Именно поэтому актуальная информация о месте нахождения и состоянии объекта доставки, вводимая в базы данных перевалочных пунктов и реплицируемая затем в базу данных комбината, имеет для снабженцев принципиальное значение.

3. Предприятие транспортировки газа (нефти) располагает массой технологического оборудования, автотранспортной техники, приборов, запасных частей и т.п., приписанных к десяткам подстанций, расположенных вдоль газопровода (нефтепровода) протяженностью в сотни километров. Состояние труб, местонахождение и состояние техники в детальном виде заносится в локальные базы данных подстанций. Головному предприятию в ряде случаев необходимо получить оперативную информацию о состоянии дел, например, для переброски техники и оборудования при проведении неотложных ремонтных работ, выдаче срочно понадобившихся отчетов «наверх» и т.п.

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

Нужен ли другой путь?

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

Если речь идет о вновь проектируемой системе или (вот удача!) вся корпоративная система заказчика, включая удаленные подразделения, выполнена на однородных, хорошо масштабируемых программных средствах, то в этом случае, пожалуй, удастся решить задачу репликации, используя штатные средства СУБД. Типична, однако, обратная ситуация, при которой предстоит интегрировать унаследованный «зоопарк», состоящий не только из различных платформ, но и из различных систем хранения-обработки данных. При этом у вас будет присутствовать желание не переделывать то, что уже давно хорошо и устойчиво функционирует.

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

Рассмотрим, например, ситуацию для примера 1, при которой первоначально было принято решение о том, что безналичные платежи за товар клиенты направляют в отделение банка по месту нахождения головного предприятия, а получают товар в одном из региональных торговых представительств. Если в качестве СУБД используется Oracle, то достаточно реализовать репликацию с помощью моментальных снимков «только для чтения», чтобы сведения о платежах клиентов, вводимые в головном предприятии, попадали в обслуживающее их торговое представительство. Все худо-бедно работает, пока по тем или иным соображениям (например, некоторое торговое представительство выделяется в самостоятельное юридическое лицо) не принимается решение о том, что теперь клиенты представительства должны переводить деньги в банк по месту приобретения товаров. Это принципиально меняет модель репликации - теперь системным администраторам и программистам для перехода на новые бизнес - правила придется проделать большой объем работы и в головном предприятии, и в самом представительстве. При этом работа по изменению ПО ведется в рамках чисто реляционной модели, которая, как известно, не содержит в явном виде информации о бизнес - процессах. Если теперь при очередном реинжиниринге будет принято решение о том, что обслуживание клиентов будет выполняться только в соответствии с договорами, заключаемыми на головном предприятии, то вся работа может начаться сначала (поскольку при этом ввод сведений о новом клиенте будет производиться только на головном предприятии).

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

Этим незамысловатым примером мы хотели продемонстрировать, что в описываемой системе объектной репликации модель тиражирования отделена от модели данных, благодаря чему процесс администрирования системы при перестройке бизнес-процессов существенно упрощается и ведется в «объектных», более естественных терминах.

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

Вы, конечно, улыбнетесь, но выбор комбинации Java/CORBA для разработки системы объектной репликации был обусловлен именно теми штампами, которые неизбежно приводятся при упоминании этих технологий: настоящей «объектностью» и независимостью от платформ (Java), а также настоящей «объектностью» и нейтральностью к языкам программирования (CORBA). И Java [1], и CORBA [2]- открытые системы, описанные достаточно подробно и внятно, имеющие предсказуемую линию развития, что, безусловно, позволяет выполнять проекты на их основе так, чтобы создаваемый программный продукт не превратился в поделку-однодневку. При этом у программистов и системных администраторов имеется определенная свобода выбора средств достижения поставленной перед ними задачи. Имели место и чисто прагматические соображения: ориентация на грандов компьютерной отрасли (Oracle, Sun, IBM).

Затронем, например, проблему выбора коммуникационной среды при создании широкомасштабной корпоративной сети. Самое экономически выгодное и само собой напрашивающееся решение - это Internet. Стандартный протокол взаимодействия брокеров объектных запросов в CORBA так и называется - Internet Inter-ORB Protocol (IIOP). Но при организации сети путем подключения к ней удаленных подразделений через местных Internet-провайдеров сразу всплывает такая захватывающая тема, как информационная безопасность. Соответствующие службы компаний будут требовать, чтобы, пролетая по Internet, объекты были опознаны только теми, кому они адресованы. Проблему аутентификации (и даже шифрования данных) можно решать, используя, например, коммерческие программные продукты, реализующие VPN-протокол для создания виртуальных частных сетей. Более элегантное решение можно будет получить при появлении на рынке брокеров объектных запросов, реализующих один из предусмотренных в стандарте CORBA служб - Security Service, тем более что разработчики стандарта обещают прозрачную интеграцию исходного компонента с любым набором стандартных сервисов CORBA.

Как происходит репликация

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

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

Рис. 1. Схема репликации

(1) - соединение с локальной базой данных;

(2) - соединение с репликационным приложением, работающим в режиме сервера;

(3) - соединение сервера со своей локальной базой данных;

(4) - сеанс репликации объектов клиентской базы данны

На рис. 1 приведена схема взаимодействия репликационных приложений между собой и с базами данных при передаче объектов. С помощью внешних настроек можно изменить такую последовательность передачи объектов между узлами. Процесс сеанса репликации из одной базы данных в другую предусматривает следующие операции:

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

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

Как описать реплицируемые объекты

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

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

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

Это - самая общая схема настройки процесса обмена требуемыми данными. В конкретных реализациях желательно иметь также джентльменский набор сервисных средств, готовых решений и действий по умолчанию. Имеется практическая реализация описываемой системы объектной репликации, в связке Oracle8 Enterprise Edition/Sun Enterprise 4500 — Oracle8 Personal Edition/ Windows95, в которой предусмотрены упомянутые средства.

К описанию бизнес - объекта необходимо подходить прагматично и использовать характерные особенности формирования структур данных того хранилища, в котором этот объект создается, эволюционирует и прекращает свое существование. Так, при описании объекта, хранящегося в реляционной базе данных, целесообразно использовать следующие исходные понятия. Во-первых, объект может обладать собственными данными или характеристиками, например, номер «заказа», адрес «партнера». Во-вторых, могут существовать объекты, без которых данный объект не может появиться на свет. Например, объект «договор» не может существовать без «партнера». Аналогичная жизненная зависимость имеется между накладной и подразделением, из которого отпущен товар по накладной. По отношению к таким объектам описываемый объект считается подчинённым. В-третьих, некоторые объекты могут считаться необходимыми для своих главных объектов, например, пункт заказа считается необходимым для объекта, описывающего общие характеристики заказа («шапка»). Таким образом, реплицируемый объект может состоять только из примитивных данных (полей) и из ссылок на другие реплицируемые объекты.

Рис. 2. Экранная форма программы реплицирования

Экранная форма, использующаяся для описания бизнес - объектов и их связей, приведена на рис. 2. В поле «Keeper Class» прописывается имя класса, отвечающего за основные манипуляции с объектами данного репликационного типа. В данном примере этому классу дано имя SimpleRplTable и его можно считать стандартным для большинства репликационных типов. В общем случае нестандартные классы приходится создавать, если база данных приемника и источника информации имеют различные логические структуры данных, с которыми соотносится реплицируемый бизнес-объект, в частности, если вы обмениваетесь информацией между информационными системами разных производителей.

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

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

А что произойдет, если объект уже был передан ранее? Если он не изменился, с момента последнего сеанса, то повторно он передаваться не будет. А что случится, если изменится некоторое свойство объекта, переданного ранее и явно не реплицируемого? Модифицированный компонент объекта (свойство) встанет в очередь на репликацию и передастся в ходе ближайшего сеанса связи. Кстати говоря, могут быть случаи, когда объект явно не реплицируется, но должен быть передан в удаленное подразделение, не ожидая, пока его подхватит некий зависящий от него другой объект. Например, ваша бизнес-логика построена так, что если в головном предприятии ввели клиента некоторого торгового представительства, а справочник контрагентов не предусматривает привязки к конкретному филиалу, то клиент «уедет» в это представительство при первом же безналичном платеже. Однако этот клиент может изъявить желание приобрести товары за наличный расчет. В этом случае сведения о нем должны быть высланы в удаленный филиал принудительно.

GZIP?ом по бездорожью

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

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

Если теперь прайс-лист на 500 позиций ужат до 1 Кбайт, то у вас должна появиться уверенность в том, что система объектной репликации будет выполнять возложенные на нее функции, на радость пользователям, программистам и, конечно, руководству.

Заключение

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

Об авторах

Виктор Хенкин — технический директор компании «Ост-Ин». Сергей Навроцкий — ведущий специалист компании «Ост-Ин» по Java-технологиям. С ними можно связаться по электронной почте по адресам vic/sergey@ostin.ru.

Литература

[1] Дэвид Фленэген. Java in a nutshell. Издательство BHV, 1998 г.

[2] Роберт Орфали, Дан Харки, Джери Эдвардс. Основы CORBA. Издательство «Малип», 1999 г.