Что означает интероперабельность в открытых системах
Интероперабельность
Интероперабельность (англ. interoperability — способность к взаимодействию) — это способность продукта или системы, интерфейсы которых полностью открыты, взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации. [1]
Содержание
Способность к взаимодействию программного обеспечения
Интероперабельность программного обеспечения (функциональность программного обеспечения) — способность программного продукта выполнять набор функций, определённых в его внешнем описании и удовлетворяющих заданным или подразумеваемым потребностям пользователей. [2]
Средства поддержки
Средством поддержки способности к взаимодействию программных компонентов являются:
Примечания
Ссылки
Полезное
Смотреть что такое «Интероперабельность» в других словарях:
интероперабельность — функциональная совместимость совместное функционирование сетей Возможность совместного использования данных программами на различных компьютерах, разработанных различными фирмами. Для взаимодействия необходимы сети «процесс процесс»,… … Справочник технического переводчика
Mail.Ru Агент — Главное окно программы Mail.Ru Агент Тип Система мгновенного обмена сообщениями Разработч … Википедия
Классификатор информационных систем по синергетическим признакам сложности — Классификация информационных систем по синергетическим признакам сложности выстраивается по мере роста сложности информационных систем (ИС) по основным описанным выше синергетическим признакам, то есть признакам увеличения склонности к нехватке… … Википедия
Windows Azure — Разработчик Microsoft Семейство ОС Windows … Википедия
Функциональность программного обеспечения — способность программного продукта выполнять набор функций: определенных в его внешнем описании; и удовлетворяющих заданным или подразумеваемым потребностям пользователей. Синонимы: Интероперабельность программного обеспечения См. также: Качество… … Финансовый словарь
Текстовый файл — Запрос «TXT» перенаправляется сюда; см. также другие значения. Пиктограммное описание текстового файла с CSV данными Текстовый файл компьютер … Википедия
CORBA — (обычно произносится [корба], иногда жарг. [кобра]; англ. Common Object Request Broker Architecture общая архитектура брокера объектных запросов) технологический стандарт написания распределённых приложений, продвигаемый… … Википедия
GIOP — (General Inter ORB Protocol) абстрактный протокол в распределённых объектных системах, обеспечивающий интероперабельность брокеров. Стандарты, связанные с данным протоколом, выпускает Object Management Group (OMG). IIOP (Internet Inter Orb… … Википедия
ICCCM — Справочное руководство соглашений по межклиентским взаимодействиям (Спецификация взаимодействия клиентов, англ. Inter Client Communication Conventions Manual, ICCCM) стандарт X Window System, обеспечивающий интероперабельность X клиентов в… … Википедия
Что означает интероперабельность в открытых системах
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИХ ИНТЕГРАЦИЯ
Интероперабельность. Основные положения
Information technologies. Industrial automation systems and integration. Interoperability. Basic principles
Дата введения 2013-09-01
Предисловие
1 РАЗРАБОТАН Федеральным государственным бюджетным учреждением науки Институтом радиотехники и электроники им. В.А.Котельникова РАН (ИРЭ им.В.А.Котельникова РАН)
2 ВНЕСЕН Техническими комитетами по стандартизации ТК 459 «Информационная поддержка жизненного цикла изделий» и ТК 22 «Информационные технологии»
5 ПЕРЕИЗДАНИЕ. Октябрь, 2018 г.
Введение
На этой основе в настоящем стандарте описывается единый подход к обеспечению интероперабельности для систем самого широкого класса.
Интенсивное применение ИКТ в различных организациях (на предприятиях, в исследовательских, образовательных, лечебных учреждениях и др.) привело к обобщенному понятию «электронное предприятие» (e-enterprise). Соответственно возникло понятие «интероперабельность предприятия» (enterprise interoperability). Следует различать «внутреннюю интероперабельность» предприятия, касающуюся взаимодействия информационных систем внутри организации, и «внешнюю», обеспечивающую интероперабельность с организациями-партнерами. Хотя настоящий стандарт предназначен в первую очередь для систем промышленной автоматизации, он имеет гораздо более широкое назначение. На его основе могут создаваться интероперабельные системы самого широкого класса по масштабу и областям применения с учетом их особенностей.
1 Область применения
1.1 Настоящий стандарт определяет:
— основные понятия, связанные с понятием «интероперабельность»;
— подходы к достижению интероперабельности и имеющиеся барьеры;
— единый подход к обеспечению интероперабельности информационных систем широкого класса;
— основные этапы по достижению интероперабельности.
1.2 Настоящий стандарт предназначен для заказчиков, поставщиков, разработчиков, потребителей, а также персонала, сопровождающего информационные системы и осуществляющего программное обеспечение и услуги.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты и документы:
Р 50.1.022-2000 Рекомендации по стандартизации. Информационная технология. Государственный профиль взаимосвязи открытых систем России. Версия 3
Р 50.1.041-2002 Рекомендации по стандартизации. Информационные технологии. Руководство по проектированию профилей среды открытой системы (СОС) организации-пользователя
ГОСТ Р ИСО/МЭК 7498-1-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель
3 Термины, определения и сокращения
3.1 В настоящем стандарте применены термины по ГОСТ Р 1.1-2005, ГОСТ Р 1.12-2004, а также следующие термины с соответствующими определениями:
3.1.1 архитектура (arhitecture): Фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и с окружающей средой, и руководящие правила проектирования и развития системы. Термин «архитектура» определяется в стандартах системной и программной инженерии применительно к системам.
3.1.2 аттестационное тестирование интероперабельности (interoperability testing): Оценка соответствия реализации стандартам, указанным в профиле интероперабельности.
3.1.3 барьер интероперабельности (interoperability barrier): Несовместимость сущностей, которая препятствует обмену информацией с другими сущностями, использованию сервисов или общему пониманию обмененных элементов.
3.1.4 внешняя интероперабельность предприятия (external enterprise interoperability): Интероперабельность, которая определяет взаимодействие предприятия с другими предприятиями и конкурентоспособность предприятия на рынке.
3.1.5 внутренняя интероперабельность предприятия (internal enterprise interoperability): Интероперабельность внутренней инфраструктуры (корпоративной системы) предприятия.
3.1.6 глоссарий интероперабельности (glossary): Термины и определения, используемые в области интероперабельности с толкованием, иногда переводом на другой язык, комментариями и примерами.
3.1.7 интегрированная система (integrated system): Система, в которой все входящие в нее подсистемы работают по единому алгоритму, т.е. имеет единую точку управления.
3.1.8 интероперабельность (interoperability): Способность двух или более информационных систем или компонентов к обмену информацией и к использованию информации, полученной в результате обмена.
3.1.10 интероперабельность предприятия (enterprise interoperability): Способность предприятий или находящихся в них сущностей (объектов) осуществлять эффективную связь и взаимодействие.
3.1.12 масштабируемость (scalability): Способность обеспечивать функциональные возможности вверх и вниз по упорядоченному ряду прикладных платформ, отличающихся по быстродействию и ресурсам.
3.1.13 организационная интероперабельность (organizational interoperability): Способность участвующих систем достигать общих целей на уровне бизнес-процессов.
3.1.14 открытая система (open system): Система, реализующая достаточно открытые спецификации или стандарты для интерфейсов, служб и форматов, облегчающая прикладному программному средству, созданному должным образом:
— перенос его с минимальными изменениями в широком диапазоне систем, использующих продукты от разных производителей (поставщиков);
— взаимодействие с другими приложениями, расположенными на локальных или удаленных системах;
— взаимодействие с людьми в стиле, облегчающем переносимость пользователя.
3.1.15 переносимость (portability): Степень легкости, с которой прикладные программные средства и данные могут быть перенесены с одной прикладной платформы на другую.
3.1.16 план (стратегия) развития стандартов (roadmap): Документ, предусматривающий последовательность разработки необходимых стандартов для обеспечения интероперабельности.
3.1.17 подход к достижению интероперабельности (interoperability approach): Способ, с помощью которого решаются проблемы и преодолеваются барьеры интероперабельности.
3.1.18 профиль интероперабельности (interoperability profile): Согласованный набор стандартов, структурированный в терминах модели интероперабельности.
3.1.19 реализация (solution): Программно-аппаратная реализация конкретной интероперабельной системы в соответствии с профилем интероперабельности.
3.1.20 семантическая интероперабельность (semantic interoperability): Способность любых взаимодействующих в процессе коммуникации информационных систем одинаковым образом понимать смысл информации, которой они обмениваются.
3.1.21 техническая интероперабельность (technical interoperability): Способность к обмену данными между участвующими в обмене системами.
3.1.22 уровень интероперабельности (interoperability concern): Уровень, на котором осуществляется взаимодействие участников.
3.1.23 электронное предприятие (e-enterprise): Предприятие, организация либо учреждение, в котором большинство функций выполняется на базе использования информационно-коммуникационных технологий.
3.1.24 эталонная модель интероперабельности (interoperability reference model): Развитие известной эталонной семиуровневой модели взаимосвязи открытых систем.
3.2 В настоящем стандарте применены следующие сокращения:
4 Общие положения
Для обеспечения соответствия настоящему стандарту любое конкретное решение о достижении интероперабельности должно быть получено разработчиком ИС на основе единого подхода, содержащего ряд последовательных этапов. К этим этапам относятся: разработка концепции, построение архитектуры, построение проблемно-ориентированной модели интероперабельности, построение в терминах этой модели профиля интероперабельности, программно-аппаратная реализация ИС в соответствии со стандартами, входящими в профиль и аттестационное тестирование [2], [3]. Необходима также разработка документа, содержащего план (стратегию) разработки стандартов, а также глоссария по проблеме интероперабельности.
В основе единого подхода должна лежать эталонная модель интероперабельности.
5 Эталонная модель интероперабельности
Эталонная модель интероперабельности представляет собой развитие семиуровневой базовой эталонной модели ВОС согласно ГОСТ Р ИСО/МЭК 7498-1-99 (рисунок 1), [3], [4]*.
Для систем конкретных классов на базе эталонной модели интероперабельности должны создаваться проблемно-ориентированные модели интероперабельности, которые могут иметь большее число уровней.
5.1 Технический уровень
Технический уровень описывает синтаксис или форматы передаваемой информации, заостряя внимание на том, как представлена информация в коммуникационной среде. Технический уровень включает такие ключевые аспекты, как открытые интерфейсы, службы связи, интеграция данных и промежуточный слой программного обеспечения (Middleware), представление и обмен данными, службы доступности и защиты информации. Техническая интероперабельность достигается главным образом за счет использования стандартных протоколов связи типа TCP/IP.
Интероперабельность ПО: кто и зачем борется с ней?
Человеку для полноценного существования необходимо общение. Компьютерным программам для полноценной работы необходим обмен данными. Проблемы с социализацией чреваты психологическими осложнениями для человека. Проблемы с обменом данных чреваты потерей функциональности для программы.
Интероперабельность – ключ к нормальной работе компьютерных программ
Социализация – ключ к гармоничному существованию человеческой личности. Интероперабельность – ключ к нормальной работе компьютерных программ. В идеальном мире информационных технологий проблем с интероперабельностью нет. Программы беспрепятственно обмениваются данными, следуя общепринятым конвенциям (форматы файлов, протоколы, структуры данных и т.д.).
ЕГАИС
Впервые запущенная в 2005 году, система контроля за производством и реализацией алкоголя ЕГАИС надолго останется хрестоматийным примером решением, в котором нарушено максимальное количество правил интероперабельности. Используемые в первых версиях ЕГАИС интерфейсы обмена данных с большой вероятностью даже не были специфицированы. В связи с этим, создание аналогичного ПО для реализации функций ЕГАИС было в принципе невозможно. (Но даже если бы такое ПО было разработано, пользоваться им было бы невозможно, поскольку оно не прошло бы обязательной сертификации.) Первые версии ЕГАИС не предусматривали возможности взаимодействия с другим ПО, вынуждая всех пользователей вести двойной учет: отдельно в стандартной учетной системе и отдельно в ЕГАИС. Наконец, безальтернативное использование ЕГАИС было закреплено на законодательном уровне – вмешательство государства привело к катастрофе, которая в принципе не могла возникнуть в условиях рынка.
В реальном мире проблемы с интероперабельностью встречаются повсеместно по двум причинам: плохая работа программистов и нежелание поставщиков ПО обеспечить возможность полноценного обмена данными со своими программами.
Низкая культура разработки, которая приводит к появлению неинтероперабельного ПО, будет оставаться проблемой, поскольку в мире существуют некомпетентные разработчики. Но говорить о ней отдельно нет надобности. Достаточно ограничить свой выбор надежными поставщиками, которые не позволяют себе использовать труд некомпетентных программистов, и эта проблема отпадет сама собой.
Проблема становится гораздо сложнее, когда в основе отсутствия интероперабельности лежат коммерческие интересы. В этом случае поставщик прекрасно осведомлен о том, как сделать свое программное обеспечение интероперабельным, но сознательно этого не делает. Хуже того, поставщик сознательно создает препятствия для совместимости.
Когда несовместимость выгодна
Идеальный конкурентный рынок порождает только интероперабельные программы. Чем c большим числом систем способна взаимодействовать некоторая программа, тем прочнее ее конкурентные позиции. Напротив, несовместимость часто является следствием неконкурентного развития рынка. Не чувствуя реальной угрозы со стороны конкурентов, доминирующий поставщик начинает увеличивать собственные прибыли, мешая конкурентам создавать совместимые продукты.
Почему техническое превосходство не всегда приводит к победе на рынке?
Есть принципиальная разница между формирующимся и уже сформировавшимся рынком. В первом случае побеждает тот поставщик, который предлагает продукт с наиболее выгодными характеристиками. Во втором случае разработать перспективный продукт мало – нужно еще преодолеть действие так называемого «сетевого эффекта» (network effect). Суть его заключается в том, что стоимость продукта возрастает по мере роста числа пользователей. Например, никому не нужен сверхсовременный мобильный телефон, с которого нельзя дозвониться пользователям обычной мобильной связи – подавляющее большинство покупателей предпочтут менее совершенное в технологическом плане, но более практическое решение. Любой поставщик, стремящийся изменить статус-кво на рынке, вынужден разрабатывать стратегию борьбы с сетевым эффектом. В случае программного обеспечения эта борьба тем легче, чем выше уровень интероперабельности ПО.
Существует три основных способа обеспечения совместимости. Первый – спецификация или стандарт, в которых с достаточной подробностью описаны используемые в программе интерфейсы обмена данными. Второй – открытая эталонная реализация, которую разработчики совместимого ПО могут брать за образец при создании аналогичных программ. Наконец, наиболее затратный способ – обратный инжиниринг (reverse engineering), когда разработчики совместимого ПО вынуждены действовать наощупь, добиваясь совместимости методом проб и ошибок.
Общепринятым является первый способ, т.е. разработка ПО на основании спецификации. Эталонная реализация может быть полезным дополнением к опубликованной спецификации, хотя сама по себе редко бывает достаточна. Что касается реверс-инжиниринга, то, не говоря о чрезвычайно высокой затратности этого способа, он практически никогда не позволяет добиться полностью удовлетворительной совместимости, особенно при разработке сложных программ. Однако в отдельных случаях этот метод дает впечатляющие результаты: в частности, именно так была реализована совместимость с форматами данных Microsoft Office в офисном пакете OpenOffice.org.
Идеология одна – бизнес разный
Было бы наивно объяснять различия в поведении участников софтверного рынка разницей их идеологии. Основополагающие несоответствия кроются в их бизнес-моделях. При этом прослеживается любопытная особенность: компании поддерживают беспрепятственную интероперабельность в тех областях, которые не связаны непосредственно с их основным источником прибыли, в то время как в области своих непосредственных коммерческих интересов они ведут себя гораздо более ревниво.
Например, Microsoft либерально относится к производителям аппаратного обеспечения под Windows и программного над Windows. В то же время, действия компании в области обеспечения совместимости Windows с другими ОС намного менее однозначны. Так, в 1993 году отсутствие со стороны Microsoft достаточной информации для обеспечения интероперабельности с ее операционными системами послужило поводом для инициирования антимонопольного разбирательства в Европе со стороны Novell. Десять лет спустя Еврокомиссия признала обоснованность таких претензий, обязав Microsoft опубликовать необходимые сведения.
Таким образом, каждый крупный поставщик рынка ИТ имеет свою область «предпочтительного доминирования», за пределами которой он искренне отстаивает принципы свободы рынка и интероперабельности. В общей картине несколько выделяются лишь Open Source-компании, которые «из принципа» отстаивают принцип интероперабельности даже в сфере своих непосредственных коммерческих интересов, однако сравнивать их с традиционными крупными ИТ-компаниями не имеет смысла. Open Source – это принципиально другой подход к бизнесу, и объемы прибыли поставщиков ПО с открытым кодом в принципе не могут приблизиться к объемам прибыли традиционных компаний.
Существует целый арсенал средств, позволяющих создать препятствия для конкурентов. Во-первых, поставщик может не публиковать сведения об используемых форматах данных и протоколах обмена, либо сознательно публиковать их лишь в частичном виде, не позволяя конкурентам добиться полной совместимости. Например, такова была политика Macromedia и далее Adobe в отношении формата Flash. Даже после открытия спецификаций в рамках проекта Open Screen Project в 2008 году часть спецификаций ключевых компонентов остается закрытой (отсутствует спецификация видео-кодека, используемого в Flash, права на который не принадлежат Adobe).
Во-вторых, поставщик может формально следовать одному из принятых в отрасли стандартов, однако при этом сознательно включать в свои программы дополнительные функции, не предусмотренные им. В этой ситуации конкурентам придется разрабатывать программы, которые неизбежно будут обладать ограниченной интероперабельностью. Такова пресловутая тактика embrace, extend and extinguish (воспринять, расширить и уничтожить). В 90-е годы прошлого века она применялась Microsoft при создании собственной реализации языка Java, лишь ограниченно совместимой с реализацией от Sun Microsystems.
Интероперабельные информационные системы: архитектуры и технологии.
Д.О. Брюхов, В.И. Задорожный, Л.А. Калиниченко, М.Ю. Курошев, С.С. Шумилов
1. Введение
Другие организации, которые работают в кооперации с OMG, например, с целью доведения результатов OMG до официальных стандартов в различных аспектах, включают: ANSI, ISO, CCITT, ANSA, X/Open Company. С OMG сотрудничает Object Database Management Group (ODMG), разрабатывающая промышленный стандарт объектных баз данных, согласованный с решениями OMG.
Развитие технологии за пятилетний период деятельности OMG столь значительно, что уместно говорить о создании новых общепринятых архитектур для распределенных вычислений вообще.
В серии публикаций по технологии интероперабельных информационных систем предполагается освещать существенно продвинутые в практику архитектурные и технологические решения, исходящие от OMG и ODMG, а также аспекты, представляющие интерес для читателей журнала «СУБД» и находящиеся в состоянии исследований и развития.
В настоящей статье мы предлагаем краткий обзор структуры и компонентов архитектуры интероперабельных информационных систем в соответствии с их текущим состоянием.
2. Актуальные потребности применений
В начале рассматриваются насущные потребности применений, определяющие существенную мотивацию для перехода к интероперабельным информационным системам и разработки соответствующей технологии.
Реализационная неоднородность источников проявляется в использовании разнообразных компьютерных платформ, средств управления базами данных, моделей данных и знаний, средств программирования, операционных систем и т.п.
Интеграция систем. Системы эволюционируют от простых, автономных подсистем к более сложным, интегрированным системам, основанным на интероперабельном взаимодействии компонентов.
Повторное использование неоднородных информационных ресурсов. Технология разработки информационных систем должна позволять крупномасштабно применять технологию повторного использования информационных ресурсов, переходя от технологии программирования, основанной на интенсивном индивидуальном труде по созданию вручную изделий, удовлетворяющих специфическим требованиям одного конкретного применения, к технологии, основанной на планируемых капиталовложениях в разработку повторно-используемых компонентов, которые могут быть «соединены» (т.е., образованы их интероперабельные сообщества) для производства серий стандартизованных продуктов в определенной прикладной области.
Продление жизненного цикла систем. В условиях исключительно быстрого технологического развития требуются специальные меры, обеспечивающие необходимую продолжительность жизненного цикла.
Существенно, что свойство интероперабельности информационных ресурсов является необходимой предпосылкой удовлетворения перечисленных требований.
3. Концепция информационной архитектуры систем
OMG на основе объектной технологии и идеи интероперабельности вводит концепцию промежуточного слоя последовательно, радикально и до конца. Технически интероперабельность компонентов (представляемых объектами) решена введением базовой объектной модели, унифицированного языка спецификации интерфейсов объектов, отделением реализации компонентов от спецификации их интерфейсов, введением общего механизма поддержки интероперабельности объектов (брокера объектных заявок, играющего роль «общей шины», поддерживающей взаимодействие объектов). Тем самым достигается однородность представления компонентов и их взаимодействия. Далее, для формирования информационной архитектуры вводится слой унифицированных (ортогональных) служб, которые используются как при конструировании прикладных систем, так и для формирования функционально законченных средств промежуточного слоя, предлагающих конкретные виды услуг. Существенно, что и службы, и средства представляются однородно своими объектными интерфейсами, что позволяет обеспечить их интероперабельность посредством брокера объектных заявок.
Одним из интересных следствий этого подхода, иллюстрирующим его радикальность, является реализация в информационной архитектуре функций СУБД совокупностью объектных служб.
Объектная модель OMG. Объектная модель OMG определяет общую объектную семантику для спецификации базовых характеристик объектов стандартным, независимым от реализации образом.
Объектные Службы (Object Services) представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку базовых функций объектов. Общие Средства (Common Facilities) образуют набор классов и объектов, поддерживающих полезные во многих прикладных системах функции. Прикладные объекты представляют прикладные системы конечных пользователей и обеспечивают функции, уникальные для данной прикладной системы.
Ниже основные компоненты OMA рассматриваются подробнее.
4. Брокер Объектных Заявок
Брокер Объектных Заявок обеспечивает механизмы, позволяющие объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь о положении в распределенной среде и способе реализации взаимодействующих с ними объектов. ORB отвечает за поиск реализации объекта, участвующего в заявке, подготовку объектной реализации к приему заявки и передачу данных, являющихся результатом заявки. Интерфейс клиента полностью независим от расположения вызываемого объекта, языка программирования, на котором он реализован, и любых других аспектов, не отраженных в интерфейсе вызываемого объекта.
Клиент может также непосредственно взаимодействовать с ORB. ORB ищет соответствующий код, пересылает параметры заявки и передает управление Реализации Объекта (Object Implementation). Реализация Объекта принимает заявку через сгенерированный компилятором IDL скелетон (skeleton) и при этом может обращаться к Объектному Адаптеру (Object Adapter) и ORB. Когда обработка заявки завершена, управление и выходные значения возвращаются клиенту.
Различные ORB могут иметь разную реализацию и поддерживать различные объектные механизмы. В структуре ORB выделяется ядро, обеспечивающее внутреннее представление объектов и передачу заявок, и набор надстраиваемых компонентов, интерфейсы которых маскируют различия в реализации ORB. Клиенты максимально мобильны и должны работать без изменения исходного кода в среде любого ORB, который поддерживает отображение IDL в соответствующий язык программирования.
Мобильны также и реализации объектов для разных ORB при условии, что последние поддерживают заданное языковое отображение и имеют требуемые Объектные Адаптеры.
Языковое отображение включает определение характерных для языка программирования типов данных и интерфейсов доступа к объектам при помощи ORB. Отображение определяет структуру интерфейса стаба клиента, интерфейса динамического вызова, скелетона объектной реализации, объектных адаптеров и прямые интерфейсы ORB.
Объектный Адаптер является основным средством доступа к услугам ORB со стороны объектной реализации. Эти услуги обычно включают: генерацию и интерпретацию объектных ссылок, вызов методов, активизацию/деактивизацию реализации и объекта, регистрацию реализаций. Предполагается наличие нескольких широко доступных объектных адаптеров с интерфейсами, соответствующими определенным видам объектов.
5. Проникновение идей OMG за пределы промежуточного слоя: система Spring
Идеи CORBA начинают проникать в архитектурные слои ниже промежуточного. Так, в проекте Spring [7], посвященном архитектуре операционной системы, рассчитанной на распределенные среды и на многопроцессорные платформы, основополагающими являются понятия строгих интерфейсов, открытости и расширяемости. Следуя этому, интерфейсы объектов Spring определены средствами IDL, не зависящими от языков программирования.
Такой подход позволяет достичь распределенности системы, соответствия типов, безопасности (при необходимости от самой слабой до самой сильной) и унифицируемости при вызове операций, независимо от того, размещаются ли объект и обратившийся к нему клиент в одном адресном пространстве, на одной машине, или удалены друг от друга.
Spring организована как микроядерная система. Она почти полностью реализована в виде набора менеджеров объектов (например, файловая система, поддерживающая объекты-файлы), выполняющихся в непривилегированном режиме и часто в различных адресных пространствах. Как следствие, добавить новую функцию к системе столь же легко, как и написать прикладную программу в Spring, причем каждая такая функция становится неотъемлемой частью распределенной системы. Все сервисы и объекты, доступные в одном узле, также доступны и в других узлах данной распределенной среды.
Реальным примером расширяемости системы может служить реализация эмуляции UNIX. Подсистема эмуляции будет целиком реализована на пользовательском уровне, не будет использовать «реальный» код UNIX и обеспечит совместимость на уровне исполняемого кода для большого набора программ Solaris. Подсистема использует сервисы, предоставляемые базовой системой Spring, и реализует только специфические для ОС UNIX средства, которые в Spring не имеют эквивалентов (например сигналы). Для того, чтобы реализовать эмуляцию Solaris, не требуется никакой модификации в самой системе Spring.
6. Развитие информационной архитектуры: Объектные Службы
Архитектура Объектных Служб обеспечивает базис для спецификации структуры и функций отдельных Объектных Служб. Предлагаемая архитектура будет уточняться по мере принятия OMG спецификаций объектных служб и должна быть согласована с общей архитектурой OMG.
Общая характеристика. Объектные Службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают базовые функции, необходимые для реализации и использования другими объектами. Операции, предоставляемые Объектными Службами, выступают в качестве базовых «строительных» блоков для Общих Средств и прикладных объектов.
Объектная служба может включать отдельный объект (например, объект службы времени), множество объектов с одним и тем же типом интерфейса (например, объекты очередей) или множество объектов с различными типами интерфейсов, наследуемыми из одного типа интерфейса службы (например, все объекты, обеспечивающие службу жизненного цикла).
Интерфейсы Объектных Служб являются модульными (отдельный объект может использовать некоторые, или все Объектные Службы), легко расширяются и настраиваются. Предоставляемые Объектными Службами операции доступны посредством интерфейсов, определенных на IDL или его расширении, совместимом с объектной моделью OMG. Наличие объектного интерфейса не требует объектно-ориентированной реализации службы. Объекты клиентов могут не использовать реализации базовых операций, предоставляемые Объектными Службами (например, объект может предоставлять свой собственный способ хранения данных; объект, моделирующий процесс, может не поддерживать транзакции).
В настоящее время OMG приняты или находятся в процессе формирования спецификации следующих служб:
Помимо рассмотренных выше, имеется также, ряд служб, которые впоследствии были связаны с другими компонентами OMA (Общими Средствами и Брокером). Так к Общим Средствам отнесены организация архивов (archive service), резервное копирование (backup service) и восстановление (restore service), операционный контроль (operational control service). К функциям ORB отнесены поддержка репозитория реализаций (implementation repository), инсталляция и активизация объектов и реализаций (installation and activation service), поддержание репозитория интерфейсов (interface repository), обеспечение механизма дублирования информации (replication service), запуск объектных служб (startup services service).
Рассмотренные выше службы далеко не исчерпывают всех возможных кандидатов на эту роль. В ходе дальнейшей работы OMG, вероятно, будут выделены и приняты дополнительные Объектные Службы.
7. Функции СУБД в информационной архитектуре
Следуя принципам модульности и ортогональности компонентов информационной архитектуры, OMG представляет функции управления базами данных рядом таких служб, как долговременное хранение объектов, управление конкурентным доступом к объектам, служба транзакций, службы объектных связей, объектных запросов, изменений объектов и т.п. Эти и другие службы, взятые вместе, реализуют функции как объектных, так и реляционных СУБД.
8. Проблемы согласованной службы запросов для информационной архитектуры
К январю 1995 г. OMG были представлены следующие основные варианты спецификаций Службы Объектных Запросов:
Основные особенности представленных предложений заключаются в следующем.
Объединенное предложение. Служба Объектных Запросов реализует функции запросов над коллекциями объектов. Запросы могут формулироваться посредством объектных производных языка SQL или других объектных языков запросов. В данном контексте в понятие «запрос» включаются также функции манипулирования коллекциями объектов.
Служба Объектных Запросов должна предоставлять возможность объектам и пользователям выполнять запросы над произвольными коллекциями других объектов. Запросы являются декларативными утвержденими, содержащими предикаты над атрибутами и операциями объектов, а также позволяющими вызывать произвольные сервисы в среде OMG. Запросы могут быть адресованы любым объектам, временно или постоянно хранимым. Должно быть предусмотрено использование механизмов вторичной индексации.
В средах с базами данных (реляционными, объектно-ориентированными и другими) Служба Объектных Запросов должна иметь правильные отображения в собственные механизмы этих систем. Иерарахическая и федеративная структура, позволяющая интегрировать разнообразные вычислители запросов и автономные системы запросов, показана на Рис.4.
Предложение предполагает использовать один из двух языков запросов: SQL-9x (SQL-92 и будущий стандарт, основанный на разработке SQL3) и OQL-9x (очевидно, тот вариант OQL, в котором обеспечивается синтаксическая совместимость с SQL-9x).
Служба Объектных Запросов базируется на Объектной Модели OMG. Реляционная модель считается подмножеством объектной модели. Модель ODMG дополнительно вводит конструкции, которые отображаются в операции модели OMG. Определены коллекции и интерфейсы Службы Объектных Запросов.
Предложение Oracle. Служба Объектных Запросов основана на языке запросов SQL и на объектном расширении SQL. Абстрактные типы данных SQL3 вводят объектную модель данных, отличную от модели OMG. Семантика службы полностью определяется языком SQL. Все операторы языка SQL инкапсулированы посредством интерфейсов IDL. Определены отображения типов данных IDL, употребляемых в качестве параметров и результатов интерфейсных функций IDL, в типы данных SQL. В целом отображение объектной модели данных SQL3 в модель данных OMG проблематично. В этом заключается основная слабость этого предложения.
Возможна иерархия сервисов в федеративной архитектуре. Различные компоненты иерархии могут предоставляться различными держателями соответствующих средств.
Предложение TI. Предложение TI основано на IDL и объектной модели OMG, не требуя их расширения. Предложен язык запросов OQL[IDL] в синтаксисе SQL. Предполагается, что коллекции будут определены внешним образом по отношению к службе запросов: они требуются также другим службам.
Открытые проблемы. Не так давно OMG подавляющим большинством голосов приняла Объединенное Предложение. В дальнейшем OMG придется преодолеть ряд проблем, включая, собственно, выбор объектной модели (в попытке справиться с противоречием между объектными моделями OMG и SQL3). Например, какова семантика SQL запросов по отношению к коллекциям, отличным от множеств (что будет результатом соединения списка и множества?), семантика запросов, сохраняющих объекты и производящих новые объекты? Следует сказать также о поддержке классической схемы диспетчеризации методов (модель OMG) и мультиобъектной (SQL3), выборе федеративной архитектуры, включающий решение проблемы отображения моделей данных, выбор спецификации Службы Коллекций Объектов.
Не следует ожидать, что все проблемы будут легко решены: многие из них являются фундаментальными.
9. Развитие информационной архитектуры: Общие Средства
Рассматриваемая ниже архитектура Общих Средств также является предварительной и при уточнении должна согласовываться с общей архитектурой OMG.
Общие Средства подразделяются на две категории: «горизонтальные» и «вертикальные» наборы средств.
«Горизонтальный» набор средств определяет операции, используемые во многих системах и не зависящие от конкретных прикладных систем. «Вертикальный» набор средств представляет технологию поддержки конкретной прикладной системы (вертикального сегмента рынка, включающего здравоохранение, производство, управление финансовой деятельностью, САПР и т.д.). При этом возможна эволюция Общих Средств, связанная с миграцией вертикальных средств, которые оказываются общими для ряда прикладных систем, в набор горизонтальных средств. Следует отметить, что грань между Объектными Службами и Общими Средствами, также как и между Общими Средствами и прикладными объектами, не является жестко фиксированной. Она может изменяться вместе с развитием объектной технологии. Архитектурные требования определения Общих Средств аналогичны требованиям, которые должны выполняться при определении Объектных Служб.
Ниже кратко рассматривается набор средств, вошедших в предварительные спецификации архитектуры Общих Средств OMG [11, 12, 13].
Средства поддержки пользовательского интерфейса (User Interface Common Facilities). Средства поддержки пользовательского интерфейса включают средства, облегчающие прикладному программисту разработку интерфейсов прикладных систем. Сюда входят:
Средства управления информацией (Information Management Common Facilities). Информация может храниться как в структурированном виде в базах данных, так и в виде текстов, изображений и т.п. Средства управления информацией включают:
Средства управления системой (System Management Common Facilities). Средства управления системой включают:
Средства управления задачами (Task Management Common Facilities). В набор средств управления задачами входят:
Вертикальные общие средства (Vertical Common Facilities). Вертикальные общие средства предназначены для использования в качестве стандартных для обеспечения интероперабельности в специфических прикладных областях. Сюда входят:
10. Объектные методологии роектирования
К настоящему времени разработано большое число различных методов OAD, например: OOD [17], OMT [20], OOA&OOD&OOP [18,19], Objectory [21] и др.
Хотя перечисленные методы основаны на объектной модели, они зачастую используют различные понятия и терминологию.
Согласно Object Analysis and Design Special Interest Group [2] в составе OMG, разработка систем включает в себя этапы стратегического планирования, анализа, проектирования и реализации.
Стратегическое планирование. Целью этапа стратегического планирования является определение основных функций системы, методов взаимодействия системы с внешним миром (человеком, другими системами), стратегии разработки системы с учетом организационных, финансовых и технических ограничений.
Анализ. Целью этапа анализа является получение полного и детального описания проблемной области, не зависящего от среды реализации.
Проектирование. Целью этапа проектирования является уточнение модели системы, полученной на этапе анализа для адаптации к реальной среде реализации и определение возможности использования существующих систем.
Реализация. Целью этапа является конкретная реализация системы.
При разработке сложных систем часто бывает недостаточно ее одностороннего рассмотрения. Методы OAD предоставляют разработчику различные модели для описания системы: объектную, динамическую и функциональную.
Объектная (структурная) модель используется для описания структуры системы: классов (типов объектов), их атрибутов и операций и связей между типами (классами). Примеры объектных моделей: диаграмма отношений объектов, иерархия типов, диаграммы часть-целое.
Динамическая модель используется для описания поведения объектов внутри системы. Примеры динамических моделей: список событий, диаграммы переходов состояний, диаграммы запросов объектов.
Функциональная модель используется для описания процессов предметной области. Примеры функциональных моделей: диаграммы функциональной декомпозиции, диаграммы потока данных.
В настоящее время OMG изучает необходимое развитие объектных моделей OMG для применения в целях объектного анализа и проектирования систем и для моделирования разнообразных прикладных объектов при использовании стандартов OMG.
11. Семантическая интероперабельность
До сих пор усилия промышленности, выражающиеся в деятельности OMG, были направлены на поддержку системного, технического уровня интероперабельности, основанного на полной инкапсуляции информационных ресурсов (язык IDL является отражением этого подхода). Вместе с тем при программировании прикладных задач на основе имеющихся ресурсов требуется решение вопроса о релевантности имеющихся ресурсов задаче, о соответствии их прикладного контекста контексту задачи и о том, что интероперабельная композиция ресурсов будет непротиворечивой в прикладном контексте задачи. Такая композиция ресурсов образует мегапрограмму, выполнение которой при заданных параметрах должно давать решение прикладной задачи. Очевидно, что достижение подобной семантической интероперабельности ресурсов в контексте задачи требует более сложных решений, чем те, что обеспечивают техническую интероперабельность.
В [3] введено понятие полной семантически интероперабельной инфраструктуры, обеспечивающей необходимые моделирующие, методологические и архитектурные средства анализа, принятия решений, доказательных рассуждений и реализации, ориентированные на повторное использование ресурсов в семантически интероперабельных композициях. Эта инфраструктура считается дополнительной по отношению к архитектуре OMG [4]. Этот подход предполагает наличие полных спецификаций существующих ресурсов и прикладных областей, включая их структуру и функции, ограничения целостности (инварианты), спецификации деятельностей (потоков работ). Спецификации ресурсов и прикладных областей должны включать также их контекстные описания. Контекстная спецификация предоставляет информацию, необходимую для правильной интерпретации экстенсиональных и интенсиональных предложений, составляющих спецификацию ресурса (предметной области). Базовыми компонентами контекстной спецификации являются онтологические спецификации, представляющие собой описания понятий контекста как контекстно-зависимых знаний, включающих необходимые правила.
Предполагается, что существующие информационные ресурсы являются технически интероперабельными. Их полные спецификации образуются в результате трансформации, унификации, обобщенного представления первоначальных спецификаций ресурсов. Информационные ресурсы содержат факты, правила и демонстрируют поведение, которые имеют определенную интерпретацию в прикладном контексте ресурса. Каждый ресурс сопровождается онтологическими спецификациями, позволяющими склеивать ресурсы в непротиворечивую композицию в контексте прикладной области. Такая композиция должна быть конкретизацией прикладной задачи. Для спецификации и проектирования семантически интероперабельных информационных систем используются специальные языки и методологии проектирования [3,5].
12. Заключение
В статье дан краткий обзор информационной архитектуры систем на основе объектной технологии и принципов интероперабельности компонентов, развиваемых OMG.
Литература
Приложение. Словарь понятий
Информационная архитектура (Information Architecture). Архитектурный слой, расположенный над сетевой архитектурой и определяющий способность совместного использования, интероперабельности готовых информационных компонентов для решения задач. Такими компонентами являются произвольные информационные ресурсы.
Информационные ресурсы (Information Resources). Автономные информационные или вычислительные службы, например: программные компоненты, базы данных, базы знаний, файлы данных (включая мультимедийную информацию), компоненты существующих информационных систем и др., рассматриваемые при конструировании систем независимо от аппаратурно-программных платформ их реализации и размещения в пространстве.
Унаследованные системы (Legacy Systems). Системы, переставшие удовлетворять изменившимся потребностям применений, которые однако продолжают использоваться ввиду больших затруднений, возникающих при попытке их замены. Унаследованные системы используют устаревшие технологии, архитектуры, платформы, а также собственно программное и информационное обеспечение. При проектировании таких систем, как правило, не предусматриваются должные меры для их пошаговой миграции в новые системы, соответствующие новым требованиям деловых процессов и технологии.
Реинженерия (Re-engineering). Реконструкция системы, непрерывный процесс формирования, уточнения требований и конструирования систем.
Обратная инженерия (Reverse Engineering). Извлечение спецификации существующей программной системы из ее реализации (как правило, устаревшей) обычно для отображения ее в реализацию, соответствующую современному технологическому уровню.
Онтологическая спецификация (Ontological Specification). Набор определений понятий прикладного контекста (индивидумов, функций, предикатов, классов, и др.) в форме, удобной для восприятия человеком и машиной. Содержит также набор правил (аксиом), связанных со словарем или с определенными понятиями. Онтологическая спецификация является концептуальной конструкцией, в рамках которой можно рассуждать о прикладной области. Играет роль связующего интерфейса между совместно используемыми ресурсами, создавая основу для их интероперабельности.
Семантическая интероперабельность (Semantic Interoperability). Интероперабельность компонентов, устанавливаемая на основе их онтологических спецификаций в контексте прикладной задачи для ее решения.
Общие средства (Common Facilities). Родовые средства, полезные в предопределенных прикладных областях, доступные посредством унифицированных спецификаций интерфейсов и просто специализируемые в конкретных применениях.
Интероперабельность (Interoperability). Технически интероперабельность означает возможность компонентов (объектов) обмениваться заявками, так что принимающий заявку объект может ее интерпретировать и возвращать результат, который может интерпретировать объект, пославший заявку. Посылка заявки (возврат результата) осуществляется посредством ORB. Таким образом, объекты интероперабельны, если методы одного объекта запрашивают сервисы другого. Интероперабельность обеспечивает возможность создания систем из произвольных неоднородных, распределенных компонентов на основе однородно специфицированных интерфейсов. В системе компоненты взаимодействуют между собой в интересах прикладной задачи посредством обмена заявками.
Объект (Object). Комбинация состояния и множества методов, которая воплощает абстракцию, характеризующуюся определенным поведением для допустимых заявок. Объект имеет тип (типы) и является экземпляром класса (классов). Объект моделирует некоторую сущность реального мира, инкапсулирует реализацию (состояние и операции, внутренне реализуемые как данные и методы) и отвечает на заявки, требующие обслуживания. Методы могут быть собственностью одного или нескольких объектов. Заявки могут направляться одному или нескольким объектам. Данные состояния могут быть собственностью одного или нескольких объектов. Данные состояния и методы могут располагаться в одном или разных местах.
Интерфейс объекта (Object Interface). Описание множества возможных применений объекта. Более точно, интерфейс описывает множество потенциальных заявок, в которых объект может осмысленно участвовать как параметр. Интерфейс объекта является объединением интерфейсов типов данного объекта.
Объектные Службы (Object Services). Объектные Службы предоставляют набор стандартных услуг (при помощи интерфейсов и объектов), которые обеспечивают базовые функции, необходимые для реализации и использования другими объектами. Составляют основу информационной архитектуры систем. Включают услуги для именования объектов, управления их жизненным циклом, долговременного хранения объектов, управления конкурентным доступом к объектам, реализации запросов к объектным пространствам, и др.
Брокер объектных заявок (Object Request Broker). Обеспечивает средства, с помощью которых объекты выдают и принимают заявки и ответы.
Долговременно-хранимый объект (Persistent Object). Объект, который может жить дольше, чем процесс, который его породил. Долговременные объекты существуют до момента их явного удаления.
Институт проблем информатики Российской академии наук
1) Эта работа выполнена в рамках проекта Российского Фонда Фундаментальных Исследований, грант 94-07-20453
2) Термин «заявка», поставленный в соответствие термину request, представляется более уместным, чем, например, термин «запрос» ввиду того, что последний соответствует термину «query» который также используется в информационной архитектуре.
3) Термин «гнездовые», поставленный в соответствие термину nested, представляется более точным, чем используемый термин «вложенные».