CC BY
42
Традиционно, чтобы обработать структурированные графом входные данные, сначала структуру графа «сплющивают» в вектор и затем используют нейронные модели, которые принимают входные векторы, например многослойные персептроны и самоорганизующиеся карты, для получения итоговых обработанных данных. Такое «сплющивание» структурированного графом входа может потерять большинство топологических отношений между узлами графа.
Одной из новых моделей, позволяющих избегать подобных потерь, являются графовые нейронные сети — GNN. Они могут управляться с нециклическими и циклическими графами, направленными и ненаправленными графами, и графами с местной зависимостью от соседнего. Опытным путем было показано, что GNN могут использоваться для моделирования структурированных графом данных и что обученные GNN могут делать вывод из непредвиденных данных [2].
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Frasconi P. A General Framework for Adaptive Processing of Data Structures / P. Frasconi,
M. Gori , A. Sperduti // IEEE Trans. Neural Netw. 1998. № 5.
2. Computational Capabilities of Graph Neural Network Model / F. Scarselli , M. Gori , A. C. Tsoi,
M. Hagenbuchner, G. Monfardini // IEEE Trans. Neural Netw. 2009. № 1.
3. The Graph Neural Network Model / F. Scarselli , M. Gori , A. C. Tsoi , M. Hagenbuchner, G. Monfardini // IEEE Trans. Neural Netw. 2009. № 1.
Поступила 06.02.2012.
УДК 004.75:004.451
ТЕХНОЛОГИЯ ПОСТРОЕНИЯ РАСПРЕДЕЛЕННЫХ СЕТЕЙ САЙТОВ
А. Д. Резниченко
В статье рассматриваются принципы построения сетей сайтов с единым информационным пространством. Основной упор сделан на выделение оптимальных методов единой аутентификации пользователей и информационного обмена между различными компонентами сети.
Постановка задачи
В настоящее время сеть Интернет стала наиболее важным и актуальным источником информации. Крупные сообщества и организации нуждаются в предоставлении своей информации, разбитой по различным отраслям деятельности. В качестве критериев этого разделения могут выступать территориальное расположение (филиалы организации в различных городах, регионах, странах), сфера деятельности различных подразделений организации, отдельные персоналии и подразделения, составляющие организацию или сообщество, и т. д. Существует задача построить информационное пространство
организации, логически выделив отдельные структурные единицы.
В данный момент для реализации этой задачи используются некоторые стандартные решения. Наиболее распространенным является усложнение структуры сайта организации, выделение отдельных иерархических веток страниц и разделов, описывающих ту или иную отрасль. В результате усложняются поиск по сайту и доступ к вложенным разделам. Второй вариант решения поставленной задачи состоит в выделении независимых крупных разделов сайта, разделяемых на основе независимы1Х поддоменов. При углублении в это решение возможно
© Резниченко А. Д., 2012
также выделение отдельного независимого сайта для каждой из структурных единиц. В данном случае каждая структурная единица становится обособленной и работает независимо от остальных, информационный обмен между ними затруднен и осуществляется вручную. На наш взгляд, оптимальным решением является организация информационного пространства на основе распределенных сетей сайтов.
Принципы построения сети
Распределенная сеть сайтов — совокупность веб-сайтов, объединенных общими информационным пространством, базами данных основных структурных единиц (пользователи, подразделения и др.), расположенных на различных хостинг-платформах, осуществляющих взаимосвязь на основе определенных протоколов. В данном случае организация (сообщество) рассматривается как совокупность некоторых структурных единиц (ячеек), объединенных с общим управляющим центром.
Рассмотрим основные принципы построения данных сетей сайтов.
1. Распределение составляющих частей
Основным принципом построения сети является разделение информационного пространства на ряд сайтов по определенному признаку. Критерии выделения составляющих элементов описаны выше: территориальное и отраслевое деление, выделение персоналий и аналогичные варианты, зависящие от рассматриваемой организации или сообщества.
В указанном информационном пространстве выделяются две крупные базовые составляющие: центральный сайт и множественные сайты-сателлиты.
Центральный сайт — интернет-ресурс, отвечающий за осуществление функций контроля и мониторинга сети сайтов. Он хранит в себе базу данных пользователей, сайтов и других необходимых структурных единиц системы. На основе центрального сайта организуются техническая поддержка и сопровождение сайтов-сателлитов системы, в том числе их установка, развертывание и обновление. Совместно с центральным сайтом целесообразно создание нестандартных ресурсов, реализующих специфические функции для всех сайтов-сателлитов. Это может быть общий центральный форум проекта, интернет-магазин, объединяющий в себе товары подразделений, и другие ресурсы, основной задачей которых является агрегация данных сайтов-сателлитов. Совместно с центральным сайтом они составляют ядро системы.
Одной из основных функций централь-
ного сайта является предоставление пользователю краткой информации о сайтах-сателлитах. Обязательным условием является наличие полного списка сайтов-сателлитов системы. Рекомендуется создание информационных страниц для каждого из сайтов системы, содержащих краткое описание сайта, его региональную или персональную принадлежность, заголовки последних новостей и публикаций сайта и подобную информацию в сокращенном виде (дайджест). Состав данной информации определяется администратором сайта-сателлита.
Сайт-сателлит — элементарная структурная единица сети. Данные сайты строятся на основе одинаковых логических принципов, единой системы управления контентом и общих стандартов представления информации в данной сети. Каждый из сайтов отвечает за обслуживание одной структурной ячейки системы: региона, города, подразделения, персоны.
Предполагается, что сайты-сателлиты и центральный сайт расположены на различных хостинг-платформах и серверах, за обслуживание каждого из которых отвечает владеющая сайтом структурная единица. Таким образом, достигается ряд преимуществ:
— система является устойчивой к выходу из строя одного или нескольких элементов, в том числе не только сайтов-сателлитов, но и различных составляющих центрального сайта. Основной функционал сайтов-сателлитов не зависит от работоспособности центрального сайта системы, равно как и центральный сайт системы способен поддерживать функциональность в случае отказа некоторых сайтов-сателлитов, предоставляя пользователю краткую информацию (дайж-дест) с этих сайтов;
— значительно снижаются технические требования к аппаратной платформе для сайтов-сателлитов по причине распределения нагрузки и посещаемости по множеству сайтов в рамках сети;
— уменьшаются технические требования к аппаратной платформе центрального сайта за счет оттока посетителей на сайты-сателлиты.
Распределение информационных ресурсов сети по различным сайтам позволяет значительно сократить затраты на обеспечение аппаратной технической базы для ее функционирования.
2. Единая аутентификация
Распределение ресурсов и информации по различным сайтам требует унификации доступа ко всем информационным ресурсам. Необходимым условием в данном случае яв-
ляется введение единой для всех сайтов базы пользователей системы с выделениями им некоторых базовых прав доступа.
Для хранения учетных записей пользователей используется центральный сайт. Его средствами реализуется регистрация пользователей, открытая либо закрытая, и управление их профайлами. Таким образом, на центральном сайте системы располагается полная объемная база данных пользователей сети и их основных прав доступа к ресурсам. Каждый из сайтов-сателлитов содержит локальную копию указанной базы данных в сокращенном виде. Использование сокращенной базы данных позволяет значительно уменьшить требования к аппаратной платформе за счет облегчения выполнения запросов к базе данных. При этом способе в локальной базе данных сайта-сателлита сохраняется информация только о тех пользователях, которые хотя бы один раз авторизовались на сайте.
Авторизация пользователей на сайте может осуществляться по двум различным алгоритмам: OAuth (OpenlD) и прямая авторизация с вводом логина и пароля.
OAuth — это открытый протокол авторизации, который позволяет предоставить третьей стороне доступ к защищенным ресурсам пользователя без необходимости передавать ей логин и пароль. OAuth позволяет скрипту веб-приложения получить ограниченный доступ к данным провайдера (центрального сайта системы), если пользователь разрешает [4]. OpenID — протокол для ускоренной регистрации. Он позволяет пользователю без ввода пароля получить аккаунт на каком-либо сервисе, если он уже зарегистрирован где-то еще в Интернете [5].
Упрощенная схема взаимодействия сайта-сателлита с OAuth-сервером центрального сайта системы на примере API Яндекс. Деньги представлена на рис. 1.
Упрощенная схема аутентификации с помощью OAuth
Указанные протоколы являются наиболее распространенными в сети Интернет и используются многими крупными веб-проектами. Основным достоинством данных протоколов является безопасность данных пользователя и сложность перехвата его личной информации. Из минусов можно выделить необходимость перехода пользователя на внешние сайты ОрепГО/ОАи^-про-вайдера (подключение внешних скриптов с этих сайтов) и использование дополнитель-
ных специализированных библиотек авторизации.
Прямая авторизация является альтернативным вариантом решения поставленной задачи. При данном способе аутентификации пользователь вводит логин и пароль системы на любом сайте-сателлите и получает доступ к его ресурсам. При этом механизм аутентификации является скрытым от пользователя и происходит на стороне сервера.
Авторизация происходит по следующему алгоритму:
1) пользователь передает на сайт-сателлит логин и пароль;
2) сайт-сателлит невидимо для пользователя осуществляет запрос на сервер авторизации центрального сайта системы;
3) сервер авторизации обрабатывает запрос от сайта-сателлита и предоставляет в качестве результата в случае неудачи код ошибки, в случае успеха — массив данных пользователя, в который обязательно входят идентификатор пользователя в системе и уникальный для данного сайта-сателлита и пользователя код, который используется для идентификации сессии пользователя на сайте;
4) сайт-сателлит обрабатывает ответ сервера. При необходимости в локальной базе
данных сайта создается новый пользователь или обновляются данные существующего пользователя;
5) пользователь осуществляет вход на сайт или получает сообщение об ошибке входа.
Таким образом, аутентификация и создание локального профиля происходят незаметно для пользователя, без внешнего использования дополнительных серверов аутентификации. При каждом входе пользователя в систему осуществляются проверка его данных и обновление устаревшей информации в локальной базе сайта. Таким образом, данные пользователя, такие как его отображаемое имя, логин, контактная информация, всегда являются актуальными. Схема аутентификации представлена на рис. 2.
О
Пользователь
Сайт-сателлит
Центральный сайт
1. Передает логин и пароль
2. Запрос на авторизацию пользователя
3. Результат авторизации
. Вход пользователя на сайт-сателлит
Рис. 2
Схема прямой авторизации пользователей
Плюсами прямой авторизации пользователей являются видимая простота реализации с точки зрения пользователя, использование привычного механизма логина и пароля, отсутствие дополнительных громоздких библиотек авторизации. К минусам подобного алгоритма стоит отнести проблемы с безопасностью использования логина и пароля на сторонних сайтах и подтверждение подлинности сайта и принадлежности его к системе до ввода пользователем своих персональных данных.
3. Центральный репозиторий
Для организации множества сайтов-сателлитов и поддержки их в работоспособном состоянии требуются центральный репозиторий и система обновления используемого на
сайтах-сателлитах программного обеспечения.
Предполагается, что для всех сайтов-сателлитов в системе используется единая система управления контентом (CMS). Это информационная система или компьютерная программа, используемая для обеспечения и организации совместного процесса создания, редактирования и управления контентом, т. е. содержимым, сайта. На основе единой CMS строится унифицированное взаимодействие сайтов с центральным сервером и пользователями системы. Допускается, что центральный сайт может также базироваться на этой CMS и отличаться от сайтов-сателлитов настройкой метода аутентификации пользователей.
Обязательными требованиями к системе являются модульность ее построения и возможность сборки требуемого программного комплекса для сайта на основе готовых существующих модулей из центрального репозитория. Таким образом достигается гибкость системы и возможность оптимизации отдельных сайтов путем отключения тех или иных модулей.
В качестве используемой CMS могут выступать системы общего назначения, такие как WordPress [7], phpBB [6] и Joomla [2] со специализированными модулями аутентификации и поддержки связи между сайтами, а также специализированная система AlterVision Core CMS.
Обязательным требованием к системе является автоматическое обновление CMS всех сайтов в ее составе для поддержания актуальной версии и быстрого внедрения нового функционала. В случае с WordPress автоматическое обновление и установка модулей (плагинов) может осуществляться средствами самой CMS и ее центрального репозитория WordPress.org с возможностью инициации обновления системы и ее модулей ответственным пользователем сайта-сателлита [7]. Система AlterVision Core CMS предлагает использование центрального сервера обновлений, отвечающего за автоматическую установку новых версий ядра и модулей системы на всех сайтах сети. Данный способ позволяет детально проконтролировать процесс обновления и снизить нагрузку на сервер обновлений за счет контроля потока обновляющихся сайтов.
Рекомендуемым требованием к центральному репозиторию является система автоматического запуска сайтов. Это понятие подразумевает наличие инструментов, позволяющих осуществлять подготовку сервера, установку и запуск системы управления контентом, предварительную настройку сайта-сателлита в автоматическом режиме без участия технических специалистов. При указанном способе расширение сети сайтов может происходить автоматически путем подачи заявки на регистрацию сайта структурной единицей организации или сообщества и последующим одобрением заявки администратором.
4. Информационный обмен между сайтами
Центральный сайт системы и сайты-сателлиты являются связанными в единое информационное пространство. Для реализации этой связи необходимо осуществление быстрого и удобного обмена информацией между сайтами в автоматическом режиме.
В данном случае применяется механизм запросов, называемый Data Ping. Он является упрощенной реализацией стандарта XML-RPC. Технически Data Ping реализуется на базе стандартного GET- или POST-запроса к HTTP-серверу сайта. Обязательными полями в запросе являются его тип (идентификатор) и формат возвращаемого результата. Идентификатор запроса определяет функцию, которая отвечает за его обработку. В качестве формата представления возвращаемого результата могут использоваться следующие варианты:
— сериализованные данные PHP. При обмене информацией между скриптами, написанными на языке PHP, наиболее удобным способом передачи данных является сериализация. Она позволяет описать любые данные в качестве представления их в виде строки символов с возможностью последующего развертывания в аналогичную структуру данных на стороне сервера. Данный способ является наиболее удобным для внутреннего обмена информацией, так как не требует использования дополнительных инструментов, реализуется встроенными средствами PHP (стандартные функции serialize и unserialize) и является наиболее компактным с точки зрения объема передаваемых данных;
— формат JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком. Несмотря на происхождение от JavaScri pt, формат считается языконезависимым и может использоваться практически с любым языком программирования. Для многих языков существует готовый код для создания и обработки данных в формате JSON [3].
— экспорт переменных в JavaScript. Альтернативным вариантом для взаимодействия с JavaScri pt является использование данных, представленных напрямую на языке JS, для последующего их «выполнения» с помощью стандартной команды eval. Данный способ не требует использования дополнительных библиотек поддержки формата JSON и позволяет получить данные на любом внешнем сайте;
— XML. Взаимодействие с любыми сторонними сервисами, работающими на любых языках и платформах, может быть реализовано на основе стандартизированного описания данных в виде XML. Средства обработки XML-документов в настоящее время реализованы для всех распространенных языков программирования и позволяют полу-
чать информацию с любых источников данных. Минусом использования формата вля-ется применение дополнительных библиотек обработки данных этого стандарта и значительное увеличение объема передаваемых данных;
— XML-RPC. Расширением и уточнением использования формата XML является реализация стандарта взаимодействия на основе интерфейса XML-RPC. Плюсом данного стандарта является полная его поддержка любыми платформами. К минусам стоит отнести значительное увеличение объема передаваемых данных по сравнению с XML [8].
При реализации механизма Data Ping подразумевается возможность использования любого из описанных выше стандартов представления данных в зависимости от запроса и свободного конвертирования внутреннего представления данных в системе в любой из указанных форматов без потери информации.
Использование данного механизма позволяет запрашивать у сайтов различные данные, такие как информация о последних новостях, лента обновлений; инициировать на сайте различные процессы, например автоматическое обновление ядра и модулей, обновление данных пользователя; осуществлять аутентификацию пользователей по механизму прямой авторизации.
Дополнительной возможностью информационного обмена является использование наиболее распространенных стандартов агрегации информации. В этих целях целесообразна реализация различных протоколов альтернативного отображения данных:
— RSS/Atom протокол позволяет отображать информацию сайтов-сателлитов в качестве ленты обновлений для использования в любых сервисах автоматического сбора обновлений с сайтов. Применение протоколов RSS/Atom для экспорта информации позволяет организовать оперативное отобра-
жение необходимой актуальной информации сайтов-сателлитов в соответствующих разделах центрального сайта;
— YML-описание данных и аналогичные форматы позволяют осуществлять экспорт данных товаров и услуг, предлагаемых центральным сайтом и сайтами-сателлитами. YML (Yandex Market Language) — это стандарт, разработанный Яндексом для принятия и размещения информации в базе данных Яндекс.Маркета. YML основан на стандарте XML (XML DTD). Единый формат представления данных позволяет быстро и качественно обрабатывать предоставляемую магазинами информацию о товарах и услугах [1].
— Sitemap. Представление сайта необходимо для большинства поисковых сервисов и систем в целях удобного построения карты сайта и качественной индексации его поисковыми системами. Возможно применение данных формата для построения иерархической карты сайта-сателлита в рамках центрального сайта.
Возможно использование дополнительных форматов для передачи специфических данных поисковым системам и агрегаторам контента. В этот перечень могут входить данные словарей и энциклопедий, кулинарные рецепты, информация о вкладах и кредитах, вакансиях и различных объявлениях и прочая информация.
Вывод
Обозначенные выше принципы положены в основу построения распределенных сетей сайтов, позволяющих наиболее оптимальным образом организовать информационное пространство средних и крупных организаций и сообществ. На основе данных принципов возможны минимизация затрат на организацию программной и аппаратной платформы для указанных сетей и построение удобной иерархической структуры элементов, составляющих сеть.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Яндекс.Вебмастер передача данных о содержимом сайта [Электронный ресурс]. Режим доступа: http://www.content.webmaster.yandex.ru. Загл. с экрана.
2. Joomla! : офиц. сайт [Электронный ресурс]. Режим доступа: http://www.joomla.org. Загл. с экрана.
3. JSON // Wikipedia : Свободная электронная энциклопедия [Электронный ресурс]. Режим доступа: http://www.ru.wikipedia.org/wiki/JSON. Загл. с экрана.
4. OAuth // Wikipedia : Свободная электронная энциклопедия [Электронный ресурс]. Режим
доступа: http://www.ru.wikipedia.org/wiki/OAuth. Загл. с экрана.
5. OpenID // Wikipedia : Свободная электронная энциклопедия [Электронный ресурс]. Режим доступа: http://www.ru.wikipedia.org/wiki/OpenID. Загл. с экрана.
6. phpBB : офиц. сайт [Электронный ресурс]. Режим доступа: http://www.phpbb.com. Загл. с экрана.
7. WordPress : офиц. сайт [Электронный ресурс]. Режим доступа: http://www.wordpress.org. Загл. с экрана.
8. XML-RPC// Wikipedia [Электронный ресурс]. Режим доступа: http://ru.wikipedia.org/
wiki/XML-RPC. Загл. с экрана.
Поступила 06.02.2012.
УДК 004.9:378.141.4
ИНФОРМАЦИОННАЯ СИСТЕМА «УЧЕБНЫЙ ПЛАН» И АВТОМАТИЗИРОВАННЫЙ РАСЧЕТ НАГРУЗКИ КАФЕДРЫ ВУЗА К. Н. Нищев, А. Г. Смольянов, М. И. Новопольцев
В статье описывается часть пакета программ, предназначенных для автоматизированной обработки информации, связанной с организацией учебного процесса. Пакет программ позволяет реализовать управление потоками информации между учебным управлением, факультетами и кафедрами. Создание единого хранилища учебных планов специальностей и направлений позволяет сгенерировать «заготовки» расчетов нагрузки для любой кафедры вуза. Одна из программ пакета предназначена для дальнейшей обработки сгенерированного расчета нагрузки кафедры. Отдельная программа позволяет автоматизировать процесс распределения нагрузки между преподавателями на уровне конкретной кафедры. Вся информация организована в виде удаленных баз данных, ориентированных на платформу «клиент-сервер».
Учебный план — нормативный документ, лежащий в основе всего учебного процесса специальности (направления) вуза. Он содержит всю структурированную числовую информацию, необходимую для организации учебного процесса. Учебные планы нового поколения государственных вузов достаточно унифицированы. Это позволяет сделать их электронный аналог. Все дисциплины плана разделены на крупные блоки, например: «Общие гуманитарные и социальноэкономические дисциплины», «Общепрофессиональные дисциплины», «Специальные дисциплины и дисциплины специализации». Каждый такой блок делится на подблоки. Для стандартных блоков — это деление на группы дисциплин «федеральных», «региональных» и «по выбору». Дисциплины плана характеризуются одинаковыми наборами числовых показателей, определяющих структуру учебной деятельности по данной дисциплине. Эти показатели определяют нали-
чие зачетов, экзаменов, контрольных работ, курсовых работ по дисциплине, а также количество лекционных, практических, лабораторных занятий.
Первоначальную подготовку данных осуществляет программа AdminPlan (рис. 1).
Эта программа предназначена для подготовки списков: 1) наименований факультетов (институтов) вуза и паролей факультетов; 2) наименований кафедр; 3) наименований специальностей; 4) наименований блоков дисциплин (рис. 2); 5) наименований подблоков дисциплин (рис. 3); 6) наименований дисциплин по блокам и подблокам (рис. 4).
Система паролей разграничивает доступ пользователей к сведениям различных факультетов: каждый факультет имеет право доступа только к своим данным. Администратор всей системы имеет возможность сменить любой из паролей факультета (института) либо полностью обновить весь список паролей.
© Нищев К. Н., Смольянов А. Г., Новопольцев М. И., 2012
