М.М. Алексеенко
Корпорация LVS , тел.:330-16-06
С появлением мобильных ПК типа "лэптоп" и "ноутбук" такие служащие смогли независимо от их местонахождения подключаться к компьютерам своей компании по проводным телефонным линиям с помощью обычных модемов.
В последнее время с развитием необходимой инфраструктуры коммуникаций все большую популярность приобретает беспроводная связь через радиомодемы, обеспечивающая более высокую степень мобильности и оперативности. Сейчас в мире имеется несколько разновидностей радиосетей и соответствующих радиомодемов, использующих различные протоколы. Используются как обычные сотовые телефонные сети, так и специальные цифровые сети.
Хотя для некоторых относительно несложных применений характеристики этих альтернативных, именуемых мобильными, каналов связи могут быть приемлемы, есть задачи, например работа с базами данных, в которых использование упомянутых каналов вызывает значительные трудности. Дело в том, что в отличие от высокоскоростных и надежных локальных сетей, телефонные и особенно радиоканалы имеют намного более низкую пропускную способность при более высоких уровнях помех. Даже в современных системах клиент-сервер, где минимизируется количество данных, передаваемых между клиентским приложением и сервером БД, применяемые протоколы взаимодействия клиента и сервера оказываются для этих каналов слишком "многословными", что в итоге приводит к значительному времени отклика при выполнении транзакций, снижая к тому же вероятность их успешного завершения из-за возможного обрыва сессии. Для примера, только время установления сеанса с сервером (login) может составлять от одной до нескольких минут. Для разрешения проблемы большого времени отклика, возникающей при работе мобильных пользователей в режиме клиент-сервер по медленным каналам связи, компанией Oracle разработан новый продукт - Mobile Agents (версия 1.1), ранее (в версии 1.0) имевший название Oracle in Motion. С целью уменьшения обмена по низкоскоростным каналам уже известная модель клиент-сервер трансформирована здесь в новую - "клиент-агент-сервер". Отличие этих моделей можно проиллюстрировать следующим образом:
Как можно видеть, в новой модели работа мобильных клиентов по низкоскоростным линиям сводится к минимуму с переносом основного трафика в локальную сеть. При такой модели работы каждое приложение разбивается на две взаимодействующие части. Первая - Клиент, находится на мобильном ПК, обеспечивая пользовательский интерфейс для ввода данных и представления результатов и, возможно, некоторую локальную обработку. Вторая - Агент, располагается на компьтере в локальной сети и, выступая там "полномочным" представителем первой, выполняет по ее запросам доступ к серверам БД, другим источникам данных, различного рода сервису типа электронной почты, печати, передачи факсов и т.п. В отличие от клиент-серверной модели здесь не организуется сеанс работы (сессия) пользователя с БД. Вместо этого Клиент посылает своему Агенту обычно достаточно короткие сообщения-запросы. Получив сообщение, Агент, работая самостоятельно, выполняет запрошенное действие и возвращает Клиенту сообщение-ответ, содержащее требуемые данные или же просто информацию об успешности операции.
Для сравнения времени отклика, получаемого в каждой из моделей, примем, что средняя транзакция из нескольких операторов SQL потребует около 50 обращений к серверу (для отдельного оператора необходимо от 2 до 20 обращений), а количество данных, вовращаемых сервером, не слишком велико (несколько сот байтов). Примерные значения времени отклика при выполнении подобных транзакций для обеих моделей представлены в таблице, приведенной ниже.
Конфигурация технических средств системы, реализуемой на базе продукта Oracle Mobile Agents, включает мобильные ПК, линии мобильной связи (радио и телефонные), локальную сеть (или в более широком плане - корпоративную сеть) и подключенные к этой сети компьютер, в котором располагается центральное звено системы - Шлюз Сообщений, компьютеры, на которых работают Агенты, и компьютеры-серверы, содержащие необходимые данные. Фактически Агенты могут располагаться как на компьютере Шлюза, так и на серверных компьютерах, а функции Шлюза и сервера также могут быть реализованы на одном компьютере. Поэтому в принципе, для функционирования системы достаточно одного компьютера, поддерживающего функции всех размещаемых в локальной сети компонент системы. Реальная конфигурация определяется, исходя из технологии конкретного бизнеса и доступных аппаратных средств.
В программную часть входит ряд системных и пользовательских компонентов, размещаемых на разных участках системы. Системными компонентами являются Менеджер Сообщений (на мобильном ПК), Шлюз Сообщений и Менеджер Событий Агента. Агенты строятся из общей управляющей части в виде Менеджера Событий и прикладной пользовательской части. Клиенты полностью разрабатываются пользователями.
Логическая конфигурация системы состоит из множества узлов, каковыми рассматриваются все Менеджеры Сообщений и Агенты, и Шлюза Сообщений в качестве центрального пункта.
Общая структура система схематично может быть представлена следующим образом:
На мобильном ПК могут располагаться несколько Клиентов различного назначения. Все они посылают и принимают сообщения, используя размещенный на этом же ПК системный компонент - Менеджер Сообщений. Когда пользователь хочет послать или принять сообщения, он с помощью Менеджера Сообщений по одному из возможных каналов устанавливает связь с другим системным компонентом - Шлюзом Сообщений. Установление связи между мобильным ПК и Шлюзом всегда выполняется по инициативе пользователя. При этом он использует наиболее подходящий из доступных в конкретной ситуации каналов: радио - в дороге или необорудованном месте, телефон - дома или в гостинице, локальную сеть - у себя в офисе. Передача сообщений между Шлюзом и Агентами выполняется по локальной сети. Таким образом, все сообщения пересылаются в системе по цепочке Клиент-Менеджер Сообщений-Шлюз Сообщений-Агент.
На базе механизма пересылки сообщений в системе реализуется бессесионный, асинхронный режим работы. "Бессессионность" означает отсутствие необходимости оперативного соединения клиента с сервером. Каждое сообщение от Клиента рассматривается при этом как независимая транзакция (в широком смысле, как некоторая независимая единица работы). Соединение с сервером устанавливается впоследствии Агентом с выполнением необходимого контроля доступа для каждого сообщения. Асинхронность работы обеспечивается механизмом внутренних очередей в Менеджере сообщений, Шлюзе Сообщений и Агенте.
Пользователь может создавать очередное сообщение, не дожидаясь ответа на предыдущее и даже работая автономно, без связи по какому-либо каналу со Шлюзом Сообщений. Все сообщения Клиентов помещаются в выходную очередь Менеджера Сообщений, откуда пересылаются в Шлюз при установлении связи с ним. Шлюз, принимая сообщение, сохраняет его во внутренней очереди и пересылает далее соответствующему Агенту, когда таковой запущен на каком-либо из компьютеров в локальной сети. Принятое Агентом сообщение помещается во входную очередь и хранится там, пока не будет доступен сервер БД или другие компоненты, необходимые ему для выполнения запрошенного в сообщении действия. Аналогично сохраняется и продвигается от узла к узлу ответное сообщение, генерируемое Агентом. При таком построении системы порядок прихода ответных сообщений никак не связан с порядком отправления соответствующих запросов. Функционирование Агентов и Клиентов в системе можно рассматривать как управляемое событиями, где каждое входящее сообщение инициирует соответствующую обработку. Для поддержки такого способа работы в системе имеются различные механизмы уведомления программ обработки о поступлении им сообщений, вплоть до автоматического запуска нужного клиентского приложения на мобильном ПК.
Клиент и Агент, являясь двумя разделенными частями единого приложения, должны разрабатываться самостоятельно с учетом потребностей конкретного бизнеса. В каждом приложении для Клиента и соответствующего ему Агента определяется взаимно согласованный набор сообщений. Всякое сообщение имеет тип (номер), исходя из которого определяется структура данных в сообщении и требуемая обработка. Сообщение имеет системный заголовок с фиксированным набором полей, включая тип сообщения и адрес получателя, и переменную часть, зависящую от типа сообщения и состоящую из пользовательских данных. Для каждого типа посылаемого сообщения на принимающей стороне должна быть предусмотрена соответствующая процедура обработки.
Поскольку для Клиента, вообще говоря, не имеет значения, где конкретно в корпоративной сети функционирут Агент, а важен только обеспечиваемый им сервис, адресация Агентов выполняется по символическому имени сервиса, присваиваемого каждому типу Агента. Клиентам присваиваются те же имена, что имеют соответствующие им Агенты. При этом не требуется для каждого экземпляра Клиента иметь обслуживающий его экземпляр Агента. Все экземпляры однотипных Клиентов, расположенные на мобильных ПК, принадлежащих разным пользователям, могут разделять один экземпляр соответствующего Агента. С другой стороны, при необходимости в сети может быть запущено несколько экземпляров однотипных Агентов - в этом случае Шлюз Сообщений по кругу распределяет между ними сообщения Клиентов, выполняя элементарную балансировку нагрузки. Шлюз располагает информацией о текущем количестве Агентов каждого типа и их местонахождении в сети, поскольку при запуске Агент регистрирует себя в Шлюзе. Взаимодействие Клиента и Агента может осуществляться в трех формах. Наиболее типичной является форма: запрос от Клиента - ответ от Агента. Обычно в этом случае Клиент запрашивает какую-либо информацию от сервера или желает произвести модификацию данных на сервере. Агент при этом возвращает запрошенные данные или информирует Клиента о результате операции. Агент направляет ответ конкретному Клиенту, выдавшему запрос, поскольку адрес отправителя всегда присутствует в заголовке полученного сообщения. Этим адресом является идентификатор узла, присвоенный системой мобильному ПК пользователя. Внутри узла сообщение-ответ будет передано Клиенту, имеющему то же символическое имя, что и Агент, пославший ответ. Вторая форма взаимодействия имеет место при наличии таких типов сообщений от Клиента, когда ответное сообщение от Агента не требуется. Агент выполняет требуемое действие и не посылает обратно никаких подтверждений. Эта форма, по-видимому, будет использоваться сравнительно редко для пересылки некритичных сообщений, обычно не связанных с использованием БД. И наконец, новые интересные возможности предлагаются третьей доступной формой взаимодействия Клиента и Агента, реализуемой в архитектуре клиент-агент-сервер. Здесь сообщение инициируется самим Агентом и является его реакцией не на внешнее, поступившее от Клиента, сообщение, а на некоторое локальное событие, регистрируемое Агентом. При этом Агент может либо сам путем периодического опроса осуществлять мониторинг определенных процессов, либо его могут уведомить извне об интересующем его событии. Например, если у Агента установлена связь с сервером БД, то используя механизм сигнализации (alerts) о событиях в БД, имеющийся в современных СУБД (например в Oracle7), сервер будет информировать Агента о произошедших изменениях в БД. Агент в, свою очередь, может оповещать заинтересованных Клиентов и, тем самым, мобильных пользователей о возникновении, к примеру, таких ситуаций, как достижение критического количества какого-либо товара на складе или изменение его цены (что может быть важно для целого круга мобильного персонала), утверждение введенного ранее заказа (что может относиться к лицу, делавшему заказ) и т.п. Адресация сообщений, посылаемых Агентом, в этой схеме отличается от случая, когда Агент предварительно получает запрос и, следовательно, располагает обратным адресом в виде идентификатора узла, из которого поступило сообщение. Здесь при посылке сообщений Клиенты адресуются по имени пользователя мобильного ПК, под которым он зарегистрирован в системе. Шлюз же, зная идентификатор узла, связанного с этим пользователем, перешлет сообщение именно на его мобильный ПК.
Защита пересылаемых в системе сообщений может обеспечиватся на уровне каналов связи и на прикладном уровне. В пакетных радиосетях передача осуществляется в цифровом виде через специальные радиомодемы, выполняющие разбиение сообщений на пакеты и их сборку из пакетов, обеспечивая тем самым особый род кодирования. Хотя при этом механизме и не устраняется полностью возможность прослушивания, она все же значительно затруднена по сравнению с обычной сотовой радиотелефонией. При работе по телефонным линиям могут применяться физические ключи защиты, обеспечивающие доступ к Шлюзу только авторизованным пользователям. Система позволяет задавать для посылаемых сообщений режим автоматического сжатия данных (реализуемого программно), что помимо уменьшения количества передаваемой информации также добавляет некоторую степень защиты. В следующей версии продукта, 2.0, предполагается системная поддержка шифрации передаваемых потоков данных. Возможно применение и собственных механизмов кодирования, поскольку на вид пользовательских данных в сообщении не накладывается никаких ограничений. Доступ в саму систему возможен только для зарегистрированных пользователей после ввода их идентификатора и пароля (последний всегда шифруется).
Располагающиеся на мобильных ПК Клиенты и Менеджер Сообщений работают в среде MS Windows. Для создания Клиентов имеется комплект разработчика (Software Developer Kit), обеспечивающий быстрое построение приложений с использованием либо интерфейса OLE 2.0 Automation, либо Windows DLL. Используя любой из интерфейсов, Клиент может устанавливать связь с Менеджером Сообщений, определять механизм уведомления о поступлении сообщений (через OLE 2.0, DDE или Windows-сообщения), выбирать из входной очереди пришедшие сообщения и распаковывать их, устанавливать параметры в заголовках посылаемых сообщений, упаковывать данные и отправлять сообщения в выходную очередь. При разработке могут использоваться такие достаточно известные средства, как MS Visual Basic, MS Excel, MS Access, MS C/Visual С++, Borland C/C++, Powersoft PowerBuilder, Gupta SQL Windows, а также Oracle Developer 2000 и Oracle Power Objects.
Менеджер Сообщений (Message Manager) представляет из себя законченный системный компонент в форме Windows-приложения, которое должно стартовать до запуска Клиентов. Он имеет несложный пользовательский интерфейс, позволяющий, в частности, выбрав текущий канал, установить связь со Шлюзом или, отказавшись от связи, работать автономно, а также видеть количество входящих и исходящих сообщений для каждого Клиента во внутренних очередях Менеджера. Имея в своем составе драйверы для поддерживаемых каналов связи (пакетная радиосеть - протоколы Mobitex и CDPD, с набором номера по телефонным проводной или сотовой сети - протокол PPP, локальная сеть - протокол TCP/IP), Менеджер Сообщений обеспечивает независимость работы Клиентов от типа используемого канала. Схема взаимодействия компонентов на мобильном ПК представлена на рисунке.
Шлюз Сообщений (Message Gateway) является законченным системным компонентом, размещаемым на компьютере с ОС UNIX (для Sun, HP, IBM RS 6000) или Windows NT. В этом же узле располагается СУБД Oracle, используемая Шлюзом для хранения информации о текущей конфигурации системы, включая имена, пароли мобильных пользователей системы, перечень сервисов обеспечиваемых агентами, сетевые адреса агентов и пр. Эта информация не требует много места для ее хранения и может размещаться в БД Oracle, используемой на этом же узле для прочих целей. Однако в зависимости от числа пользователей и модели их работы в системе, следует предусмотреть резерв дискового пространства для хранения пересылаемых сообщений.
Менеджер Событий Агента (Agent Event Manager) - это системный компонент, встраиваемый в состав Агентов, которые работают на тех же платформах, что пригодны для размещения Шлюзов Сообщений. Он отвечает за связь со Шлюзом, включая регистрацию Агента и пересылку сообщений, а также осуществляет диспетчеризацию поступивших сообщений, выполняя, в зависимости от типа сообщения, вызов соответствующего, обеспечиваемого пользователем, обработчика. Количество этих обработчиков (handlers) и реализуемые ими функции специфичны для каждого приложения. Обработчики пишутся на языках C или C++ с использованием вызовов функций интерфейса того или иного источника данных, к которому необходим доступ. Например, для работы с СУБД Oracle можно использовать базовый Call-интерфейс Oracle (OCI), либо для упрощения разработки воспользоваться прекомпилятором Pro*C, позволяющим включать в программу на C непосредственно операторы языка SQL. Примерная схема построения Агента приведена ниже.
Агенты, построенные на базе Менеджера Событий, обобщенно именуются UNIX-агентами. Кроме того, в системе имеется возможность создания Агентов, работающих в среде MS Windows. Структура Windows-агента сходна со структурой Клиента, однако, являясь Клиентом особого рода, он не инициирует запросы, а принимает и исполняет их, и может не иметь какого-либо пользовательского интерфейса, присущего обычным Клиентам. Для подобных Агентов функции Мененджера Событий Агента выполняет Менеджер Сообщений, обычно размещаемый на мобильных ПК. Windows-Агенты могут быть полезны для получения каких-либо данных или сервиса, имеющихся на обычных ПК со средой Windows. Понятно, что для реализации доступа к многопользовательским серверам БД наилучшим образом образом подходят UNIX-агенты, поскольку и те и другие работают, по-существу, в одной среде на достаточно мощных и надежных компьютерах с многозадачными и устойчивыми ОС. Эти Агенты способны быстрее обрабатывать потоки поступающих запросов и требуют минимум обслуживания. Также ясно, что на ПК, где могут находиться Windows-Агенты, чаще возможно возникновение ситуаций, требующих вмешательста человека.
Для управления отдельными звеньями и всей системой в целом продукт содержит ряд утилит администрирования. Обеспечивается возможность журнального протоколирования и сбора статистики. Для облегчения построения и тестирования приложений поддерживается возможность работы в режиме "прототипа", без использования Шлюза и реальных UNIX-агентов. В продукт включено несколько образцов готовых приложений, изготовленых с применением разных средств разработки.
Данный продукт был опробован авторами в работе по локальной сети , через модемы по проводным телефонным линиям и по пакетной сети "Радиотел". В последнем случае использовались радиомодемы Radio-Pad фирмы Racal, работавшие друг с другом через промежуточную базовую станцию. Поскольку в настоящее время Oracle Mobile Agents обеспечивает работу только c радиомодемами для пакетных радиосетей RAM Mobile Data и CDPD, то при работе по сети "Радиотел" приходилось использовать те же процедуры установления связи и передачи данных, что и для телефонного канала. В качестве клиентских мест использовались ноутбук и настольный ПК с MS Windows 3.1. Шлюз сообщений, Агенты и СУБД Oracle7 (версия 7.1.6) располагались на рабочей станции SUN SPARCstation 10 c ОС Solaris 2.3. Использовались внешние телефонные модемы FasTalk II фирмы Motorola, а на ноутбуке - модем формата PC Card. Со стороны клиентских ПК поддержка протокола PPP обеспечивалась с помощью пакета PC/TCP фирмы FTP Software.