Кривопішин О.С., Поздняков А.В.
В пакетном режиме непосредственное соединение между взаимодействующими субъектами (узлами) асинхронной учебной сети [2] устанавливается лишь на время обмена пакетом сообщений, а все остальное время приложения работают независимо и асинхронно. В общем случае, такая организация взаимодействия требует распределения обучающих функций между субъектами и практически исключает возможность группировки всей логики работы учебной сети в одном узле. Таим образом, применение классической клиент-серверной модели взаимодействия, которая инкапсулирует всю логику работы на сервере, затруднительно.
Возможность асинхронной работы распределенных обучающих приложений предполагает наличие промежуточного слоя, осуществляющего управление не только распределенными обучающими объектами, а и сообщениями между ними. Из возможных вариантов реализаций промежуточного слоя возьмем для дальнейшего рассмотрения промежуточный слой, ориентированный на посылку сообщений [1], который поддерживает связь между компонентами распределенной системы посредством обмена сообщениями. В этом случае клиентские компоненты используют промежуточный слой для посылки серверу сообщения с заявкой на обслуживание, которое содержит параметры запрашиваемой операции. Результаты выполнения заявки возвращаются в другом сообщении, посылаемом сервером клиенту. Такие заявки могут быть сгруппированы в пакеты. Графически схема взаимодействия субъектов ALN в этом случае выглядит следующим образом:

Рис.1 - Схема взаимодействия субъектов ALN при помощи промежуточного слоя ориентированного на обмен сообщениями
Сильной стороной промежуточного слоя данного типа является то, что он естественным образом поддерживает асинхронную доставку сообщений. Сразу же после передачи пакета сообщений промежуточному слою, клиент возобновляет свою работу и не ожидает немедленного ответа сервера. Через какое-то время сервер отправляет пакет сообщений с результатами, который клиент может принять в удобное для себя время.
Еще одна сильная сторона промежуточного слоя такого типа – поддержка групповой рассылки. Одно и то же сообщение может быть направленно нескольким получателям так, что это будет прозрачным для клиентов. Групповая рассылка представляет собой полезный примитив для реализации механизма уведомлений о событиях, а также архитектур, основанных на подписке/рассылке.
Системы, использующие промежуточный слой, ориентированный на пересылку сообщений, позволяют достичь отказоустойчивости путем реализации очередей сообщений. Сообщения, поставленные в очередь, хранятся в долговременной памяти промежуточного слоя. Отправитель записывает сообщение в очередь сообщений. Если получатель окажется недоступен (сервер временно не работает из-за неполадок), то сообщение будет находиться в очереди до тех пор, пока получатель не сможет его принять. Как показано на Рис. 4, для реализации асинхронных заявок между клиентом и сервером используются две FIFO очереди. Очередь заявок предназначена для передачи и буферизации заявок, а очередь ответов передает и буферизирует ответы.

Рис.2 - Очереди заявок и ответов в брокере сообщений
Подобные очереди могут быть организованы на уровне пакетов сообщений, а механизм работы с очередями реализуется брокером сообщений.
В случае асинхронной работы субъектов сети с сервером, обмен сообщениями может происходить посредством обмена файлами. Для отправки сообщения на сервер специальный брокер сообщений сохраняет текст этого сообщения в файле, предварительно закодировав его (алгоритм кодирования/ декодирования определяется конкретной реализацией такого брокера).

Рис.2 – Преобразование HTTP сообщения спецификаций IMS, SCORM и AICC в структурированный файл
Дальше, посредством транспортной подсистемы файл доставляется на сервер. После того, как сервер получает файл сообщения он его декодирует и обрабатывает так же, как обычное сообщение, присылаемое по HTTP. После его обработки ответное сообщение экспортируется брокером сервера в файл, который передается назад клиенту. Пример XML-кода такого сообщения представлен ниже.
1) Клиент запрашивает значение переменной Object_GUID с сервера:
<Message>
<Header pupilId="2346" command ="LMSGetValue" create_time="23.11.2003 18:23"/>
<Parameter name="Object_GUID"/>
</Message>
2) Сервер возвращает клиенту сообщение с кодом выполнения операции, типом возвращаемой переменной и ее значением:
<Message>
<Header status="0"/>
<Response resultType="Integer" resultValue="1253"/>
</Message>
Файл обмена может содержать не одно, а группу сообщений оформленных в пакет. В таком случае сообщения будут обрабатываться последовательно по мере их поступления, либо в соответствии с их приоритетом.
Использование брокера сообщений, позволяющего обеспечить пакетный режим работы клиентских приложений и поддерживающего спецификации SCORM либо IMS обеспечит:
СПИСОК ЛИТЕРАТУРЫ