Совместное редактирование в MS Office 2010 - немного технических подробностей

В блоге SharePoint Workspace Team, появилась статья SharePoint Workspace and the Office Document Cache, которая затрагивает некоторые вопросы реализации такой давно ожидаемой функциональности, как параллельная/совместная работа над документами, которая доступна при использовании Microsoft Office 2010 и SharePoint Foundation 2010 (ну или SharePoint Server 2010, естественно).

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

Как это выглядит...

Итак, пусть мы (т.е. я, конечно, но в двух лицах Admin1 и Administrator) открываем с узла SharePoint какой-нибудь простой документ, например MS Word:

То, что над документом работают несколько человек можно увидеть, взглянув на строку состояния в низу окна Word:

Если теперь щелкнуть по области авторов, то можно увидеть подробные сведения о каждом из моих соавторов и даже связаться с ними по почте (или через службу мгновенных сообщений, если в сети развернут Communication Server):

(в моем примере нет ни изображений, ни статусов пользователей: "занят"/"в сети"/..., т.к. в этом тестовом домене я практически ничего не настраивал и уж тем более не развертывал сервисы Communication Server. Впрочем, мне это ничуть не мешает, ибо я знаю, что мой соавтор - это я сам, а желания поговорить с собой ... пока не возникает, вроде)

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

Обратите внимание: изменения сейчас есть только локально у пользователя Administrator, ни на сервере, ни у второго клиента они не доступны. Однако, как только пользователь Administrator сохранит свой измененный документ на сервер, у первого пользователя появится уведомление в строке состояния о доступности изменений:

а метки, которые показывали места изменений, приобретут вид (значок дискетки появится, в общем):

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

- выделение будет оставаться до следующего сохранения (когда автор сохранит уже совокупный документ, включающий все исправления: и свои, и других авторов).

Однако в этой идиллии возможны и темные пятна - конфликтующие изменения, когда авторы совместно правят одну и ту же область. В общем случае такая ситуация не возникнет, т.к. изменения, произведенные первым автором тут же блокируют область от изменений всеми остальными авторами (заблокировать область можно и превентивно - выделив часть документа и нажав кнопку "Блокировать авторов" в меню или на Ribbon). При попытке изменить заблокированную область будет выдано предупреждение о невозможности правки:

Однако, информация об изменениях распространяется не мгновенно (по моим наблюдениям задержка между внесением изменения, и появлением информации о нем проходит не меньше 10-20 секунд, но это очень условные прикидки), кроме того, Office 2010 позволяет открывать документы из локальной копии без непосредственной связи с сервером (сам я не проверял - так уверяют авторы блогов, которые я читал, приходится верить). А это значит, что в принципе несколько авторов могут независимо внести правки в одну и ту же область. В этом случае Word не может автоматически слить изменения и предлагает автору (тому, который пытается сохранить свой документ последним) разрешить конфликты вручную.

Вот так будет выглядеть сообщение об обнаружении конфликта:

А вот так - панель со списком конфликтующих изменений и текст, который попал в конфликт:

Вот так примерно это выглядит. Ну а теперь немного тех самых технических подробностей.

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

Итак, работа офисного пакета с нелокальными документами (т.е. загружаемыми по сети из публичных источников) строится на таких компонентах как:

• Локальном хранилище Office Document Cache и программе Upload Center (msosync.exe)
• Протоколах File Sync via SOAP over HTTP и Binary Requests for File Synchronization via SOAP Protocol Specification

Office Document Cache и Upload Center  

Все документы, загружаемые извне (например, с узла SharePoint или папки в SkyDrive) на компьютер пользователя сохраняются в специальном хранилище - Office Document Cache (ODC). Все офисные приложения, т.е. и Word, и Excel, и PowerPoint работают с этим хранилищем. Основная (но не единственная!) его задача - уменьшение времени при повторном открытии файлов. Физически хранилище - это не более чем папка в профиле пользователя %userprofile%\AppData\Local\Microsoft\Office\14.0\OfficeFileCache. Для управления хранилищем используется приложение Upload Center (или Центр отправки в русскоязычном Office) - процесс Msosync.exe.

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

Co-authoring

Для реализации собственно совместной работы используются дв специализированных протокола: File Sync via SOAP over HTTP и Binary Requests for File Synchronization via SOAP Protocol Specification. Оба протокола рассматривают редактируемые файлы как структурированные сущности (используется специальный термин для единицы структуризации: хранимая ячейка (storage cell)). Сам протокол ничего не знает о содержимом и форматах этих сущностей - это полностью отдается на откуп клиентам.

Оба протокола работают (как ясно из названия) поверх SOAP (говорится о HTTP-реализации, но я подозреваю, что никаких особых привязок именно к HTTP в спецификациях нет).

Первый из протоколов обеспечивает:

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

Второй протокол позволяет обмениваться изменениями (т.е. передавать не целиком файл, а только измененные хранимые ячейки) между клиентами. Понятно, что для корректной работы на каждой стороне должны быть одинаковые клиенты, либо должен быть способ им обменяться информацией о том, какой формат имеют файлы и какие его части синхронизируются. Для этого в протоколе предусмотрены такие понятия как: описание хранилища (Storage Manifest), пользовательские данные (User Data) и настраиваемые фильтры (Custom Filter) - для идентификации которых используются глобально-уникальные идентификаторы (GUID), которые определяет вендор форматов. 

Описания обоих протоколов опубликованы на сайте MSDN: [MS-FSSHTTP]: File Synchronization via SOAP over HTTP Protocol Specification и [MS-FSSHTTPB]: Binary Requests for File Synchronization via SOAP Protocol Specification в рамках инициативы Microsoft Open Specification Promise.

Описания того, как организуется взаимодействие между экземплярами Word (т.е. описание тех самых хранилищ, фильтров, ...) доступно на там же сайте и по той же программе: [MS-WORDLFF]: Word Co-Authoring File Format (.xml) in Document Lock Persistence Structure Specification. Для других приложений я подобных описаний не нашел (скорее всего, плохо искал или они просто еще не выложены), но данная функциональность также заявлена для Excel и OneNote.

Вместо заключения 

К сожалению я не очень владею хитросплетениями лицензирования по программе Microsoft Open Specification Promise - вроде бы лицензирование по ней предполагает возможность свободной реализации в рамках Community-проектов, и какие-то отчисления, если проект коммерческий - но, это туманные воспоминания 3-4 летней давности и все уже могло измениться (а еще я мог сам тогда не разобраться).

Но это что касается юридических вопросов, а в техническом плане все перечисленные протоколы, в первую очередь MS-FSSHTTP и MS-FSSHTTPB, практически не содержат вендор-специфичных деталей (единственно, что я нашел при первичном анализе - необходимость размещать сервисы по пути <сервер>/_vti_bin/cellstorage.svc, где сервер - тот с которого забираются файлы). 

А это значит, что если в плане лицензирования все окажется хорошо, можно будет ожидать, что в ближайшее время поддержка механизмов co-authoring для Office 2010 будет появляться и у других поставщиков ECM-систем.