Поездки
Подготовка мобильных устройств с помощью SyncML
Рамон Арджона (Ramon Arjona)
Cодержание
Что такое OMA?
SyncML: XML для синхронизации
Элементы SyncML
Элементы SyncBody
Но погодите! Это еще не все!
Применение SyncML на практике
В выпуске журнала MSDN Magazine за апрель 2008 года Майк Каллигаро (Mike Calligaro) в рубрике «Поездки» написал статью о подготовке устройства Windows Mobile с использованием файлов XML и API DMProcessConfigXML. Использованные Майком файлы XML были основаны на стандарте подготовки клиентов открытого сообщества производителей мобильной связи (Open Mobile Alliance Client Provisioning – OMA-CP) по управлению устройствами, ранее известном как протокол приложений для беспроводной связи (протокол WAP).
OMA-CP нормально работает при управлении несколькими устройствами, и в статье Майка имеются предложения по способам передачи нескольким устройствам одновременно данных для их подготовки. Но что если необходимо систематически, в течение длительного времени подготавливать тысячи устройств? И что если необходимо знать, какие параметры программного обеспечения и реестра уже установлены на устройствах, которыми нужно управлять?
Такого рода масштабные, скоординированные усилия по подготовке являются областью действия стандарта управления устройствами открытого сообщества производителей мобильной связи (OMA Device Management – OMA-DM). Протокол OMA-DM основан на диалекте XML, именуемом SyncML, который может быть использован для подготовки устройств и управления ими в корпоративном масштабе. В этой статье рассказывается о структуре документа SyncML, который используется в протоколе OMA-DM. Я рассмотрю определенные сценарии использования для платформы Windows Mobile, в том числе удаленное стирание памяти устройства. Я также продемонстрирую, как можно добавить закладку в избранное браузера на устройстве, используя XML из статьи Майка в сочетании с OMA-DM.
Что такое OMA?
Открытое сообщество производителей мобильной связи (Open Mobile Alliance – OMA) - это отраслевая группа, состоящая из более чем 200 операторов мобильной связи, производителей мобильных устройств и поставщиков программного обеспечения (включая Майкрософт). OMA было сформировано в 2002 году, чтобы создать единую группу для управления возрастающим количеством стандартов мобильных устройств, появляющихся на рынке, включая WAP, стандарт управления устройствами Device Management и SyncML. Наличие множества групп приводило к дублированию работы, поэтому партнеры по отрасли собрались вместе и соединили все важные инициативы под эгидой единой группы.
Стандарты OMA помогают упростить работу с мобильными устройствами и сетями путем создания не находящегося в чьей-то собственности способа связи между протоколами. SyncML и OMA-DM являются двумя аспектами этого семейства открытых протоколов. Подобно всем протоколам, они, в определенной степени, подвержены интерпретации, и каждый поставщик может свободно поставлять собственные дополнительные расширения. Но работа с ними проще и прямолинейнее, чем попытки преодолеть препятствия защищаемого формата, принадлежащего конкретному поставщику.
SyncML: XML для синхронизации
SyncML – это разметка на основе XML, используемая в качестве основы большинства протоколов, определенных OMA. Документ SyncML именуется сообщением. Сообщение должно состоять из XML-документа правильного формата, но не обязательно допустимого. В нем должны совпадать теги начала и завершения для всех элементов, все атрибуты должны быть заключены в кавычки, и во всем остальном оно также должно соответствовать базовому определению правильного формата — ключевому для любого документа, именующего себя XML.
Несмотря на существование определения типа документа (DTD) SyncML от отправителя и получателя не требуется проверки на соответствие ему. Одна из причин этого состоит в том, что проверка требует дополнительной памяти и времени процессора, а мобильным устройствам часто недостает и того, и другого. В свою очередь, сообщение содержит элементы команды, которые выполняют всю тяжелую работу конкретных протоколов OMA.
SyncML и OMA-DM не зависят от способа передачи данных. Привязки к способам передачи данных уже определены для протоколов HTTP и Object Exchange (OBEX), возможно определение и других привязок. Это делает SyncML и OMA-DM полезными для беспроводной подготовки устройств. Используя SyncML и OMA-DM с совместимым сервером управления устройствами, можно передавать настройки на устройства, не используя карты памяти, не привязывая устройство и не требуя никаких действий (таких как посещение веб-сайта) от конечного пользователя.
В пакете SyncML содержится одно или несколько сообщений. Пакет SyncML включает в себя все сообщения, которыми обменялись отправитель и получатель.
Элементы SyncML
Документ SyncML состоит из корневого элемента SyncML, заголовка, определенного элементом SyncHdr, и тела, определенного элементом SyncBody. Корневым элементом документа SyncML всегда является элемент SyncML, который выглядит следующим образом:
<SyncML xmlns='SYNCML:SYNCML1.1'>
...
</SyncML>
Элемент SyncML содержит дочерние элементы SyncHdr и SyncBody. Элемент SyncHdr выглядит подобно разметке на рис. 1. Этот короткий заголовок сообщает всю информацию, необходимую получателю для обработки сообщения.
Рис. 11. SyncHdr
<SyncHdr>
<VerDTD>1.2</VerDTD>
<VerProto>DM/1.2</VerProto>
<SessionID>1</SessionID>
<MsgID>1</MsgID>
<Target>
<LocURI>https://mgmt.contoso.com/ </LocURI>
</Target>
<Source>
<LocURI>urn:uuid:6D67E196-D082-4c91-A0DD-DEB3D1D58EB5</LocURI>
<LocName>MyDeviceName</LocName>
</Source>
<Cred>
<Meta>
<Format xmlns="syncml:metinf">b64</Format>
<Type xmlns="syncml:metinf">syncml:auth-md5</Type>
</Meta>
<Data>ODZlMDNiYmM1MjA1YTI3MDc5MDk2MDcwYTA4OGM2Zjg=</Data>
</Cred>
</SyncHdr>
Элемент VerDTD указывает, что это сообщение соответствует версии 1.2 протокола представления SyncML Representation Protocol, как он определен в OMA. Элемент VerProto дает сходное указание: данное сообщение имеет дело с версией 1.2 протокола OMA-DM. Номера версий одинаковы, но существует различие:. SyncML используется для иных протоколов OMA, включая протокол управления устройствами (о котором я рассказываю в этой статье) и протокол синхронизации данных (для которого был первоначально разработан SyncML).
Элемент SessionID указывает, какой сеанс SyncML рассматривается сейчас. Значение этого идентификатора не может превышать четырех байт.
MsgID – это идентификатор, уникальный внутри сеанса. Он используется для отслеживания обмена сообщениями между отправителем и получателем. Когда получатель отправляет ответ с результатами выполнения команды, то такое ответное сообщение ссылается на сообщение, на которое дается ответ, включая MsgID в элемент MsgRef.
Элемент Target указывает, кто должен стать получателем сообщения. Элемент Source указывает, кто должен стать отправителем сообщения. Оба эти элемента содержат элемент LocURI, в котором находится строка, являющаяся уникальным идентификатором отправителя или получателя. LocURI для Target и Source должен быть URL-адресом, URI или URN. Поскольку у сервера управления обычно уже имеется уникальное имя DNS, то полное доменное имя сервера управления часто можно увидеть в LocURI сообщений, отправитель или получатель которых является сервером управления.
Обратите внимание на то, что ни элемент Target, ни элемент Source не относятся к адресации или маршрутизации сообщения напрямую. Эти задачи оставлены приложению управления устройствами и поддерживающим транспортным протоколам.
Мобильные устройства часто обозначаются URN, который, согласно определению RFC 4122, ссылается на GUID и таким образом дает уникальную ссылку на устройство, к которому происходит обращение. Сопоставление этого GUID с адресом, которого можно достигнуть по сети, возлагается на приложение. Поскольку по GUID нельзя интуитивно определить, о каком конкретном устройстве идет речь, то к элементу Source добавляется элемент LocName, в котором содержится имя устройства, отправившего сообщение SyncML.
Наконец, элемент Cred содержит информацию, определяющую отправителя. В нем имеется пара элементов Meta, уведомляющих получателя, что данное приложение использует схему проверки подлинности MD5, которая определена в стандарте SyncML, и что маркер безопасности зашифрован в формате base-64. Элемента Data, находящийся на том же уровне, что и элемент Meta, содержит маркер проверки подлинности, который может быть использован получателем для определения отправителя.
Элемент SyncBody
Элемент SyncBody показан на рис. 2. Следует учесть, что элементы Target здесь, как и в SyncHdr, обозначаются LocURI. Почти все в SyncML обозначается LocURI. LocURI построен в соответствии с вложенной иерархической структурой, подобной иерархии элементов XML, но обработка LocURI требует несколько меньше ресурсов, чем обработка серии вложенных узлов XML. Корень концептуального дерева обозначается символом «.», который необходимо указывать всегда.
Рис. 2. Элемент SyncBody
<SyncBody>
<Add>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/PkgID
</LocURI>
</Target>
<Data>pkg id setbrowserfavorite</Data>
</Item>
<Item>
<Target>
<LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/PkgURL
</LocURI>
</Target>
<Data>http://content.contoso.com/download/SetBrowserFavorite.cab
</Data>
</Item>
</Add>
<Exec>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/Operations/DownloadInstall </LocURI>
</Target>
</Item>
</Exec>
<Final/>
</SyncBody>
Дерево содержит сведения о мобильном устройстве, включая такие подробности, как имеющийся объем памяти или исполняемые файлы, доступные для вызова через OMA-DM. Если для ссылки на это дерево сведений о мобильном устройстве используется LocURI, то он всегда должен быть полным URI. Полным в том смысле, что он должен быть задан от корня устройства до необходимого конечного объекта, к которому требуется обратиться. Частичные или относительные URI недопустимы в этой части спецификации OMA-DM.
Отметьте, что я называю это «концептуальным» деревом. Это потому, что спецификации SyncML и OMA-DM не навязывают никаких деталей реализации того, как эта информация сохраняется в резервном хранилище, ни мобильному устройству, ни серверу управления устройствами. Данные для SyncML должны быть представлены так, как если бы они были деревом; тем не менее, хранить их можно в реляционной базе данных, в устройстве или реестре сервера, в энергозависимой памяти, в серии плоских файлов или каким-то иным способом. Спецификация полностью игнорирует механизм, используемый для физического сохранения данных.
Под корневым узлом находятся три важных дочерних узла: DevInfo, DevDetail и Vendor. Узел DevInfo содержит сведения о производителе устройства, языке, установленном на интерфейсе пользователя устройства и идентификаторе устройства. Узел DevDetail содержит прочую, независимую от поставщика, информацию об устройстве, включая его аппаратную версию и максимальную длину URI, поддерживаемую устройством. Большая часть прочих интересных сведений об устройстве хранится в узле Vendor. По спецификации, разработчики должны помещать свои расширения протокола OMA-DM ниже узла Vendor, и именно там вам придется потратить большую часть времени на подготовку устройств Windows Mobile и управление ими.
Удаленное стирание памяти
Команда Exec всегда говорит устройству сделать что-то, но OMA-DM может отдать устройству лишь ограниченный набор команд. В число того, что можно запустить на устройстве Windows Mobile посредством OMA-DM, входит удаленное стирание памяти. Эта функция подобна функции стирания, которую предлагает клиентам Windows Mobile сервер Exchange, и весьма полезна в случае потери или кражи устройства. Команда на стирание памяти устройства с помощью OMA-DM выглядит следующим образом:
<Exec>
<CmdID>3</CmdID>
<Item>
<Target><LocURI>./Vendor/MSFT/RemoteWipe/doWipe</LocURI></Target>
</Item>
</Exec>
Память устройства можно стереть и с помощью OMA-CP. Так что, при желании, можно создать CAB-файл с XML подготовки в нем и доставить его устройству через загрузку OMA-DM. Затем содержимое файла CAB будет перенаправлено тому же CSP RemoteWipe, который будет вызван OMA-DM, и результаты будут идентичны.
Элемент SyncBody, показанный ранее, содержит один элемент Add. Элемент Add говорит получателю добавить узел или серию узлов к дереву сведений об устройстве. Реализация OMA-DM от Майкрософт поддерживает так называемое неявное добавление; это значит, что, если команда Add ссылается на LocURI с узлами, отсутствующими на устройстве, то все узлы, от корневых до оконечных, вставляются в дерево сведений об устройстве. Без этого расширения узлы пришлось бы добавлять к устройству по одному, что привело бы к быстрому исчерпанию пропускной способности, времени использования процессора и, со временем, терпения пользователя.
Эта команда Add добавляет кое-что к узлу Download для управления программным обеспечением на устройстве с URL-адресом content.contoso.com/download/SetBrowserFavorite.cab. В конечном итоге, данный URL будет маршрутизирован к поставщику служб настройки (CSP) на устройстве (по странному совпадению именуемому Download CSP), который попытается извлечь содержимое, указанное данным URL.
За командой Add следует команда Exec. Команда Exec указывает устройству что-то сделать. В данном случае она указывает устройству установить и загрузить пакет с идентификатором SetBrowserFavorite.cab.
За командой Exec следует элемент Final, который сообщает принимающему устройству, что это последнее сообщение SyncML, которое следует ожидать от данного сеанса. Без элемента Final получатель будет ожидать новых сообщений SyncML.
Если CAB-файл можно установить на устройство, скопировав его на него посредством ActiveSync, то, как правило, этот CAB-файл можно установить на устройство, используя OMA-DM. Файл CAB должен быть подписан сертификатом, которому доверяет устройство. Если файл не подписан допустимым сертификатом, установка файла CAB закончится неудачей. Это отличается от поведения, которое можно увидеть при установке неподписанного файла CAB через ActiveSync. При установке неподписанного файла через ActiveSync устройство может запросить подтверждения намерения установить неподписанный CAB, предполагая, что политика, установленная на устройстве, допускает это.
Протокол OMA-DM на устройстве Windows Mobile не запрашивает этого. Вместо этого возникает ошибка, о которой протокол уведомляет сообщением с кодом ошибки в приложении «Управляемые программы», а затем отправляет соответствующий код ошибки обратно серверу управления устройствами. Данная схема имеет смысл, поскольку ActiveSync инициируется тем, кто физически держит устройство в руках — то есть либо самим владельцем, либо лицом, которому владелец устройства доверяет. Протокол же OMA-DM запускается удаленным агентом в совершенно неподконтрольное пользователю время.
Прежде всего, с помощью Download CSP по указанному URL извлекается содержимое. Затем CAB-файл просматривается, и, если он не подписан, выдается ошибка. Если CAB-файл подписан, то Download CSP распаковывает его и должным образом рассылает его содержимое. Если CAB-файле содержится программное обеспечение, то оно устанавливается на устройство. Если в CAB-файле содержится XML-файл для подготовки OMA-CP (подобный CAB-файлу, созданному Майком в его статье), то XML- файл подготовки применяется к устройству. Если в CAB-файле находится обычное содержимое, такое как фильм или экранная заставка, то это содержимое сохраняется в файловой системе устройства.
Приложение «Управляемые программы» записывает все попытки установить CAB-файл на устройство через OMA-DM, удачные или нет. После завершения установки устройство отправляет обратно код, определенный стандартом OMA-DM, серверу управления, используя для этого новый сеанс OMA-DM.
Но погодите! Это еще не все!
Устройства Windows Mobile отвечают на подмножество командных элементов, указанных в SyncML. Ниже приведено несколько командных элементов, о которых я еще не говорил.
Команда Alert позволяет отправителю уведомить получателя. Например, от сервера управления устройству может прийти оповещение, которое дает ему указание пробудиться и начать сеанс. Или же в оповещении может содержаться информация, которая должна быть отображена конечному пользователю через интерфейс пользователя.
Элемент Atomic используется для группировки таких команд, которые должны закончиться успехом или неудачей как единое целое. Эта возможность важна для групп взаимосвязанных команд, когда частичный успех оставит устройство в нежелательном или неизвестном состоянии. Если не сгруппировать их в элементе Atomic, три отдельные команды Add сработают или не сработают независимо друг от друга и создадут три отдельных ответных сообщения для сервера управления.
Delete – это команда, противоположная Add. Команда Delete удаляет узел из дерева устройства. Если у узла есть дочерние узлы, удаляются и они. Некоторые узлы, такие как встроенный узел DevInfo и его дочерние узлы, не могут быть удалены, а попытка удалить их создаст код ошибки. Команда Replace заменяет определенный узел в дереве устройства.
Команд Get используется для запроса информации в дереве устройства и возвращает эту информацию отправителю в сообщении SyncML. Например, для получения объема памяти, доступной в текущий момент на устройстве, будет отправлена следующая команда Get:
<Get>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DeviceInformation/TotalStorage</LocURI>
</Target>
</Item>
</Get>
Команда Result отправляется в ответ на Get и содержит значение узла, запрошенного командой Get.
Элемент Sequence используется для того, чтобы сгруппировать узлы в определенном порядке. Если предполагается последовательная обработка одной команды за другой, то их необходимо сгруппировать в элемент Sequence. Иначе порядок исполнения не гарантирован.
И, наконец, элемент Status содержит код удачного или неудачного завершения, возвращаемый определенной операцией. Статус 200 обычно означает успешное завершение.
Применение SyncML на практике
SyncML появился не как протокол управления устройствами, а как протокол синхронизации устройств. Реализации протокола синхронизации OMA, основанные на SyncML, часто используются устройствами для синхронизации информации календаря и контактов. Базовая спецификация протокола SyncML затрагивает как требования для синхронизации, так и для управления. Это значит, что базовый протокол представления SyncML содержит элементы, которые никогда не используются в OMA-DM, и другие элементы, которые никогда не используются в синхронизации.
Те, кто читает спецификацию SyncML в первый раз, могут несколько запутаться, поскольку спецификация затрагивает две расходящиеся предметные области. Хотя синхронизация и управление частично перекрываются, это определенно не одно и то же. При изучении спецификации представления протокола полезно принципиально отделить элементы SyncML, используемые в управлении, от элементов, используемых и в синхронизации.
Для подготовки устройств через OMA-DM необходим сервер управления. Существует несколько коммерческих предложений, включая Microsoft System Center Mobile Device Manager 2008. Доступны также некоммерческие библиотеки и реализации SyncML. Из-за гибкости, которая предоставлена как поставщикам, так и тем, кто занимается реализацией, заставить серверы и устройства общаться с использованием OMA-DM не всегда так просто, как хотелось бы. Но сложности интеграции различных устройств, использующих стандарты OMA, намного предпочтительнее сложности взаимодействия устройств, использующих неразбериху не связанных друг с другом и защищенных законодательством об интеллектуальной собственности способов обмена информацией, которая господствовала на рынке мобильных устройств до появления OMA.
Вопросы и комментарии направляйте по адресу goplaces@microsoft.com.
Рамон Арджона (Ramon Arjona) – старший ведущий тестер в группе Windows Mobile корпорации Майкрософт.