Асратян Р.Э., Лебедев В.Н. Средства информационного взаимодействия в современных распределенных гетерогенных системах

Оглавление

Предисловие

Развитие глобальной информационной среды и Internet-технологий в настоящее время происходит по нескольким направлениям:

• стремительное увеличение объемов информационных ресурсов по всевозможным предметным областям;
• значительное увеличение числа пользователей за счет широких возможностей подключения к Internet;
• совершенствование средств и методов сбора, структурирования, представления и поиска информации в Internet-пространстве и т.д.

В [1] авторы данной работы, анализируя некоторые задачи, возникающие в рамках последнего из перечисленных выше направлений, акцентировали внимание на двух взаимосвязанных подходах:

• совершенствование формы представления публикуемой в Internet информации, основанное на методах формализованного представления знаний и позволяющее более точно и содержательно проводить анализ контента сайтов ("Семантический Web");
• совершенствование технологии поиска, основанное на использовании архитектур распределенных многоагентных систем (РМАС).

Идея реализации механизма поиска информации в Internet в форме распределенной многоагентной системы родилась еще в конце 90-х годов. Появление данного подхода обусловлено сразу несколькими факторами:

• распределенной формой хранения информации в Internet;
• разнородностью этой информации (сегодня Internet содержит информацию практически по всем направлениям человеческой деятельности);
• новым взглядом на механизм поиска как на электронного помощника или референта, способного не только найти необходимую информацию, но и обработать ее в соответствии с поставленной человеком задачей.

Например, реализация поисковых систем на основе РМАС позволяет модифицировать существующих и создавать новых агентов, не оказывая существенного влияния на работоспособность системы в целом.

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

В [1] предложена концепция Internet-протокола RFPP (Remote File Package Protocol – протокол удаленной обработки пакетов файлов), который имеет ряд простых и удобных для программистов механизмов удаленного взаимодействия программных модулей.

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

Исследования, проведенные в 2008 году, показали, что RFPP может эффективно применяться при решении следующих задач:

• поддержка информационного взаимодействия в распределенных гетерогенных информационно-управляющих системах (ИУС);
• создание технологической электронной почты с гарантированной доставкой;
• разработка поисковых агентов и их взаимодействие в РМАС для поиска информации в Internet-пространстве;
• создание защищенных тоннелей с использованием сетей общего пользования (Internet) для поддержки удаленных взаимодействий между корпоративными частными сетями.

Один из перспективных подходов к построению современных информационно-управляющих систем заключается в их декомпозиции на множество взаимодействующих между собой программных компонент (агентов), каждый из которых обеспечивает решение какой-то частной задачи. Современные распределенные информационно-управляющие системы (РИУС) могут включать сотни и тысячи программных компонент, функционирующих на серверах и рабочих станциях, разнесенных на сотни и тысячи километров. Удовлетворение базисных требований к системам управления (надежность, информационная безопасность, масштабируемость, многоагентность и т.п.) невозможно без создания эффективных средств информационного взаимодействия компонент системы в разнородной сетевой среде. Сегодня уже никто из разработчиков не относится к этим средствам как к второстепенному обслуживающему механизму. Наоборот, пришло четкое осознание, что они представляют собой "системообразующую конструкцию", определяющую архитектуру РИУС, принципы ее функционирования, стиль и средства ее разработки и конечную эффективность.

Несмотря на наличие большого количества современных сетевых средств и протоколов на базе TCP/IP (TELNET, FTP, SMTP/POP3, HTTP и т.п.), разработчики распределенных систем управления сталкиваются с целым рядом проблем [1,2]. В большинстве случаев разработчики вынуждены пользоваться широко-известными Интернет-службами и протоколами, изначально спроектированными для решения совсем других задач: поддержки массовых коммуникаций (SMTP/POP3), электронной прессы (HTTP) и т.п. Возникающие проблемы в значительной степени связаны с тем, что упомянутые сетевые технологии не обеспечивают достаточную надежность и устойчивость сетевых обменов, а их семантика не вполне адекватна потребностям распределенных систем. Поэтому, создание специализированных сетевых технологий, специально ориентированных для поддержки взаимодействий в распределенных системах управления является актуальной задачей.

С точки зрения потребностей разработки распределенных систем, все наиболее распространенные сетевые протоколы и Интернет-службы (см. Приложение 1) не свободны от ряда фундаментальных недостатков, например:

• во всех этих службах (кроме электронной почты) отсутствуют собственные средства межсерверного взаимодействия и межсерверной маршрутизации данных в сети. Другими словами все они ориентированы на работу в однородной сети, допускающей прямое сетевое соединение между любыми двумя узлами. Вместе с тем, соображения безопасности все чаще заставляют разработчиков РИУС "прятать" серверы и рабочие станции системы в частных локальных сетях с отказом от однородности сети. В этих условиях возможность взаимодействия через цепочку серверов (т.е., через узлы-посредники) становится совершенно необходимой.
• отсутствие в службах надежных встроенных средств защиты от несанкционированного доступа существенно осложняет задачу обеспечения информационной безопасности. Имеющиеся, например, в HTTP или РОРЗ средства защиты слишком примитивны и не могут быть признаны удовлетворительными.
• все распространенные Internet-службы весьма требовательны к качеству каналов связи и чувствительны к сетевым сбоям. Наверное, многим знакома ситуация, когда вследствие разрыва сетевого соединения результаты длительной работы, например, CGI-приложения или Web-сервиса оказываются потерянными. Этот недостаток особенно характерен для Internet-служб, которые обычно относят к классу "online", т.е. служб, реализующих все фазы взаимодействия (передача параметров, обработка, получение результатов и т.п.) в течение одного сеанса связи. Риск потери данных объясняется тем, что эти службы, как правило, жестко ассоциируют "контекст" сеанса связи с ТСР-соединением. Поэтому, разрушение соединения означает потерю "контекста" и, как следствие, результатов обработки.

Именно этими недостатками объясняется то обстоятельство, что многие разработчики больших РИУС до сих пор прибегают к электронной почте, как к средству организации сетевых взаимодействий, т.е. отказываются от режима on-line, чтобы ослабить зависимость от существующего качества линий связи и однородности/неоднородности сети.

Понятие "контекста" сеанса связи является основополагающим для описываемой ниже сетевой службы RFPS (Remote File Packets Service – служба удаленных пакетов наборов данных) и протокола RFPP, на котором базируется эта служба [3,4]. Главной особенностью этой службы является то, что этот контекст ассоциируется не с сетевым соединением, а с новым, явно определяемым понятием – удаленным пакетом наборов данных (далее будем называть его просто "пакетом") Клиент RFPS сам открывает пакет на RFPS-сервере при необходимости удаленного взаимодействия и закрывает его, когда он больше не нужен. В промежутке между этими событиями он может наполнить пакет данными, вызвать те или иные удаленные обработчики данных, получить результаты их работы, передать пакет другому клиенту, переместить пакет с одного сервера на другой и продолжить обработку на другом сервере и т.п. Причем, все это может быть сделано или за одно TCP-соединение, или за несколько. Сохраняя идентификатор пакета, клиент всегда может восстановить контекст сеанса после случайного (или намеренного) разрыва соединения и продолжить работу.

Главная цель разработки RFPS заключалась в решении следующих задач.

• создание простого, интуитивно понятного средства сетевой поддержки распределенных приложений и информационно-управляющих систем.
• обеспечение защиты от потери данных в условиях некачественных каналов связи.
• обеспечение возможности межсерверного взаимодействия и межсерверной маршрутизации данных.
• преодоление "водораздела" между т.н. "online" и "offline"-взаимодействиями. Фактически, применительно к RFPS термины "online" и "offline" скорее характеризуют стиль "поведения" клиента, а не являются имманентными свойствами протокола.

Об авторах

Кандидат технических наук, доцент, ведущий научный сотрудник лаборатории "Распределенные автоматизированные информационные системы" Института проблем управления им. В.А. Трапезникова Российской академии наук.

Виталий Николаевич ЛЕБЕДЕВ

Кандидат технических наук, доцент, заведующий лабораторией "Распределенные автоматизированные информационные системы" Института проблем управления им. В.А. Трапезникова Российской академии наук.