Структура модуля интеграции

Модуль построен на базе стандартного модуля LMS Moodle типа «Блок».

Модуль можно разделить на несколько частей:

Базовые классы (классы ядра), организующие работы модуля в целом.

Средства Moodle, такие как языковые пакеты и библиотеки, с помощью которых организуется доступ к данным LMS Moodle.

Шаблоны вида, реализующие пользовательские интерфейсы для агентов, возвращающих результаты различной структуры.

Реализация протокола для связи с мультиагентной системой. На данный момент построен на базе протокола SOAP и языка описания веб-сервисов WSDL. Классы реализующие протокол не являются базовыми, поэтому при смене протокола не нужно будет вносить системные изменения в модуль. При реализации протокола реализованы как клиентская так и сервисная части, то есть модуль может выступать как клиент, так и как сервис. Для второго случая не предусмотрен пользовательский интерфейс, сервисы создаются программистом.

Схема работы модуля интеграции

Авторизация пользователя, проверка достаточно ли у него прав для просмотра страницы или блока производится средствами Moodle.

При обращении к модулю проводится выборка из базы настроек, заданных пользователем.

Если определен шаблон вида, то он подключается и выводится, с передачей в него информации об имени сервиса, запросе к клиенту, который необходимо будет выполнить по умолчанию, а так же запросах, которые необходимо будет выполнить в фоне, если таковые определены. Каждый из запросов, информация о которых была передана, отправляется из шаблона асинхронно (то есть каждый следующий запрос отправляется не дожидаясь результата выполнения предыдущего). Каждый запрос отправляется к скрипту, который проверяет переданные параметры, получает из базы данных информацию о модуле, необходимую для отправки запроса к мультиагентной системе и инициализирует клиента, если все необходимые параметры определены (такие как адрес мультиагентной системы, данные о прокси-сервере, если они определены, время ожидания отправки и ответа запроса). Если входных параметров достаточно, то отправляется запрос к мультиагентной системе, иначе возвращается флаг об ошибке. Ответ на запрос или флаг об ошибке преобразуются в строку согласно формату JSON и отправляются в шаблон, в котором происходит их обработка и вывод.

Описание интерфейсов общения с мультиагентной системой Интерфейсы общения с мультиагентной системой построены на безе библиотеки nuSOAP и включают в себя реализацию языка описания веб-сервисов WSDL и протокола SOAP.

WSDL.

Для описания интерфейса программной компоненты, включая спецификацию корректных сообщений, был разработан язык WSDL (Web Service Definition Language). Описание на языке WSDL включает в себя следующие семь составляющих:

Рис. 2.6.1. Составные части WSDL документа.

Описание типов передаваемых данных. При использовании кодирования SOAP Document оно состоит из схемы XML, определяющей корректные сообщения, получаемые программной компонентой в теле пакета SOAP.

Описание входящих и исходящих сообщений, которые связываются с описанными типами данных.

Описание операций (сервисов программной компоненты), с каждой из которых связывается входящее и исходящее сообщение.

Описание типов портов (идентификаторов программных компонент), с каждым из которых связывается некоторый набор операций.

Описание привязок (binding), связывающие типы портов и их сообщений с определенным типом кодирования тела пакета, а также с версией протокола SOAP.

Описание портов, связывающие типы портов и соответствующие им привязки с конкретными URL.

Общее описание службы (интерфейса программной компоненты) как совокупности портов.

Упрощенная структура WSDL-документа:

…

…

…

…

…

С помощью нескольких элементов обозначаются главные разделы WSDL-документа.

Пользователям и разработчикам WSDL предоставляет формализованное описание взаимодействия клиент-служба. Разработчики используют документы WSDL в качестве входной информации для генератора-посредника, который порождает клиентский код в соответствии с требованиями службы. WSDL также может использоваться и на входе динамического вызова посредника, который затем генерирует корректные запросы к службе во время исполнения. В обоих случаях цель — избавить пользователя и разработчика от необходимости разбираться во всех деталях доступа к службе.

SOAP.

SOAP — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался, в основном, для реализации удалённого вызова процедур, а название было аббревиатурой: Simple Object Access Protocol — простой протокол доступа к объектам. Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируется технологии веб-сервисов.

Сообщение SOAP выглядит так:

Заголовок SOAP является расширением, предоставляющим способ передачи в SOAP-сообщениях информации, вообще говоря не являющейся полезной для приложения. Подобная «контрольная» информация включает, например, директивы прохождения сообщения или контекстную информацию, относящуюся к обработке сообщения. Это позволяет подстраивать SOAP-сообщения под каждое конкретное приложение. Следующие непосредственно за env: Header дочерние элементы называются заголовочными блоками. Они представляют логическую группировку данных, которые, как показано позже, могут быть индивидуально адресованы SOAP-узлам, встречаемым сообщением на пути от отправителя к конечному получателю.

Тело SOAP-сообщения является обязательным элементом внутри env: Envelope, содержащим основную информацию SOAP-сообщения, которая должна быть передана из начальной точки пути сообщения в конечную.

Одна из целей SOAP — инкапсулировать функциональность, реализуемую посредством вызовов удаленных процедур, используя широкие возможности применения и гибкость XML.

Для вызова SOAP RPC требуется следующая информация:

Адрес SOAP-узла места назначения;

Имя процедуры либо метода;

Наименования и значения всех аргументов, передаваемых процедуре или методу вместе с выходными параметрами и возвращаемым значением;

Четкое разделение аргументов, используемых для идентификации web-ресурса, являющегося действительным местом назначения RPC, от аргументов, содержащих данные и контрольную информацию, используемых для обработки вызова ресурсом места назначения RPC.

Определение шаблона обмена сообщениями, а также так называемого «Web-метода», которые будут использоваться для передачи RPC.

Данные, которые могут быть переданы как часть заголовочных блоков SOAP. Эти данные не являются обязательными.

SOAP также предлагает проектировщику приложений общую функцию, называемую Web-методом SOAP, которая позволяет приложениям полностью контролировать выбор так называемого «Web-метода» — одного из GET, POST, PUT, DELETE, чья семантика определена в спецификациях HTTP Web-метод может использоваться поверх привязки. Эта функция гарантирует, что SOAP-приложения могут взаимодействовать поверх привязки образом, совместимым с архитектурными принципами World Wide Web. (Говоря кратко, простота и масштабируемость Web существует в значительной степени благодаря существованию множества «общеупотребительных» методов (GET, POST, PUT, DELETE), которые могут быть использованы для взаимодействия с любым ресурсом Web посредством URI.) Функция SOAP Web-метод поддерживается HTTP-привязкой SOAP, хотя, в принципе, она доступна и для всех других привязок SOAP к нижележащим протоколам.

Преимущества SOAP:

Обеспечивает взаимодействие программных систем независимо от платформы.

Использование интернет-протокола HTTP обеспечивает взаимодействие программных систем через межсетевой экран.

Недостатки SOAP:

Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки.

Хотя SOAP является стандартом, различные программы часто генерируют сообщения в несовместимом формате. Например, запрос сгенерированный AXIS-клиентом, не будет понят сервером WebLogic.

Схема сетевого взаимодействия системы Moodle и мультиагентной системы.

Moodle и мультиагентная система «общаются» по принципам взаимодействия веб-сервисов:

Клиентское приложение инициализирует SOAPClient.

SOAPClient читает файлы описания методов веб-сервиса (WSDL).

SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет на сервер. Возможно использование любого транспортного протокола, но, как правило, используется HTTP.

Пакет принимает серверное приложение, создает объект SOAPServer и передает ему пакет запроса.

SOAPServer читает описание веб-сервиса, загружает описание и пакет запроса в XML DOM деревья.

SOAPServer вызывает метод объекта/приложения, реализующего сервис Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту.

SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

Расчет надежности программного комплекса Надежность является комплексным свойством, которое включает в себя следующие свойства: работоспособность, сохраняемость, ремонтопригодность, долговечность.

Основное свойство, описываемое количественными характеристиками — работоспособность. Утрата работоспособности — отказ.

Количественные характеристики надежности (работоспособности) различаются для восстанавливаемых и невосстанавливаемых изделий.

Основные характеристики надежности для невосстанавливаемых изделий:

вероятность безотказной работы за время t: P (t);

вероятность отказа за время t: Q (t)= 1 — P (t);

интенсивность отказов (t) — указывает среднее число отказов, возникающее за единицу времени эксплуатации изделия;

среднее время наработки изделия до отказа T0.

Реальные значения указанных характеристик получают по результатам испытаний на надежность.

В расчетах времени до отказа t считается случайной величиной, поэтому используется аппарат теории вероятностей.

Свойства (аксиомы):

P (0)=1 (рассматривается эксплуатация работоспособных изделий);

Lim t? P (t)=0 (работоспособность не может быть сохранена неограниченное время);

(для невосстанавливаемых) dP (t)/dt?0 (после отказа изделие не восстанавливается).

Выбор показателя надежности:

Если невосстанавливаемое изделие работает однократно в течение небольшого заданного отрезка времени tзад. <

Если отказ невосстанавливаемого изделия не влечет опасных последствий и изделие работает до отказа, то надежность характеризуют средним временем наработки до отказа T.