Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
УП_ИБ РВ редакция.docx
Скачиваний:
4
Добавлен:
01.07.2025
Размер:
3 Мб
Скачать
☆

2.4 Элементы грид

В среде грид явным образом присутствуют следующие элементы:

1) Программы пользователя.

2) Ресурсы.

3) Промежуточное программное обеспечение (Middleware), выступающее в роли посредника между пользовательскими программами и ресурсами. Middleware включает большой объем программного обеспечения, разрабатывается большими организациями и строго стандартизуется, чтобы обеспечить взаимно перекрестное использование частей этого Middleware разными разработчиками.

В число наиболее известных пакетов Middleware входят [3,4,7]:

- Globus Toolkit. Условно его можно назвать американским направлением, разрабатывается многими организациями, в частности, по проекту Globus, который возник в Аргоннской национальной лаборатории. Здесь разработаны пакеты GT1,GT2, GT3 и GT4;

- gLITE. Его условно можно назвать европейским проектом, поскольку его разработка курируется Европейским центром ядерных исследований (CERN). gLITE также явился следствием ряда предыдущих проектов (EDG, LCG и др.).

GT4 содержит набор стандартных служб. На данный момент они представляют собой девять Web-сервисных интерфейсов, но их число растет [8].

1) Управление заданиями: пакет программ выявления и управления ресурсами (GRAM).

2) Надежная файлопередача (RFT).

3) Делегирование функций.

4) Система мониторинга и выявления свободных ресурсов – индекс (MDS-index).

5) Система мониторинга и выявления – MDS-trigge.

6) Система мониторинга и выявления – сбор данных (MDS-aggregate).

7) Авторизация сообщества (CAS).

8) Интеграция и доступ к данным (OGSA-DAI).

9) Протокол дистанционного контроля Grid (GTCP) для онлайнового контроля оборудования.

В настоящее время каждая современная грид базируется на Открытой Архитектуре грид-служб (OGSA), который позволяет интеграцию служб и ресурсов через распределенные, гетерогенные, динамические виртуальные организации. OGSA — это информационная спецификация, которая призвана определять общую, стандартную и открытую архитектуру для грид-приложений. Цель OGSA состоит в том, чтобы стандартизировать почти все услуги, которые грид-приложение может использовать, например задание и сервисы управления ресурсом, коммуникации и безопасность. OGSA определяет сервис-ориентированная архитектуру (SOA) для грид, которая реализует модель вычислительной системы как ряд реализованных распределенных вычислительных образцов, используя Веб-сервисы как основную технологию. В основном, стандарт OGSA определяет интерфейсы обслуживания и идентифицирует протоколы для того, чтобы вызывать эти услуги [9,10].

2.5 Сервисно-ориентированная архитектура soa

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

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

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

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

Достоинствами слабой связи являются:

1) Гибкость: сервис может быть расположен на любом сервере, а при необходимости перемещен. Пока ссылка на этот сервис есть в службе регистрации, предполагаемые клиенты будут в состоянии найти и использовать его.

2) Масштабируемость: функциональные возможности сервиса могут быть расширены или сужены, поскольку при этом описание сервиса динамически меняется, и, соответственно, изменяются и запросы.

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

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

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

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

Рисунок 3 - Многошаговое взаимодействие и сервисы