Архитектура Объединения Google Wave

Авторы: Soren Lassen, Sam Thorogood

Перевод на русский: sim-sim, 2009, Creative Commons Attribution 3.0 License.

Оригинал: Google Wave Federation Architecture

Волны Гугл являются новой коммуникационной платформой для совместной работы, основанной на хостируемых XML документах (называемых волнами), поддерживающей параллельные модификации и обновления с коротким временем ожидания. Эта платформа позволяет людям связываться и работать вместе новым, удобным и эффективным способом. Мы собираемся предложить эти преимущества пользователям Волн Гугл и мы также хотим поделиться ими со всеми, сделав волны открытой платформой, чтобы каждый мог внести свой вклад. Мы приветствуем тех, кто запускает серверы волн и становится провайдером волн для себя или как сервис для своих пользователей, и объединяет волны в "федерацию", то есть обмеривается волнами с другими и с Волнами Гугл. Таким образом, пользователи от других провайдеров волн могут связываться и работать вместе, используя совместные волны. Мы представляем "Протокол федерации Волн Гугл" для интеграции волн между провайдерами волн в Интернете.

Этот документ дает обзор того, как различные элементы технологии Волн Гугл — модель данных, операциональные преобразования и протокол клиент-сервер — используются вместе при запуске обслуживающего сервиса волн, и как провайдеры сервисов волн связываются между собой, используя Протокол федерации Волн Гугл со своими криптографическими средствами для защиты от фальсификации. Все эти элементы описаны более подробно в сопутствующих документах на этом сайте, и читатель может обратиться к ним за деталями. Фокусом этого документа является федерация, которая включает протокол федерации волн типа "сервер-сервер", и не касается протокола типа "клиент-сервер" между клиентами и сервером волн у провайдера волн. Тем не менее, этот документ далек от исчерпывающего доклада о федерации волн. В частности, вложения (attachments) и группы — важные элементы федерации, здесь не рассматриваются. Они будут вскоре проработаны в последующих материалах на этом сайте.

Провайдеры Волн

Протокол федерации волн позволяет каждому стать провайдером волн и обмениваться волнами с остальными. Например, организация может действовать как провайдер волн для своих членов, индивид может запустить сервер волн как провайдер волн для одного потребителя или членов семьи, и провайдер услуг Интернет может запустить обслуживающий сервис волн как еще один сервис Интернет для своих потребителей, в дополнение к email, службам мгновенных сообщений, ftp и т.д. В этой модели, Волны Гугл являются одними из множества провайдеров волн.

Провайдер волн идентифицируется по своему доменному имени (именам).

Потребители волн имеют свой волновой адрес, который состоит имени потребителя и домена провайдера волн, в той же самой форме, как и email адрес, а именно @. Волновой адрес может также ссылаться на группу, роботов, хосты и другие сервисы. Групповой адрес ссылается на список волновых адресов, очень похожий на список рассылки по email. Робот является автоматизированным участником волны (см. API роботов). Примерами являются робот-переводчик и робот для игры в шахматы. Хост транслирует данные между волнами и другими коммуникациями и протоколами обмена, такими как email и мгновенных текстовых сообщений. В сухом остатке мы не придаем значения адресатам, которые являются сервисами, включая роботов и хостов — они в основном рассматриваются в качестве таких же потребителей, в том, что касается интеграции.

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

Волны, Вейвлеты и Идентификаторы

Волна состоит из набора вейвлетов (элементарных волн). Если потребитель имеет доступ к вейвлету, то он называется участником этого вейвлета. Каждый вейвлет имеет список участников и набор документов, которые верстают его содержание. Различные вейвлеты волны могут иметь разный список участников. Копии вейвлетов распространяются между всеми провайдерами волн, которые имеют хотя бы одного участника в этом вейвлете. Один особый среди таких провайдеров волн, имеет определяющую копию этого вейвлета. Мы говорим, что этот конкретный провайдер является хостером этого вейвлета.

Когда потребителю приходит волна, ему доставляется ее представление, а именно: набор вейвлетов в волне, в которой он становится участником (напрямую или косвенно, через членство в группе). В общих чертах, различные потребители имеют разные представления для одной волны. Например, конкретные данные для потребителя волны, такие как статус прочитано/непрочитано в волне, хранятся во вейвлете пользовательских данных волны только для участвующих в ней потребителей. Вейвлет пользовательских данных отображаются в представлении волны только этому участнику. Другим примером является приватные ответы внутри волны, которые отображаются как вейвлет с ограниченным списком участников. Вейвлет приватных ответов появляется в представлении волны только ограниченному списку пользователей.

Волна идентифицируется глобальным уникальным id волны, который представляет собой пару из id и доменного имени. Доменное имя указывает провайдера волны, который порождает волну.

Вейвлет имеет свой вейвлет id, который уникален внутри своей волны. Подобно id волны, вейвлет id является парой из доменного имени и строки id. Доменное имя в id вейвлета играет особую роль: оно указывает провайдера волны, который является хостером вейвлета. Вейвлет хостится у провайдера волны того участника, который создал вейвлет. Провайдер волны, который является хостером вейвлета, отвечает как за операциональные преобразования, так и за исполнение операций во вейвлете и за обмен примененных операций с провайдерами волн всех участников вейвлета.

Вейвлеты в одной и той же волне могут хостится у разных провайдеров волн. Например, вейвлет пользовательских данных всегда хостится у провайдера волн потребителя, независимо от того, где обслуживается остальная часть волны. На самом деле, пользовательские данные не являются федеральными, т.е. ими не обмениваются с другими провайдерами. Другим примером является вейвлет приватных ответов. Конкретный простой пример этого — когда все участники приватных ответов принадлежат одному и тому же провайдеру волны. В таком случае провайдер волн не обменивается вейвлетом приватных ответов с другими провайдерами волн, у которых хостятся другие ее вейвлеты.

Архитектура Обслуживающих Сервисов Волн

Провайдер волн оперирует обслуживающим сервисом волн на одном или больше серверах сети. Центральной частью сервиса волн является хранилище волн, которое хранит операции вейвлета, и сервер волн, который правит операции вейвлета с помощью операциональных преобразований, а так же записывает и читает операции вейвлета из хранилища волн. Обычно сервис волн обслуживает волны для потребителей провайдера волн, которые подключены к клиентской части сервиса волн (см. "Модель данных Гугл Волн и клиент-сервер протокол"), и мы должны иметь это ввиду в последующем описании описании архитектуры сервиса волн. Еще более важно, для целей интеграции, что сервис волн обменивается волнами с участниками от разных провайдеров, связываясь с серверами их провайдеров волн. Обслуживающий сервис волн использует два компонента для пирингового обмена с другими провайдерами волн — "хост федерации" и "удаленный узел федерации". (В ранней ревизии этой рабочей спецификации эти компоненты были названы как "шлюз федерации" и "прокси федерации", соответственно). Они описываются в следующем разделе.

Сервер волн у конкретного провайдера волн обслуживает представления волн для локальных участников, т.е. участников из своего домена. Как было описано ранее, копии вейвлетов поставляются всем провайдерам волн, которые имеют участников в этом вейвлете. Копии вейвлета у конкретного провайдера могут быть как локальными, так и удаленными. Мы используем термин "локальный вейвлет" и "удаленный вейвлет", ссылаясь на два таких типа копий вейвлета (в обоих случаях мы ссылаемся на копии вейвлета, а не на сами вейвлеты). Представление волны может содержать оба типа копий вейвлета одновременно.

У конкретного провайдера волн локальными вейвлетами являются те, что созданы у этого провайдера, а именно: теми потребителями, которые принадлежат к провайдеру вейвлета. Сервер волн является ответственным за обработку операций вейвлета, передаваемых ему локальными участниками и удаленными участниками от других провайдеров. Сервер волн управляет многопоточностью, упорядочивая передаваемые операции вейвлета относительно друг друга, используя операциональные преобразования. А так же он проверяет их корректность перед применением на локальном вейвлете.

Удаленные вейвлеты хостируют другие провайдеры волн. Сервер волн поддерживает кэшированные копии локально и обновляет их операциями вейвлета, которые получает от хостирующих провайдеров волн. Когда локальный участник отправляет вейвлетную операцию удаленному вейвлету, сервер волн пересылает операцию серверу волн хостирующего провайдера. Когда преобразованная и примененная операция возвращается обратно, она применяется на кэшированной копии. Доступ на чтение локальным участникам дается из кэшированной копии без обращения к хостирующему провайдеру волн.

Все локальные и удаленные вейвлеты хранятся в устойчивом от сбоев хранилище волн, входящему в сервер волн.

Мы говорим, что провайдер волн находится "против течения" относительно локальных вейвлетов и что он находится "по течению" по отношению к его удаленным вейвлетам.

Хост Федерации и Удаленный узел Федерации

Обслуживающий сервис волн использует два компонента для пирингового обмена с другими провайдерами волн — "хост федерации (federation host)" и "удаленный узел федерации (federation remote)".

Хост федерации обеспечивает коммуникацию локальных операций вейвлета, т.е. операций на локальном вейвлете:

• Выдает новые операции вейвлета, которые уже применены в локальном вейвлете, провайдерам волн каждого удаленного участника.
• Удовлетворяет запросы старых операций вейвлета.
• Обеспечивает согласование запросов операций вейвлета.

Удаленный узел федерации обеспечивает коммуникацию удаленных операций вейвлета и является компонентом провайдера волн, который связывается с хостом федерации вверх по течению провайдеров волн:

• Получает новые операции вейвлета, выдаваемых ему провайдерами волн, которые являются хостерами вейвлетов.
• Запрашивает старые операции вейвлета у хостирующих провайдеров волн.
• Отправляет операции вейвлета хостирующим провайдерам волн.

Хост федерации провайдера волн вверх по течению связывается с удаленным узлом федерации провайдера волн вниз по течению для передачи операций вейвлета, которые хостируются провайдером волн вверх по течению.

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

Пример

Рассмотрим для примера вейвлет с id вейлета W (acmewave.com, conv+090528), где acmewave.com является доменом, а "conv+090528" id-строкой (структуру которой мы здесь не рассматриваем). id вейвлета предписывает, что W хостится у провайдера волн Acmewave. Предположим, что W имеет участника feddy@federati.com из другого домена federati.com.



Все операции вейвлета W, отправленные как локальными, так и удаленными участниками, преобразовываются и применяются в W, сохраняются в локальном хранилище волн провайдера Acmewave, и затем примененные операции передаются на федеральный хост, который выдает их federati.com. Хост Acmewave устанавливает связь с удаленным узлом Federati и отсылает операции через соединение.

Иногда получателю бывает нужно получить прошлые операции от отправителя. Типичным является случай, когда получены операции для вейвлета и при этом получатель не имеет всех предыдущих операций для вейвлета. (Это условие легко проверяется, потому что примененные операции содержат в себе последовательные номера версий.) В этом случае получающий удаленный узел федерации устанавливает соединение с доменом, который хостирует вейвлет и запрашивает прошлые операции, которые у него отсутствуют. (Один из случаев происходит, когда у сервера волн может создаться определенный интервал в истории операций: от момента времени t1 при удалении вейвлета, когда в его домене нет участников этого вейвлета, и до момента времени t2, когда участник из его домена присоединяется к тому же вейвлету. Хост федерации отвечает, посылая новую операцию AddParticipant, и пересылает все последующие новые операции удаленному узлу федерации, но последний должен сам откатиться и запросить предыдущие операции.)

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

Предположим что есть другой вейвлет, хостируемый Federati, т.е. домен id вейвлета — fedrati.com, и этот вейвлет имеет участника user@acmewave.com. Тогда хост Federati и хост Acmewave станут связываться друг с другом таким же образом.

Протокол

Сетевой протокол между хостами и удаленными узлами федерации называется "Протокол федерации Волн Гугл". Он является открытым расширением XMPP протокола обмена сообщениями через Интернет. Некоторые из ключевых полезных возможностей XMPP, которые используются в протоколе федерации волн — определение IP адресов и портов, используя SRV записи, TLS аутентификация и шифрование соединений. См. "Google Wave Federation Protocol".

Транспорт XMPP шифрует операции на транспортном уровне, таким образом, он обеспечивает криптографическую защиту только между серверами, соединенными друг с другом напрямую. Дополнительный уровень шифрования обеспечивает сквозная (end-to-end) аутентификация между провайдерами волн, использующая криптографические подписи и сертификаты, позволяя всем провайдерам вейвлета верифицировать свойства операций. В частности, провайдер волн внизу по течению может удостовериться, что провайдер волн не подделывает операции вейвлета, а именно: невозможно подделать требования (1) операций вейвлета, исходящие от потребителя другого провайдера волн или (2) того, что происходит в другом контексте. Это относится к ситуации, когда два потребителя от разных, надежных провайдеров волн, скажем love.com и peace.com, являются участниками вейвлета, который хостится у зловредного провайдера волн evil.com. Протокол требует от love.com подписывать операции своего потребителя сертификатом love.com и peace.com должен подписывать операции своего потребителя сертификатом peace.com. Эти подписи передаются вместе с операциями и evil.com должен хостировать подписи вместе с операциями. Кроме того, love.com и peace.com будут проверять подписи всех операций, которые пересылает evil.com. Это делает невозможным для evil.com изменять или подделывать содержание сообщений от потребителя love.com, которыми он делится с peace.com, и наоборот. Все подписывания и верификации осуществляются провайдерами волн, но не клиентским программным обеспечением конечных потребителей.



Спецификация протокола требует, чтобы провайдеры волн, соединяясь с использованием протокола федерации, должны обеспечивать аутентификацию используя криптографически безопасные TLS механизмы. Кроме того, рекомендуется, чтобы они использовали TLS для шифровки трафика между собой. Клиент-сервер протокол и протокол федерации не обеспечивают сквозную (end-to-end) аутентификацию или шифрование между конечными потребителями. Провайдер волн должен обеспечивать аутентификацию своих конечных потребителей, и им рекомендуется предоставлять своим конечным потребителям безопасные шифрованные соединения в своих клиентской части обслуживающего сервиса волн. Сочетание безопасных соединений между обслуживающими сервисами волн и безопасных соединений между потребителями и между самими обслуживающими сервисами волн обеспечивает достаточный уровень безопасности между конечными клиентами.


Ссылки:

Jochen Bekmann, Michael Lancaster, Soren Lassen, David Wang: "Модель данных в Волнах Гугл и Протокол клиент-сервер".
David Wang, Alex Mah: "Операциональные Преобразования в Волнах Гугл".
Danny Berlin: "Протокол федерации Волн Гугл".
Lea Kissner, Ben Laurie: "Генеральная доверенность в Федерации".