CC BY
14УДК 004.75
А.В. Аристов, В.П. Зеленский
ИНТЕРОПЕРАБЕЛЬНОСТЬ ДИАЛОГОВЫХ ПРИЛОЖЕНИЙ В СЕТЕВОМ ОКРУЖЕНИИ
Нижегородский государственный технический университет им. Р.Е. Алексеева
Предложена модель описания интерфейсов приложений, которая может быть использована при построении комплексных диалоговых систем, обладающих свойством интероперабельности своих компонент.
Ключевые слова: гетерогенная среда, семантическая интероперабельность, модели, гипервизор, виртуализация.
При создании информационных систем с повышенными требованиями к свойствам открытости часто возникает проблема включения программных компонент с низким коэффициентом семантической интероперабельности [1]. В работах [2, 3] описаны подходы к повышению способности компонент к взаимодействию с внешним окружением. Отмечается, что, несмотря на дорогостоящие проекты, компаниями IBM, Microsoft, Oracle, SAP и др. цели эффективной семантической интероперабельности не были достигнуты. Одним из перспективных направлений является интероперабельность межсистемных сообщений. В этом случае информационная система может быть рассмотрена с точки зрения совокупности интерфейсов взаимодействия с внешним программным обеспечением, программно-аппаратной платформой и пользователями. Передачу данных и управляющих сигналов программам выполняет в конечном итоге операционная система.
Постановка задачи. Рассмотрим систему, состоящую из некоторого множества вычислительных узлов, функционирующих под управлением различных программно-аппаратных платформ. На каждом узле выполняются информационные системы со своим набором интерфейсов.
Требуется разработать технологию построения среды поддержки семантической ин-тероперебельности, которая обладает механизмами включения новых программно-аппаратных комплексов и построения на их основе сервис-ориентированных диалоговых систем. В круг задач входит разработка форматов хранения информации об интерфейсах приложений, включая пользовательский интерфейс, и о доступных функциях системы.
Информационное обеспечение и потоки сообщений в системе
На рис. 1 представлена схема передачи управляющих сигналов и данных между компонентами среды поддержки семантической интероперабельности.
В состав среды входит четыре подсистемы:
• клиент,
• сервер адресов, на котором располагаются сведения о существующих
информационных системах,
• сервер ресурса,
• ресурс, отдельная информационная система с поддержкой CLI.
На узлах хранится информация о поддерживаемых интерфейсах и функциях, которые доступны через этот интерфейс. На специально выделенном сервере адресов хранится информация о существующих в системе приложениях с указанием адреса узла. Запрос к системе выполняется с удаленного клиентского приложения, например, Web-браузера. Предварительно запрашиваются сведения о доступных приложениях или отдельных сервисах, построенных на базе приложений. Клиенту передается список приложений и сервисов. Идентифи-
© Аристов А.В., Зеленский В.П., 2016.
кационные данные выбранного приложения или сервиса передаются содержащему их узлу. После установления соединения клиенту передается информация о доступных интерфейсах, строится пользовательский интерфейс. Далее клиент взаимодействует с сервером ресурса, который осуществляет прием кода запрашиваемого сервиса и входные данные, преобразует их в инструкции, интерпретируемые информационной системой, и инициирует выполнение этих инструкций. После обработки запроса, результат возвращается от ресурса к серверу, где он передается клиенту, в доступном для него формате.
Клиент Сервер адресов Сервер ресурса Ресурс
Запрос списка сервисов гвах построения UI Карта интерфейсов
Сведения о доступных приложениях и сервисах Карта сервисов
Сведения о средс Управляющий сигнал
1 Идентификатор сервиса
Код Ш/Потоковое видео
Данные и идентификаторы функций
Результат в формате клиента
Результат в формате ресурса
Рис. 1. Схема передачи управляющих сигналов и данных
Клиент содержит список технологий, которые могут быть использованы для построения пользовательского интерфейса (карта UI), сервер адресов - идентификационные сведения узлов, на которых расположены ресурсы, а также список сервисов, доступных у ресурсов. Сервер ресурса включает описание интерфейсов ресурса и поддерживаемые ресурсом форматы запросов.
В рамках статьи рассматриваются системы с поддержкой интерфейса командной строки.
Модель интерфейсов CLI информационной системы
Были проанализированы CLI ряда программных систем, работающих под управлением ОС Windows и *nix. Любая команда CLI может быть описана с помощью шаблона:
[символ_начала_команды]имя_команды [параметр_1 [параметр_2 [...]]] (1) Символ начала команды может быть самым разным, однако чаще всего для этой цели используется косая черта (/). Если строка вводится без этого символа, выполняется некоторая базовая команда. Если же такой базовой команды нет, символ начала команды отсутствует вообще (как, например, в DOS). Параметры команд могут быть представлены в самых разных форматах. В основном применяются следующие правила:
• параметры разделяются пробелами (и отделяются от названия команды пробелом);
• параметры, содержащие пробелы, обрамляются кавычками-апострофами (') или двойными кавычками (");
• если параметр используется для обозначения включения какой-либо опции, выключенной по умолчанию, он начинается с косой черты (/) или дефиса (-);
• если параметр указывает действие из группы действий, назначенных команде, он не начинается со специальных символов;
• если параметр указывает объект, к которому применяется действие команды, он не начинается со специальных символов;
• если параметр указывает дополнительный параметр какой-либо опции, то он имеет формат /опция:дополнительный_параметр (вместо косой черты также может употребляться дефис).
Примеры приложений, предоставляющих CLI:
• САПР AutoCAD (http://www.autodesk.ru);
• система моделирования общего назначения GPSS World (http://www.minutemansoftware.com);
• свободный режимный текстовый редактор VIM (http://www.vim.org/). Предлагается описание формата представления CLI приложения с помощью XSD [4],
так как, в отличие от большинства языков описания XSD, был разработан для использования в создании программного обеспечения для обработки документов XML, а также:
• обладает мощными средствами для определения сложных структур данных;
• обеспечивает понятный способ описания грамматики языка;
• способен легко модернизироваться и расширяться.
XML-описание входящего сообщения состоит из общего описания формата и описания команды.
<xs:element name="inMessage"> <xs:compl exType>
<xs:element name="command" type="command" minOccurs="1" use="required"/> <xs:attribute name="number" type="xs:string"/> <xs:attribute name-"service" type="xs:string"/> <xs:complexType> </xs:element>
Тег command является контейнером для описания команд, подаваемых на вход CLI. <xs:complexType name="command"> <xs:sequence>
<xs:element name-'startSymbol" type-'startSymbol" minOccurs="0" maxOccurs="1"/> <xs:element name="comName" type-" tName " use="required" minOccurs="1" maxOccurs="1"/>
<xs:element name="comParams" type="comParams" min0ccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:ComplexType>
Тег startSymbol служит для описания символа начала команды, если в этом есть необходимость.
<xs:simpleType name="startSymbol"> <xs:restriction base="xs:string">
<xs:enumeration value-'/"/> <xs:enumeration value="-"/> <xs:enumeration value=":"/> <xs:whiteSpace value="collapse"/> </xs:restriction"> </xs:simpleType> Тег comName определяет имя команды. <xs:simpleType name-" tName ">
<х8:ге8Шс1;юп Ьа8е="х8:81;г1п§">
<хв^Ы1е8расе уа1ие="со11ар8е"/> <хв:райегп уа1ие="([а-2Л-2])*"/> </х8:ге8Шс1;1оп> </хв:в1шр1еТуре>
Тег comParams является контейнером описаний параметров команды. <хБ:сошр1ехТуре паше-'сошРагашБ "> <хБ:Бедиепсе>
<хв:е1ешеп паше="рБерага1ог" 1уре="рБерага1ог" ше="геди1геё" шахОссигБ="1"/> <хв:е1ешеп паше="рагашКеу" 1уре="рКеу" ш1пОссигБ="0" шахОссигБ="1"/> <хв:е1ешеп паше="рКаше" 1уре='ЧКаше" шахОссигБ="1"/> <хв:е1ешеп паше="аёёРагаш" 1уре=" аёёРагаш " ш1пОссигБ="0" шахОссигБ="1"/> <хв:е1ешеп паше="рБерага1ог" 1уре="рБерага1ог" ш1пОссигБ="0" шахОссигБ="1"/> <хв:е1ешеп паше="рУа1ие" 1уре="х8:81х1п§" ш1пОссиг8="0" шахОссигБ="1"/> </хБ:Бедиепсе> </хБ:сошр1 ехТур е>
Тег рБерага1ог описывает разделитель параметров. <хв:в1шр1еТуре паше="рБерага1ог"> <х8:ге8Шс1;1оп Ьа8е="х8:81х1п§">
<х8:епишегайоп уа1ие=" "/> <х8:епишегайоп уа1ие="_"/> </х8:ге8Шс1;1оп> </хв:в1шр1еТуре> Тег рагашКеу описывает элемент включения/выключения опции. <хв:в1шр1еТуре паше="рКеу"> <х8:ге8Шс1;1оп Ьа8е="х8:81х1п§">
<х8:епишегайоп уа1ие=" /"/> <х8:епишегайоп уа1ие="-"/> </х8:ге8Шс1;1оп> </хв:в1шр1еТуре>
Тег addParam описывает дополнительные параметры в случае их наличия. <хв:в1шр1еТуре паше="аёёРагаш"> <хБ:Бедиепсе>
<х8:ге81х1с1;1оп Ьа8е="х8:81;г1п§"> <хв:е1ешеп паше="со1оп" 1уре="х8:81х1п§" ше="геди1геё" йхеё=":" шахОссигБ="1"/> <хв:е1ешеп паше="аёёРагКаше" 1уре='ЧКаше" шахОссиге-' 1"/>
</хБ:геБ1г1с11оп> </хБ:Бедиепсе> </хБ:в1шр1еТуре>
Далее представлен пример входящего СКИ-сообщения, сформированного в соответствии с предлагаемым форматом и использующего механизм макроподстановок для передачи пользовательских данных. <1пМеБ8а§е> <сошшапё>
<81аЛ8ушЬо1>@ш8ушЬо1</81аг18ушЬо1>
<сошКаше>@шСош</сошКаше>
<сошРагашБ>
<рБерага1ог >@ш8ер</р8ерага1;ог > <рКаше>@шРКаше</рКаше> </сошРагашБ> <сошРагашБ>
<pSeparator >@usSep</pSeparator >
<pName>@usPName</pName>
<addParam>
<colon>:</colon>
<addParName>>@usAddPName </addParName> </addParam>
<pValue>@usPValue</pValue> </comParams> </command> </inMessage>
Исходящее CLI-сообщение рассматривается как совокупность некоторых текстовых данных. <xs:element name=MoutMessageM> <xs:annotation>
<x s:documentation>OutMessage</xs:documentation> </xs:annotation>
<xs:element name="data" type="xs:string"/> </xs:element>
Карта сервисов
Сервис представляет собой функцию, которая может быть запрошена у приложения. Для доступа к функции необходимо передать операционной системе, под управлением которой функционирует приложение, информацию о параметрах CLI для последующего ее выполнения. С клиентской системы передаются идентификатор запрашиваемого сервиса и пользовательские данные для обработки. Для каждого приложения подержится xml файл с информацией о доступных сервисах и шаблонах команд, именуемый далее картой сервисов. Шаблон команды включает наименование команд, список ключей, параметров, а также макроподстановок для пользовательских данных.
Экспериментальная система
Разработана система управления диалоговыми программами, поддерживающими интерфейс командной строки. Схема системы приведена на рис. 2.
Для решения проблемы переносимости интерфейса пользователя использован механизм виртуализации. Суть его состоит в следующем. Для всех серверных информационных систем создается формальное описание интерфейса командной строки CLI и пользовательского интерфейса. Строится карта графического интерфейса пользователя, которая содержит информацию о дереве форм и элементах форм. Дополнительно формируется список доступных сервисов, которые могут быть запрошены пользователем. С каждым сервисом связываются интерфейсы CLI и подмножество элементов GUI, необходимые для взаимодействия с пользователем. По коду сервиса сервер определяет дерево и состав форм, формирует пользовательский интерфейс в javascript коде.
Для обеспечения переносимости пользовательского интерфейса были разработаны:
1. Формат описания интерфейсов (карта интерфейсов) подключаемой информационной системы.
2. Формат описания средств построения/воспроизведения UI клиентской платформы.
3. Формат описания функциональных сервисов (карта сервисов) произвольных информационных систем.
Клиентское приложение - это браузер, в котором формируется удаленный GUI на основе передаваемого с сервера javascript кода. Для повышения эффективности разработки и
обеспечения независимости от браузера была использована библиотека jquery. Сервер ресурсов включает группу php модулей, выполняющих следующие функции:
• прием запросов сервисов от клиентских систем в асинхронном режиме;
• формирование команд на основе поддерживаемых шаблонов инструкций CLI;
• передача команд конечным приложениям;
• прием результатов обработки;
• передача результатов клиентским системам.
Проведено тестирование системы для приложений GPSS World Student (платформа win32) и Midnight Commander (платформа Linux).
Рис. 2. Схема системы управления диалоговыми программами
Выводы
Разработана архитектура среды, расширяемой по приложениям на основе разных API операционных систем, поддерживающим интерфейс командной строки. Для обеспечения независимости от программной платформы применялись гипервизоры. Предложен кросс -платформенный формат хранения шаблонов инструкций CLI, на основе которого построены механизмы взаимодействия клиентских систем и серверного программного обеспечения с CLI.
Методика может быть применена при создании систем с поддержкой семантической интероперабельности программных компонент, обладающих другими интерфейсами.
Библиографический список
1. Батоврин, В.К. Способ количественной оценки интероперабельности / В.К. Батоврин, А.С. Королев // Информационные технологии и вычислительные системы. 2009. №. 5.
2. Бородакий, Ю.В. К проблеме обеспечения интероперабельности Ю.В. Бородакий, Ю.Г. Лободинский, Информационные технологии и вычислительные системы. 2009. №. 5.
3. Батоврин, В.К. Обеспечение интероперабельности - основная тенденция в развитии открытых систем / В.К. Батоврин, Ю.В. Гуляев, А.Я. Олейников // Информационные технологии и вычислительные системы. 2009. №. 5.
4. Официальный сайт консорциума W3C [Электронный ресурс]. - Режим доступа к ресурсу: http: //www.w3. org
Дата поступления в редакцию 06.05.2016
A.V. Aristov, V.P. Zelenskii
INTERACTIVE APPLICATION INTEROPERABILITY IN A NETWORKED ENVIRONMENT
Nizhny Novgorod state technical university n.a. R.E. Alexeyev
Subject: The subject of this study is the open computer systems architecture.
Purpose: The aim is to create application interfaces model, which reduces the cost of creating complex information systems.
Design/methodology/approach: A theoretical framework is proposed based on methodology of open systems in computer science, cross-platform data formats and UML.
Findings: The results can be applied to the design and researching of scalable, extensible integrated information systems whose components operate on different hardware and software platforms. Research limitations/implications: The present study provides a continuation and development methods of constructing integrated information systems in a networked environment.
Originality/value: Model describing application interfaces, which can be used in the construction of complex interactive systems, with interoperability of their components was proposed.
Key words: heterogeneous environment, semantic interoperability, models, hypervisor, virtualization.
