Этот документ посвящен обзору средства для создания систем распределенных вычислений под названием Globus Toolkit. Целью обзора было выяснение перспектив использования инструментария для создания системы Testing Grid.
Сначала следует заметить, что бóльшая часть функциональности Globus реализована под UNIX-подобные системы. Наша задача требует непременного наличия модулей под Windows, что ограничивает нас только той частью Глобуса, которая работает по принципу веб-сервисов. Глобус предоставляет три так называемых ядра для веб-сервисов (WS Core), написанных на разных языках: C WS Core, Python WS Core и Java WS Core. Собственно, только последнее из них (только Java WS Core) и может быть использовано под Windows, так как остальные, повторюсь, написаны под UNIX-системы.
По нашему мнению, система Globus Java WS Core не подходит для нашего проекта. Она, возможно, подходит больше, чем другие исследованные системы, но все равно это не то. Основная причина в том, что нам придется втеснить наши задачи в механизм веб-сервисов, однако нам это ничего не даст.
Документация Globus'a построена по каким-то очень странным законам, понять которые до конца не удалось до сих пор (к тому же она неполна). Это, а также масштабность проекта, вызвало столь существенную задержку с разбором этой системы. Однако в конце концов удалось с уверенностью выяснить, что Globus Java WS Core — не что иное, как всего лишь реализация системы для запуска веб-сервисов. Сама по себе она включает только контейнер для запуска веб-сервисов на сервере и несколько небольших утилит для управления ими. Она поддерживает расширения веб-сервисов: WSRF (Web Service Resource Framework, необходимо для моделирования сущностей, сохраняющих свое состояние, на основе веб-сервисов, которые сами по себе состояние не сохраняют) и WS-Notification (необходима, чтобы дать возможность серверу связываться с клиентами, а не только клиентам с сервером). Однако, это все, что умеет данный компонент.
Для него реализовано несколько сервисов, которые могли бы быть нам полезны (например, RFT и WS GRAM), но они хоть и используют WS Core, все равно работают только под Unix/Linux подобными системами.
Самое же важное то, что использование WS Core нам не может дать ровным счетом ничего. Да, мы получаем некую систему, которая позволяет вызывать методы удаленных объектов. Но это — все. Начнем с того, что вызов удаленных объектов в нашем проекте хоть и может быть применен, но не может дать никаких преимуществ. С точки же зрения локальных сетей организаций использование механизмов веб-сервисов выглядит странным. Наиболее же популярные компоненты Globus не могут быть нами использованы потому, что они реализованы только для Unix/Linux систем.
Заданием было оценить, сколько и что именно нам придется делать, если мы будем использовать Globus. Ответ в том, что нам придется делать все тоже самое, что мы бы делали при написании системы с нуля. Единственное, что нам может пригодиться, это автоматическая поддержка сертификатов X.509, которая введена в Globus Java WS Core. Взамен мы получаем необходимость перевода всей архитектуры проекта под идеологию веб-сервисов, которая, строго говоря, для таких проектов не предназначена. В связи с этим обязательно появятся серьезные проблемы, которые сведут на нет это преимущество Globus Java WS Core. Также стоит заметить, что по результатам работы Алексея Кузнецова найдены совместимые реализации алгоритма электронной подписи для разных платформ (Java, C++), которым можно доверять.
Globus Java WS Core может быть использован при реализации нашего проекта, но это не даст нам ровным счетом никаких преимуществ и повлечет за собой множество проблем.