Рис.2.7. Подробная схема репликации данных.
Схема репликации приведена на рис.2.7. Рассмотрим процесс передачи изменений подробнее:
1. При изменении данных в реплицируемой таблице новые данные через триггер записываются в журнал изменений. Кроме того, туда заносится имя таблицы, код сделанного изменения и первичный ключ измененной записи.
2. При возникновении в базе определенного события (например при большом количестве записей в журнале изменений) или в определенный момент времени коммуникационный сервис запускает процесс репликации.
3. Процесс репликации устанавливает соединение с сервером подписки и начинает синхронизацию данных.
4. Сервер подписки принимает измененную запись и модифицирует соответствующим образом таблицу на своей стороне.
5. Если в процессе изменения записи был сгенерирован новый ключ, то он передается на сервер репликации.
6. Сервер репликации заменяет первичный ключ реплицируемой записи на ключ, возвращаемый с сервера подписки и удаляет соответствующую запись из журнала изменений.
При передаче изменений коммуникационным сервисом используется протокол двухфазной фиксации транзакций (Two-phase commit transactions), что позволяет застраховаться от ошибок.
При синхронизации данных подобным методом процесс репликации может быть прерван в любой момент времени и продолжен позднее с той же точки. Данная особенность позволяет использовать такую схему тиражирования даже на очень плохих каналах связи.
Для решения задач репликации, резервного копирования, удаленного доступа и удаленного управления на сервере баз данных необходим процесс, планирующий запуск процессов и обрабатывающий подключения удаленных пользователей. Основные требования, предъявляемые к коммуникационному серверу таковы:
1. Так как информационная система носит распределенный характер, а также учитывая отсутствие квалифицированных кадров в местах установки сервера необходимо предусмотреть возможность удаленного конфигурирования системы.
2. Для облегчения задач администрирования необходимо как можно более полно автоматизировать выполнение наиболее часто встречающихся задач, таких как резервное копирование данных и репликация.
3. Учитывая необходимость дальнейшего расширения системы необходимо предусмотреть возможность наращивания функциональности коммуникационного сервера.
4. Учитывая разнородность сети необходимо обеспечить возможность подключения пользователей по нескольким протоколам: TCP/IP, Named Pipes, IPX/SPX, NetBIOS.
Учитывая специфику платформы Windows NT коммуникационный сервер построен по архитектуре системного сервиса (System Service). Для разработки коммуникационного сервера применялась среда разработчика Microsoft Developer Studio 4.2/Visual C++ Enterprise Edition.
Архитектура сервера представлена в Приложении 2.
Для обеспечения наращиваемости системы проведено разделение функциональности сервера на две части:
· Ядро сервера - обслуживает подключения удаленных пользователей, планирует запуск пользовательских задач а также обеспечивает возможность удаленного конфигурирования системы.
· Пользовательские задачи - обеспечивают реплицирование, резервное копирование, синхронизацию картотек, съем данных с аппаратуры повременного учета.
Пользовательские задачи реализованы в виде многопоточных DLL. Каждая пользовательская задача должна обеспечивать две точки входа:
· void TaskProc(void) - основной поток - реализует необходимую функциональность.
· void Terminate(void) - функция для принудительного останова задачи (например при останове сервера)
Информация о пользовательских задачах хранится в реестре Windows NT
(ключ HKEY_LOCAL_MACHINE\SOFTWARE\Svyazinform\CommService\Tasks, рис.2.8).
Рис.2.8. Конфигурация задач коммуникационного сервера в реестре Windows NT.
Ядро cервера построено по многопоточной архитектуре и включает в себя следующие модули:
· Модуль инициализации - основная точка входа сервиса - регистрирует сервис в диспетчере сервисов.
· Модуль управления сервисом - реализует функции запуска и останова сервера.
· Планировщик задач - осуществляет запуск пользовательских задач в заданное время.
· Модуль обслуживания подключений - обрабатывает запросы удаленных пользователей, а также отвечает за удаленное конфигурирование системы.
· Модуль регистрации событий - записывает информацию о состоянии сервера в системный журнал событий.
Для установки коммуникационного сервиса разработана программа, регистрирующая сервис в системе и создающая необходимые ключи в реестре Windows NT. Исходный код программы представлен в Приложении 4.
Для удаления сервера разработана программа, выполняющая чистку системного реестра. Исходный текст программы представлен в Приложении 5.
Для удаленного конфигурирования пользовательских задач разработано клиентское приложение «Менеджер задач коммуникационного сервера».
Данная программа позволяет управлять списком пользовательских задач (именами модулей и временем запуска). Главное окно программы представлено на рис.2.9.
Рис.2.9. Главное окно программы конфигурирования коммуникационного сервера.
Разработка программы велась с помощью пакета Microsoft Visual C++ 4.2. Механизм реализации этой программы выходит за рамки данного дипломного проекта.
Целью дипломного проекта было создание информационной системы для автоматизации расчетов с абонентами АО «Связьинформ» РМ.
Учитывая то, что объем дипломного проекта не позволяет рассчитать экономический эффект от научно-исследовательских разработок, ограничимся составлением плана выполнения дипломного проекта, построением ленточного графика выполнения проекта и расчетом сметы затрат.
В соответствие с темой дипломного проекта определяются этапы НИР и их содержание. Этапы НИР необходимо максимально детализировать.
Таб.4.1. Этапы НИР.
№ n/n | Этап и содержание работы | Длительность цикла, дн. | Трудоемкость в % от общей трудоемкости | Исполнитель |
1 | 2 | 3 | 4 | 5 |
1 | Постановка задачи и составление технического задания | 5 | 3,1 | И1, Р, Д |
2 | Составление плана и календарного графика работы | 1 | 0,7 | Д, Р |
3 | Подбор и изучение технической документации и литературы | 14 | 10,55 | Д, Р |
4 | Написание вводной части и литературного обзора | 5 | 4,35 | Д |
5 | Информационное моделирование системы | 28 | 20,25 | Д, Р |
6 | Разработка коммуникационного сервера | 12 | 6,28 | Д |
7 | Отладка коммуникационного сервера | 18 | 8,35 | Д, Р |
1 | 2 | 3 | 4 | 5 |
8 | Написание теоретической части работы | 15 | 14,07 | Д, Р |
9 | Выводы по теоретической части проекта | 2 | 2,1 | Д, Р |
10 | Подбор данных и расчет экономической части проекта | 4 | 2,85 | Д, К1 |
11 | Анализ проделанной работы | 2 | 1,65 | Д |
12 | Составление пояснительной записки к дипломному проекту | 12 | 8,4 | Д |
13 | Оформление графической части работы | 12 | 10,75 | Д |
14 | Оформление приложений к дипломному проекту | 5 | 3,025 | Д |
15 | Сдача работы на отзыв руководителю | 2 | 1,65 | Д |
16 | Сдача работы на рецензирование | 2 | 1,2 | Д |
17 | Сдача дипломного проекта на кафедру | 1 | 0,725 | Д |
ИТОГО: | 140 | 100 |
Примечание: Д-дипломник;
И1-инженер-консультант
Р-руководитель
К1-консультант по экономической части
Трудоемкость выполнения НИР определяется по сумме этапов и видов работ, оцениваемых экспертным путем в человеко-днях и носит вероятностный характер, так как зависит от множества трудно учитываемых факторов.
Ожидаемая продолжительность работ рассчитывается по формуле:
где Tmin - оптимистическая оценка времени разработки, исходящая из
наиболее благоприятных условий её выполнения;
Т н.в. - наиболее вероятная продолжительность выполнения работы при
нормальных, чаще всего встречающихся условиях;
Т max - максимальное время выполнения работы при наиболее
неблагоприятных условиях её выполнения;
Одновременно с расчетом величины Тож. Определяют дисперсию (разброс) по формуле:
Дисперсия определяет степень неопределенности выполнения работы за ожидаемое время Тож.
Расчеты ожидаемой продолжительности работ сведены в таблицу.
Таб.4.2. Продолжительность работ.
№ n/n | Этап и содержание работы | Tmin | Tн.в. | Tmax | Tож | Di |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
1 | Постановка задачи и составление технического задания | 3 | 5 | 7 | 5 | 0,44 |
2 | Составление плана и календарного графика работы | 1 | 1 | 2 | 1,167 | 0,03 |
3 | Подбор и изучение технической документации и литературы | 12 | 14 | 16 | 14 | 0,44 |
4 | Написание вводной части и литературного обзора | 3 | 5 | 7 | 5 | 0,44 |
5 | Информационное моделирование системы | 26 | 28 | 29 | 27,8 | 0,25 |
6 | Разработка коммуникационного сервера | 11 | 12 | 14 | 12,2 | 0,25 |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
7 | Отладка коммуникационного сервера | 16 | 18 | 20 | 18 | 0,44 |
8 | Написание теоретической части работы | 13 | 15 | 17 | 15 | 0,44 |
9 | Выводы по теоретической части проекта | 1 | 2 | 2 | 1,8 | 0,027 |
10 | Подбор данных и расчет экономической части проекта | 3 | 4 | 6 | 4,2 | 0,25 |
11 | Анализ проделанной работы | 1 | 2 | 2 | 1,8 | 0,27 |
12 | Составление пояснительной записки к дипломному проекту | 10 | 12 | 14 | 12 | 0,44 |
13 | Оформление графической части работы | 11 | 12 | 13 | 12 | 0,44 |
14 | Оформление приложений к дипломному проекту | 4 | 5 | 5 | 4,8 | 0,027 |
15 | Сдача работы на отзыв руководителю | 2 | 2 | 3 | 2,2 | 0,027 |
16 | Сдача работы на рецензирование | 1 | 2 | 3 | 2 | 0,11 |
17 | Сдача дипломного проекта на кафедру | 1 | 1 | 1 | 1 | 0 |
Анализ проведенных расчетов позволяет сделать вывод о том, что расчетное ожидаемое время выполнения работы приближается к наиболее вероятному времени и разброс временных параметров располагается в интервале от 0 до 0,44. Это говорит о том, что при проведении работ необходимо строго соблюдать временной режим.