Программное обеспечение GRID: состояние и перспективы.

В.П.Шириков

Объединенный Институт Ядерных Исследований, г. Дубна

   Идеи GRID, предложенные Фостером и Кессельманом в первую очередь для реализации распределенной обработки данных (и в этом смысле GRID рассматривался как "вычислительный" партнер "информационного" Web), можно рассматривать, в частности, как развитие старых идей, заложенных в проекты CONDOR и Flock CONDOR, опробованных, в частности, в ОИЯИ совместно с коллаборантами в Амстердаме и Варшаве на наборе рабочих станций фирмы SUN. Эти проекты не нашли в свое время серьезной реализации и применений из-за низкого качества и пропускной способности линий связи вычислительных ресурсов, недоработанности программного обеспечения безопасности обмена информацией и т.д.: одно дело - когда в корпоративных рамках или тем более в рамках локальных сетей организуется пул компьютеров для совместного решения потока задач при пропускной способности связей внутри пула не менее 10 Mbps, и другое - когда в общий пул объединяются компьютеры из разных сетей. Сейчас CONDOR (см., например, http://www.cs.wisc.edu/condor/) можно считать возродившимся и успешно примененным в пробных прогонах программного обеспечения, основанных на использовании пакета GT2, изначально предложенного Аргонской Национальной Лабораторией в рамках проекта Globus (http://www.globus.org). Учитывая, что есть возможность и распараллеливания прикладных программ средствами пакета MPICH-G2 (grid-совместимой реализации стандарта MPI), а также, что все упомянутые наборы программного обеспечения являются свободно-распространяемыми и проверенными в реальных применениях среди российских работ, выполненных для организации GRID-сегмента в рамках локальной сети с применением пакетов Globus Toolkit 2.4 и MPICH-G2, можно упомянуть хотя бы разработку параллельной версии программного комплекса АТОМ и ее испытание на экспериментальном кластере МЦ СПбГУ, доложенную в прошлом году на конференции "Научный сервис в сети Интернет" [1], то можно считать, что проблема оборудования локальных сетей системой эффективных распределенных вычислений внутри этих сетей сменила статус "научно-исследовательской" на "эксплуатационный". Здесь может быть спорным только один вопрос: высказанное утверждение относится к Linux-ориентированному оборудованию, это с точки зрения ОС гомогенный GRID, как пока и те, о которых речь пойдет ниже. Это обстоятельство, как я знаю, беспокоит, например, ИПМ РАН, являющийся одним из соисполнителей российского сегмента GRID в рамках 6-й Рамочной программы Европейской Комиссии и ее проекта EGEE (Enabling Grids for E-science in Europe), начатого в апреле 2004 года (см. http://www.eu-egee.org или http://egee-intranet.web.cern.ch/egee-intranet/gateway.html). На самом деле этот проект стартовал не на пустом месте, а на основе предыдущих проектов: EDG (European DataGrid) и LCG (LHC Computing Grid). Основной целью проекта EDG (http://www.eu-datagrid.org) являлось создание базовой сетевой инфраструктуры для реализации проектов LCG и Biomedical Grids. LCG (http://www.cern.ch/lcg) предназначен для обработки данных с Большого Адронного Коллайдера (Large Hadron Collider), который ожидается к запуску в 2007 году: эксперименты этом ускорителе будут порождать потоки данных с экстремальными характеристиками (100 Mbps и общим объемом несколько петабайт в год для каждого эксперимента: ALICE, ATLAS, CMS, LHCb), и постановка приложений LCG на инфраструктуру EDG позволит производить массовую распределенную обработку этих данных с использованием гигабитных линий связи сети GEANT (см. http://www.dante.net/geant/), Linux-кластеров двухпроцессорных узлов с 32-битной и 64-битной архитектурой, а также внешней памяти с терабитными объемами на базе RAID-массивов и DLT-лент в центрах обработки. Основными задачами участников проекта LCG как базового для реализации общеевропейского междисциплинарного GRID и его объединения с "Гридами" других регионов мира (например, американским по проекту DataTag) стали:

   - Обеспечение работоспособности программного обеспечения для мобилизуемых компьютерных ресурсов с применением современных IT-технологий "промежуточного слоя" (middleware) в пакетах GT;

   - Совершенствование средств распараллеливания задач или GRID-сервисов широкого использования (типа популярной у физиков системы ROOT для анализа данных, преобразованной сейчас в PROOF: Parallel Root Facility для 64-битного оборудования GRID-кластеров PC);

   - Техническое совершенствование опорных кластеров (увеличение числа узлов, переход на использование двухпроцессорных узлов с 64-битной архитектурой).

   Об успешной реализации первой фазы проекта LCG (LCG-1) см., например, в CERN Courier (октябрь 2003, стр. 9). Об участии ОИЯИ и российских институтов в проектах LCG и EEGE см., например, публикации [2,3].

   Комплектация инструментального пакета системного программного обеспечения уровня 2004 года (LCG-2) на основе использования компонент от разных проектов выглядит следующим образом:

Базовые компоненты:

  • EDG 2.1:

--WMS (Workload Management System)

--DMS (Data Management System)

.RM (Replica Manager)

.RLS: Replica Location Service & LRC (Local Replica Catalog)

.RMC (Replica Metadata Catalog)

--Fabric Management

--VO (Virtual Organization) Management)

--BDII (Berkeley DB Information Index)

  • VDT (Virtual Data Toolkit) 1.1.8:

--Globus Toolkit 2.2.4

--Condor 6.4.7

.Condor-G

.Class Ads

  • Информационный сервис:

--Globus MDS (Monitoring and Discovery System)

.GRIS (Grid Resource Information System)

.GIIS (Grid Index Information Service)

  • EDG 1.1: Grid-ICE, GLUE Schema...

(см. http://atlas-canada-computing.web.cern.ch/atlas-canada-computing/documents/LCG-2-Userguide.pdf).

   Данный инструментальный пакет устанавливается на технике "виртуальных организаций" (VO`s): коллабораций индивидуалов и институтов, объединяющих свои вычислительные ресурсы (CE-computer elements, SE-storage elements) для совместного использования при распределенной обработке потока задач (на этапе использования LCG-1 было 5 таких VO: одна - для LCG Deployment Group и 4 - для коллабораций упомянутых выше экспериментов. На этапе LCG-2 уже большая свобода для подключения новых VO). "Мостом" доступа к LCG-2 для конкретного пользователя (юзера) является в этом случае UI (User Interface): машина, где юзер получает персональный пароль (account) и сертификат для следующих операций: ввода задач для выполнения на каких-то CE, просмотра ресурсов (подходящих для выполнения задачи), просмотра и копирования файлов, контроля состояния (статуса) введенных задач, отмены прохождения одной или нескольких задач, получения вывода закончившихся задач. В целом весь процесс ввода и управления прохождением задач в LCG-2 описывается следующей схемой (см. также её графическое представление на стр.21 руководства LCG-2-Userguide по URL-ссылке, приведенной выше):

   a) После получения цифрового сертификата от одного из LCG-2 ответственных лиц (Certification Authorities), регистрации в VO и получения account`а на LCG-2 User Interface (UI)-машине, юзер имеет право работать с LCG-2 Grid. Он делает login в UI-машину и получает proxy-сертификат (талон на временное использование внешних ресурсов).

   b) Юзер поставляет свою задачу из UI в одну из машин (узлов), именуемых Resource Brokers и ответственных за дальнейшее её прохождение. На такой машине (узле) выполняются основные сервисы, входящие в состав WMS (Workload Management System), в том числе:

   . Network Server (NS), воспринимающий запросы входящих с UI задач. Среди таких запросов, изложенных в "паспорте задачи" (Job Description -файле), юзер может указать один или более файлов для копирования из UI на RB-узел: этот набор составляет Input Sandbox;

    .   Workload Manager, основная компонента системы;

   . Match-Maker  (часто  именно его называют Resource Broker`ом), чья обязанность - найти наилучший ресурс (Computing Element, CE), отвечающий требованиям задачи;

     .  Job Adapter, готовящий  "описание" задачи  до передачи его сервису Job Control Service (JCS);

     .  JCS с возможностями подсистемы Condor, переправляющий задачу в CE.

     . LB (Loggin and Bookkeeping)-сервис, регистрирующий все события в части процесса управления прохождением задачи, о которых юзер или системный администратор может узнать.

   RB-узлу доступен сервис, предоставляемый BDII (Berkeley DB Information Index): эта служба опрашивает региональные серверы GIIS (Grid Index Information Servers) о наличии и состоянии вычислительных (CE) ресурсов и ресурсов памяти на дисках, MSS и т.п. (SE, Storage Element`ов), отображая это состояние в своей БД.

   Итак, на первом этапе сервис NS в RB принимает от UI информацию о задаче и требуемых ею ресурсах, данное событие отмечается в LB-журнале, задаче присваивается статус SUBMITTED.

c) WMS через свою компоненту Match-Maker подыскивает наилучший доступный CE для данной задачи: для этого опрашивается сервис BDII о статусе вычислительных и "памятийных" ресурсов, а также для обнаружения места данных- сервис RLS (Replica Location Service), которому доступны каталоги RMC (Replica Metadata Catalog) и LRC (Local Replica Catalog), где отображаются файлы, доступные разным юзерам и размещенные в разных SE. Событие записывается в журнал LB и задаче присваивается статус WAIT.

d) WMS Job Adapter готовит задачу (её "паспорт") для JCS/Condor и её передаче выбранному CE: задаче присваивается статус READY.

e) CE-это в общем случае однородная ферма вычислительных узлов (WN, Worker Nodes) и узел, выступающий в роли Grid Gate (GG). т.е. front-end к остальному Grid. На нем выполняется Globus gatekeeper, Globus GRAM (Globus Resource Allocation Manager), сервер Local Resource Management System (LRMS, планировщик) вместе с LB-сервисами. В LCG-2 в качестве LRMS поддерживаются PBS (Portable Batch System), LSF и Condor. В то время как WN-узлы спрятаны за firewalls, узел GG должен быть доступен извне CE. На узлах WN доступны все команды и API`s для выполнения действий с Grid-ресурсами и данными. CE может использовать средства памяти (SE) через Grid FTP-сервис (в последней версии LCG управление динамической работы с ресурсами памяти возлагается на SRM: Storage Resource Manager).

   Итак, на следующем после d шаге Globus Gatekeeper на CE получает запрос от RB и отдает задачу планировщику (системе обслуживания очереди) LRMS: PBS, LSF или Condor. Статус задачи-SCHEDULED.

f) LRMS реализует выполнение задачи на доступной локальной ферме рабочих узлов WN, куда копируются из RB и файлы, нужные задаче.

Статус задачи - RUNNING.

g) Во время выполнения задачи ей могут быть доступны файлы с SE (через rfio-протокол) или локальной памяти WN. Информация по SE и результатам рассмотрения задачи сервисом Match-Maker включаются в файл.Brokerinfo, передаваемый рабочим узлам CE службой WMS, и может извлекаться из этого файла средствами библиотеки API или WMS CLI.

h) Задача может порождать новые выходные данные, которые могут быть "выгружены" в Grid и сделаны доступными для использования другими юзерами. Это делается инструментами Data Management - сервисов. Выгрузка в Grid означает его копирование на Storage Element (SE) и регистрацию его местоположения, метаданных и т.д. в RMS. В то же время, во время выполнения задачи или через UI файлы могут "реплицироваться " двумя разными SE.

i) Если задача завершается без ошибок, её output-файлы, указанные пользователем в Output Sandbox, передаются обратно в RB-узел: статус задачи - DONE.

j) На данном этапе юзер может забрать Output из UI, используя WMS CLI или API. Статус задачи - CLEARED.

k) Запросы о статусе задачи адресуются базе данных LB из UI-машины (узла). Также из UI возможны запросы к BDII о статусе ресурсов.

l) Если что-то случается плохого на CE, где проходит задача, то она автоматически перебрасывается другому CE в соответствие с начальными требованиями юзера. Если это не получается, задача метится как ABORTED. Если задача не успевает быть завершенной к моменту истечения времени, определенного выданным пользователю proxy-сертификатом, WMS-служба позволяет заблаговременно обновить proxy (этим ведает Proxy Server, PS), однако на время этого автоматического продления все другие запросы пользователя не будут обслуживаться.

   Вот теперь коснемся той темы, которая относится к технологии "middleware", о которой говорилось в обзорах на конференциях "Научный сервис в сети Интернет" в 2002 /2003/2004 годах [4, 5, 7] и которая касается и Web, и GRID в равной степени.

   Предсказывается, что вся информационная и вычислительная программная поддержка науки в рамках Интернет будет реализовываться комплексом программных агентов (брокеров) и сервисов, доступных этим агентам непосредственно или через репозитории (регистрационные службы): см. хотя бы формализованный пример цикла полной автоматизации и обработки экспериментальных данных в сетевой компьютерной среде, от начала поступления данных на анализ до подведения итогов и результатов обработки научным сообществом, в работе David De Rouge et al "The Semantic Grid: a Future e-Science Infrastructure" (http://www.semanticgrid.org/documents/semgrid-journal/semgrid-journal.pdf). Перспективность агентно-ориентированного подхода к разработке распределенных интеллектуальных систем отмечается, например, и в работе [9].

   Средства взаимодействия агентов (клиентов) с сервисами, как службами - исполнителями нужных агентам работ, - одни из главнейших составляющих "middleware", имеющих давнюю историю применений, и к данному моменту достаточно много крупных приложений, реализованных, например, в рамках применения архитектуры CORBA (Common Object Request Broker Architecture). По разным причинам, о которых говорилось в докладе [4], это применение не вышло за рамки корпоративного, поэтому на смену (или скорее "развитие") пришла архитектура OGSA (Open Grid Services Architecture) с такими ключевыми понятиями, как Web/Grid-сервисы (службы), WSDL (Web Services Description Language для описания их возможностей и способов доступа в формате XML Schema, их интерфейсов), UDDI (Universal Description,Discovery and Integration: средства регистрации, каталогизации описаний сервисов в формализованном XML-формате), WS-Inspection (вариант коллекции описаний и ссылок, по назначению близкий к аппарату UDDI) и протокол SOAP (Simple Object Access Protocol) поверх HTTP (для обмена данными и сообщениями в XML-формате между агентами, сервисами и регистрационными службами, для удаленного вызова процедур). В рамках OGSA схема взаимодействия агентов-клиентов (потребителей сервисов) с агентами-поставщиками сервисных услуг и регистрационными службами (если они используются) может быть представлена примерно так, как это сделано в работе [6]. В принципе такие идеологи GRID как Фостер и Кессельман, определяя для него необходимую архитектуру системного и прикладного программного обеспечения, предполагали использование стандартизованных средств именно из архитектуры OGSA (см. статью Ian Foster, Carl Kesselman, Jeffrey M.Nick, Steven Tuecke "The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration", http://www.globus.org/research/papers/ogsa.pdf). "Middleware", используемое для проектов типа EDG и LCG, данной архитектуре пока не соответствует, хотя какие-то шаги навстречу ей у физиков были сделаны в проектах типа Alien для реализации систем распределенного анализа данных: см., например, http://www.uscms.org/s&c/lcg/ARDA/ARDA-report-v1.pdf. Одним из основных шагов по реализации OGSA-архитектуры стала разработка OGSI (Open Grid Services Infrastructure), определившая механизмы для создания, управления и обмена информацией между Grid-сервисами, т.е.Web-сервисами, предоставляющими корректно определенные интерфейсы и отвечающие специфическим соглашениям (например, в связи с введением понятия "временных", transient служб). В соответствие с документом по проекту OGSI появились первые реализации программных пакетов Globus Toolkit 3 (GT3) как набора средств (tools) для создания описаний и развертывания сервисов, управления ресурсами, обеспечения коммуникаций и безопасности обмена информацией. В секциях 2-7 документа OGSI дан материал о том, как спецификации Grid-сервисов отображаются средствами типа WSDL: здесь вводится и определяется gwsdl - расширение к существовавшей на момент начала разработки OGSI версии WSDL 1.1 как временная мера до появления более развитых версий WSDL (1.2 и выше), см. http://www.w3.org/TR/2003/WD-wsdl12-20030611/.

   Рабочая группа, созданная для реализации проекта ARDA (Architectural Roadmap for Distributed Analysis) и включившая в свой состав представителей всех основных коллабораций по использованию экспериментальных установок на LHC, изначально предполагала сделать пробный вариант своей системы обработки данных с применением версий пакета GT3; целый ряд организаций (в том числе ОИЯИ и российские институты) также опробовали применение указанных версий. Результат: если, скажем, при работе с Web-сервисами (их создании, определении их WSDL-интерфейсов, генерации модулей для стабов и скелетонов при обращении к рабочим вариантам методов сервисов) было не обязательно знать WSDL-тонкости представления описаний сервиса, а можно было воспользоваться готовыми инструментальными средствами, заложенными компаниями SUN и Apache в пакеты типа JWSDP и Axis, то реализация описаний интерфейсов сервисов на gwsdl даже в версиях Globus Toolkit 3.2 оказалась с программной точки зрения неудобной, "ручной" и плохо диагностируемой (сделанная, скажем, ошибка в одном символе проявлялась только в том, что сервис не запускался). В целом выявилось по крайней мере три причины недовольства пользователей продукцией рабочей группы по реализации OGSI (см. http://www.globus.org/wsrf/faq.asp#wsrf):

1. Слишком  много лишнего и недостаточно четко включено в спецификации OGSI v.1.0, определяющей стандарты описаний интерфейсов сервисов, системы обмена сообщениями и.д.

2. Потеряно взаимодействие с существующими средствами развертывания Web- сервисов. OGSI v.1.0 слишком жестко и негибко использует XML Schema.

3. В спецификации смешиваются (объединяются) понятия "сервис" и "ресурсы", с которыми работает сервис. Разработчики не учли появление ряда промышленных стандартов de-facto, в том числе на способы адресования сервисов в системе обмена сообщениями по протоколу SOAP, см., например,

http://www6.software.ibm.com/software/developer/library/ws-add200403.pdf

http://www-106.ibm.com/developerworks/webservices/library/ws-add/

   В результате в ЦЕРНе (головной организации по проекту LCG), например, были фактически приостановлены работы по использованию спецификаций OGSI. В январе 2004 года стартовал совместный проект WS-Resource Framework (WSRF) участников альянса Globus Allians и IBM (при взаимодействии с HP и рядом других фирм) с целью упорядочения и модификации подходов OGSI в спецификации OGSI V1.0 Cоотношение между WSRF и OGSI изложены в документе "From OGSI to WSRF: Refactoring and Extensions",

см. http://www.ibm.com/developerworks/library/ws-resource/gr-ogsitowsrf.html, и на Первой EGEE- конференции в апреле 2004 года Кессельман объявил об ожидаемом появлении в 3-м квартале с.г. версии GT4. Согласно сентябрьской информации (см. http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/GT4Facts/index.html: Status and Plans for the Globus Toolkit 4.0 (GT4)), окончательная полная рабочая версия GT4 будет готова к 31 января 2005 года.

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

   Проблема использования OGSA не сводится только к освоению ее инструментария для создания новых распределенных приложений, остается вопрос о том, что делать с теми, которые уже были реализованы с применением "middleware"-технологий CORBA, RMI и др. Частично говорилось об этом на базе примеров реализации самими прикладниками преобразований таких приложений за счет создания программных "мостов" CORBA-OGSA в обзорном докладе [4] или RMI-OGSA [8]. Сейчас аппарат приспособления к новой архитектуре развит уже на промышленном уровне. Так, в PC WEEK/RE (номер 10 от 23 марта 2004г.) Питер Коффи пишет по поводу инструментария Web-сервисов: "В принципе они полезны, вот только текущему моменту никак не соответствуют. Но положение начинает меняться. Изнуренным работой корпоративным программистам на Java и C++ должен понравиться выпущенный фирмой Iona Technologies пакет Artix Encompass: в его варианте Standard Edition есть инструментарий разработки Web-сервисов, а в Advanced Edition - средства превращения в Web-сервисы приложений, созданных на базе Java, CORBA, IBM WebSphereMQ и др. Здесь же отмечается, что в том, что касается протоколов связи между агентами и сервисами, то кроме SOAP (Simple Object Access Protocol, стандарт OGSA) предоставляется свой транспортный механизм JMS (Java Messaging System) и другие методы доставки информации, включая туннелирование по протоколу IIOP (Internet Inter-ORB Protocol из архитектуры CORBA). Обеспечивается и трансляция между различными форматами (SOAP, IIOP...), есть встроенный визуальный графический дизайнер, позволяющий разрабатывать и интегрировать Web-сервисы.

   Итак, выбор пути использования спецификаций SOAP/WSDL/UDDI с API для доступа к UDDI-реестрам из любого языка программирования в любой операционной среде можно считать сделанным и для GRID, и для Web; их применение реализовано в целом ряде приложений и фирменных программных продуктов, и как отмечается, например, в статье "Где хранить сведения об информационных ресурсах?" (см. PC WEEK/RE, выпуск 36, октябрь 2004), "только децентрализация и сквозное взаимодействие на основе общепринятых мировых стандартов (XML, SOAP, Web Services, WSDL, UDDI) способны привести к успеху при создании удобных и повсеместно доступных систем хранения каталогизированной информации". Нужно ли физикам полностью и немедленно преобразовывать набор системных служб LCG-2 или приложения типа развиваемых проектом ARDA в соответствие со спецификациями OGSA-считается, как можно понять, не очевидным. При решении типовых конкретных задач обработки больших потоков информации и необходимости добиться максимальной производительности этой обработки в жесткие сроки они могут временно обойтись и без той полной универсальной автоматизации процесса работы коллаборации исследователей, которая представлена схемой David De Rouge`a et al., тем более что для такой эффективной автоматизации аппарата содержательного (семантического) описания сервисов средствами XML Schema недостаточно, здесь в идеале нужна реализация "представления знаний" более развитым "онтологическим" подходом (обзор [5]), а отсутствие хороших автоматизированных средств генерации онтологий (аннотаций к содержимому коллекций информации) на языках "on top of XML" (типа OWL: Ontology Web Language) сдерживает этот процесс. Впрочем, работы по созданию подобных средств ведутся, в том числе и в России (например, [10]).

    ЛИТЕРАТУРА

1. М.М. Степанова, О.А. Стесик, А.Г. Сурков, Л.В. Чернышева. Разработка параллельной версии программного комплекса "Атом" и ее испытание на экспериментальном GRID-кластере. // Труды Всероссийской научной конференции "Научный сервис в сети ИНТЕРНЕТ", Новороссийск, 2003, стр. 172-173.

2. В.А. Ильин, В.В. Кореньков. Участие Российских центров и ОИЯИ в проектах LCG и EGEE // Тезисы докладов международной конференции "Распределенные вычисления и ГРИД-технологии в науке и образовании", Дубна, 2004, стр. 48.

3. В.А. Ильин и др. Web-портал www.egee-rdig.ru: единое информационное пространство участников RDIG. // Тезисы докладов международной конференции "Распределенные вычисления и ГРИД-технологии в науке и образовании", Дубна, 2004, стр. 47.

4. В.П. Шириков, В.В. Галактионов. На пути к внедрению новых информационных технологий. // Труды Всероссийской научной конференции "Научный сервис в сети ИНТЕРНЕТ", Новороссийск, 2002, стр. 8-11.

5. В.П. Шириков. Как у нас с интеллектом в Web и GRID для создания полноценного научного сервиса? // Труды Всероссийской научной конференции "Научный сервис в сети ИНТЕРНЕТ", Новороссийск, 2003, стр. 33-38.

6. В.В. Галактионов. Web Services - сервис-ориентированная технология для распределенных объектных вычислительных систем. Основные концепции, протоколы и спецификации. // Сообщение ОИЯИ Р10-2003-140, Дубна, 2003.

7. В.П. Шириков. Программное обеспечение GRID: переоценка ценностей. // Труды Всероссийской научной конференции "Научный сервис в сети ИНТЕРНЕТ", Новороссийск, 2004, стр. 142-144.

8. В.В. Галактионов. Bridge RMI-GT3: сопряжение технологий распределенных систем с архитектурами RMI и GRID-OGSA. // Тезисы докладов международной конференции "Распределенные вычисления и ГРИД - технологии в науке и образовании", Дубна, 2004, стр. 31.

9. Е.И. Зайцев. Об агентно-ориентированном подходе к разработке распределенных интеллектуальных систем. // Тезисы докладов международной конференции "Распределенные вычисления и ГРИД - технологии в науке и образовании", Дубна, 2004, стр. 41.

10. А.В. Жучков и др. Использование онтологий при работе с гетерогенными федеративными массивами данных в распределенных информационных системах. // Тезисы докладов международной конференции "Распределенные вычисления и ГРИД - технологии в науке и образовании", Дубна, 2004, стр. 40.