Объектные технологии в распределенных системах

Спецификации COSS и CF

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

Почва для новых идей в области технологий использования вычислительных ресурсов появилась с созданием микропроцессоров в середине семидесятых годов и новых средств обработки информации на их основе - персональных компьютеров - в начале восьмидесятых. Относительная дешевизна и автономность ПК обусловили их широкое проникновение на рынок массовых средств обработки информации, (который, собственно, и возник с появлением ПК), в основном, в сфере бизнеса. Быстрое развитие индустрии аппаратного и программного обеспечения для ПК привело к тому, что сегодня мировой парк ПК насчитывает сотни миллионов машин и созданы сотни тысяч приложений для них. Однако, наряду с многочисленными удобствами, обусловившими столь широкое распространение ПК, системы обработки информации на их основе имеют и недостатки. Сильная децентрализация вычислительных ресурсов на основе ПК приводит к возникновению ряда проблем. Прежде всего необходимо было решить проблему разделения (передачи) данных между ПК. Надо сказать, что такая проблема не стояла во времена, когда группа пользователей использовала мэйнфреймы, так как в них данные находились географически в одной точке (на одном диске). Проблема передачи данных между ПК привела к интенсивному развитию локальных и глобальных вычислительных сетей. Сети решили многие проблемы обмена информацией между компьютерами, но их ограниченная пропускная способность побудила исследователей искать новые решения. задач эффективной распределенной обработки информации. Слишком найряжеиный трафик в сети при обмене данными между большим количеством компьютеров привел к развитию технологии -"клиент сервер" в области хранения данных, И на самом деле, например, общие файлы удобнее хранить на файловом сервере, выделенном специально для их хранения, что также приводит к большей сохранности данных. Оказалось, однако, что применение технологии клиент-сервер только в области разделения данных оказалось в некоторых случаях мало эффективным и также приводило к большой нагрузке сети. Представим себе, например, приложение, выполняющееся на рабочей станции в сети и осуществляющее поиск заданной строки в файле, находящемся на файловом сервере. Для того, чтобы найти слово длиной, скажем, в десять символов в многомегабайтном файле, этот файл потребуется полностью перекачать с сервера на рабочую станцию сетевым окружением клиентской машины. Теперь представьте, что такие действия осуществляются десятью машинами одновременно. Ясно, что в таком и подобных примерах, возможности сетевого оборудования, даже ультрасовременного, сводятся на нет недостатками использованной модели применения технологии клиент-сервер. Ведь если бы файловый сервер имел функцию обработки запроса на поиск указанного слова в указанном файле, то не пришлось бы "гонять" десятки мегабайт информации по сети. Приложение, использующее эту функцию, получилось бы распределенным, так как использует код, выполняющийся на различных компьютерах для достижения одной цели. В сущности, распределенные приложения представляют собой расширение технологии клиент-сервер в область разделения не только данных, но и кода. В качестве примеров наиболее распространенных приложений такого типа можно привести современные СУБД, использующие технологию "клиент-сервер", такие как INGRES, ORACLE, INFORMIX и многие другие. В них клиент работает с базами данных посредством обращения к серверной части с помощью языка SQL (Structured Query Language), что приводит к выполнению сервером соответствующих процедур: поиска, замены, вставки и других. Вообще говоря, указанные СУБД не могут считаться полноценными распределенными, вследствие некоторой однобокости в смысле разделения функций между частями распределенного приложения, Под уаспределенным приложением в дальнейшем будем понимать совокупность процессов, выполняющихся различными процессорам в сети, либо на одном компьютере, причем всякий, в общем случае, процесс может выступать в операциях удаленного вызова как клиентом, так и сервером. Развивая идеи распределенных вычислительных сред Фонд открытых систем (OSF - Open Systems Foundation) разработал и стандартизовал технологию ВСЕ (Distributed Computing Environment) в качестве инструментария, используемого для создания распределенных приложений.

Преимущества объектного подхода

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

Проблем, возникающих при разработке распределенных систем, очень много. Распределение имен между сервисами, описание интерфейсов между удаленными частями приложения, протоколы передачи и тому подобные тонкие вопросы даже сами по себе достаточно сложны, а ведь, кроме их решения, требуется еще увязать все в единую работающую систему. Решение такой сложной задачи может привести к непредсказуемым ошибкам и нестыковкам, что приведет к неоправданным затратам времени и средств на создание конкретных распределенных приложений. Но ведь существует хорошо изученный подход для реализации программных проектов, экономящий массу времени и средств. Это объектный подход к проектированию и реализации проекта. Объектные технологии позволяют на стадии проектирования абстрагироваться от деталей реализации системы и сконцентрироваться на основных концепциях. Большинство возможных ошибок может быть выявлено еще на стадии проектирования, при этом сокращаются затраты времени и средств. А реализовать тщательно спроектированную систему не представляет особого труда, так как никаких неожиданных препятствий при этом не возникает. Способность объектного подхода упрощать сложное уже нашла свое применение в СУБД, мультимедиа и других приложениях. Практически все разрабатываемые и перспективные существующие операционные системы также основаны на объектных технологиях (NextStep, Taligent, Microsoft Cairo, Spring). Кроме того, даже принципиальные свойства объектов упрощают работу с ними в гетерогенных системах. Например, инкапсуляция позволяет программисту унифицировать метод адресации объекта в системе, вместо того чтобы поддерживать идентификаторы процессов и данных одновременно. Взаимодействие между объектами осуществляется путем передачи сообщений (вызова методов), что вкупе с сильным разделением интерфейсов объектов от их внутренней реализации представляет собой идеальную основу для построения распределенных систем.

Цель - расиределенные объектные системы

Невозможно приступать к разработке конкретных распределенных приложений, основанных на объектной технологии, без предварительной стандартизации многих аспектов таких приложений, например, архитектуры подсистемы передачи сообщений по сети, для того, чтобы система получилась "открытой" для других приложений и систем. Поэтому еще в 1989 году усилиями одиннадцати компаний была создана OMG (Object Management Group). Среди этих компаний были такие ведущие производители и поставщики оборудования и программного обеспечения, как DEC, Hewlett-Packard, NCR и SunSoft. Это предопределило авторитет OMG в указанной области; сегодня в этой ассоциации насчитывается более 500 участников, среди которых как производители программного и аппаратного обеспечения, так и компании-пользователи, также заинтересованные в конечных продуктах, университеты и т. п. Все это говорит о том, как перспективны объектные технологии в разработке и реализации распределенных вычислительных систем. OMG занялась выработкой рекомендаций по реализации различных аспектов распределенных объектных вычислительных систем. Результатом этой деятельности явилось создание обзора под названием ОМА (Object Management Architecture, Архитектура Управления Объектами), включающего в себя следующие спецификации: CORBA (Common Object Request Broker Architecture, Обобщенная Архитектура Посредника Объектных Запросов), COSS (Common Object Services Specification - Обобщенная Спецификация Объектных Сервисов) и CF (Common Facilities - Обобщенные Средства).

CORBA

Целью работы OMG было и есть создание обобщенной модели распределенной объектной системы, которая позволила бы разделять объекты, написанные на любом языке программирования, между приложениями, созданными на любом другом языке и которая работала бы при этом в гетерогенной сети компьютеров под управлением различных операционных систем.

ОМА представляет собой полный набор рекомендаций по созданию распределенных объектных систем, среди которых основной, несомненно, является CORBA, так как решает базовые вопросы взаимодействия объектов и описывает позволяющие делать это механизмы, независимые от языка реализации приложения, операционной системы, сетевых протоколов и т. п. Первая версия CORBA была выпущена OMG в октябре 1991 года. Следующая версия - 1.1 - в марте 1992 года, и, наконец последняя версия документа - 2.0 была выпущена в декабре 1994 года. Надо сказать, что версии 1.0 и 1.1 оставляли некоторые области, такие как, например, система уникальных идентификаторов объектов в сети, неопределенными, в результате чего появилось много реализаций стандарта, не совместимых друг с другом. В качестве примеров можно привести: Snap от Template Software, DEC-ORB от DEC, ILOG Broker/Server от ILOG Inc. Поэтому стандарт CORBA 2.0 содержит спецификацию взаимодействия различных реализаций посредника объектных запросов (ORB). Она предпола-

гает использовать в качестве моста между удаленными посредниками объектных запросов механизм двустороннего динамического синтеза интерфейса вызываемого объекта с помощью Dynamic Sceleton Interface (Динамический Скелетный Интерфейс), введенного только в спецификацию CORBA 2.0. Этот механизм будет рассмотрен нами чуть позднее.

Описание CORBA начнем с описания объектной модели, используемой в стандарте. Прежде чем определять архитектуру взаимодействия объектов, необходимо определить архитектуру самих объектов. Поэтому CORBA содержит описание собственной объектной модели и называет ее "классической". Объекты могут посылать и принимать сообщения от других объектов и изменять при этом внутреннее состояние. В операции передачи сообщения передающий объект-клиент посылает сообщение объекту-серверу, сообщение при этом содержит идентификатор целевого объекта и параметры запроса, которых может и не быть. Объектная модель OMG полностью разделяет интерфейс объекта от его реализации. Более того, сама модель имеет дело только с интерфейсами объектов, при этом термины "интерфейс" объекта и его "тип" являются синонимами. Такое разделение позволяет абстрагироваться от конкретного языка реализации объектов и используется уже другими объектными технологиями (например, технология OLE).

Реализация ссылок на объекты также ограничена обобщенным понятием Object Reference (которое закреплено в базовом типе объектной модели OMG) и разрешается при трансляции объекта из Языка Описания Интерфейсов (IDL - Interface Definition Language) в язык реализации (В CORBA 2.0 есть возможность трансляции в С и С++). Основные объектные понятия - инкапсуляция, наследование и полиморфизм реализуются синтаксически в Языке Описания Интерфейсов.

Язык Описания Интерфейсов

Наиболее общий механизм, предоставляемый ORB, который описывается в стандарте CORBA, для взаимодействия удаленных объектов, предполагает использование Языка Описания Интерфейсов в качестве средства для доступа к удаленным сервисам. Целью создания IDL была возможность описания интерфейсов объектов независимо от языка реализации самого объекта. В пользу использования такого подхода можно сказать, что он уже используется и в других областях, в частности, в операционных системах (например, ОС Spring), для описания интерфейсов между прикладными программами и ядром. CORBA IDL очень похож на язык С с использованием некоторых конструкций языка С++ и предоставляет возможность описывать такие характеристики интерфейсов, как имена, типы параметров и возвращаемого результата методов описываемых объектов. Полное описание интерфейсов, адекватное созданному на конкретном языке программирования, достигается описанием соответствия между IDL и языком реализации объектов:. серверов и клиентов. При реализации на базе ORB конкретных приложений, IDL-описания интерфейсов используемых объектов транслируются в наборы функций доступа к ORB, которые затем связываются с исполняемым модулем. IDL использует, в общем, такую же лексику, как и С++, вводя в тоже время ряд новых ключевых слов, характерных для распределенных систем. Поэтому описание интерфейсов на IDL очень похоже на описание классов в С++. Так как IDL создан лишь для описания интерфейсов, то в нем отсутствуют конструкции, характерные для обычных языков программирования, например, средства управлении памятью, конструкции условного ветвления и т. п. Также нет разделения описываемого интерфейса на закрытую (private) и открытую (public) части, поскольку используемая в CORBA объектная модель предполагает разделение интерфейса объекта от его реализации (все методы, внесенные в IDL-описание, являются общими). Объектная модель OMG строго типизирована. Типы объектов используются для описания возможных операций над объектом. Заранее определены две категории типов: Базовые (Basic) и Сложные (Constructed). Базовые типы объектов представляют собой фундаментальные типы данных: знаковые и беззнаковые длинное и короткое целое, 32 и 64-битные числа с плавающей запятой (стандарт IEEE), символы таблицы ISO 55890 (Latin 1), булев, перечисление, цепочка символов, а также произвольный тип - Any. Введен также специальный тип 8-битных данных - Octal, применение которого гарантирует сохранение порядка следования байт при передаче данных между различными системами.

Сложные типы базовой модели объектов OMG представляют собой сущности более высокого уровня, важнейшей из которых является тип Interface (интерфейс). Объект имеет данный тип, если удовлетворяет набору операций, определяемому типом. Другие типы включают в себя Struct (структура), Sequence (последовательность), Union (объединение) и Array (массив). Структуры и объединения имеют такой же смысл, как и в С. Последовательность определяет массив произвольной длины, состоящий из объектов какого-либо одного типа, включая последовательность. Массив имеет фиксированную длину и состоит из объектов одного типа.

Рассмотрим теперь подробнее архитектуру Посредника Объектных Запросов, предложенную OMG (в дальнейшем ORB). Именно ORB управляет взаимодействием объектов-клиентов и серверов. Управление заключается в установлении связи между клиентом и сервером, передаче запроса вместе с параметрами и возврат результата. При этом ORB должен обеспечить прозрачность всего этого процесса как для клиента, так и для сервера, т. е. запрос должен происходить также, как и локальный (в одном адресном пространстве). Поэтому CORBA определяет архитектуру интерфейсов, состоящих из трех существенных компонент: клиентский интерфейс, интерфейс сервера (интерфейс реализации запрашиваемого объекта - implementation-side interface) и ядро ORB.

Клиентский интерфейс обеспечивает объекту-клиенту взаимодействие с ORB и с объектомсервером. Он состоит из трех базовых интерфейсов: IDL stub, Интерфейс динамического вызова (Dynamic Invocation) и Интерфейс сервисов ORB (ORB services). IDL stub - интерфейс представляет собор функции, сгенерированные на основе IDL-определений интерфейсов, и "слинкованные" с клиентской программой. (Stub - набор функций на языке программы-клиента, сгенерированный из описания интерфейса объекта-клиента на языке описания интерфейсов). Таким образом, возможности ORB могут быть доступны программам-клиентам, написанным на любом языке программирования, если stub на используемом языке может быть получен из описания интерфейса на IDL. В настоящее время стандарт CORBA поддерживает соответствие между IDL и С, IDL и С++, и планируется включение в стандарт языка Smalltalk При использовании интерфейса IDL stub объекты программы-клиента взаимодействуют с объектом-сервером просто вызывая функции, сгенерированные из IDL-описания, как и для локальных объектов.

Когда интерфейс объекта, с которым будет работать программа-клиент, неизвестен во время компиляции, используется интерфейс динамического вызова (Dynamic Invocation Interface). Этот интерфейс предоставляет механизм запроса к объектам, интерфейс которых становится известным лишь во время выполнения программы, в отличие от IDL- stub интерфейсов. Интерфейс динамического вызовы доступен через ряд вызовов ORB, в которых указывается тип объекта, тип запроса и параметры. Программа-клиент при этом должна указать параметры вызова и знать тип возвращаемого результата. Эта информация может быть получена также из хранилища интерфейсов (Interface Repository). CORBA предполагает использование хранилища интерфейсов и хранилище реализаций объектов (Implementation Repository), как альтернативу IDL. Хранилище интерфейсов позволяет получать информацию об интерфейсе объекта-сервера по его идентификатору, используя набор постоянных объектов, предоставляющих эту информацию. CORBA 2.0 обеспечивает механизм глобальных идентификаторов, которые являются уникальными для всех участвующих во взаимодействии Посредников Объектных Запросов (ORB) и всех репозиториев. Эти идентификаторы могут быть сгенерированы системой во время регистрации объекта-сервера (так генерируется UUID-Universally Unique Identifier в DCE) или указаны пользователем как уникальный префикс в IDL-описании объекта. Implementation Repository содержит информацию, которая позволяет ORB находить и активизировать объект-сервер для осуществления динамического запроса. CORBA также предлагает использовать Implementation Repository для хранения другой полезной информации об объекте, например, отладочную административную информацию и. т. п. CORBA ничего не говорит о внутренней реализации Interface Repository и Implementation Repository, так что производители конкретных CORBA-совместимых систем могут реализовать их различными способами, что не влияет, однако, на совместимость этих систем, так как интерфейсы унифицированы.

Возможно, многие программы будут пользоваться IDL stub для получения доступа к объектам-серверам, что, несомненно, более эффективно, чем использование Dynamic Invocation. В любом случае, для объекта-сервера оба способа запроса выглядят совершенно одинаково.

Последний способ доступа программы-клиента к ORB, специфицируемый стандартом CORBA, называется ORB Services Interface (Интерфейс сервисов ORB) и представляет собой набор функций ORB, которые доступны прямо из клиентской программы. К примеру, когда требуется получить ссылку на объект, удобнее всего воспользоваться именно этим интерфейсом. Детали реализации этого интерфейса полностью не описаны в стандарте и могут варьироваться в реализациях разных производителей. ORB Services Interface представляет собой единственный интерфейс ORB, который доступен как для объектов-клиентов, так и для серверов. Рассмотрим теперь интерфейсы, предоставляемые ORB для объектов-серверов (Implementation-side Interfaces). Кроме ORB Services Interface (то есть прямого API к сервисам ORB), объектам-серверам предлагается унифицированный механизм доступа к ORB, называемый Object Adapter (объектный адаптер). Конкретные реализации ORB могут иметь различные реализации объектных адаптеров, специфические сервисные системы, например, объектные СУБД в своей реализации ORB могут использовать объектный адаптер, оптимизированный для выполнения конкретных запросов. Поэтому CORBA 2.0 предусматривает два стандартных интерфейса более высокого по отношению к Object Adapter уровня: Static Skeleton и Dynamic skeleton Invocation. Первый представляет собой набор функций, сгенерированный на основе IDL-описания интерфейса объекта-сервера, используемый ORB для вызова метода объекта-сервера, запрошенного объектом-клиентом. Второй (впервые введенный в CORBA 2.0) позволяет осуществлять соединение с объектом-сервером прямо во время запроса. Dynamic Skeleton Invocation Interface проверяет параметры, принимаемые объектным адаптером, и определяет адрес запрашиваемого объекта и вызываемый метод. Такая техника вызова методов объекта-сервера, как уже отмечалось выше, используется при организации мостов передачи сообщений между несколькими посредниками объектных запросов. Это удобно, так как при этом не требуется хранение интерфейсов объектов в каждом репозитории интерфейсов. Dynamic Skeleton Invocation Interface может принимать как статические, так и динамические запросы от клиентов. Очевидно, что максимальное быстродействие достигается при использовании статических интерфейсов, а интерфейс динамического вызова позволяет достичь высокой гибкости системы. Вызов каркасных методов из обоих интерфейсов производится ORB через Object Adapter Interface (интерфейс объектного адаптера), который также может использоваться непосредственно для работы с объектом-сервером. Интерфейс объектного адаптера в сущности представляет собой набор из трех раздельных интерфейсов: закрытый интерфейс к Static й Dynamic skeleton, закрытый интерфейс к ядру ORB (ORB core) и открытый интерфейс для прямого использования объектами-серверами. Функции интерфейса объектного адаптера заключаются в обеспечении доступа объекта-сервера к следующим сервисам ORB. создание и интерпретация ссылок на объекты, вызов методов, функции обеспечения безопасности, регистрация и инициализация объектов, преобразование ссылок на объекты при передаче. CORBA предлагает использовать ряд различных типов Object Adapter Interface для использования с различными типами объектов. Стандарт описывает наиболее общий тип интерфейса - Basic Object Adapter (ВОА). ВОА должен поддерживаться каждой конкретной реализацией Посредника Объектных Запросов (ORB) - таково требование спецификации CORBA. ВОА позволяет использовать различные схемы реализаций объектов в качестве серверов: от использования в качестве методов сервера отдельных программ, до использования отдельных программ для каждого типа объектов и до использования раздельного доступа через один адаптер к методам различных объектов одного типа. Кроме того, CORBA описывает некоторые специальные типы Object Adapter Interface для обеспечения доступа к объектам, хранимым в объектно-ориентированных базах данных и в библиотеках.

Чем же занимается Object Adapter? Прежде всего, регистрирует новые классы объектов в хранилище реализаций, где хранятся прототипы объектов-серверов. Как уже отмечалось, хранилище реализаций может быть реализовано произвольным способом, так как управляется только объектным адаптером. Кроме того, к функциям объектного адаптера относятся: генерация рабочих версий объектов-серверов по прототипам во время обработки запросов, назначение объектам уникальных идентификаторов (о которых мы уже говорили выше), сообщение другим объектам о существовании зарегистрированного сервера и обработка входных запросов к объектам-серверам (поддержка очередей запросов, планирование и поддержка приоритетов запросов).

Object Adapter используется в качестве интерфейса верхнего уровня при передаче сообщений между удаленными системами. В качестве же интерфейса нижнего уровня, используемого ядром ORB при передаче сообщений по сети, выбран IIOP (Internet Inter-ORB Protocol), являющийся по сути тем же TCP/IP с определенным форматом поля сообщения, позволяющим ему выполнять роль "посредника между посредниками". Используемый в IIOP формат сообщения поддерживает представление данных для всех определенных в IDL типов и оптимизирован для представления семантики межобъектных сообщений. Протокол IIOP стандартизован лишь в спецификации CORBA 2.0 и предусматривает также множество необязательных протоколов, объединенных под общим названием ESIOPs (Environment-Specific Inter-ORB Protocols). В частности, в среде ВСЕ можно использовать в качестве ESIOP протокол RPC для повышения скорости передачи сообщений.

Спецификации COSS и CF

Спецификация COSS, входящая в ОМА наряду с CORBA, определяет набор объектов-серверов, предлагающих такие фундаментальные сервисы, как поддержка жизненных циклов объектов, постоянных объектов, генерация событий, поддержка взаимозависимых объектов, поддержка транзакций при выполнении операций, а также распознавание конфликтов при обращении к сервисным объектам. Позднее планируется включить в COSS объекты, выполняющие функции безопасности информации в распределенных приложениях, лицензирования доступа к сервисам, а также поддержки версий доступных сервисов.

Для создания основы под разработкой реальных распределенных приложений, в ОМА введена спецификация Common Facilities (CF), которая концентрируется на общих сервисах уровня приложения, в отличие от CORBA и COSS, концентрирующихся на низкоуровневых операциях, обеспечивающих общую работоспособность распределенного приложения. Спецификация СЕ определяет набор объектов-серверов, поддерживающий работу пользователей с распределенным приложением и включающий такие сервисы, как печать, почта, работа с базами данных, доски объявлений и составные документы. OMG определяет эти сервисы как наиболее часто используемые в распределенных системах. Наиболее интенсивно развивается сейчас технология составных документов. Наиболее известные примеры: OLE 2.0 от Microsoft, OpenDoc от Apple, OpenStep от Next. Существование упомянутых, уже реально используемых технологий к моменту принятия Common Facilities Specification, позволило, тем не менее, благодаря сходству используемых в упомянутых системах объектных моделей, выработать рекомендации по интеграции указанных технологий в единую распределенную систему на основе CORBA, кроме OLE 2.0 от Microsoft, так как используемая Microsoft объектная модель - СОМ (Component Object Model) существенно отличается от принятой OMG "классической" модели. Это различие заключается, в основном, в способах реализации наследования и реализациях механизма экспорта интерфейса, предлагаемых CORBA и СОМ.

Заключение

Нельзя сказать, что принятые ОМА рекомендации полностью избавят теперь разработчиков распределенных приложений от возможных проблем, так как многие рекомендации носят общий характер и, кроме того, не выяснен вопрос интеграции систем, основанных на СОМ (например, широко распространенная технология OLE 2.0 компании Microsoft). Отрадно, однако, что при принятии описанных стандартов был учтен опыт уже разработанных распределенных систем, основанных как на ранних стандартах CORBA, так и на технологии ВСЕ, что позволяет интегрировать уже созданные системы во вновь создающиеся, сохраняя сделанные инвестиции, Стандарт CORBA 2.0 предлагает возможность использования DCE/RPC в качестве протокола нижнего уровня при функционировании системы из нескольких ORB. Будем надеяться, что в будущем использование распределенных вычислительных систем позволит полноценно использовать все имеющиеся ресурсы. Важные шаги для достижения этого уже сделаны.

НПФ "КАРИ", г. Ярославль E-mail: kari@univ.unijar.ac.ru