Содержание к диссертации
Введение
ГЛАВА 1. Анализ современного состояния технологии репликации данных субд с использованием различных методов 12
1.1. Исследование особенностей организации и классификация современных технологий репликации данных субд 12
1.1.1. Репликация программным методом 12
1.1.2. Промышленные методы и механизмы тиражирования данных. 13
1.2. Исследование методов выявления данных субд участвующих в репликации 17
1.2.1. Применение триггеров субд. 17
1.2.2. Монитор обработки транзакций 19
1.2.3. Вызовы удаленных процедур rpc. 21
1.2.4. Службы преобразования данных dts. 22
1.3. Исследование механизмов передачи реплицируемых данных в распределенной системе 22
7.5. /. Механизм передачи сообщений через электронную почту. 23
1.3.2. Передача данных через ftp сервера 23
1.3.3. Метод прямого соединения в реальном времени 24
1.4. Исследование методов сжатия передаваемых данных 24
1.4.1. Кодирование хаффмана 25
1.4.2. Динамическое кодирование хаффмана 27
1.4.3. Кодирование lzw. 29
1.4.4. Сравнительный анализ динамических методов сжатия 30
1.5. Исследование методов и алгоритмов защиты данных от не санкционированного доступа 32
1.5.1. Криптосистема без передачи ключей 33
1.5.2. Криптосистема с открытым ключом 34
1.5.3. Электронная подпись 36
1.6. Анализ проблем возникающих при репликации информации 37
1.6.1. Конфликт времени-выполнения операции над данными 38
1.6.2. Поддержка целости данных БД в распределенных системах... 38
1.7. ПОСТАНОВКА ЗАДАЧИ 38
Выводы 41
ГЛАВА 2. Разработка методов увеличения производительности системы репликации данных субд независимых платформ в распределенных системах 42
2.1. Математическая модель информационного процесса репликации данных субд 42
2.2. Разработка методики авторизации удаленных клиентов 44
2.2.1. Анализ отказоустойчивости работы алгоритмов авторизации пользователей 46
2.3. Разработка методики формирования данных участвующих в репликации 48
2.3.1. Математическая модель журнала транзакций 52
2.4. Методика разрешения конфликта времени-выполнения операций надданными 54
2.5. Методика поддержки целостности данных субд в распределенной системе 54
2.6. Разработка структур данных необходимых для передачи транзакций и системных данных 56
2.7. Разработка методики адаптации системы репликации данных к различным платформам субд 59
Выводы 65
Глава 3. Разработка структурной и функциональной модели системы репликации данных и моделей данных для субд независимых платформ в распределенных системах 67
3.1. Разработка архитектуры системы репликации данных 67
3.2. Структурная модель системы репликации данных 69
3.2.1. Структура публикатора и подписчика 69
3.2.2. Структура репликатора транзакций 70
3.2.3. Структура модуля доступа к субд. 72
3.2.4. Структура модуля настройки и адм инистрирования 74
3.3. Функциональная модель системы репликации данных 76
3.4. Модель данных системы репликации данных 84
3.4.1. Модель журнала транзакций. 85
3.4.2. Модель таблиц схемы репликации данных 86
3.4.3. Модель полей схемы репликации данных 87
3.4.4. Модель действий транзакций 87
3.4.5. Модель пользователей системы репликации данных 88
3.4.6. Модель обслуживания сессии пользователя 89
3.4.7. Модель версии схемы репликации 89
3.4.8. Модель обслуживания схемы репликации 90
3.5. Алгоритмическое обеспечение системы репликации данных 91
Выводы 103
Глава 4. Методы и средства программной реализации системы репликации данных 104
4.1. Выбор программно-аппаратной платформы 104
4.2. Выбор инструментальных средств 105
4.3. Выбор средств коммуникации узлов 108
4.4. Метод реализации коммуникации узлов на базе интерфейса windows-sockets api 110
4.5. Протокол взаимодействия распределенных узлов системы репликации данных 113
4.6. Интерфейс администрирования схемы репликации данных 114
Выводы 116
Заключение 117
Список литературы
- Исследование методов выявления данных субд участвующих в репликации
- Анализ отказоустойчивости работы алгоритмов авторизации пользователей
- Структурная модель системы репликации данных
- Метод реализации коммуникации узлов на базе интерфейса windows-sockets api
Введение к работе
В настоящее время информационная инфраструктура современных предприятий и организаций, к которым можно отнести и высшие учебные заведения, носит все более распределенный характер. Уровень принимаемых управленческих решений, контроль и управление информационными ресурсами требует все большей децентрализации. Структура современных организаций представляет собой разветвленную схему, в состав которой входят десятки территориально разделенных подразделений, функционирование которых, друг без друга, часто, вообще не возможно, а так же взаимодействие между структурой других организаций. При этом качество функционирования такой сложной, корпоративной системы во многом зависит от применяемых в ее деятельности новейших информационных технологий. Основной проблемой при автоматизации распределенных систем является организация обработки распределенных данных.
Актуальность темы. Применение технологии тиражирования данных [1], является важным этапом в успешной работе предприятия. Внедрение данной технологии обеспечивает гарантированную доставку, своевременность и целостность передаваемых данных. Репликация данных предполагает их дублирование в различных узлах компьютерной сети. При этом любая база данных (БД) является локальной (как для СУБД, так и для пользователя, работающего с ней), т.е. данные всегда размещаются локально на том узле сети, где они обрабатываются, и все транзакции в системе завершаются локально. Эффективность технологии репликации данных в распределенной системе зависит от того, какие операции выполняются в системе [2]. Так, операция чтения объекта в репликационной схеме выполняется локально в узле сети, это быстрее и дешевле, чем чтение объекта с удаленного компьютера сети. Поэтому, тиражирование данных в как можно большее количество узлов распределенной системы с часто повторяющимися запросами на чтение является
предпочтительным, т.к. снижает нагрузку с центрального сервера. С другой стороны, если в распределенной системе происходит интенсивное обновление информации, т.е. преимущественно выполняются операции записи, то репликационная схема должна быть построена по принципу "направленного" тиражирования, при этом снижаются затраты на пересылку данных. Тем самым подход, основанный на анализе интенсивности операций "чтение-запись" в распределенных системах, обеспечивает возможность построения рациональных, в смысле технико-экономических показателей, алгоритмов тиражирования данных. В тоже время, размещение дорогостоящих СУБД в различных распределенных точках, где скорость обработки данных не играет роли, является не всегда оправданным [3, 4].
Концепции построения систем репликации данных исследовались в СО РАН, в Санкт-Петербургском государственном университете, в Томском государственном политехническом университете, а так же в работах: Новикова Б.А. «Методы и средства организации хранения в системах баз данных нового поколения»; Макарова СВ. «Управление обновлениями в СУБД расширенной архитектуры "Клиент-сервер»; Курбанова ЯЗ. «Разработка алгоритмов и программ для управления процессами решения взаимосвязанных задач в системе распределенной обработки данных»; Богдановой О.В. «Разработка методов моделирования и оптимизации распределенных систем обработки данных на локальных вычислительных сетях»; Мачтакова С.Г. «Разработка моделей и программного обеспечения распределенной информационной системы». Среди иностранных авторов можно выделить James V. Hansen, Tom Swan, Peter Garrison, Tomas Delamarter.
Цель работы. Целью диссертационной работы является создание системы репликации данных и разработка на этой основе алгоритмов и методов тиражирования информации в распределенных системах, а так же исследова
ниє методов адаптации системы репликации данных к различным платформам СУБД.
Для достижения намеченной цели были поставлены и решены следующие задачи:
? исследование структур данных формирующихся для репликации и разработка на их основе типов данных для передачи информации;
? разработка структуры журнала транзакций и структур данных для хранения схемы репликации;
? разработка методики выявления данных участвующих в репликации;
? разработка методики авторизации удаленных клиентов;
? разработка модели автоматизированной системы репликации данных не зависящей от платформы СУБД и адаптацию, на основе этой модели, к различным платформам;
? разработка методики разрешения конфликта времени-выполнения операций над данными и методики поддержки целостности данных СУБД в распределенной среде;
? разработка программного комплекса системы репликации данных СУБД независимых платформ;
Структура диссертационной работы. Диссертационная работа состоит из введения, четырех глав и заключения.
В первой главе проведен анализ методов построения систем репликации данных СУБД. Рассмотрены общие принципы построения систем репликации данных. Описаны методы, позволяющие передавать данные в распределенной системе, способы сжатия информации и алгоритмы авторизации и защиты информации. Сформулированы специфические требования к системам репликации данных СУБД.
Во второй главе разработан метод авторизации удаленных клиентов, метод разрешения конфликта времени-вьшолнения операций над данными и метод поддержки целостности данных СУБД в распределенной системе. Про
ведено исследование структур данных необходимых для передачи реплици-руемой информации, на основании чего, были разработаны типы данных, позволяющих временно хранить передаваемые данные. Предложен метод адаптации системы репликации данных к различным платформам СУБД.
В третьей главе разработаны методы и алгоритмы адаптации СРД СУБД независимых платформ. Разработана система управления реплицируе-мыми данными, обеспечивающая синхронизацию распределенных СУБД.
В четвертой главе проведены анализ и выбор программно-аппаратной платформы, языка программирования и инструментальных средств, программной реализации системы репликации данных СУБД независимых платформ. Разработана методика программной реализации подсистем и системы репликации данных СУБД независимых платформ в целом.
Научная новизна. Основные результаты диссертационной работы получены впервые, в частности:
1. разработана модель автоматизированной системы репликации данных, не зависящей от платформы СУБД. В рамках разработанной модели предложены:
- методика разрешения конфликта времени-выполнения операций над данными;
- методика поддержки целостности данных СУБД в распределенной среде;
- методика выявления данных, участвующих в репликации.
- модификация математической модели журнала транзакций;
2. разработан программный комплекс системы репликации данных СУБД независимых платформ;
Степень обоснованности научных положений, выводов и рекомендаций. В диссертационной работе использованы методы оптимизации, аппарата теории множеств, теории автоматов и структурного анализа. При программ
ной реализации разработанных методик и алгоритмов использованы технологии объектного, структурного и модульного программирования.
Кроме того, для предложенного способа репликации данных и последующей адаптации системы репликации данных к различным платформам СУБД проведено экспериментальное исследование.
Практическая ценность. На основе проведенных исследований и предложенных методик разработано программное обеспечение системы репликации данных, проведена адаптация СРД к различным платформам СУБД, позволяющая, в частности, синхронизировать данные между такими СУБД, как MS SQL Server 7.0 - 2000, Sybase SQL Anywhere 5.0, Interbase 5.0 - 6.0, Oracle 9.0. и пр. В результате исследований и разработок получены следующие результаты:
разработана система репликации данных, функционирующая с различными платформами СУБД;
разработаны средства, позволяющие реплицировать данные в распределенной среде, используя каналы глобальной сети Internet или альтернативные каналы связи с помощью сетевых протоколов.
Результаты диссертационной работы внедрены в Московской государственной академии приборостроения и информатики и ЗАО «Домбытхим». Программные разработки, полученные в диссертации, зарегистрированы в Отраслевом фонде алгоритмов и программ, свидетельство о регистрации № 2447.
Апробация результатов. Основные результаты диссертационной работы докладывались на:
Международной научно-технической конференции "Информационные технологии в открытом образовании", октябрь 2001г., в г. Москве;
Научно-технических конференциях и семинарах кафедр «Автоматизированные системы управления и обработки информации» и «Персональные компьютеры и сети» МГАПИ. Основные результаты диссертационной работы изложены в девяти публикациях:
1. Голубятников И.В., Сергеев И.В. Методы восстановления баз данных после сбоев // Международная научно-техническая конференция "Информационные технологии в открытом образовании", 11-12 октября 2001г., Москва. Тезисы докладов, сс.144-151.
2. Голубятников И.В., Сергеев И.В.. Программный комплекс репликации данных серверов баз данных // Программное и информационное обеспечение систем различного назначения на базе персональных ЭВМ. Межвузовский сборник научных трудов. Под ред. д.т.н., проф. Михайлова Б.М. -М.:МГАПИ, 2001. сс.72-74.
3. Сергеев И.В.. Обзор существующих методов репликации данных // Программное и информационное обеспечение систем различного назначения на базе персональных ЭВМ. Межвузовский сборник научных трудов. Под ред. д.т.н., проф. Михайлова Б.М. - М.:МГАПИ, 2001. ее. 156-158.
4. Голубятников И.В., Брейман А.Д., Сергеев И.В.. Формирование СУБД независимых решшкационных данных // Программное и информационное обеспечение систем различного назначения на базе персональных ЭВМ. Межвузовский сборник научных трудов. Под ред. д.т.н., проф. Михайлова Б.М. - М.:МГАПИ, 2001. сс.51-53.
5. Голубятников И.В., Матвеев Ю.В., Сергеев И.В. Модели индексирования и поиска информации в СУБД // Системный анализ, информатика и оптимизация. Сборник научных трудов. Под ред. д.т.н., проф. Букреев В.З.- М.гРЗИТЛП, 2001. сс.87-95.
6. Голубятников И.В., Брейман А.Д., Матвеев Ю.В., Сергеев И.В. Архитектура и взаимодействие с СУБД современных информационно-поисковых систем // Системный анализ, информатика и оптимизация. Сборник научных трудов. Под ред. д.т.н., проф. Букреев В.З.-М.:РЗИТЛП, 2001. сс.95-106.
7. Голубятников И.В., Матвеев Ю.В., Сергеев И.В. Создание программного комплекса репликации СУБД-независимых данных // Системный анализ, информатика и оптимизация. Сборник научных трудов. Под ред. д.т.н., проф. Букреев В.З.- М.:РЗИТЛП, 2001. сс.106-116.
8. Матвеев Ю.В., Сергеев И.В. Анализ методов репликации хранилища данных // Системный анализ, информатика и оптимизация. Сборник научных трудов. Под ред. д.т.н., проф. Букреев В.З.- М.:РЗИТЛП, 2001.СС.161-167.
9. Сергеев И.В. Голубятников И.В. «Система репликации данных СУБД независимых платформ» зарегистрированная в Отраслевом фонде алгоритмов и программ, свидетельство об отраслевой регистрации разработки № 2447, 24.03.2003. г.Москва.
Исследование методов выявления данных субд участвующих в репликации
Для обеспечения выявления изменений данных в СУБД необходимо реализовать интерфейс, который возмет на себя эту функцию. Любые изменения в реляционной СУБД происходят при выполнении и завершении транзакций. Рассмотрим некоторые модели обнаружения выполнения транзакций, которые были исследованы в диссертационной работе Курбанова Я.Э. [89]. 1.2.1. Применение триггеров СУБД.
В реляционных СУБД для подержания бизнес логики приложений используются триггеры. Триггер - это программа, которая автоматически вы полняется при попытке изменения содержимого заданной таблицы [13,14]. Для каждой таблицы можно определить три типа триггеров: 1. Вставка (INSERT); 2. Удаление (DELETE); 3. Модифицирование (UPDATE);
Метод выявления реплицируемых данных, основанный на применение триггеров, реализуется с помощью создания триггеров, которые при выполнении обрабатывают измененные данные и сохраняют в специализированные файлы или таблицы результаты выполнения транзакций. Например, для MS SQL Server результат выполнения транзакции вставки данных в таблицу ТаЫе1 в поля IDENT NAME : INSERT INTO Tablel ( IDENT , NAME ) values (100, "MYNAME") при выполнении триггера: CREATE TRIGGER имя триггера FOR INSERT AS Select IDENT, NAME from Inserted, где Inserted - фрагмент журнала транзакций для выполняемой транзакции, будет выглядеть как: 100 MYNAME Исходя из этого, можно сделать выводы: 1. для каждой сущности можно создать триггер, который будет реагировать на выполняемые транзакции; 2. для каждого триггера можно описать схему заполнения журнала транзакций репликации;
На основе использования триггеров, строятся транзакционные системы репликации данных. Такие системы используют журнал транзакций для выявления реплицируемых данных. К достоинствам такого метода, можно отнести: высокую скорость работы систем репликации; легкий алгоритм создания и ведения журнала транзакций. К недостаткам: сложность контроля времени выполнения транзакций. 1.2.2. Монитор обработки транзакций.
Одним из альтернативных методов, является создание монитора обработки транзакций [9] (Transaction Processing Monitor - ТРМ) - это программные системы, которые относят к категории middleware, то есть к посредническому или промежуточному программному обеспечению, решающие задачу эффективного управления информационно-вычислительными ресурсами в распределенной системе. В числе важнейших характеристик ТРМ — масштабируемость, поддержка функциональной полноты и целостности приложений, достижение максимальной производительности при обработке данных при невысоких стоимостных показателях, поддержка целостности данных в гетерогенной среде. ТРМ опираются на трехзвенную модель "клиент-сервер" (модель сервера приложений или AS-модель). Естественно, что все преимущества модели отражаются и на программных системах, построенных на ее основе. На современном рынке мониторов транзакций основными "действующими лицами" являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc), TUXEDO Sytem (Novell).
Несмотря на принципиальное сходство, конкретные ТРМ отличаются рядом характеристик, причем различия часто вытекают из специфики операционной системы, в которой реализован и функционирует ТРМ. Понятия транзакции в ТРМ и в традиционных СУБД значительно отличаются. Суть остается одной, но в СУБД транзакция — это атомарное действие над базой данных, в то время как в ТРМ транзакция трактуется гораздо шире. Она включает не только операции с данными, но и любые другие действия — передачу сообщений, выдачу отчетов, запись в индексированные файлы, опрос датчиков и т.д. Это позволяет реализовать в ТРМ прикладные транзакции, бизнес транзакции, что в СУБД, сделать невозможно.
Анализ отказоустойчивости работы алгоритмов авторизации пользователей
Так как, любую операцию над данными БД можно разделить на последовательность элементарных операций той же атомарности, то журнал транзакций хранит результат каждой операции этой последовательности. Операция изменения одного или нескольких значений в строке или группе строк выглядит в языке SQL следующим образом. Update "имя таблицы" SET "имя поля 1="значение поля", "имя поля 2"="значение поля", ... В результате выполнения этого запроса в реляционной БД произойдет изменения всех строк указанной таблицы и значений полей этой таблицы.
В реляционных СУБД для поддержания бизнес логики используются триггеры. Триггеры это набор команд сервера БД или операций SQL, которые автоматически выполняется при попытке изменения содержимого определенной таблицы. Для каждой таблицы можно определить три типа триггеров: триггер ввода (срабатывает при добавлении записи в таблицу); трипер изменения (срабатывает при изменении текущего значения записи таблицы); триггер удаления (срабатывает при удалении записи из таблицы);
В триггерах можно определить, какие строки и поля таблицы изменяются. Из выше сказанного, можно сделать вывод, что для записи результатов транзакций в журнал транзакций, необходимо для каждой таблицы участвующей в репликации создать три триггера: добавления, изменения и удаления. Структуры триггеров приведены ниже. 1. Триггер вставки (INSERT) значений в таблицу: CREATE TRIGGER sysReplTriggerOnINSERTValue-симя таблицы ON [ владелец таблицы ].[ имя таблицы ] // определяем событие срабатывания FOR INSERT NOT FOR REPLICATION AS
II определяем переменные командой DECLARE DECLARE @sysReplUniqueColumn uniqueidentifier DECLARE @TABLE_IDENT int DECLARE @SysUserIDENT int II присваиваем значения переменным SELECT SysUserlDENT = USERJD (CURRENTUSER) SELECT @Table_IDENT=object_id ( имя таблицы ) SELECT @sysReplUniqueColumn=sysReplUniqueColumn FROM INSERTED II вставляем в журнал транзакцию с идентификатором действия = 1 INSERT INTO sysRepIications (TABLEIDENT, RECORDKEYIDENT, sysAc tion, SysUserlDENT) VALUES (@TABLEJDENT, @sysReplUniqueColumn, 1, SysUserlDENT) II КОНЕЦ ТРИГГЕРА 2. Триггер удаления (DELETE) значений из таблицы: CREATE TRIGGER sysRepITriggerOnDELETEVali таблицы ON [ владелец таблицы ].[ имя таблицы ] // определяем событие срабатывания FOR DELETE NOT FOR REPLICATION AS II определяем переменные командой DECLARE DECLARE @sysReplUniqueColumn uniqueidentifier DECLARE @TABLE_IDENT int DECLARE @SysUserIDENT int II присваиваем значения переменным SELECT SysUserlDENT = USERJD (CURRENTJJSER) SELECT @Table_IDENT=object_id ( имя таблицы ) SELECT @sysReplUniqueColumn=sysRepIUniqueColumn FROM DELETED II вставляем в журнал транзакцию с идентификатором действия = 2 INSERT INTO sysRepIications (TABLEIDENT, RECORDKEYIDENT, sysAc tion, SysUserlDENT) VALUES (@TABLE_IDENT, @sysReplUniqueColurnn, 2, SysUserlDENT) II КОНЕЦ ТРИГГЕРА 3. Триггер изменения (UPDATE) значений в таблице: CREATE TRIGGER sysReplTriggerOnUPDATEValue_ HivM таблицы ON [ владелец таблицы ].[ имя таблицы ] // определяем событие срабатывания FOR UPDATE NOT FOR REPLICATION AS II определяем переменные командой DECLARE DECLARE @sysReplUniqueColumn uniqueidentifier DECLARE @TABLE_IDENT int DECLARE @SysUserIDENT int DECLARE @COLUMN_ID int II присваиваем значения переменным SELECT @SysUserfDENT = USERJD (CURRENT_USER) SELECT @Table_IDENT=object_id ( имя таблицы ) SELECT @sysReplUniqueColumn=sysReplUniqueColumn FROM INSERTED ... начало блока проверки полей ... IF UPDATE ( имя поля ) BEGIN II определяем идентификатор поля SELECT @COLUMN_ID=colid FROM syscolumns WHERE NAME=, имя поля and id = @TABLEJDENT II вставляем в журнал транзакцию с идентификатором действия = 3 INSERT INTO sysReplications (TABLEIDENT, FIELDIDENT, RECORDKEYTOENT, sysAction, sysUserlDENT) VALUES (@TABLE_IDENT, @COLUMN_ro, @sysReplUniqueColumn, 3, @SysUserroENT) END ... вьппе указанный блок формируется для всех полей задействованных в схеме ...
Структурная модель системы репликации данных
Как уже отмечалось, все системы репликации данных в распределенных системах строятся на стандартных средствах репликации серверов БД или пишутся системы, жестко привязанные к структуре и платформе СУБД. Ни те не другие не могут одновременно функционировать на различных платформах СУБД. Это приводит к использованию дорогих серверов БД с высокой производительностью, там, где это может быть излишним.
Решение этих проблем, предполагается, путем создания программного комплекса репликации данных СУБД, не осуществляя привязки к БД на программном уровне. Его отличие от встроенных систем репликации данных СУБД состоит в том, что данные с сервера на платформе MS SQL Server реплицируются на сервера Interbase, Sybase или Oracle. При этом в структуре СУБД добавляются и изменяются сущности, которые позволяют создать такой программный комплекс, при этом, не меняя логику работы самих сущностей, можно утверждать, что разработчикам распределенных систем не придется менять программный код, для функционирования разрабатываемой нами системы.
Ключевой особенностью предлагаемой архитектуры системы репликации данных, является выделение трех взаимодействующих между собой уровней: Публикатор-Подписчик СРД, Модуль доступа к СУБД (МД), Репликатор Транзакций (РТ). Наличие промежуточного звена - Интерфейс к СУБД, отличает предлагаемую архитектуру от наиболее часто используемых разновидностей архитектуры репликации данных, а Репликатор транзакций позволяет в режиме реального времени обмениваться пакетами транзакций. Архитектура СРД представлена на рис.3.1.
1. Архитектура СРД Обмен пакетами осуществляется посредством сетевого протокола ТСРЛР [42]. В роли сервера выступает Публикатор, а в роли клиентов подписчики. Для установки соединения необходимо настроить протокол, таким образом, что бы клиент мог подсоединиться по указанному серверу адресу и прослушиваемому порту. Это делает возможным эксплуатировать данную систему, при наличии сетевой карты, не только в локальных и глобальных сетях, но и настроить работу сервера и клиента на одном компьютере. Физическая топология сети, в которой функционирует СРД, не влияет на процесс работы системы, а лишь может влиять на скорость обмена пакетами протокола ТСРЛР, а, следовательно, на скорость работы репликатора транзакций. Топология организации соединения между публикатором и подписчиком представлена на рис 3.2.
Использование дополнительного программного обеспечения, proxy сервера, позволяет настроить TCP/IP канал для подключений из Internet и других сетей. Более того, на proxy сервера ложится и дополнительный уровень безопасности подключений, что делает СРД более устойчивой к несанкционированному доступу.
На стадии настройки системы определяется, как будет себя вести программный модуль, как публикатор или как подписчик. Отличие заключается в работе не только самих этих модулей, но и модуля репликатора транзакций и его подсистем. Первое отличие в работе этих двух модулей заключается в том, что публикатор является серверов TCP/IP соединений, который прослушивает указанный DP адрес и порт на наличие запросов на подключение от подписчиков. В свою очередь, подписчик выступает в роли ТСРЯР клиента, который по указанному адресу и порту посылает запрос на подключение. Структурная схема Публикатора - Подписчика представлена на рис 3.3.
Получив запрос на подключение, публикатор (сервер) передает работу подсистеме сценария ТСР/ГР сервера. Подписчик (клиент), установив соединение, передает работу подсистеме сценария ТСРЯР клиента. Подсистема сценария ТСРЯР сервера и клиента взаимодействуют между собой через ТСРЯР соединение и через РТ. При завершении работы сценариев и всех подсистем РТ Публикатор разрывает соединение с Подписчиком. Структура Публикатора строится на основе потоковой модели, что позволяет одновременно обслуживать подключения множества клиентов, и выполнения всех сценариев вызываемых ими. Каждый из сценариев вызывает функции подсистем РТ. Рассмотрим структуру Репликатора Транзакций. 3.2.2. Структура Репликатора Транзакций.
Основной подсистемой, отвечающей за выполнение сценариев Публикатора и Подписчика, а так же за прием и передачу пакетов содержащих упакованные транзакции, является подсистема приема и передачи пакетов транзакций (ППТ). Основной функцией данной подсистемы является прием упакованных данных по каналу ТСРЯР и передача этих данных подсистеме упаковки и распаковки данных (УРД), а также получение упакованных данных от УРД и пересылка обратной стороне. Структура Репликатора Транзакций представлена на рис 3.4.
Метод реализации коммуникации узлов на базе интерфейса windows-sockets api
Разрабатываемый программный комплекс репликации данных СУБД состоит из 4 компонент: модуля настройки и администрирования программного комплекса, доступа к информации БД, серверного модуля репликации данных и клиентского модуля репликации данных.
Доступ к информации СУБД происходит через СОМ интерфейсы. Для каждой СУБД описывается СОМ интерфейс, реализующий специфику этой платформы. Связь между серверным и клиентским модулем в среде глобальной или локальной сети, устанавливается посредством использования специализированного протокола. Схема взаимодействия сервера и клиента СРД между собой и СУБД представлена на рис. 4.1.
Взаимодействие сервера и клиента СРД и доступ к СУБД. При выборе средств реализации модулей, прежде всего, необходимо принять во внимание следующие особенности системы репликации данных: модуль доступа к СУБД должен наследовать интерфейс объектно-компонентной модели (COM) IUnknown и реализовывать методы доступа к информации СУБД выбранной платформы; функционирование сервера и клиента СРД должно происходить в качестве службы операционной системы; связь между сервером и клиентом должна происходить в режиме реального времени по каналам глобальной или локальной сети. Среди универсальных языков программирования, используемых для разработки программ для Windows можно выделить Бейсик, Си++ и Паскаль. Учитывая значительную зависимость возможности применения того или иного языка программирования от свойств конкретной среды разработки, целесообразно рассмотреть их реализации в средствах разработки различных фирм. Для рассмотрения выберем наиболее характерных представителей систем, реализующих тот или иной язык программирования.
Система программирования Microsoft Visual Basic (версии 6.0) реализует собственный диалект языка Бейсик [51]. Согласно исследованиям, большинство прикладных программ для Windows в мире (свыше 45%) создаются с помощью Visual Basic. Это, прежде всего, связано с развитой поддержкой средств визуального проектирования и быстрой разработки программ, позволяющей в кратчайшие сроки разрабатывать прикладные программные продукты. Однако для системного программирования данное средство мало применимо в связи с тем, что программы, написанные на Visual Basic, либо должны исполняться в интегрированной среде разработки, либо зависят от библиотеки времени выполнения, фактически представляющей собой интерпретатор р-кода, что сильно замедляет выполнение программы и понижает ее мобильность.
Система программирования Borland C++ (версии 5.0) реализует стандарт языка Си++ и предоставляет полностью интегрированную среду разработки, включающую многофункциональный текстовый редактор, производительный оптимизирующий компилятор, интеллектуальный редактор связей и полноэкранный отладчик [56-63]. Данная система включает объектно-ориентированную библиотеку Object Windows Library (OWL), инкапсулирующую вызовы Windows АРІ в методах классов и значительно упрощающую создание Windows-приложений, особенно в части интерфейса пользователя. Borland C++ позволяет создавать как программы для выполнения под управлением MS-DOS, так и 16-ти или 32-ух битные программы для выполнения в средах семейства Windows. К недостаткам данной системы можно отнести отсутствие средств визуального проектирования, трудоемкость разработки приложений, взаимодействующих с базами данных, относительно низкую скорость компиляции и компоновки программ.
Система программирования Delphi (версии 6.0) реализует диалект языка Паскаль, включающий в себя объектно-ориентированные возможности, приближающиеся к средствам, предоставляемым языком Си++. Система включает полностью интегрированную среду разработки, мощные средства визуального проектирования и быстрой разработки программ, в том числе, программ, взаимодействующих с базами данных. Помимо этого, Delphi предоставляет полный набор средств для системного программирования в средах семейства Windows [64-72].
В комплекте с Delphi 6.0 поставляется набор визуальных компонент для работы с СУБД разных платформ [73-76]. Например, для доступа к реляционным СУБД Microsoft SQL Server и Sybase, можно воспользоваться компонентами, реализующими интерфейс ADO, который предоставляет иерархическую модель объектов для доступа к различным OLE DB-провайдерам. Так же можно воспользоваться этими компонентами при работе с другими реляционными СУБД, таких как Oracle, DB2, InterBase и MySQL, если для них реализован интерфейс OLE DB. Так же, для работы с Oracle, MySQL и DB2 в Delphi 6.0 предусмотрен специальный пакет dbExperess, функции доступа и работы которых, реализованы в визуальных компонентах. dbExperess позволяет получить прямой доступ к БД, используя стандартные библиотеки серверов, входящие в состав поставки этих СУБД. Для работы с серверами InterBase, в Delphi 6.0 предусмотрен набор визуальных компонент - IB, позволяющих обрабатывать данные СУБД.
