УДК 004.06

Рассмотрена проблема интероперабельности и предложен общий подход к ее достижению, основанный на лучших практиках крупных исследовательских проектов. Разработана концепция обеспечения интероперабельности в области электронной коммерции, которая включает в себя общий подход к обеспечению интероперабельности, построение архитектуры и модели интероперабельности, а также определение набора стандартов, необходимых для дальнейшей реализации поставленной задачи на основе технологии XML.
Ключевые слова - интероперабельность, электронная коммерция, XML .
Введение
Одной из наиболее активно развивающихся областей деятельности человека может по праву считаться сфера электронной коммерции (e-commerce), т. е. сфера, которая включает в себя все финансовые и торговые транзакции, осуществляемые при помощи компьютерных сетей, и бизнес-процессы, связанные с проведением таких транзакций. По оценке исследовательской лаборатории Bay.Ru, объем российского рынка электронной коммерции в 2011 г. составил около 1213 млрд дол. Эксперты считают, что в 2012 г. его объем превысит отметку 15 млрд дол., а количество пользователей, которые так или иначе занимаются электронной коммерцией, достигнет порядка 2,3 млн чел., и эта цифра будет неуклонно расти.
Но существует множество барьеров, которые мешают развитию данной отрасли. Одним из таких барьеров считается проблема обеспечения интероперабельности. «Интероперабельность - это способность двух или более систем или компонентов к обмену информацией и к использованию информации, полученной в результате обмена» (ISO/IEC 24765).
В данной статье предложена концепция по обеспечению интероперабельности в области электронной коммерции, которая основана на лучших практиках разработок зарубежных компаний, таких как Microsoft, Oracle, Sun Microsystems и др., в области электронной коммерции. В основу концепции нами заложен единый подход к обеспечению интероперабельности, который будет описан далее.
Общий подход к обеспечению интероперабельности
В настоящее время существует множество подходов к обеспечению интероперабельности для разных областей деятельности человека. К примеру, Национальным институтом по стандартам и технологиям (NIST) был разработан документ , который посвящен разработке структуры, включающей протоколы и стандарты на модели управления информацией для достижения функциональной совместимости устройств и систем Smart Grid.
В области электронного здравоохранения (e-health) существует научно-исследовательский австралийский проект NEHTA , который разработал архитектуру обеспечения интероперабельности электронного здоровья. Данная архитектура устанавливает общие понятия из области электронного здоровья, принципы и стандарты, чтобы развивать и реализовывать интероперабельность на техническом, семантическом и организационном уровнях.
Обобщив собственный опыт и опыт других разработчиков, мы разработали единый подход к обеспечению интероперабельности, который можно представить в виде ряда последовательных этапов.
Одной из особенностей данной цепочки является то, что каждый последующий этап базируется на предыдущем. Практически во всех источниках, будь то NIST или NEHTA, опущены либо совмещены некоторые элементы данной цепочки. Это говорит о том, что для разных проектов существуют различные приоритеты и задачи, которые должны решаться максимально быстро и эффективно, и для которых, возможно, нет острой необходимости в описании некоторых из этапов приведенной цепочки. Сжатые сроки разработки и ограниченность ресурсов также могут повлиять на полноту описания той или иной области исследования.
Зачастую еще одним фактором, влияющим на набор этапов цепочки, является разная трактовка понятий, в особенности из-за различных областей знаний, к которым данные определения применены. Поэтому предлагаем обобщить данные определения и использовать их в широком смысле.
Основные положения (Framework) содержат концепцию по достижению интероперабельности. Термин Framework имеет много значений, начиная от буквального (каркас, рамка) и заканчивая широким (концептуальный уровень, контекст, основные принципы) и узким (структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта).
Архитектура (Arhitecture) - определение элементов системы и связей между ними и с окружающей средой.
Эталонная модель (Reference model) - многоуровневая модель интероперабельности.
Профиль (Profile) - согласованный набор стандартов, расположенных в терминах эталонной модели.
Реализация (Solution) - программно-аппаратная реализация конкретной интероперабельной системы в соответствии с профилем.
Основные положения обеспечения интероперабельности в области электронной коммерции
Обмен, покупка и продажа товаров в различных масштабах, а также последующая транспор-
тировка от склада до покупателя являются коммерцией в широком смысле этого слова. Но когда все вышеперечисленные процессы осуществляются в электронном виде, то речь идет уже об электронной коммерции. Если быть более точным, то электронная коммерция - разновидность бизнес-активности1, в которой взаимодействия субъектов бизнеса купли-продажи товаров и услуг (как материальных, так и информационных) осуществляются с помощью глобальной компьютерной сети Интернет или какой-нибудь другой информационной сети . С точки зрения коммуникационных особенностей, электронная коммерция базируется на передаче информации, продуктов и услуг с помощью компьютерных сетей. С точки зрения бизнеса, для сферы электронной коммерции характерна автоматизация биз-нес-транзаций и технологических процессов. Если рассматривать электронную коммерцию с позиции сферы обслуживания, то это - инструмент, который позволяет сократить сервисные издержки на взаимодействие между компаниями и потребителями, что способствует улучшению качества продукции и увеличению скорости предоставления услуг. Электронная коммерция с точки зрения онлайн обеспечивает возможность покупки и продажи продуктов и услуг с помощью сети Интернет.
Электронная коммерция тесно связана с еще одним понятием - «электронный бизнес». Электронный бизнес (e-business) - деловая активность2, которая использует возможности глобальных информационных сетей для преобразования внутренних и внешних связей компании в целях создания прибыли . Электронная коммерция является важнейшей составляющей электронного бизнеса, которая охватывает не только операции купли-продажи, а и сопровождение процессов создания спроса на продукцию и услуги, автоматизацию административных функций, связанных с онлайновыми продажами и обработкой заказов, а также с совершенствованием обмена информацией между партнерами. Другими словами, понятие «электронный бизнес» шире понятия «электронная коммерция», касающегося только коммерческой деятельности. Понятие «электронный бизнес» охватывает всю систему взаимоотношений с партнерами и заказчиками.
Рассматривая область электронной коммерции, можно отметить, что, так же, как и сфера
1 Совокупности видов экономической деятельности: покупка, продажа, аренда, инвестирование и др. (в соответствии с национальным стандартом ШГС).
2 Экономическая деятельность, конкретизированная в виде производства того или иного товара или оказания конкретной формы услуг (в соответствии с национальным стандартом ШГС).
электронного бизнеса, электронная коммерция состоит из более мелких областей, среди которых:
- электронное движение капитала (Electronic Funds Transfer, EFS);
- электронные страховые услуги (e-insurance);
- электронные деньги (e-cash);
- электронная торговля (e-trade);
- электронный маркетинг (e-marketing);
- электронный банкинг (e-banking);
- электронный обмен информацией (Electrons Data Interchange - EDI).
Для области электронной коммерции характерны следующие типы систем: B2C (бизнес - потребителю), B2B (предоставление товаров и услуг предприятиям), B2B2C (предоставление товаров и услуг предприятиям для последующей реализации потребителю), G2B или G2C (правительство - бизнес или правительство - потребитель).
Все вышеперечисленные классы систем имеют разный набор сущностей, которые участвуют в информационном процессе, но, не смотря на это, любая система электронной коммерции содержит типовые компоненты.
Рассмотрим более подробно компоненты электронной коммерции.
Сетевая инфраструктура - информационная магистраль или путь, по которому перемещаются информационные потоки между отправителем и получателем. В качестве информационной магистрали могут выступать коаксиальные кабели, беспроводные и радиосигналы, сигналы спутниковой связи. Все эти способы коммуникации взаимосвязаны маршрутизаторами, коммутаторами, мостами, шлюзами и т. д.
Информационно-распределенная инфраструктура - компонент, который включает в себя промежуточное программное обеспечение, интерпретирующее информационные потоки. В данном случае информационные потоки представлены в виде нулей и единиц.
Общая бизнес-инфраструктура
Государственные политики и правовые вопросы конфиденциальности Безопасность, аутентификация, электронные платежи Технические стандарты для защиты документов и сетевых протоколов
Мультимедия-контент и инфраструктура публичной сети
HTML, JavaScript, WWW Информационно-распределенная инфраструктура
EDI, E-mail, HTTP
Сетевая инфраструктура
Телекоммуникации, беспроводные сети, Интернет
Мультимедиа-контент и инфраструктура публичной сети - компонент, который позволяет преобразовывать информационные потоки в понятный для восприятия контент и мультимедиа содержимое. Наиболее распространенной архитектурой является WWW (World Wide Web) - распределенная архитектура, предоставляющая доступ к связанным между собой документам, расположенным на различных компьютерах, подключенных к Интернету. Контент может формироваться на основе языка гипертекстовой разметки HTML и других технологий (таких как Java Script, XML и пр.).
Общая бизнес-инфраструктура включает в себя различные методы, обеспечивающие онлайн-покупки. Для обеспечения безопасности онлайн-покупки созданы различные методы шифрования информации, кроме этого, необходима обязательная аутентификация покупателя на платежном шлюзе, если оплата производится с помощью безналичных средств.
Архитектура интероперабельности для электронной коммерции
Одним из главных в разработке систем любого класса является этап описания элементов системы и связей между ними и с окружающей средой, т. е. архитектуры системы. Разработка архитектуры системы позволяет сформировать подход к дальнейшей разработке приложения в соответствии с бизнес- и техническими требованиями, такими как стоимость, производительность, безопасность. Основываясь на разработанной архитектуре, разработчики могут спроектировать удобное, масштабируемое, расширяемое и надежное программное решение.
Для того чтобы снизить бизнес-риски, связанные с созданием и развертыванием программного решения, в архитектуре должны быть учтены следующие факторы :
- категории пользователей программного решения и то, как они будут его использовать;
- ИТ-среда и класс систем, куда может быть интегрировано программное решение;
- каким образом программное решение будет развернуто в производстве и какие аппаратные ресурсы будут необходимы для этого;
- какие требования к качеству (безопасность, производительность и управляемость) будут предписаны к системе;
- бизнес- и технологические тенденции, которые могли бы повлиять на программное решение в долгосрочной перспективе;
- специфичные особенности системы, характерные для той ИТ-среды, в которой будет существовать данное программное решение.
Исходя из данных особенностей мы предлагаем архитектуру, отражающую особенности сферы электронной коммерции.
Данная архитектура построена с позиции трех ключевых сущностей, характерных для области электронной коммерции: покупатель, продавец и посредник. Сама же система состоит из двух частей: открытой (front-end) и закрытой (back-end). Такое разделение необходимо для разграничения прав доступа между сущностями. К примеру, продавец, являющийся владельцем (или администратором) некоторой системы, может производить ее администрирование по защищенным каналам связи (https, ssh и др.). Кроме этого, администратор может настроить связь системы с другими сервисами, такими как яндекс-маркет и др. Данная связь происходит с помощью обмена данными между системами, опять же по зашифрованным каналам связи.
Ключевую роль в данном процессе играет уровень интероперабельности системы. Поэтому авторы поставили себе задачу по разработке конечного программного решения (или модуля), которое бы обеспечило высокий уровень интероперабельности. Кодовое название модуля - «E-com-merce Interoperability Module» (или EclM), в котором будет использована технология XML и который позволит решить проблемы интероперабельности именно для области электронной коммерции.
Модель интероперабельности для электронной коммерции
Построение эталонной модели служит одним из ключевых этапов общего цикла обеспечения интероперабельности . На каждом уровне используются свои стандарты.
Как говорилось ранее, авторы видят свою задачу в выработке единого подхода к обеспечению интероперабельности в области электронной коммерции и программной реализации данного подхода на основе языка XML. Для этого нами была разработана своя модель интероперабельности, характерная именно для области электронной коммерции и учитывающая все архитектурные особенности области электронной коммерции.
В отличие от вышеописанных моделей ведения электронной коммерции (B2B, B2C и др.) и эталонной модели, представленная модель имеет ряд особенностей:
- модель отражает 5 уровней интероперабельности;
- для данной модели характерно обязательное наличие двух систем: системы, которая потребляет услуги или товары, т. е. клиента; и си стемы, которая предоставляет услуги или товары, - продавца. Третьим звеном в данной цепочке является посредник. В большинстве случаев в качестве посредников выступают банки, платежные шлюзы, агентства и др.;
- наличие программного модуля, позволяющего достичь семантического уровня интероперабельности и перейти к интероперабельности бизнес-процессов.
Хочется отметить, что сущность «посредник» явно не упоминается в классической модели электронной коммерции (B2B, B2C и др.), но она, на самом деле, завуалирована (к примеру, B2B2C). Таким образом, мы акцентируем внимание на том, что у модели может быть дополнительная сущность «посредник», так как именно цепочка покупатель - посредник - продавец позволяет более широко понять процесс обеспечения интероперабельности электронной коммерции.
Согласованный набор стандартов в рамках модели
Для того чтобы реализовать модель на практике, необходимо согласовать набор стандартов, который будет использоваться в рамках этой модели. Опираясь на исследование Австралийского национального университета, приведем общий список стандартов, которые могут быть использованы в области электронной коммерции .
UN/EDIFACT расшифровывается как «Правила ООН электронного обмена документами для гос. управления, торговли и транспорта».
Электронный обмен документами (Electronic Data Interchange - EDI) налагает три основных требования:
- соблюдение единого синтаксиса обмена;
- возможность выбора элементов данных;
- единый формат, в котором эти элементы представлены при генерации сообщений и файлов для обмена.
В настоящее время реализуется проект ebXML «Создание единого глобального электронного рынка», который поддерживается Организацией продвижения стандартов структурированной информации OASIS. При разработке проекта ebXML применялись следующие основные принципы:
- простое, единое и повсеместное использование ebXML в электронном бизнесе;
- использование спецификаций XML в максимально возможных пределах;
- обеспечение открытыми стандартами электронной торговли: B2B (business to business) и ВС (business to customer);
- объединение структуры и содержания компонентов расходящихся XML-инициатив в единый XML-бизнес-стандарт;
- минимизация затрат при обмене приложение-приложение;
- обеспечение мультиязычной поддержки;
- поддержка национальных и международных правил торговли;
- поддержка традиционных принципов EDI на основе стандарта UN/EDIFACT.
XML DTD описывает схему документа для конкретного языка разметки посредством набора объявлений (объектов-параметров, элементов и атрибутов), которые описывают его класс (или тип) с точки зрения синтаксических ограничений этого документа. Также DTD может объявлять конструкции, которые всегда необходимы для определения структуры документа и могут влиять на интерпретацию определенных документов.
В XML-документах DTD определяет набор действительных элементов, идентифицирует элементы, которые могут находиться в других элементах, и определяет действительные атрибуты для каждого из них. Синтаксис DTD весьма своеобразен, и от автора-разработчика требуются дополнительные усилия при создании таких документов. В XML использовать DTD не обязательно - документы, созданные без этих правил, будут правильно обрабатываться программой-анализатором, если они удовлетворяют основным требованиям синтаксиса XML. Однако контроль за типами элементов и корректностью отношений между ними в этом случае будет полностью возлагаться на автора документа.
Стандарт W3C1 XML E-commerce содержит:
WSDL (Web Services Description Language) - язык описания веб-сервисов и доступа к ним, основанный на языке XML. Последние официальные спецификации - версия 2.0, которая имеет статус рекомендации, и версия 1.1, которая имеет статус заметки (note);
SOAP - облегченный протокол для обмена структурированной информацией в децентрализованной, распределенной среде;
XML Schema - язык для описания структуры и ограничения содержимого XML-документов.
Document Related Standards определяет 4 типа стандартов разметки документов:
XSL - расширяемый язык таблиц стилей;
XSLT - язык для преобразования XML-документов в другие XML-документы;
XHTML - семейство языков разметки вебстраниц на основе XML, повторяющих и расширяющих возможности HTML. Спецификации XHTML 1.0 и XHTML 1.1;
XML - расширяемый язык разметки.
1 Консорциум Всемирной паутины (World Wide Web Consortium, W3C) - организация, разрабатывающая и внедряющая технологические стандарты для Всемирной паутины.
Программная реализация интероперабельности на семантическом уровне
Исходя из набора стандартов, приведенного выше, можно сделать вывод, что в основе наиболее удачных и эффективных решений заложена технология XML. XML стал стандартом по форме рекомендации W3C, а потребность в приложениях, основанных на данной технологии, растет очень быстро.
Если рассматривать связь XML с другими стандартами, то можно выделить следующие ключевые технологии XML ТМ :
- использует правила, определенные консорциумом W3C;
- рекомендует использовать Unicode ТИ29 для обеспечения эффективной разметки текстовых элементов, что является необходимым условием для сегментации количества слов и символов;
- использует правила, определенные в стандарте SRX, для сегментации отдельных блоков текста в предложения;
- включает в себя стандарт XLIFF для извлечения текста для последующего перевода;
- позволяет легко создавать TMX-файлы для выгрузки из памяти сохраненных переводов между программной и клиентской частью.
Важно также рассмотреть роль XML в электронной коммерции и проблемы, которые необходимо преодолеть, чтобы сохранить их эффект от взаимодействия. С точки зрения электронной коммерции, в XML заложены следующие преимущества .
Стандартизация XML. Стандартизация в представлении и передаче информации имеет решающее значение для В2В и В2С электронной коммерции. XML не зависит от платформы, и приложения, построенные на технологии XML, независимы.
Управляемость. Приложения, построенные на XML, могут быть преобразованы под различные мультимедийные устройства (веб-браузер, документы, компакт-диски и т. д.).
Продолжительный жизненный цикл информационной системы. XML-форматы, а также системы, использующие XML, существуют в виде обычного текста. Это дает возможность использо-
вать данные на протяжении более длительного срока службы с возможностью использовать их повторно. Даже если система окажется устаревшей, данные будут актуальными и доступными в долгосрочной перспективе.
Расширяемость. XML, как мета-язык, обеспечивает стандартные рамки для создания бизнес-ориентированных словарей.
Интернационализация данных. Одним из главных преимуществ ведения бизнеса в Интернете является расширение клиентской базы в сторону глобализации, без необходимости привязки к конкретному офису. С поддержкой юникода в XML веб-сайты и интернет-магазины могут быть многоязычными.
Перечень достоинств XML можно продолжить и дальше. Следует сказать, что само по себе использование XML не может дать успешного решения в области электронной торговли, но может предложить огромный потенциал для бизнеса, разработчиков и потребителей, участвующих в электронной торговле. XML является надежным фундаментом для построения приложений, которые будут обладать высоким уровнем интероперабельности.
Заключение
В данной статье была предложена концепция по обеспечению интероперабельности в области электронной коммерции, состоящая из пяти этапов. Были рассмотрены основные положения, архитектура, модель, стандарты и реализация, на основе чего можно сделать следующие выводы:
- зачастую некоторые из этапов могут быть опущены или объединены (к примеру, модель и архитектура) исходя из специфики рассматриваемой области деятельности человека;
- особенностями модели интероперабельности электронной коммерции является наличие трех сущностей, в отличие от классической модели (В2В, В2С и т. д.).
Разработанная концепция позволила перейти к реализации программного решения (модуля ЕсШ) на основе технологии XML. Планируется внедрить ЕсШ в реальный проект (электронную площадку).
Литература
1. NIST Framework and Roadmap for Smart Grid Interoperability standards, 2010. nist.gov/ public_affairs/releases/upload/smartgrid_interop-erability_final.pdf (дата обращения: 09.07.2012).
2. National E-Health Transition Authority Framework, 2008. nehta.gov.au/component/docman/ doc_details/391-interoperability-framework-v20 (дата обращения: 09.07.2012).
Олейников А. Я. Технология открытых систем. - М.: Янус-К, 2004. - 286 с.
Разинкин Е. И. Обзор концептуальных документов, архитектур и моделей в области обеспечения интероперабельности в сфере e-commerce // Стандартизация, сертификация, обеспечение эффективности, качества и безопасности информационных технологий: сб. ст. Междунар. конф. «СИТОП», 2011. С. 46-50.
Разинкин Е. И. Разработка информационной предметной среды на основе технологии открытых систем: тез. докл. внутривуз. студ. конф. по итогам НИРС за 2006/07 учеб. год / под общ. ред. П. Ю. Романова, Т. В. Саляевой. Магнитогорск: МаГУ, 2007. С. 273. Handfield R. B., Nichols E. L. Supply chain redesign. Transforming supply chains into integrated value systems. - Financial Times Prentice Hall books, 2002. - 371 p.
7. Sikander J. B., Sarma V. O. A Prescriptive Architecture for Electronic Commerce and Digital Marketing. - Microsoft Ltd, 2010. - 98 p.
8. Батоврин В. К., Гуляев Ю. В., Олейников А. Я. Обеспечение интероперабельности - основная тенденция в развитии открытых систем // Информационные технологии и вычислительные системы. 2009. № 5. С. 7-15.
9. Information Technology in Electronic Commerce. Australian National University. https://wattle.anu . edu.au (дата обращения: 09.07.2012).
10. Kamthan P. B., Pai H. I. Perspectives of XML in E-Commerce. - IRT, 2002. - 40 p.
11. Anderson M. M. Workflow Interoperability - Enabling e-commerce. - WfMC White Paper, 1999. - 12 p.

стр. 1

стр. 2

стр. 3

стр. 4

стр. 5

стр. 6

стр. 7

стр. 8

стр. 9

стр. 10

стр. 11

стр. 12

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Информационные технологии

Интероперабельность. Основные положения

Издание официальное

Стандартинформ

Предисловие

1 РАЗРАБОТАН Федеральным государственным бюджетным учреждением науки Институтом радиотехники и электроники им. В.А. Котельникова РАН (ИРЭ им. В.А. Котельникова РАН)

2 ВНЕСЕН Техническими комитетами по стандартизации ТК 459 «Информационная поддержка жизненного цикла изделий» и ТК22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 13 ноября 2012 г. №751-ст

4 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок-в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

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

ГОСТ Р 55062-2012

6.2.2 При построении архитектуры следует пользоваться сервис-ориентированным подходом, основанном на использовании распределенных, слабо связанных (англ, loose coupling) заменяемых компонентов, оснащенных стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам .

6.3 Построение проблемно-ориентированной модели интероперабельности

6.3.1 Проблемно-ориентированная модель может иметь больше уровней интероперабельности за счет «расщепления» уровней эталонной модели в зависимости от вида интероперабельности. К этим видам могут относиться: динамическая, концептуальная, интеграционная интероперабельность .

6.4 Построение профиля интероперабельности

6.4.1 Профиль интероперабельности - согласованный набор стандартов, расположенных по уровням проблемно-ориентированной модели интероперабельности систем конкретного класса. Процесс построения профиля интероперабельности, в сущности, такой же, как при построении профиля организации-пользователя, описанного в Р 50.1.041-2002. Этот процесс состоит в последовательной идентификации требований к ИС, требований к службам, необходимым для выполнения этих требований, требований к соответствующим ИТ и к стандартам этих ИТ. Его можно представить в виде ряда этапов. На заключительном этапе и происходит построение профиля. Отличие профиля интероперабельности от профиля, описанного в Р 50.1.041-2002, состоит в том, что кроме стандартов технического уровня в профиль будут входить стандарты более высокихуровней, нормативно-правовые документы самых верхних уровней. При сравнении с профилем, описанным в Р 50.1.022-2000, следует говорить о профиле «второго поколения» .

6.5 Программно-аппаратная реализация

6.5.1 Современные информационные системы строятся из программно-аппаратных модулей со стандартными интерфейсами. Стандарты на эти интерфейсы должны быть указаны в профиле интероперабельности. Эти модули получили в мировой практике название COTS-продуктов (Commercial Of The Shelf products). Использование COTS-продуктов позволяет разработчику систем не зависеть от конкретного поставщика и получить примерно 4-кратную выгоду по сравнению с построением «монолитных» систем.

6.6 Аттестационное тестирование

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

7

Библиография

Технология открытых систем/под редакцией Олейникова А.Я. - М.: Янус-К, 2004. - 288 с.

Гуляев Ю.В., Журавлев Е.Е., Олейников А.Я. Методология стандартизации для обеспечения интероперабельности информационных систем широкого класса. Аналитический обзор//Журнал радиоэлектроники, 2012. - № 3. [Электронный ресурс]: URL: jre.cplire.ru/jre/Mar/12/2/text/pdf.

Олейников А.Я., Разинкин Е. И. Особенности подхода к обеспечению интероперабельности в области электронной коммерции//Информационные технологии и вычислительные системы, 2012. - № 3. - С. 82-92

Европейская концепция интероперабельности для услуг Общеевропейского электронного правительства. Проект для публичного обсуждения как основа для EIF 2.0-1/07/2008

Гуляев Ю.В., Олейников А.Я. Стандартизация информационных технологий в фундаментальных исследованиях. Стандарты информационных технологий от «нано» до GRID//Мир стандартов, 2008.- №8.- С. 12-25

Майерс Б.Г., Оберндорф П. Управление приобретением программного обеспечения: открытые системы и COTS-продукты. -Addison-Wesley, 2001

Батоврин В.К., Гуляев Ю.В., Олейников А.Я. Обеспечение интероперабельности-основная тенденция в развитии открытых систем//Информационные технологии и вычислительные системы, 2009. - № 5. - С. 7-15

ИСО/МЭК/ИЕЕЕ 24765:2010 Системы и программотехника. Словарь

ИСО 11354-1:2011 Современные автоматизированные технологии и их применение. Требова

ния к установлению взаимодействия процессов на производственных предприятиях. Часть 1. Система взаимодействия предприятий

Батоврин В.К. Системная и программная инженерия/Словарь-справочник. - М.: ДМК Пресс, 2010

Эталонная модель сервис-ориентированной архитектуры 1.0. Стандарт организации OASIS, 12 октября, 2006

Липаев В.В. Системы тестирования ИТ-продуктов на соответствие стандартам: учебник. - М.: СИНТЕГ, 2010.-270 с.

УДК 004.773:006.354 ОКС 35.240.50

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

Редактор Н.Н. Кузьмина Технический редактор В.Н. Прусакова Корректор И.А. Королева Компьютерная верстка И.А. Налейкиной

Сдано в набор 04.02.2014. Подписано в печать 13.02.2014. Формат 60 х 84^. Гарнитура Ариал. Уел. печ. л. 1,40. Уч.-изд. л. 1,10. Тираж 74 экз. Зак. 231.

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ», 123995 Москва, Гранатный пер., 4. www.gostinfo.ru [email protected]

ГОСТ Р 55062-2012

1 Область применения...................................................1

3 Термины, определения и сокращения........................................2

4 Общие положения....................................................3

5 Эталонная модель интероперабельности.....................................3

5.1 Технический уровень................................................4

5.2 Семантический уровень..............................................4

5.3 Организационный уровень............................................4

6 Основные этапы обеспечения интероперабельности..............................4

6.1 Создание концепции................................................5

6.2 Построение архитектуры.............................................6

6.3 Построение проблемно-ориентированной модели интероперабельности...............7

6.4 Построение профиля интероперабельности.................................7

6.5 Программно-аппаратная реализация......................................7

6.6 Аттестационное тестирование..........................................7

Библиография........................................................8

Введение

На этой основе в настоящем стандарте описывается единый подход к обеспечению интероперабельности для систем самого широкого класса.

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

ГОСТ P 55062-2012

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИХ ИНТЕГРАЦИЯ

Интероперабельность.

Основные положения

Information technologies. Industrial automation systems and integration. Interoperability. Basic principles

Дата введения-2013-09-01

1 Область применения

1.1 Настоящий стандарт определяет:

Основные понятия, связанные с понятием «интероперабельность»;

Подходы кдостижению интероперабельности и имеющиеся барьеры;

Единый подход кобеспечению интероперабельности информационных систем широкого класса;

Основные этапы по достижению интероперабельности.

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты и документы:

ГОСТ РИСО/МЭК 7498-1-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

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

Издание официальное

3 Термины, определения и сокращения

3.1 В настоящем стандарте применены термины по ГОСТ Р1.1-2005, ГОСТ Р1.12-2004, а также следующие термины с соответствующими определениями:

3.1.1 архитектура (arhitecture): Фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и сокружающей средой, и руководящие правила проектирования и развития системы. Термин «архитектура» определяется в стандартах системной и программной инженерии применительно к системам.

3.1.2 аттестационное тестирование интероперабельности (interoperabiliy 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.9 интероперабельная система (interoperable system): Система, в которой входящие в нее подсистемы работают по независимым алгоритмам, не имеют единой точки управления, все управление определяется единым набором стандартов - профилем интероперабельности.

3.1.10 интероперабельность предприятия (enterprise interoperability): Способность предприятий или находящихся в них сущностей (объектов) осуществлять эффективную связь и взаимодействие.

3.1.11 концепция (framework): Основные положения по достижению интероперабельности. Термин framework имеет много значений: начиная от буквального смысла (каркас, рамка), широкого смысла (концептуальная основа, контекст, основные принципы, описание основных проблем предметной области и обобщенные правила для их решения) и узкого смысла, понимаемого программистами, - структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта.

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): Способ, с помощью которого решаются проблемы и преодолеваются барьеры интероперабельности.

ГОСТ Р 55062-2012

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 Общие положения

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

В основе единого подхода должна лежать эталонная модель интероперабельности.

5 Эталонная модель интероперабельности

Эталонная модель интероперабельности представляет собой развитие семиуровневой базовой эталонной модели ВОС согласно ГОСТ Р ИСО/МЭК 7498-1-99 (рисунок 1), , .

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

5.1 Технический уровень

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

5.2 Семантический уровень

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

5.3 Организационный уровень

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

Примечани е - Интероперабельность считается значимой, если взаимодействие имеет место, по крайней мере, на трех уровнях: техническом, семантическом и организационном.

6 Основные этапы обеспечения интероперабельности

Основные этапы обеспечения интероперабельности приведены на рисунке 2.

Последовательная реализация этапов должна привести к созданию интероперабельной системы. Для успешной реализации всего процесса достижения интероперабельности необходимо также создать «План разработки стандартов» и разработать необходимые стандарты, которые должны постоянно актуализироваться.

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

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

ГОСТ Р 55062-2012

6.1 Создание концепции

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

6.1.2 Положение о том, что одной из фундаментальных особенностей развития современных ИКТ выступает формирование гетерогенной ИКТ-среды. В такой среде возникает проблема взаимодействия разнородных компонентов (систем), получившая название «проблема интероперабельности». Основным способом для решения данной проблемы является планомерное и последовательное использование принципов открытых систем, в основе которых лежит использование методов функциональной стандартизации и согласованных наборов ИКТ-стандартов - профилей. Интероперабельность, наряду со свойствами «переносимость» и «масштабируемость», представляет важнейшее свойство открытых систем. Первоначально термин «интероперабельность» был введен только на техническом уровне (см. рисунок 1), он получил распространение за счет использования стандартных протоколов связи .

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

6.1.4 Положение о том, что интероперабельность представляет собой средство повышения конкурентоспособности организаций. Интенсивное применение ИКТ в различныхорганизациях (на предприятиях, в исследовательских, образовательных, лечебных учреждениях и др.) привело к понятию «электронное предприятие» (e-enterprise). Соответственно возникло понятие «интероперабельность предприятия» (enterprise interoperability) .

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

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

В настоящее время ИС строятся не как монолитные системы, а из коммерчески доступных программно-аппаратных модулей со стандартными интерфейсами, обеспечивающими интероперабельность, так называемые Commercial Of The Shelf products (COTS-products). Отсюда следует, что обеспечение интероперабельности - одно из главных требований при построении современных ИС .

6.1.8 В настоящее время используют множество определений понятия «интероперабельность», поскольку многие организации дают собственные определения, исходя из стоящих перед ними задач. В концепции должно быть указано определение понятия «интероперабельность», желательно данное официальной организаций по стандартизации. Наряду с понятием «интероперабельность» используется еще целый ряд родственных понятий, такие как совместимость на уровне протоколов передачи данных (coexistent), способность к соединению (interconnectable), способность к взаимодействию (interworkable) .

Примечание - В под «интероперабельностью» понимается способность двух или более систем или компонентов к обмену информацией и к использованию информации, полученной в результате обмена.

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

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

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

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

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

Концепция должна быть утверждена уполномоченным органом соответствующего уровня.

Примечание - Если речь идет об интероперабельности при создании электронного правительства, концепция должна быть утверждена на правительственном уровне; если речь идет об интероперабельности в области электронного здравоохранения - Минздравом РФ; если речь идет об интероперабельности в области электронного образования - Минобрнауки РФ и т. д.

6.2 Построение архитектуры

6.2.1 Архитектура - фундаментальная организация системы, реализованная в ее компонентах, ихвзаимосвязяхдругсдругом и сокружающей средой, и руководящие правила проектирования и развития системы. Термин «архитектура» определяют в стандартах системной и программной инженерии применительно к системам. В более широком смысле определяются информационная архитектура, программная архитектура, архитектура данных, архитектура управления объектами. Архитектура позволяет выделить объекты стандартизации для построения профиля интероперабельности .

ГОСТ Р 55062-2012

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИХ ИНТЕГРАЦИЯ

Интероперабельность. Основные положения

Information technologies. Industrial automation systems and integration. Interoperability. Basic principles

ОКС 35.240.50

Дата введения 2013-09-01

Предисловие

1 РАЗРАБОТАН Федеральным государственным бюджетным учреждением науки Институтом радиотехники и электроники им. В.А.Котельникова РАН (ИРЭ им.В.А.Котельникова РАН)

2 ВНЕСЕН Техническими комитетами по стандартизации ТК 459 "Информационная поддержка жизненного цикла изделий" и ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 13 ноября 2012 г. N 751-ст

4 ВВЕДЕН ВПЕРВЫЕ

5 ПЕРЕИЗДАНИЕ. Октябрь, 2018 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации" . Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

На этой основе в настоящем стандарте описывается единый подход к обеспечению интероперабельности для систем самого широкого класса.

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

1 Область применения

1.1 Настоящий стандарт определяет:

- основные понятия, связанные с понятием "интероперабельность";

- подходы к достижению интероперабельности и имеющиеся барьеры;

- единый подход к обеспечению интероперабельности информационных систем широкого класса;

- основные этапы по достижению интероперабельности.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты и документы:

Р 50.1.022-2000 Рекомендации по стандартизации. Информационная технология. Государственный профиль взаимосвязи открытых систем России. Версия 3

Р 50.1.041-2002 Рекомендации по стандартизации. Информационные технологии. Руководство по проектированию профилей среды открытой системы (СОС) организации-пользователя

ГОСТ Р ИСО/МЭК 7498-1-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

Примечание - При пользовании настоящим стандартом необходимо проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 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.9 интероперабельная система (interoperable system): Система, в которой входящие в нее подсистемы работают по независимым алгоритмам, не имеют единой точки управления, все управление определяется единым набором стандартов - профилем интероперабельности.

3.1.10 интероперабельность предприятия (enterprise interoperability): Способность предприятий или находящихся в них сущностей (объектов) осуществлять эффективную связь и взаимодействие.

3.1.11 концепция (framework): Основные положения по достижению интероперабельности. Термин framework имеет много значений: начиная от буквального смысла (каркас, рамка), широкого смысла (концептуальная основа, контекст, основные принципы, описание основных проблем предметной области и обобщенные правила для их решения) и узкого смысла, понимаемого программистами, - структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта.

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 Общие положения

5 Эталонная модель интероперабельности

Эталонная модель интероперабельности представляет собой развитие семиуровневой базовой эталонной модели ВОС согласно ГОСТ Р ИСО/МЭК 7498-1-99 (рисунок 1), , *.
________________
* Поз., , см. раздел Библиография. - Примечание изготовителя базы данных.

Рисунок 1 - Эталонная модель интероперабельности

5.1 Технический уровень

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

5.2 Семантический уровень

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

5.3 Организационный уровень

6 Основные этапы обеспечения интероперабельности

Основные этапы обеспечения интероперабельности приведены на рисунке 2.

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

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

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

Рисунок 2 - Основные этапы обеспечения интероперабельности

6.1 Создание концепции

6.1.2 Положение о том, что одной из фундаментальных особенностей развития современных ИКТ выступает формирование гетерогенной ИКТ-среды. В такой среде возникает проблема взаимодействия разнородных компонентов (систем), получившая название "проблема интероперабельности". Основным способом для решения данной проблемы является планомерное и последовательное использование принципов открытых систем, в основе которых лежит использование методов функциональной стандартизации и согласованных наборов ИКТ-стандартов - профилей. Интероперабельность, наряду со свойствами "переносимость" и "масштабируемость", представляет важнейшее свойство открытых систем. Первоначально термин "интероперабельность" был введен только на техническом уровне (см. рисунок 1), он получил распространение за счет использования стандартных протоколов связи .

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

6.1.4 Положение о том, что интероперабельность представляет собой средство повышения конкурентоспособности организаций. Интенсивное применение ИКТ в различных организациях (на предприятиях, в исследовательских, образовательных, лечебных учреждениях и др.) привело к понятию "электронное предприятие" (e-enterprise). Соответственно возникло понятие "интероперабельность предприятия" (enterprise interoperability) .

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

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

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

В настоящее время ИС строятся не как монолитные системы, а из коммерчески доступных программно-аппаратных модулей со стандартными интерфейсами, обеспечивающими интероперабельность, так называемые Commercial Of The Shelf products (COTS-products). Отсюда следует, что обеспечение интероперабельности - одно из главных требований при построении современных ИС .

6.1.8 В настоящее время используют множество определений понятия "интероперабельность", поскольку многие организации дают собственные определения, исходя из стоящих перед ними задач. В концепции должно быть указано определение понятия "интероперабельность", желательно данное официальной организаций по стандартизации. Наряду с понятием "интероперабельность" используется еще целый ряд родственных понятий, такие как совместимость на уровне протоколов передачи данных (coexistent), способность к соединению (interconnectable), способность к взаимодействию (interworkable) .

Примечание - В под "интероперабельностью" понимается способность двух или более систем или компонентов к обмену информацией и к использованию информации, полученной в результате обмена.

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

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

Концепция должна быть утверждена уполномоченным органом соответствующего уровня.

Примечание - Если речь идет об интероперабельности при создании электронного правительства, концепция должна быть утверждена на правительственном уровне; если речь идет об интероперабельности в области электронного здравоохранения - Минздравом РФ; если речь идет об интероперабельности в области электронного образования - Минобрнауки РФ и т.д.

6.2 Построение архитектуры

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

6.2.2 При построении архитектуры следует пользоваться сервис-ориентированным подходом, основанном на использовании распределенных, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащенных стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам .

6.3 Построение проблемно-ориентированной модели интероперабельности

6.3.1 Проблемно-ориентированная модель может иметь больше уровней интероперабельности за счет "расщепления" уровней эталонной модели в зависимости от вида интероперабельности. К этим видам могут относиться: динамическая, концептуальная, интеграционная интероперабельность .

6.4 Построение профиля интероперабельности

6.4.1 Профиль интероперабельности - согласованный набор стандартов, расположенных по уровням проблемно-ориентированной модели интероперабельности систем конкретного класса. Процесс построения профиля интероперабельности, в сущности, такой же, как при построении профиля организации-пользователя, описанного в Р 50.1.041-2002 . Этот процесс состоит в последовательной идентификации требований к ИС, требований к службам, необходимым для выполнения этих требований, требований к соответствующим ИТ и к стандартам этих ИТ. Его можно представить в виде ряда этапов. На заключительном этапе и происходит построение профиля. Отличие профиля интероперабельности от профиля, описанного в Р 50.1.041-2002 , состоит в том, что кроме стандартов технического уровня в профиль будут входить стандарты более высоких уровней, нормативно-правовые документы самых верхних уровней. При сравнении с профилем, описанным в Р 50.1.022-2000 , следует говорить о профиле "второго поколения" .

6.5 Программно-аппаратная реализация

6.5.1 Современные информационные системы строятся из программно-аппаратных модулей со стандартными интерфейсами. Стандарты на эти интерфейсы должны быть указаны в профиле интероперабельности. Эти модули получили в мировой практике название СOTS-продуктов (Сommercial Of The Shelf products). Использование COTS-продуктов позволяет разработчику систем не зависеть от конкретного поставщика и получить примерно 4-кратную выгоду по сравнению с построением "монолитных" систем.

6.6 Аттестационное тестирование

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

Библиография


	Технология открытых систем/под редакцией Олейникова А.Я. - М.: Янус-К, 2004. - 288 с.
	Гуляев Ю.В., Журавлев Е.Е., Олейников А.Я. Методология стандартизации для обеспечения интероперабельности информационных систем широкого класса. Аналитический обзор//Журнал радиоэлектроники, 2012. - N 3. [Электронный ресурс]: URL: jre.cplire.ru/jre/Mar/12/2/text/pdf.
	Олейников А.Я., Разинкин Е.И. Особенности подхода к обеспечению интероперабельности в области электронной коммерции//Информационные технологии и вычислительные системы, 2012. - N 3.- С.82-92
	Европейская концепция интероперабельности для услуг Общеевропейского электронного правительства. Проект для публичного обсуждения как основа для EIF 2.0-1/07/2008*
________________ * Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт http://shop.cntd.ru . - Примечание изготовителя базы данных.
	Гуляев Ю.В., Олейников А.Я. Стандартизация информационных технологий в фундаментальных исследованиях. Стандарты информационных технологий от "нано" до GRID //Мир стандартов, 2008. - N 8. - C.12-25
	Майерс Б.Г., Оберндорф П. Управление приобретением программного обеспечения: открытые системы и COTS-продукты. - Addison-Wesley, 2001
	Батоврин В.К., Гуляев Ю.В., Олейников А.Я. Обеспечение интероперабельности - основная тенденция в развитии открытых систем//Информационные технологии и вычислительные системы, 2009. - N 5. - С.7-15
	ИСО/МЭК/ИЕЕЕ 24765:2010 Системы и программотехника. Словарь
	ИСО 11354-1:2011	Современные автоматизированные технологии и их применение. Требования к установлению взаимодействия процессов на производственных предприятиях. Часть 1. Система взаимодействия предприятий
	Батоврин В.К. Системная и программная инженерия/Словарь-справочник. - М.: ДМК Пресс, 2010
	Эталонная модель сервис-ориентированной архитектуры 1.0. Стандарт организации OASIS, 12 октября, 2006
	Липаев В.В. Системы тестирования ИТ-продуктов на соответствие стандартам: учебник. - М.: СИНТЕГ, 2010. - 270 с.


УДК 004.773:006.354	ОКС 35.240.50

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

Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
М.: Стандартинформ, 2018

Л.Калиниченко
Институт проблем информатики РАН

Введение

Настоящий доклад рассматривает аспекты новой, быстро развивающейся и уже интенсивно применяемой технологии создания открытых систем - технологии интероперабельных систем.
Рассматриваемая технология привела к выделению нового архитектурного слоя - информационной архитектуры систем, определяющей способность совместного использования, совместной деятельности (в дальнейшем будет использоваться термин "интероперабельность") компонентов (информационных ресурсов) для решения задач. Этот слой расположен обычно над сетевой архитектурой, являющейся необходимой предпосылкой такой совместной деятельности компонентов, обеспечивающей их взаимосвязь.
Деятельность по созданию технологии интероперабельных систем охватывает весь мир. Наиболее существенный вклад в принимаемые идеологические, архитектурные и технологические решения интероперабельных систем вносит 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).
В настоящем докладе предлагается краткий обзор структуры и компонентов архитектуры интероперабельных систем в соответствии с текущим состоянием разработки стандартов (более подробную информацию можно найти в ).

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

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

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

Брокер Объектных Заявок. Брокер Объектных Заявок обеспечивает механизмы, позволяющие объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь о положении в распределенной среде и способе реализации взаимодействующих с ними объектов. ORB отвечает за поиск реализации объекта, участвующего в заявке, подготовку объектной реализации к приему заявки и передачу данных, являющихся результатом заявки. Интерфейс клиента полностью независим от расположения вызываемого объекта, языка программирования, на котором он реализован, и любых других аспектов, не отраженных в интерфейсе вызываемого объекта. На основании совместных предложений ряда ведущих компаний OMG был разработан стандарт Общей Архитектуры Брокера Объектных Заявок (Common Object Request Broker Architecture (CORBA)) . CORBA определяет среду для различных реализаций ORB, поддерживающих общие сервисы и интерфейсы. Это обеспечивает переносимость клиентов и реализаций объектов между различными ORB.
В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту CORBA . 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. Существенное влияние на архитектурные решения оказывают также исследования и разработки, воплощенные в согласованном стандарте интерфейсов объектных СУБД , опубликованном в конце 1993 г. группой ODMG (Object Database Management Group). Эта группа включает представителей основных компаний - производителей объектных СУБД.
Общие Средства. Общие Средства заполняют концептуальное пространство между ORB и объектными службами с одной стороны, и прикладными объектами с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные Службы -- фундаментальные объектные интерфейсы, а задача Общих Средств -- поддержка интерфейсов сервисов высокого уровня. Общие Средства подразделяются на две категории: "горизонтальные" и "вертикальные" наборы средств. "Горизонтальный" набор средств определяет операции, используемые во многих системах, и не зависящие от конкретных прикладных систем. "Вертикальный" набор средств представляет технологию поддержки конкретной прикладной системы (вертикального сегмента рынка), такого, как здравоохранение, производство, управление финансовой деятельностью, САПР и т.д.
Ниже кратко рассматривается состав первоначальных компонентов спецификации архитектуры Общих Средств OMG .
Средства поддержки пользовательского интерфейса (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 является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и может быть отображен в любой транспортный протокол, поддерживающий виртуальные соединения. Одно из таких отображений - отображение 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 позволяет обеспечить поддержку глобального объектного пространства в масштабе Internet.
Существенное различие назначений WWW и CORBA заключается в том, что WWW облегчает жизнь поставщиков и потребителей информации, а CORBA облегчает задачу разработчиков систем и фирм-поставщиков инструментальных средств. Поэтому роли WWW и CORBA являются взаимно дополняющими, и в этой связи требуются специальные технологии, обеспечивающие их сопряжение. Такое сопряжение сулит очевидные преимущества. Разработчики программных продуктов, использующие CORBA, получают доступ к быстро растущему рынку на основе WWW, а мир WWW получает доступ к услугам, обеспечиваемым на основе возможностей CORBA, значительно более мощным, чем реализуемая WWW простая модель обмена HTML-страницами. Интеграция двух миров приведет к наилучшему использованию этих двух стандартов.
Известны два основных подхода к интеграции CORBA и WWW. Первый из них основан на построении шлюзов между мирами WWW и CORBA, служащих для трансформации HTTP в протокол CORBA 2.0 IIOP . Другой подход заключается во встраивании функций CORBA в состав клиентов WWW (программ просмотра) и серверов. Реализация второго подхода возможна либо на основе новых WWW клиентов и серверов со встроенным IIOP, либо при помощи подгрузки (downloading) из сети модуля поддержки IIOP в клиенте или сервере.
В новом поколении WWW клиентов и серверов, поддерживающих Java, модуль поддержки IIOP реализуется на Java. Достоинства этого подхода заключаются в обеспечении динамической "раскрутки" функций по отношению к CORBA. Так, для любого ресурса, доступного посредством CORBA, может быть разработан пользовательский интерфейс как апплет Java. Этот апплет использует модуль IIOP для взаимодействия с сервером CORBA. При первом доступе пользователя к какой-либо услуге, программа просмотра автоматически загружает и инсталлирует апплет пользовательского интерфейса. После этого пользователь имеет доступ к этой услуге посредством собственного апплета.
Таким образом, услуги объектов-серверов оказываются доступными широчайшей аудитории, независимо от применяемых пользователями платформ и при сохранении для разработчика возможности усовершенствования реализации услуг и их интерфейсов.

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

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

Заключение

В докладе дан краткий обзор информационной ар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.