CC BY
135
ИССЛЕДОВАНИЯ И РАЗРАБОТКИ РАСПРЕДЕЛЁННЫХ ПРОГРАММНЫХ СИСТЕМ
УДК 004.75
ПРИМЕНЕНИЕ WEB-СЛУЖБ В РОБОТОТЕХНИКЕ
© 2010 г. С.А. Минеев
Нижегородский госуниверситет им. Н.И. Лобачевского sergm@nifti.unn.ru
Поступила в редакцию 27.05.2010
Проблемы создания и обеспечения функционирования распределенных вычислительных комплексов в глобальной информационной сети тесно смыкаются с проблемами мобильной робототехники. Статья посвящена вопросам применения технологии Web-служб для создания робототехнических систем, обсуждаются стандарты, доступные инструментальные средства, проблемы и перспективы развития.
Ключевые слова: Web-службы, SOA, распределенные вычислительные системы, мобильные роботы.
Введение
Глобальная информационная сеть Intemet сегодня расширяется не только за счет подключения новых информационных серверов и стационарных пользовательских терминалов, но и за счет мобильных терминалов, аппаратных средств сбора первичной информации и другой аппаратуры. В сети успешно функционируют автоматические и автоматизированные узлы, например банкоматы, платежные терминалы, элементы систем аварийной и пожарной сигнализации. Предпринимаются попытки интеграции робототехнических систем с сетью Intemet.
Коммуникационные проблемы, которые приходится решать разработчикам платежных терминалов и других подобных систем, встают и перед создателями мобильных роботов. К таким проблемам можно отнести:
- обнаружение устройств и установление с ними сетевого соединения;
- обеспечение контроля доступа и криптозащиты передаваемых данных;
- низкую надежность сетевого соединения;
- многопользовательский доступ;
- организацию распределенных вычислений;
- организацию синхронного и асинхронного информационных взаимодействий.
Перечисленные проблемы возникают и в локальных вычислительных сетях. Существует много технологий (в том числе и стандартизированных), позволяющих решать данные про-
блемы для локальных вычислительных сетей, но в глобальной сети Internet эти технологии часто не могут эффективно применяться.
Ответом IT-индустрии и IT-сообщества на растущие запросы со стороны разработчиков и пользователей автономных автоматических систем, подключенных к сети Internet, стало появление ряда новых технологий, в том числе технологий Web-служб и SOA.
Свойства и виды Web-служб
Web-служба определяется как программная система, однозначно идентифицируемая уникальной символьной строкой URI (Uniform Resource Identifier), программный интерфейс Web-службы определен с помощью языка XML и публикуется в сети, доступ к функциональности службы обеспечивается посредством протоколов HTTP или HTTPS [1].
Для организации взаимодействия с Web-службой необходимо знать URI, получить XML-описание интерфейса и передавать/принимать сообщения HTTP (HTTPS), составленные в соответствии с описанием интерфейса. Язык реализации и платформа функционирования для Web-служб не регламентируются.
Механизм поиска и установления связи с конкретной Web-службой базируется на спецификации UDDI (Universal Description Discovery & Integration) и предполагает наличие UDDI-сервера, на котором развернута специальная
Web-служба, основные задачи которой: регистрация новых Web-служб и ответы на поисковые запросы о расположении служб с заданными атрибутами.
Различают два подхода к созданию Web-служб: REST и SOAP [2]. Подход REST (Representational State Transfer) ориентирован на передачу больших объемов статической информации, например HTML-страниц, PDF-документов, изображений и т. п., базируется на четырех методах GET/PUT/POST/DELETE протокола HTTP. Протокол SOAP (Simple Object Access Protocol) относится к классу RMI-протоколов (Remote Method Invocation) и позволяет удаленно вызвать методы объектов, существующих в контексте Web-службы. Для поддержки протокола SOAP используется описание программного интерфейса на языке WSDL (Web Services Description Language) [3], которое публикуется самой Web-службой. WSDL-описания используются для создания функционально-совместимых Web-служб и программ-клиентов, взаимодействующих с Web-службой.
Web-службы толерантны к разрывам сетевого соединения, так как не сохраняют информацию о сеансе связи с клиентом. Каждое новое сообщение требует установления нового соединения TCPIP, которое закрывается по завершении передачи сообщения. Такое поведение обладает преимуществами в условиях ненадежного канала связи (что очень актуально для мобильных узлов), но требует определенных накладных расходов для установления/разрыва соединения.
Архитектура SOA
Стандарты и технологии Web-служб послужили основой создания новой архитектуры распределенных информационно-вычислительных систем - SOA (Service-Oriented Architecture). Информационно-вычислительная система, построенная на принципах SOA, представляет собой совокупность слабо связанных Web-сервисов [4]. Часть сервисов относится к инфраструктуре системы (сервисы UDDI, сервисы централизованного контроля доступа, сервисы управления резервированием, очереди сообщений), а часть - к функциональности системы (информационные сервисы, вычислительные сервисы, сервисы сбора данных).
Приложения в SOA-системе разделяются на два вида: сервисы и клиенты сервисов. Сервисы регистрируются в UDDI-реестре на начальном этапе своего жизненного цикла, периодически уведомляют UDDI-сервис о продолжении своей
работы и дерегистрируются при завершении своего жизненного цикла. Доступ любого приложения к функциональности сервиса обеспечивается в три этапа: обнаружение нужного сервиса, проверка прав доступа приложения, установление прямого соединения с сервисом, которые выполняются с участием инфраструктурных сервисов. Все последующие взаимодействия приложения с сервисом производятся напрямую, без посредников. Сервисы могут выступать в качестве клиентов других сервисов, т. е. взаимодействовать друг с другом.
Сегодня SOA-архитектура широко применяется в корпоративных информационных системах. Такие крупные производители программного обеспечения, как Microsoft, IBM, Sun Microsystems, предлагают инструментарий для разработки и мониторинга SOA-систем.
SOA в робототехнике
Беспроводные мобильные системы связи, такие как Wi-Fi, Bluetooth, GSM, ZigBee [5] и др., привнесли в робототехнику возможность подключения мобильных роботов к глобальной и локальным информационным сетям. Возможность удаленного взаимодействия с мобильной робототехнической платформой традиционно используется для отладки встроенного ПО, удаленного управления и получения телеметрической информации. Интеграция робота в глобальную сеть существенно расширяет возможности как самого робота, так всей робототехнической системы.
С точки зрения организации информационного взаимодействия мобильная роботизированная платформа является рядовым вычислительным узлом и может взаимодействовать с другими вычислительными узлами посредством стандартизированных протоколов. Следовательно, на мобильной платформе, подключенной к Internet, могут быть развернуты Web-службы, которые, с одной стороны, взаимодействуют с аппаратными и программными ресурсами робота и, с другой стороны, доступны через Internet для программ мониторинга, управления и т. п. Такая архитектура робототехнической системы полностью соответствует SOA-подходу.
Рассмотрим несколько вариантов SОА-архитектур робототехнических систем:
I. Мобильная платформа оснащена системой электропитания, несколькими датчиками, навигационной системой, системой связи и микроконтроллером. Вычислительная мощность микроконтроллера невысока и не позволяет обеспечить автономное управление системами робота
для решения целевой задачи. В этом случае на мобильной платформе достаточно разместить сервисы, обеспечивающие включение/выключение исполнительных механизмов (эффекторов), съем данных с датчиков и навигационной системы, а система управления и алгоритмы обеспечения решения целевой задачи могут быть оформлены как в виде сервисов, так и в виде программ-клиентов и размещены на мощном компьютере.
II. Мобильная платформа оснащена системой электропитания, датчиками, навигационной системой, системой регистрации видеоинформации, системой связи и одним или несколькими высокопроизводительными процессорами. Бортовых вычислительных ресурсов достаточно для обеспечения автономности робота при выполнении целевой задачи. На мобильной платформе размещены как сервисы, обеспечивающие работу аппаратных средств, так и сервисы управления и алгоритмического обеспечения. На удаленном компьютере, играющем роль монитора телеметрии и пункта управления, функционирует программное обеспечение, позволяющее пользователям следить за ходом выполнения заданий и/или корректировать его.
III. Оснащение мобильной платформы соответствует вариантам I или II, на удаленной ПЭВМ размещен сервис, имитирующий окружающую робота обстановку, и соответствующие имитационные сервисы системы электропитания, датчиков навигационной системы и других систем робота, взаимодействующих напрямую с окружающей обстановкой. Данный вариант архитектуры позволяет отлаживать программное обеспечение управления и алгоритмы выполнения целевой задачи в условиях недоступности реального окружения, что актуально, например, для разработки встроенного ПО автономных подводных роботов или робо-тов-исследователей поверхности планет Солнечной системы. Переключение с имитационных сервисов на штатные производится изменением адресов URI.
IV. Оснащение мобильной платформы соответствует варианту II, но мобильная платформа не одна и сервисы различных роботов могут взаимодействовать друг с другом, определяя кооперативное поведение группы роботов при решении целевой задачи [6]. Примеры алгоритмов группового поведения: «Делай как я», «Здесь работаю я, исследуй соседнюю зону», «Цель обнаружена, все сюда».
Рассмотренные SOA-архитектуры робототехнических систем требуют обязательного наличия механизма обнаружения (discovery) мо-
бильных узлов в условиях динамической адресации. Такой механизм может быть реализован на базе UDDI-сервера (см. выше), имеющего статический URI и доступного для мобильных платформ. Каждый сервис робототехнической системы должен зарегистрироваться на UDDI-сервере при старте и уведомить сервер при завершении своей работы (дерегистрироваться).
Доступные программные инструменты и технологии
Преимущества архитектуры SOA для робототехнических систем были осознаны разработчиками и исследователями уже более 15 лет назад. На сегодня существует несколько коммерческих продуктов и некоммерческих проектов с открытым исходным кодом (open-source projects), успешно применяемых при создании мобильных роботов [7, 8]. Большинство робототехнических SOA-платформ базируется либо на собственных узкоспециализированных протоколах передачи данных через сокеты TCPIP, либо на платформах CORBA [9] или Ice [10]. Такие решения хорошо зарекомендовали себя в локальных сетях, но в глобальной информационной сети Internet применение данных платформ встречает серьезные препятствия, например наличие брэндмауэров. Только компания Microsoft предлагает комплексное решение для сети Internet - Microsoft Robotic Developer Studio [8], которое изначально базируется на коммуникационных протоколах Web-служб. Рассмотрим данный продукт более подробно.
В основе комплекта Microsoft Robotic Developer Studio две библиотеки - «Concurrency and Coordination Runtime» (CCR) и «Decentra-lized Software Services» (DSS). Обе библиотеки предназначены для создания распределенных приложений на платформе Microsoft .Net Framework [11].
Библиотека CCR предоставляет разработчику реализации входных/выходных очередей (портов) сообщений, посредством которых организуется асинхронное взаимодействие между распределенными объектами, арбитров, позволяющих управлять асинхронным взаимодействием, планировщиков параллельных задач. Архитектура распределенных систем базируется на принципах:
А) все взаимодействия между распределенными объектами производятся с помощью асинхронных сообщений, централизованного управления доставкой и обработкой сообщений нет;
Б) каждый вычислительный узел оснащен входными/выходными очередями сообщений;
В) арбитры извлекают сообщение из очереди (помещают сообщения в очередь) ориентируясь по атрибутам сообщений, вызывают пользовательские обработчики;
Г) планировщики задач обеспечивают пользовательским обработчикам конкурентный или приоритетный доступ к аппаратным ресурсам (датчикам, эффекторам, средствам коммуникации и др.).
Библиотека DSS представляет собой надстройку над CSS и реализует инфраструктуру Web-служб специального вида. Любая Web-служба, создаваемая на платформе Microsoft Robotic Developer Studio (MRDS), является SOAP-службой, интерфейс которой определен протоколом «Decentralized Software Services Protocol» (DSSP) [ll]. Хотя формально службы MRDS и относятся к классу SOAP-служб, но по логике функционирования это настоящие REST-службы, так как через протокол передаются описания состояния (state) службы, которые либо запрашиваются, либо передаются для установки (всего к командам HTTP определено 9 дополнительных команд). Сами состояния Web-службы протоколом DSSP не определяются, для их описания имеется специальный язык описания манифестов DSS. Манифесты создаются и распространяются вместе с Web-службами, в состав MRDS входит специальный инструмент для просмотра и редактирования манифестов.
Определение протокола DSSP [ll] позволяет создавать Web-службы с помощью не только инструментов Microsoft, но и альтернативного инструментария [l2, li]. Библиотеки DSS и CSS недоступны для встраиваемых систем, так как базируются на платформе Microsoft .Net Framework.
Современная робототехника немыслима без средств симуляции, позволяющих отлаживать программное обеспечение робототехнических систем без доступа к аппаратным средствам робота и вне реального окружения. На сегодня существует большое количество средств симуляции окружающей роботов обстановки и имитации работы аппаратуры (датчиков и эффекторов) роботизированной платформы [l4, lS]. Большинство таких средств позволяют описать окружающий робота мир (2D, iD), описать саму роботизированную платформу и «погрузить» модель платформы в модель окружающей обстановки. Модель платформы и модель мира исполняются обычно на одном компьютере, что не позволяет отлаживать встраиваемое ПО на настоящей аппаратной платформе, разместив модель мира на удаленном сервере.
В состав Microsoft Robotic Developer Studio входит среда Visual Simulation Environment, несколько кодогенераторов DSS-сервисов для Microsoft Visual Studio, манифесты DSS для таких популярных в робототехнике устройств, как дифференциальный колесный движитель, Web-камера, бампер, сонар и др. С помощью перечисленного программного обеспечения достаточно быстро можно смоделировать и виртуальное окружение, и модель роботизированной платформы. Отличительной особенностью Microsoft Robotic Developer Studio является то, что виртуальное окружение с точки зрения встроенного ПО робота тоже выглядит как Web-служба.
Структура робототехнической системы, построенной с помощью Microsoft Robotic Developer Studio, полностью соответствует принципам SOA - все элементы системы являются службами и могут функционировать в глобальной информационной сети. К недостаткам системы можно отнести:
А) сложность реализации DSS-служб для встраиваемых платформ (такая возможность в документации Microsoft Robotic Developer Studio не обсуждается), хотя большинство современных роботизированных платформ основываются на процессорах, которые не поддерживаются операционными системами семейства Microsoft Windows;
Б) излишнюю сложность идеологии REST на базе SOAP и DSS-манифестов, хотя для сходных задач повсеместно с успехом применяется SOAP и язык описания интерфейсов WSDL.
Кроме специализированных комплектов программного обеспечения, ориентированных непосредственно на задачи робототехники, для создания роботизированных SOA-систем могут быть применены средства для разработки встраиваемых Web-служб [12, 13].
Особенно выделяется программный комплекс gSOAP, разработанный и развиваемый в государственном университете штата Флорида [13]. Данный комплекс содержит:
A) библиотеку stdsoap2, обеспечивающую инфраструктуру для создания Web-служб;
Б) кодогенератор soapcpp2, генерирующий серверную и клиентскую части Web-служб;
B) кодогенератор wsdl2h, позволяющий создавать Web-службы на базе описаний интерфейса на языке WSDL.
Библиотека stdsoap2 поставляется в исходном коде и это единственный элемент системы, который обязательно нужно включить в состав создаваемой Web-службы. Таким образом, переносимость gSOAP на разные платформы оп-
ределяется переносимостью исходного кода stdsoap2. На сегодня известно о переносе этой библиотеки на платформы:
- семейства Microsoft Windows (2000, XP, Vista, Windows l);
- семейства Linux (RedHat, SuSE);
- семейства Unix (Solaris, HP-UX, FreeBSD, TRU64, Irix, AX);
- Mac OS X;
- встраиваемые платформы (VxWorks, QNX, WinCE, Palm OS, Symbian).
Для приложений робототехники особенно интересными являются примеры переноса gSOAP на встраиваемые платформы.
Кодогенератор soapcpp2 создает код серверной и клиентских частей на основе описания интерфейса Web-службы в форме заголовочного файла h-файла для языка C/C++. Сгенерированный серверный код можно использовать и как самостоятельное приложение-сервер, и как Web-службу под управлением таких популярных Web-серверов, как Apache и Microsoft Information Server [13]. С помощью параметров командной строки можно управлять кодогенератором, например разре-
шать/запрещать применение стандартной библиотеки С++, библиотеки STL, устанавливать тип протокола HTTP/HTTPS и т. п. Web-служба, создаваемая на базе результата кодо-генерации soapcpp2, может поддерживать и SOAP, и REST подходы.
С помощью кодогенератора wsdl2h можно создать Web-службу на базе существующего WSDL-описания. Например, в глобальной информационной сети существует некоторая SOAP-служба и необходимо создать Web-службу, реализующую интерфейс существующей службы (т. е. обеспечить совместимость с точки зрения клиентов Web-служб). Для этого необходимо запросить у существующей службы ее WSDL-описание с помощью HTTP-запроса GET, запустить кодогенератор wsdl2h с полученным WSDL-описанием в качестве параметра. Кодогенератор создаст h-файл c описанием интерфейса, который пригоден для кодогенератора soapcpp2.
Доступ к Web-службам на базе gSOAP может быть осуществлен как через клиентскую часть, сгенерированную soapcpp2, так и через созданную с помощью других инструментов, поддерживающих стандарты SOAP 1.1/1.2 и HTTP1.0/1.1. Примеры таких инструментов: Microsoft Visual Studio 2008, SUN JAX-WS. Таким образом, клиенты Web-служб на базе gSOAP не ограничены в выборе платформ и языков программирования.
Программные инструменты из состава gSOAP довольно широко применяются в робототехнике. Уже реализовано несколько роботизированных платформ, взаимодействующих с глобальной информационной системой Internet посредством функционирующих на самих роботах Web-служб [16].
Перспективы
Создание распределенных робототехнических систем на базе принципов SOA и протоколов Web-служб возможно в течение ближайших 3-5 лет. Для этого на сегодняшний день есть набор всех необходимых технологий и инструментов.
Многие существующие инструментальные средства, такие как ORCA [7], OROCOS [8] и др., будут адаптированы к работе в сети Internet посредством введения поддержки протоколов Web-служб.
Экспериментальные работы по созданию встраиваемых Web-служб для мобильных роботов приведут к появлению целого спектра REST-и SOAP-интерфейсов для систем датчиков и эффекторов робототехнических платформ. Кроме интерфейсов для аппаратной периферии платформ возможно появление интерфейсов для систем автономного управления. Вокруг таких интерфейсов сможет образоваться сообщество разработчиков совместимых программных систем. Например, группа, разрабатывающая мобильного робота X, публикует WSDL-интерфейсы дифференциальных приводов, контактных датчиков, сонара, навигационной системы и клиентскую программу для управления этой периферией. Другая группа может реализовать для своего робота Y Web-службы на базе опубликованных WSDL-описаний и воспользоваться программой управления для робота X. Таким образом, опубликованные WSDL-интерфейсы элементов роботов могут стать точками консолидации усилий различных робототехнических групп, в первую очередь университетских. Коммерческие организации смогут предложить профессиональные инструменты, ориентированные на популярные интерфейсы, которые станут сначала стандартами de facto, а потом и индустриальными стандартами.
Еще одним перспективным направлением представляется создание имитаторов окружающей роботов обстановки с интерфейсом в виде набора Web-служб. Появление таких систем мотивируется тем, что:
- мощности персональных компьютеров, на которых сейчас функционируют системы ими-
тации [10], недостаточно для адекватного моделирования таких физических эффектов, как трение, инерция, гидродинамическое сопротивление, волны в средах и др.;
- через глобальную сеть Метй доступны высокопроизводительные вычислительные системы, основная задача которых как раз и заключается в моделировании виртуального мира, в котором действуют физические законы реального.
Сценарий взаимодействия пользователей с такими сетевыми средствами имитации может выглядеть следующим образом:
A) пользователь формирует на специальном языке, например Х3Б [17], описание необходимой ему окружающей виртуальной обстановки и описание робота (геометрия, масса). Динамическое поведение обеспечивается назначением событиям в виртуальном мире, например столкновению робота с препятствием, обработчиков, взаимодействующих с Web-службами пользователя;
Б) пользователь регистрирует на сайте сетевой системы имитации свое описание и запускает имитацию;
B) в процессе имитации производится циклическая оценка инвариантов, которым назначены обработчики, в условиях изменения параметров модели со стороны программы пользователя. Пользователь может наблюдать результаты имитации «со стороны» с помощью интерактивного Web-интерфейса;
Г) изменение окружающей модель робота обстановки приводит к срабатыванию обработчиков, инициирующих обращения к Web-службам пользователя, которые он может наблюдать средствами отладки, индикации или др.;
Д) пользователь останавливает процесс имитации, освобождает ресурсы симулятора.
Заинтересованы в создании подобных систем эмуляции не только энтузиасты робототехники и учебные заведения, но и крупные производители суперкомпьютерных, кластерных вычислительных систем, разработчики средств моделирования 3Б-миров.
Заключение
Современный уровень развития средств коммуникации, аппаратного обеспечения встраиваемых систем, средств разработки распределенных программных систем, средств моделирования физического мира позволяет разработчикам робототехнических систем сделать качественный скачок в архитектуре и функциональности создаваемых ими систем.
Для сообщества исследователей и энтузиастов робототехники появляется техническая возможность консолидировать свои усилия на основе открытых стандартов, сформировавших глобальную информационную сеть Internet. Фактически Internet и Internet-технологии сегодня стали ресурсом, который определит в ближайшем будущем облик робототехники 20102020 гг. В первую очередь этим ресурсом должны воспользоваться научные и учебные организации, во вторую - коммерческие фирмы.
Список литературы
1. Дальви Д., Джоши Б. XML для разработчиков-профессионалов .NET. М.: Изд-во «Лори», 2003.
2. Черняк Л. SOAP и REST, вместе или порознь? // Открытые системы. 2003. № 9.
3. Ньюкомер Э. Веб-сервисы. XML, WSDL, SOAP и UDDI. Для профессионалов. СПб.: Издательский дом «Питер», 2007.
4. OASIS Reference Model for Service Oriented
Architecture 1.0 URL: http://www.oasis-open.org
/committees/download.php/19679/soa-rm-cs.pdf (дата обращения: 08.04.2010).
5. Bluetooth wireless for robots. URL: http://www. societyofrobots .com/ electronics_bluetooth_robot. shtml (дата обращения: 08.04.2010).
6. Amoretti M., Zanichelli F., Conte G. A Service-Oriented Approach for Building Autonomic Peer-to-Peer Robot Systems //Enabling Technologies: Infrastructure for Collaborative Enterprises. WETICE 2007. 16th IEEE International Workshops. 2007.
7. Open Robot Control Software. URL: http://www. orocos. org (дата обращения: 08.04.2010).
8. Microsoft Robotic Developer Studio. URL: http://www.microsoft.com/Robotics (дата обращения:
08.04.2010).
9. Orfali R., Harkey D. Edwards J. The Essential Distributed Objects Survival Guide. John Wiley & Sons, 1995.
10. Henning М. et al. Distributed Programming with Ice, ZeroC, 2003. URL: www.zeroc.com/Ice-Manual.pdf (дата обращения: 08.04.2010).
11. Frystyk H.N., Chrysanthakopoulos G. Decentralized Software Services Protocol - DSSP/1.0. URL: http:// purl. org/msrs/dssp.pdf (дата обращения: 08.04.2010).
12. Enhydra. ksoap. URL: http://ksoap.enhydra.org (дата обращения: 08.04.2010).
13. Engelen R. An XML Web Services Development
Environment for Embedded Devices. URL: http://www. cs.fsu.edu/~engelen/cases03.html (дата обращения:
08.04.2010).
14. Vaughan R.T., Gerkey B.P., Howard A. On Device Abstractions for Portable, Reusable Robot Code // Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2003), Las Vegas, Nevada, October, 2003.
15. The Player Project, Free Software Tools for Robot and Sensor Application. URL: http://playerstage. sourceforge.net (дата обращения: 08.04.2010).
16. Moritz G., Piter S., Timmermann D., Golatowski F. Real-Time Service-Oriented Communication Proto-
cols on Resource Constrained Devices // Proceedings of the International Multiconference on Computer Science and Information Technology. 2008.
17. ISO/IEC 19775-1.2:2008 — X3D Architecture and Base Components Edition 2.
WEB-SERVICES APPLICATION IN ROBOTICS
S.A. Mineyev
The problems of creation and maintenance of distributed computer complex functioning in the global information network are closely connected with those of mobile robotics. The paper focuses on the application of Web-services technology for the creation of robotic systems. Standards, available tools, problems and development prospects are discussed.
Keywords: Web-services, service-oriented architecture, distributed computer systems, mobile robots.
