Продолжающаяся децентрализация компьютерных систем, несмотря на всю их разнородность, требует определенного качества обслуживания (quality of service, QoS), обеспечиваемых динамически объединяемыми ресурсами предприятий и поставщиков услуг.

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

Такой подход предъявляет новые требования к разработке и развертыванию распределенных приложений. Сейчас разработчики приложений и программного обеспечения промежуточного слоя, как правило, ориентируются на конкретную платформу (будь то Windows NT, Unix, мэйнфрейм, J2EE или .Net). Такие платформы предлагают разнообразные возможности, от встроенных функций управления ресурсами до интеграции источников данных, служб кластеризации, защиты, управления рабочей нагрузкой и обнаружения проблем. Естественно, разные платформы предлагают разные реализации этих возможностей, разную семантику и API.

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

Работа в этом направлении привела к появлению концепции Grid [1], ставшей популярной при организации научных и технических вычислений [2]. Технологии и инфраструктуры Grid поддерживают совместное и скоординированное использование разнородных ресурсов в динамических, распределенных виртуальных организациях [3], позволяя из географически рассредоточенных компонентов, применяемых в разных организациях с различными правилами работы создавать виртуальные вычислительные системы, способные совместно поддерживать требуемый уровень обслуживания.

В частности, свободно распространяемый инструментарий Globus Toolkit стал фактическим стандартом конструирования Grid-систем. На его основе созданы самые разные проекты: от систем обеспечения работы научных групп, которым требуется удаленный доступ к специализированными экспериментальным лабораториям, например, Network for Earthquake Engineering Simulation (NEESgrid, www.neesgrid.org), до систем распределенной аналитической обработки больших объемов информации, таких как Grid Physics Network, EU DataGrid Project и Particle Physics Data Grid (www.ppdg.net).

Эволюция технологии Grid привела к возникновению архитектуры Open Grid Services Architecture [4]. В ней Grid-система предоставляет обширный набор служб, которые виртуальные организации могут объединять различными способами. Архитектура OGSA, созданная на концепциях и технологиях, разработанных специалистами в области Grid и Web-служб [6], определяет единообразную семантику предоставления служб, стандартные механизмы для создания, именования и обнаружения экземпляров Grid-служб, обеспечивает прозрачность местонахождения и связывание различных протоколов и поддерживает интеграцию с базовыми механизмами нижележащих платформ.

Разработка технических спецификаций OGSA ведется в рамках форума Global Grid Forum, разрабатывающего стандарты для Grid-сообщества и в качестве свободно распространяемой эталонной реализации предлагающего Globus Project. Инструментарий Globus Toolkit на базе OGSA и коммерческие продукты в этой архитектуре появились в конце 2002 года.

Распространение технологий Grid

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

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

Эволюция корпоративных вычислений

Ранее организации «поручали» свои вычислительные задачи централизованным корпоративным центрам обработки данных. Развитие Internet и возникновение электронного бизнеса привели к необходимости расширить корпоративные ИТ-инфраструктуры таким образом, чтобы они охватывали внешние сети, ресурсы и службы.

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

Подобные попытки в целом оказались неудачными. Дело в том, что декомпозиция возникает и внутри ИТ-служб самого предприятия. Были разработаны новые приложения для компонентных моделей программирования наподобие Enterprise JavaBeans, которые изолируют приложения от базовых вычислительных платформ, поддерживая их переносимость. К примеру, приложения обслуживания Web-запросов ориентированы на массовые серверы, а не на мэйнфреймы. В то же время, Web-доступ к корпоративным ресурсам требовал еще более быстрого обслуживания запросов, заставляя кэшировать контент ближе к границе сети.

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

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

Провайдеры услуг и B2B

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

Чтобы электронные коммунальные службы могли добиться снижения издержек за счет массовости, им необходима инфраструктура, способная настраиваться по требованию в соответствии с нуждами конкретных пользователей. Эта инфраструктура должна обеспечивать:

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

Ключевая тенденция развития ИТ-отрасли — это взаимодействие типа «бизнес-бизнес», управление цепочками поставок, охватывающими несколько организаций, виртуальные Web-магистрали и электронные аукционы. B2B-коммуникации, по существу, образуют виртуальные организации с особенно жесткими требованиями к защите, готовности, контролю, уровню обслуживания и к сложной обработке транзакций. Все это также подогревает интерес к интеграции распределенных систем, часто характеризующихся значительными различиями в базовых технологиях.

Открытая архитектура GRID-служб

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

Ориентация на службы

OGSA поддерживает создание, обслуживание и применение наборов служб для VO, предлагая общее представление для вычислительных ресурсов и памяти, сетей, программ, баз данных и т.п., трактуя их как сетевые службы, предлагающие свои возможности посредством обмена сообщениями. Конечно, можно вместо этого использовать термин «объект», как в системах типа SOS [8] и Legion [9], но этого делать не стоит из-за излишней многозначности данного термина, а также потому, что в OGSA не содержится требования объектно-ориентированной реализации. Принятие единообразной, основанной на службах модели делает все компоненты среды виртуальными, при том что модель должна опираться на реализации физических ресурсов.

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

Виртуализация

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

Виртуализация Grid-служб позволяет легко отображать общее семантическое поведение служб на оригинальные механизмы платформы. Такая виртуализация становится проще, если выразить функции службы в стандартной форме, чтобы любые реализации службы вызывались одинаковым образом. Для этой цели выбран WSDL, язык описания Web-служб. WSDL проводит различие между определением интерфейсов служб и связываниями протоколов, используемых для вызова служб; один интерфейс может иметь несколько вариантов связываний, в том числе и распределенные протоколы (такие, как HTTP), и локальные связывания (например, средства межпроцессного взаимодействия, предусмотренные локальной ОС).

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

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

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

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

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

Семантика Grid-служб

Возможность виртуализировать и комбинировать службы зависит не только от определения стандартных интерфейсов; необходима также стандартная семантика для взаимодействия служб, например, единые механизмы обнаружения свойств служб. С этой точки зрения, OGSA определяет Grid-службу как Web-службу, предоставляющую множество специфицированных интерфейсов и поддерживающую специфицированные соглашения. Интерфейсы касаются вопросов, связанных с обнаружением службы, ее динамическим созданием, управлением жизненным циклом, уведомлением и управляемостью; соглашения касаются также именования и модернизируемости. Grid-службы охватывают вопросы авторизации и контроля одновременного использования. Этот базовый набор согласованных интерфейсов, на основе которого реализуются все службы, поддерживает создание иерархических служб более высокого порядка, которые могут одинаковым образом восприниматься на всех уровнях абстракции.

Каждую Grid-службу определяет набор интерфейсов, сконфигурированный как WSDL portType (рис. 1). Служба должна поддерживать интерфейс GridService; кроме того, OGSA определяет множество других интерфейсов для уведомления и создания экземпляров. Конечно, пользователи также определяют произвольные, ориентированные на конкретное приложение интерфейсы. serviceType (элемент расширения WSDL) определяют множество типов portType, которое поддерживает службы Grid вместе с некоторой дополнительной информацией, касающейся отслеживания версий.

Grid-служба OGSA

Рис. 1. Grid-служба OGSA. Служба состоит из элементов данных и различных обязательных и дополнительных интерфейсов, с потенциальным воплощением через различные реализации, возможно, в разных средах

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

Участники VO зачастую хотят реализовать новые временные экземпляры службы динамически для поддержки конкретной затребованной функциональности. Когда эта функциональность больше не требуется, службу можно удалить. Например, в системе видеоконференций организация сеанса может включать в себя создание экземпляров службы в промежуточных точках для сквозного управления потоками данных в соответствии с ограничениями, накладываемыми соглашением об уровне обслуживания. Среды Web-служб могут реализовать службы динамически для того, чтобы обеспечить пользователям надежное время ответа, управляя рабочей нагрузкой за счет динамического добавления «обрабатывающих узлов». Другие примеры деятельности, которые можно представить и управлять как временным экземпляром службы: запрос к базе данных, операция добычи данных, резервирование полосы пропускания сети, передача данных.

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

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

Стандартные интерфейсы

OGSA определяет стандартное поведение и соответствующие интерфейсы.

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

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

Управление жизненным циклом. Службы OGSA могут создаваться и уничтожаться динамически. Их можно удалять явно; они также могут быть удалены или стать недоступными из-за возникновения системной ошибки, например, в случае сбоя в операционной системе. Интерфейсы определяются для управления жизненным циклом службы и, в частности, для восстановления служб и состояния, связанных с неудавшимися операциями. Например, окончание сеанса видеоконференции может также потребовать завершения служб, созданных в промежуточных точках для управления потоками. OGSA выполняет это требования, определяя стандартную операцию SetTerminationTime в интерфейсе GridService, необходимом для поддержки состояния при управлении жизненным циклом экземпляров службы. Протоколы с поддержкой состояния [10] позволяют OGSA в конце концов аннулировать состояние, установленное в удаленной системе, если поток последовательных восстанавливающих сообщений не обновит его. Интерфейс GridService также определяет операцию ExplicitDestruction.

Уведомление. Набор динамических, распределенных служб должен иметь возможность асинхронно уведомлять друг друга о серьезных изменениях своего состояния. OGSA определяет общие абстракции и интерфейсы служб для подписки на такие уведомления и для их доставки. Благодаря этому службы, созданные как композиция более простых служб, могут стандартным образом работать с уведомлениями, к примеру, с уведомлениями об ошибках. Специализированные связывания протоколов позволяют уведомлениям OGSA использовать различные (в том числе, коммерчески доступные) системы передачи сообщений для доставки сообщений с уведомлениями в соответствии с определенным QoS.

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

Среды исполнения

На практике, Grid-службы выполняются конкретной средой исполнения. Эта среда определяет не только программную модель реализации, язык, средства разработки и отладки, но также и то, каким именно образом реализуется семантика службы.

Часто приложения Grid-служб используют набор процессов операционной системы в качестве среды исполнения. Скажем, создание нового экземпляра службы предусматривает создание нового процесса. Такая среда позволяет реализовать службу на различных языках (Си, C++, Java, Fortran, Python и т.д.). Семантика Grid может быть реализована непосредственно как часть службы или предоставлена посредством библиотеки, связанной с приложением.

Реализовывать Web-службы могут и более сложные среды исполнения на базе контейнеров или компонентов: J2EE, IBM WebSphere, .Net и Sun ONE. Внутри таких сред определяется оболочка, которая используется для реализации и создания компонентов, соответствующих устанавливаемым средой интерфейсам для создания сложных приложений. По сравнению с низкоуровневой функциональностью, которую предлагают базовые среды исполнения, контейнерные или компонентные среды, как правило, предлагают значительную программируемость, управляемость, гибкость и безопасность. Как следствие, они весьма популярны для создания служб электронной коммерции.

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

Определяя семантику службы, OGSA указывает взаимодействия между службами независимо от среды исполнения. Однако определение базовых характеристик, которые должны поддерживать все среды исполнения может помочь созданию служб:

  • отображение общих для Grid имен, или дескрипторов служб, на элементы, специфические для реализации, такие как указатели Си и ссылки на объекты Java;
  • диспетчеризация вызовов Grid и уведомлений в специфические для реализации действия, такие как события и вызовы процедур;
  • обработка протоколов и форматирование данных для передачи по сети;
  • управление жизненным циклом экземпляров служб;
  • аутентификация между службами.

Важное следствие поддержки виртуализации в OGSA заключается в том, что пользователь не должен знать о том, как конкретная среда исполнения реализует поведение и интерфейсы OGSA. Простая среда исполнения, виртуальная среда исполнения и коллективные службы могут реализовывать одни и те же интерфейсы (рис. 2).

Компонентное окружение Grid

Рис. 2. Ком­по­нент­ное окру­же­ние Grid

Простая среда исполнения. Простая среда исполнения предоставляет набор ресурсов, размещенных внутри одной организации. Он поддерживает базовые механизмы управления службами, такие как сервер приложений на базе J2EE, .Net или Linux-кластер. В OGSA интерфейс такой среды, как правило, будет структурирован — реестр, одна или несколько «фабрик» (factory) и модуль handleMapper, отвечающий за определение соответствия между глобально уникальным дескриптором Grid-службы и информацией о связывании. Каждая фабрика занесена в реестр, что позволяет клиентам обнаруживать имеющиеся фабрики.

Виртуальная среда исполнения. В более сложных средах ресурсы, связанные с VO, будут охватывать гетерогенные, географически распределенные среды исполнения. Например, на рис. 2 ресурсы принадлежат двум простым средам. Тем не менее, виртуальная среда исполнения, которая может, к примеру, соответствовать набору ресурсов, предоставляемых в рамках B2B-взаимодействия, может быть открыта клиенту для доступа через точно такие же интерфейсы, как и для простой среды исполнения.

Коллективные службы. Можно также создать виртуальную среду исполнения, которая предоставляет участникам VO более сложные виртуальные, коллективные или комплексные (сквозные) службы. В этом случае реестр отслеживает и «рекламирует» фабрики, которые создают экземпляры служб более высокого уровня. Такие экземпляры реализуются путем обращения к фабрикам более низкого уровня для создания множества экземпляров служб и за счет объединения поведения этих экземпляров в единый экземпляр службы более высокого уровня.

Пример: служба добычи данных

Рис. 3 иллюстрирует некоторые аспекты использования OGSA. Представлена ситуация, в которой пользователь хочет обнаружить, приобрести и развернуть удаленным образом средства для создания новой базы данных путем добычи данных из нескольких источников данных в Internet. На рисунке представлены следующие шаги.

  1. Пользователь (или, более вероятно, программа или служба, действующая от имени пользователя) обращается к реестру, который поддерживает соответствующее VO, для поиска провайдеров служб, способных предоставить требуемые возможности добычи и хранения данных. В запросе пользователя могут указываться такие требования, как стоимость, местонахождение или производительность.
  2. Реестр возвращает дескрипторы, указывающие фабрику добычи данных и фабрику базы данных, поддерживаемых провайдерами, которые соответствуют требованиям пользователя (или, возможно, несколько дескрипторов, представляющих службы-кандидаты). Пользователь указывает службы, приемлемые для него.
  3. Пользователь инициирует запросы к фабрике добычи и базы данных, специфицируя ряд деталей, например, те операции по добыче данных, которые будут выполняться, вид базы данных, в которой будут храниться результаты, и время жизни для создаваемых экземпляров служб.
  4. Если этот процесс переговоров завершается успешно, создаются два новых экземпляра служб с требуемым начальным состоянием, ресурсами и временем жизни.
  5. Служба добычи данных инициирует запросы к соответствующим удаленным базам данных, по существу, действуя в качестве клиента от имени пользователя, когда он выполняет еще более удаленные операции. Механизмы защиты OGSA решают возникающие вопросы делегирования.
  6. Результаты запросов возвращаются либо модулю добычи данных (рис. 3), либо вновь создаваемой базе данных. Вместе с тем, в зависимости от первоначально оговоренного времени жизни пользователь может периодически направлять сообщения о продлении этого времени, чтобы показать, что ему еще нужна данная служба.

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

***

Технологии и концепции Grid быстро набирают популярность, выходя за рамки научных сообществ. Open Grid Services Architecture ускоряет этот процесс, преобразуя технологии, которые предлагает Globus Toolkit, в единообразную, ориентированную на службы архитектуру и интегрируя их со стандартами на Web-службы. Таким образом, OGSA представляет естественную эволюцию технологий Grid и Web-служб.

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

Службы и абстракции OGSA предлагают строительные блоки, которые разработчики могут применять для реализации множества Grid-служб более высокого уровня, например, для управления данными и ресурсами [11, 12]. Global Grid Forum работает с отраслевыми и научными организациями и сообществом сторонников свободно распространяемого программного обеспечения над формированием набора служб, которые при их совместном использовании будут в состоянии удовлетворить разнообразные требования приложений электронного бизнеса и электронной науки.

Литература

  1. I. Foster, C. Kesselman, eds., The Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, San Francisco, 1999
  2. W.E. Johnston, D. Gannon, B. Nitzberg, "Grids as Production Computing Environments: The Engineering Aspects of NASA's Information Power Grid", Proc. 8th Int'l Symp. High-Performance Distributed Computing (HPDC8); http://www.computer.org/proceedings/hpdc/0287/02870034abs.htm
  3. I. Foster, C. Kesselman, S. Tuecke, "The Anatomy of the Grid: Enabling Scalable Virtual Organizations", Int'l J. High-Performance Computing Applications, vol. 15, no. 3, 2001; http://www.globus.org/research/papers/anatomy.pdf
  4. I. Foster et al., "The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration", tech. report, Glous Project; http://www.globus.org/research/papers/ogsa.pdf
  5. S. Graham et al., Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI, Sams Technical Publishing, Indianapolis, Ind., 2001
  6. E. Christensen et al., "Web Services Description Language 1.1", W3C Note, 2001 15 Mar.; http://www.w3.org/TR/wsdl
  7. C. Catlett, L. Smarr, "Metacomputing", Comm. ACM, 1992 June
  8. M. Shapiro, "SOS: An Object-Oriented Operating System-Assessment and Perspectives", Computing Systems, vol. 2, no. 4, 1989
  9. A.S. Grimshaw, W.A. Wulf, "The Legion Vision of a Worldwide Virtual Computer", Comm. ACM, vol. 40, no. 1, 1997
  10. S Raman, S. McCanne, "A Model, Analysis, and Protocol Framework for Soft State-Based Communication", Computer Communication Rev., vol. 29, no. 4, 1999
  11. N.W. Paton et al., "Database Access and Integration Services on the Grid", tech. report UKeS-2002-3, National e-Science Centre; http://www.nesc.ac.uk, 2002
  12. M. Livny, "High-Throughput Resource Management", The Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, San Francisco, 1999

Ян Фостер (foster@mcs.anl.gov) — заместитель директора подразделения математики и информатики Арагонской национальной лаборатории, профессор информатики Чикагского университета. Карл Кессельман (carl@isi.edu) — руководитель проекта Института информатики университета Южной Калифорнии. Стивен Тьюке (tuecke@mcs.anl.gov) — архитектор программного обеспечения Лаборатории распределенных систем подразделения математики и информатики Арагонской лаборатории и научный сотрудник Института вычислительной техники Чикагского университета; содиректор подразделения Global Grid Forum Security. Джеффри Ник (jnick@us.ibm.com) — директор по архитектуре новейших систем корпорации IBM, ведущий архитектор проекта Project eLiza.

Ian Foster, Carl Kesselman, Jeffrey M. Nick, Steven Tuecke. Grid Services for Distributed System Integration. IEEE Computer, June 2002. IEEE Computer Society, 2002, All rights reserved. Reprinted with permission.

OGSA и Globus Toolkit

OGSA и Globus ToolkitGlobus Toolkit [I, II] — свободно распространяемый набор служб с открытой архитектурой и библиотек, которые поддерживают Grid-среды и приложения для них. Этот инструментарий решает вопросы защиты, обнаружения информации, управления ресурсами и данными, обеспечивает коммуникации и переносимость приложений.

Рис. Структура GT3

OGSA — естественная эволюция второй версии Globus Toolkit (GT2). Ключевые концепции, такие как «фабрика» или «реестр», а также надежные и защищенные вызовы существуют и в Globus Toolkit, но в менее общей и гибкой форме и без тех преимуществ, которые дает единообразный язык определения интерфейсов. По существу, в OGSA основные элементы проектирования подобных сред серьезно переосмыслены и еще больше абстрагированы, благодаря чему они могут применяться к любому уровню виртуализации ресурсов организации.

Проект Globus Project развивает кодовую базу Globus Toolkit. Результатом этой эволюции станет третья версия Globus Toolkit. На рисунке представлена структура GT3, которая включает:

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

Первый прототип GT3 Core был представлен в мае, а полная версия GT3 —в конце 2002 года. Эта версия реализует OGSA с полностью открытыми исходными текстами и поддерживает Globus API, а также интерфейсы WSDL.

Литература
  1. I. Foster, C. Kesselman, "Globus: A Toolkit-Based Grid Architecture", The Grid: Blueprint for a New Computing Infrastructure, I. Foster and C. Kesselman, eds., Morgan Kaufmann, San Francisco, 1999
  2. I. Foster, "The Grid: A New Infrastructure for 21st Century Science", Physics Today, vol. 55, no. 2, 2002