Web call (uri2dec) open source project home page

Welcome

August 19, 2007

Перспективы применения RTC

Filed under: General — admin @ 7:03 pm

Перспективы применения RTC
Real time client (RTC) API, поставляемый вместе с Microsoft Windows XP, позволяет достаточно быстро создавать приложения, использующие стек протоколов IPv4 и IPv6 для мгновенного обмена сообщениями: текстовыми, голосовыми и видеосообщениями, а также использовать совместно используемое приложение (white board).
Часть функциональности также можно совместить с использованием Microsoft Peer-To-Peer SDK, для синхронизации совместно используемой информации в группах пользователей (поддерживается только стек IPv6, что на практике ограничивает его применение использованием в ЛВС, иначе от пользователей потребуется навык для создания туннеля IPv6 по IPv4).
Областью применения могут быть как приложения общего назначения, как:
SIP софт телефоны;
SIP софт видеотелефоны;
IM клиенты;
White board приложения,
так и некоторые другие, не столь явные, которые и будут рассмотрены ниже.
В документе ищутся отличительные черты, присущие RTC приложению и предлагается рассмотреть варианты использования этих черт для реализации эффективных приложений.
Отличительные черты, присущие RTC
Отличительной чертой RTC приложения является то, что, взаимодействуя с SIP сервером, он получает возможность получать сообщения извне ЛВС. Большинство других Интернет клиентских приложений всегда инициируют сессию с сервером первыми. В отличие от этого, RTC приложение, взаимодействуя с шлюзом, получает возможность получать пакеты извне брэндмауэра, явно не инициируя сессию. Не вдаваясь в подробности механизмов, используемых для того, чтобы пакеты принимались брэндмауэром и пересылались клиенту внутрь ЛВС, принимаем положение о том, что RTC приложение, по крайней мере, теоретически, позволяет размещать информацию в Интернет без явной организации туннеля в файрволе. В документе “Обзор SIP на конец 2006″ описываются некоторые аспекты проблем NAT и файрволов.
RTC API дает возможность передавать текстовые сообщения с заголовком. Заголовок можно использовать для различения типов сообщений.
На часть сообщений клиент может создавать автоматически ответные сообщения. На практике это означает, что удаленный пользователь может запрашивать информацию, и в пределах группы пользователь может располагать свои сервисы.
Как разновидности IM, RTC присуще тяготение к сфере B2B или, другими словами, группы пользователей формируются по профессиональному признаку или по другим объединяющим интересам. B2C вряд ли приемлемо.
В отличие от существующих служб IM RTC клиент должен предлагать интеграцию с существующей КИС, так как очевидной слабостью существующих служб IM является невозможность взаимодействия с программами и вообще, отсутствием контекста сообщения. Под контекстом имеется в виду действия, осуществляемые КИС – продажи, возврат товаров, веб ссылки и новости, по поводу которых велся обмен сообщениями. Более подробно проблемы контекста рассматриваются в документе cFrame Inc. Executive Summary Introducing “Context Messaging”. Там же рассматриваются существующие примеры, как ZapLet.
Чтобы обеспечить поддержку контекста, RTC должен инициировать или контролировать определенные процессы, в частности, с службами, поддерживающими контекстность через заголовки, тогда событие можно будет связать с сообщениями, и наоборот.
RTC предоставляет возможность создавать приложения, аналогичные Lotus Domino с потенциально меньшими затратами для пользователя.
Преимущество перед веб сервером, который может выполнять все указанные функции, кроме, собственно, прямого общения, заключается в том, что пользователю не нужно иметь веб сервер, чтобы разделять информацию с небольшой аудиторией, ограниченной группой пользователей.
Варианты использования
Очевидное применение – это мини web/ftp сервер, дающий доступ к опубликованной информации:
Текстам (веб, блоги, CVS, библиотеки текстов и программ);
Файлам известных форматов (файлообменник аудио, видеофайлов);
Сервисам (базы данных, телеметрия)
Для первых двух применений можно попробовать такие инновации, как иерархия по одному или нескольким атрибутам. Полученные файлы наследуют иерархию с того клиента, откуда они были получены. Копирование файлов нужно на случай отключения клиента от сети.
Сервисы являются обобщением первых двух применений. Возникает сложность создания сервисов, так как квалификация пользователя недостаточна, и пользователь ожидает, что такие сервисы будут ему предоставлены. Ниша ограничена, и занята ZapLet (почтовый клиент для flow).
Наиболее очевидными сервисами могут быть – прайс листы, каталоги товаров, аксессуаров, услуг и запчастей, системы заказов, аукционы, голосования, службы поддержки, в том числе – пользователей программ, call центры, где покупка отличается нечеткой формализацией (например, требуется много переговоров).
Географически распределенные системы могут быть реализованы – где требуется взаимодействие с партнерами в других городах, есть нежелание пользоваться сайтами и форумами более крупных партнеров.
Реализация сервисов
Сервисы можно распространять как плагины, кроме того, опубликовать API для написания своих сервисов, хотя, вероятно, он будет мало использоваться, однако сам факт открытия API важен.
Плагин позволяет пользователю его опубликовать в своем клиенте и реализовать доступ к КИС.
Простейший плагин предоставляет доступ к интранет веб серверу. Определенные ссылки помечаются для публикации группе пользователей, после чего они получают возможность использовать веб приложения. Это удобно, если используются бесплатные скрипты.
Другой плагин может предоставлять telnet доступ, собирая telnet пакеты и передавая их в одном. Более сложный случай, в принципе реализуемый – это удаленный desktop.
Более сложные плагины должны вызывать процедуры, используя, например, soap или реализовывать встроенный веб сервис.
Так как SIP телефоны часто снабжаются веб браузером, имеет смысл ограничиться простейшим вариантом для доступа к интранет серверу.
Рассмотрим пример клиента, ориентированного на конкретную группу пользователей, с помощью плагина доступа к интранет веб серверу.
Рекламное агентство (РА) размещает рекламу в другом городе. Так как отдача от собственного вебсервера для небольшого РА невелика, РА может рассмотреть возможность участия в веб сервисе по аукциону мест. Однако, вероятно, что такие сервисы отсутствуют или неприемлемы по разным причинам (условия размещения информации, величина платы). Вместо этого РА хочет работать с ограниченным числом других РА.
Разработка специализированного плагина может быть выполнена с использованием бесплатного RAD, как Turbo Delphi в виде веб приложения с передачей по регистрируемому протоколу IE.
История сообщений в клиенте связывает время запросов.
Архитектура клиента
Интеграция с AD/LDAP позволяет передавать звонки внутрь
Регистрируемый протокол IE. Позволяет избежать развертывания интранет веб сервера.
Проталкивание адреса веб страницы, co- browse. Позволяет вызвать формы для заполнения клиентом.

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

About Us | Site Map | Privacy Policy | Contact Us | Copyright © 2007-2011 Commandus software development group . All rights reserved. Powered by WordPress