CC BY
29ИНФОРМАТИКА И СИСТЕМЫ УПРАВЛЕНИЯ
УДК 004.75
Д.В. Жевнерчук, А.В. Аристов, Ю.В. Герасимов
СЕМАНТИЧЕСКАЯ ИНТЕРОПЕРАБЕЛЬНОСТЬ В ДИАЛОГОВЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
Чайковский технологический институт, Ижевский государственный технический университет, г. Чайковский
Определен технический базис, гарантирующий интероперабельность информационных систем на уровне данных и команд. Разработана методика взаимодействия информационных систем, функционирующих на разных программно-аппаратных платформах. Предложен метод эмуляции оператора для обеспечения взаимодействия информационных систем с низкой степенью интероперабельности. Предложена архитектура системы трансляции пользовательских управляющих сигналов между информационными системами.
Ключевые слова: интероперабельность, открытая система, интерфейс, архитектура, кроссплатформенность.
Введение
Сегодня технология открытых систем (ТОС) [1, 2, 3, 4] является перспективным и приоритетным государственным направлением научных исследований. Открытая система должна удовлетворять свойствам расширяемости, переносимости приложений и данных, масштабируемости и интероперабельности. Кроме того, она должна быть построена на основе совокупности ряда информационных стандартов, доступ к которым не ограничен техническими, юридическими или иными механизмами. Одной из ключевых характеристик открытых систем является интероперабельность, которая определяет способность систем взаимодействовать с другими системами [2]. В работе [5, 6] предлагаются методы, которые позволяют оценить возможность включения программного компонента в открытую систему. Во многих работах отмечается, что для включения программного компонента в открытую систему требуется привести его к стандартизованному профилю [3]. Это может потребовать модификации программного кода системы.
Постановка задачи
Объектом исследования является среда интеграции информационных систем, функционирование которой происходит в двух режимах:
• приложение как диалоговый сервис;
• приложение как знание-ориентированный сервис.
Во всех режимах среда должна быть расширяема по произвольным информационным системам, чтобы обеспечить передачу данных и управляющих сигналов между клиентскими и серверными платформами.
В первом случае к ядру среды дополнительно предъявляется требование передачи интерфейса пользователя клиентской платформе. Для универсальных инструментов должны быть доступны диалоговые средства, предоставляющие доступ ко всем функциям системы. Если на основе приложения развернут узкоспециализированный инструмент, то среда предоставляет некоторое подмножество диалоговых средств.
© Жевнерчук Д.В., Аристов А.В., Герасимов Ю.В., 2012.
Во втором случае интегрированные в среду приложения используются для решения конкретной задачи посредством агентных систем, запрашивающих у пользователя или других систем постановку задачи в формализованном виде.
Таким образом, требуется разработать методику построения мультирежимных сред интеграции информационных систем, а также найти технический базис для обеспечения ин-тероперабельности программных компонент на уровне обмена данными.
Методика
Среда интеграции информационных систем должна обладать свойствами открытой системы и должна уметь подключать информационные системы независимо от их степени интероперабельности. На рис. 1 представлена архитектура серверной части.
Для решения проблемы кроссплатформенности предлагается использовать уровень виртуальных машин [8]. Благодаря этому появляется возможность обрабатывать на одной аппаратной платформе информационные системы, функционирующие на основе API разных операционных систем. Вся вычислительная нагрузка ложится на серверный программно-аппаратный комплекс, именуемый далее вычислительное облако. Таким образом, облако представляет собой совокупность произвольных аппаратных платформ с установленными виртуальными машинами и / или операционными системами. Такое решение обеспечит функционирование произвольной информационной системы. Для взаимодействия информационных систем с внешней средой (другие ИС и пользователи) существует множество интерфейсов:
• интерфейсы объектов (распределенных объектов);
• сервисы;
• java интерфейсы;
• интерфейсы импорта/экспорта;
• пользовательские интерфейсы.
На рис. 1 представлена схема многоуровневой архитектуры серверной части.
CU, GUI, RDP, VNC COM, DCOXL CORBA, OpenTaifc WCF RMI SOA, Java SOA Множество вариантов
Пользовательский интерфейс Технология [распределенных] объектов Java Сервисы экспорт импорт
Информационные системы
Процессы Процессы
Гипервнзор 2 типа JRE Процессы
OSi OS; OS, OSp
VMi VM; VM, VM*
Гипервнзор 1 типа
А, А? А, Ал
Рис. 1. Многоуровневая архитектура серверной части
API современных операционных систем, расширяющие функциональность библиотеки и утилиты позволяют автоматизировать взаимодействие с ИС, используя любой из перечисленных интерфейсов, включая интерфейс пользователя (user interface, UI).
Клиентские системы в рамках концепции рассматриваются, как тонкие и ультратонкие и предназначены для приема от пользователя данных и управляющих сигналов, передачи их на сервер, а также для вывода возвращаемых с сервера результатов. Общая структура клиентской платформы представлена на рис 2.
Web клиент Desktop клиент Stream Video клиент
UI клиент
i к
Средства программной генеиаинн Потоковое видео Сетевой интерфейс прикладного уровня
Средства построения воспроизведения Ш
Операционная система
Al
А2
Ai
An
Рис. 2. Архитектура клиентской части
Пользовательский интерфейс на клиенте может быть построен с применением Web технологий, языков и средств разработки высокого уровня, API операционных систем. Отдельно на рисунке выделен подход, при котором UI транслируется в форме потокового видео в плейер, поддерживающий функции ввода данных и управляющих сигналов.
Для решения проблемы переносимости интерфейса пользователя предлагается использовать механизм виртуализации (рис. 3). Суть его состоит в следующем. Для всех серверных информационных систем создается формальное описание поддерживаемых интерфейсов, включая пользовательские, Web-сервисы, объектные/компонентные и др. Строится карта графического интерфейса пользователя, которая содержит информацию о дереве форм и элементах форм. Дополнительно формируется список доступных сервисов, которые могут быть запрошены пользователем. С каждым сервисом связываются интерфейсы и подмножество элементов GUI, необходимое для взаимодействия с пользователем.
При запросе сервиса информационной системы, включающего определенную группу функций, вместе с ним передается список поддерживаемых технологий построения GUI. По коду сервиса сервер определяет дерево и состав форм, формирует пользовательский интерфейс либо в потоковом видео, либо в коде, поддерживаемом клиентом. Для обеспечения переносимости пользовательского интерфейса были разработаны:
1) формат описания интерфейсов (карта интерфейсов) подключаемой информационной системы;
2) формат описания средств построения/воспроизведения UI клиентской платформы;
3) формат описания функциональных сервисов (карта сервисов) произвольных информационных систем;
4) протоколы обмена списками поддерживаемых технологий.
Интерфейсы
подзержив гемых интерфейсов
Рис. 3. Схема взаимодействия клиента и сервера
В указанных форматах содержатся:
• описание типа пользовательского интерфейса, идентификационных данных об управляющих компонентах, объектах, структурах;
• система команд с указанием формальных параметров;
• функции информационной системы с указанием формальных параметров, а также результата выполнения;
• типы управляющих сигналов, интерпретируемых информационной системой;
• связи типа «сигнал-команда-функция».
Для приема запросов к функциональным сервисам от пользователей и преобразования их к формату поддерживаемых интерфейсов предлагается использовать сервер интеропера-бельности.
Для обеспечения взаимодействия с программами, у которых существует только пользовательский интерфейс, используется режим эмуляции оператора. Под эмуляцией оператора будем понимать способ взаимодействия с информационной системой посредством элементов графического пользовательского интерфейса или с помощью интерфейса командной строки. Доступ к элементам GUI осуществляется с помощью API ОС, либо специализированных библиотек и утилит. Функционирующие в облаке информационные системы можно рассматривать в качестве ресурса или комплексного сервиса, запрашиваемого клиентами посредством серверов интероперабельности.
Для использования информационных систем в качестве знание-ориентированного сервиса (ресурса) введена дополнительная категория программного обеспечения - агент. Также были разработаны два интерфейса взаимодействия программного обеспечения: агент-ресурс и агент-оператор. Интерфейс агент-ресурс определяет правила обмена информацией и управляющими сигналами между системами эмуляции оператора и ресурсами. Ресурс
осуществляет обработку задания пользователя только по запросу агента. Интерфейс агент-оператор определяет правила приема и анализа пользовательского задания.
Итак, агент должен выполнять следующие функции:
1) прием и анализ пользовательского задания;
2) поиск ресурса, который обладает необходимыми сервисами;
3) передача параметров задачи ресурсу;
4) прием ответа от ресурса;
5) передача ответа пользователю.
В любом процессе решения задачи с применением программно-аппаратного обеспечения можно выделить три основные группы пользователей:
пользователи-заказчики, которые осуществляют постановку задачи; пользователи-аналитики, которые определяют методы и средства решения задачи; пользователи-операторы, которые обладают знаниями и навыками владения инструментом, решают задачи и передают результат заказчикам.
Таким образом, агент представляет собой эмуляцию пользователя-аналитика и пользователя-оператора.
На рис. 4 приведена концептуальная схема знание-ориентированной сетевой среды. В общем случае пользователь предает запрос на естественном языке. Агент определяет тип задачи, формализует ее постановку. Для этого требуется создать базу знаний предметной области, позволяющую определить методы, с помощью которых может быть решена задача, оиределить программный ресурс, который содержит реализацию выбранных методов.
Рис. 4. Концептуальная схема знание-ориентированной сетевой среды
На основании запросов к базе знаний, происходит выбор алгоритмов семантического анализа запроса и его формализация. На следующем этапе определяется класс задачи и ресурс, который может выступить в качестве инструмента для решения этой задачи. Паспорт
ресурса позволяет определить последовательность управляющих сигналов, которую должен сгенерировать агент и передать ресурсу. В процессе определения типа задачи так же выбирается алгоритм семантического разбора постановки задачи, формулируемой пользователем-заказчиком в текстовом виде. Для выбора алгоритма база знаний содержит информацию о связи между типом задачи и алгоритмами анализа семантики текста в контексте пользовательского задания. Кроме того, выбирается алгоритм представления запроса в формате, наиболее удобном для выработки последовательности управляющих сигналов к ресурсу. Пунктирными стрелками изображены связи типа "предметная область-онтология", а сплошными - связи типа "клиент знаний - онтология".
Экспериментальная часть
Предложенная методика была использована при построении тестовой среды доступа к информационным системам. Сервер 2 CPU 2,5 ГГц 4x; кэш (L1/ L2/ L3) - 128 Кб х4/ 512 Кб х4/ 6Мб; RAM 24 Гб, 4 HDD SAS 146Гб 2.; EIDE DVD+/-RW, на котором настроена виртуальная машина Oracle VirtualBox 4 и установлены 2 операционные системы: Windows XP и Mandriva Linux. На сервере выполняются приложения, поддерживающие интерфейс командной строки или графический интерфейс пользователя. Для каждого приложения создается xml файл с описанием интерфейсов. Отдельно реализована группа модулей для формирования клиентских скриптов, выполняющих построение GUI в браузере. В качестве основы построения GUI использовались j avascript (j Query) и HTML. Для связи с приложениями на сервере был настроен Apache 2.0 и реализованы модули на PHP 5.0. Передача запросов на сервер выполняется в асинхронном режиме с помощью ajax-запросов. Язык PHP поддерживает доступ к интерфейсу командной строки Windows и winAPI. WinAPI используется для доступа к оконным элементам приложений, управления активными окнами, эмуляции клавиатуры и мыши. Для управления приложениями в среде Linux был использован интерфейс командной строки, а также утилита xDoTool [9] для управления окнами и эмуляции клавиатуры и мыши. Серверные php модули получают от браузерных клиентов идентификатор сервиса, который описан в xml файлах. На основании идентификатора определяется запрашиваемое приложение, поддерживаемые интерфейсы и состав окон GUI. Формируемый клиентский скрипт содержит код виджетов, а также ajax запросов для передачи параметров на сервер. Серверные php модули формируют команды CLI, поддерживаемые приложениями и выполняют их. Если приложение поддерживает GUI, то на основе передаваемых параметров эмулируются клики мыши и нажатия клавиш в окне приложения. Результаты, отображаемые в оконных элементах, считываются API или xDoTool, в зависимости от того, какая ОС обрабатывает приложение, затем упаковываются в ajax ответ, возвращаются запросившему клиентскому модулю и выводятся в браузер.
Вывод
Предложенная методика может быть применена для:
• интеграции разнородных программно-аппаратных информационных систем в единое вычислительное облако;
• построения сервис-ориентированной интерактивной среды;
• построения знание-ориентированной среды, с четким делением приложений на ресурсы и агенты.
Был построен тестовый вариант среды интеграции информационных систем, тестирование среды проводилось для ОС Windows XP (процесс калькулятор) и Mandriva Linux (процесс SpeedCrunch). На клиентских системах использовались те же операционные системы. Для управления калькулятором в качестве интерфейса использовался GUI и API WIN32, с помощью которого осуществляется доступ к оконным элементам, а также эмуляция управляющих сигналов. Для управления SpeedCrunch использовалась утилита xDoTool.
Библиографический список
1. ISO/IEC TR 10000-1: 1995 (final text, June 1995), Information technology - Framework and taxonomy of International Standardized Profiles - Part 1 :General Principles and Documentation Framework.
2. Батоврин, В.К. Обеспечение интероперабельности - основная тенденция в развитии открытых систем / В.К. Батоврин, Ю.В. Гуляев, А.Я. Олейников // Информационные технологии и вычислительные системы. 5/2009.
3. Сухомлин, В.А. Методологический базис открытых систем // Открытые системы. 1996. N 4.
4. Технология открытых систем / под ред. А.Я. Олейникова. - М.: Янус-К, 2004.
5. Батоврин, В.К. Способ количественной оценки интероперабельности / В.К. Батоврин, А.С. Королев // Информационные технологии и вычислительные системы. 5/2009.
6. Петров, А.Б. Методика сравнительной оценки интероперабельности информационных систем / А.Б. Петров, Н.А. Стариковская // Информационные технологии и вычислительные системы. 5/2009.
7. Журавлев, Е.Е. Интероперабельность в e-science / Е.Е. Журавлев, А.Я. Олейников // Информационные технологии и вычислительные системы. 5/2009.
8. Гультяев, А.К. Виртуальные машины: несколько компьютеров в одном / А.К. Гультяев. -Питер, 2006. - 224 с.
9. Sissel, J. XDoTool - fake keyboard/mouse input, window management, and more, 2011 г. , http ://www.semicomplete.com/proj ects/xdotool/ #id270150
Дата поступления в редакцию 06.04.2012
D.V. Zhevnerchuk, A.V. Aristov, Y.V. Gerasimov
SEMANTIC INTEROPERABILITY OF DIALOG INFORMATION SYSTEMS
Subject: The subject of this study is the exchange of information between the programs that operate on different platforms and with different interfaces.
Purpose: The aim is to create architecture and methods for constructing of the software with the properties of openness. Design/methodology/approach: A theoretical framework is proposed based on virtualization of computer recourses, methodology of open systems in computer science and design of network software systems.
Findings: The results can be applied to the design and development of scalable, extensible integrated information systems whose components operate on different hardware and software platforms.
Research limitations/implications: The present study provides a starting-point for further research semantic interoperability of software with different interfaces.
Originality/value: All applications are integrated into the system can operate in a dialog or knowledge-oriented modes and represent the services documented with cross-platform data formats. The study defined technical basis to ensure interoperability of information systems at the level of data and commands, developed a method for the interaction of information systems that operate on different hardware and software platforms. Method is emulating an operator to ensure the interoperability of information systems with a low degree of interoperability.
Key words: interoperability, open systems, interface, architecture, cross-platform.
