Архитектуры и технологии разработки интероперабельных систем

Л.Калиниченко, Институт проблем информатики РАН,
E-mail: leonidk@ipian23.ipian.msk.su

Введение

Настоящий доклад рассматривает аспекты новой, быстро развивающейся и уже интенсивно применяемой технологии создания открытых систем - технологии интероперабельных систем.
Рассматриваемая технология привела к выделению нового архитектурного слоя - информационной архитектуры систем, определяющей способность совместного использования, совместной деятельности (в дальнейшем будет использоваться термин "интероперабельность") компонентов (информационных ресурсов) для решения задач. Этот слой расположен обычно над сетевой архитектурой, являющейся необходимой предпосылкой такой совместной деятельности компонентов, обеспечивающей их взаимосвязь.
Деятельность по созданию технологии интероперабельных систем охватывает весь мир. Наиболее существенный вклад в принимаемые идеологические, архитектурные и технологические решения интероперабельных систем вносит Object Management Group (OMG) - крупнейший в мире консорциум разработки программого обеспечения, включающий свыше 600 членов - компаний - производителей программного продукта, разработчиков прикладных систем и конечных пользователей. Так например, в OMG входят: Air Force Institute of Technology, American Airlines, Apple Computers, AT&T, Bellcore, Boeing Computer Services, Borland Inter\-national, Chase Manhattan Bank, Digital Equipment, Fujitsu Ltd., General Electric, Hewlett-Packard, IBM, ICL, Informix Software Inc., Ingres Ltd., Intel Corp., Los Alamos National Lab., Microsoft Corp., MIT, Oracle Corp., Siemens AG, SunSoft Inc., Sybase Inc., Texas Instruments Inc., US Defense Information Systems Agency. Целью OMG является создание согласованной информационной архитектуры, опирающейся на теорию и практику объектных технологий и общедоступные для интероперабельности спецификации интерфейсов информационных ресурсов. Эта архитектура должна обеспечивать повторное использование компонентов, их интероперабельность и мобильность, опираясь на коммерческие продукты.
Другие организации, которые работают в кооперации с OMG, например, с целью доведения результатов OMG до официальных стандартов в различных аспектах, включают: ANSI, ISO, CCITT, ANSA, X/Open Company, Object Database Management Group (ODMG).
В настоящем докладе предлагается краткий обзор структуры и компонентов архитектуры интероперабельных систем в соответствии с текущим состоянием разработки стандартов (более подробную информацию можно найти в [3,8,9]).

Потребности применений

Насущные потребности применений, определяющие существенную мотивацию для перехода к интероперабельным информационным системам и разработки соответствующей технологии, включают следующие.
Функционирование систем в условиях информационной и реализационной неоднородности, распределенности и автономности информационных ресурсов системы. Информационная неоднородность ресурсов заключается в разнообразии их прикладных контекстов (используемых онтологических средств - понятий, словарей; отображаемых реальных объектов, составляющих "поверхность соприкосновения" различных реальных миров и их (объектов) абстракций в информационных системах; семантических правил, определяющих адекватность совокупностей моделируемых объектов реальности; моделируемых деятельностей; видов данных, способов их сбора и обработки; интерфейсов пользователей и т.д.).
Реализационная неоднородность источников проявляется в использовании разнообразных компьютерных платформ, средств управления базами данных, моделей данных и знаний, средств программирования, операционных систем, и т.п.
Интеграция систем. Системы эволюционируют от простых, автономных подсистем к более сложным, интегрированным системам, основанным на интероперабельном взаимодействии компонентов.
Реинженерия систем. Эволюция деловых процессов - это непрерывный процесс, который является неотъемлемой составляющей деятельности организаций. Соответственно, создание системы и ее реконструкция (реинженерия) - непрерывный процесс формирования, уточнения требований и конструирования. Реконструкция систем осуществляется постепенно. Система должна быть сконструирована так, чтобы произвольные ее составляющие могли быть реконструированы при сохранении целостности системы.
Миграция унаследованных систем. Любая система после создания противодействует изменениям и имеет тенденцию быстрого превращения в бремя организации (т.н. legacy systems - унаследованные системы, использующие "уставшие" технологии, архитектуры, платформы, а также собственно программное и информационное обеспечение, при проектировании которых не были предусмотрены нужные меры для их пошаговой миграции в новые системы, соответствующие новым требованиям деловыx процессов и технологии). Существенно, что в процессе миграции необходимо, чтобы мигрировавшие составляющие системы и оставшиеся компоненты унаследованных систем сохраняли интероперабельность.
Повторное использование неоднородных информационных ресурсов. Технология разработки информационных систем должна позволять крупномасштабно применить технологию повторного использования информационных ресурсов, переходя от технологии программирования, основанной на интенсивном индивидуальном труде по созданию вручную изделий, удовлетворяющих специфическим требованиям одного конкретного применения, к технологии, основанной на планируемых капиталовложениях в разработку повторно -используемых компонентов, которые могут быть "соединены" (т.е., образованы их интероперабельные сообщества) для производства серий стандартизованных продуктов в определенной прикладной области.
Продление жизненного цикла систем. В условиях исключительно быстрого технологического развития требуются специальные меры, обеспечивающие необходимую продолжительность жизненного цикла.
Существенно, что свойство интероперабельности информационных ресурсов является необходимой предпосылкой удовлетворения перечисленных требований.
Архитектура промежуточного слоя (middleware)
Основу информационной архитектуры систем составляет концепция промежуточного слоя (middleware) - сосредоточение родовых служб в специальном слое архитектуры, расположенном между операционной системой и средствами управления компьютерными сетями и прикладными системами, специфическими для конкретных областей применения [2].
Традиционно к такому промежуточному слою относились средства управления и доступа к данным, средства разработки программ, средства управления распределенными вычислениями (включая поддержку необходимых протоколов взаимодействия), средства поддержки пользовательского интерфейса и др. Такие инфраструктуры использовались как отдельными компаниями (IBM), так и в международных проектах (UNIX - ориентированная интеграционная среда) [2]. Применяемые идеи и технологии не позволяли до сих пор решить радикально архитектуру промежуточного слоя.
OMG на основе объектной технологии и идеи интероперабельности вводит концепцию промежуточного слоя последовательно, радикально и до конца. Технически интероперабельность компонентов (представляемых объектами) решена введением базовой объектной модели, унифицированного языка спецификации интерфейсов объектов, отделением реализации компонентов от спецификации их интерфейсов, введением общего механизма поддержки интероперабельности объектов (брокера объектных заявок, играющего роль "общей шины", поддерживающей взаимодействие объектов). Тем самым достигается однородность представления компонентов и их взаимодействия. Далее, для формирования информационной арxитектуры вводится слой унифицированных (ортогональных) служб, которые используются как при конструировании прикладных систем, так и для формирования функционально законченных средств промежуточного слоя, предлагающих конкретные виды услуг. Существенно, что и службы и средства представляются однородно своими объектными интерфейсами, что позволяет обеспечить их интероперабельность посредством брокера объектных заявок.
Объектная модель OMG. Объектная модель OMG определяет общую объектную семантику для спецификации базовыx характеристик объектов стандартным, независимым от реализации образом.
Объектная модель OMG определяется в виде объектной модели -- ядра (Core Object Model (COM)) и совокупности расширений. Объектная модель -- ядро специфицирует некоторый набор базовых понятий. Примерами понятий COM являются объекты, операции, типы, отношение тип/подтип, наследование, интерфейс типа. Каждое расширение вводит дополнительный набор понятий. Расширяться может либо COM, либо уже существующие и согласованные расширения. При этом вводится понятие профиля, как некоторой комбинации COM и одного, или нескольких расширений, вместе поддерживающих определенную целевую архитектуру.
Эталонная модель архитектуры OMG. Эталонная Модель [20] определяет концептуальную схему для поддержки технологии, удовлетворяющей техническим требованиям OMG. Она идентифицирует и характеризует компоненты, интерфейсы и протоколы, составляющие Архитектуру Управления Объектами OMG (Object Management Architecture (OMA)), не определяя, впрочем, их детально.
Согласованная с OMA прикладная система состоит из совокупности классов и экземпляров, взаимодействующих при помощи Брокера Объектных Заявок (Object Request Broker (ORB)). Объектные Службы (Object Services) представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку базовых функций объектов. Общие Средства (Common Facilities) образуют набор классов и объектов, поддерживающих полезные во многих прикладных системах функции. Прикладные объекты представляют прикладные системы конечных пользователей и обеспечивают функции, уникальные для данной прикладной системы.

Компоненты архитектуры

Брокер Объектных Заявок. Брокер Объектных Заявок обеспечивает механизмы, позволяющие объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь о положении в распределенной среде и способе реализации взаимодействующих с ними объектов. ORB отвечает за поиск реализации объекта, участвующего в заявке, подготовку объектной реализации к приему заявки и передачу данных, являющихся результатом заявки. Интерфейс клиента полностью независим от расположения вызываемого объекта, языка программирования, на котором он реализован, и любых других аспектов, не отраженных в интерфейсе вызываемого объекта. На основании совместных предложений ряда ведущих компаний OMG был разработан стандарт Общей Архитектуры Брокера Объектных Заявок (Common Object Request Broker Architecture (CORBA)) [7]. CORBA определяет среду для различных реализаций ORB, поддерживающих общие сервисы и интерфейсы. Это обеспечивает переносимость клиентов и реализаций объектов между различными ORB.
В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту CORBA [7]. CORBA непрерывно совершенствуется OMG. Текущий уровень стандарта -- CORBA 2.0.
Объектные Службы. Объектные Службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают базовые функции, необходимые для реализации других объектов. Операции, предоставляемые Объектными Службами, выступают в качестве базовых "строительных" блоков для Общих Средств и прикладных объектов. В настоящее время OMG приняты, или наxодятся в процессе формирования спецификации следующиx служб:

Служба Уведомления Объектов о Событии (Event Notification Service).
Служба Жизненного Цикла Объектов (Object Lifecycle Service).
Служба Именования Объектов (Name Service).
Служба Долговременного Хранения Объектов (Persistent Object Service).
Служба Управления Конкурентым Доступом (Concurrency Control Service).
Служба Внешнего Представления Объектов (Externalization Service).
Служба Объектных Связей (Relationships Service).
Служба Транзакций (Transaction Service).
Служба Изменения Объектов (Change Management Service).
Служба Лицензирования (Licensing Service)/
Служба Объектных Свойств (Properties Service).
Служба Объектных Запросов (Object Query Service).
Служба Безопасности Объектов (Object Security Service).
Служба Объектного Времени (Time Service).

Функции СУБД в информационной арxитектуре. Следуя принципам модульности и ортогональности компонентов информационной архитектуры, OMG представляет функции управления базами данных рядом таких служб, как долговременное хранение объектов, управление конкурентным доступом к объектам, служба транзакций, службы объектных связей, объектных запросов, изменений объектов и т.п. Эти и другие службы, взятые вместе, реализуют функции как объектных так и реляционных СУБД.
Спецификация служб формируется на основе опыта промышленных корпораций, входящих в состав OMG. Существенное влияние на архитектурные решения оказывают также исследования и разработки, воплощенные в согласованном стандарте интерфейсов объектных СУБД [7,13], опубликованном в конце 1993 г. группой ODMG (Object Database Management Group). Эта группа включает представителей основных компаний - производителей объектных СУБД.
Общие Средства. Общие Средства заполняют концептуальное пространство между ORB и объектными службами с одной стороны, и прикладными объектами с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные Службы -- фундаментальные объектные интерфейсы, а задача Общих Средств -- поддержка интерфейсов сервисов высокого уровня. Общие Средства подразделяются на две категории: "горизонтальные" и "вертикальные" наборы средств. "Горизонтальный" набор средств определяет операции, используемые во многих системах, и не зависящие от конкретных прикладных систем. "Вертикальный" набор средств представляет технологию поддержки конкретной прикладной системы (вертикального сегмента рынка), такого, как здравоохранение, производство, управление финансовой деятельностью, САПР и т.д.
Ниже кратко рассматривается состав первоначальных компонентов спецификации архитектуры Общих Средств OMG [16,17].
Средства поддержки пользовательского интерфейса (User Interface Common Facilities)
Средства управления информацией (Information Management Common Facilities)
Средства управления системой (System Management Common Facilities)
Средства управления задачами (Task Management Common Facilities)
Вертикальные общие средства (Vertical Common Facilities)
Вертикальные общие средства предназначены для использования в качестве стандартных для обеспечения интероперабельности в специфических прикладных областях.
Поддержка интероперабельности брокеров в стандарте CORBA 2.0
Интероперабельность брокеров поддерживается Универсальным Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP [9] является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и может быть отображен в любой транспортный протокол, поддерживающий виртуальные соединения. Одно из таких отображений - отображение GIOP в протокол TCP/IP - определено CORBA 2.0 в качестве Межброкерного Протокола Internet (Internet Inter-ORB Protocol, сокращенно IIOP). Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать сети брокеров в рамках Internet и за ее пределами.
Согласно GIOP, внутренняя архитектура брокеров предполагается неизвестной. Подход, который может быть выбран конкретным брокером для поддержки GIOP/IIOP, не определяется. Все, что требуется для согласованного включения брокера в компьютерную сеть, - это существование связанных с ним компонентов, способных посылать и принимать сообщения IIOP.
Спецификация GIOP включает:

Определение Общего представления данных (Common Data Representation - CDR), являющегося, по существу, коммуникационным синтаксисом, отображающим значения типов данных OMG IDL в формат передачи данных между брокерами и межброкерными мостами (агентами);
Форматы передаваемых между агентами сообщений GIOP, которые введены для поддержки объектных заявок, установления местоположения реализаций объектов и управления транспортными соединениями.
Определение ограничений на допустимый сетевой транспорт GIOP.

Протокол IIOP, который можно считать специализацией GIOP, определяет дополнительно, как агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP.

Интеграция CORBA и WWW-технологий

Быстрое распространение всемирной паутины (WWW) происходило в тот период, когда распределенные объектные системы, в особенности архитектура CORBA, проходили стадию стабилизации и созревания. Принятие стандарта CORBA 2.0 [9] позволяет обеспечить поддержку глобального объектного пространства в масштабе Internet.
Существенное различие назначений WWW и CORBA заключается в том, что WWW облегчает жизнь поставщиков и потребителей информации, а CORBA облегчает задачу разработчиков систем и фирм-поставщиков инструментальных средств. Поэтому роли WWW и CORBA являются взаимно дополняющими, и в этой связи требуются специальные технологии, обеспечивающие их сопряжение. Такое сопряжение сулит очевидные преимущества. Разработчики программных продуктов, использующие CORBA, получают доступ к быстро растущему рынку на основе WWW, а мир WWW получает доступ к услугам, обеспечиваемым на основе возможностей CORBA, значительно более мощным, чем реализуемая WWW простая модель обмена HTML-страницами. Интеграция двух миров приведет к наилучшему использованию этих двух стандартов.
Известны два основных подхода к интеграции CORBA и WWW. Первый из них основан на построении шлюзов между мирами WWW и CORBA, служащих для трансформации HTTP в протокол CORBA 2.0 IIOP [9]. Другой подход заключается во встраивании функций CORBA в состав клиентов WWW (программ просмотра) и серверов. Реализация второго подхода возможна либо на основе новых WWW клиентов и серверов со встроенным IIOP, либо при помощи подгрузки (downloading) из сети модуля поддержки IIOP в клиенте или сервере.
В новом поколении WWW клиентов и серверов, поддерживающих Java, модуль поддержки IIOP реализуется на Java. Достоинства этого подхода заключаются в обеспечении динамической "раскрутки" функций по отношению к CORBA. Так, для любого ресурса, доступного посредством CORBA, может быть разработан пользовательский интерфейс как апплет Java. Этот апплет использует модуль IIOP для взаимодействия с сервером CORBA. При первом доступе пользователя к какой-либо услуге, программа просмотра автоматически загружает и инсталлирует апплет пользовательского интерфейса. После этого пользователь имеет доступ к этой услуге посредством собственного апплета.
Таким образом, услуги объектов-серверов оказываются доступными широчайшей аудитории, независимо от применяемых пользователями платформ и при сохранении для разработчика возможности усовершенствования реализации услуг и их интерфейсов.

Семантическая интероперабельность

До сих пор усилия промышленности, выражающиеся в деятельности OMG, были направлены на поддержку системного, технического уровня интероперабельности, основанного на полной инкапсуляции информационных ресурсов (язык IDL является отражением этого подхода). Вместе с тем при программировании прикладных задач на основе имеющихся ресурсов требуется решение вопроса о релевантности имеющихся ресурсов задаче, о соответствии их прикладного контекста контексту задачи и о том, что интероперабельная композиция ресурсов будет непротиворечивой в прикладном контексте задачи. Такая композиция ресурсов образует мегапрограмму, выполнение которой при заданных параметрах должно давать решение прикладной задачи. Очевидно, что достижение подобной {\em семантической интероперабельности} ресурсов в контексте задачи требует более сложных решений, чем те, что обеспечивают техническую интероперабельность.
В [12] введено понятие полной семантически интероперабельной инфраструктуры, обеспечивающей необходимые моделирующие, методологические и архитектурные средства анализа, принятия решений, доказательных рассуждений и реализации, ориентированные на повторное использование ресурсов в семантически интероперабельных композициях. Эта инфраструктура считается дополнительной по отношению к архитектуре OMG [11]. Этот подход предполагает наличие полных спецификаций существующих ресурсов и прикладных областей, включая их структуру и функции, ограничения целостности (инварианты), спецификации деятельностей (потоков работ).

Заключение

В докладе дан краткий обзор информационной арxитектуры систем на основе объектной теxнологии и принципов интероперабельности компонентов, развиваемыx OMG.
Нетрудно видеть, что разрабатываемая арxитектура специально ориентирована на достижение целей - насущныx потребностей разработки прикладныx систем, сформулированныx во введении.

Список литературы

G.Booch, Object-Oriented Analysis and Design with Applications, Benjamin/Cummings Series in OO Software Eng., 1994.
Майкл Л. Броди, "Интероперабельные информационные системы в науке", Сборник материалов семинара, Москва, апрель 6-7, 1995.
Брюхов Д.О., Задорожный В.И., Калиниченко Л.А., Курошев М.Ю., Шумилов С.С. Интероперабельные информационные системы: архитектуры и технологии. СУБД, N 4, 1995
P.Coad and E.Yourdon, Object-Oriented Analysis (Second Edition), Prentice Hall, 1991.
Hutt A. (editor). Object Analysis and Design. Description of methods. Object management group. John Wiley and Sons. 1994. p. 202
I.Jacobson, M.Christerson, P.Jonsson, G.Overgaard, Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
Калиниченко Л.А. Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния. СУБД, N 1, 1996
Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД, N 2, 1996
Калиниченко Л.А., Когаловский М.Р. Интероперабельность брокеров в стандарте CORBA 2.0. СУБД, N 3, 1996
Калиниченко Л.А. СИНТЕЗ: язык определения, проектирования и программирования интероперабельных сред неоднородных информационных ресурсов (вторая редакция) Сентябрь 1993.
Kalinichenko L.A. A Complementary Architecture Integrating Industrial and Semantic Interoperation Environments. Institute for Problems of Informatics, Russian Academy of Sciences, Technical Report, 1993.
Kalinichenko L.A. Emerging semantic-based interoperable information system technology. Computers as our better partners. Proceedings of the International IISF/ACM Symposium, Tokyo, World Scientific, 1994.
The Object Database Standard: ODMG-93. Ed. by R.G.G. Cattell, Morgan Kaufmann Publ., 1994.
Object Management Group, "The Common Object Request Broker: Architecture and Specification", OMG Document Number 91.12.1, December 1991.
Object Management Group, "Object Services Architecture", Revision 8.0, 09 December 1994.
Object Management Group, "Common Facilities Architecture", Revision 2.0, September 1994.
Object Management Group, "Common Facilities Architecture", Revision 3.0, November 1994.
Object Management Group, "Common Facilities Roadmap", Revision 3.1, January 1995.
OMG, "Common Object Services Specification Volume1 (COSS1), March 1994.
Object Management Group, " Object Management Architecture Guide", OMG Document Number 92.11.1, September 1, 1992.
J.Rumbaugh et al., Object-Oriented Modeling and Design, Prentice Hall, 1991.

[Назад] [Содержание] [Вперед]