Continuar coloca
Dispositivos móviles con SyncML de aprovisionamiento
Ramon Arjona
Contenido
¿Qué es OMA?
SyncML: XML para sincronización
Elementos SyncML
El elemento SyncBody
Pero, se espera. Hay más!
Colocar SyncML para trabajar
En el de 2008 abril emitir de MSDN Magazine Calligaro Mike, escribí una columna continuar coloca sobre aprovisionamiento de un dispositivo de Windows Mobile mediante archivos XML y la API DMProcessConfigXML . Los archivos XML utiliza Mike se basaban en el estándar de abrir Mobile Alliance (OMA) (CP OMA) de aprovisionamiento de cliente para administración de dispositivos, conocido como inalámbrico protocolo (WAP).
CP de OMA funciona bien para administrar unos dispositivos, y en su columna Mike tiene sugerencias de formas de insertar información de aprovisionamiento a múltiples dispositivos a la vez. Pero ¿qué ocurre si necesita que suministrar miles de dispositivos de una manera sistemática durante un largo período de tiempo? Y ¿qué ocurre si tiene que saber qué configuración de software y del registro ya se establece en los dispositivos que intenta administrar?
Este tipo de trabajo de aprovisionamiento grande y coordinar es el dominio de administración de dispositivos de OMA (OMA DM). El protocolo de OMA DM se según un dialecto de XML denominado SyncML y puede utilizarse para aprovisionar y administrar dispositivos en un escenario de empresa. Esta columna analizará la estructura de un documento SyncML utilizado en el protocolo de OMA DM. Cubrirá escenarios específicos de la plataforma Windows Mobile, incluidos remotamente borrar el dispositivo. También mostrará cómo puede establecer un explorador favorito en el dispositivo mediante el código XML de la columna de Mike en conjunción con de OMA DM.
¿Qué es OMA?
OMA es un grupo de sector con más de 200 operadores móviles, fabricantes de dispositivos móviles y los proveedores de software (incluido Microsoft). OMA se formó en 2002 para crear un único grupo para administrar el número creciente de estándares de dispositivo móvil que se han aparezcan en el mercado, incluidos WAP, administración de dispositivos y SyncML. Este multiplicidad de grupos creando duplicación de trabajo, por lo que los asociados de sector preocupa obtuvo juntos y poner todas estas iniciativas importantes juntos en un grupo de sombrilla único.
Los estándares OMA facilitar trabajar con dispositivos móviles y las redes al crear una forma de nonproprietary comunicarse entre tecnologías. SyncML y OMA-DM son dos aspectos de esta familia de protocolo abierto. Al igual que todos los protocolos, estarán sometidos a una determinada cantidad de interpretación y cada proveedor es libertad para proporcionar sus propia extensiones de valor agregados. Pero trabajar con ellos es más fácil y más sencillo que intentar negociar un formato propio específica del proveedor.
SyncML: XML para sincronización
SyncML es un marcado basado en XML que se utiliza como base para la mayoría de los protocolos definidos por OMA. Un documento SyncML se llama a un mensaje. El mensaje debe ser XML bien formado pero XML necesariamente no válido. Es decir, debe tener que coinciden con las etiquetas de apertura y de cierre de todos los elementos, debe tiene comillas alrededor de todos los atributos y en caso contrario, ajustarse a la definición básica de bien-formedness es fundamental para cualquier documento al llamar a sí mismo XML.
Aunque hay una definición de tipo de documento (DTD) SyncML, no es necesario que el remitente o destinatario validar en él. Una de las razones para esto es que validación requiere memoria adicional y tiempo de procesador y los dispositivos móviles suelen ser breve en ambos de estos recursos. El mensaje, a su vez, contiene elementos de comando que realizan el trabajo pesado de protocolos OMA específicos.
SyncML y OMA-DM son independiente de transporte. Hay los enlaces de transporte definidos para HTTP y Exchange de objetos (OBEX) y sería posible para los otros enlaces debe estar definido. Esto facilita SyncML y de OMA DM útil para los dispositivos de aprovisionamiento a través del aire. Con SyncML y de OMA DM con un servidor de administración de dispositivos compatibles con, puede insertar configuraciones en un dispositivo sin usar una tarjeta de memoria, sin tethering el dispositivo y sin preguntar al usuario final para la interacción, tales como visitar un sitio Web.
Conceptualmente, uno o más mensajes se encuentra en un paquete SyncML. El paquete SyncML abarca todos los mensajes enviados entre un emisor y un receptor.
Elementos SyncML
Un documento de SyncML se compone de un elemento de SyncML raíz, un encabezado definida por el elemento SyncHdr y un cuerpo definido por el elemento SyncBody. La raíz de un documento SyncML siempre es un elemento SyncML, el cual este aspecto:
<SyncML xmlns='SYNCML:SYNCML1.1'>
...
</SyncML>
El elemento SyncML contiene los elementos de secundarios SyncHdr y SyncBody. Un elemento SyncHdr parece el marcado en la figura 1 . Este encabezado corta indica todo lo que un receptor tendría que saber para procesar el mensaje.
La figura 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>
El elemento de VerDTD indica que este mensaje ajusta al versión 1.2 del protocolo de la representación SyncML, tal como se define en OMA. El elemento VerProto indica algo similar: que está viendo un mensaje que se encarga de versión 1.2 del protocolo de OMA DM. Los números de versión son los mismos, pero las dos cosas son diferentes. SyncML se utiliza para distintos protocolos OMA, incluidos un protocolo de administración de dispositivo (que me explicar en esta columna) y un protocolo de sincronización de datos (para el que SyncML se diseñó originalmente).
El elemento de SessionID indica en qué sesiones SyncML buscas. El valor de este IDENTIFICADOR puede ser, como máximo, 4 bytes de longitud.
El MsgID es un IDENTIFICADOR que es único dentro de la sesión. Se utiliza para mantener el seguimiento de la conversación entre remitente y receptor. Cuando el destinatario responde con resultados, el mensaje se han respondido al incluir el MsgID en un elemento MsgRef consulte los resultados.
El elemento Target indica que el receptor del mensaje está pensado para ser. El elemento de origen indica que el remitente del mensaje está pensado para ser. Estos elementos ambos contienen un elemento LocURI que contiene la cadena que identifica el remitente o destinatario. El LocURI del destino y origen debe ser una dirección URL, un identificador URI o una URN. Ya que un servidor de administración normalmente, ya tendrá un nombre DNS único, es habitual para ver el nombre de dominio completo del servidor de administración de la LocURI cuando el remitente o destinatario es un servidor de administración.
Tenga en cuenta que ni el destino del elemento de origen directamente se relaciona con direcciones o el mensaje de enrutamiento. Estas tareas quedan en la aplicación de administración de dispositivos y los protocolos de transporte auxiliares.
Los dispositivos móviles con frecuencia se conocen por un URN que hace referencia a un GUID, definido por RFC 4122, que hace referencia identifica al dispositivo específico que se va a tratar. Es la aplicación para asignar este GUID volver a una dirección que se puede llegar a través de la red. Dado que el GUID no es un modo intuitivo inmediatamente de saber en qué dispositivo específico hablar, la aplicación ha agregado un elemento LocName al elemento de origen, que contiene el nombre del dispositivo que se originó el mensaje SyncML.
Por último, el elemento de credenciales contiene información que identifica el autor. Contiene un par de elementos META que informar a los destinatarios que este mensaje utiliza el esquema de autenticación de MD5 que está definido en el estándar SyncML, y que el token de seguridad está codificado en base-64. El elemento de datos que es el elemento relacionado de los elementos META contiene el símbolo de autenticación que puede utilizarse por el destinatario para confirmar la identidad del remitente.
El elemento SyncBody
Un elemento SyncBody se muestra en Figura 2 . Observe que aquí, los elementos de destino sólo como en el SyncHdr, se identifican mediante LocURI. Casi todo lo en SyncML se identifica mediante LocURI. El LocURI está integrado de acuerdo con una estructura de árbol anidados, similar a la estructura de árbol anidado de un documento XML, pero es algo menos costoso proceso de una serie de nodos XML anidados. La raíz del árbol conceptual se identifica mediante la ". " carácter, que siempre se debe especificar.
La Figura 2 SyncBody elemento
<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>
El árbol contiene información sobre el dispositivo móvil, incluidos los detalles como la cantidad de memoria se o los archivos ejecutables disponibles que se va a invocar a través de OMA DM. Cuando un LocURI se utiliza para hacer referencia a este árbol de información del dispositivo, siempre debe ser un identificador URI completo. Es decir, siempre se debe especificar desde la raíz de dispositivo hacia abajo hasta la hoja específico que tratar. Los identificadores URI parcial o relativa no se permiten en esta parte de la especificación de OMA DM.
Tenga en cuenta que hace referencia a esto como un árbol "conceptual". Esto se debe a que las especificaciones SyncML y de OMA DM no imponer los detalles de implementación en el dispositivo móvil o en el servidor de administración de dispositivo de cómo esta información se almacena en realidad en un almacén de respaldo. SyncML quiere tratar los datos como si fuese un árbol, pero se podría almacenar en una base de datos relacional, en el registro de dispositivo o servidor, en la memoria volátil, en una serie de archivos sin formato o en alguna otra forma. La especificación es completamente independiente el mecanismo utilizado para físicamente conservar estos datos.
Debajo del nodo raíz se tres nodos secundarios importante: DevInfo, DevDetail y proveedor. El nodo DevInfo contiene información sobre el fabricante del dispositivo, el idioma de interfaz de usuario del dispositivo y el identificador de dispositivo. El nodo DevDetail contiene otra información de proveedor independiente sobre el dispositivo, incluyendo su versión de hardware y la longitud máxima del identificador URI compatible con el dispositivo. La mayoría de los demás detalles interesantes sobre el dispositivo se almacenan en el nodo de proveedor. Por especificación, los implementadores deben park sus extensiones al protocolo de OMA DM bajo el nodo de proveedor y esto es que pasará gran parte de su tiempo cuando aprovisionamiento o administrar los dispositivos Windows Mobile.
Barrido remoto
comando de ejecución Y el siempre indica el dispositivo para hacer algo, pero no hay un conjunto limitado de cosas que puede se ordene el dispositivo para realizar por de OMA DM. Una otro lo que puede realizarse en un dispositivo Windows Mobile con de OMA DM es un barrido remoto. Esto es similar a la característica de eliminación para los clientes de Windows Mobile que ofrece Exchange y es realmente útil si un dispositivo en el control se ha perdido o robado. El comando para borrar un dispositivo con de OMA DM es similar a ésta:
<Exec>
<CmdID>3</CmdID>
<Item>
<Target><LocURI>./Vendor/MSFT/RemoteWipe/doWipe</LocURI></Target>
</Item>
</Exec>
Es posible limpiar un dispositivo con OMA de CP, demasiado. Por lo que puede, si realmente desea, crear un archivo CAB con aprovisionamiento XML en él y distribuirlo al dispositivo a través de OMA DM descarga. Contenido del archivo CAB, a continuación, obtener se enrutan al mismo CSP RemoteWipe que invoca de OMA DM, y el resultado sería el mismo.
El elemento de SyncBody mostrado anteriormente contiene un elemento de agregar. El elemento Agregar indica el receptor para agregar un nodo o una serie de nodos al árbol de información del dispositivo. Agrega la implementación de OMA DM admite algo denominado implícita de Microsoft, lo que significa que si un comando Add hace referencia a un LocURI con nodos que no están presentes en el dispositivo, todos los nodos de la raíz en la hoja se insertan en el árbol de dispositivos de información. Sin esta extensión, los nodos tendría que agregarse al árbol de dispositivos uno en un momento, lo que podría consumir rápidamente ancho de banda, tiempo de procesador, y, finalmente, paciencia del usuario.
Este comando Add es agregar algo al nodo de descarga de administración de software en el dispositivo tener content.contoso.com/download/SetBrowserFavorite.cab la dirección URL. En última instancia, esta dirección URL se enrutarán a un proveedor de servicio de configuración (CSP) en el dispositivo, coincidentally denominado el proveedor de descarga, que se intentará recuperar el contenido especificado por esta dirección URL.
El comando Add es seguido por un comando de ejecución Y. El comando de ejecución Y indica al dispositivo que vaya a hacer algo. En este caso, es que indica el dispositivo para Aceptar descargar e instalar el paquete con el SetBrowserFavorite.cab ID.
El comando de ejecución Y va seguido de un elemento final, que indica el receptor que éste es el último mensaje de SyncML que se debe esperar para esta sesión. Sin el elemento final, el receptor esperaría que podría haber varios mensajes SyncML para seguir.
Si para poder instalar un archivo CAB en el dispositivo por copiarla en el dispositivo a través de ActiveSync, normalmente, puede instalar ese archivo CAB en el dispositivo mediante de OMA DM. El archivo CAB debe estar firmado con un certificado que confía en el dispositivo. Si el archivo no está firmado con un certificado válido, se producirá un error en la instalación del archivo CAB. Este comportamiento de es diferente del que verá al instalar un archivo CAB sin signo a través de ActiveSync. Cuando se instala un archivo sin signo a través de ActiveSync del dispositivo es posible que solicitará confirmación de la intención de instalar el COMITÉ sin signo, suponiendo que la directiva en el dispositivo se establece en permitir esto.
El protocolo de OMA DM en un dispositivo Windows Mobile no le indica que. Sólo se produce un error, le informa del error con un mensaje que contiene código de error en el subprograma programas administrado y envía un código de error relacionados volver al servidor de administración de dispositivo. Este diseño sentido porque se se inicia ActiveSync por usted, o Espero que alguien confía, mientras el dispositivo está físicamente en sus manos. De OMA DM se inicia por un agente remoto a la vez que está completamente fuera de su control.
En primer lugar, el proveedor de descarga recupera el contenido de la dirección URL especificada. A continuación, examina el archivo CAB y falla si es sin signo. Si está firmado el archivo CAB, el proveedor de descarga desempaqueta el archivo CAB y distribuye el contenido del archivo correctamente. Si el comité asesor del cambio de software, el software está instalado en el dispositivo. Si el comité asesor del cambio contiene CP de OMA aprovisionamiento XML, como el archivo CAB Mike creado en su columna, a continuación, se aplica el aprovisionamiento XML para el dispositivo. Si el archivo CAB contiene contenido sin formato, como una película o una pantalla principal, este contenido se almacena en el sistema de archivos de dispositivo.
El subprograma programas administrado registra cada intento, correcto o incorrecto, para instalar un archivo CAB en el dispositivo a través de OMA DM. Una vez finalizada la instalación, el dispositivo envía un código definido por el OMA-DM estándar al servidor de administración en una nueva sesión de OMA DM.
Pero, se espera. Hay más!
Los dispositivos Windows Mobile responden a un subconjunto de los elementos de comandos especificados en SyncML. Los siguientes son unos elementos de comandos que aún no ha tratado.
El comando alerta permite al remitente notificar el destinatario. Por ejemplo, una alerta desde un servidor de administración en un dispositivo es posible que indique el dispositivo para reactivar e iniciar una sesión. O una alerta podría contenga información que debe mostrarse al usuario final a través de la interfaz de usuario.
El elemento atomic se utiliza para agrupar otros comandos que deben todo correctamente o fracasan como una unidad. Esto es importante cuando está relacionado con un grupo de comandos y éxito parcial podría dejar el dispositivo en un estado desconocido o no deseado. A menos que se agrupan en un elemento atomic, tres comandos agregar independientes podrían correctamente o se producirá un error independientes entre sí y generan tres mensajes de respuesta independientes para el servidor de administración de.
Eliminar es el opuesto de agregar. El comando Eliminar Quita un nodo del árbol de dispositivos. Si el nodo tiene nodos secundarios, los que se eliminan, demasiado. No se pueden quitar algunos nodos, como el nodo DevInfo integrado y sus elementos secundarios, y el intento de quitarlos genera un código de error. El comando reemplazar reemplaza un nodo determinado en el árbol de dispositivos.
El comando Get se utiliza para consultar el árbol de dispositivos para obtener información y devuelve esa información en un mensaje SyncML al remitente. Por ejemplo, para obtener la cantidad de almacenamiento disponible actualmente en el dispositivo, el siguiente comando Get se enviará:
<Get>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DeviceInformation/TotalStorage</LocURI>
</Target>
</Item>
</Get>
El comando resultado se envía en respuesta a un Get, que contiene el valor del nodo el Get solicitado.
El elemento de secuencia se utiliza para agrupar los nodos en un orden específico. Si espera que comandos procesadas uno tras otro, debe agruparlos en un elemento de secuencia. Garantizar en caso contrario, que el orden de ejecución no es.
Y por último, el elemento de estado contiene el código de éxito o error devuelto por una operación dada. Normalmente, un estado de 200 indica éxito.
Colocar SyncML para trabajar
SyncML comenzó como un protocolo no para la administración de dispositivos, pero para sincronización de dispositivos. Las implementaciones del protocolo de sincronización OMA basado en SyncML se utilizan con frecuencia para permitir que los dispositivos sincronizar el calendario y la información de contacto. La especificación de protocolo de base para SyncML trata los requisitos para la sincronización, así como los requisitos de administración de. Esto significa que el protocolo de representación SyncML base contiene elementos que nunca se utilizan en de OMA DM y otros elementos que nunca se utilizan en sincronización.
Lectores de la primera vez de la especificación SyncML posible a sí mismos un poco confundido, porque la especificación está intentando solucionar dos dominios con problemas divergentes. Aunque hay cierta superposición entre sincronización y la administración, las dos cosas definitivamente no son iguales. Resulta útil separar los elementos de SyncML que se utilizan en la administración desde un punto de vista conceptual de los que se utilizan en la sincronización al revisar la especificación de representación en forma de protocolo.
Debe tener un servidor de administración para suministrar los dispositivos a través de OMA DM. Existen varias ofertas comerciales, incluidos Microsoft System Center el Administrador de dispositivos móviles 2008. Y hay bibliotecas SyncML noncommercial y las implementaciones disponibles así. La cantidad de flexibilidad permite proveedores y los implementadores significa que dispositivos y servidores de hablar con de OMA DM no es siempre tan sencillo como una desearía. Pero las dificultades que presenta la integración de dispositivos diferentes que utilizan los estándares OMA es extremadamente preferible a la dificultad de realizar interoperar utilizando el hodgepodge de métodos de comunicación no relacionados y propietario que había dominado el mercado móvil antes de la llegada de OMA de dispositivos.
Envíe sus preguntas y comentarios a goplaces@Microsoft.com.
Ramon Arjona un responsable de pruebas jefe está trabajando en el equipo de Windows Mobile en Microsoft.