Распределенные объектные технологии в информационных системах

вертикальный - каждый компонентный имеет уникальный в рамках данной информационной системы интерфейс;

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

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

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

В случае использования  вертикального типа взаимодействия распределенных компонентов объем  кода, необходимого для интеграции, будет определяться количеством  компонентов системы. На рис. 5 показана схема взаимодействия компонентов вертикально построенной системы. Количество интерфейсов в этом случае будет порядка N*N, где N - число компонентов. Для внедрения новой задачи потребуется 2N+1 раз разрабатывать новые связующие программы. Обычно такое решение является результатом недостаточного внимания, уделяемого проектированию архитектур ИС. 
 
 
 
 

Рисунок 5.

Вертикальная  архитектура системы 
 

В случае горизонтально  построенной системы (рис. 6) количество интерфейсов (интеграционного кода) будет минимальным. Добавление нового компонента потребует реализовать дополнительно всего два интерфейса. 
 
 
 
 

Рисунок 6.

Горизонтальная  архитектура системы 
 

При реальной разработке чрезвычайно трудно создать одинаковые интерфейсы для всех подсистем, поэтому  наиболее предпочтительным для создания распределенной системы является смешанный тип взаимодействия компонентов (рис. 7). В этом случае построенная архитектура сохраняет свойство универсальности интерфейсов, но позволяет добавлять специфичные для данного приложения операции. 
 
 
 
 

Рисунок 7.

Гибридная архитектура  системы 
 

Количество кода, необходимого для интеграции новой  задачи при такой архитектуре, изменяется в зависимости от конкретного  проекта от 2 (горизонтальная архитектура) до 2N+1 (вертикальная архитектура). 
 

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

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

портируемость приложений - перенос приложений на различные аппаратные платформы, операционные системы, сетевые протоколы;

интероперабельность (interoperability) - возможность совместного  использования информации и ресурсов компонентами распределенной системы [14];

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

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

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

Функциональная  нагрузка компонентов в ИС 
 

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

группа функций  пользовательского интерфейса;

группа прикладных функций, характерных для данной предметной области;

группа функций  хранения и управления данными. 
 

Декомпозиция  функций из этих групп по компонентам  определяет логическую архитектуру  информационной системы. Выбор приемлемой логической архитектуры информационной системы является одним из важнейших этапов проектирования ИС. 
 

С каждой логической архитектурой может быть связана  диаграмма, описывающая отношения  взаимодействия компонентов в ИС (пример на рис. 8). 
 

Такая диаграмма  представляет собой ориентированный граф. Дуги графа определяют отношения взаимодействия между программными компонентами ИС, являющимися его вершинами. 
 

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

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

Всевозможные  цепи между элементами множества S и T образуют множество цепей C. ИСКлючаем  из множества С все цепи, содержащие дуги, которые исходят из вершин, реализующих только функции третьей группы, или которые входят в вершины, реализующие только функции первой группы. 
 

Каждой цепи Ci множества С ставим в соответствие число Li, равное количеству вершин в  множестве, полученном из множества  вершин входящих в цепь Ci путем исключения повторяющихся вершин. 
 

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

Согласно введенному формализму, можно выделить следующие, наиболее распространенные, классы логических архитектур: 

двухуровневые архитектуры (L=2);

трехуровневые (L=3);

распределенные  одноранговые архитектуры (L>3 или  существуют отношения взаимодействия между компонентами, каждый из которых реализует функции всех трех групп). 
 

В качестве примера, на рис. 8 представлен граф, иллюстрирующий один из вариантов распределенной одноранговой архитектуры. 
 
 
 
 

Рисунок 8.

Логическая архитектура. Диаграмма отношений взаимодействия. 

Двухуровневые архитектуры 
 

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

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

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

Согласно указанным  вариантам декомпозиции, можно говорить о следующих двухуровневых архитектурах: 

интеллектуального клиента (доступ к удаленным данным, архитектура на базе файлового сервера);

интеллектуального сервера (доступ в режиме терминала, архитектура интеллектуального  сервера баз данных)

распределенной  функциональной логики 
 

Двухуровневые архитектуры обладают рядом достоинств и недостатков, частично описанных в [1,2]. Использование двухуровневых архитектур при построении крупных информационных систем, исходя из присущих им недостатков, приводит во многих случаях к краху проектов, связанных с их разработкой. 

Трехуровневые архитектуры 
 

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

Трехуровневые архитектуры предусматривают не столь жесткие связи между  клиентом и сервером и более гибкие формы распределенной обработки [2]. Наиболее распространенной считается  архитектура, согласно которой выделяются три компонента ИС (представления, прикладной, доступа к информационным ресурсам), являющиеся автономными и общающиеся через средства межпроцессного взаимодействия при помощи стандартных интерфейсов. Отдельные компоненты могут располагаться как на одном компьютере, так и на разных компьютерах, обеспечивая тем самым распределенную обработку информации. Компонент представления часто располагается на персональном компьютере, прикладной компонент (называемый также сервером приложения) выполняется сервером среднего уровня под управлением операционной системы Unix или Windows NT, а компонент доступа к данным и сами данные располагаются либо на мощных Unix-серверах, либо на больших или мини-ЭВМ. Однако на практике все три компонента могут с успехом выполняться и на одном компьютере. 
 

Основным элементом трехуровневой архитектуры является сервер приложения. Как правило, в нем реализуется несколько прикладных функций, каждая из которых оформлена как сервис (service) и предоставляет некоторые услуги всем компонентам представления, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый из них может предоставлять определенный набор севрисов. Детали реализации прикладных функций в серверах приложений полностью скрыты от клиентов. Кроме того, разработчики могут создавать, изменять или переносить любые компоненты ИС, практически не затрагивая других. 

Распределенные  одноранговые архитектуры 
 

Согласно распределенной одноранговой архитектуре клиент (рис. 10) [2,18], взаимодействующий с сервером приложений, трактуется более широко, чем компонент представления. Он может поддерживать интерфейс с конечным пользователем, а может выполнять прикладные функции и являться сервером приложения. В общем случае, в рамках данной архитектуры, клиент (сервер) может как предоставлять, так и запрашивать некоторые сервисы. Это позволяет на этапе проектирования информационной системы осуществить такую декомпозицию функций из указанных выше трех групп по компонентам ИС, которая была бы оптимальной в контексте решаемой задачи. 
 
 
 
 

Рисунок 10.

Распределенная одноранговая архитектура. 
 

Для обеспечения  взаимодействия компонентов информационной системы, поддерживающей распределенную одноранговую архитектуру, необходимо создать промежуточный программный  уровень (middleware), при помощи которого запросы принимаются от клиентов и направляются соответствующему серверу. К счастью, сегодня уже имеется или анонсировано достаточное количество инструментальных средств, позволяющих разработчикам строить распределенные ИС, не вдаваясь в детали реализации взаимодействия клиента и сервера. Многие из этих программных продуктов реализуют стандарт CORBA (Common Object Request Broker Architecture), а некоторые инструментальные пакеты (например, продукт Orbix фирмы IONA Technologies) предлагают расширенные варианты этого стандарта. 
 

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

Технологии интеграции компонентов распределенных ИС 
 

Гетерогенные  вычислительные среды сегодня стали реальностью для многих организаций. В связи с этим повышаются требования к интеграции разнородных приложений, автоматизирующих деятельность предприятий и функционирующих в распределенных средах с широким диапазоном платформ и сетей. Крупные организации, как, например, Центральный банк РФ, Государственная налоговая служба, Таможенный комитет, имеют различные компьютерные системы (SUN, RS6000, IBM PC, Alpha и т.д.), которые установлены в одном или разных местах. Для администраторов компьютерных систем, основной проблемой является обеспечение взаимодействия этих систем для их совместной работы. Перед разработчиками приложений, во-первых, стоит проблема создания такого программного обеспечения, которое могло бы работать на максимально возможном числе платформ, используемых в организации. Во-вторых, разработка приложений в концепции Единого Информационного Пространства, должна осуществляться либо на основе собственных стандартов (замкнутое решение), либо на основе общепринятых международных стандартах. Используя международные стандарты, можно достаточно просто интегрировать в ИС программные продукты фирм, следующих этим стандартам. В третьих, разработчикам необходимо предусмотреть возможность модификации приложений ИС так, чтобы процесс модернизации был минимален по времени и затратам. А этого можно достичь, следуя определенным принципам выделения и объединения компонент информационных систем.