Введение
Единое информационное пространство
Стратегия разработки крупных информационных систем
Архитектура взаимодействия компонент распределенной ИС
Функциональная нагрузка компонентов в ИС
Двухуровневые архитектуры
Трехуровневые архитектуры
Распределенные одноранговые архитектуры
Технологии интеграции компонентов распределенных ИС
Заключение
Литература

Введение

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

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

  • малые информационные системы;
  • средние информационные системы;
  • крупные информационные системы (корпоративные информационные системы - системы уровня федеральных организаций).

К классу малых информационных систем относятся системы уровня небольшого предприятия. К основным признакам таких систем следует отнести:

  • непродолжительный жизненный цикл;
  • ориентация на массовое использование;
  • невысокая цена;
  • практическое отсутствие средств аналитической обработки данных;
  • отсутствие возможности незначительной модификации без участия разработчиков;
  • использование в основном настольных СУБД (Clarion, FoxPro, Clipper, Paradox, Access и др.);
  • однородность аппаратного и системного программного обеспечения (широкое использование в качестве аппаратного обеспечения недорогих персональных компьютеров);
  • практическое отсутствие средств обеспечения безопасности;
  • и т.д.

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

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

И наконец, к характерным признакам корпоративных информационных систем следует отнести:

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

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

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

Единое информационное пространство

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

Информационные ресурсы концентрируются в рамках информационных систем (ИС). Объединение ресурсов на основе информационно-коммуникационного взаимодействия информационных систем выводит их на уровень корпоративных информационных ресурсов. Такое объединение будем называть Единым Информационным Пространством (ЕИП). Реализация ЕИП масштаба федерации, корпорации, предприятия возможна при создании и последующем соблюдении стандарта на взаимодействие между собой как информационных систем, так и их отдельных приложений (рис. 1).

Picture 1.

Рисунок 1.
Корпоративные информационные ресурсы

К сожалению, в ряде случаев под информационными ресурсами понимают только данные, т.е. решение проблемы построения ЕИП сводится к организации доступа к удаленным базам данных. В результате понятие Единого Информационного Пространства сужается до понятия Единого Пространства Данных (ЕПД) (рис. 2), а информационные системы выступают в роли клиента и сервера, взаимодействуя друг с другом по сценарию представленному на рис. 3.

Picture 2.

Рисунок 2.
Единое пространство данных

Информационная система-клиент (ИСК) посылает информационной системе-серверу (ИСС) запрос, получая в качестве результата данные, подлежащие дальнейшей обработке. В качестве языка запросов, как правило, используется язык SQL - стандарт общения с реляционными системами управления базами данных. Доступ к удаленным базам данных (БД) в большинстве случаев осуществляется с помощью продуктов, поддерживающих протоколы ODBC (Open DataBase Connectivity) и JDBC (Java DataBase Connectivity), либо используются шлюзы, поставляемые производителями СУБД или третьими фирмами-разработчиками.

Picture 3.

Рисунок 3.
Архитектура доступа к удаленным данным

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

Описанному сценарию взаимодействия систем присущи и все недостатки, характерные для двухуровневой архитектуры клиент-сервер:

  • необходимо знать на стороне ИСК особенности используемой СУБД и структуру удаленной БД ИСС, что снижает уровень безопасности всей системы в целом;
  • затруднено сопровождение и модификация тех приложений информационных систем-клиентов, которые общаются с базами данных информационных систем-серверов, т.к. любое изменение схемы удаленной БД на стороне ИСС влечет за собой изменение приложений в ИСК, что усложняет обслуживание, обновление или замену приложений, установленных на десятках - сотнях компьютеров;
  • значительно усложняется администрирование БД ИСС, включающее управление правами доступа пользователей ИСК.

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

Рост популярности глобальной сети Internet и технологии World-Wide-Web в последнее время вызывает повышенный интерес к ним со стороны разработчиков корпоративных информационных систем.

Изначально WWW создавался только как средство, предоставляющее графический интерфейс в Internet и упрощающее доступ к информации, распределенной по миллионам компьютеров во всем мире [19]. При этом основными компонентами являлись страницы, узлы, броузеры и серверы Web. Не вдаваясь в подробности описания, отметим, что пользователям была предоставлена возможность навигации по Internet с использованием технологии гипертекста, поддерживаемой протоколом HTTP (Hypertext Transfer Protocol) и стандартом языка HTML (Hypertext Markup Language).

Появление CGI (Common Gateway Interface) решило проблему обмена информацией между сервером Web и такими программами как базы данных, которые не могут непосредственно обмениваться данными с броузерами Web. В результате появилась возможность реализации интерактивного взаимодействия конечного пользователя с программами стороны Web-сервера, которые обрабатывали информацию, введенную пользователем в броузере, и в качестве результата возвращали сформированную HTML-страницу. Многие из существующих решений доступа к БД в среде Internet и основаны на данном подходе.

Следует отметить, что появление языка Java предоставило для разработчиков информационных систем абсолютно новые технологические решения построения приложений в среде Internet/Intranet. Однако было бы неправильно рассматривать технологию Java только как часть технологии WWW, поскольку Java позволят решать задачи гораздо более широкого класса, чем технология, базирующаяся на языке HTML, протоколе HTTP и CGI.

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

Столь сильное утверждение связано с тем, что при рассмотрении взаимодействия информационных систем, ИСК с броузером выступает в роли компонента представления, а ИСС с WWW-сервером и приложениями выступает в роли компонента, реализующего функциональную логику и доступ к данным, что по сути соответствует двухуровневой архитектуре с интеллектуальным сервером (рис. 4). Несмотря на то, что так же как и в подходе, основанном на доступе к удаленным данным, WWW-технология способна улучшить ситуацию с импортом/экспортом данных между ИСК и ИСС, все-таки имеет место ряд недостатков, присущих двухуровневой архитектуре с интеллектуальным сервером.

Picture 5.

Рисунок 4.
Архитектура с интеллектуальным сервером.

Так, одним из недостатков, несомненно, является реальное отсутствие возможности реализации процесса обработки данных, поставляемых WWW-сервером, на стороне ИСК. Действительно, ИСК получает информацию от ИСС в виде HTML-страниц, что практически делает невозможным организацию процесса обработки полученных данных компонентами ИСК. Как следствие, это приводит к отсутствию требуемой эффективности использования вычислительных ресурсов информационных систем. С другой стороны, остро встает проблема поддержания безопасности системы в целом, которая в настоящий момент не имеет целостного решения в среде Internet, что не допустимо для организаций, выдвигающих повышенные требования к безопасности. И наконец, как и в предыдущем подходе, существенно усложняется администрирование ресурсов ИСС, включающее управление правами доступа пользователей ИСС.

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

Данный подход соответствует распределенной, одноранговой архитектуре взаимодействия [2, 18]. Согласно этой архитектуре, любые приложения из различных ИС могут выступать как в роли клиента, так и в роли сервера по отношению друг к другу, совместно решая те или иные задачи. Такой подход минимизирует дублирование приложений. Распределение приложений по различным информационным системам позволяет добиться оптимального баланса загрузки приложений и аппаратных средств, и, следовательно, приводит к эффективному использованию информационных ресурсов систем в целом.

Знание схемы базы данных необходимо только тому приложению, которое обрабатывает данные из этой базы данных. Использование ИСС сервисов, предоставляемых информационной системой-сервером и реализующих методы обработки данных, позволяет решить проблему изменения схемы удаленной базы данных. При этом статичность интерфейсов компонентов, предоставляющих ИСС набор сервисов, достигается путем применения методологий объектно-ориентированного анализа и проектирования, распределенных объектных технологий (СORBA, Java, DCOM (по мере принятия стандарта)) на различных этапах создания информационных систем.

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

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

При увеличении выполняемых сервером работ системы в двухуровневой архитектуре клиент-сервер становятся все более похожими на большие ЭВМ (мэйнфреймы), а структуры обрабатываемых ими данных и способы их представления слабо доступны для использования совместно с другими приложениями [3]. Обычно взаимодействие рассмотренных приложений клиент-сервер организовывают средствами СУБД, что существенно перегружает серверную часть. С другой стороны, современные технологии позволяют создать интегрированную среду, которая как в рамках ИС, так и в рамках концепции Единого Информационного Пространства:

  • не зависит от аппаратных и системных программных средств;
  • опирается на международные и промышленные стандарты;
  • позволяет разработать единую информационную модель представления предприятия как совокупности управляемых ресурсов и потоков деятельности, настраивающуюся на реализацию правил управления коллективной деятельностью каждого конкретного предприятия;
  • обеспечивает расширяемость системы, т.е. простоту и легкость добавления новых компонентов в существующие ИС;
  • позволяет интегрировать старые функционирующие Приложения (legacy applications) в новые ИС;
  • допускает естественную интегрируемость ИС;
  • обеспечивает безопасность, надежность и отказоустойчивость;
  • обеспечивает документируемость создаваемых ИС, что гарантирует ее жизнеспособность и эволюционное развитие;
  • позволяет накапливать, тиражировать и развивать формализованные знания специалистов;
  • существенно снижает суммарные затраты на создание ИС.

Стратегия разработки крупных информационных систем

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

  • экспертизу проектов ИС;
  • научно-методическое руководство и консультирование при проведении анализа предметной области, проектирования и реализации ИС;
  • комплексный анализ состояния предприятий, выработку рекомендаций по их реструктуризации с последующим внедрением ИС, обеспечивающих реализацию эффективных моделей управления;
  • надзор за реализацией ИС ( соответствие выбранным стандартам, установленным планам, рекомендованным технологиям);
  • взаимодействие с ведущими компаниями в области информационных технологий, научными и учебными центрами.

При разработке информационных систем особое внимание должно уделяться этапам анализа и проектирования. Однако часто этим пренебрегают, и построенные таким образом системы, как правило, быстро проявляют свою нежизнеспособность. За свой короткий жизненный цикл такие системы получили название "сгорающие системы" (stovepipe systems) [4]. Характерные черты таких систем:

  • монолитность;
  • закрытость (сложность переноса на другие платформы);
  • трудоемкость внесения изменений;
  • дорогостоящая поддержка;
  • отсутствие документации.

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

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

Часто система становится "сгорающей" из-за способа ее разработки. Это выражается в том, что на начальном этапе довольно часто создание программных компонентов ведется исключительно для внутренних потребностей конкретного подразделения, не предусматривая взаимодействия с компонентами других подразделений. Позже становится очевидным, что взаимодействие программных компонентов различных подразделений не только желательно, но и необходимо, а осуществить его чрезвычайно трудно, а порой и невозможно. Архитектуры таких ИС являются замкнуто-собственными (ad-hoc architecture). Подобные архитектурные решения затрудняют расширение системы, требуют существенной модификации объединяемых компонент ИС, что резко увеличивает стоимость разработки и сроков реализации.

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

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

Определим основные группы требований к средним и крупным ИС:

  1. Требования к системе в целом.
  2. Требования по соответствию стандартам.
  3. Требования по безопасности системы.
  4. Требования к аппаратной части и системному программному обеспечению:
    • серверные платформы;
    • платформы клиентов;
    • сети и телекоммуникации.
  5. Требования к интерфейсу с пользователем.
  6. Требования к системам доступа к данным;
  7. СУБД;
  8. информационным хранилищам;
  9. аналитической обработки данных.
  10. Требования к совместимости с другими ИС.
  11. Требования к миграции унаследованных систем.
  12. Требования по администрированию системы.
  13. и т.д.

Как пример раскрыты "требования к системе в целом":

  1. ИС не должна противоречить общегосударственным нормативным документам и инструкциям той организации, для которой осуществляется разработка.
  2. ИС должна эволюционировать:
    • ИС не должна полностью зависеть от производителей аппаратных и программных средств;
    • при разработке ИС необходимо опираться на международные и промышленные стандарты;
    • необходимо обеспечить расширяемость системы, т.е. возможность добавления новых компонентов в уже существующую ИС;
    • при разработке ИС необходимо предусмотреть возможность интеграции со смежными системами;
    • необходимо обеспечить инкапсуляцию старых задач.
  3. Разработку (анализ, проектирование и программирование) следует осуществлять согласно методологии, выбор которой необходимо обосновать.
  4. В соответствие с выбранной методологией необходимо сформировать технологию, учитывающую все аспекты разработки ИС.
  5. Уровень безопасности ИС должен соответствовать законодательству РФ и общепринятым мировым нормам.
  6. и т.д.

Важнейшим решением, принимаемым при создании ИС, является выбор и обоснование методологии и технологии разработки системы. Правильный выбор позволит адекватно решить поставленную задачу с оптимальными затратами. Использование методологии при создании ИС упорядочивает процесс разработки и позволяет решить проблемы, возникающие из-за повышенной сложности информационных систем. На сегодняшний день существуют два основных подхода к разработке программных систем, различие между которыми обусловлено критериями декомпозиции. Первый подход называют структурным, и в его основу положен принцип функциональной декомпозиции, при которой выделяют функциональные элементы системы и устанавливают строгий порядок происходящих действий [5,6,7]. Второй, объектно-ориентированный подход опирается на объектную декомпозицию [8,9,10,11,12]. В этом случае выделяются объекты, содержащие как данные, так и методы их обработки. Объекты обладают характерным для них поведением и, взаимодействуя друг с другом, обеспечивают общее поведение системы.

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

Архитектура взаимодействия компонент распределенной ИС

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

Рассматривая информационную систему как совокупность взаимодействующих компонентов, можно распределить их по следующим уровням:

  1. аппаратный - компьютеры, периферийные устройства, сетевое и телекоммуникационное оборудование и т.д.;
  2. системный и системно-зависимый - операционные системы, сетевые протоколы и т. д.;
  3. прикладной среды - средства middleware (CORBA, DCE, Tuxedo и т.д.), DBMS, Intranet, OLAP, коммуникационные интерфейсы...;
  4. приложения предметной области:
    1. общая инфраструктура - совокупность компонент ИС, пригодных для использования в различных предметных областях. Такими компонентами, например, являются:
      1. средства автоматизации бизнес-процессов (атомарных задач и потоков работ);
      2. средства управления доступом к информационным ресурсам;
      3. средства составления и печати отчетов (генераторы отчетов).
    2. компоненты реализующие модель предметной области(~ей);

Под проектированием архитектуры взаимодействия компонентов информационной системы (уровни II-IV) понимается выделение базовых компонентов, разработка их интерфейсов, а также определение правил и принципов взаимодействия этих компонентов.

Проектирование архитектуры взаимодействия компонентов ИС - один из наиболее важных и сложных этапов и ему не всегда уделяется достаточно внимания при разработке системы.

При проектировании архитектуры взаимодействия распределенных компонентов информационной системы различают следующие типы взаимодействия [13]:

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

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

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

Picture 6.

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

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

Picture 7.

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

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

Picture 8.

Рисунок 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 представлен граф, иллюстрирующий один из вариантов распределенной одноранговой архитектуры.

Picture 9.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Picture 10.

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

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

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

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

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

Для оценки существующих технологий интеграции компонентов информационных систем определяются следующие категории технологических решений, характеризующие воззрение конкретной организации на архитектуру информационной системы в целом [13,15]:

  1. Частные решения
  2. Разнообразные(смешанные) механизмы (Miscellaneous Mechanisms)
  3. Удаленные вызовы процедур на базе DCE RPC
  4. Распределенные объекты (CORBA, DCOM) (Distributed Object)
  5. Frameworks
  6. Стандартные архитектуры (Standard Architectures)

Коротко остановимся на решениях, соответствующих каждой из категорий.

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

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

Ко второй категории относятся технологические решения, предполагающие построение информационных систем из расчета на конкретную задачу и изначально не рассчитанные на использование технологий интеграции систем. Поэтому в данном случае в качестве средств интеграции используются такие механизмы, как сокеты (sоckets) протокола TCP/IP и ONC RPC (Object Network Computing Remote Procedure Call). Программное обеспечение данной категории, как правило, разрабатывается для использования только внутри конкретной организации, что приводит к резкому увеличению затрат при интеграции с другими системами.

В технологических решениях третьей категории предполагается использование технологий, базирующихся на средствах единообразной интеграции компонентов и имеющих преимущества в сравнении с решениями предыдущей категории. К данной категории относятся технологии на базе механизма вызова удаленных процедур (RPC), такие как OSF DCE. Как известно, OSF DCE определяет сервисы безопасности, именования и другие важные механизмы, необходимые для интеграции систем в распределенной среде. С другой стороны, создание объектно-ориентированной системы на базе DCE не может быть оптимальным решением в силу не полной объектно-ориентированности последней. Характерным недостатком OSF DCE считается сложность создания объектов как независимых компонентов распределенной системы и ориентированность на процедурный стиль программирования. Поэтому имеется тенденция рассматривать DCE как технологию, которая устарела в сравнении с новыми объектно-ориентированными технологиями построения распределенных систем, такими как технология CORBA и DCOM (по мере принятия стандарта). Использование данной технологии может привести к моральному износу системы [13].

В четвертой категории, при построении информационных систем используются ORB-технологии CORBA такие, как высокоуровневый механизм RPC. Здесь применяют сервисы и язык описания интерфейсов (OMG IDL), определенные в спецификации CORBA, только для обеспечения межплатформенного взаимодействия. В случае, когда межплатформенное взаимодействие не требуется, используются собственные механизмы взаимодействия компонентов системы. Важно отметить, что эти системы рискуют технологически устареть, используя специфические механизмы, не обеспечивающие реальных преимуществ программной архитектуры CORBA.

Технологические решения пятой категории предполагают разработку frameworks как основы программной архитектуры для использования в нескольких проектах. Как правило, framework воплощает тщательно продуманные принципы построения программной архитектуры и довольно часто создается с помощью средств, определенных в стандарте CORBA. Разработка frameworks - направление многообещающее и бурно развивающееся в последнее время, но это уже тема отдельной статьи.

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

Заключение

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

Литература

  1. Ладыженский Г. Системы управления базами данных - коротко о главном. // СУБД, 1995, #2.
  2. Эккерсон В. В поисках лучшей архитектуры клиент-сервер.- Сети, 1995, #4
  3. Васкевич Д. Стратегии Клиент/Сервер .- Киев: Диалектика, 1996.
  4. Материалы III международной конференции. Развитие и применение открытых систем.- Москва, 1996.
  5. DeMarco T. Structured Analysis and System Specification. - Englewood Cliffs, NJ : Yourdon Press, 1979.
  6. Page-Jones M. The Practical Guide to Structured Systems Design, 2nd ed. - Englewood Cliffs, NJ : Yourdon Press, 1988.
  7. Дэвид А.Марка, Клемент Л. МакГоуэн SADT, Методология структурного анализа и проектирования: Пер. c англ. - М.: 1993.
  8. Буч Г. Объектно-ориентированное проектирование с примерами применения. - М.: Конкорд, 1992.
  9. Rumbaugh J. et al. Object-Oriented Modeling and Design. - Englewood Cliffs, NJ : Prentice Hall, 1991.
  10. Coad P., Yourdon E. Object-Oriented Analysis, 2nd Ed. - Englewood Cliffs, NJ : Prentice Hall, 1991.
  11. Shlaer S., Mellor S.J. Object-oriented systems analysis : modeling world in data. - Englewood Cliffs, NJ: Yourdon Press, 1988.
  12. Ivar Jacobson Object Oriented System Engeenering (Use case driven approach), 1993.
  13. Thomas J. Mowbray, Phd Ron Zahavi. The Essential CORBA: System Integration Using Distributed Object, 1995.
  14. Сухомлин, Методологический базис открытых систем. - Открытые системы, 1996, #4.
  15. Robert Orfali, Dan Harkey, Jeri Edwards, The Essential Distributed Object. - John Wiley&Sons, Inc., 1996.
  16. Nayeem Islam, Distributed Objects Methodologies for Customizing Systems Software, IEEE Computer Society Press, 1996
  17. Ted Lewis and others. Object-oriented application Frameworks.- Manning Publications Co., 1995.
  18. Guide to Building Client/Server Solutions, Digital Equipment Corporation, January 1993.
  19. Аарон И. Волш. Основы программирования на Java для Word Wide Web . - Киев: Диалектика, 1996.
Кирилл Владимирович Ахтырченко, Виктор Владимирович Леонтьев НИВЦ МГУ ТОО "Фирма UNIS" Тел. (095) 939 - 2226