Архитектура для расширяемой системы совместной работы в реальном времени

Архитектура для расширяемой системы совместной работы в реальном времени

Иллюстрации

Показать все

Реферат

Перекрестные ссылки на связанные заявки

По настоящей заявке испрашивается приоритет предварительной патентной заявки США 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 мультимедийных стеков. Эти объекты описаны выше детально. Схема архитектуры показывает соотношение между объектом действия, объектом конечной точки и объектом мультимедийных стеков в возможном варианте осуществления. Более конкретно, схема архитектуры показывает, что функциональность, обеспечива