![[Home]](/~megera/oddmuse/zen3.gif)
По мере резкого увеличения количества астрономических данных в 90-х годах прошлого века возникла необходимость стандартизации способов их хранения, обработки и доступа к ним. Это стало особенно актуальным учитывая будущие проекты, которые основываясь на новых технологиях ставят новые грандиозные задачи ( возникло даже выражение "technology enabled science"). Для сравнения, за 15 лет работы космического телескопа Хаббл было получено 700.000 снимков около 20.000 объектов. При этом ежесуточно на землю поступало около 15 Gb информации. Все хранилище оценивается в 25 Tb. Будущие проекты оценивают свое хранилище уже в петабайты при ежесуточном наполнении в терабайты ! Так, проект "Large Synoptic Survey Telescope" ( www.lsst.org ), который стартует в 2012 году, планирует получать изображения размером в 3 миллиарда пикселов и за ночь накапливать около 15 Tb информации. Закладывается хранилище емкостью в 200 Pb с пропускной способностью сети в 10 Gb/sec. Проект НАСА "Solar Dynamics Observatory" (sdo.gsfc.nasa.gov), посвященный мониторингу солнечной активности (запуск в 2008 году), планирует ежесуточно получать около 3 Tb данных.
Кроме того, астрономия активно децентрализуется, т.е., астрономы стремятся хранить данные не в центрах коллективного хранилища, а там где это удобно для их поддержания. Сейчас насчитывается более 10,000 уникальных каталогов, не считая их различных версий, и эта цифра будет только увеличиваться. Публикация новых каталогов, модификация старых, требует значительных усилий по стандартизации описания метаданных, регистрации каталогов.
Совершенно очевидно, что старый подход, когда необходимые данные просто скачивались тем или иным способом на компьютер для обработки, совершенно непригоден. Требуется новая технология, которая позволяет передавать программы в центры данных, там их исполнять и предоставлять пользователю только результаты. Новый подход требует соглашений о том, как находить ресурсы (центры данных), каким образом и в каком виде эти данные надо передавать, какие программные интерфейсы необходимы для написания программ и какова политика использования ресурсов.
Для организации процесса обработки данных (pipeline), который может быть очень трудоемким, поисковых задач требуется доступ к GRID центрам, что также требует определенных соглашений (см. проект GRIST, http://grist.caltech.edu). В ГАИШ МГУ ведется работа по оцифровыванию стеклянной библиотеки, которая содержит наблюдения (пластинки) за 150 лет и является ценнейшим материалом для астрономии. Обработка большого количества снимков (около 100,000) помимо сложной архитектуры хранилища и методов доступа к сканам, потребует столь значительных вычислительных ресурсов и времени, что приводит к необходимости использования распределенных вычислительных ресурсов.
Возникла парадоксальная ситуация, когда есть много данных, которыми практически трудно воспользоваться из-за разнобоя в описаниях, единицах измерений, протоколов хранения и передачи данных и т.д. Аналогичная картина наблюдается как в других науках (например, физика высоких энергий, биология, метеорология), так и в бизнесе, развитие которого опирается на бизнес-процессы, реализуемые, в частности, с помощью информационных технологий.
Отмечу, что требуется обеcпечить прежде всего не интерактивную работу с данными, а программный доступ к ним, чтобы можно было автоматизировать рутинные работы обработки наблюдений, поиска данных.
Кроме того, помимо необходимости разработки новых программных компонентов, существует большое количество старых программ и систем, которые обслуживают существующие информационные ресурсы и требуется найти способ их интеграции. Очевидно, что это возможно только при абстрагировании от конкретного устройства компонент, протоколов связи между ними и формата данных, которыми они обмениваются. В противном случае, затраты на подключение новых компонентов с системе требует больших финансовых и временных затрат ( большинство существующих распределенных информационных систем связаны именно таким способом ). Попытки решения задач интеграции в распределенных системах предпринимались, например, технология CORBA, разрабатываемая в соответствии со спецификациями консорциума OMG (Object Management Group, http://omg.org/), чья спецификация версии 1.1 в 1991 году стала первой серьезной технологией построения распределенных систем. предлагающей реальную независимость от инфраструктуры, сетевых протоколов, операционных систем и языков программирования. ( Именно идеи CORBA вдохновили автора и его коллег в 1999 году на создание технологии Дискавери с использованием middleware, которая использовалась при работе над порталами Рамблер, Астронет, федеральных порталов министерства образования России и других.) Параллельно, компания Майкрософт продвигала технологию создания распределенных систем DCOM, разработанную на основе модели COM. Кроме CORBA, DCOM существует технология RMI, поддерживающая вызов удаленных объектов, но только если клиент и сервер являются java приложениями.
К сожалению, ни одна из перечисленных технологий не решила проблемы, так из-за разногласий между различными вендорами, разные реализации CORBA были несовместимы между собой, технология DCOM, несмотря на обещания Майкрософт, так и осталась поддерживающей только ОС Windows.
В тоже время, в связи с развитием Веба, появились Веб-службы (сервисы), которые предложили архитектуру, основанную на слабой связности (loose coupling) между компонентами. Это означает, что компонентам системы не обязательно знать как устроены, взаимодействующие с ними подсистемы, и нет необходимости разрабатывать новые форматы данных и создавать специальное ПО для взаимодействия с ними. Другими словам, все компоненты системы представляют друг для друга "черные ящики". Для Веб-служб важно только то, что используется протокол передачи данных HTTP, которые передаются в формате XML, содержащий сериализованные объекты и способ адресации - URI (Unified Resource Identifier). Учитывая, что практически все вендоры приняли и используют спецификации W3C (w3c.org), Веб-сервисы имеют все шансы стать новой технологией распределенных информационных систем. Замечу, что для интеграции старых систем требуется написать только внешний интерфейс (враппер), который удовлетворял бы описаниям веб-сервиса. Практические задачи могут быть очень сложными и требовать соединения нескольких сервисов, географически и организационно разделенных. Для управления набором сервисов, порядком их выполнения и передачей данных между ними (workflow) , разрабатываются спецификации оркестровки (WS Orchestration) и хореографии (WS Choreоgraphy) сервисов и язык BPEL4WS для описания оркестровки.
В конце 90-х крупные центры астрономических данных (CDS (Франция), CaDC (Канада), STScI (США), и т.д.) предложили начать разработку стандартов для доступа к астрономическим данным. Основная цель - оптимизировать доступ, обработку и анализ данных с целью получения максимальной научной отдачи. В 2002-м году был образован Международный Альянс Виртуальной Обсерватории (IVOA, International Virtual Observatory Alliance, ivoa.net), объединивший национальные международные ВО проекты. Главная миссия IVOA - разработка, утверждение и распространение стандартов для всех типов астрономических данных и средств их обработки и анализа.
За последние годы были рабочими группами IVOA были разработаны рекомендации: универсальное описание различных астрономических данных, представленных в каталогах (Unified Content Descriptors, UCD), создание основанного на XML стандарта для обмена астрономическими данными (VOTable), создание стандартных способов доступа к изображениям (Simple Image Access Protocol) и спектрам (Simple Spectral Access Protocol). Основным результатом для общественности является появление десятков архивов, предоставляющих доступ к данным через стандартные интерфейсы (например, приложение Aladin, разработанное в CDS).
Виртуальная Обсерватория - это новая концепция организации доступа к астрономическим данным любого рода и средствам для их обработки и анализа в современной эре развития информационных технологий. С технологической точки зрения, Виртуальная Обсерватория есть сервисно-ориентированная архитектура для астрономии.
На сегодняшний день в технологической структуре ВО можно выделить три основные части:
Проект создания Российской Виртуальной Обсерватории (РВО, http://www.inasan.ru/rus/rvo/) начал осуществляться в 2002 году, однако, никаких результатов в рамках РВО получено не было, что частично объясняется как слабой информированностью российского астрономического сообщества относительно целей и задач ВО в целом, и РВО в частности, так и недостаточной технологической базой на данный момент.
Наша группа в ГАИШ МГУ, при поддержке РФФИ, нацелена на получение, в первую очередь, реальных научных результатов с помощью методов ВО, что требует решение ряда технологических задач, в первую очередь начиная от создания архитектуры узла ВО, способной обеспечить хранилище очень больших каталогов и работу с ними. Кроме того, существуют такие нерешенные проблемы, как версионность данных, их аутентичность, которые мы считаем важными и намереваемся исследовать возможности их решения. Действительно, научные исследования требуют возможности проверки результатов, что затруднительно в современную эпоху, когда каталоги не выпускаются как книги, а публикуются в сети и могут измениться в любой момент времени. Версионность важна и для создателя каталога. Нам близка эта тема, так как версионность поддерживается в нашей технологии, например, на сайте проекта Астронет все объекты (публикации) идентифицируются по URI, которое является ссылкой в базе данных на актуальную в данный момент версию. При этом, можно восстановить всю историю изменения объекта. Аутентичность данных тоже важна, так как надо быть уверенным, что используются именно оригинальные данные, а не прошедшие чью-либо обработку.
В рамках проекта Астронет (www.astronet.ru) уже создан полностью рабочий прототип узла Виртуальной Обсерватории SAI CAS (vo.astronet.ru), который является первым (и единственным) в России и СНГ реально работающим центром доступа ко всем крупнейшим астрономическим каталогам (несколько миллиардов объектов). Все ресурсы уже зарегистрированы в международных реестрах и доступны как ресурсы ВО. Отметим, что SAI CAS является открытым проектом, в его работе принимают участие сотрудники разных институтов, и технология реализована с помощью только открытых технологий (PostgreSQL, Apache, Axis, Java, PHP) и оригинальных алгоритмов работы с очень большими астрономическими каталогами, что очень важно для его клонирования в других местах. Более подробно, это проект будет представлен в другом докладе.
Применение и развитие сервисно-ориентированной архитектуры в науке является важнейшим фактором развития российской науки, так как позволяет находить, публиковать и обмениваться данными в распределенном мировом хранилище информации, что позволяет решать новые, ранее недоступные, задачи. Учитывая нынешнее состояние наблюдательной базы в России, приобщение к ресурсам Виртуальной Обсерватории является необходимым фактором выживания российской астрономии.
Автор выражают благодарность Российскому Фонду Фундаментальных Исследований за многолетнюю поддержку исследований (гранты 05-07-90225-в, 06-07-89182-а).
