2 Аналитический обзор информационных источников по технологии RESTful-веб-сервисов и их применения для построения распределенных инфраструктур 2.1 Общий подход к разработке распределенных инфраструктур: сервисно-ориентированная архитектура (SOA) 2.1.1 Базовые принципы SOA
Общей основой построения грида является клиент-серверная архитектура. В соответствии с принципом виртуализации ресурсов, - доступ не к серверам, а к сервисам - более точным базовым принципом построения грида является сервисно-ориентированная архитектура (service-oriented architecture, SOA) при которой в качестве услуг предоставляются функциональные возможности, с дополнительным акцентом на слабые связи между взаимодействующими сервисами [2-1]. Сервис (служба) - программный компонент, к которому можно удаленно обратиться посредством компьютерной сети, и предоставляющий некоторые функциональные возможности запрашивающей стороне. Таким образом, SOA это архитектурный стиль, который подчеркивает реализацию компонентов системы как модульных сервисов, которые могут быть обнаружены, идентифицированы и использованы клиентами. Сервисы должны иметь следующие характеристики [2-2]:
Сервисы могут быть полезными каждый сам по себе, или они могут быть объединены, чтобы предоставить единый высокоуровневый сервис. Среди других достоинств, это позволяет многократно использовать уже существующие функциональные возможности.
Сервисы общаются со своими клиентами, обмениваясь сообщениями: фактически, сервисы и различаются/идентифицируются в соответствии с совокупностью сообщений, которые они могут принять и ответов, которые они могут направить запрашивающей стороне.
Сервис может участвовать в таких процессах обработки запросов, при которых порядок, в котором сообщения посылаются и принимаются, влияет на результат операций, выполненных сервисом. Это называется "сервисной хореографией" (service choreography) [2-3].
Сервис может быть полностью независимым, или может зависеть от существования других сервисов, или каких-либо ресурсов, например, баз данных.
Сервисы предоставляют информацию о своих возможностях, интерфейсах, политике и поддерживаемых протоколах связи. Детали реализации, например, язык программирования и платформа, на которой он реализован, не нужны клиентам для направления запросов и не предоставляются.
Рисунок 2.1 иллюстрирует простой цикл взаимодействия сервисов, который начинается с того, что данный сервис оповещает о своем существовании и свойствах посредством известного сервиса регистрации (1), свойства и способы взаимодействия с которым должны быть заранее известны клиентам.
Рисунок 2.1 - Взаимодействие сервисов в SOA-среде
Потенциальный клиент, который может быть другим сервисом (или человеком), делает запрос в сервис регистрации (2), чтобы найти сервис, который удовлетворяет его потребностям. Регистрационный сервис возвращает (возможно пустой) список подходящих сервисов; клиент выбирает один из них и передает ему запрос, а сервис отвечает, передавая или результат требуемой операции или сообщение об ошибке (3). При этом они используют любой взаимно распознаваемый протокол. На рисунке показан самый простой случай. В реальной установке процесс может быть значительно более сложным. Например, данный сервис может поддержать только HTTPS протокол, обслуживать только зарегистрированных пользователей, предлагать различные уровни сервиса различным пользователям, или требовать оплаты за использование. Представленный иллюстративный пример соответствует простому синхронному, двунаправленному способу обмена сообщениями, в то время как в реальной жизни взаимодействие может быть односторонним, или ответ может быть получен не от того сервиса, которому клиент посылал запрос, но от некоторого другого, которому он был передан для завершения обработки.
2.1.2 Веб-сервисная технология
Основным средством построения систем на основе SOA являются веб-сервисы. SOA и веб-сервисы являются взаимно дополняющими понятиями: сервисная ориентация – это архитектурный стиль, а веб-сервисы - технология выполнения. Веб-сервисы (или веб-службы) – это распределенные программные компоненты, идентифицируемые своим сетевым адресом и описанным интерфейсом. Другие программные системы могут взаимодействовать с веб-сервисами согласно этому описанию посредством сообщений, передаваемых с помощью интернет-протоколов. Одним из наиболее распространенных языков описания интерфейсов веб-сервисов является языка WSDL (Web Service Description Language), созданный на основе XML (eXtensible Markup Language), а сообщения формируются на другом «диалекте» XML - SOAP (обзор стандартных технологий веб-сервисов можно найти, например, в [2-3]).
Веб-сервисы предоставляют детальную информацию об их функциях и о интерфейсах, но не о деталях реализации и платформе; таким образом клиент и сервис, которые поддерживают общие протоколы коммуникации, могут взаимодействовать независимо от платформ, на которых они выполняются или языков программирования, на которых они написаны. Это делает веб-сервисы особенно подходящими для распределенной гетерогенной среды.
Хотя веб-сервисы, вообще говоря, могут использовать разные транспортные протоколы, и даже могут предлагать клиентам выбор, самым распространенным является SOAP поверх протоколов HTTP или HTTPS. Это важно поскольку использование HTTP и HTTPS обычно не вызывает проблем совместимости с системами сетевой защиты в организациях, которые разрешают двунаправленный трафик HTTP.
При построении распределенных инфраструктур важно, что веб-сервис может быть спроектирован так, чтобы "представлять" специфическое устройство или обычное приложение, принимая запросы управления и контроля через стандартизированные интерфейсы, с ресурсом общаясь посредством его «родного» интерфейса, и возвращая результат запрашивающей стороне опять в стандартном формате. Рисунок 2.2 иллюстрирует, каким образом единая консоль может управлять совокупностью разнообразных ресурсов посредством уровня виртуализации на основе веб-сервисов.
Рисунок 2.2 - Виртуализация ресурсов с помощью веб-сервисов
В 90-е годы прошлого и в первые годы XXI века распределенные инфраструктуры для научных исследований создавались практически исключительно на базе грид-систем. Работа грид-систем опирается на программное обеспечение промежуточного уровня: программные компоненты и протоколы, которые обеспечивают требуемый контролируемый доступ к ресурсам. Причем на первом этапе своего существования грид-системы строились или на основе специально разработанных общедоступных компонент или на основе закрытых (проприетарных) технологий. Хотя различные общественные и коммерческие решения были успешны в своих областях применения грида, каждое со своими сильными и слабыми сторонами, они имели ограниченный потенциал как основы для грида нового поколения, который должен быть масштабируемым и интероперабельным, чтобы удовлетворять потребности широкомасштабных научных и производственных проектов.
В последние годы стало ясно, что есть значительное перекрытие между целями вычислительного грида и преимуществ сред, основанных на SOA и веб-сервисах. Быстрый прогресс в технологии веб-сервисов и разработке соответствующих стандартов обеспечили эволюционный путь от жесткой и узко-направленной архитектуры грид-систем первого поколения к стандартизированным, сервис-ориентированным распределенным инфраструктурам, гарантирующим стабильно-высокое качество обслуживания пользователей.
На рис. 2.3 схематично представлен простая сервисно-ориентированная инфраструктура, в котором сервисы используется и для виртуализации ресурсов, и для обеспечения других функциональных возможностей.
На схеме показана единая консоль и для запуска заданий и управления распределенными ресурсами. Программное обеспечение интерфейса пользователя (консоли) обращается к сервису регистрации, чтобы получить информацию о существующих грид-ресурсах. Затем пользователь посредством консоли входит в контакт с сервисами, «представляющими» (виртуализирующими) каждый ресурс, чтобы запросить периодическое получение данных о работе ресурсов и получение извещений о существенных изменениях в их состоянии (например, если ресурс становится недоступным или сильно загруженным).
Рисунок 2.3 - Упрощенная схема сервисно-ориентированной распределенной инфраструктуры
Пользователь направляет запрос на запуск задания в службу запуска, которая передает запрос службе распределения заданий (часто называемой планировщиком). Служба распределения контактирует со службой, представляющей приложение, и запрашивает информацию о требованиях к ресурсам для выполнения задания. Затем служба распределения запрашивает у службы регистрации информацию о всех подходящих ресурсах в гриде и напрямую контактирует с ними, чтобы убедиться в их доступности. Если подходящие ресурсы доступны, планировщик выбирает наилучшую доступную совокупность ресурсов и передает информацию о их сервису приложения с запросом на начало выполнения. В противном случае планировщик ставит задание в очередь и выполняет его, когда необходимые ресурсы становятся доступными. Когда выполнение задания заканчивается, сервис приложения сообщает о результате планировщику, который извещает об этом сервис запуска заданий. Сервис запуска заданий, в свою очередь, уведомляет пользователя.
Отметим, что эта общая схема сильно упрощена: функционирование реальной распределенной инфраструктуры даже с ограниченной функциональностью является намного более сложным, чем показано на схеме.
2.1.3 Использование принципов SOA для построения распределенной инфраструктуры: открытая архитектура грид-сервисов (OGSA)
Конвергенция SOA и вычислительных грид-систем воплощена Глобальным грид-форумом (GGF) в Открытой архитектуре грид-сервисов (Open Grid services Architecture, OGSA). Основной документ [2-4], фиксирующий архитектуру OGSA, описывает общие принципы построения сервисно-ориентированного грида в терминах необходимых функциональных возможностей, например, выполнение заданий, управление ресурсами и данными, обеспечение безопасности. Основной целью этого и других документов, посвященных OGSA (см. [2-5]), является стандартизация интерфейсов и поведения основного (базового) набора грид-сервисов, чтобы они могли взаимодействовать как друг с другом, так и с распределенными приложениями независимо от конкретных реализаций таких сервисов. OGSA, в частности,
определяет стандартные механизмы для создания, именования и обнаружения постоянных и временных экземпляров сервисов;
обеспечивает прозрачность местонахождения и взаимодействия по различным протоколам для экземпляров сервисов;
описывает общую модель ресурсов, которая представляет собой абстрактное представление как физических ресурсов (таких как процессоры, процессы, диски и файловые системы), так и логических (экземпляров сервисов).
Для понимания терминологии необходимо отметить, что в рамках OGSA различают общее понятие сервиса и понятие экземпляра сервиса. Сервис - это абстрактное понятие, он определяется своим интерфейсом и способом взаимодействия с другими сервисами. При этом не имеется в виду, что сервис обязательно как-то реализован и реально функционирует. Напротив, реально функционирующий сервис является экземпляром того или иного сервиса.
При разработке OGSA учитывался ряд требований, полученных в результате анализа различных сценариев использования грид-систем, в том числе:
интероперабельность (виртуализация ресурсов, общие способы управления и обнаружение ресурсов, стандартизация протоколов);
разделяемый доступ к ресурсам;
оптимизация выделения ресурсов;
возможность запуска заданий на удаленных вычислителях;
возможность манипуляции данными;
снижение стоимости администрирования больших гетерогенных систем;
безопасность (аутентификация и авторизация, возможность интеграции с различными системами безопасности, делегирование прав)
надежность;
гарантии качества обслуживания;
простота использования и расширяемость (возможность расширения спектра применения);
масштабируемость (отсутствие узких мест, препятствующих наращиванию объема ресурсов).
OGSA определяет грид-сервис как веб-сервис, который предоставляет набор корректно определенных интерфейсов и следует специфическим конвенциям для их создания и композиции сложных распределенных систем. Интерфейсы определяют способы обнаружения, динамического создания службы, управления жизненным циклом, уведомления, управляемости. Конвенции определяют способ именования и возможность модернизации грид-служб. OGSA также определяет механизмы обновления «знаний» клиента о службе, в том числе, о поддерживаемых ею операциях и сетевых протоколах, которые клиент может использовать для связи с этой службой.
В отличие от традиционных веб-сервисов, которые позволяют обнаруживать и инициировать только постоянные службы, OGSA также предусматривает поддержку временных экземпляров сервисов, инициируемых и завершаемых динамически (например, временный экземпляр службы может быть создан для обращения к хранилищу данных, для резервирования сетевых или процессорных ресурсов). OGSA описывает как создается грид-служба, как называется, как определено ее время жизни и т.д. OGSA предписывает базовое поведение, но не определяет конфигурацию службы и ее развертывание в грид-инфраструктуре. Другими словами, OGSA не касается вопросов реализации, парадигмы программирования, конкретных языков, механизмов и инструментальных средств реализации или операционной среды.
Таким образом, грид-сервис — это (возможно временная) служба на базе грид-протоколов с корректно описанным интерфейсом или набором интерфейсов. Каждый интерфейс грид-службы определяет набор операций, которые инициируются путем передачи соответствующей последовательности сообщений.
Ориентация на службы разделяет задачу интероперабельности на две подзадачи: определение интерфейсов служб и выбор протоколов, которые могут вызывать конкретный интерфейс. Ориентированное на службы представление решает вопросы, связанные с потребностью в стандартных механизмах определения интерфейсов, локальной и удаленной прозрачности, адаптации к локальным службам ОС и единообразной семантике. Такое представление также упрощает виртуализацию за счет объединения разнородных реализаций под общим интерфейсом.
2.1.3.1 Виртуализация
Виртуализация поддерживает согласованный доступ к ресурсам на множестве гетерогенных платформ. Виртуализация также позволяет определять отображение множества логических экземпляров ресурсов на один и тот же физический и помогает управлению ресурсами в ВО, обеспечивая композицию из ресурсов более низкого уровня. Более того, виртуализация дает возможность объединять базовые службы и формировать более сложные службы.
Виртуализация грид-служб позволяет легко отображать общее семантическое поведение служб на оригинальные механизмы платформы. Такая виртуализация становится проще, если выразить функции службы в стандартной форме, чтобы любые реализации службы вызывались одинаковым образом. Для этой цели выбран WSDL, язык описания Web-служб. WSDL проводит различие между определением интерфейсов служб и связываниями протоколов, используемых для вызова служб; один интерфейс может иметь несколько вариантов связываний, в том числе и распределенные протоколы (такие, как HTTP), и локальные связывания (например, средства межпроцессного взаимодействия, предусмотренные локальной ОС).
Характеристиками связываний являются надежность и иные формы QoS, а также аутентификация и делегирование полномочий. Выбор связываний всегда должен быть прозрачным для инициатора запроса в том, что касается семантики вызова служб, но не в других отношениях. К примеру, инициатор запроса должен иметь возможность выбрать конкретное связывание из соображений производительности.
Определение интерфейса службы и связывания отделены от реализации службы. Служба может поддерживать несколько реализаций на различных платформах. Например, в зависимости от платформы и контекста можно использовать следующие подходы к реализации:
создать эталонную реализацию для обеспечения полной переносимости между различными платформами для поддержки сред исполнения, предназначенных для хостинга службы;
использовать наличие на платформе специализированных оригинальных механизмов для отображения на них функциональности службы из определения интерфейса службы;
применять эти механизмы рекурсивно, создавая службу более высокого уровня из нескольких служб более низкого уровня, которые сами могут либо отображаться на оригинальные механизмы, либо выполнять дальнейшую декомпозицию.
Предлагаемая архитектура обладает локальной и удаленной прозрачностью в отношении местонахождения и вызова служб. Она также предоставляет многочисленные связывания для выполнения локальной оптимизации вызова служб с участием инициатора вызова. Кроме того, она поддерживает «переговоры» между протоколами сетевых потоков с тем, чтобы предоставить возможность выбора между несколькими протоколами, каждый из которых оптимизирован для определенной цели. Наконец, реализация конкретного интерфейса грид-службы может отображаться на оригинальные функции и возможности платформы.
2.1.3.2 Семантика грид-служб
Возможность виртуализировать и комбинировать службы зависит не только от определения стандартных интерфейсов. Необходима также стандартная семантика для взаимодействия служб, например, единые механизмы обнаружения свойств служб. С этой точки зрения, OGSA определяет грид-службу как веб-службу, предоставляющую множество специфицированных интерфейсов и поддерживающую специфицированные соглашения. Интерфейсы касаются вопросов, связанных с обнаружением службы, ее динамическим созданием, управлением жизненным циклом, уведомлением и управляемостью. Соглашения касаются именования и модернизируемости грид-службы, а также охватывают вопросы авторизации и контроля одновременного использования. Этот базовый набор согласованных интерфейсов, на основе которого реализуются все службы, поддерживает создание иерархических служб более высокого порядка, которые могут одинаковым образом восприниматься на всех уровнях абстракции.
Каждую грид-службу определяет набор интерфейсов, сконфигурированный как WSDL portType. Служба должна поддерживать интерфейс GridService; кроме того, OGSA определяет множество других интерфейсов для уведомления и создания экземпляров. Конечно, пользователи также определяют произвольные, ориентированные на конкретное приложение интерфейсы. Элемент расширения WSDL serviceType определяют множество типов portType, которое поддерживает службы грид вместе с некоторой дополнительной информацией, касающейся отслеживания версий.
С каждым интерфейсом связан потенциально меняющийся набор элементов данных службы — элементов XML, имеющих имя и тип и инкапсулированных в стандартный формат контейнеров. Элементы данных службы определяют стандартное представление для информирования об экземплярах грид-служб. Этот важный аспект модели OGSA формирует основу для обнаружения и управления потенциально меняющимися свойствами служб. Наконец, пользователи могут самыми разными способами реализовать конкретную службу, как определено ее интерфейсами и связанными элементами, и размещать ее в различных средах.
Участники ВО зачастую хотят реализовать новые временные экземпляры службы динамически для поддержки конкретной затребованной функциональности. Когда эта функциональность больше не требуется, службу можно удалить. Например, в системе видеоконференций организация сеанса может включать в себя создание экземпляров службы в промежуточных точках для сквозного управления потоками данных в соответствии с ограничениями, накладываемыми соглашением об уровне обслуживания. Среды веб-служб могут реализовать службы динамически для того, чтобы обеспечить пользователям надежное время ответа, управляя рабочей нагрузкой за счет динамического добавления «обрабатывающих узлов». Другие примеры деятельности, которые можно представить и управлять как временным экземпляром службы: запрос к базе данных, операция добычи данных, резервирование полосы пропускания сети, передача данных.
Поскольку грид-службы динамические и сохраняют свое состояние, необходим способ, позволяющий отличать один динамически создаваемый экземпляр службы от другого. Для этого каждый экземпляр службы получает глобально уникальное имя — дескриптор.
WSDL позволяет определять несколько связываний протоколов для конкретного интерфейса. От варианта связывания может зависеть такое свойство, как надежность. Службы взаимодействуют друг с другом путем обмена сообщениями. В распределенных системах, в которых случаются сбои отдельных компонентов, однако никогда не удастся гарантировать доставку отправленного приложения. Поддержка внутреннего состояния может стать гарантией того, что служба получает сообщение лишь однажды или не получает его вовсе, даже при использовании таких механизмов, как повторная передача. В подобных ситуациях может потребоваться использование протокола, который гарантирует одноразовую доставку или аналогичную семантику, точно так же, как и поддержка связывания протокола для взаимной аутентификации при соединении.
2.1.3.3 Стандартные интерфейсы
OGSA определяет стандартное поведение и соответствующие интерфейсы.
Обнаружение. Приложениям необходим механизм для обнаружения доступных служб, определения их характеристик и конфигурирования своих запросов к этим службам. Помимо элементов данных службы, определяющих стандартное представление информации об экземплярах службы, OGSA предлагает стандартную операцию FindServiceData, которая извлекает информацию о службе из конкретных экземпляров грид-службы, и стандартный интерфейс для информации о регистрации экземпляров службы.
Динамическое создание службы. Возможность динамического создания новых экземпляров службы и управления ими требует использования средств создания службы. OGSA устанавливает стандартный интерфейс Factory и стандартную семантику службы.
Управление жизненным циклом. Службы OGSA могут создаваться и уничтожаться динамически. Их можно удалять явно; они также могут быть удалены или стать недоступными из-за возникновения системной ошибки, например, в случае сбоя в операционной системе. Интерфейсы определяются для управления жизненным циклом службы и, в частности, для восстановления служб и состояния, связанных с неудавшимися операциями. Например, окончание сеанса видеоконференции может также потребовать завершения служб, созданных в промежуточных точках для управления потоками. OGSA выполняет это требования, определяя стандартную операцию SetTerminationTime в интерфейсе GridService, необходимом для поддержки состояния при управлении жизненным циклом экземпляров службы. Протоколы с поддержкой состояния позволяют OGSA в конце концов аннулировать состояние, установленное в удаленной системе, если поток последовательных восстанавливающих сообщений не обновит его. Интерфейс GridService также определяет операцию ExplicitDestruction.
Уведомление. Набор динамических, распределенных служб должен иметь возможность асинхронно уведомлять друг друга о серьезных изменениях своего состояния. OGSA определяет общие абстракции и интерфейсы служб для подписки на такие уведомления и для их доставки. Благодаря этому службы, созданные как композиция более простых служб, могут стандартным образом работать с уведомлениями, к примеру, с уведомлениями об ошибках. Специализированные связывания протоколов позволяют уведомлениям OGSA использовать различные (в том числе, коммерчески доступные) системы передачи сообщений для доставки сообщений с уведомлениями в соответствии с определенным QoS.
Управляемость. В производственных средах, возможно, потребуется выполнять мониторинг больших наборов экземпляров грид-служб и управлять ими. Соответствующие операции определяет интерфейс управляемости.
2.1.3.4 Среды исполнения
На практике веб-службы выполняются конкретной средой исполнения. Эта среда определяет не только программную модель реализации, язык, средства разработки и отладки, но также и то, каким именно образом реализуется семантика службы.
Реализовывать веб-службы могут и более сложные среды исполнения на базе контейнеров или компонентов: J2EE, IBM WebSphere, .Net и Sun ONE. Внутри таких сред определяется оболочка, которая используется для реализации и создания компонентов, соответствующих устанавливаемым средой интерфейсам для создания сложных приложений. По сравнению с низкоуровневой функциональностью, которую предлагают базовые среды исполнения, контейнерные или компонентные среды, как правило, предлагают значительную программируемость, управляемость, гибкость и безопасность. Как следствие, они весьма популярны для создания служб электронной коммерции.
В контексте OGSA контейнер гарантирует, что службы, которые он поддерживает, соответствуют семантике грид-служб, а также берет на себя некоторые служебные функции, освобождая от заботы о них того, кто реализует службу.
Определяя семантику службы, OGSA указывает взаимодействия между службами независимо от среды исполнения. Однако определение базовых характеристик, которые должны поддерживать все среды исполнения может помочь созданию служб:
отображение общих для грид имен, или дескрипторов служб, на элементы, специфические для реализации, такие как указатели Си и ссылки на объекты Java;
диспетчеризация вызовов грид и уведомлений в специфические для реализации действия, такие как события и вызовы процедур;
обработка протоколов и форматирование данных для передачи по сети;
управление жизненным циклом экземпляров служб;
аутентификация между службами.
Важное следствие поддержки виртуализации в OGSA заключается в том, что пользователь не должен знать о том, как конкретная среда исполнения реализует поведение и интерфейсы OGSA. Простая среда исполнения, виртуальная среда исполнения и коллективные службы могут реализовывать одни и те же интерфейсы.
Простая среда исполнения. Простая среда исполнения предоставляет набор ресурсов, размещенных внутри одной организации. Он поддерживает базовые механизмы управления службами, такие как сервер приложений на базе J2EE, .Net или Linux-кластер. В OGSA интерфейс такой среды, как правило, будет структурирован — реестр, одна или несколько «фабрик» (factory) и модуль handleMapper, отвечающий за определение соответствия между глобально уникальным дескриптором грид-службы и информацией о связывании. Каждая фабрика занесена в реестр, что позволяет клиентам обнаруживать имеющиеся фабрики.
Виртуальная среда исполнения. В более сложных средах ресурсы, связанные с ВО, будут охватывать гетерогенные, географически распределенные среды исполнения. Тем не менее, виртуальная среда исполнения, которая может, к примеру, соответствовать набору ресурсов, предоставляемых в рамках B2B-взаимодействия, может быть открыта клиенту для доступа через точно такие же интерфейсы, как и для простой среды исполнения.
Коллективные службы. Можно также создать виртуальную среду исполнения, которая предоставляет участникам ВО более сложные виртуальные, коллективные или комплексные (сквозные) службы. В этом случае реестр отслеживает и «рекламирует» фабрики, которые создают экземпляры служб более высокого уровня. Такие экземпляры реализуются путем обращения к фабрикам более низкого уровня для создания множества экземпляров служб и за счет объединения поведения этих экземпляров в единый экземпляр службы более высокого уровня.
Таким образом, службы и абстракции OGSA предлагают строительные блоки, которые разработчики могут применять для реализации множества грид-служб более высокого уровня, например, для управления данными и ресурсами.
|
