Книжная полка Сохранить
Размер шрифта:
А
А
А
|  Шрифт:
Arial
Times
|  Интервал:
Стандартный
Средний
Большой
|  Цвет сайта:
Ц
Ц
Ц
Ц
Ц

Программные продукты и системы, 2012, № 1 (97)

международный научно-практический журнал
Покупка
Основная коллекция
Артикул: 706065.0001.99
Программные продукты и системы : международный научно-практический журнал. - Тверь : НИИ Центрпрограммсистем, 2012. - № 1 (97). - 164 с. - ISSN 0236-235X. - Текст : электронный. - URL: https://znanium.ru/catalog/product/1016231 (дата обращения: 20.05.2024). – Режим доступа: по подписке.
Фрагмент текстового слоя документа размещен для индексирующих роботов. Для полноценной работы с документом, пожалуйста, перейдите в ридер.
Н а у ч н о - и с с л е д о в а т е л ь с к и й  и н с т и т у т  
«Це нтр п р ог р ам мс и стем» 
 
 
 
 
 
 
 
 
 
 
 
Программные 
продукты и системы 

 
 
 
 
 
НАУЧНО-ПРАКТИЧЕСКОЕ ИЗДАНИЕ 
 
 
 
№ 1 (97), 2012 
 
 
 
 
 

Главный редактор 

С.В. ЕМЕЛЬЯНОВ, академик РАН 
 
 
 
 
 
 
 
Тверь 

Вниманию авторов! 
 
Международный журнал «Программные продукты и системы» публикует материалы научного и 
научно-практического характера по новым информационным технологиям, результаты академических и 
отраслевых исследований в области использования средств вычислительной техники. Практикуется 
выпуск тематических номеров по искусственному интеллекту, системам автоматизированного 
проектирования, по технологии разработки программных средств и системам защиты, а также 
специализированные выпуски, посвященные научным исследованиям и разработкам отдельных вузов, 
НИИ, научных организаций.  
Решением Президиума Высшей аттестационной комиссии Министерства образования и науки РФ 
№ 616 от 19.02.2010 международный журнал «Программные продукты и системы» внесен в Перечень 
ведущих рецензируемых научных журналов и изданий, в которых должны быть опубликованы основные 
научные результаты диссертаций на соискание ученых степеней кандидата и доктора наук. 
Информация об опубликованных статьях регулярно по установленной форме представляется в 
систему Российского индекса научного цитирования (РИНЦ). 

Условия публикации 

Редакция принимает к рассмотрению материалы, соответствующие тематике журнала (05.13.00 – 
Информатика, вычислительная техника и управление) и ранее нигде не опубликованные. 
Материалы, поступившие в редакцию, оцениваются на соответствие редакционным требованиям. 
Работа представляется в электронном виде в формате Word (шрифт Times New Roman, размер 11 
пунктов с полуторным межстрочным интервалом). При обилии сложных формул обязательно наличие 
статьи и в формате pdf. Формулы желательно набирать в редакторе формул Word (Microsoft Equation 3.0). 
Объем статьи вместе с иллюстрациями должен быть не менее 10 000 знаков. Просьба не присылать 
цветные, тонированные и не подлежащие дальнейшему редактированию в Word’е рисунки, а также 
отсканированные формулы и тексты. Заголовок не должен превышать 7 слов; сокращения, а также 
терминологию узкой тематики желательно в нем не использовать. Количество авторов на одну статью – 
не более 4, количество статей одного автора в номере, включая соавторство, – не более 2. Список 
литературы (оформленный в соответствии с ГОСТом Р 7.05–2008), наличие которого обязательно, должен 
включать не более 5 пунктов. 
Вместе со статьей следует прислать отзыв-рекомендацию в произвольной форме и экспертное 
заключение. 
Необходимо также представить сведения об авторах: фамилия, имя, отчество, наименование 
организации, должность, ученые степень и звание (если есть), контактный телефон, электронный адрес, 
почтовый адрес для отправки бесплатного авторского экземпляра.  
Кроме того, статья должна иметь на русском и английском языках аннотацию (не более 50 слов), 
ключевые слова (7–10 слов), а также УДК. На английский язык необходимо перевести название статьи, 
имя и фамилию автора, наименование организации, ученую степень и звание (если есть). 

Порядок рецензирования 

Все статьи, поступающие в редакцию (соответствующие тематике и оформленные согласно 
требованиям к публикации), подлежат обязательному рецензированию в течение месяца с момента 
поступления.  
В редакции есть устоявшийся коллектив рецензентов, среди которых члены международной 
редколлегии журнала, эксперты из числа крупных специалистов в области информатики и 
вычислительной техники ведущих вузов страны, а также ученые и специалисты НИИ «Центрпрограммсистем» (г. Тверь). 
Рецензирование проводится конфиденциально. Автору статьи предоставляется возможность 
ознакомиться с текстом рецензии. При необходимости статья отправляется на доработку или отклоняется. 
Рецензии обсуждаются на заседаниях редакционной коллегии, которая проводится один раз в 
месяц в НИИ «Центрпрограммсистем» (г. Тверь) или в Главной редакции международного журнала 
«Проблемы теории и практики управления» (г. Москва). 
Решение о целесообразности опубликования статьи после рецензирования принимается 
редакционным советом. 
Материалы, одобренные редакционным советом, публикуются бесплатно в течение года с момента 
одобрения, а статьи, отправленные на доработку, – с момента поступления после доработки. Если 
принятая к публикации статья, по мнению автора, является срочной, редакция вправе опубликовать ее в 
текущем номере на коммерческой основе. 

 
 
 

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

3

УДК 681.3.06+519.68 
ВХОДНОЙ ЯЗЫК ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ  
БАЗЫ ЗНАНИЙ GRID-СИСТЕМЫ 
(Работа выполнена при частичной поддержке РФФИ, грант № 10-07-00146) 
 
Г.А. Опарин, д.т.н.; А.Г. Феоктистов, к.т.н.; Э.К. Вартанян 
(Институт динамики систем и теории управления СО РАН, г. Иркутск,  
oparin@icc.ru, agf@icc.ru, e.vartanyan@mail.ru) 

 
Рассматривается язык описания знаний об экспериментальной Grid-системе. Описание таких знаний базируется 
на объектно-ориентированной модели данных. 
Ключевые слова: входной язык, объектно-ориентированная база знаний, Grid-система. 
 
Организация Grid-систем различного назначения является важным и практически значимым 
направлением научных исследований в области 
высокопроизводительных вычислений [1]. Сложность таких систем обусловлена их динамичностью и стохастичностью, наличием большого числа объектов различной природы и связей между 
ними, распределенностью этих объектов и избыточностью информационно-вычислительных ресурсов. В Grid-систему могут интегрироваться 
сложные предметно-ориентированные программные комплексы. Для эффективного использования Grid-системы требуются развитые средства 
описания, хранения и обработки знаний о ее инфраструктуре, а также о процессах планирования 
и вычислений.  
В данной статье рассматривается язык описания объектной модели экспериментальной Gridсистемы, созданной на базе вычислительных ресурсов Суперкомпьютерного центра при Институте динамики систем и теории управления 
(ИДСТУ) СО РАН. 
Представление знаний. В качестве модели 
Grid-системы используется объектно-ориентированная модель данных, обладающая рядом важных 
свойств, необходимых для представления знаний о 
Grid-системе. В частности, данная модель 
− позволяет работать со сложноструктурированными данными, отражать их природу и связи 
между ними; 
− моделирует многомерную структуру данных, с которой приложение в дальнейшем может 
работать напрямую (доступ, поиск или изменение 
данных), что увеличивает производительность 
системы по отношению к реляционной модели; 
− обладает гибкими средствами модификации 
и развития; 
− поддерживает комплексирование по данным 
(представление объектов Grid-системы в универсальном формате, позволяющем работать с ними 
различным 
предметно-ориентированным 
программным комплексам). 
База знаний (БЗ) Grid-системы, реализованная 
на основе такой модели, обеспечивает целостность 
и безопасность информации в процессе извлечения объектов для совместного с другими пользо
вателями доступа к ним и облегчает работу с объектно-ориентированными приложениями. 
В состав базовых элементов модели Grid-системы входят множества классов C, объектов O, 
полей P и типов T. Приведем ее основные характеристики: 
− главное понятие в модели – объект; 
− полная идентификация объекта (без привязки к конкретной БЗ) состоит из объекта и имени 
его типа; 
− объект состоит из набора полей, задаваемых 
классом объекта; 
− в качестве поля могут выступать значение 
какого-либо типа (например, строка или число), 
ссылка на объект определенного класса или символ неопределенности; 
− каждому классу c∈C соответствуют множество его объектов oc∈O и список его полей pc∈P; 
− ссылки на объекты являются значениями 
специального типа, они служат для доступа к объектам, на которые ссылаются; 
− ссылки создаются одновременно с объектами, на которые они ссылаются впоследствии; 
− различаются два вида ссылок на объект: 
простые ссылки, указывающие на один объект, и 
так называемые множественные ссылки, указывающие сразу на несколько объектов; 
− внешнее значение ссылки представляется 
как имя (или имена) указываемого объекта (или 
объектов); 
− с помощью аппарата ссылок реализуются 
следующие виды отношений между объектами: 
«один-к-одному», «многие-к-одному», «один-комногим» и «многие-ко-многим»; 
− специальное поле в объекте отводится для 
хранения имени объекта; 
− множественные виды отношений (все из 
перечисленных выше, кроме «один-к-одному») 
строятся на основе списков; 
− списки являются объектами специального 
класса и служат для объединения совокупности 
объектов и получения возможности ссылки ко 
всем этим объектам как к единому целому; 
− списки имеют специальное поле, в котором 
хранится длина списка; 

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

4

− вновь вводимые классы могут наследовать 
свойства имеющихся классов; 
− возможные изменения модели данных определяются фиксированным набором базовых 
операторов; 
− базовые операторы можно объединять в составной оператор, причем один составной оператор может быть частью другого; 
− типы и некоторые классы изначально 
встроены в модель данных; 
− смысловая нагрузка класса объектов находит свое отражение через указание возможности 
участия объектов данного класса в качестве параметров определенных операторов (базовых или 
составных) с пояснением роли их участия (входные, выходные); 
− знания предметного специалиста об условиях применения объекта того или иного класса в 
процессе вычислений представляются в виде набора продукций, которые являются и объектами 
определенного класса модели. 
Введем вспомогательные элементы модели: 
символ неопределенности θ, который используется при создании объекта, выступая в роли значения полей до их инициализации; функцию 
g:O→C, ставящую в соответствие объекту некоторый класс; функцию q: P→C∪T∪{θ}: ∀ p∈P  

,

( )
,

.

c
C

q p
t
T

∈
=
∈
θ


Состояние модели Grid-системы задается в виде структуры s=<C, O, P, T>. 
Язык описания модели. Рассматриваемый 
язык представления знаний о Grid-системе включает синтаксические конструкции вида: <Имя базового оператора> (<Параметр 1> [, <Параметр 2>, …, <Параметр n>]). 
Данный язык позволяет представить любые 
действия с моделью Grid-системы как последовательность базовых операторов. В результате выполнения базового оператора происходит переход 
из исходного состояния модели s=<C, O, P, T> в 
результирующее s′=<C′, O′, P′, T′>. 
На выполнение базовых операторов могут 
быть наложены ограничения двух видов: встроенные в транслятор языка описания модели Gridсистемы и дополнительные, определяемые разработчиком модели. К первому виду относятся блокировки дублирования и уничтожения классов или 
объектов, проверка соответствия типов и другие 
подобные ограничения целостности модели. Ограничения второго вида определяют специфику 
объектов модели и взаимосвязей между ними. Они 
формируются разработчиком с помощью специальной подсистемы транслятора. 
Свойства модели (полнота, корректность и целостность) выявляются в процессе трансляции ее 
описания.  

В качестве примера рассмотрим описание 
фрагмента вычислительной модели распределенного пакета прикладных программ по линейной 
алгебре. Основными объектами этой модели являются множество параметров Z, множество операций F, множество программных модулей M, 
реализующих операции из F, и множество вычислительных узлов Grid-системы N. 
В таблице 1 приведены примеры создания 
классов этих объектов.  
Таблица 1 
 
Базовый  
оператор 
Описание 
Ограни- 
чения 

newClass(Prm); Создание класса Prm 
(класс параметров) 
Prm∉C 

newField(Prm, 
name, String); 
Создание поля name 
(полное имя параметра) 
в классе Prm. String – 
предопределенный тип 

name∉PPrm;
String∈T;  
Prm∈C 

newField(Prm, 
value, 
Link(Object)); 

Создание поля value 
(значение параметра). 
Значением поля value 
является ссылка на объект класса Object 

value∉PPrm;
Object, 
Prm∈C 

newClass(Mdl); Создание класса Mdl 
(класс модулей) 
Mdl∉C 

newField(Mdl, 
name, String); 
Создание поля name 
(полное имя параметра) 
в классе Mdl 

name∉PMdl; 
String∈T;  
Mdl∈C 

newClass(Opr); Создание класса Opr 
(класс операций) 
Opr∉C 

newField(Opr, 
name, String); 
Создание поля name 
(полное имя операции) 
в классе Opr 

name∉POpr; 
String∈T;  
Opr∈C 

newField(Opr, 
module, 
Link(Mdl)); 

Создание поля module 
(ссылка на программный модуль, реализующий данную операцию) в классе Opr 

module∉POpr; 
Mdl, Opr∈C 

newField(Opr, 
input, 
Link(Array(Prm,
null))); 

Создание поля input 
(входные параметры 
операции) как ссылки 
на список объектов 
класса Prm 

input∉POpr;
Opr, Prm∈C

newField(Opr, 
output, 
Link(Array(Prm,
null))); 

Создание поля output 
(выходные параметры 
операции) 

output∉POpr; 
Opr, Prm∈C

newClass(Node); Создание класса Node 
(класс вычислительных 
узлов) 

Node∉C 

newField(Node, 
id, String); 
Создание поля id (уникальный идентификатор вычислительного 
узла) в классе Node 

id∉PNode; 
String∈T; 
Node∈C 

newField(Node, 
modules, 
Link(Array(Mdl))); 

Создание поля modules 
(модули, установленные на узле) как ссылки 
на список объектов 
класса Mdl 

modules∉PNode; 
Mdl, 
Node∈C 

 
На основе созданных классов формируются 
объекты модели. В таблице 2 приводится описание 
операции масштабирования матриц при вычислении ее собственных значений и векторов. 

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

5

Таблица 2 
 
Базовый  
оператор 
Описание 
Ограничения 

newObject(n, 
Prm); 
Создание объекта n (порядок 
матрицы) класса Prm 
Prm∈C;  
n∉O 

newObject(b, 
Prm); 
Создание объекта b (основание системы счисления в 
машине с плавающей запятой) класса Prm 

Prm∈C;  
b∉O 

newObject(a, 
Prm); 
Создание объекта a (исходная 
матрица) класса Prm 
Prm∈C;  
a∉O 

newObject(low, 
Prm); 

Создание объекта low (параметр операции balance) класса Prm 

Prm∈C; 
low∉O 

newObject(hi, 
Prm); 

Создание объекта hi (параметр операции balance) класса Prm 

Prm∈C;  
hi∉O 

newObject(d, 
Prm); 
Создание объекта d (вектор, 
содержащий информацию о 
перестановках и масштабных 
коэффициентах) класса Prm 

Prm∈C;  
c∉O 

newObject(arr1, 
Array(Prm, 
3)); 

Создание списка из трех объектов класса Prm (входные 
параметры операции масштабирования) 

Prm∈C; 
arr1∉O 

newObject(arr2, 
Array(Prm, 
4)); 

Создание списка из четырех 
объектов класса Prm (выходные параметры операции 
масштабирования) 

Prm∈C; 
arr2∉O 

initObject(arr1[0], 
n); 

Инициализация элемента 
списка arr1 
arr1, n∈O;  
arr1.length>0

initObject(arr1[1], 
b); 

Инициализация элемента 
списка arr1 
arr1, b∈O;  
arr1.length>1

initObject(arr1[2], 
a); 

Инициализация элемента 
списка arr1 
arr1, a∈O; 
arr1.length>2

initObject(arr2[0], 
a); 

Инициализация элемента 
списка arr2 
arr2, a∈O;  
arr2.length>0

initObject(arr2[1], 
low); 

Инициализация элемента 
списка arr2 
arr2, low∈O; 
arr2.length>1

initObject(arr2[2], 
hi); 

Инициализация элемента 
списка arr2 
arr2, hi∈O;  
arr2.length>2

initObject(arr2[3], 
d); 

Инициализация элемента 
списка arr2 
arr2, d∈O;  
arr2.length>3

newObject(m, 
Mdl); 
Создание объекта m (модуль, 
реализующий операцию 
масштабирования) класса 
Mdl 

Mdl∈C;  
m∉O 

newObject(bln, 
Opr); 

Создание объекта bln (операция масштабирования) класса Opr 

Opr∈C;  
bln∉O 

initField(bln, 
name,  
«Balance»); 

Инициализация поля name. 
Balance – значение типа 
String 

bln∈O; 
String∈T; 
name∈Pc; где 
c=g(bln), 
q(name)=String 

initField(bln, 
module, m); 

Инициализация поля module 
bln,m∈O;  
module∈Pc, где 
c=g(bln), 
q(module)=g(m)

initField(bln, 
input, 
Link(arr1)); 

Инициализация поля input 
bln, arr1∈O; 
q(input)=g(arr1); 
input∈Pc, где 
c=g(bln) 

initField(bln, 
output, 
Link(arr2)); 

Инициализация поля output 
bln, arr2∈O;  
q(output)= 
=g(arr2);  
output∈Pc, где 
c=g(bln) 

 
Масштабирование матрицы применяется для 
понижения ее нормы с целью упрощения процесса 
нахождения собственных значений матрицы. Схема операции масштабирования имеет следующий 
вид: balance: {n, b, a}→{a, low, hi, d}. Обозначения взяты из работы [2]. Как видно из примера, 
связи между объектами возникают при инициализации полей. В данном случае список параметров 
связан с операцией масштабирования через поля 
input и output. Описание узлов Grid-системы приведено в таблице 3. 
Таблица 3 
 
Базовый  
оператор 
Описание 
Ограничения

newObject(r1, 
Node); 
Создание объекта r1 
(узел РВС) класса Node 
Node∈C;  
r1∉O 

… 
… 
… 

newObject(rN, 
Node); 
Создание объекта rN 
(узел РВС) класса Node 
Node∈C;  
rN∉O

newObject(arr3,  
Array(Mdl,1));

Создание списка из одного объекта класса Mdl 
(список модулей, установленных на узлах) 

Node∈C;  
arr∉O  

initObject(arr[0], 
m); 

Инициализация элемента 
списка arr (в список установленных модулей заносится модуль m) 

arr, m∈O;  
arr.length>0 

initField(r1, 
modules, 
Link(arr)); 

Инициализация поля 
modules (установка модулей arr на узел r1) 

arr, r1∈O; 
q(modules)= 
=g(arr); 
modules∈Pc, 
где c=g(r1)  

… 
… 
… 

initField(rN, 
modules, 
Link(arr)); 

Инициализация поля 
modules (установка модулей arr на узел rN) 

arr, rN∈O; 
q(modules)= 
=g(arr); 
modules∈Pc, 
где c=g(rN)  

 
Планирование загрузки ресурсов становится 
необходимым при возникновении избыточности 
ресурсов Grid-системы в случае, когда существует 
программный модуль, размещенный в двух или 
более вычислительных узлах (табл. 3). 
База знаний. В качестве основы БЗ экспериментальной Grid-системы ИДСТУ СО РАН используется 
объектно-ориентированная 
БД 
(ООБД) NeoDatis [3], дополненная управляющей 
надстройкой – мультиагентной системой планирования и распределения ресурсов [4]. 
В целом характеристики БД NeoDatis соответствуют основным положениям стандарта ODMG 
(Object Database Management Group) [5] и тем самым обеспечивают возможность ее интеграции с 
различными предметно-ориентированными комплексами, функционирующими в Grid-системе. 
Схематично процесс создания БЗ показан на 
рисунке. Описание предметной области, объектов 
и ресурсов Grid-системы на входном языке транслируется в текст описания на языке Java. Стандартный Java-компилятор, используя библиотеки 
Java-классов (JDK), классов взаимодействия с 
ООБД (драйвер) и классов модели Grid-системы, 

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

6

компилирует текст на языке Java в исполняемый 
байт-код. При исполнении байт-кода Java-интерпретатором (Java Virtual Machine) создается БД, 
которая вместе с подсистемой логического вывода, 
интерпретирующей правила вывода данных, образует БЗ Grid-системы. 
Рассмотренные в данной работе язык и средства его трансляции дают возможность конструировать предметно-ориентированные модели вычислений, включать в них требуемые ограничения и 
контролировать полноту, корректность и целостность атрибутов и взаимосвязей объектов разрабатываемых моделей. Такие модели обеспечивают 
детализированное описание инфраструктуры разнородных распределенных вычислительных сред, 
предоставляя возможность эффективно использо
вать ресурсы этих сред при решении сложных научных и прикладных задач. 
 
Литература 
 
1. Baker M., Buyya R., Laforenza D. Grids and Grid Technologies for Wide-Area Distributed Computing // Software: Practice and Experience. 2002. Vol. 32. No. 15, pp. 1437–1466. 
2. Уилкинсон, Райнш. Справочник алгоритмов на языке 
АЛГОЛ. Линейная алгебра. М.: Машиностроение, 1976. 389 с. 
3. NeoDatis. URL: http://neodatis.wikidot.com (дата обращения: 17.10.2011). 
4. Джордан Д. Обработка объектных баз данных в С++. 
Программирование по стандарту ODMG. М.: Издат. дом 
«Вильямс», 2001. 384 с. 
5. Децентрализованное управление потоками заданий в 
интегрированной кластерной системе / И.В. Бычков [и др.] // 
Вестн. НГУ. Сер. Информационные технологии. 2011. Т. 9. 
Вып. 2. С. 42–54. 
 
 
 
 

УДК 004.75 

ИНФОРМАЦИОННАЯ СИСТЕМА ГридННС 
(Работа выполнена при финансовой поддержке Минобрнауки РФ, контракт № 07.514.11.4022, 
 и гранта РФФИ № 11-07-00434-а) 
 
А.П. Крюков, к.ф.-м.н.; Л.В. Шамардин, к.ф.-м.н.; Д.О. Патрикеев 
(Научно-исследовательский институт им. Д.В. Скобельцына МГУ им. М.В. Ломоносова  
(НИИЯФ МГУ), kryukov@theory.sinp.msu.ru, shamardin@theory.sinp.msu.ru, 
patrikeev@theory.sinp.msu.ru) 

 
Описаны архитектура информационной системы ГридННС, построенная на основе RESTful-веб-сервисов, структура публикуемой информации и используемая модель безопасности. Одним из главных отличий ГридННС от других 
грид-инфраструктур является использование архитектурного стиля REST для реализации грид-сервисов.  
Ключевые слова: высокопроизводительные вычисления, распределенные вычисления, грид, ГридННС, REST, 
RESTful-веб-сервисы, информационная система, система учета. 
 
Концепция грида была предложена в 90-х годах 
20 века К. Кессельманом и Я. Фостером [1]. За 
прошедшее время гриды прошли значительный 
путь развития. На основе успешного опыта ис
Транслятор 

БЗ 

Мультиагентная система планирования  
и распределения ресурсов 

Текст описания 
на входном языке 

Текст описания 
на языке Java
Байт-код 

Компилятор 

Java-компилятор

БД 

Библиотека классов JDK 
Библиотека классов ООБД 

Интерпретатор 

JVM

Библиотека классов 
модели Grid-системы 

Подсистема
логического 

вывода

Схема создания базы знаний Grid-системы 

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

7

пользования Globus Toolkit версии 2 (GT2) сформулирована открытая архитектура грид-сервисов 
(Open Grid Services Architecture, OGSA, http://www. 
ogf.org/documents/GFD.80.pdf), которая в дальнейшем 
была заменена на WSRF (http://docs.oasis-open.org/ 
wsrf/wsrf-primer-1.2-primer-cd-02.pdf). В рамках подхода WSRF объединяются веб-сервис и ресурс, 
доступ к которому он обеспечивает. Канонической 
реализацией WSRF является Globus Toolkit версии 4 (GT4). 
Следуя спецификациям WSRF, можно создавать универсальные сервисы, использующиеся 
практически для любых гридов. Однако стандарт 
WSRF оказался исключительно сложным и, как 
следствие, трудным в реализации. Даже каноническая реализация в виде GT4 не является полной и 
содержит ряд ошибок. Все это ставит под угрозу 
достижение основной цели – создание универсального, динамически изменяющегося грида. 
В 2000 г. Р. Филдинг предложил новый, простой в использовании и гибкий подход к созданию 
веб-сервисов – архитектурный стиль REST [2]. 
Важным достоинством RESTful-сервисов по сравнению с подходом, основанным на WSRF, является несложная семантика запросов, соответствующая интуитивно ясным методам HTTP-протокола. 
Кроме того, RESTful-сервисы используют протокол HTTP по его прямому назначению – как протокол запросов, а не просто как транспортный 
протокол, в отличие от WSRF, где процессы сериализации и десериализации создают дополнительные проблемы, в том числе и с совместимостью реализаций. 
В процессе работы над проектом грид-инфраструктуры Национальной нанотехнологической 
сети (ГридННС) (http://ngrid.ru/ngrid, 2008) авторы 
использовали архитектурный стиль REST для реализации грид-сервисов в рамках концепции 
OGSA. В частности, на этой основе был реализован ключевой сервис ГридННС, управляющий выполнением заданий и названный Pilot [3, 4]. 

В настоящей работе описывается информационная система ГридННС, построенная на базе 
RESTful-веб-сервисов. 
 
Структура ГридННС 
 
ГридННС предоставляет возможность унифицированного безопасного удаленного доступа к 
суперкомпьютерным ресурсам ННС.  
Структуру ее можно представить в виде трех 
слоев (рис. 1): пользовательские интерфейсы, 
грид-шлюзы к ресурсам и общие инфраструктурные сервисы. 
Слой пользовательских интерфейсов предназначен для запуска пользователями своих заданий 
в ГридННС. 
Слой общесистемных сервисов отвечает за 
функционирование и управление ГридННС. Основными общесистемными сервисами являются 
информационная система (ИС), система учета, 
сервис управления и распределения задач, система 
регистрации сервисов и ресурсов, служба выдачи 
и управления цифровыми сертификатами, сервис 
проверки работоспособности ресурсов. 
Слой грид-шлюзов обеспечивает доступ к вычислительным 
ресурсам, 
подключенным 
к 
ГридННС. Грид-шлюз – это комплекс сервисов, 
обеспечивающий всю функциональность, необходимую для использования кластера или суперкомпьютера из ГридННС.  
Важный принцип, положенный в основу проектирования ГридННС, – отказ от установки дополнительного ПО на вычислительном ресурсе. 
Все промежуточное ПО устанавливается только на 
специальном сервере – грид-шлюзе. При таком 
подходе грид-шлюз взаимодействует с системой 
пакетной обработки вычислительного ресурса как 
специфический пользователь. 
Одним из компонентов грид-шлюзов является 
сервис ИС. Другой компонент ИС, агрегатор (hub), 
является частью общесистемных сервисов. Опи
Слой сайтов 
 с грид-шлюзами 
и ресурсами 

Слой общих 
сервисов 

Слой интерфейсов
пользователей 

Ресурс
Ресурс

Сайт ГридННС 

ИП 
ИЛР

ИП 
ИЛР
. . . 

Ресурс
Ресурс

Сайт ГридННС 

ИП 
ИЛР

ИП 
ИЛР
. . . 

Ресурс
Ресурс

Сайт ГридННС 

ИП 
ИЛР

ИП 
ИЛР
. . . 
. . . 

Общие сервисы грид-инфраструктуры 

ИП 
ИП 
ИП 
. . . 

Рис. 1. Общая структура ГридННС 

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

8

шем подробнее устройство и особенности функционирования ИС ГридННС. 
 
ИС ГридННС 
 
ИС ГридННС первоначально была построена 
на базе WS-MDS из инструментального набора 
Globus Toolkit 4. Однако из-за сложности использования и расширения возможностей WSRF-сервисов возникла необходимость перехода на более 
удобные в использовании RESTful-веб-сервисы. 
Новая реализация ИС для грида стала еще более 
актуальной после того, как появилась информация 
о намерении разработчиков Globus Toolkit отказаться от использования WSRF-сервисов в последней версии Globus Toolkit 5, а также из-за отсутствия в его составе собственной ИС и инструментария для ее создания. 
Архитектура ИС ГридННС изображена на рисунке 2. Основная задача ИС в том, чтобы обеспечить пользователей и сервисы ГридННС информацией о текущем состоянии ресурсов. Например, 
сервису управления выполнением заданий Pilot 
эта информация позволяет выбрать подходящий 
ресурс для выполнения задач с учетом требований 
с их стороны и планирования распределения нагрузки. В качестве источников информации о ресурсе выступают файл с его статическим описанием, а также провайдер динамической информации 
о нем. Статическая информация включает, например, название ресурса, его местоположение. Первоисточник динамической информации – локальный менеджер ресурсов (ЛМР), которым является 
система 
управления 
пакетной 
обработкой 
(СУПО) вычислительного ресурса.  
Особое внимание при построении ИС уделяется схеме данных. В качестве прототипа схемы 

данных использовалась GLUE Scheme 2.0 (http:// 
forge.ogf.org/sf/projects/glue-wg, 2007), а в качестве 
формата для обмена данными – JSON [5]. Общая 
структура публикуемой информации по каждому 
вычислительному ресурсу имеет следующий вид: 

 
{ 
... 
   "Site": { 
   ... 
      "Cluster": [ 
      ... 
         "SubCluster": [ 
          ... 
          { 
           ... 
           "Queue": [...] 
           "Host": [...] 
           "Software": [...] 
          } 
         ] 
      ] 
   } 
... 
} 
 
Таким образом, каждый ресурс (сайт) представляет собой список кластеров, которые, в свою 
очередь, содержат подкластеры. Современные суперкомпьютеры довольно часто являются неоднородными. Например, суперкомпьютер «Ломоносов», занимающий 18-е место в Top500 самых 
мощных суперкомпьютеров мира, имеет ряд рабочих узлов с расширенной оперативной памятью, 
другая часть использует графические процессоры. 
Разбиение кластера на подкластеры позволяет 
учесть неоднородную структуру вычислительного 
ресурса. Структура подкластера предполагается 
однородной. 
Статическая часть информации о ресурсе содержит его общее описание (наименование, местоположение, административные контакты и т.д.). 
Приведем пример статической информации: 

 
{ 
    "__metadata": { 
        "infosys2_site_version": "0.5.0" 
    }, 
    "CreationTime": "2011-11-24T09:06:40Z", 
    "Validity": 3600, 
    "Site": { 
        "Cluster": [ ... ], 
        "Description": "Resource center", 
        "Info": { 
            "ServiceEndpoint": { 
                "GRAM": [ 
                    "https://rc.ru:8443/wsrf/services/ 
ManagedJobFactoryService" 
                ], 
                "GridFTP": [ 
                    "gsiftp://rc.ru:2811" 
                ], 
                "IS2": "https://rc.ru:8443/ 
services/LIS2", 
                "RFT": [ 
                    "https://rc.ru:8443/wsrf/services/ 
ReliableFileTransferFactoryService" 
                ] 
            } 
        }, 
        "Latitude": 55.6, 
        "Location": "Moscow, Russia", 
        "Longitude": 37.5, 
        "Name": "xxx", 
        "SecurityContact": "mailto: security@rc.ru", 
        "SysAdminContact": "mailto: sysadmin@rc.ru", 
        "UniqueID": "xxx.ru", 
        "UserSupportContact": "mailto: support@rc.ru", 
        "Web": "http://www.xxx.ru", 
    } 
} 
 

Сайт 1
Сайт 2  
ЛМР 

Сервис 
управления 
задачами 

Сервис 

сопряжения с 

ЛМР 

InfoSys2 

Грид  

Сервис 
управления 
заданиями 

InfoSys2Hub 

Интерфейс 
пользователя

Сервис  
регистрации 

Рис. 2. Архитектура информационной системы

ГридННС

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

9

Сведения о кластерах, зарегистрированных на 
одном ресурсном центре, помещаются в массив 
«Cluster», содержание которого в примере условно 
обозначено «[...]». Секция «Cluster» включает следующую информацию: 

 
{ 
    "SubCluster": [ 
         { 
             "Name": "rc.ru/subcluster0", 
             "PhysicalCPUs": 16, 
             "LogicalCPUs": 16, 
             "Queue": [ ... ], 
             "Host": [ ... ], 
             "Software": [ ... ], 
         }, 
         ... 
    ] ... 
} 
 
Структура рабочих узлов описывается в секции 
«Host»: 

 
   "Host": [ 
       { 
           "MainMemory": { 
               "RAMSize": 1024, 
               "VirtualSize": 8192 
           }, 
           "Processor": { 
               "ClockSpeed": 2667, 
               "Model": "E5430", 
               "Vendor": "Intel Xeon", 
               "InstructionSet": "x86" 
           }, 
           "OperatingSystem": { 
               "Release": "5.3", 
               "Version": "Final", 
               "Name": "CentOS" 
           }, 
           "UniqueID": "subcluster0.rc.ru/ 
host", 
           "Architecture": { 
               "SMPSize": 1, 
               "PlatformType": "i686" 
           } 
       } 
   ] ... 
 
Следует еще раз подчеркнуть предположение о 
том, что подкластер имеет однородную структуру. 
Вся неоднородность учтена на уровне кластера, 
который может включать разные подкластеры. 
Информация о доступном пользователям ПО 
публикуется в секции «Software»:  

 
    "Software": [ 
        { 
            "LocalID": "hpmpi-2.02.05.01-20070708r", 
            "Version": "2.02.05.01-20070708r", 
            "Name": "hpmpi", 
            "InstalledRoot": "/opt/hpmpi" 
        }, 
        { 
            "ModuleName": "lmp", 
            "LocalID": "lammps-25Sep11", 
            "EnvironmentSetup": [ 
                { 
                    "softenv": "+lammps-25sep11" 
                } 
            ], 
            "ACL": { 
                "Rule": [ 
                    "VOMS:/sysadmin", 
                    "VOMS:/gridnnn", 
                    "VOMS:/education", 
                    "VOMS:/abinit" 
                ] 
            }, 
            "Version": "25Sep11", 
            "Name": "lammps", 
            "InstalledRoot": "/shared/lammps" 
        } 
    ], ... 
 
В секции, описывающей ПО, важную роль играют права доступа («ACL»), с помощью которых 

системный администратор может сообщить о существовании ограничений на использование тех 
или иных пакетов прикладных программ членами 
конкретных виртуальных организаций (ВО). Таким образом, публикуется локальная политика использования прикладного ПО в зависимости от 
принадлежности к ВО. В свою очередь, сервис управления выполнением заданий Pilot при выборе 
ресурса, на котором может быть выполнена задача, 
руководствуется этой информацией. Если данный 
ресурс не публикует сведения о поддержке какойлибо ВО, то он исключается при выборе места 
выполнения для задач пользователей этой ВО. 
Важной частью схемы является секция «EnvironmentSetup»,   где указываются   метки   програм- 
много окружения «softenv» или другие расширения, по наличию которых ПО грид-шлюза осуществляет специальную настройку среды выполнения для обеспечения доступа к соответствующему 
ПО некоторым стандартным образом. Например, 
этой настройкой может быть добавление необходимых путей в переменные PATH и LD_LIBRARY_PATH. Данная необходимость связана с тем, 
что прикладное ПО на ресурсах может быть установлено различными способами. Простейший 
пример – использование разных корневых директорий для прикладных пакетов. Так как в момент 
запуска задания пользователь не знает, на каком 
ресурсе будет выполнена его задача, необходим 
механизм ее настройки в момент запуска на конкретном ресурсе. Пользователь указывает названия пакетов, требования к их версиям. Сервис Pilot извлекает из ИС список окружений, необходимых для данных пакетов на выбранном ресурсе, и 
дополняет описание задачи соответствующими 
расширениями. Таким образом, пользователю не 
требуются знания особенностей установки ПО на 
ресурсах грида, что существенно упрощает запуск 
задач в такой неоднородной среде. 
Не менее важным атрибутом ресурса, публикуемым в ИС, является информация о свойствах 
очереди, в частности, об обслуживаемых ВО. Секция «Queue» содержит динамическую информацию о состоянии очередей СУПО каждого подкластера вычислительного ресурса. Публикуемая динамическая информация получается от СУПО. 
Структура секции следующая: 
 
    "Queue": [ 
        { 
             "CEInfo": "example.com/batch-A", 
             "Feature": [ "mpi", "single" ], 
             "ACL": { 
                 "Rule": [ 
                     "VOMS:/nnn-vo-0", 
                     "VOMS:/nnn-vo-1", 
                     "VOMS:/nnn-vo-2/group1", 
                     "VOMS:/nnn-vo-3/Role=VO-Admin" 
                 ] 
             } 
             "MaxWallTime": 6000, 
             "MaxTotalJobs": 100, 
             "MaxRunningJobs": 50, 
             "RunningJobs": 30, 
        } 
    ] ... 
 

Программные продукты и системы  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
№ 1, 2012 г. 

10

В приведенном примере динамической информацией является количество запущенных заданий 
(«RunningJobs»). 
Следует обратить внимание на то, что данная 
секция, как и секция «Software», имеет подсекцию 
«ACL» и позволяет указать права доступа к очереди членам ВО. Возможна и более детальная спецификация доступа на основе ролей и групп пользователей в данной ВО. Параметры очередей 
СУПО устанавливают политику администрации 
вычислительного ресурса по отношению к потребленным компьютерным ресурсам, таким как 
время счета и максимальное количество доступных вычислительных ядер. Таким образом, данная 
секция позволяет информировать пользователей 
об ограничениях на возможное количество потребляемых ресурсов. 
Секции «Software» и «Queue» совместно обеспечивают эффективный и гибкий механизм управления доступом к вычислительным ресурсам. 
Информация с каждого ресурса агрегируется 
специальным RESTful-сервисом InfoSys2Hub, собирающим информацию с сайтов, опубликованных в сервисе регистрации грид-сервисов ГридННС, с учетом их режима работы («работает» или 
«тестируется»). Такая структура позволяет потребителям информационного сервиса иметь дело с 
единственной точкой входа в инфраструктуру. Регистрация нового ресурса автоматически приводит 
к появлению информации о нем в ИС, изменения 
состояния сайтов также отражаются в общей ИС. 
Безопасность ИС построена на использовании 
цифровых сертификатов стандарта X.509 инфраструктуры публичных ключей (PKI). Доступ к сервису предоставляется конечному набору потребителей в соответствии с конфигурацией сервиса. 
В заключение необходимо отметить, что в процессе разработки ГридННС был решен ряд прин
ципиальных вопросов создания грид-инфраструктур на основе RESTful-грид-сервисов. 
В частности, реализована ИС как RESTful-сервис, обеспечивающий публикацию информации о 
состоянии ресурсов, ее агрегацию со всех доступных для пользователей ресурсов, предоставление 
ее потребителям. 
В качестве формата обмена информацией был 
использован JSON. Его гибкость позволила реализовать подмножество публикуемых параметров, 
которые описаны в GLUE Scheme 2 – стандарте 
для построения ИС в грид-инфраструктурах.  
Использование RESTful-сервисов дало возможность применять HTTP-протокол не только 
как транспортный, но и по его прямому назначению – как протокол запросов с ясной семантикой. 
Это обусловило значительное упрощение сериализации и десериализации информации, что повысило надежность системы. 
В ближайшее время планируется внедрение 
данной версии ИС в инфраструктуру ГридННС в 
качестве основной. 
 
Литература 
 
1. Foster I. and Kesselman C. The Globus Project: A Status 
Report // In Proc. Heterogeneous Computing Workshop, IEEE 
Press, 1998, pp. 4–18. 
2. Fielding R.T. Architectural styles and the design of networkbased software architectures // Doсtoral dissertation, University of 
California, Irvine, 2000. 
3. Реализация программного интерфейса грид-сервиса Pilot 
на основе архитектурного стиля REST / Демичев А. [и др.] // 
Вычислительные методы и программирование. 2010. Т. 11.     
С. 62–65. 
4. Демичев А., Крюков А., Шамардин Л. Принципы построения грид с использованием Restful-веб-сервисов // Программные продукты и системы. 2009. № 4. 
5. K.Zyp: A JSON Media Type for Describing the Structure 
and Meaning of JSON Documents // Technical report, IETF Network Workong Group, draft-zyp-json-schema-02, March 2010. 
 
 
 
 

УДК 519.688 

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА АВТОМАТИЗАЦИИ  
ПАРАЛЛЕЛЬНОГО РЕШЕНИЯ БУЛЕВЫХ УРАВНЕНИЙ  
НА МНОГОЯДЕРНЫХ ПРОЦЕССОРАХ 
 
Г.А. Опарин, д.т.н.; В.Г. Богданова, к.т.н. 
(Институт динамики систем и теории управления Сибирского отделения РАН, г. Иркутск,  
oparin@icc.ru, bvg@icc.ru) 

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