Технологии MIDAS

Технология MIDAS (Multitier Distributed Applications Services) — набор сервисов для создания многозвенных распределенных при­ложений.

Многозвенное приложение представляет собой распределен­ные системы удаленного доступа к данным, которые состоят, как минимум, из трех логических уровней. Эти логические уровни мо­гут находиться как на одном, так и на нескольких компьютерах.

Применение многозвенных приложений позволяет обеспечить следующие преимущества:

• формирование пакета бизнес-логики в общедоступном сред­нем уровне, доступ на который могут получить одновременно сразу несколько клиентов, что позволит избежать дублирования биз­нес-логики для каждого отдельного клиентского приложения;

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

• увеличение устойчивости за счет возможности организации гибкой перестраиваемой системы защиты информации.

В самой простой форме (так называемой three-tiered model) многозвенное приложение включает в себя следующие уровни: клиентское приложение, сервер приложений, управление пере­дачей данных и удаленный сервер базы данных.

Клиентское приложение обеспечивает интерфейс пользователя на пользовательском компьютере.

Сервер приложений находится в доступном для всех клиентов месте и обеспечивает общую передачу данных.

Управление передачей данных обеспечивает так называемый бро­кер данных.

Удаленный сервер базы данных обеспечивает систему управления базой данных.

Взаимодействие указанных уровней осуществляется следующим образом.

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

• Клиент соединяется с сервером приложений (который мо­жет определяться как во время исполнения, так и во время созда­ния приложения).

• Запускается сервер приложений.

• Клиент получает интерфейс IAppServer от сервера приложе­ний.

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

• Клиент расшифровывает пакеты данных и предоставляет их пользователю.

• Пользователь взаимодействует с клиентским приложением. При изменении данных клиент упаковывает измененные данные в пакеты и отсылает их на сервер приложений.

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

• Клиент уточняет необработанные данные, после чего посы­лает их снова серверу приложений. Затем клиент обновляет свои данные с сервером.

Разработка пользовательских приложений производится с при­менением языка программирования Delphi. Технология MIDAS позволяет:

• получать доступ к данным, физически расположенным на разных машинах;

• распределять нагрузку ресурсов по сети, что позволяет умень­шить сетевой трафик;

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

Эффективную разработку приложений MIDAS обеспечивают следующие основные компоненты:

• модули удаленных данных;

• компонент TClientDataSet набора данных клиента;

• компоненты связи TDCOMConnection, TSocketConnection, TWebConnection, TCorbaConnection;

• брокер бизнес-объектов SimpleObjectBroker.

Модули удаленных данных — это специальные модули данных, которые действуют как серверы автоматизации или как CORBA-серверы, предоставляя клиентам доступ к любым провайдерам, которые они содержат. Используются на сервере приложений.

Компонент набора данных клиента TClientDataSet — это специ­ализированный набор данных, который использует MIDAS.DLL для управления.

Компоненты связи TDCOMConnection, TSocketConnection, TWebConnection, TCorbaConnection — это набор компонентов, которые определяют сервер приложений, тип взаимодействия между клиентом и сервером и формируют интерфейс, доступный для наборов данных клиента. Каждый из этих компонентов специ­ализируется на конкретном протоколе связи.

Брокер бизнес-объектов SimpleObjectBroker служит для распре­деления вычислительной нагрузки по нескольким серверам.

С помощью технологии MIDAS можно создавать системы, кото­рые могут обрабатывать запросы Интернет-приложений. MIDAS ра­ботает одинаково хорошо с технологиями CORBA, СОМ, OLEnterprise и MTS и упрощает интеграцию существующих систем.

ЧАСТЬ III. ПРОЕКТИРОВАНИЕ СЕРВЕРНОЙ ЧАСТИ ПРИЛОЖЕНИЯ БАЗ ДАННЫХ

ГЛАВА 7. МЕТОДИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ СЕРВЕРНОЙ ЧАСТИ ПРИЛОЖЕНИЯ

Методология разработки серверной части приложения пре­дусматривает разбиение всего процесса проектирования на кон­цептуальное, логическое и физическое.

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

Концептуальное проектирование базы данных включает в себя следующие этапы.

• Создание локальной концептуальной модели данных.

• Определение типов сущностей.

• Определение атрибутов.

• Определение типов связей.

• Проверка модели на избыточность.

• Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

• Обсуждение локальных концептуальных моделей данных с конечными пользователями.

Создание локальной концептуальной модели данных. Целью дан­ного этапа является определение предметной области и состава пользователей разрабатываемой базы данных.

На рис. 7.1 показан пример локальной концептуальной моде­ли, устанавливающей предметную область и связи между подраз­делениями предприятия в процессе изменения конструкторской документации в разработанной базе данных «Извещение».

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

Рис. 7.1. Структура связей между подразделениями приборостроительно­го предприятия

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

Определение атрибутов. На данном этапе для каждой табли­цы БД устанавливается необходимый состав атрибутов (призна­ков), описывающий конкретную сущность, а также необходимые ключевые поля.

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

На рис. 7.2 показан пример, отражающий типы сущностей, и соответствующий состав таблиц и связей между ними в базе дан­ных «Извещение».

Проверка модели на избыточность. На данном этапе база данных проверяется на избыточность связей и производится ее устране­ние в случае обнаружения.

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

Проверка соответствия локальной концептуальной модели конк­ретным пользовательским транзакциям. На данном этапе проверя­ется полнота получения информации каждым пользователем базы данных в результате выполнения пользовательских запросов или транзакций.

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

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

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

1. Создание и проверка локальной логической модели данных на основе представления предметной области каждого из типов пользователей.

2. Устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап).

3. Определение набора отношений исходя из структуры локаль­ной логической модели данных.

4. Проверка отношений с помощью правил нормализации таб­лиц.

5. Проверка соответствия отношений требованиям пользова­тельских транзакций.

6. Определение требований поддержки целостности данных.

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

8. Создание и проверка глобальной логической модели данных.

9. Слияние локальных логических моделей данных в единую
глобальную модель данных.

10. Проверка глобальной логической модели данных.

11. Проверка возможностей расширения модели в будущем.

12. Обсуждение глобальной логической модели данных с пользователями.

На рис. 7.3 показана схема реализации базы данных «Извеще­ние» как элемента глобальной системы в условиях внедрения на предприятии единого информационного пространства на основе системы SQL Server2000 и системы электронного документообо­рота PartY Plus.

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

Физическое проектирование базы данных (для реляционной модели) включает в себя следующие этапы.

1. Перенос глобальной логической модели данных в среду целевой СУБД.

2. Проектирование базовых отношений в среде целевой СУБД.

3. Проектирование отношений, содержащих производные данные.

4. Реализация ограничений предметной области.

5. Проектирование физического представления базы данных.

6. Анализ транзакций.

7. Выбор файловой структуры.

8. Определение индексов.

9. Определение требований к дисковой памяти.

10. Разработка пользовательских представлений.

11. Разработка механизмов защиты.

12. Анализ необходимости введения контролируемой избыточ­ности.

13. Организация мониторинга и настройка функционирования операционной системы.

На рис. 7.4 показана схема программно-аппаратной реализации базы данных «Извещение» для выбранной СУБД SQL Server2000. Данная схема отражает первый этап физического проектирования и является основой для проведения всех сформулированных ранее этапов физической реализации базы данных.

ГЛАВА 8. ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ СЕРВЕРНОЙ ЧАСТИ

ПРИЛОЖЕНИЯ

Дата добавления: 2014-01-07