Вот и прошёл первый Office Hours в России. Сейчас волна закрыта уже на запись, но всегда можно почитать о чём писали. Напомню ссылку: http://bit.ly/bfKBBK В виду того, что мне пришлось уехать в другой город из Москвы (в Оренбург), то я не смог отследить обсуждение и даже поучаствовать. Мне очень жаль.
Напомню, что у кого есть аккаунт они могут зайти и почитать здесь, а у кого нет аккаунта в Google Wave, то я напишу самые важные на мой взгляд вопросы, которые обсуждали, а так же какие ответы на них давали.
Существует ли поддержка Ruby on Rails?
Alexander Belozor (ABel):
Руби вообще пока в Google инструментах не поддерживается, к сожалению. Тут нужна активность пользователей. )))
Check-boxes для выбора волн в поиске. Изменение доступа участников. Уже появилась edit кнопка в тулбаре. Возможно скорое появление руссифицированой версии.
В API будет добавлена поддержка нового Python и Java API для роботов. Wave должна работать гораздо быстрее на Хроме.
Обещанный третий режим доступа (помимо рид-онли и полного доступа) когда примерно можно ждать? Это дело ближайшего времени или будет попозже?
Vadim Gerasimov:
Это из категории попозже.
Памела добавила в "песочнице" папку для extensions. Это будет перенесено в превью?
Vadim Gerasimov:
Со следующим перезапуском.
Google Chrome OS планируется выпускать на устройствах на базе intel Atom, соответственно планируются какие-нибудь работы по оптимизации либо самой Chrome OS либо Google Wave?
LZSaver:
Браузер Chrome к моменту релиза Chrome OS или Google Wave уже будет версии 10-ой, так что скорость и там, и там, и там поднимут.
Ну вот и все основные вопросы русскоязычных пользователей Google Wave. Ждите обновлений позднее и удачного дня!
Итак, я написал небольшой проект на Java, который представляет собой клиент к Google Wave, который, в свою очередь, вы можете расширить необходимыми вам возможностями. Визуально выглядит он не очень презентабельно (впрочем, а-ля Windows 3.11, почему бы и нет), поскольку веб-дизайнер из меня не очень хороший, однако абсолютно за весь исходный код я отвечаю головой :). Так, например, требующиеся для отображения CSS-стили при этом выглядят максимально понятно, а XHTML-структура максимально упрощена (не в ущерб стандартам) для того, чтобы настоящий дизайнер мог развернуться и сделать действительно красиво :). Сайт, исходные коды, и war-пакет с текущим состоянием проекта находятся по адресу http://code.google.com/p/sametimed Сейчас у меня нет под рукой общедоступного хостинга, чтобы я мог прямо вот так запустить проект и дать поиграться с ним не отходя от хабра, однако, я могу предложить вам видео (на vimeo), демонстирующее его основные возможности, что, думаю, тоже вполне ничего, а запустить проект вы сможете сами, благо подробные инструкции есть на сайте проекта, а развёрнутые пояснения и подробное описание работы (и руководство к расширению возможностей) — внутри…
Любой Web-сервер, реализующий спецификации Java EE (тестировалось на встроенном в Eclipse Jetty)
Браузер Firefox
Чуть более подробные инструкции как его запустить сам по себе или в виде рабочего проекта для Eclipse представлены на странице проекта. Здесь же я рассмотрю структуру кода и опишу как он действует (пока без что UML-диаграмм, извините, по мере возможности я их добавлю).
Общая концепция
Здесь под сочетанием «серверная сторона/часть» подразумевается не сервер wave-protocol, а серверная строна веб-приложения. Поскольку в wave-protocol сейчас существует только консольный клиент, релизованный в виде jar-приложения, основной вопрос состоит в своевременной передаче информации с клиента на серверную часть и наоборот. Посему стало необходимо ввести два понятия:
Команда: отправляется с клиента на сервер, требует «открыть волну», «добавить участника», «отменить действие», «сказать привет» и т.п., отправляется по действию пользователя.
Сообщение: отправляется с сервера на клиент, сообщает о том, что «кто-то пригласил в волну», «sonya ответила привет», «добавился участник», «произошла ошибка», отправляется при любом обновлении.
При этом, команду с клиента можно отправить сразу, сильно не задумываясь о нагрузке на сервер, а вот сообщения об обновлениях требуется отсылать только по факту происшествия. Однако, на клиенте находится javascript, который без сложных приспоcоблений не может осуществлять такие вещи. Здесь потребовался Reverse Ajax, вернее его реализация для Java — библиотека DWR (Direct Web Remoting), она позволяет вызывать функцию на клинете с сервера в тот момент, когда решит сервер, а не клиент. Их сайт рассказывает о всех возможностях, которые вовсе не ограничены данным применением, но для проекта, как я уже сказал, из всех возможностей я использовал только эту. Команды и сообщения передаются в виде XML, а содержимое сообщений об обновлениях в виде JSON, засчёт чего в построении интерфейса участвует только Javascript (я использовал JQuery), а серверная сторона даже не задумывается о существовании UI. (для серверной стороны в проекте есть интерфейс Renderer, реализация которого вызывается при необходимых обновлениях, но он предназначен как раз для случаев вроде консольного клиента)
Описание процесса, происходящего в текущей версии
При запуске клиента, вы видите страницу с полем для ввода юзернейма и единственной кнопкой. Wave-protocol сервер при этом должен быть запущен. При нажатии на кнопку введённый вами юзернейм передаётся в сервлет (GetClientViewServlet), который подключает вас «к волне», и возвращает всю структуру (модель) клиента в виде JSON. JQuery на клиентской стороне строит весь интерфейс вейвлета. Если вы нажмёте кнопку ещё раз, вы запросите ещё один вейвлет, при этом между собой они будут различаться по внутреннему ID (сгенерированному автоматически), указанному на синей полоске в скобках. По этому ID и сервер и клиент определяют, к какому клиенту относится команда и/или сообщение. Одновременно с этим DWR начинает ожидать вестей об обновлениях, а вы в это время можете ввести любую из доступных команд в поле консоли и нажать «send». Например, создать волну командой «\new», открыть её командой «\open <id>» и что-нибудь сказать, набрав просто текст (как в скайпе). При нажатии на кнопку «send» отправляется POST-запрос к другому сервлету (CommandsReceiverServlet), который получает сгенерированную в виде XML команду и тут же её выполняет, передавая данные серверу wave-protocol. Обновления в данный момент приходят с серверной стороны (и от сервера wave-protocol) в виде XML-сообщения (на клиентской стороне есть обработчик, который вызывается при получении новых сообщений), в котором содержится алиас изменившейся модели (например, «chat», «inbox», «userslist», «errors» или «editor») и её содержимое в виде JSON, которое тут же обрабатывается и обновляет соответствующую часть вейвлета. Как видите, всё до невозможности просто.
Структура проекта и возможности для расширения
Java:
name.shamansir.sametimed.waveВсе классы, лежащие «снаружи» и относящиеся к клиенту непосредственно; здесь находятся абстрактные классы AUpdatingWavelet и ADocumentsWavelet — определяющие структуру соответствующего типа вейвлетов (обновляющийся вейвлет и его расширение, вейвлет содержащий документы). Класс SimpleWavelet служит примером такой реализации. Класс WavesClient занимается обработкой команд и именно он возвращает модель содержащегося в нём вейвлета в GetClientViewServlet.
name.shamansir.sametimed.wave.messagingВсе, что относится к командам и сообщениям. Идентификаторы команд/сообщений в CommandID/MessageTypeID, сами классы Command и UpdateMessage, сервлет-обработчик CommandsReceiverServlet.
name.shamansir.sametimed.wave.modelКлассы, описывающие модель вейвлета. Они содержат описание каждой суб-модели, вроде списка участников, чата или текстового документа. И ModelID, описывающий возможные модели с абстрактным классом AModel, конечно. Плюс, ModelFactory, фабрика моделей.
name.shamansir.sametimed.wave.model.baseЗначения моделей, вроде «набора строк чата», «набора блоков текста в документе», «списка доступных волн» и т.д. Именно в этих классах описывается преобразование в JSON.
name.shamansir.sametimed.wave.model.base.atomТо, из чего состоят значения, если это необходимо для их структуры — «строка чата», «блок текста», «идентификатор волны»
name.shamansir.sametimed.wave.model.base.chatВейвлет с функцией чата и клиент для него
name.shamansir.sametimed.wave.model.base.editorВейвлет с поддержкой редактируемого документа, на данный момент не имплементирован, поэтому отключен
name.shamansir.sametimed.wave.renderКлассы, относящиеся к рендерингу Здесь находится тот самый класс JSUpdatesListener, который средствами DWR вызывает функцию обновления на клиенте.
Самый логичный способ расширения — имплементация класса ADocumentsWavelet или расширение класса WaveletWithChat. Поскольку, в наиболее вероятном случае, вы будете оперировать понятием «документ» (А чат или что-либо другое, как раз являются документами), то именно такой способ должен подойти вам лучше всего. Также вам понадобится задуматься о модели данного документа (создав соответсвующий тип, реализующий AModel, добавить id модели в тип ModelID и генерацию модели в ModelFactory). Если документ не будет обрабатывать какие-либо новые команды, то этого достаточно — можно заменить в GetClientViewServlet возвращаемый вейвлет на ваш собственный и вуаля!.. Ах, да, ещё генерация UI на клиенте, но об этом ниже. Если же необходимы свои собственные, предназначенные сугубо для него команды, то необходимо добавить соответствующие команды в тип CommandID. После этого нужно расширить класс WavesClient для поддержки вашего вейвлета и для того, чтобы он обрабатывал и передавал новые команды вейвлету независимо от предка. И, в этом случае, заменить в GetClientViewServlet реализацию WavesClient на вашу собственную. И снова вуаля! (снова, не учитывая UI) Вам понадобится, конечно же, учесть пару тонкостей при написании обработки команд, но в общих чертах это весь необходимый процесс для расширения функциональности клиента.
Javascript
ui.js занимается генерацией интерфейса, для каждого блока модели есть собственный метод
command.js отправляет и генерирует команды, принимает сообщения об обновлениях, а также содержит обработчики для кнопок
ajax.js скрипт, который давно пора заменить на соответствующий метод jquery, но никак не доходят руки :). используется в command.js
Для того, чтобы добавить генерацию вашей модели, достаточно добавить строку, вызывающую ваш метод обработки в методы CreateClient и renderUpdate объекта ClientRenderer в ui.js и собственно написать этот метод. Всё остальное будет (должно) работать самостоятельно.
CSS
sametimed-plain.css ещё чуть более ужасный интерфейс чем цветной :)
sametimed-colored.css цветной, Windows 3.11-подобный интерфейс :).
Пока что стили, определяющие позиционирование и внешний вид (цветность) не разделены, хотя они разделяются комментариями в самих файлах. Думаю, я не буду этого менять.
Эпилог
Вышло много текста про один небольшой аппликейшн, но зато пост описывает все его возможности. Надеюсь найдётся не один человек, которому эта разработка будет интересна и если найдётся, планирую усовершенствовать его дальше. Пока это небольшая поделка «из интереса», но немного стараний — и её можно превратить в полноценный проект. Тех, кто это будет тестировать, прошу постить баги в соответствующее место, в разумных пределах и не относящиеся к дизайну :). Участие в разработке приветствуется но поощрить нечем, только лицензией :).
В одной из статей я описывал инсталляцию волнового демо-сервера FedOne. В «комплекте» к серверу имеется и клиент, с весьма примитивным текстовым интерфейсом. Я уверен, что у многих из тех, кто тестировал FedOne, возникала мысль о написании GUI-клиента к нему.
И вот Thomas Beverley выложил исходные тексты клиента FedOne с графическим пользовательским интерфейсом. На скриншоте вы можете посмотреть, как это все выглядит под Windows XP. Запущены сервер и два клиента. Есть кнопки для практически всех команд, которые сейчас имеются в API (заготовлена даже пустая кнопка «Test butt», видимо, на будущее). В центре вы видите модальное окно для добавления нового участника в волну. Аналогичное окно появляется при удалении участника.
Процедура установки этой версии клиента проста. Нужно скачать исходные тексты и заменить ими папку\src\org\waveprotocol\wave\examples\fedone\waveclient\console. После этого запускаете «ant clean» (спасибо D.Unkovsky за напоминание :) и затем «ant» для перекомпиляции. Как пишет автор, можно легко изменить клиент с помощью имеющегося класса WaveConnector.java. Этот класс полностью документирован и позволяет упростить взаимодействие с Google-волной. Базируясь на нем, вы можете построить свой собственный текстовый клиент или создать ваш вариант графического интерфейса. Как пример смотрите класс ConsoleClient.java.
P.S. И напоследок — небольшой трюк (Windows only), теперь уже от меня. Раз уж мы говорим о графическом интерфейсе, давайте сделаем более удобным управление сервером и клиентами. Сейчас приходится запускать их с помощью bat-файлов, причем окна с запущенными процессами невозможно свернуть в трей. Но мы можем воспользоваться удобной утилиткой LNK file improver by Dmitry Koteroff (dk@dklab.ru) из комплекта Denwer. Она позволяет запускать любую программу и сворачивать ее окно в трей. Если вы заглянете в текст этой маленькой (6656 байт) софтинки каким-нибудь редактором, то увидите, что прямо в исходном тексте можно отредактировать ее параметры: стартовый каталог, строку запуска с аргументами, адрес иконки, нужно ли запускать свернутой в трей, позволять ли запуск нескольких экземпляров и делать ли доступным пункт «Terminate» в контекстном меню (по правой кнопке) этой крохотули. Единственно, что надо соблюдать при изменении текста — делать замену знаков, а не вставку. Я сделал себе три разновидности этого исполняемого файла (сервер и два клиента), добавил иконку от Google Wave и теперь у меня на экране не висит несколько DOS-образных окон, а есть лишь пара-тройка волновых «змеек» в трее (их видно в правом нижнем углу скриншота).
В «очень раннем режиме», но все-таки заработал первый альтернативный Wave-сервер. Можно зарегистрироваться, создавать волны, добавлять в них других пользователей, совместно использовать гаджеты (причем можно создавать свои и делать их доступными другим). Хочется надеяться, в ближайшее время появятся и другие функции. У разработчиков есть блог. Вы также можете попробовать поставить такой сервер к себе — исходники открыты (Python, Django).
Внимание! Для использования входите через Google Chrome, через Firefox — работает не всё.
Рекомендую включить гаджет Simple Chat — это чат где сообщения появляются по мере набора.
Волны Гугл являются новой коммуникационной платформой для совместной работы, основанной на хостируемых 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) аутентификацию или шифрование между конечными потребителями. Провайдер волн должен обеспечивать аутентификацию своих конечных потребителей, и им рекомендуется предоставлять своим конечным потребителям безопасные шифрованные соединения в своих клиентской части обслуживающего сервиса волн. Сочетание безопасных соединений между обслуживающими сервисами волн и безопасных соединений между потребителями и между самими обслуживающими сервисами волн обеспечивает достаточный уровень безопасности между конечными клиентами.
