Архитектура для расширяемой системы совместной работы в реальном времени
Группа изобретений относится к средствам унифицированного интерфейса программирования приложений для написания прикладных программ, которые используют коммуникационные протоколы. Техническим результатом является обеспечение дополнительных функций совместной работы в приложении в реальном масштабе времени. Архитектура имеет объекты действий, объекты конечных точек и множество мультимедийных стеков. Эти объекты могут использовать различные коммуникационные протоколы, такие как Протокол Инициирования Сеанса или Протокол Передачи в Реальном Времени, для передачи и приема сообщений. Объекты действий, объекты конечных точек и множество мультимедийных стеков могут иметь каждый один или более интерфейсов программирования приложений (API), которые разработчик приложения может использовать для доступа или обеспечения функциональных возможностей, связанных с совместной работой. Эти объекты отображают интерфейс API на базовую реализацию, обеспечиваемую другими объектами. Использование объектов действий позволяет разработчику обеспечивать меньший объем логики приложения, чем это было бы необходимо в ином случае для обеспечения сложных сервисов совместной работы. 3 н. и 14 з.п. ф-лы, 5 ил.
Перекрестные ссылки на связанные заявки
По настоящей заявке испрашивается приоритет предварительной патентной заявки США 60/513790 от 23.10.2003, заявки 60/599807 от 06.08.2004, заявки 10/918333 от 13.08.2004 и заявки 10/918855 от 14.08.2004.
Область техники
Описываемая технология в целом относится к передаче данных и, более конкретно, к архитектуре для расширяемой системы совместной работы в реальном времени.
Предшествующий уровень техники
Различные коммуникационные приложения и протоколы обеспечивают связь между программами программного обеспечения или пользователями. В качестве примера, приложения коммуникаций в реальном времени, такие как MICROSOFT WINDOWS MESSENGER (сервис сообщений компании Microsoft Windows) и Voice over Internet Protocol (передача голоса по Интернет-протоколу) (VoIP), обеспечивают связь между пользователями, посылающими друг другу текстовые, видео- или речевые данные. Эти приложения могут использовать различные протоколы, такие как SIP (Протокол Инициирования Сеанса), RTP (Протокол Передачи в Реальном Времени), RTCP (Протокол Управления в Реальном Времени), для установления сеансов и для пересылки относящейся к передачам информации. Протокол SIP является протоколом управления уровня приложений, который устройства могут использовать для обнаружения друг друга и для установления, модификации и завершения сеансов между устройствами. Протокол RTP является протоколом для доставки аудио- и видеоданных через Интернет и часто используется в потоковых мультимедийных системах и в системах видеоконференцсвязи во взаимосвязи с другими протоколами, такими как RTCP и Н.323. Протокол RTCP представляет собой протокол, который обеспечивает возможность клиентскому приложению контролировать и управлять данными, передаваемыми или принимаемыми с использованием протокола RTP, и используется вместе с протоколом RTP. Протоколы SIP и RTP/RTCP являются стандартами, предложенными для сети Интернет. Их спецификации “RFC 3261” и “RFC 3550” доступны через Интернет по адресу www.ietf.org на /rfc/rfc3261.txt и по адресу www.faqs.org на /rfcs/rfc3550.html соответственно и включены в настоящий документ во всей своей полноте посредством ссылки.
Приложения могут дополнительно использовать другие протоколы. Приложения могут использовать усовершенствованные версии вышеуказанных протоколов или другие отличающиеся протоколы, которые предназначены для пересылки специализированных данных. В качестве примера, когда становится доступным новый или усовершенствованный протокол для пересылки информации видеоконференцсвязи, разработчику приложения, создающему или модифицирующему приложение, может оказаться желательным использовать новый или усовершенствованный протокол, например, для улучшения рабочих показателей или предоставления дополнительных функций. Для использования нового или усовершенствованного протокола разработчику приложения может потребоваться модифицировать части приложения, которые взаимодействуют с коммуникационными протоколами, поскольку усовершенствование протокола или новый протокол могут иметь интерфейс, отличающийся от того, который ранее использовался. В качестве примера, хотя протокол может иметь интерфейс NewSession (новый сеанс) для создания нового сеанса, усовершенствованная версия может включать в себя метод StartSession (запуск сеанса), который создает и запускает сеанс и получает дополнительные параметры. Поскольку StartSession получает дополнительные параметры, его интерфейс отличается от NewSession, и поэтому приложение, использующее NewSession, может потребовать модификации для использования StartSession. Если протокол имеет отличающийся интерфейс, разработчикам приложений может потребоваться изучить этот отличающийся интерфейс и модифицировать свои приложения для использования этого интерфейса, чтобы применять протокол.
Разработчикам приложений может потребоваться изучение детальных особенностей каждого из множества коммуникационных протоколов, которые они используют в разрабатываемых приложениях. В качестве примера, если разработчик приложения использует протокол SIP или RTP/RTCP, разработчику приложения может потребоваться изучить все три протокола, чтобы обеспечить программную логику, связанную с этими протоколами. Разработчику приложения, не знакомому со всеми тремя протоколами, может потребоваться дополнительное обучение и время для знакомства со всеми этими протоколами. Кроме того, если приложение должно модифицироваться для работы с дополнительными или усовершенствованными протоколами, разработчику приложения может потребоваться пересмотреть или дополнить логику программирования, чтобы приложение могло функционировать с этими протоколами. Это может привести к дополнительным расходам и трудностями в разработке.
Кроме того, различные протоколы представляют множество сложностей. Например, для обеспечения функции видеоконференцсвязи в приложении, разработчику приложения потребовалось бы ознакомиться с рядом протоколов и обеспечить логику для координации этих протоколов для дополнения возможностей видеоконференцсвязи. Дополнение к приложению других возможностей совместной работы, таких как передача текстовых сообщений, передача речевых сообщений и т.д. представляет другие подобные проблемы.
Таким образом, весьма полезной была бы архитектура для расширенной системы совместной работы в реальном времени, которая облегчает добавление функций обеспечения совместной работы в приложение без существенных инвестиций в подготовку разработчиков.
Сущность изобретения
Предложена архитектура для расширенной системы совместной работы в реальном времени. Эта архитектура представляет унифицированный интерфейс программирования приложений (API) для написания прикладных программ, которые используют коммуникационные протоколы. Архитектура имеет объекты действий, объекты конечных точек и множество мультимедийных стеков. Эти объекты могут использовать различные коммуникационные протоколы, такие как SIP (Протокол Инициирования Сеанса), RTP (Протокол Передачи в Реальном Времени), для передачи и приема сообщений, содержащих информацию. Объекты действий, объекты конечных точек и множество мультимедийных стеков могут иметь каждый один или более интерфейсов программирования приложений (API), которые разработчик приложения может использовать для доступа или обеспечения функциональных возможностей совместной работы. Эти объекты отображают API на базовые реализации, обеспечиваемые другими объектами. Использование объектов действий позволяет разработчику обеспечивать меньший объем логики приложения, чем это было бы необходимо в ином случае для обеспечения сложных сервисов совместной работы.
Краткое описание чертежей
Фиг.1 - блок-схема, иллюстрирующая компоненты архитектуры для расширяемой системы совместной работы в реальном времени согласно возможному варианту осуществления.
Фиг.2 - блок-схема, иллюстрирующая компоненты объекта конечной точки расширяемой системы совместной работы в реальном времени согласно возможному варианту осуществления.
Фиг.3 - блок-схема, иллюстрирующая объекты действий расширяемой системы совместной работы в реальном времени согласно возможному варианту осуществления.
Фиг.4 - блок-схема, иллюстрирующая процедуру "Создание серверной конечной точки" согласно возможному варианту осуществления.
Фиг.5 - блок-схема, иллюстрирующая архитектуру расширяемой системы совместной работы в реальном времени согласно возможному варианту осуществления.
Детальное описание
В возможном варианте осуществления предусмотрена архитектура для расширяемой системы совместной работы в реальном времени. Архитектура обеспечивает высокоуровневый интерфейс программирования приложений (API) для написания прикладных программ, которые используют коммуникационные протоколы для обеспечения сервисов совместной работы. Разработчик приложения может добавить сервисы совместной работы к приложению с использованием интерфейса API без необходимости изучения сложностей, связанных с различными базовыми протоколами, которые реализуют сервисы совместной работы.
Эта архитектура содержит объекты действий, объекты конечных точек и множество мультимедийных стеков. Эти объекты могут использовать различные коммуникационные протоколы, такие как SIP или RTP/RTCP, для передачи и приема сообщений. Каждый из объектов действий, объектов конечных точек и множества мультимедийных стеков может иметь один или более интерфейсов API, которые могут использоваться разработчиком приложения для доступа к функциям или обеспечения функций, предоставляемых объектами. Разработчик приложения может выбрать вариант обеспечения логики приложения, которая использует интерфейсы API, предоставляемые объектами конечных точек или мультимедийными стеками, или может выбрать вариант обеспечения логики приложения, которая использует интерфейс API, обеспечиваемый объектом действия. За счет использования интерфейсов API, обеспечиваемых объектами конечных точек или мультимедийными стеками, разработчик приложения получает возможность проявить высокую степень гибкости, но должен обеспечивать существенно больший объем логики приложения, чем в случае использования только интерфейса API объекта действия. Разработчик приложения может выбрать вариант использования интерфейса API объекта действия по различным причинам. Интерфейс API объекта действия обеспечивает более высокоуровневый интерфейс, чем интерфейсы API объекта конечной точки и мультимедийных стеков. Кроме того, объекты действий координируют объект конечной точки и мультимедийный стек и, таким образом, для выполнения координации не потребуется создание логики приложения.
Объекты действий обеспечивают сервисы для приложений и других объектов. Объекты действий представляют собой объекты, которые позволяют приложению участвовать в множестве различных действий и могут включать в себя, например, мгновенную передачу сообщений, телеконференцсвязь, видеоконференцсвязь, совместное использование приложений и другие действия. Объекты действий могут рассматриваться как объекты «в оболочке», которые обеспечивают функции лежащих в их основе (базовых) объектов, включая объекты конечных точек и мультимедийные стеки. В частности, объекты действий координируют объекты конечных точек и мультимедийные стеки для обеспечения непрерывного и интегрированного сеанса связи с другими объектами, использующими объекты действий, такими как приложения.
В качестве примера выгоды от использования объекта действия может служить следующее. Разработчику приложения может оказаться желательным обеспечить возможности видеоконференцсвязи в приложении. Для этого разработчик приложения должен был бы сначала познакомиться с протоколом сигнализации, таким как протокол SIP, и мультимедийным протоколом, таким как протокол RTP/RTCP. Затем разработчик приложения должен был бы обеспечить логику приложения для создания сеанса, определить, имеется ли в текущий момент онлайновый контакт с лицом, с которым желательна видеоконференцсвязь, послать приглашение присоединиться к видеоконференции, согласовать различные параметры, касающиеся видеоконференции, получить аудио- и видеоданные от аппаратных средств получения аудио- и видеоданных и, наконец, осуществить обмен аудио- и видеоданными с использованием протокола RTP/RTCP. В противоположность этому, при использовании объекта действия, соответствующего видеоконференцсвязи, согласно предложенной архитектуре, многие из этих этапов исключаются, поскольку этот объект действия, соответствующий видеоконференцсвязи, специально предназначается для консолидации логики прикладной программы в несколько высокоуровневых интерфейсов. Предложенная архитектура имеет подобные объекты действий для ряда других действий, связанных с совместной работой. Кроме того, эта архитектура обеспечивает поддержку для дополнительных объектов действий, которые должны дополнительно вводиться в будущем.
Объект конечной точки обеспечивает сервисы администрирования, такие как сигнализация. Объект конечной точки включает в себя компоненты профиля, публикации/подписки, сигнализации и стека протоколов. Компонент профиля может обеспечивать абстрактное описание пользователя посредством интерфейса API. Компонент публикации/подписки обеспечивает интерфейсы для отслеживания информации присутствия и доступности, относящейся к пользователям. Компонент сигнализации может использоваться для обеспечения или приема редких транзакционных сообщений, относящихся к установлению или управлению сеансами связи. Компонент сигнализации может также использоваться для согласования, например, параметров среды передачи, например лимита ширины полосы. Компонент стека протоколов используется компонентами профиля, публикации/подписки и сигнализации для посылки или приема данных и поддерживает различные протоколы, включая протокол SIP.
Как описано выше, объект действия обеспечивает инструмент для разработчиков приложений, позволяющий простым способом дополнительно вводить сервисы совместной работы в приложения. В качестве примера, разработчик приложения, желающий добавить функцию видеоконференцсвязи в приложение, может обеспечить логику для создания (или «реализации») объекта действия, соответствующего видеоконференцсвязи. Объект действия, соответствующий видеоконференцсвязи, может затем создать объект конечной точки для сигнализации (например, объект конечной точки протокола SIP) и мультимедийный стек для передачи сообщений, чтобы осуществить пересылку аудио/видеоданных. В процессе последующих действий видеоконференцсвязи (например, при посылке или приеме потока аудио/видеоданных) объект действий может координировать объекты при их создании или реализации (создании экземпляра). В одном варианте осуществления приложение может создавать объекты и дополнительно обеспечивать индикацию объектов для объекта действия. В таком случае объекту действия не требуется создавать эти объекты.
Объекты мультимедийного стека обеспечивают сервисы передачи содержимого, такие как обработка потока аудио/видеоданных. В качестве примера, объект мультимедийного стека может использовать протокол RTP/RTCP для посылки или приема аудиовизуальной информации, относящейся к видеоконференции.
На фиг.1 показана блок-схема, иллюстрирующая компоненты архитектуры для расширяемой системы совместной работы в реальном времени согласно возможному варианту осуществления. Архитектура для расширяемой системы совместной работы в реальном времени содержит объект 102 сервиса совместной работы, множество объектов 104 конечных точек, объекты 106 действий и множество мультимедийных стеков 108. Одно или более приложений 110 могут использовать архитектуру путем доступа к различным методам, свойствам и событиям, связанным с архитектурой. Разработчик приложения, создающий приложение, может использовать архитектуру путем применения унифицированного интерфейса API вместо необходимости изучения и реализации различных интерфейсов API для каждого мультимедийного стека, протокола или другого компонента, который может использовать приложение или архитектура.
Объект 102 сервиса совместной работы обеспечивает инструмент для приложений, чтобы совместно использовать множество объектов конечных точек, и может обеспечивать совместимые интерфейсы API для ряда объектов конечных точек. В качестве примера, если объект 1 конечной точки обеспечивает интерфейс, связанный с приемом (или посылкой) информации, объект 2 конечной точки аналогичным образом обеспечивает интерфейс, связанный с приемом (или посылкой) информации, но два интерфейса используют различные имена, однако выполняют сходные функции, то объект сервиса совместной работы может обеспечить общее имя для обоих интерфейсов. Если разработчик приложения использует это общее имя в приложении, то разработчику приложения не нужно пересматривать приложение в случае, когда новый или модифицированный объект, который обеспечивает интерфейс с отличающимся именем, используется с объектом сервиса совместной работы.
Объекты 104 конечных точек обеспечивают инструмент для сигнализации о других объектах. Сигнализация может быть использована между двумя объектами конечных точек, для которых имеет место сеанс, например, так что объект конечной точки может пригласить или запросить другой объект конечной точки осуществить действие или обменяться информацией, связанной с сеансом. В качестве примеров, объект конечной точки может пригласить другой объект конечной точки к диалогу с мгновенной передачей сообщений и затем может передать текстовые сообщения, относящиеся к диалогу. Объекты конечных точек описаны ниже более детально со ссылкой на фиг.2.
Объекты действий являются компонентами, которые обеспечивают возможность приложению участвовать в различных действиях, связанных с совместной работой. Эти компоненты обеспечивают интерфейс API, который разработчик приложения может использовать для координации объектов конечных точек и мультимедийных стеков. Объекты 106 действий описаны ниже более детально со ссылкой на фиг.3.
Объект 108 мультимедийного стека обеспечивает сервисы передачи содержимого, такие как обработка потоков данных, и обеспечивает интерфейс API для других объектов для посылки или приема данных. Архитектура может поддерживать виртуально бесконечное количество мультимедийных стеков ввиду того, что архитектуре не требуется проводить различия между различными типами данных или сред передачи. В результате новые мультимедийные стеки могут быть добавлены, или мультимедийные стеки могут быть модифицированы, по мере того как изменяются требования. Примером мультимедийного стека является протокол RTP/RTCP. Этот мультимедийный стек может быть использован для посылки аудиовизуальной информации.
На фиг.2 показана блок-схема, иллюстрирующая компоненты объекта конечных точек расширяемой системы совместной работы в реальном времени, согласно одному варианту осуществления. Объекты конечных точек обеспечивают сервисы администрирования, например, инструмент для сигнализации о других объектах. Сигнализация может быть использована между двумя объектами конечных точек, для которых имеет место сеанс, например, так что объект конечной точки может пригласить или запросить другой объект конечной точки осуществить действие или обменяться информацией, связанной с сеансом. В качестве примеров, объект конечной точки может пригласить другой объект конечной точки в сеансе к диалогу с мгновенной передачей сообщений и затем может передать текстовые сообщения, относящиеся к диалогу.
Данная архитектура может поддерживать различные объекты конечных точек, и каждый объект конечной точки может быть реализован многократно. В качестве примера, может иметься объект конечной точки, относящийся к персональной пользовательской учетной записи провайдера Интернет-сервиса (например, MSN.COM), и другой объект конечной точки, относящийся к корпоративной пользовательской учетной записи Интернет (например, MICROSOFT.COM). Пользователь может зарегистрироваться у провайдеров сервисов с использованием персональной учетной записи на множестве устройств (например, на портативном вычислительном устройстве и на настольном вычислительном устройстве), а также может зарегистрироваться с использованием корпоративной учетной записи на некоторых из устройств (например, на настольном вычислительном устройстве). Таким образом, может иметься два экземпляра, относящиеся к указателю URI (универсальный идентификатор ресурса), связанному с персональной учетной записью. Индивидуальные экземпляры объектов конечных точек могут быть затем уникальным образом идентифицированы посредством комбинации универсального идентификатора ресурса (URI) и идентификатора конечной точки (EID). В качестве примера, объект конечной точки может быть идентифицирован с помощью URI вида user@MSN.COM и с помощью EID вида “1234”. Как описано выше, идентификатор EID может быть использован для конкретного различения экземпляра объекта конечной точки от другого экземпляра объекта конечной точки, который связан с тем же самым указателем URI.
Объект конечной точки может обеспечить интерфейс «данные» и интерфейс «сигнализация». Интерфейс данных может включать в себя методы, события, свойства, относящиеся к данным, которые опубликованы или абонированы объектом конечной точки. Путем публикации или подписки на данные приложение может обеспечивать данные или уведомляться об изменениях в данных. Интерфейс сигнализации может обеспечивать способы, события и свойства, относящиеся к управлению сигнализацией для объекта конечной точки. В качестве примера, характеристики сигнализации могут включать в себя создание или присоединение к сеансам, вхождение в диалог или выход из диалога, принятие приглашений или отказ от приглашений и другие сигналы.
Показанный на чертеже объект 200 конечной точки содержит компонент 201 профиля, компонент 202 публикации и подписки, компонент 204 сигнализации и компонент 206 стека протоколов.
Компонент профиля может обеспечивать абстрактное описание пользователя посредством интерфейса API. Он поддерживает сервисно-связанную информацию для пользователя, такую как электронный адрес (например, URI), мандат (учетная запись с параметрами доступа пользователя, сформированными после его успешной аутентификации), используемый для провайдера сервиса, статус провайдера сервиса, возможности и стратегии. Пользователи могут иметь более одного профиля на провайдера сервиса. Компонент профиля может быть использован при создании сеансов связи с другими пользователями, например, для обеспечения пользовательского URI. Компонент профиля обеспечивает методы для входа в систему или выхода из системы для пользователя в связи с провайдером сервисов.
Компонент публикации и подписки обеспечивает интерфейсы для отслеживания информации присутствия и доступности, относящейся к пользователям. Информация доступности связана с тем, присутствует ли пользователь на конкретном вычислительном устройстве. Информация доступности связана с тем, доступен ли присутствующий пользователь для приема сообщения или желает ли он этого. В качестве примера, пользователь сотового телефона может быть присутствующим, когда его сотовый телефон включен, но может быть недоступным для сеанса связи с передачей сообщения, когда пользователь участвует в телефонном вызове. Аналогичным образом, пользователь, установивший индикацию «занято» в MICROSOFT WINDOWS MESSENGER, может присутствовать, но быть недоступным для передачи сообщений.
В качестве еще одного примера, объект присутствия может обеспечивать информацию, относящуюся к пользователю, который присутствует и доступен для участия в диалоге MICROSOFT WINDOWS MESSENGER с использованием вычислительного устройства, а также доступен для участия в телеконференции с использованием сотового телефона. Если пользователь больше не зарегистрирован в MICROSOFT WINDOWS MESSENGER, объект присутствия может обновить эту информацию, так чтобы приложение, использующее объект присутствия, могло определять, что пользователь больше не присутствует или не доступен для участия в диалоге MICROSOFT WINDOWS MESSENGER. Таким образом, информация присутствия указывает, присутствуют ли пользователи или другие объекты. Различные провайдеры сервисов или протоколы могут использовать различные механизмы для формирования или обеспечения информации присутствия. Для того чтобы разработчику приложения не требовалось знать о множестве путей выработки или обеспечения информации присутствия, разработчик приложения может использовать объект конечной точки для выработки или использования информации присутствия.
Компонент публикации/подписки обеспечивает интерфейс подписки для создания подписки на публикацию другого объекта, интерфейс публикации для обеспечения подписок на другие объекты и интерфейс уведомления для приема уведомлений, связанных с сервисами, на публикации которых была осуществлена подписка. Эти интерфейсы позволяют приложению использовать компонент для обеспечения, приема или отслеживания информации присутствия. В качестве примера, если пользователь участвует в диалоге MICROSOFT WINDOWS MESSENGER с использованием персонального компьютера и участвует в телеконференции с использованием сотового телефона, компонент публикации/подписки может обнаруживать и сообщать о присутствии пользователя в обоих местоположениях. Указатель URI и идентификатор EID могут совместно уникальным образом идентифицировать экземпляры объектов конечных точек. Поскольку пользователь может присутствовать во множестве местоположений одновременно, указатель URI пользователя может быть указан как присутствующий в этом множестве местоположений. Добавление идентификатора EID во взаимосвязи с заданным указателем URI обеспечивает механизм однозначно определенной идентификации конкретного экземпляра присутствия.
Уведомления могут быть обеспечены в связи с различной информацией. В качестве примера, могут быть обеспечены уведомления в отношении того, является ли пользователь интерактивным, занятым, доступным, отсутствующим на время обеда и т.д. Уведомления могут также обеспечиваться в связи с территориальным местоположением пользователя (например, как это обеспечивается Системой глобального позиционирования GPS), контактной информацией, календарной информацией, сообщениями вне офиса, аудио/видеорежимом и т.д.
Компонент сигнализации может также использоваться для обеспечения или приема нечастых транзакционных сообщений, относящихся к установлению или управлению сеансами связи. Этот компонент может также использоваться для согласования, например, параметров среды передачи, таких как число кадров в секунду.
Объект стека протоколов отвечает за передачу и прием информации с использованием протокола. В качестве примера, протокол SIP может использоваться для посылки или приема информации сигнализации. В различных вариантах осуществления равным образом могут быть использованы другие протоколы. В одном варианте осуществления объект конечной точки может быть совместимым с множеством протоколов. В таком случае объект конечной точки может иметь возможность использовать, например, множество протоколов, если необходимо, для посылки и приема информации. Альтернативно, архитектура может поддерживать множество комбинаций объектов конечных точек и протоколов в качестве отдельных объектов конечных точек. В таком случае один объект конечной точки может использоваться для протокола SIP, а другой - для некоторого другого протокола.
На фиг.3 показана блок-схема, иллюстрирующая объекты действий расширяемой системы совместной работы в реальном времени согласно возможному варианту осуществления. Объекты действий обеспечивают сервисы для приложений и других объектов. Объекты действий являются объектами, которые позволяют приложению участвовать во множестве конкретных действий и могут включать в себя, в качестве примера, мгновенную передачу сообщений, телеконференцсвязь, видеоконферненцсвязь, совместное использование приложений и другие действия. Объекты действий могут рассматриваться как объекты «оболочки», которые обеспечивают функциональность базовых объектов, включая объекты конечных точек и мультимедийные стеки. В частности, объекты действий координируют объекты конечных точек и мультимедийные стеки для обеспечения непрерывного сеанса связи с объектами, использующими объекты действий, такие как приложения.
Каждый объект действия обеспечивает функциональность, которая позволяет приложению, использующему объект, принимать участие во множестве действий. В качестве примера, объект действий может инкапсулировать информацию сигнализации и среды передачи. При этом объект действий может служить мостом между сигнализацией и средой передачи, так что приложение, использующее объект действий, обеспечивается в интегрированном виде. Например, разработчику приложения необходимо просто запросить видеоконференцию, а не устанавливать отдельные соединения и сеансы связи протоколов SIP и RTP/RTCP. Иллюстративные примеры действий описаны ниже.
Объект 304 действия сеанса совместной работы позволяет приложению обеспечивать сервисы совместной работы для пользователей приложения. В качестве примера, объект действия сеанса совместной работы может позволить двум пользователям, применяющим два разных компьютера, совместно работать над созданием совместно используемого документа.
Объект 310 действия совместного использования приложения позволяет приложению, использующему объект действия совместного использования приложения, обеспечивать функциональность, относящуюся к совместному использованию приложений между пользователями, применяющими различные вычислительные устройства. В качестве примера, два пользователя могут совместно использовать приложение «белая доска», с использованием которой пользователь может обеспечивать визуальную информацию, которую может просматривать и которой может манипулировать другой пользователь.
Объект 306 действия передачи сообщений позволяет приложениям обеспечивать возможности передачи сообщений для пользователей приложения. В качестве примера, разработчику приложения может оказаться желательным разрешить передачу сообщений в приложении, которое создает разработчик. В качестве примера, когда два пользователя совместно работают над документом путем одновременного редактирования документа, пользователям может оказаться желательным иметь возможность посылать текстовые сообщения друг другу или участвовать в видеоконференции в процессе совместной работы. В таком случае разработчик приложения может использовать объект действия сеанса совместной работы, а также объекты действий передачи сообщений и видеоконференцсвязи для обеспечения возможности пользователям осуществлять совместную работу и обмениваться сообщениями друг с другом в процессе совместной работы.
Объект 308 действия видеоконференцсвязи обеспечивает инструменты видеоконференцсвязи для приложения. Видеоконференцсвязь может предусматривать посылку и прием аудиовизуальной информации.
Также возможны и другие объекты действий, которые представлены как объекты 312 действий.
Разработчик приложения может использовать объекты архитектуры, описанные выше (и те, что не перечислены или не описаны), путем использования интерфейсов API, обеспечиваемых этими объектами. Эти объекты могут обеспечивать простой для использования интерфейс API, так что разработчику приложения не требуется ссылаться на интерфейсы API, обеспечиваемые базовыми компонентами, которые предоставляют сервисы, связанные с объектами действий. В качестве примера, провайдер сервиса передачи сообщений может обеспечить интерфейс API, который разработчик может использовать. Для этого разработчику может потребоваться потратить время на изучение этого интерфейса API, который может быть довольно сложным. Вместо этого разработчику может оказаться желательным использовать более простой интерфейс API, обеспечиваемый объектом архитектуры. Кроме того, объект может инкапсулировать этапы, которые могут потребоваться для использования множества других объектов. В качестве примера, разработчику приложения, желающему обмениваться сообщениями с двумя компьютерами, может потребоваться использовать интерфейс API, обеспечиваемый протоколом SIP, а также интерфейс API, предоставляемый другим объектом низкого уровня, который обеспечивает услугу передачи сообщений. В противоположность этому, разработчику приложения следовало бы использовать только объект действия, соответствующий передаче сообщений, и тем самым иметь возможность добавить функцию передачи сообщений к приложению намного более простым путем. Кроме того, архитектура может действовать для координирования множества объектов, тем самым требуя от разработчика приложения создания меньшего объема логики программирования.
В одном варианте осуществления сеанс совместной работы содержит и использует объекты действий.
На фиг.4 показана блок-схема, иллюстрирующая процедуру "Создание серверной конечной точки" согласно возможному варианту осуществления. Процедура вызывается приложением для создания объекта конечной точки, которая соединяется с сервером. Когда создана конечная точка, которая соединяется с сервером, информация, которую он публикует, может быть доступной для объектов, имеющих на это подписку, даже после того как созданная конечная точка больше не функционирует.Таким образом, конечная точка, соединенная с сервером, может обеспечить информацию «на каждый URI», что означает, что информация остается доступной после истечения срока жизни объекта.
Процедура начинается на этапе 402. На этапе 404 процедура создает новый объект конечной точки и указывает, что конечная точка связана с приложением. Указанное приложение может быть обеспечено как параметр для создания функции, которая действует для создания конечной точки. При создании конечной точки может быть обеспечено «дружественное» (удобное) имя, чтобы можно было ссылаться на эту конечную точку по этому удобному имени. Альтернативно, на вновь созданную конечную точку можно ссылаться по уникальному идентификатору, связанному с конечной точкой. Этот уникальный идентификатор может генерироваться системой, когда объект создан.
На этапе 406, после создания конечной точки, приложение может зарегистрировать вновь созданный объект конечной точки для сервера, чтобы обеспечить возможность серверу маршрутизировать сообщения к этой конечной точке. После приема запроса регистрации от объекта конечной точки сервер может направить запрос аутентификации к конечной точке. Запрос аутентификации может содержать «область», используемую сервером. Область может указывать имя домена, связанное с сервером. В качестве примера, сервер может направить запрос аутентификации с областью “MICROSOFT.com.”
На этапе 408 процедура отвечает на запрос аутентификации предоставлением мандата (например, ИД и пароля пользователя), связанного с приложением. Этот мандат может быть введен пользователем или предоставлен автоматически. Сервер может подтвердить подлинность мандата, который выдает процедура. Мандат может быть связан с областью. Например, если приложение обеспечивает мандат, который не связан с областью сервера (“MICROSOFT.com.”), сервер может не аутентифицировать приложение.
Если регистрация успешна, то конечная точка может быть готова к приему сообщений от других объектов. В противном случае, конечная точка может оказаться неспособной к приему сообщений.
На этапе 412 процедура возвращается к своему инициатору.
В возможном варианте осуществления сервер может разрешить конечной точке, которая не была успешно зарегистрирована, передавать сообщения, но не принимать сообщения. Альтернативно, в модели с более низким уровнем защиты сервер может разрешить любой конечной точке посылать или принимать сообщения.
В одном варианте осуществления сервер может направить запрос аутентификации конечной точке, когда конечная точка пытается послать сообщение, но не когда она принимает сообщения.
Альтернативная процедура (не показана) может создавать одноранговую конечную точку. Одноранговая конечная точка представляет собой такую конечную точку, которая не ассоциирована с сервером. Когда конечная точка не ассоциирована с сервером, информация, которую публикует конечная точка, может оказаться недоступной, когда конечная точка прекратит функционирование.
На фиг.5 показана схема архитектуры, иллюстрирующая архитектуру расширяемой системы совместной работы в реальном времени согласно возможному варианту осуществления. Архитектура содержит объект 502 действия, объект 504 конечной точки и объекты 506 мультимедийных стеков. Эти объекты описаны выше детально. Схема архитектуры показывает соотношение между объектом действия, объектом конечной точки и объектом мультимедийных стеков в возможном варианте осуществления. Более конкретно, схема архитектуры показывает, что функциональность, обеспечиваемая объектом действия, включает в себя функциональность, обеспечиваемую объектами конечной точки и мультимедийных стеков.
В одном варианте осуществления множество объектов действий могут быть использованы с соответствующими объектами мультимедийных стеков.
Приложения могут вызывать методы объектов архитектуры или могут непосредственно вызывать методы базовых объектов, которые реализуют соответствующую функцию. За счет вызова методов объектов архитектуры от разработчика приложения может потребоваться обеспечить меньший объем логики и может не потребоваться пересмотр логики приложения, когда базовые компоненты изменяются.
Ниже представлены некоторые приложения API, обеспечиваемые архитектурой.
Приложение может создать объект конечной точки путем создания новой «КонечнойТочкиСовместнойРаботы». Приложение может обеспечить следующие параметры: URI, относящийся к объекту конечной точки, сервер, связанный с объектом конечной точки, и указание мандата сети.
Метод «МандатСети» обеспечивает указание мандата сети. Этот метод принимает в качестве параметров указание учетной записи пользователя, пароль и домен, с которым связана учетная запись.
Метод «Ввести» регистрирует конечную точку и обеспечивает указание успеха или неудачи. Этот метод не требует параметров.
Метод «Опубликовать» публикует информацию присутствия. В качестве примера, приложение может показать, что пользователь является интерактивным, занят, говорит по телефону и т.д. Архитектура является довольно гибкой для обеспечения виртуально неограниченного числа указаний присутствия. Например, приложение может выбрать вариант публикации местоположения пользователя, определенного системой GPS.
В противоположность этому метод «Подписаться» осуществляет подписку на публикацию объекта конечной точки.
Метод «Пригласить» приглашает пользователя к сеансу совместной работы. Этот метод получает указание URI, которому должно быть направлено приглашение.
Метод «Принять» принимает приглашение. И наоборот, метод «Отклонить» отклоняет приглашение.
Объект действия передачи сообщений может быть создан из класса «ДействиеМгновеннойПередачиСообщений». Этот объект действия поддерживает различные методы, включая, например, метод для посылки сообщений «ПослатьСообщение».
Метод «ПослатьСообщение» посылает сообщение. Он получает последовательность сообщения в качестве параметра.
Методы могут быть обеспечены множеством объектов архитектуры. Архитектура может дополнительно обеспечивать методы, свойства и события, относящиеся к извлечению пользовательских свойств, добавлению пользователя к списку контактов, добавлению или удалению участников из диалогов т.д.
Вычислительное устройство, на котором может быть реализована данная архитектура, включает в себя центральный процессорный блок, память, устройства ввода (например, клавиатуру и указательные устройства), устройства вывода (например, устройства отображения) и запоминающие устройства (например, накопители на дисках). Устройства памяти и запоминающие устройства представляют собой машиночитаемые носители, которые могут содержать команды, которые реализуют систему. Кроме того, структуры данных и структуры сообщений могут храниться или передаваться по среде передачи данных, например, посредством сигнала или коммуникационного канала. Могут использоваться различные коммуникационные каналы, например сеть Интернет, локальная сеть, глобальная сеть, двухточечное коммутируемое соединение.
Архитектура может быть реализована в различных операционных средах, включая вычислительные устройства, исполняющие операционную систему MICROSOFT WINDOWS. Эта операционная среда является лишь одним примером подходящей операционной среды и не предусматривает никакого ограничения в отношении объема использования функциональных возможностей системы. Другие хорошо известные вычислительные системы, среды и конфигурации, которые подходят для использования, могут включать персональные компьютеры, серверные компьютеры, портативные или настольные устройства, включая «интеллектуальные» сотовые телефоны, мультипроцессорные системы, системы на основе микропроцессоров, программируемые приборы бытовой электроники, сетевые персональные компьютеры, универсальные вычислительные машины, распределенные вычислительные среды, которые включают в себя любые из вышеупомянутых систем или устройств и тому подобное.
Архитектура может быть описана в общем контексте команд, исполняемых компьютером, таких как программные модули, исполняемые одним или более компьютеров или других устройств. В общем случае программные модули включают в себя стандартные подпрограммы, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют определенные абстрактные типы данных. В типовом случае функциональность программных модулей может быть объединена или распределена, как это необходимо в различных средах.
Из вышеизложенного понятно, что конкретные варианты осуществления изобретения, описанные выше, представлены для иллюстрации, и что различные модификации могут быть осуществлены без отклонения от сущности и объема изобретения. Таким образом, изобретение ограничивается только прилагаемой формулой изобретения.
1. Способ, выполняемый в вычислительной системе, для обеспечения сервисов совестной работы в реальном времени в приложении, заключающийся в том, что
создают экземпляр объекта действия (106, 300, 502), причем объект действия предоставляет функциональность объекта конечной точки (104, 200, 504) и объекта мультимедийного стека (108, 506), оба из которых являются базовыми для объекта действия, и содержит интерфейс программирования приложения для обеспечения сервиса совместной работы, и
активизируют методы интерфейса программирования приложения,
причем активизированные методы обеспечивают сервисы администрирования объекта конечной точки, который предоставляет абстракцию пользователя на вычислительном устройстве и идентифицируется комбинацией электронного адреса пользователя и идентификатором конечной точки, причем сервисы администрирования включают предоставление информации присутствия, относящейся к тому, присутствует ли пользователь на вычислительном устройстве; и
причем активизированные методы дополнительно обеспечивают сервисы передачи содержимого объекта мультимедийного стека между приложениями (110), которые осуществляют передачу информации сервиса совместной работы.
2. Способ по п.1, в котором объект конечной точки использует Протокол Инициирования Сеанса.
3. Способ по п.2, в котором объект мультимедийного стека использует Протокол Передачи в Реальном Времени.
4. Способ по п.2, в котором объект мультимедийного стека использует Протокол Управления в Реальном Времени.
5. Способ по любому из пп.1-4, в котором сервисы передачи содержимого включают в себя обеспечение среды передачи.
6. Расширяемая система совместной работы в реальном времени, содержащая множество объектов мультимедийных стеков (108, 506);
объект конечной точки (104, 200, 504) для обеспечения или получения информации сигнализации, причем объект конечной точки предоставляет абстракцию пользователя на вычислительном устройстве и идентифицируется комбинацией электронного адреса пользователя и идентификатором конечной точки, и
множество объектов действий (106, 300, 502), причем объекты действий обеспечивают функциональность множества объектов мультимедийных стеков и объекта конечной точки, все из которых являются базовыми для множества объектов действия, обеспечивают интерфейс программирования приложения для приложений и используют множество объектов мультимедийных стеков и объект конечной точки для обеспечения сервисов совместной работы, при этом сервисы совместной работы включают предоставление информации присутствия, относящейся к тому, присутствует ли пользователь на вычислительном устройстве,
причем приложение использует интерфейс программирования приложения и не требует обеспечивать логику для координации объектов мультимедийного стека и объекта конечной точки.
7. Расширяемая система совместной работы в реальном времени по п.6, в которой интерфейс программирования приложения обеспечивает совместимое имя интерфейса, даже если два базовых объекта, реально обеспечивающих ассоциированную функциональность, используют отличающиеся имена интерфейсов.
8. Расширяемая система совместной работы в реальном времени по п.6, в которой один из сервисов совместной работы представляет собой передачу сообщений (306).
9. Расширяемая система совместной работы в реальном времени по п.6, в которой один из сервисов совместной работы представляет собой видеоконференцсвязь (308).
10. Расширяемая система совместной работы в реальном времени по п.6, в которой один из сервисов совместной работы представляет собой совместное использование приложения (310).
11. Расширяемая система совместной работы в реальном времени по п.6, добавляющая объекты мультимедийных стеков.
12. Расширяемая система совместной работы в реальном времени по п.6, в которой объект конечной точки включает в себя компонент профиля (201), предоставляющий абстракцию пользователя на вычислительном устройстве, компонент публикации и подписки (202), предоставляющий интерфейсы для предоставления информации присутствия, компонент сигнализации (204), адаптированный для предоставления транзакционных сообщений, относящихся к установлению или управлению сеансом совместной работы в реальном времени, и компонент стека протоколов (206), предназначенный для передачи и приема информации с использованием протокола.
13. Расширяемая система совместной работы в реальном времени по п.12, в которой компонент стека протоколов использует Протокол Инициирования Сеанса.
14. Расширяемая система совместной работы в реальном времени по п.12, в которой компонент стека протоколов использует протокол сигнализации.
15. Расширяемая система совместной работы в реальном времени по любому из пп.6-14, в которой один из множества объектов мультимедийных стеков использует Протокол Передачи в Реальном Времени.
16. Расширяемая система совместной работы в реальном времени по п.15, в которой объекты действия координируют множество объектов мультимедийных стеков и объект конечной точки под управлением приложения.
17. Машиночитаемый носитель, имеющий исполняемые компьютером инструкции для выполнения способа по любому из пп.1-5.
