4. Архитектура системы эод
Система ЭОД построена на многоуровневой системной архитектуре (используются два типа архитектуры - двухуровневая и трёхуровневая) и базируется на системном программном обеспечении фирмы Microsoft.
Уровень пользовательского интерфейса (клиентская часть) функционирует в MS Window 9Х (Windows NT Workstation, Windows 2000 Professional), уровень данных опирается на MS SQL Server 2000, бизнес-уровень работает на основе технологии COM+.
Пользовательский интерфейс (клиентская часть) реализован с применением ActiveX — технологий. Клиентская часть системы, в смысле внутренней архитектуры, выполнена по принципу «Контейнер + ActiveX Document». «Контейнер» в Системе ЭОД называется «Универсальное рабочее вместо» (далее УРМ). УРМ обеспечивает пользователю интуитивно-понятный интерфейс для выбора режимов и погрузки ActiveX документов, в виде которых реализованы практически все пользовательские режимы Системы ЭОД. Система ЭОД реализована на протоколе TCP/IP. Рассмотрим основные теоретические вопросы системной архитектуры.
Системная архитектура определяет, как взаимодействуют элементы приложения и какую функциональность они представляют. Существует три типа системной архитектуры:
одноуровневая (или монолитная);
двухуровневая
многоуровневая
Многоуровневая системная архитектура является особым случаем трехуровневой, в которой один или более уровней разбивается на дополнительные уровни, что обеспечивает более высокую масштабируемость. Типичное приложение, взаимодействующее с пользователем (от электронной таблицы, выполняемой на персональном компьютере, до системы финансовой отчетности, работающей на мэйнфрейме), состоит из трех элементов:
Сервисы презентации (пользовательские интерфейсы) - преобразование информации для представления пользователю, обеспечение интерфейса ввода
Бизнес-сервисы (прикладная логика) - поддержка необходимых алгоритмов, генерация деловой информации на основе полученных данных, обеспечение целостности данных;
Сервисы данных - обеспечение хранения, выборки, защиту и целостность данных.
Главная задача сервиса презентации, или пользовательского интерфейса - взаимодействие с пользователем.
Бизнес-сервисы (бизнес-правила) - это набор алгоритмов, реализующих вычисления и контролирующих поток управления в приложении. Бизнес-правила определяются конкретным видом деятельности, на которое рассчитано приложение. На практике бизнес-правила как раз и являются той целью, которое должно реализовать приложение. Сервисы данных управляют информацией, отвечают за её хранение и обеспечивают функциональность, необходимую для обработки данных. Пример сервиса данных - MS SQL Server, работающий на компьютере с Windows 2000 Server.
Одноуровневое приложение.
В таких приложениях пользовательский интерфейс, бизнес-правила и сервисы данных поддерживаются одним уровнем. За обработку сервисов всех трех типов отвечает одно приложение или его элемент. Сами данные могут находиться в любом месте, допустим, на сервере, но функциональность, связанная с доступом к данным, является частью приложения.
Двухуровневое приложение.
В двухуровневых (клиент-серверных) приложениях компоненты, отвечающие за сервис презентации и прикладную логику (бизнес-сервис), размещаются на клиентской машине и обращаются к общему источнику данных по сети. В таких приложениях пользовательский интерфейс и прикладная логика образуют один уровень на клиентском компьютере, а сервисы данных предоставляются отдельными приложениями (на сервере) вроде MS SQL Server или Oracle. Например, приложение, написанное на Visual Basic, вызывает хранимые процедуры на MS SQL Server и таким образом получает нужные данные. Первое приложение - один уровень, второе - другой. Код для пользовательского интерфейса и поддержка прикладной логики не обязательно должны составлять одно целое. Приложение, написанное на Visual Basic, может обращаться к данным, вызывая нужные функции из динамически подключаемых библиотек (DLL). В этом случае, хотя пользовательский интерфейс и прикладная логика находятся в разных местах, они всё равно считаются одним уровнем.
Многоуровневое приложение.
В подобных приложениях сервис презентации, бизнес-сервис и сервис данных отделены друг от друга. Компоненты, отвечающие за сервис презентации, поддерживают пользовательский интерфейс и запрашивают бизнес-сервис, компоненты которого, в свою очередь, выдают запросы к сервису данных.
В
многоуровневом приложении клиент
предоставляет только пользовательский
интерфейс. Прикладная логика реализуется
промежуточным уровнем, который размещается
между пользовательским 
интерфейсом
и системой хранения данных (сервис
данных). Это и позволяет выделять каждый
тип сервиса в отдельный уровень.
Проводя аналогию с описанным выше двухуровневым приложением, многоуровневая архитектура характеризуется тем, что одно приложение - это уровень презентации, второе - бизнес-уровень, третье - уровень данных.
Схема многоуровневого приложения приведена ниже.
Преимущество такой архитектуры заключается в том, что прикладная логика сосредоточена в одном месте, что значительно облегчает её модификацию. В многоуровневом приложении клиент не обращается к системе хранения данных напрямую. Разделение всех сервисов позволяет модифицировать любой уровень системы, не внося изменения в другие. Тем самым удаётся существенно уменьшить необходимость в поддержке клиентских компонентов.
Рассмотрев основные теоретические вопросы системной архитектуры, вернёмся к вопросу архитектуры Системы ЭОД.
Часть Системы ЭОД реализована в архитектуре клиент-сервер (связь №1 на схеме). Клиентская часть Системы ЭОД ("Универсальное рабочее место") включает в себя сервисы презентации (пользовательские интерфейсы) в виде всевозможных форм и прикладную логику (бизнес-сервисы), которая работает с сервисом данных (СУБД) в виде динамически подключаемых библиотек (DLL) из которых происходит вызов хранимых процедур БД.
Другая часть Системы ЭОД реализована в трёхуровневой архитектуре. В этой части Универсальное рабочее место включает в себя только сервисы презентации! которые взаимодействуют с бизнес-сервисом (связь №2 на схеме), которые, в свою очередь, взаимодействует с сервисом данных (связь №3 на схеме). На бизнес уровень вынесена поддержка алгоритмов, реализация которых в архитектуре клиент-сервер сложна или не эффективна.