Cet article a fait l'objet d'une traduction automatique.

Vous place

Mise en service À SyncML de périphérique mobile

Ramon Arjona

Contenu

Qu'est-ce que OMA ?
SyncML : code XML de synchronisation
Éléments SyncML
L'élément SyncBody
Mais, en attente ! Il est plus !
Placer SyncML au travail

Dans le avril 2008 émettre de MSDN Magazine Calligaro, Mike écrit une colonne vous place surCréation d'un périphérique Windows Mobile à l'aide fichiers XML et l'API DMProcessConfigXML. Les fichiers XML utilisé Mike étaient basés sur la norme de mise en service client ouvrir mobile Alliance (OMA) (PC OMA) pour la gestion de périphériques, précédemment appelée en tant que WAP (Wireless Application Protocol).

OMA-PC fonctionne correctement pour gérer plusieurs périphériques, et, dans sa colonne Mike a suggestions de façons d'injecter des informations d'attribution de privilèges d'accès aux périphériques multiples à la fois. Mais que se passe-t-il si vous devez provision des milliers de périphériques d'une façon systématique sur une longue période de temps ? Et que se passe-t-il si vous voulez savoir quels paramètres logiciels et du Registre sont déjà définis sur les périphériques que vous essayez de gérer ?

Ce type de coordonnées, l'effort d'attribution de privilèges d'accès est le domaine de gestion de périphériques OMA (MD OMA). Le protocole OMA-DM repose sur un langage de XML appelé SyncML, et il peut servir à fournir et gérer les périphériques dans un scénario d'entreprise. Cet article explique comment la structure d'un document SyncML utilisé dans le protocole MD-OMA. J'aborderai scénarios d'utilisation spécifique pour la plate-forme Windows Mobile, y compris le nettoyage à distance du périphérique. J'AI également explique comment vous pouvez définir un navigateur préféré sur le périphérique du code XML de colonne de Mike en association avec MD-OMA.

Qu'est-ce que OMA ?

OMAest un secteur comprenant plus de 200 opérateurs mobiles, les fabricants de périphériques mobiles et les fournisseurs de logiciels (y compris Microsoft). OMA formé dans 2002 pour créer un groupe unique pour gérer le nombre de normes de périphérique mobile qui ont été apparaissant dans le marché, notamment WAP, gestion de périphériques et SyncML burgeoning. Cette multiplicité de groupes créait duplication de travail, pour les partenaires concernées a reçu l'ensemble et tous ces initiatives importants établies sous un groupe unique parasol.

Normes OMA faciliter il travailler avec les périphériques mobiles et des réseaux en créant un moyen de communiquer entre les technologies nonproprietary. SyncML et OMA-DM sont deux aspects de cette famille de protocole ouvert. Comme tous les protocoles, ils sont soumis à une certaine quantité d'interprétation, et chaque fournisseur est libre de fournir ses propres extensions valeur ajoutées. Mais leur utilisation est plus facile et plus simple que d'essayer de négocier un format propriétaire et spécifiques au fournisseur.

SyncML : code XML de synchronisation

SyncML est un balisage XML-basé qui est utilisée comme base pour la plupart des protocoles définis par OMA. Un document SyncML est appelé un message. Le message doit être XML bien formé mais XML n'est pas nécessairement valide. C'est-à-dire, il doit correspondent balises ouvrantes et fermantes pour tous les éléments, doit ont des guillemets autour de tous les attributs et sinon, correspondre à la base définition de bien-formedness est essentielle pour tout document lui-même appel XML.

Il est une définition de type SyncML document (DTD), il n'est pas nécessaire que l'expéditeur ou destinataire valider par rapport à elle. Une des raisons de cette est que validation nécessite de mémoire supplémentaire et l'heure processeur et les périphériques mobiles ont tendance à être court sur les deux de ces ressources. Le message, à son tour, contient des éléments commande faire l'essentiel de protocoles OMA spécifiques.

SyncML et OMA-DM sont indépendant du transport. Il y sont les liaisons de transport définis pour HTTP et OBEX (Object Exchange), et il est possible pour les autres liaisons à définir. Cela permet SyncML et OMA-DM utiles pour les périphériques d'attribution de privilèges d'accès par voie hertzienne. Utilisez SyncML et OMA-DM avec un serveur de gestion du périphérique compatible, vous pouvez pousser configurations sur un périphérique sans utiliser une carte mémoire, sans tethering le périphérique et sans demander de l'utilisateur final pour l'interaction, telles que visitent un site Web.

Un ou plusieurs messages est contenu, d'un point de vue conceptuel, dans un package SyncML. Le package SyncML englobe tous les messages envoyés entre un expéditeur et un récepteur.

Éléments SyncML

Un document SyncML se compose d'un élément SyncML racine, un en-tête définie par l'élément SyncHdr et un corps définie par l'élément SyncBody. La racine d'un document SyncML est toujours un élément SyncML, qui ressemble à ceci :

<SyncML xmlns='SYNCML:SYNCML1.1'>
...
</SyncML>

L'élément SyncML contient les éléments enfants SyncHdr et SyncBody. Un élément SyncHdr ressemble à la balise dans la figure 1 . Cet en-tête court indique tout ce qu'un récepteur devez savoir pour traiter le message.

La figure 1 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>

L'élément VerDTD indique que ce message est conforme à la version 1.2 du protocole de représentation des propriétés SyncML, comme défini par OMA. L'élément VerProto indique quelque chose de similaire : que vous êtes un message qui concerne la version 1.2 du protocole MD-OMA. Les numéros de version sont identiques, mais les deux choses sont différentes. SyncML est utilisé pour les différents protocoles OMA, notamment un protocole de gestion des périphériques (que je suis aborder dans cette colonne) et un protocole de synchronisation de données (pour lequel SyncML a été conçu).

L'élément SessionID indique à quelle session SyncML que vous recherchez. La valeur de ce code peut être, au maximum 4 octets.

Le MsgID est un ID qui est unique dans la session. Il est utilisé pour effectuer le suivi de la conversation entre l'expéditeur et le destinataire. Lorsque le destinataire répond avec résultats, les résultats de faire référence à du message en cours a répondu à en incluant le MsgID dans un élément MsgRef.

L'élément cible indique qui le destinataire du message sert. L'élément source indique qui l'expéditeur du message sert. Ces éléments deux contient un élément LocURI qui contient la chaîne identifiant de l'expéditeur ou destinataire. Le LocURI de la cible et source doit être une URL, un URI ou un URN. Un serveur de gestion est ayant généralement déjà d'un nom unique DNS, il est courant pour voir le nom de domaine pleinement qualifié du serveur de gestion de la LocURI lorsque l'expéditeur ou destinataire est un serveur de gestion des.

Notez que ni la cible, ni l'élément source est directement liée à Adressage ou le message de routage. Ces tâches sont conservés à l'application Gestion des périphériques et les protocoles de transport prise en charge.

Les périphériques mobiles sont souvent désignés par un URN qui fait référence à un GUID, comme défini par RFC 4122, qui désigne unique le périphérique spécifique est adressé. C'est à l'application à mapper ce GUID vers une adresse qui est accessible via le réseau. Car le GUID n'est pas un moyen immédiatement intuitif pour savoir sur le périphérique spécifique que vous parlez, l'application a ajouté un élément LocName à l'élément source, qui contient le nom du périphérique dont provient le message SyncML.

Enfin, l'élément Identification contient des informations qui identifie l'origine. Il contient une paire de éléments META qui informe le destinataire que ce message utilise le schéma d'authentification MD5 qui est définie dans la norme SyncML et qui le jeton de sécurité est codé de base-64. L'élément de données qui est le frère des éléments META contient le jeton d'authentification utilisables par le destinataire de confirmer l'identité de l'expéditeur.

L'élément SyncBody

Un élément SyncBody est illustré figure 2 . Notez que les éléments de destination, simplement le souhaitez dans la SyncHdr sont identifiées par LocURI. Presque tout dans SyncML est identifiée par LocURI. Le LocURI est construite selon une structure arborescente imbriqués, semblable à la structure imbriquée arborescence d'un document XML, mais est un peu moins coûteuse à traiter à une série de nœuds XML imbriqués. La racine de l'arborescence conceptuel est identifiée par le «. » caractère, doit toujours être spécifié.

La figure 2 SyncBody élément

<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>

L'arborescence contient des informations sur le périphérique mobile, y compris détails tels que la quantité de mémoire qu'ou les fichiers exécutables sont disponibles pour être appelées via OMA-DM. Lorsqu'un LocURI est utilisé pour faire référence à cette arborescence d'information de périphérique, il doit toujours être un URI complet. C'est-à-dire qu'il doit être toujours spécifié à partir de la racine de périphérique vers la feuille spécifique pour être traités. URI partiel ou relatif ne sont pas autorisés dans cette partie de la spécification MD-OMA.

Notez que J'AI désignez-le comme une arborescence « conceptuelle. C'est parce que les spécifications SyncML et OMA-DM n'imposent pas les détails d'implémentation sur le périphérique mobile ou sur le serveur de gestion périphérique pour comment ces informations sont réellement conservées à une banque de sauvegarde. SyncML souhaite adresser les données comme s'il s'agissait d'une arborescence, mais vous pouvez le stocker dans une base de données relationnelle, dans le périphérique ou serveur Registre, dans la mémoire volatile, d'une série de fichiers plats ou dans une autre façon. La spécification est complètement agnostic au mécanisme utilisé pour physiquement conserver ces données.

Sous le nœud racine sont trois nœuds enfants important : DevInfo, DevDetail et d'un fournisseur. Le nœud DevInfo contient des informations sur le fabricant du périphérique, la langue définie sur l'interface utilisateur du périphérique et l'ID de périphérique. Le nœud DevDetail contient les autres informations fournisseur-indépendant sur le périphérique, y compris sa version matériel et la longueur maximale de l'URI pris en charge par le périphérique. La plupart des autres détails intéressants sur le périphérique sont stockés sous le nœud du fournisseur. Par spécification, les implémenteurs doivent park leurs extensions sur le protocole OMA-DM sous le nœud de fournisseur, et c'est dans laquelle vous passerez une grande partie de votre temps lorsque la mise en service ou Gestion des périphériques Windows Mobile.

Nettoyage à distance

Exec la commande indique toujours le périphérique pour faire quelque chose, mais il existe un ensemble limité d'opérations que le périphérique peut être commandé par OMA-DM. Une autre chose que peut être déclenchée par OMA-DM sur un périphérique Windows Mobile est un nettoyage à distance. Ceci est similaire à la fonctionnalité de nettoyage proposée pour les clients Windows Mobile par Exchange et est réellement utile si un périphérique sous votre contrôle a été perdu ou volé. La commande pour effacer un périphérique avec OMA-DM ressemble à ceci :

<Exec>
  <CmdID>3</CmdID>
  <Item>
    <Target><LocURI>./Vendor/MSFT/RemoteWipe/doWipe</LocURI></Target>
  </Item>
</Exec>

Il est possible effacer un périphérique avec OMA-PC, trop. Donc vous pouvez, si vous vouliez vraiment, créez un fichier CAB avec la mise en service XML qu'il et distribuer sur le périphérique via téléchargement MD-OMA. Contenu du fichier CAB est puis obtenir acheminé vers le même CSP RemoteWipe qui serait être appelée par OMA-DM et les résultats serait identique.

L'élément SyncBody illustrée précédemment contient un élément Ajouter. L'élément Ajouter indique le destinataire d'ajouter un nœud ou une série de nœuds à l'organigramme d'informations du périphérique. L'implémentation Microsoft de OMA-DM prend en charge un élément appelé implicite ajouter, qui signifie que si une commande ajouter fait référence à un LocURI avec des nœuds qui ne sont pas présents sur le périphérique, tous les nœuds de la racine à la feuille sont insérées dans l'arborescence d'informations du périphérique. Sans cette extension, nœuds serait doivent être ajoutés à l'arborescence périphérique une à la fois, ce qui serait rapidement consomment la bande passante, temps processeur, et, finalement, patience de l'utilisateur.

Cette commande Add ajoute quelque chose au nœud de téléchargement de gestion de logiciel sur le périphérique ayant la content.contoso.com/download/SetBrowserFavorite.cab URL. Au final, cette URL est routée à un fournisseur de services configuration (CSP) sur le périphérique, coincidentally appelé le CHIFFREMENT de téléchargement, qui tente d'extraire le contenu spécifié par cette URL.

La commande Add est suivie d'une commande EXEC. La commande EXEC indique le périphérique à aller faire quelque chose. Dans ce cas, il est indique le périphérique pour télécharger et installer le package avec le SetBrowserFavorite.cab code.

La commande EXEC est suivie d'un élément final, qui indique le récepteur Ceci est le dernier message SyncML qui doit être attendu pour cette session. Sans l'élément final, le récepteur attendez qu'il serait messages SyncML supplémentaires à suivre.

Si vous pouvez installer un fichier CAB sur le périphérique en copiant sur le périphérique via ActiveSync, vous pouvez généralement installer ce fichier CAB sur le périphérique à l'aide MD-OMA. Le fichier CAB doit être signé avec un certificat qui approuve le périphérique. Si le fichier n'est pas signé avec un certificat valide, l'installation du fichier CAB échouera. Ce le comportement diffère que vous verrez l'installation d'un fichier .cab non signé sur ActiveSync. Lorsque vous installez un fichier non signé via ActiveSync le périphérique peut demande confirmation de votre intention d'installer le fichier CAB non signé, en supposant que la stratégie sur le périphérique est configurée pour autoriser.

Le protocole OMA-DM sur un périphérique Windows Mobile ne vous invite pas. Il simplement échoue, vous de l'échec informe avec un message contenant un code d'erreur dans l'applet programmes gérés et envoie un code d'erreur associés retour au serveur de gestion périphérique. Cette conception est logique car ActiveSync est en cours initié par vous, ou nous espérons que quelqu'un vous approuvez, pendant que le périphérique est physiquement en votre main. MD-OMA est initiée par un agent à distance, à la fois est entièrement en dehors de votre contrôle.

Tout d'abord, le CHIFFREMENT télécharger extrait le contenu à partir de l'URL spécifiée. Puis il recherche dans le fichier CAB, puis échoue si elle est non signé. Si le fichier .cab est signé, le CHIFFREMENT télécharger décompresse le fichier CAB et envoie le contenu du fichier correctement. Si le fichier CAB contient des logiciels, le logiciel est installé sur le périphérique. Si le fichier CAB contient OMA-CP création XML, comme le fichier CAB Mike créé dans sa colonne, puis le code XML d'attribution de privilèges d'accès est appliqué à celui-ci. Si le fichier CAB contenu contenu simple, comme un film ou un écran de base, ce contenu est stocké sur le système de fichiers du périphérique.

L'applet programmes gérés enregistre chaque tentative, réussite ou échec, pour installer un fichier CAB sur le périphérique via MD-OMA. Une fois l'installation terminée, le périphérique envoie un code défini par L'OMA-DM standard sur le serveur gestion dans une nouvelle session MD-OMA.

Mais, en attente ! Il est plus !

Les périphériques Windows Mobile répondent à un sous-ensemble des éléments de commandes spécifié dans SyncML. Suivantes sont quelques éléments commande que je L'AI n'ont pas encore indiqué.

La commande mise en garde permet l'expéditeur informer le destinataire. Par exemple, une alerte d'un serveur de gestion vers un périphérique peut indiquer le périphérique pour réveiller et recommencer une session. Ou une alerte peut fournir des informations qui doivent être affichées à l'utilisateur final via l'interface utilisateur.

L'élément atomic est utilisé pour regrouper d'autres commandes qui doivent toutes réussisse ou échoue en tant qu'unité. Ceci est important lorsqu'un groupe de commandes est lié et réussite partielle devez laisser le périphérique dans un état indésirable ou inconnu. Sauf si regroupés dans un élément atomic, trois commandes Ajouter distincts serait réussisse ou échoue indépendantes les unes des autres et créer des trois messages de réponse distinct pour le serveur de gestion.

Supprimer est le contraire d'ajouter. La commande Supprimer supprime un nœud de l'arborescence de périphériques. Si le nœud possède des nœuds enfant, ceux sont supprimés, trop. Des nœuds, telles que le nœud DevInfo intégré et ses enfants, ne peut pas être supprimées et la tentative pour supprimer les génère un code d'erreur. La commande remplacer remplace un nœud donné dans l'arborescence de périphériques.

La commande Get est utilisée pour interroger l'arborescence de périphériques pour d'informations et renvoie ces informations dans un message SyncML à l'expéditeur. Par exemple, pour obtenir la quantité de stockage disponible actuellement sur le périphérique, la commande Get suivante serait envoyée :

<Get>
  <CmdID>3</CmdID>
  <Item>    
    <Target>
      <LocURI>./Vendor/MSFT/DeviceInformation/TotalStorage</LocURI>
    </Target>
  </Item>
</Get>

La résultat commande est envoyée en réponse à un Get contenant la valeur du nœud le obtenir demandé.

L'élément de séquence est utilisé pour regrouper des nœuds dans un ordre spécifique.Si vous prévoyez que les commandes traitées une après l'autre, vous devez les regrouper dans un élément de séquence.Sinon, l'ordre d'exécution n'est pas garantie.

Et enfin, l'élément d'état contient le code de réussite ou l'échec renvoyé par une opération donnée.Un état de 200 indique généralement la réussite.

Placer SyncML au travail

SyncML a commencé comme un protocole pas pour la gestion des périphériques mais pour synchronisation de périphérique.Implémentations du protocole de synchronisation OMA selon SyncML sont utilisées fréquemment pour autoriser les périphériques à synchroniser calendrier et les coordonnées.La spécification de protocole de base pour SyncML traite la configuration requise pour la synchronisation, ainsi que la configuration requise pour Gestion.Cela signifie que le protocole de représentation SyncML base contient des éléments qui sont jamais utilisés dans OMA-DM et autres éléments qui ne sont utilisés de la synchronisation.

Lecteurs initiale de la spécification SyncML peuvent trouver eux-mêmes un peu confondre car la spécification tente de résoudre le problème divergent deux domaines.Il est certains chevauchement entre la synchronisation et la gestion, les deux tâches sont certainement pas les mêmes.Il est utile pour segregate les éléments de SyncML qui sont utilisés dans Gestion d'un point de vue conceptuel de ceux utilisés dans la synchronisation lors de la révision la spécification de représentation de protocole.

Vous devez disposez un serveur de gestion pour activer vos périphériques via MD-OMA.Plusieurs offres commerciales sont disponibles, y compris Microsoft System Center Gestionnaire de périphérique mobile 2008.Et des bibliothèques SyncML noncommercial et les implémentations disponibles ainsi.Le montant de flexibilité autorisé à fournisseurs et les ingénieurs d'application signifie que ce qui rend les périphériques et serveurs parler à l'aide OMA-DM n'est pas toujours simple une voudrez.Mais les difficultés présentées par l'intégration de différents périphériques qui utilisent les normes OMA est immensely préférable à la difficulté de rendre les périphériques interagir à l'aide la hodgepodge des méthodes de communication non liés et propriétaires qui dominé le marché mobile Avant l'avénement des OMA.

Veuillez envoyer vos questions et commentaires àgoplaces@Microsoft.com.

Ramon Arjona un test principal responsable fonctionne dans l'équipe Windows Mobile chez Microsoft.