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

Question

Это не столько вопрос с простым, практичным ответом, сколько вопрос, способствующий обсуждению темы обмена данными в режиме реального времени.

Начну с примера:

Google Wave по своей сути является механизмом асинхронной синхронизации данных в реальном времени. Wave поддерживает (или планирует поддерживать) одновременную (в режиме реального времени) совместную работу с документами, редактирование автономных (автономных) документов, разрешение конфликтов, историю и воспроизведение документов с атрибуцией и объединение серверов.

Основной частью Wave является механизм оперативного преобразования: http://www.waveprotocol.org/whitepapers/operational-transform

Механизм OT управляет состоянием документа. Изменения между клиентами объединяются, и каждый клиент всегда имеет разумный и последовательный взгляд на документ; окончательный документ в конечном итоге согласован между всеми подключенными клиентами.

Мой вопрос: является ли эта система абстрактной или достаточно общей, чтобы ее можно было использовать в качестве библиотеки или универсальной структуры, на которой можно создавать веб-приложения, синхронизирующие асинхронное состояние в реальном времени на каждом клиенте?

Использует ли протокол Wave непосредственно какие-либо современные веб-приложения (кроме клиента Google)? Имеет ли смысл напрямую использовать его для общей синхронизации состояний в веб-приложении?

Какие еще существующие библиотеки или интегрированные среды вы бы хотели использовать при создании такого веб-приложения?

Сколько кода в таком приложении может быть предметно-ориентированной логикой по сравнению с общей логикой синхронизации состояний? Или, другими словами, насколько утечки могут быть абстракции синхронизации состояний?

Комментарии и обсуждение приветствуются!

Answer 1

Что касается реализации OT, Wave действительно ослаблен и не выполняет - и не может - выполнить обещание OT, о котором вы прочтете в литературе. Основанный на совместной системе Jupiter, он ограничен топологией сети клиент-сервер. Кроме того, Google помешал алгоритмам Jupiter OT ограничить количество операций «в полете» данным клиентом до одной - это действительно вредит интерактивности между клиентами.

Насколько "общая" волна? Из того, что я помню о коде, он кажется довольно привязанным к модели данных Wave - сообщения, аннотации и т. Д. Итак, я ожидаю, что будет трудно применить его к другим моделям данных без серьезной модификации.

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

Волна активно находится в стадии разработки, поэтому со временем ситуация улучшится.

Существует не так много альтернатив Wave. Как отмечалось в моем ответе на этот вопрос , я использую Ceda для синхронизации на основе OT. В Ceda нет проблемы «утечки абстракции» - он может использовать OT для синхронизации произвольных структур данных - ваше приложение определяет схему.

Answer 2

Книга Джека Моффитта " Профессиональное программирование на XMPP с использованием JavaScript и jQuery " дает ответ именно на этот вопрос, включая биты операционного преобразования.

Answer 3

Вы можете достичь этого с помощью чего-то вроде PubSubHubbub , и я думаю, что это довольно просто. Как это работает: обе системы должны иметь каналы RSS / Atom, которые представляют данные, или, по крайней мере, события в данных «объект по URL создан XYZ» ... и т. Д.

Затем убедитесь, что в обоих каналах включен PubSubHubbub, что означает, что они могут уведомлять подписчиков при обновлении своего контента.

Подписаться каждый компонент на каналы других компонентов.

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

Большим преимуществом этого является то, что опирается только на то, что "известно" : HTTP, ATOM.

В этом блоге приведен пример с социальными данными, но это также может относиться к любому типу данных.

Answer 4

HTTP был создан для обработки вызовов, которые были инициированы от клиента к серверу, но это проблема, когда вам нужна Технология Push . Я веб-разработчик, поэтому буду использовать Comet .

Браузер делает Ajax-стиль запрос к серверу, который хранится открыть, пока на сервере не появятся новые данные отправить в браузер, который отправляется на браузер в полном ответе. Браузер инициирует новый длинный запрос на опрос, чтобы получить последующие события.

Вы можете создавать веб-приложения в стиле Comet, используя среду веб-разработки под названием Lift. (Он написан на языке программирования Scala, который компилируется в байт-код Java, что означает, что вы можете запустить его на сервере приложений Java.)

Что-то интересное для наблюдения - HTML5, который имеет функцию под названием Веб-сокеты , которая может сделать Comet устаревшим.