Принципы и средства реализации проблемно-ориентированных вычислительных сервисов

Принципы и средства реализации проблемно-ориентированных вычислительных сервисов

О.В. Сухорослов, ИСА РАН, с.н.с., os@isa.ru

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

Введение

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

Предлагаемый подход, охватывающий фактически все этапы научных исследований, состоит в построении распределенных вычислительных сред нового поколения, предоставляющих доступ к проблемно-ориентированным сервисам и образующих универсальную инфраструктуру для научной кооперации [1]. Данная инфраструктура базируется на сервис-ориентированном подходе: пользователи преобразуют свои приложения в удаленно доступные сервисы, которые могут быть обнаружены и использованы другими пользователями для решения интересующих их задач.

Актуальность данного направления исследований подтверждается сформулированной в 2005 году концепцией «сервис-ориентированной науки» (Service-Oriented Science) [2], автором которой выступил Иэн

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

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

• унификация и обеспечение интероперабельности сервисов на уровне протоколов, интерфейсов, форматов и семантики данных;

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

• снижение технологического барьера для потенциальных разработчиков сервисов за счет упрощения процедур создания и размещения сервисов в сети;

• обеспечение масштабируемости сервисов, в том числе за счет динамического подключения внешних вычислительных ресурсов;

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

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

В статье рассматриваются принципы и средства реализации проблемно-ориентированных вычислительных сервисов в рамках инструментария WebSolve. Отличительными особенностями инструментария являются использование открытых Web-технологий на основе архитектурного стиля REST, удобство преобразования в сервисы

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

Проблемно-ориентированный вычислительный сервис

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

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

Отметим, что описанная модель является довольно общей и может быть, вообще говоря, применена к большому классу сервисов, не обязательно предоставляющих доступ к вычислительным алгоритмам. В частности, это могут быть сервисы доступа к базам данных или сервисы, осуществляющие обработку и преобразование данных. В общем случае, речь может идти о произвольном программном компоненте, оформленном в виде сервиса. Тем не менее, инструментарий WebSolve ориентирован в первую очередь на создание сервисов для решения научных и прикладных вычислительных задач. Рассмотрим характерные особенности вычислительных сервисов.

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

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

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

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

Для упрощения повторного использования и композиции сервисов в рамках различных приложений требуется унификация механизма удаленного доступа к сервисам на уровне протоколов и форматов данных. В качестве базовой платформы для организации удаленного доступа к сервисам инструментарий WebSolve использует протокол HTTP и другие Web-технологии, основанные на архитектурном стиле REST (Representational State Transfer) [3]. В рамках инструментария разработан и подробно описан унифицированный REST-интерфейс [4], который должны реализовывать сервисы среды. Разработанный интерфейс учитывает характерные особенности вычислительных сервисов, такие как длительная обработка запросов и передача больших объемов данных в виде файлов. Также в соответствии с сервис-ориентированным подходом разработанный интерфейс поддерживает интроспекцию, т.е. получение информации о сервисе. Выбранные базовые технологии допускают независимые реализации описанного интерфейса на различных языках программирования. При этом детали реализации сервиса остаются полностью на усмотрение его разработчика.

Контейнер сервисов Everest

Наличие готового и простого в использования инструмента для создания сервисов очень важно с точки зрения расширения круга

потенциальных разработчиков сервисов. Для упрощения процесса разработки сервисов в рамках инструментария WebSolve реализован контейнер сервисов Everest. Данный контейнер представляет собой универсальную среду выполнения сервисов, реализующую упомянутый выше унифицированный REST-интерфейс вычислительного сервиса.

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

Everest реализован на языке Java, на базе библиотеки Jersey, являющейся, в свою очередь, открытой эталонной реализацией спецификации JAX-RS (Java API for RESTful Web Services). На Рис. 1 изображена архитектура Everest. Взаимодействие с клиентами осуществляется с помощью встроенного в контейнер Web-сервера Jetty. Входящие HTTP-запросы передаются библиотеке Jersey и, затем, реализации Everest. Обмен данными между клиентскими приложениями и сервисами осуществляется в форматах JSON (при доступе через REST-интерфейс) и HTML (при доступе через веб-браузер).

Рис. 1. Архитектура контейнера сервисов Everest

Контейнер осуществляет обработку запросов клиентов в соответствии с конфигурационной информацией. Данная информация

считывается при запуске сервера из текстовых дескрипторов сервисов. Дескриптор сервиса состоит из двух частей:

• внешнее описание сервиса, передаваемое клиентам (текстовая аннотация сервиса, декларации входных и выходных параметров);

• внутренняя конфигурация сервиса, содержащая информацию о реализации сервиса (адаптер и его конфигурационные параметры). Каждый размещенный в контейнере сервис становится доступным

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

Компонент JobManager осуществляет управление обработкой запросов к сервисам. Запросы преобразуются в задания и размещаются в очереди, откуда затем извлекаются конфигурируемым пулом потоков-обработчиков. При выполнении задания поток-обработчик вызывает тот или иной адаптер, в соответствии с внутренней конфигурацией сервиса.

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

В настоящее время реализовано четыре универсальных адаптера, поддерживающих интеграцию следующих типов приложений:

• приложение с интерфейсом командной строки (адаптер Command);

• приложение на языке Java (адаптер Java);

• задание, запускаемое на вычислительном кластере через систему очередей PBS/Torque (адаптер Cluster);

• грид-задание, запускаемое в инфраструктуре EGI (адаптер Grid). Адаптер Command осуществляет преобразование запроса к сервису в

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

Адаптер Java осуществляет вызов заданного Java-класса в рамках текущей виртуальной машины, передавая в вызове параметры запроса к сервису. Используемый Java-класс должен реализовывать стандартный

программный интерфейс. Во внутренней конфигурации сервиса требуется указать имя соответствующего Java-класса.

Адаптер Cluster осуществляет преобразование запроса к сервису в запуск вычислительного задания на кластере под управлением системы очередей PBS/TORQUE. Данный адаптер может использоваться, например, для преобразования в сервис существующего параллельного приложения. Во внутренней конфигурации сервиса требуется указать путь к файлу с шаблоном вычислительного задания, а также информацию об отображении параметров сервиса в аргументы и файлы задания.

Адаптер Grid осуществляет преобразование запроса к сервису в запуск вычислительного задания в грид-инфраструктуре, основанной на ПО gLite (например, European Grid Infrastructure). Данный адаптер может использоваться как для преобразования в сервис существующего грид-приложения, так и для переноса существующей реализации сервиса в грид, например, из соображений производительности и масштабируемости. Во внутренней конфигурации сервиса требуется указать виртуальную организацию грид, путь к файлу с шаблоном грид-задания в формате JD, а также информацию об отображении параметров сервиса в аргументы и файлы грид-задания.

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

Механизм безопасности

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

Реализованный в WebSolve механизм безопасности соответствует современному подходу к обеспечению безопасности в Web/грид-системах и основан на использовании инфраструктуры шифрования с открытым ключом, сертификатов стандарта X.509 и протокола TLS/SSL.

Субъектами безопасности в рамках WebSolve являются пользователи и серверы, на которых функционируют сервисы, а объектами безопасности - сервисы. Каждый пользователь и сервер имеет цифровой сертификат формата X.509, подписанный некоторым удостоверяющим

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

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

Взаимная аутентификация взаимодействующих субъектов осуществляется с помощью протокола TLS/SSL и расширения HTTPS. При установлении SSL-соединения клиент и сервер обмениваются своими сертификатами и производят проверку чужих сертификатов.

В целях упрощения доступа пользователей к сервисам также предусмотрен способ аутентификации пользователей при помощи публичных провайдеров учетных записей и протокола OpenID. Данный способ доступен только при доступе к сервису через веб-браузер.

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

Заключение

В статье рассмотрены принципы и средства реализации проблемно-ориентированных вычислительных сервисов в рамках инструментария WebSolve. Разработанный на основе архитектурного стиля REST интерфейс WebSolve-сервиса учитывает характерные особенности вычислительных сервисов, такие как длительная обработка запросов и передача больших объемов данных в виде файлов. Для упрощения процесса разработки вычислительных сервисов реализован универсальный контейнер сервисов, позволяющий быстро, без написания дополнительного программного кода, преобразовать в сервисы широкий спектр существующих приложений. Реализованный в контейнере механизм адаптеров позволяет подключать произвольные реализации обработчиков запросов к сервису. В частности, путем трансляции запроса в вычислительное задание, на уровне адаптера может быть реализован доступ к различным видам вычислительных ресурсов. Данный механизм позволяет упростить процесс преобразования в сервисы существующих параллельных и грид-приложений, а также перенос реализации сервиса на новую вычислительную инфраструктуру.

Литература

1. Астафьев А.С., Афанасьев А.П., Лазарев И.В., Сухорослов О.В., Тарасов А.С. Научная сервис-ориентированная среда на основе технологий Web и распределенных вычислений. // Научный сервис в сети Интернет: масштабируемость, параллельность, эффективность: Труды Всероссийской

суперкомпьютерной конференции (21-26 сентября 2009 г., г. Новороссийск). Москва: Изд-во МГУ, 2009. С. 463-467.

2. Foster I. Service-Oriented Science // Science. 2005. Vol. 308, No. 5723. P. 814817.

3. Fielding, R.T. Architectural styles and the design of network-based software architectures. PhD Dissertation. Dept. of Information and Computer Science, University of California, Irvine, 2000.

4. Сухорослов О.В. Унифицированный интерфейс доступа к алгоритмическим сервисам в Web. // Проблемы вычислений в распределенной среде / Под ред. С.В. Емельянова, А.П. Афанасьева. Труды ИСА РАН, Т. 46. Москва: КРАСАНД, 2009. C. 60-82.