Применение технологии CORBA при построении распределенных информационных систем

Введение

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

При реализации проектов создания гетерогенных распределенных информационных систем, на различных этапах разработчиками все более активно применяются объектные методологии и технологии. При этом рост популярности объектных методологий и технологий сопровождается появлением с одной стороны объектных методологий анализа и проектирования [2,3,4,5,6], которые в совокупности уже сейчас составляют мощный методологический базис, а с другой стороны объектных технологий построения гетерогенных распределенных информационных систем, каковыми являются CORBA, Java, DCOM.

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

Среды взаимодействия компонент распределенной информационной системы

Согласно концепции построения единого информационного пространства[7], информационные системы состоят из программных компонентов (прикладных компонентов, СУБД, Web - серверов и др.), взаимодействующих друг с другом. Взаимодействие таких компонентов осуществляется на базе некоторой среды, основной целью которой становится реализация механизма, обеспечивающего возможность прозрачного взаимодействия компонентов в контексте гетерогенных распределенных сред, являющихся в силу различного рода причин (необходимость эффективного использования всех существующих внутри организации вычислительных ресурсов, наличие унаследованных приложений и т.п.) характерной чертой большинства крупных организаций. Построение среды взаимодействия, есть один из труднейших этапов разработки ИС. Как показывает практика, создание разработчиками ИС собственной, уникальной среды взаимодействия компонент приводит с одной стороны к резкому увеличению затрат на реализацию проекта построения ИС, а с другой к неполноте (ущербности) полученного решения. Здесь уместно провести аналогию с попытками создания своей собственной системы управления базами данных небольшими группами разработчиков, которые к моменту начала проекта не имели ни глубоких знаний, ни тем более опыта в данной области. Насколько оправдан данный подход? Как правило, в большинстве случаев можно было бы обойтись использованием промышленных СУБД (DB2, Informix, Oracle, Sybase и др.), которые воплощают хорошо отработанные решения крупных компаний, являющихся лидерами в данной отрасли. Но этого не происходит, и как результат появляется продукт, который, не имея перспектив развития (возможности наращивания функциональности, осуществления поддержки, интегрируемости с другими системами и т.п.), в дальнейшем все равно будет выброшен в мусорную корзину. Описанная ситуация во всех отношениях правомерна и для случаев реализации собственной, уникальной среды взаимодействия компонентов.

Исследование проектов создания распределенных ИС позволяют сделать вывод, что для того чтобы избежать неоправданных затрат на разработку собственной, уникальной среды, необходимо использовать уже существующие программные продукты, которые относятся к уровню промежуточного программного обеспечения (middleware), воплощая отработанные решения и реализуя так необходимые среды. Но не все продукты уровня middleware, могут использоваться в качестве среды взаимодействия компонентов крупной информационной системы. Это обусловлено тем, что одним из основных требований к крупной информационной системе является использование программных продуктов и технологий, удовлетворяющих международным и промышленным стандартам в области открытых информационных систем. История выполнения крупных проектов показывает, что поддержка стандартов существенно снижает риск устаревания крупных информационных систем, экономит капиталовложения, связанные с их сопровождением [14,17]. В качестве примера рассмотрим технологию, предлагаемую Forte Software, Inc. Данная технология воплощает прекрасные решения [25]. Однако, базовый механизм, обеспечивающий взаимодействие компонентов в рамках технологии Forte, уникален. Поэтому, не смотря на то, что имеется совокупность средств, обеспечивающих ее интеграцию с технологиями CORBA, DCOM, JavaBeans, DCE, Active/X, существует опасность ее использования. Она обусловлена попаданием в зависимость от одной фирмы - производителя, а, следовательно, большими накладными расходами, возникающими при организации взаимодействия существующих компонентов ИС с помощью какого - либо другого продукта уровня middleware.

Успех эффективного использования промежуточного программного обеспечения зависит от поддерживаемого им уровня взаимодействия компонент информационных систем. Чем выше уровень взаимодействия, тем проще разработчикам определять интерфейсы компонентов, осуществлять проектирование компонентов, реализовывать протоколы их взаимодействия. К настоящему моменту существует ряд технологий (CORBA, RMI, DCOM, DCE и др.), которые реализуют среды взаимодействия, соответствующие 6-7 уровню модели OSI [9,17]. Каждая из них уже стала стандартом де-факто, правильное использование которого облегчает процесс построения распределенных информационных систем, функционирующих в гетерогенных средах. Среди всего многообразия технологий, на сегодняшний день, CORBA приобрела набольшую зрелость, чтобы быть использованной при создании высоко-критичных распределенных информационных систем. На рынке программного обеспечения существует множество продуктов удовлетворяющих спецификациям CORBA 2.0 (M3, BeaBroker, Orbix, PowerBroker, VisiGenic и др.). На основе каждого из них имеются примеры успешно выполненных проектов в различных производственных отраслях (банковском деле, биллинге, авиационной промышленности и др.) [19,20,21].

Программная и технологическая инфраструктуры

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

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

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

Рис. 1. Модель, описывающая архитектуру информационных систем управления производственными процессами.

Компоненты программной инфрастуктуры, а также связи между ними, в большинстве случаев определяют ядро информационной системы, которое отражает ее программную архитектуру. Проектирование программной архитектуры - один из важнейших этапов создания информационной системы [8]. Довольно часто ему уделяется недостаточно внимания, что приводит в дальнейшем к отсутствию возможности эволюционного развития информационной системы. Не смотря на то, что программные архитектуры различных распределенных информационных систем отличаются друг от друга, можно рассматривать некоторый класс информационных систем, которые автоматизируют процессы, имеющие общую структурную организацию. Тогда существует высокая вероятность того, что на достаточно высоком уровне абстракции такие информационные системы будут иметь аналогичные программные архитектуры. В силу этого данную модель можно рассматривать как каркас программной архитектуры для достаточно широкого класса информационных систем.

Итак, представленная модель определяет четыре уровня. Остановимся коротко на каждом из них.

Уровень 1 включает различные среды взаимодействия компонентов, базирующиеся на таких технологиях как CORBA, RMI, DCE и DCOM. Программное обеспечение данного уровня реализует набор услуг, обеспечивающих возможность взаимодействия компонентов в гетерогенных средах. Так, например, любой ORB (Object Request Broker), удовлетворяющий спецификациям CORBA 2.0 позволяет [12, 17, 18]:

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

Кроме этого, в спецификациях CORBA 2.0 определяется GIOP (General Inter-ORB Protocol), который является одним из необходимых элементов поддержки интероперабельности ORB различных производителей [18, 23]. GIOP является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и может быть отображен в любой транспортный протокол, поддерживающий виртуальные соединения [23]. Так, в настоящий момент, все производители ORB в своих продуктах поддерживают протокол IIOP (Internet Inter-ORB Protocol), который специализирует GIOP и определяет дополнительно, как агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP. Отметим, что довольно часто, поддержка протокола IIOP уменьшает, но не сводит к нулю объем работ, связанных с организацией взаимодействия компонентов, управляемых различными ORB. Это связано тем, что, как и в случае с языком SQL, каждый из производителей стремится реализовать в своем продукте функциональность, выходящую за рамки стандарта, но предоставляющую более удобные средства реализации взаимодействия компонентов.

Как уже упоминалось выше, на основе предоставляемых уровнем 1 услуг, достаточно просто и быстро могут быть решены задачи телекоммуникационного взаимодействия, когда среда взаимодействия используется в качестве высокоуровневого RPC (Remote Procedure Calls), а так же небольшие модельные задачи. Это обусловлено тем, что для полноценного функционирования компонентов корпоративной информационной системы в гетерогенной среде нужно нечто большее. Действительно, сейчас практически невозможно представить себе крупную информационную систему, в которых не использовался бы механизм управления транзакциями и конкурентным доступом к ресурсам, не было бы необходимости в поддержке какой - либо политики безопасности, не решались бы задачи администрирования, лицензирования и конфигурирования, входящих в нее, компонентов. А раз так, то возникает вопрос: В каких компонентах и как должна быть реализована дополнительно требуемая функциональность? Результаты деятельности производителей программного обеспечения и организаций в области стандартизации, говорят о целесообразности ее оформления в виде набора служб, создаваемого на основе сред взаимодействия компонентов.

В связи с этим уровень 2 определяет слой универсальных служб. Данные службы реализуют базовый набор услуг, применяемые при решении различного рода задач, и выступают в роли "строительных" блоков при создании компонентов информационных систем. Типичными примерами таких служб являются Event Service, Naming Service, Transaction Service, Persistent Service, Security Service и др. В контексте архитектуры информационной системы, каждая из служб воплощает внутри себя микроархитектуру, создание которой, как правило, является результатом применения набора образцов проектирования(design patterns)[10]. Деятельность по разработке и спецификации служб ведутся такими организациями, как OMG (Object Management Group), Open Group и др. Практика показывает, что реализация многих из них, в отличие от сред взаимодействия, под силу небольшим группам разработчиков.

Применение служб уровня 2 предоставляет следующие возможности, способствующие уменьшению трудозатрат на разработку ИС:

• построения ИС из повторно используемых компонентов;
• использования хорошо отработанных архитектурных решений.

В отличие предыдущего уровня, уровень 3 определяет предметно - ориентированные службы, которые имеют смысл только в контексте некоторого класса релевантных предметных областей. Данные службы составляют промежуточный слой между прикладными и системными составляющими информационной системы. Их использование, как правило, связано с построением ИС, обладающих свойствами расширяемости, адаптируемости и интегрируемости, что характерно для крупных организаций, стремящихся осуществлять комплексную информатизацию. Примерами таких служб могут быть общие средства (Common Facilities), деятельность по разработке которых осуществляется под эгидой OMG. Так, в случае информационных систем финансового и управленческого учета, в качестве предметно-ориентированных службы часто выступает набор компонент, реализующих функции Workflow.

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

Реализация определяемых подсистем и поддерживаемых ими интерфейсов базируется на использовании служб и сред взаимодействия, расположенных на 1,2 и 3 уровнях модели. Так, например, при реализации управляющей структуры можно воспользоваться услугами службы, реализующей модель Workflow. При этом в качестве механизма поддержки распределенных бизнес - транзакций нередко используются менеджеры транзакций (реализации OMG Transaction Service, М3, Tuxedo и др.), которые, в свою очередь, могут обращаться за услугами к другим службам (Persistent Service, Concurrency Control Service, Property Service и т.п.).

Довольно часто при проектировании интерфейсов, разработчики определяют для каждой компоненты уникальный интерфейс, что в конечном итоге приводит к вертикальной архитектуре взаимодействия [7,9]. В случае большого числа компонент, это чревато существенным увеличением накладных расходов при модификации компонент. Горизонтальную архитектуру взаимодействия также нельзя считать оптимальной, так как она требует реализации сложного протокола взаимодействия. Как правило, наиболее приемлемым решением является использование смешанной архитектуры взаимодействия, когда интерфейсы между подсистемами являются горизонтальными, а внутри подсистемы используется вертикальный способ взаимодействия. Применение объектно-ориентированного подхода при анализе и проектировании позволяет инкапсулировать внутри подсистемы компоненты, которые в процессе эволюции информационной системы могут быть модифицированы. Тогда изменение интерфейсов компонентов из одной подсистемы не сопровождается изменением компонентов из другой подсистемы.

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

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

Консорциумом OMG специфицирован ряд служб (Object Services) и общих средств (Common Facilities), который может послужить основой для построения программной инфраструктуры гетерогенной распределенной информационной системы. Примерами служб являются:

• служба именования объектов (Naming Service),
• служба доставки сообщений (Event Service),
• служба свойств (Property Service),
• служба транзакций (Transaction Service),
• служба управления конкурентным доступом (Concurrency Control Service),
• и др.

Сегодня для многих из них уже существуют реализации, предлагаемые различными производителями программного обеспечения (BeaSystems, Iona Technologies, Expersoft и др.). К сожалению, не смотря на это многообразие, остается открытым один важный вопрос: Какие подходы и принципы должны использоваться разработчиками для эффективного применения служб на этапах проектирования и реализации распределенной ИС? Отсутствие очевидного ответа на это вопрос следует из следующего рассуждения. Известно, что службы OMG не являются независимыми друг от друга. Часть из них может быть создана на базе других служб. Согласно рекомендациям OMG, существует представленный на рисунке 2 граф зависимостей одной службы от другой.

Рис. 2. Граф зависимостей служб, специфицированных OMG.

Фактически, данный граф определяет этапность и относительную сложность реализации служб. Например, для того, чтобы создать службу запросов (Query Service), требуется наличие практически всех служб. И это понятно, поскольку с точки зрения предоставляемой функциональности она является одной из самых развитых, позволяя формулировать и выполнять запросы над объектами c использованием OQL (Object Query Language) ODMG[24], SQL или подмножества этих двух языков. При выполнении запроса служба может обратиться за услугами к Transaction Service, Relationship Service, Persistent Service, Concurrency Control Service, Property Service, часть из которых в свою очередь пользуется услугами Naming Service, Externalization Service, Life Cycle Service. Как результат возникает довольно длинная цепочка вызовов методов удаленных объектов, что может отрицательно сказаться на времени выполнения запроса. Для систем, обрабатывающих информацию в режиме реального времени и требующих гарантированного времени отклика на запрос это неприемлемо.

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

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

Как будет видно в дальнейшем, понимание сферы использования служб, а также знание методов их использования на этапе проектирования архитектуры информационной системы является ключевым фактором успешного применения служб. Другим важным аспектом эффективного применения служб можно считать наличие у разработчиков технологических приемов их совместного использования, ибо практика показывает, что использование одной из служб не решает проблем, связанных с построением крупных информационных систем на базе технологии CORBA. Так, например, служба именования объектов (Naming Service) обеспечивает связывание имен объектов относительно некоторого контекста именования, но изначально не предназначена для управления распределенными транзакциями или извещения заинтересованных объектов о происходящих в системе событиях. А ведь без данной функциональности не мыслима практически любая информационная система, работающая в режиме реального времени и выдвигающая повышенные требования к целостности обрабатываемой информации.

Исследования показывают, что не для всех задач службы могут быть использованы в том виде, в котором они специфицированы OMG. В связи с этим возникает вопрос: Достаточно ли функциональности, в, специфицированных OMG, службах? Ответ может быть и да, и нет. Все зависит от требований, выдвигаемых к информационной системе, от специфики рассматриваемых предметных областей. При выполнении реальных проектов, в ряде случаев можно либо вообще не использовать некоторые из служб, либо использовать их "облегченные" реализации, которые реализуют лишь часть специфицированной функциональности и/или пользуются услугами меньше рекомендованного числа других служб. В тоже время, существуют задачи, решение которых требует наличия дополнительных и/или расширения специфицированных OMG служб. В качестве примера рассмотрим службу управления конкурентным доступом (Concurrency Control Service). Поддерживаемый ей IDL - интерфейс определен с учетом совместного использования данной службы с Transaction Service. Однако существует ряд задач, в которых требуется обеспечить доступ к ресурсам на основе механизма блокировок, но совершенно нет необходимости в поддержке транзакций. Здесь возникает два варианта решения проблемы: либо создавать собственную уникальную службу, либо не реализовывать ряд методов, специфицированной OMG службы. Вероятнее всего, наиболее предпочтительным будет второе решение, поскольку оно на уровне IDL - интерфейса остается в рамках стандарта, а при необходимости может соответствующем образом дополнено до поддержки стандарта на уровне реализации.

В тоже время OMG жестко специфицировала модель блокировок, поддерживаемую Concurrency Control Service (таблица 2)[18].

Данная модель соответствует методу гранулированных синхронизационных захватов [22], а соответственно обладает всеми недостатками, характерными для этого метода. Так, например, хорошо известно, что в рамках данного метода не может быть решена проблема фантомов. Кроме, этого в ряде задач (например, при работе с большими целочисленными массивами) возникает необходимость явным образом осуществлять блокировки объектов, значения атрибутов которых попадают в определенный интервал. Для описанных случаев, служба управления конкурентным доступом в том виде, как она специфицирована OMG, просто не может обеспечить требуемую функциональность. В сложившейся ситуации, скорее всего, оправданным будет решение, сопровождающееся расширением Concurrency Control Service, когда определяется новый интерфейс, наследуемый от интерфейса, специфицированного OMG, а описание модели блокировок выносится на уровень конфигурации службы. Отметим, что описанный подход адаптации служб путем усечения/расширения функциональности может быть с успехом применен и по отношению к другим службам.

В заключение данного раздела отметим, что OMG продолжает деятельность по разработке новых спецификаций стандарта CORBA, включающих новые службы, механизмы, средства. Так, в 1997 году появилась спецификация CORBA 3.0. В настоящий момент уже появляются b-версии продуктов (например, Orbix, фирмы Iona Technologies), поддерживающих стандарт CORBA 3.0, который расширяет функциональность, определенную в предыдущих версиях. Эволюция версий стандарта CORBA (от 1.1 до 3.0) с точки зрения определяемых функций представлена на следующей диаграмме (рис. 3) [17].

Рис. 3. Эволюция версий стандарта CORBA.

Проектирование и реализация подсистем

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

Проектирование компонент

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

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

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

В настоящий момент существует достаточно много литературы, описывающей принципы реализации компонентов и объектов на языке C++. Поэтому, не останавливаясь на этом, перейдем к обсуждению основных принципов взаимодействия и вариантов декомпозиции CORBA - объектов, т.е. объектов, для которых определяются IDL - интерфейсы. Для этого рассмотрим следующие архитектурные решения, которые представлены на рисунке 4.

Варианты декомпозиции CORBA - объектов по компонентам

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

Рис. 4. Варианты декомпозиции CORBA - объектов.

В отличие от первого, второе решение не ограничивает число CORBA - объектов, поддерживаемых одной компонентой. При построении распределенных информационных систем, именно оно является наиболее распространенным и позволяет в наибольшей степени ощутить эффективность использования технологии CORBA. В его рамках особую значимость приобретает правильный выбор средств взаимодействия CORBA - объектов, расположенных в одной компоненте. Это обусловлено тем, что часть из них с одной стороны является обычными C++ объектами, а с другой поддерживает некоторый набор IDL - интерфейсов. Такое положение дел делает возможным обеспечить их взаимодействие либо средствами, предоставляемыми ORB (рис.4, б), либо с помощью C++ библиотеки, реализующей некоторый локальный framework взаимодействия (рис.4, в). Исследования показывают, что первый способ целесообразно применять в случае, если существует хотя бы небольшая вероятность того, что объекты в процессе эксплуатации информационной системы могут быть разнесены по различным компонентам. Так, например, нередко, для достижения более высокой производительности и/или отказоустойчивости требуется присутствие в системе нескольких одинаковых компонентов, объекты которых взаимодействуют друг с другом. На начальных стадиях проектирования необходимость в разделении не всегда очевидна, и если проектировщик ее не предусмотрел, и реализовал взаимодействие с помощью локального framework"а взаимодействия, то, в дальнейшем, могут возникнуть существенные расходы на перепрограммирование компонентов. С другой стороны, нельзя не отметить, что использование локального framework"а увеличивает скорость взаимодействия объектов, облегчает процесс программирования компонентов. Практика показывает, что наибольшей гибкости и производительности можно добиться лишь при разумном сочетании первого и второго способов взаимодействия, когда одни CORBA - объекты компоненты взаимодействуют с помощью локального framework"а, а другие пользуются услугами, предоставляемыми ORB.

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

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

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

Пользовательский интерфейс

Хотя подсистема пользовательского интерфейса занимает в большинстве случаев лишь небольшую часть всей гетерогенной распределенной информационной системы, но от этого она не теряет своей важности. Ведь подчас именно возможности, заложенные в данную подсистему, определяют внешние свойства разрабатываемой ГРИС. Сегодня с одной стороны уже стало нормой, когда в информационных системах масштаба корпорации присутствуют приложения, пользовательский интерфейс которых создается с помощью различных средств разработки (JavaBuilder, Microsoft C++, Delphi, PowerBuilder и др.). С другой стороны, что особенно характерно для крупных информационных систем, в процессе их эволюции появляются новые требования к визуализации вводимой и отображаемой информации, создаются новые языки и средства разработки. Как результат, становятся актуальными такие требования к компонентам данной подсистемы, как независимость от аппаратных и программных платформ, возможность модификации компонентов, без останова и перепрограммирования компонент из других подсистем. В связи с этим, в данном разделе рассматриваются те технологические решения, которые могут использоваться разработчиками для создания подсистемы пользовательского интерфейса, удовлетворяющей перечисленным требованиям.

Итак, как было описано в предыдущих разделах, на этапе проектирования архитектуры производится выделение всей функциональности, связанной с визуализацией информации, в отдельную подсистему. При этом компоненты подсистемы создаются на базе CORBA, или какой - либо другой среды взаимодействия (DCOM, DCE и др.). В чем преимущества данного решения?

Действительно, при такой декомпозиции, компоненты пользовательского интерфейса развязаны с компонентами других подсистем относительно средств их реализации. Это, во-первых, позволяет создавать компоненты на различных языках программирования с помощью различных средств разработки, и, во-вторых, существенно упрощает процесс модификации компонентов. Последнее обусловлено тем, что в отличие от двухуровневых архитектур с интеллектуальным клиентом [11], здесь в одной компоненте не объединяются бизнес - логика и функции визуализации вводимой и отображаемой информации. Кроме этого, использование CORBA позволяет определять горизонтальные IDL - интерфейсы между компонентами данной подсистемы и других подсистем, что согласно [9,12] облегчает процесс интеграции новых компонентов в информационную систему. Все это, в сумме, фактически, определяет независимость компонентов пользовательского интерфейса от остальных частей ИС, позволяя в процессе эксплуатации системы полностью заменять один вариант пользовательского интерфейса на другой без останова и перепрограммирования компонент из других подсистем.

Одной из задач, которую решают разработчики при создании пользовательского интерфейса является обеспечение возможности определения и сохранения настроек, индивидуальных для каждого пользователя системы. В случае применения технологии CORBA, одним из наиболее эффективных решений можно считать использование службы свойств (Property Service), специфицированной OMG. Данная служба поддерживает возможность динамически ассоциировать с объектами различные свойства, которые в случае пользовательского интерфейса приобретают статус настроек пользователя. При этом в процессе функционирования системы, могут, как изменяться значения уже существующих настроек, так и добавляться новые настройки, что обеспечивает в большинстве случаев требуемую гибкость. В различных реализациях данной службы сохранение настроек может осуществляться как на основе файловой системы, так и с использованием некоторой системы управления базами данных, в качестве которой могут выступать как реляционные, так и объектные СУБД (Informix, Oracle, Versant, ObjectStore и др.). Естественно предположить, что в случае информационных систем, выдвигающих повышенные требования к отказоустойчивости, более предпочтительным будет второй вариант.

Другой важной задачей, возникающей при построении пользовательского интерфейса, можно считать создании компонентов, функционирующих под различными операционными системами на различных аппаратных платформах без перекомпиляции исходного кода. Кроме этого, в мире все явственнее прослеживается тенденция, направленная на разработку таких информационных систем, доступ к которым мог бы быть осуществлен как из локальной сети, так и через Internet. В связи с этим, все чаще в качестве технологии построения компонентов пользовательского интерфейса выступает технология Java, которая изначально создавалась из расчета на поддержку независимости от платформ, отказоустойчивости, динамической загрузки компонент через WWW и т.д. Все, предоставляемые ей, преимущества правомерны при создании информационных систем на основе технологии CORBA, поскольку в рамках OMG определено отображение IDL на язык Java. Данный факт делает возможным совместное использование технологий CORBA и Java, предоставляя в руки разработчиков мощное интегрированное решение, ориентированное на создание гетерогенных распределенных информационных систем, и в частности подсистемы пользовательского интерфейса.

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

Так, в случае PULL - модели, в тот момент, когда клиент готов обрабатывать сообщения, производится запрос к серверу на предмет новых сообщений. Если на сервере для данного клиента сообщений нет, то последний ожидает некоторый промежуток времени, а затем снова посылает аналогичный запрос серверу (рис.5). Одним из достоинств решения, основанного на данной модели, можно считать простоту его реализации. Так, в случае двухуровневых архитектур, характерным примером является поддержка обмена сообщениями через сервер баз данных, где создается некоторая промежуточная база данных, к которой клиенты периодически посылают запросы на наличие новых сообщений. К сожалению, данная модель обладает рядом существенных недостатков. Действительно, нетрудно заметить, что возникает бесполезная нагрузка на сеть, характеризующаяся огромным количеством пустых вызовов (в двухуровневой архитектуре к серверу баз данных). При большом числе клиентов это может привести к существенному увеличению сетевого трафика и негативно сказаться на времени обработки информации. Кроме этого, запросы к серверу посылаются с некоторым интервалом, что приводит к постоянным задержкам при уведомлении. В некоторых системах, работающих в режиме реального времени, это может быть совершенно неприемлемо.

Рис. 5. Модель PULL доставки сообщений.

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

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

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

В зависимости от контекста решаемой задачи и пропускных способностей сетевых каналов, тип взаимодействия клиента и сервера сообщений может быть как асинхронным, так и синхронным. Используемый в модели PUSH способ взаимодействия компонент соответствует распределенной одноранговой архитектуре, описанной в [7]. Существуют следующие достоинства модели PUSH:

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

Рис. 6. Модель PUSH доставки сообщений.

При реальных разработках ИС, довольно часто используется как модель PULL, так и модель PUSH. Разумная комбинация компонент ИС, поддерживающих PULL/PUSH модели обмена сообщениями позволяет достичь высокого уровня гибкости и производительности создаваемой информационной системы. Нельзя не отметить, что в модели PUSH клиент должен быть одновременно и сервером, что в определенной степени усложняет его разработку и может восприниматься как недостаток данной модели. К счастью, при использовании технологии CORBA сложность реализации моделей PULL и PUSH практически одна и та же. Это обусловлено наличием в большинстве продуктов, поддерживающих стандарт CORBA, службы доставки сообщений (Event Service), специфицированной OMG. Данная служба поддерживает обе описанные модели и, как показывает практика, может быть с успехом применена в проектах создания распределенной информационной системы. Даже не имея в наличии службы доставки сообщений, для клиента достаточно просто определяется IDL - интерфейс, тривиальная реализация которого превращает клиента в сервер, способный не только запрашивать, но и принимать сообщения от других компонент.

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

Функциональная логика (Бизнес - логика) и Управляющая структура

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

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

В настоящее время преимущество получает та организация, руководители которой могут в короткий срок перестроить ее деятельность в соответствии с современными требованиями бизнеса. Как результат, многие существующие экономические модели управления устарели, поскольку предполагают наличие жесткой организационно-штатной структуры, статичность процессов, протекающих в организациях. К счастью, уже сегодня, им на смену приходят новые методы управления, в основе которых лежат более гибкие экономические модели [1,16], в которых предусмотрена возможность относительно безболезненного изменения производственных процессов. Поддержка возможности изменения процессов без перепрограммирования компонентов ИС положена в основу второго подхода. Здесь, в отличие от первого, описание структуры процесса носит декларативный характер и выносится на уровень конфигурации информационной системы. Тогда становится возможным создание набора компонентов, основной задачей которых является интерпретация декларативно описанного процесса и управление последовательностью выполняемых работ путем вызова и принудительного информирования исполнителей о заданиях, а также контролем их исполнения. Такие компоненты не связаны со спецификой предметной области, а, следовательно, могут быть оформлены в виде отдельной подсистемы (Управляющей структуры), которая носит универсальный характер и может использоваться во множестве различных проектов.

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

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

В связи с этим в качестве базового средства при создании подсистемы Workflow, чаще всего, используются различные менеджеры транзакций (реализации OMG Transaction Service, М3, Tuxedo и др.). Отметим, что иерархия процессов может представлять собой сильно ветвистое дерево глубины большей 2. Кроме этого часть процессов может выполняться параллельно. Поэтому немаловажным фактором успеха, при использовании менеджеров транзакций, становится возможность поддержки последними, как плоских (flat), так и вложенных (nested) транзакций.

Служба транзакций (Transaction Service), специфицированная OMG, поддерживает в обязательном порядке плоские транзакции и, в зависимости от реализации, вложенные транзакции. Кроме этого служба транзакций обеспечивает возможность участия в транзакциях как компонент, функционирующих на базе различных ORB, так и компонент, не являющихся CORBA - объектами, но поддерживающих стандарт X/Open DTP. На сегодняшний день, на рынке программных продуктов уже существуют реализации OMG Transaction Service (Expertsoft Transaction Service, Iona Transaction Service и др.) или продуктов, являющихся его расширениями (BeaSystems M3)[14]. Поэтому, неудивительно, что данная служба является одним из наиболее вероятных претендентов на использование при построении гетерогенных распределенных информационных систем, выдвигающих повышенные требования к отказоустойчивости, целостности вычислений и хранимых данных.

Для многих организаций (строительные компании и т.п.) бизнес - процессы могут быть продолжительными во времени (недели, месяцы и даже годы). Данный факт выдвигает некоторые трудности при реализации подсистемы Workflow, поскольку предполагает поддержку внутри подсистемы долговременных бизнес - транзакций. Для того, что бы преодолеть возникающие трудности, разработчики должны, во-первых, предусмотреть возможность сохранения всей информации, касающейся бизнес-процессов, во внешней памяти, и, во-вторых, приобрести или создать менеджер транзакций, поддерживающий долговременные транзакции. Важно отметить, что подсистема Workflow, а вместе с ней и служба транзакций, по сути, становятся центральным место всей гетерогенной распределенной системы. Поэтому при их создании разработчики должны уделять повышенное внимание, как этапам реализации и тестирования, так, и что более важно, этапу проектирования, ибо ошибки данного этапа, как показывает исследования[13,14], имеют наиболее плачевные последствия.

При изменении бизнес - процесса реально могут возникнуть следующие две ситуации. В случае первой, изменяется последовательность выполняемых работ, но типы участников остаются те же. В случае второй, изменяется как последовательность работ, так и типы участников бизнес - процесса. Как влияет каждая из ситуаций на необходимость перепрограммирования компонентов ИС? Поскольку описание бизнес - процесса носит декларативный характер, изменение последовательности выполняемых работ не сопровождается модификацией компонентов. Но даже, если происходит добавление, изменение или удаление компонентов-участников, то в случае использования технологии CORBA могут потребоваться лишь незначительные изменения. Это обусловлено тем, что между компонентами Workflow и компонентами, являющимися участниками бизнес - процесса и поддерживающими IDL - интерфейс, может быть реализована горизонтальная архитектура взаимодействия компонентов[9], которая базируется на универсальных контейнерах данных. Контейнер данных в самом общем виде представляет собой последовательность объектов типа any, определенного в IDL. Использование здесь данной архитектуры вполне оправдано, поскольку согласно определенной в предыдущих разделах модели, компоненты обмениваются только управляющей информацией, а ее объемы сравнительно небольшие.

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

Доступ к базам данных

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

• организации доступа к распределенным базам данных,
• организации доступа к неоднородным базам данных,

то указанная черта определяет локальную автономию компонентов подсистемы доступа к базам данных относительно других компонентов информационной системы, что в свою очередь существенно облегчает решение перечисленных выше проблем, упрощает создание повторно используемых компонентов, которые в процессе эксплуатации системы могли бы быть модифицированы без коренного перепрограммирования остальных подсистем ИС. Актуальность возникающих проблем обусловлена тем, что для многих крупных организаций уже стало нормой стремление к созданию федеративной системы управления базами данных. Согласно [15], основной задачей федеративной СУБД является интеграция неоднородных БД, а именно представление пользователям интегрированной системы некоторого взгляда на глобальную схему БД, представленной в некоторой модели данных, и автоматическое преобразование операторов манипулирования БД глобального уровня в операторы, понятные соответствующим локальным СУБД. Кроме этого, организация доступа к базам данных крупной информационной системы, в ряде случаев, может потребовать осуществление процесса миграции данных. Так, например, существуют следующие причины, которые вынуждают организации осуществлять процесс миграции данных:

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

Компоненты, решающие все перечисленные выше задачи реализуют функции хранения и управления данными, а, следовательно, являются частью подсистемы доступа к базам данных. Сложность ее построения, существенно зависит от технологии, используемой на различных этапах создания данной подсистемы. Так, применение технологии CORBA при построении подсистемы доступа к базам данных позволяет в большинстве случаев решить все, встающие перед разработчиками задачи. Действительно, OMG специфицирован ряд служб (Persistent Service, Relationship Service, Transaction Service, Query Service, Concurrency Control Service), реализующих многие функции объектных и реляционных систем управления базами данных. В тоже время, в предыдущих разделах упоминалось, что использование такой службы, как Query Service может быть сопряжено с неприемлемым временем выполнения запроса. Но как часто возникает необходимость в минимально возможном времени отклика на запрос? Для многих организаций, особенно в случае наличия унаследованных систем, на первый план выступает не скорость выполнения запроса, а возможность обеспечения единого интерфейса к неоднородным базам данных. В такой ситуации, использование Query Service вполне оправдано, поскольку позволяет на основе стандартных средств сделать подсистему открытой при интеграции ее компонентов с другими компонентами информационных систем. В тех ситуациях, когда перед разработчиками вырисовывается полный спектр описанных проблем, вполне естественным будет использование и других служб, реализующих функции систем управления базами данных. Например, различные реализации Persistent Service, обеспечивающие возможность сохранения и восстановления состояния CORBA - объекта, могут быть использованы при сохранении CORBA - объектов, имеющих сложную внутреннюю структуру.

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

Удаленный вызов метода такого сервера сопровождается выполнением некоторого множества операторов манипулирования БД. Тогда, при условии, что IDL - интерфейсы объектов сервера остаются неизменными, переход от одного сервера баз данных к другому сопровождается лишь заменой реализации методов объектов, что при использовании технологии CORBA может осуществляться без останова остальных компонент информационной системы. Важно отметить, что здесь не существует принципиальных ограничений на то, являются ли сервера баз данных однородными. Так, например, переход может осуществляться как от реляционной СУБД к объектной СУБД, так и наоборот. Это обусловлено тем, что практически все производители СУБД предоставляют средства встраивания операторов манипулирования БД в различные языки программирования, и, в частности, в C и C++. Вполне естественно, что данный подход обеспечивает существенно меньшее время отклика на запрос, чем в случае использования Query Service.

При использовании описанного подхода имеется возможность реализации горизонтальной архитектуры взаимодействия компонентов, которая, как и в случае подсистемы Workflow базируется на универсальных контейнерах данных. В качестве одной из возможных реализаций универсальных контейнеров может быть использована служба коллекций объектов (Collection Service), определенная в спецификациях Query Service. Горизонтальная архитектура взаимодействия в контексте тенденции, направленной на удешевление компьютеров, при увеличении их производительности, делает возможным построение компонентов информационной системы, в которых информация, отражающая специфику рассматриваемой предметной области, выносится на уровень конфигурации системы. Такие компоненты являются повторно используемыми, поскольку могут быть сконфигурированы под конкретный проект создания ИС. Как результат, при разработке подсистемы доступа к базам данных, могут быть созданы CORBA - сервера, IDL - интерфейс которых не зависит от специфики задач, решаемых в рамках рассматриваемого проекта построения ИС. Вся информация, связывающая CORBA - сервер с рассматриваемой предметной областью, содержится в его репозитории. Например, такой информацией может быть некоторое множество коллекций операторов (возможно параметризованных) языка БД. В случае использования языка SQL, коллекция фактически представляет собой составной запрос, состоящий из одного или более SQL - операторов и имеет некоторый уникальный идентификатор. Вызывая методы CORBA - серверов и передавая в них в качестве параметров идентификаторы коллекций и блоки данных, содержащие фактические параметры для параметризованных SQL - операторов, происходит выполнение соответствующей коллекции. Важно отметить, что и здесь не существует принципиальных ограничений на создание настраиваемых CORBA - серверов для СУБД, поддерживающих модель данных, отличную от реляционной. Так, например, в процессе эволюции информационных систем могут появиться реализации, обеспечивающие доступ к объектным СУБД, но, при условии статичности IDL - интерфейсов, это не будет сопровождаться изменением компонент из других подсистем ИС.

Заключение

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

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

Литература

1. Майкл Хаммер, Джеймс Чампи, "Реижениринг корпорации" - Издательство С. Петербургского университета, 1997.

2. Grady Booch,"Object - oriented analysis and design" - The Benjamin/cummings Publishing Company, Inc., 1994.

3. Mark Priestley, "Practical Object - Oriented Design" , 1996.

4. Arthur M. Langer, "The Art of Analysis" - Springer - Verlag New Work, Inc., 1997.

5. Rumbaugh J. et al. "Object-Oriented Modeling and Design" - Englewood Cliffs, NJ : Prentice Hall, 1991.

6. Martin Fowler with Kendall Scott, "UML distilled Applying the standard object modeling language" - Addison Wesley Longman, Inc., 1997

7. К. В. Ахтырченко, В. В. Леонтьев, Распределенные объектные технологии в информационных системах // СУБД 1997. №5-6

8. Robert J. Allen, "A Formal Approach to Software Architecture", Shool of Computer Science, Carnegie Mellon University, Pittsburgh, May 1997.

9. Thomas J. Mowbray, Phd Ron Zahavi, "The Essential CORBA: System Integration Using Distributed Object" ,1995.

10. Thomas J. Mowbray, Raphael C. Malveau "CORBA Design Pattern" - " - John Wiley&Sons Inc., 1997.

11. Эккерсон В. В поисках лучшей архитектуры клиент-сервер. // Сети. 1995. №4

12. Robert Orfali, Dan Harkey, Jeri Edwards, "The Essential Distributed Object" - John Wiley&Sons Inc., 1996.

13. Васкевич Д. " Стратегии Клиент/Сервер" / - Киев: Диалектика, 1996.

14. Jeri Edwards, "3-Tier Client/Server At Work" - John Wiley&Sons Inc., 1997.

15. Кузнецов С.Д. Введение в СУБД: часть 8. // СУБД. 1996. №4.

16. Ivar Jacobson, Maria Ericsson, Agenta Jacobson, "Th Object Advantage: Business process reengineering with Object Technology" - ACM Press, 1995.

17. Robert Orfali, Dan Harkey, Jeri Edwards, "Instant CORBA" - John Wiley&Sons Inc., 1997.

18. http://www.omg.org

19. http://www.iona.com

20. http://www.beasys.com

21. http://www.expertsoft.com

22. Кузнецов С.Д. Введение в СУБД: часть 5. // СУБД. 1996. №1.

23. Л.А. Калиниченко, М.Р. Когаловский Интероперабельность брокеров в стандарте CORBA 2.0 // СУБД. 1996. №3.

24. http://www.odmg.org

25. http://www.forte.com