|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #05-06/97
|
|
Сегодня, в условиях постоянного поиска, направленного на улучшение производственных процессов, и быстрого развития вычислительной техники и прикладного программного обеспечения, сложность информационных систем резко возрастает. Появляются новые концепции, технологии, архитектурные решения построения ИС. Совершается переход от статичной, централизованной структуры ИС к динамичной, гибкой, основанной на распределенности систем получения и обработки информации.
Специфика решаемых с помощью ИС задач, различная сложность их создания, модификации, сопровождения, интеграции с другими ИС и т.п., позволяют разделить информационные системы на следующие классы:
К классу малых информационных систем относятся системы уровня небольшого предприятия. К основным признакам таких систем следует отнести:
В отличие от предыдущего класса, признаками средних информационных систем являются:
И наконец, к характерным признакам корпоративных информационных систем следует отнести:
В настоящее время появляется множество статьей, касающихся описания продуктов, технологий и методологий, рассчитанных на создания малых и средних информационных систем. Технологии и методологии построения крупных информационных систем, объединяющих внутри себя множество локальных информационных систем, практически не рассматриваются и не обсуждаются. Довольно часто это приводит к тому, что в качестве технологий создания крупной информационной системы разработчики выбирают те, которые изначально на это не рассчитаны. В результате реализуемые проекты не получают должного развития, становясь "долгостроем", или умирают вообще.
В связи с этим в статье представлен концептуальный взгляд на создание информационных систем масштаба корпорации (уровня федеральных организаций) с использованием распределенных объектных технологий.
Современный уровень развития общества естественным образом вывел индустрию информационных технологий на одно из ведущих (стратегических) направлений, в котором сосредоточиваются огромные интеллектуальные и финансовые ресурсы. Информация и инструменты управления информацией (программные продукты различного функционального назначения) приобрели статус информационных ресурсов.
Информационные ресурсы концентрируются в рамках информационных систем (ИС). Объединение ресурсов на основе информационно-коммуникационного взаимодействия информационных систем выводит их на уровень корпоративных информационных ресурсов. Такое объединение будем называть Единым Информационным Пространством (ЕИП). Реализация ЕИП масштаба федерации, корпорации, предприятия возможна при создании и последующем соблюдении стандарта на взаимодействие между собой как информационных систем, так и их отдельных приложений (рис. 1).
К сожалению, в ряде случаев под информационными ресурсами понимают только данные, т.е. решение проблемы построения ЕИП сводится к организации доступа к удаленным базам данных. В результате понятие Единого Информационного Пространства сужается до понятия Единого Пространства Данных (ЕПД) (рис. 2), а информационные системы выступают в роли клиента и сервера, взаимодействуя друг с другом по сценарию представленному на рис. 3.
Информационная система-клиент (ИСК) посылает информационной системе-серверу (ИСС) запрос, получая в качестве результата данные, подлежащие дальнейшей обработке. В качестве языка запросов, как правило, используется язык SQL - стандарт общения с реляционными системами управления базами данных. Доступ к удаленным базам данных (БД) в большинстве случаев осуществляется с помощью продуктов, поддерживающих протоколы ODBC (Open DataBase Connectivity) и JDBC (Java DataBase Connectivity), либо используются шлюзы, поставляемые производителями СУБД или третьими фирмами-разработчиками.
Фактически, при построении единого пространства данных используется архитектура доступа к удаленным данным, являющаяся аналогом двухуровневой архитектуры клиент-сервер [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-технология способна улучшить ситуацию с импортом/экспортом данных между ИСК и ИСС, все-таки имеет место ряд недостатков, присущих двухуровневой архитектуре с интеллектуальным сервером.
Так, одним из недостатков, несомненно, является реальное отсутствие возможности реализации процесса обработки данных, поставляемых WWW-сервером, на стороне ИСК. Действительно, ИСК получает информацию от ИСС в виде HTML-страниц, что практически делает невозможным организацию процесса обработки полученных данных компонентами ИСК. Как следствие, это приводит к отсутствию требуемой эффективности использования вычислительных ресурсов информационных систем. С другой стороны, остро встает проблема поддержания безопасности системы в целом, которая в настоящий момент не имеет целостного решения в среде Internet, что не допустимо для организаций, выдвигающих повышенные требования к безопасности. И наконец, как и в предыдущем подходе, существенно усложняется администрирование ресурсов ИСС, включающее управление правами доступа пользователей ИСС.
В отличие от рассмотренных подходов, в концепции единого информационного пространства предусматривается, что в роли информационных ресурсов ИС (по отношению к рассматриваемой ИС) выступают не только данные, но и различные приложения информационных систем. Тогда в каждой из информационных систем часть методов обработки данных реализуется в виде приложений, доступных из других информационных систем. Например, при взаимодействии двух ИС первая пользуется сервисами, предоставляемыми второй, и как результат получает уже обработанные данные, которые могут быть подвергнуты дальнейшей обработке компонентами первой ИС.
Данный подход соответствует распределенной, одноранговой архитектуре взаимодействия [2, 18]. Согласно этой архитектуре, любые приложения из различных ИС могут выступать как в роли клиента, так и в роли сервера по отношению друг к другу, совместно решая те или иные задачи. Такой подход минимизирует дублирование приложений. Распределение приложений по различным информационным системам позволяет добиться оптимального баланса загрузки приложений и аппаратных средств, и, следовательно, приводит к эффективному использованию информационных ресурсов систем в целом.
Знание схемы базы данных необходимо только тому приложению, которое обрабатывает данные из этой базы данных. Использование ИСС сервисов, предоставляемых информационной системой-сервером и реализующих методы обработки данных, позволяет решить проблему изменения схемы удаленной базы данных. При этом статичность интерфейсов компонентов, предоставляющих ИСС набор сервисов, достигается путем применения методологий объектно-ориентированного анализа и проектирования, распределенных объектных технологий (СORBA, Java, DCOM (по мере принятия стандарта)) на различных этапах создания информационных систем.
И, наконец, так как в рамках конкретных информационных систем локализованы не только данные, но методы их обработки, происходит существенное уменьшение затрат на администрирование, сопровождение и модификацию информационных систем, составляющих единое информационное пространство.
Большинство как имеющихся, так и разрабатываемых в России информационных систем представляют собой приложения в двухуровневой архитектуре клиент-сервер. При этом в качестве средств общения клиента и сервера довольно часто используются не полностью стандартизированные механизмы триггеров и хранимых процедур. Специфика их реализации (неотделимость от ядра системы управления базами данных) приводит к необходимости наличия дополнительных вычислительных ресурсов на стороне сервера.
При увеличении выполняемых сервером работ системы в двухуровневой архитектуре клиент-сервер становятся все более похожими на большие ЭВМ (мэйнфреймы), а структуры обрабатываемых ими данных и способы их представления слабо доступны для использования совместно с другими приложениями [3]. Обычно взаимодействие рассмотренных приложений клиент-сервер организовывают средствами СУБД, что существенно перегружает серверную часть. С другой стороны, современные технологии позволяют создать интегрированную среду, которая как в рамках ИС, так и в рамках концепции Единого Информационного Пространства:
Сэкономить значительные финансовые средства при создании информационных систем, соответствующих современному уровню, возможно в результате организационных мероприятий, призванных осуществлять:
При разработке информационных систем особое внимание должно уделяться этапам анализа и проектирования. Однако часто этим пренебрегают, и построенные таким образом системы, как правило, быстро проявляют свою нежизнеспособность. За свой короткий жизненный цикл такие системы получили название "сгорающие системы" (stovepipe systems) [4]. Характерные черты таких систем:
Можно отметить следующие причины, приводящие к созданию нежизнеспособных проектов:
Часто система становится "сгорающей" из-за способа ее разработки. Это выражается в том, что на начальном этапе довольно часто создание программных компонентов ведется исключительно для внутренних потребностей конкретного подразделения, не предусматривая взаимодействия с компонентами других подразделений. Позже становится очевидным, что взаимодействие программных компонентов различных подразделений не только желательно, но и необходимо, а осуществить его чрезвычайно трудно, а порой и невозможно. Архитектуры таких ИС являются замкнуто-собственными (ad-hoc architecture). Подобные архитектурные решения затрудняют расширение системы, требуют существенной модификации объединяемых компонент ИС, что резко увеличивает стоимость разработки и сроков реализации.
Для упорядоченного процесса разработки и во избежание необдуманных сжигающих средства решений первоочередной этап создания ИС заключается в формировании стратегии разработки и дальнейшего использования такой системы. Необходимо наличие концептуальных решений по всем основным вопросам, в круг которых входят как общие проблемы построения крупной ИС, так и сложности, вызванные спецификой самой организации.
Характерной особенностью разработки стратегии является формирование требований к ИС и планирование разработки в целом (материальные затраты, время, ресурсы и т.д.), которые основаны на результатах предварительного анализа деятельности организации. На этом этапе выделяются требования к ИС с обоснованием по каждому принимаемому решению с учетом организационных, финансовых и технических ограничений.
Определим основные группы требований к средним и крупным ИС:
Как пример раскрыты "требования к системе в целом":
Важнейшим решением, принимаемым при создании ИС, является выбор и обоснование методологии и технологии разработки системы. Правильный выбор позволит адекватно решить поставленную задачу с оптимальными затратами. Использование методологии при создании ИС упорядочивает процесс разработки и позволяет решить проблемы, возникающие из-за повышенной сложности информационных систем. На сегодняшний день существуют два основных подхода к разработке программных систем, различие между которыми обусловлено критериями декомпозиции. Первый подход называют структурным, и в его основу положен принцип функциональной декомпозиции, при которой выделяют функциональные элементы системы и устанавливают строгий порядок происходящих действий [5,6,7]. Второй, объектно-ориентированный подход опирается на объектную декомпозицию [8,9,10,11,12]. В этом случае выделяются объекты, содержащие как данные, так и методы их обработки. Объекты обладают характерным для них поведением и, взаимодействуя друг с другом, обеспечивают общее поведение системы.
Другим важнейшим решением является обоснованный выбор технологии создания ИС. Технология создания информационных систем представляет собой совокупность практических инженерных знаний, применяемых в процессе разработки программного обеспечения на протяжении всего его жизненного цикла. Технология также описывает принципы организации и управления процессом разработки, представляя его в виде ряда последовательных и параллельных этапов, а также рабочих продуктов, создаваемых на этих этапах. С технологией неразрывно связаны инструментальные средства, используемые на различных стадиях разработки.
Выбор приемлемой технологии создания информационной системы напрямую зависит от выбора архитектуры ИС.
Рассматривая информационную систему как совокупность взаимодействующих компонентов, можно распределить их по следующим уровням:
Под проектированием архитектуры взаимодействия компонентов информационной системы (уровни II-IV) понимается выделение базовых компонентов, разработка их интерфейсов, а также определение правил и принципов взаимодействия этих компонентов.
Проектирование архитектуры взаимодействия компонентов ИС - один из наиболее важных и сложных этапов и ему не всегда уделяется достаточно внимания при разработке системы.
При проектировании архитектуры взаимодействия распределенных компонентов информационной системы различают следующие типы взаимодействия [13]:
Достоинства и недостатки этих типов взаимодействия легко проследить на примере интеграции новой задачи в информационную систему, состоящую из нескольких компонентов.
В случае использования вертикального типа взаимодействия распределенных компонентов объем кода, необходимого для интеграции, будет определяться количеством компонентов системы. На рис. 5 показана схема взаимодействия компонентов вертикально построенной системы. Количество интерфейсов в этом случае будет порядка N*N, где N - число компонентов. Для внедрения новой задачи потребуется 2N+1 раз разрабатывать новые связующие программы. Обычно такое решение является результатом недостаточного внимания, уделяемого проектированию архитектур ИС.
В случае горизонтально построенной системы (рис. 6) количество интерфейсов (интеграционного кода) будет минимальным. Добавление нового компонента потребует реализовать дополнительно всего два интерфейса.
При реальной разработке чрезвычайно трудно создать одинаковые интерфейсы для всех подсистем, поэтому наиболее предпочтительным для создания распределенной системы является смешанный тип взаимодействия компонентов (рис. 7). В этом случае построенная архитектура сохраняет свойство универсальности интерфейсов, но позволяет добавлять специфичные для данного приложения операции.
Количество кода, необходимого для интеграции новой задачи при такой архитектуре, изменяется в зависимости от конкретного проекта от 2 (горизонтальная архитектура) до 2N+1 (вертикальная архитектура).
Общие интерфейсы компонентов - ключ к проектированию архитектуры, обеспечивающей успешное развитие и поддержку системы на протяжение длительного периода.
При проектировании архитектуры приложений первым шагом должен быть выбор используемых стандартов. С увеличением сложности информационных систем, важность соответствия программного обеспечения стандартам возрастает. Стандарты используются для достижения следующих целей:
Как было сказано в предыдущем разделе, информационная система состоит из совокупности, взаимодействующих друг с другом, программных компонентов. Каждый из таких компонентов представляет собой программный модуль, исполняемый в рамках отдельного процесса. В компоненте, согласно [1], могут быть реализованы функции из следующих трех групп:
Декомпозиция функций из этих групп по компонентам определяет логическую архитектуру информационной системы. Выбор приемлемой логической архитектуры информационной системы является одним из важнейших этапов проектирования ИС.
С каждой логической архитектурой может быть связана диаграмма, описывающая отношения взаимодействия компонентов в ИС (пример на рис. 8).
Такая диаграмма представляет собой ориентированный граф. Дуги графа определяют отношения взаимодействия между программными компонентами ИС, являющимися его вершинами.
Вершины, реализующие функции пользовательского интерфейса, называются начальными и образуют множество начальных вершин S. В этих вершинах пользователь может вводить или получать информацию.
Вершины, реализующие функции хранения и управления данными, называются конечными и образуют множество конечных вершин T. В этих вершинах происходит управление (запись, выборка, модификация) данными в различных источниках информации (БД, файлах и т.п.).
Всевозможные цепи между элементами множества S и T образуют множество цепей C. ИСКлючаем из множества С все цепи, содержащие дуги, которые исходят из вершин, реализующих только функции третьей группы, или которые входят в вершины, реализующие только функции первой группы.
Каждой цепи Ci множества С ставим в соответствие число Li, равное количеству вершин в множестве, полученном из множества вершин входящих в цепь Ci путем исключения повторяющихся вершин.
Число L, равное наибольшему из всех Li, определяет количество уровней в рассматриваемой архитектуре. Число L фактически обозначает максимальное количество компонентов, участвующих в процессе, предполагающем выполнение функций из первой, второй и третьей групп.
Согласно введенному формализму, можно выделить следующие, наиболее распространенные, классы логических архитектур:
В качестве примера, на рис. 8 представлен граф, иллюстрирующий один из вариантов распределенной одноранговой архитектуры.
Двухуровневая архитектура предполагает, что количество уровней равно двум. Это означает наличие максимум двух программных компонентов, в совокупности реализующих функции из первой, второй и третьей группы.
Один из двух компонентов выступает в роли сервера, т.е. реализует набор сервисов, доступных другому компоненту, который выступает в роли клиента, т.е. в процессе работы пользуется сервисами, предоставляемыми сервером. Компоненты могут располагаться как на одном компьютере, так и на различных компьютерах, объединенных в сеть.
Различия в реализациях двухуровневой архитектуры определяются в основном тем, функции каких групп выполняет клиент, а каких сервер. Существует несколько вариантов декомпозиции функций представления, прикладных функций и функций хранения и управления данными в рамках двухуровневой архитектуры ИС.
Согласно указанным вариантам декомпозиции, можно говорить о следующих двухуровневых архитектурах:
Двухуровневые архитектуры обладают рядом достоинств и недостатков, частично описанных в [1,2]. Использование двухуровневых архитектур при построении крупных информационных систем, исходя из присущих им недостатков, приводит во многих случаях к краху проектов, связанных с их разработкой.
Трехуровневая архитектура предполагает, что количество уровней равно трем, что означает наличие максимум трех программных компонентов, которые участвуют в процессе, предполагающем выполнение функций из первой, второй и третьей группы.
Трехуровневые архитектуры предусматривают не столь жесткие связи между клиентом и сервером и более гибкие формы распределенной обработки [2]. Наиболее распространенной считается архитектура, согласно которой выделяются три компонента ИС (представления, прикладной, доступа к информационным ресурсам), являющиеся автономными и общающиеся через средства межпроцессного взаимодействия при помощи стандартных интерфейсов. Отдельные компоненты могут располагаться как на одном компьютере, так и на разных компьютерах, обеспечивая тем самым распределенную обработку информации. Компонент представления часто располагается на персональном компьютере, прикладной компонент (называемый также сервером приложения) выполняется сервером среднего уровня под управлением операционной системы Unix или Windows NT, а компонент доступа к данным и сами данные располагаются либо на мощных Unix-серверах, либо на больших или мини-ЭВМ. Однако на практике все три компонента могут с успехом выполняться и на одном компьютере.
Основным элементом трехуровневой архитектуры является сервер приложения. Как правило, в нем реализуется несколько прикладных функций, каждая из которых оформлена как сервис (service) и предоставляет некоторые услуги всем компонентам представления, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый из них может предоставлять определенный набор севрисов. Детали реализации прикладных функций в серверах приложений полностью скрыты от клиентов. Кроме того, разработчики могут создавать, изменять или переносить любые компоненты ИС, практически не затрагивая других.
Согласно распределенной одноранговой архитектуре клиент (рис. 10) [2,18], взаимодействующий с сервером приложений, трактуется более широко, чем компонент представления. Он может поддерживать интерфейс с конечным пользователем, а может выполнять прикладные функции и являться сервером приложения. В общем случае, в рамках данной архитектуры, клиент (сервер) может как предоставлять, так и запрашивать некоторые сервисы. Это позволяет на этапе проектирования информационной системы осуществить такую декомпозицию функций из указанных выше трех групп по компонентам ИС, которая была бы оптимальной в контексте решаемой задачи.
Для обеспечения взаимодействия компонентов информационной системы, поддерживающей распределенную одноранговую архитектуру, необходимо создать промежуточный программный уровень (middleware), при помощи которого запросы принимаются от клиентов и направляются соответствующему серверу. К счастью, сегодня уже имеется или анонсировано достаточное количество инструментальных средств, позволяющих разработчикам строить распределенные ИС, не вдаваясь в детали реализации взаимодействия клиента и сервера. Многие из этих программных продуктов реализуют стандарт CORBA (Common Object Request Broker Architecture), а некоторые инструментальные пакеты (например, продукт Orbix фирмы IONA Technologies) предлагают расширенные варианты этого стандарта.
Распределенные одноранговые архитектуры имеют более универсальный характер, чем двухуровневые и трехуровневые архитектуры. Четкое разграничение логических компонентов, присущее распределенным одноранговым архитектурам, и рациональный выбор программных средств позволяют достичь такого уровня гибкости, открытости и производительности ИС, который пока недостижим при использовании двухуровневых и трехуровневых архитектур.
Гетерогенные вычислительные среды сегодня стали реальностью для многих организаций. В связи с этим повышаются требования к интеграции разнородных приложений, автоматизирующих деятельность предприятий и функционирующих в распределенных средах с широким диапазоном платформ и сетей. Крупные организации, как, например, Центральный банк РФ, Государственная налоговая служба, Таможенный комитет, имеют различные компьютерные системы (SUN, RS6000, IBM PC, Alpha и т.д.), которые установлены в одном или разных местах. Для администраторов компьютерных систем, основной проблемой является обеспечение взаимодействия этих систем для их совместной работы. Перед разработчиками приложений, во-первых, стоит проблема создания такого программного обеспечения, которое могло бы работать на максимально возможном числе платформ, используемых в организации. Во-вторых, разработка приложений в концепции Единого Информационного Пространства, должна осуществляться либо на основе собственных стандартов (замкнутое решение), либо на основе общепринятых международных стандартах. Используя международные стандарты, можно достаточно просто интегрировать в ИС программные продукты фирм, следующих этим стандартам. В третьих, разработчикам необходимо предусмотреть возможность модификации приложений ИС так, чтобы процесс модернизации был минимален по времени и затратам. А этого можно достичь, следуя определенным принципам выделения и объединения компонент информационных систем.
Для оценки существующих технологий интеграции компонентов информационных систем определяются следующие категории технологических решений, характеризующие воззрение конкретной организации на архитектуру информационной системы в целом [13,15]:
Коротко остановимся на решениях, соответствующих каждой из категорий.
Как уже упоминалось выше, одним из основных требований, которым должны удовлетворять распределенные информационные системы, является использование программного обеспечения и технологий, согласующихся с общепризнанными стандартами, определяющими принципы взаимодействия компонент ИС.
Технологические решения, относящиеся к первой категории, базируются на основе собственных (уникальных для данной организации) протоколов и интерфейсов взаимодействия. Такие решения, в большинстве случаев, порождают непреодолимые трудности при попытке организации общения компонентов данной ИС с компонентами информационных систем, построенных на основе других решений межкомпонентного взаимодействия.
Ко второй категории относятся технологические решения, предполагающие построение информационных систем из расчета на конкретную задачу и изначально не рассчитанные на использование технологий интеграции систем. Поэтому в данном случае в качестве средств интеграции используются такие механизмы, как сокеты (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, что в конечном итоге позволяет организациям практически на нет свести риск устаревания систем. Важно отметить, что не каждая организация способна создать технологию мирового класса. Организации, разрабатывающие решения шестой категории, - всемирно известные фирмы, являющиеся создателями стандартов взаимодействия систем в своей отрасли.
Активно развивающееся направление объектно-ориентированных методологий и технологий создания ИС позволяют по-новому взглянуть на процесс разработки и эксплуатации информационных систем. Поэтому в заключении хотелось бы отметить, что данная статья является лишь вводной частью в концепцию построения крупных информационных систем с использованием распределенных объектных технологий. Остались практически не затронутыми многие актуальные проблемы, связанные с созданием корпоративных гетерогенных распределенных информационных систем, которые предполагается осветить в последующих статьях.
|
|