4.2.2. Выбор технологической среды реализации

Важное значение при выборе технологической среды реализации прикладного программного обеспечения имел тот факт, что разрабатываемое АРМ является интегрированной информационной системой. При ее реализации одним из важных вопросов является организация взаимодействия модулей друг с другом и с хранилищами информации. В рамках данной системы реализовано взаимодействие модулей через данные. Результаты работы одного модуля в виде данных записываются в БД. Для другого модуля эти данные являются входными. Взаимодействие через данные требует их унификации (единого формата хранения и языка запросов к БД). Для унификации формата хранения данных использована технология DCOM [101, 126]. Исходным представителем данной технологии является платформа «клиент-сервер» [32, 38, 103, 126]. В рамках данной платформы, на верхнем уровне размещается сервер баз данных. В нем хранятся данные. Нижний уровень представлен клиентскими приложениями, которые используют эти данные в работе. Кроме того, в приложениях реализована бизнес-логика работы с данными, а также проверка их на достоверность и непротиворечивость [28, 126]. Подобные приложения называют «толстыми клиентами» [63]. Реализованное прикладное программное обеспечение базируется на более совершенной платформе - трехуровневой архитектуре «клиент-сервер» [32] (рис. 4.2).

В данной платформе уровни иерархии размещены по схеме: «сервер БД - сервер приложений - клиент». Особенностью данной платформы является тот факт, что процедуры, реализующие доступ к данным и их обработку, перенесены из клиентского приложения в сервер приложений (т. е на отдельный уровень). Данную архитектуру называют «тонкий клиент» [28, 32]. Механизм функционирования данной платформы заключается в следующем. На верхнем уровне находится удаленный сервер баз данных. Он обеспечивает хранение и управление данными. На среднем уровне (middle ware) находится сервер приложений. В сервере приложений содержатся средства и код, общие для всех клиентских приложений, в частности средства доступа к БД. Он обеспечивает соединение клиентов с сервером БД и реализует бизнес-логику. На нижнем уровне находятся клиентские приложения. Пользователь запускает клиентское приложение. Оно соединяется с доступным ему сервером приложений. Затем клиент запрашивает какие-то данные. Этот запрос упаковывается в пакет установленного формата и передается серверу приложений. Там пакет распаковывается и передается серверу БД, который возвращает затребованные данные. Сервер приложений обрабатывает эти данные согласно заложенной в него бизнес-логике, упаковывает и передает этот пакет клиенту. Клиент распаковывает данные и использует их в своей работе. Если данные изменены пользователем, то цепочка их передачи на сервер БД выглядит следующим образом. Клиент упаковывает измененные данные и отправляет пакет на сервер приложений. Тот распаковывает их и отправляет на сервер БД. Если все исправления могут быть без осложнений занесены в БД, то на этом все завершается. Если возникли осложнения (например, сделанные изменения противоречат бизнес-правилам или в результате изменения одних и тех же данных разными пользователями возникли противоречия), то проблемные записи, возвращаются клиенту. Далее пользователь принимает решение, что с ними делать (исправить или отказаться).

Основными достоинствами такой архитектуры являются:

- повышение оперативности функционирования сервера БД за счет переноса части рутинных операций на сервер приложений;

- уменьшение размера клиентских приложений за счет разгрузки их от лишнего кода;

- единое поведение всех клиентов;

- упрощение настройки клиентов – при изменении общего кода сервера приложений автоматически изменяется поведение приложений - клиентов.