Este artigo foi traduzido por máquina.
Going locais
Pager ou telefone celular configuração com SyncML
Ramon Arjona
Conteúdo
O que É o OMA?
SyncML: XML para sincronização
Elementos de SyncML
O elemento SyncBody
Mas, espere! Há mais!
Colocar SyncML para trabalhar
No de 2008 abril emitir de MSDN Magazine Mike, Calligaro escreveu uma coluna going locais sobreprovisionamento de um dispositivo Windows Mobile usando arquivos XML e a API DMProcessConfigXML. Os arquivos XML usado de Mike foram baseados no padrão abrir Mobile Alliance (OMA) Configuração de cliente (OMA-CP) para gerenciamento de dispositivo, anteriormente conhecido como protocolo de aplicativo sem fio (WAP).
OMA-CP funciona bem para gerenciar alguns dispositivos, e em sua coluna Mike tem sugestões de maneiras de enviar informações de configuração para vários dispositivos ao mesmo tempo. Mas e se você precisa provisão milhares de dispositivos de uma maneira sistemática durante um longo período de tempo? E se você precisa saber quais configurações de software e do Registro já estão definidas nos dispositivos você está tentando gerenciar?
Esse tipo de esforço de provisionamento grande e coordenado é o domínio de gerenciamento de dispositivos do OMA (DM do OMA). O protocolo de DM do OMA se baseia em um dialeto do XML chamado SyncML, e ele pode ser usado para configurar e gerenciar dispositivos em um cenário de empresa. Esta coluna aborda a estrutura de um documento de SyncML usado no protocolo DM do OMA. FALAREI sobre cenários de uso específicas para a plataforma Windows Mobile, incluindo a limpeza remotamente o dispositivo. Também demonstrarei como você pode definir um navegador Favoritos no dispositivo usando o XML da coluna de Mike em conjunto com DM do OMA.
O que É o OMA?
OMAum grupo de setor é composta de mais de 200 operadores móveis, fabricantes de dispositivos móveis e fornecedores de software (incluindo Microsoft). OMA foi formada em 2002 para criar um único grupo para gerenciar o número burgeoning de padrões de dispositivo móvel que foram exibidos no mercado, incluindo WAP, gerenciamento de dispositivos e SyncML. Essa multiplicidade de grupos estava criando duplicação de trabalho, para que os parceiros do setor preocupado tem juntos e colocado todas essas iniciativas importantes juntos em um grupo de único guarda-sol.
Padrões do OMA facilitar trabalhar com dispositivos móveis e redes, criando uma forma proprietários de se comunicar entre as tecnologias. SyncML e DM do OMA são dois aspectos dessa família de protocolos abertos. Como todos os protocolos, eles estão sujeitos a uma determinada quantidade de interpretação e cada fornecedor é livre para fornecer suas próprias extensões de valor agregados. Mas trabalhar com eles é mais fácil e mais simples de tentar negociar um formato proprietário, específicos do fornecedor.
SyncML: XML para sincronização
SyncML é uma marcação baseada em XML que é usada como base para a maioria dos protocolos definidos pelo OMA. Um documento SyncML é chamado de uma mensagem. A mensagem deve ser XML bem formado, mas não necessariamente um XML válido. Ou seja, ele deve ter correspondentes marcas de abertura e fechamento para todos os elementos, deve ter todos os atributos de aspas e estão em conformidade caso contrário, com a definição básica de bem-formação que são essencial para qualquer documento chamar próprio XML.
Embora não há uma definição de tipo de documento de SyncML (DTD), não é nenhum requisito de que o remetente ou destinatário validar contra ele. Um dos motivos para isso é que validação requer memória extra e tempo do processador e dispositivos móveis costumam ser curto nos dois desses recursos. A mensagem, por sua vez, contém elementos de comando que fazem o trabalho pesado de protocolos do OMA específicos.
SyncML e DM do OMA são independente de transporte. Há ligações de transporte definidas para HTTP e Object Exchange (OBEX), e seria possível para outras ligações seja definido. Isso torna SyncML e DM do OMA útil para dispositivos de provisionamento pelo ar. Usando SyncML e DM do OMA com um servidor de gerenciamento de dispositivo compatível com, você pode enviar configurações para um dispositivo sem usar um cartão de memória, sem tethering o dispositivo e sem pedir ao usuário final interação, como a visitar um site.
Uma ou mais mensagens está contido, conceitualmente, em um pacote SyncML. O pacote SyncML abrange todas as mensagens enviadas entre um remetente e um destinatário.
Elementos de SyncML
Um documento SyncML consiste em um elemento de SyncML raiz, um cabeçalho definido pelo elemento SyncHdr e um corpo definido pelo elemento SyncBody. A raiz de um documento SyncML sempre é um elemento SyncML, que tem esta aparência:
<SyncML xmlns='SYNCML:SYNCML1.1'>
...
</SyncML>
O elemento SyncML contém os elementos filho SyncHdr e SyncBody. Um elemento SyncHdr é semelhante a marcação na Figura 1 . Este cabeçalho curto informa tudo o que um receptor precisará saber para processar a mensagem.
A 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>
O elemento VerDTD indica se esta mensagem está de acordo com a versão 1.2 do protocolo de representação SyncML, conforme definido pela OMA. O elemento VerProto indica algo semelhante: que você está vendo uma mensagem que lida com a versão 1.2 do protocolo DM do OMA. Os números de versão são os mesmos, mas as duas coisas são diferentes. SyncML é usado para diferentes protocolos OMA, incluindo um protocolo de gerenciamento de dispositivo (que eu estou discutindo nesta coluna) e um protocolo de sincronização de dados (para o qual SyncML foi projetado originalmente).
O elemento de identificação de sessão indica qual sessão SyncML você está procurando. O valor dessa identificação pode ser, no máximo, 4 bytes.
O MsgID é uma identificação que é exclusiva dentro da sessão. Ele é usado para manter o controle da conversação entre remetente e destinatário. Quando o destinatário responde com os resultados, os resultados consulte a mensagem seja respondida pelo incluindo o MsgID em um elemento MsgRef.
O elemento de destino indica que o destinatário da mensagem deve ser. O elemento de origem indica que o remetente da mensagem deve ser. Esses elementos contém um elemento LocURI que contém a seqüência de caracteres com exclusividade identifica o remetente ou destinatário. O LocURI do destino e origem deve ser uma URL, um URI ou um URN. Como um servidor de gerenciamento será geralmente já tem um nome DNS exclusivo, é comum para ver o nome de domínio totalmente qualificado do servidor de gerenciamento no LocURI quando o remetente ou destinatário é um servidor de gerenciamento.
Observe que nem o destino o elemento de origem está diretamente relacionado endereçamento ou roteamento a mensagem. Essas tarefas são esquerdas para o aplicativo de gerenciamento de dispositivo e os protocolos de transporte de suporte.
Dispositivos móveis são freqüentemente chamados por um URN que se refere a um GUID, conforme definido pela RFC 4122 — que se refere exclusivamente a no dispositivo específico sendo resolvido. Ele é o aplicativo para mapear esta GUID novamente para um endereço que pode ser acessado pela rede. Como o GUID não é uma maneira intuitiva imediatamente para saber qual dispositivo específico você está falando, o aplicativo adicionou um elemento LocName ao elemento fonte, que contém o nome do dispositivo que originou a mensagem SyncML.
Finalmente, o elemento de credenciais contém informações que identificam a origem. Ele contém um par de elementos META que informe o destinatário que esta mensagem usa o esquema de autenticação MD5 que é definido no padrão SyncML e que o token de segurança é codificado base 64. O elemento de dados que é o irmão dos elementos META contém o símbolo de autenticação que pode ser usado pelo destinatário para confirmar a identidade do remetente.
O elemento SyncBody
Um elemento SyncBody é mostrado na Figura 2 . Observe que aqui, os elementos de destino apenas como em SyncHdr, são identificados por LocURI. Quase tudo no SyncML é identificado por LocURI. O LocURI é criado de acordo com a uma estrutura de árvore aninhada, semelhante da estrutura árvore aninhada de um documento XML, mas é um pouco menos caro processar de uma série de nós XML aninhados. A raiz da árvore conceitual é identificado pela ". " caractere, que sempre deve ser especificado.
A 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>
A árvore contém informações sobre o dispositivo móvel, incluindo detalhes, como a quantidade de memória possui ou executáveis que estão disponíveis para ser chamado pela DM do OMA. Quando um LocURI é usado para se referir a essa árvore de informações do dispositivo, ele deve ser sempre um URI completo. Ou seja, ele sempre deve ser especificado na raiz do dispositivo para a folha específica a serem abordados. URIs parcial ou relativas não são permitidas nesta parte da especificação DM do OMA.
Observe que me referir a isso como uma árvore "conceitual". Isso ocorre porque as especificações SyncML e DM do OMA não impor qualquer detalhe de implementação no dispositivo móvel ou no dispositivo gerenciamento de servidor para como essas informações, na verdade, são conduzidas a um armazenamento de backup. SyncML quer tratar os dados como se fosse uma árvore, mas você pode armazená-lo em um banco de dados relacional, no registro do dispositivo ou servidor, na memória volátil, em uma série de arquivos simples ou de alguma outra maneira. A especificação é completamente desconhecida para o mecanismo usado para manter fisicamente esse dados.
Sob o nó de raiz são três nós filho importante: DevInfo, DevDetail e fornecedores. O nó DevInfo contém informações sobre o fabricante do dispositivo, o idioma definido na interface do usuário do dispositivo e o identificador do dispositivo. O nó DevDetail contém outras informações de fornecedor independente sobre o dispositivo, incluindo a versão de hardware e o comprimento máximo do URI dispositivo dá suportado. Mais outros detalhes interessantes sobre o dispositivo são armazenados no nó do fornecedor. Pela especificação, implementadores devem estacionar suas extensões para o protocolo DM do OMA sob o nó de fornecedor, e isso é onde você passa a maior parte do seu tempo quando a configuração ou gerenciamento de dispositivos Windows Mobile.
Apagamento remoto
Exec o comando sempre informa o dispositivo para fazer algo, mas há um conjunto limitado de coisas que o dispositivo pode ser solicitado fazer DM do OMA. Uma outra coisa que pode ser disparada em um dispositivo Windows Mobile por DM do OMA é um apagamento remoto. Isso é semelhante ao recurso de apagamento oferecido para clientes do Windows Mobile pelo Exchange e é realmente útil se um dispositivo sob seu controle tiver sido perdido ou roubado. O comando para limpar um dispositivo com DM do OMA tem esta aparência:
<Exec>
<CmdID>3</CmdID>
<Item>
<Target><LocURI>./Vendor/MSFT/RemoteWipe/doWipe</LocURI></Target>
</Item>
</Exec>
É possível limpar um dispositivo com o OMA-CP, muito. Portanto, você pode, se você realmente quiser, criar um arquivo CAB com provisionamento XML dentro dele e distribui-lo para o dispositivo por meio de download de DM do OMA. Conteúdo do arquivo CAB, em seguida, poderia obter roteado para o mesmo CSP RemoteWipe que poderia ser invocada por DM do OMA, e os resultados devem ser o mesmo.
O elemento de SyncBody mostrado anteriormente contém um elemento de adicionar. O elemento Add informa o receptor para adicionar um nó ou série de nós à árvore de informações de dispositivo. A implementação da Microsoft de DM do OMA suporta algo chamado implícito adicionar, que significa que se um comando Add se refere a um LocURI conosco que não estão presentes no dispositivo, todos os nós da raiz para a folha são inseridos na árvore de informações de dispositivo. Sem essa extensão, nós teria que ser adicionada à árvore de dispositivo um por vez, que pode consumir rapidamente largura de banda, tempo de processador, e — finalmente — Paciência do usuário.
Este comando Adicionar está adicionando algo para o nó download para gerenciamento de software no dispositivo tendo o content.contoso.com/download/SetBrowserFavorite.cab URL. Finalmente, esta URL será roteada para um provedor de serviço de configuração no dispositivo — chamado coincidentally o CSP de download — que irá tentar extrair o conteúdo especificado por esta URL.
O comando Add é seguido por um comando Exec. O comando Exec informa o dispositivo para ir a fazer algo. Nesse caso, ele é informando o dispositivo para baixar e instalar o pacote com o SetBrowserFavorite.cab de identificação.
O comando Exec é seguido por um elemento final, que informa o destinatário que essa é a última mensagem SyncML que deverão ser esperada para esta sessão. Sem o elemento final, o receptor espera que deve haver SyncML mais mensagens a seguir.
Se você pode instalar um arquivo CAB para o dispositivo copiando-o para o dispositivo via ActiveSync, você geralmente pode instalar esse arquivo CAB para o dispositivo usando DM do OMA. O arquivo CAB deve ser assinado com um certificado que o dispositivo confie. Se o arquivo não está assinado com um certificado válido, a instalação do arquivo CAB falhará. Isso é diferente do comportamento que você verá quando instalando um arquivo CAB não assinado através do ActiveSync. Quando você instala um arquivo não assinado pela ActiveSync o dispositivo pode solicitar confirmação de sua intenção para instalar o CAB não assinado, supondo que a diretiva no dispositivo é definida para permitir isso.
O protocolo de DM do OMA em um dispositivo Windows Mobile não solicita a você. Ele apenas falha, notifica sobre a falha com uma mensagem contendo um código de erro no miniaplicativo programas gerenciados e envia um código de erro relacionadas de volta ao servidor dispositivo gerenciamento. Esse design faz sentido pois ActiveSync é que está sendo iniciado por você ou Esperamos que alguém você confia, enquanto o dispositivo está fisicamente em suas mãos. DM do OMA é iniciado por um agente remoto, no momento está completamente fora do seu controle.
Primeiro, o CSP download busca o conteúdo da URL especificada. Em seguida, ele examina o arquivo CAB e falhará se ele não está assinado. Se o arquivo CAB é assinado, o CSP download descompacta o arquivo CAB e circula o conteúdo do arquivo corretamente. Se o CAB contiver software, o software é instalado para o dispositivo. Se o CAB contém OMA-CP provisionamento XML — como o arquivo CAB Mike criado na sua coluna — e o XML de provisionamento é aplicado ao dispositivo. Se o arquivo CAB contiver conteúdo simples, como um filme ou uma tela de base, em seguida, esse conteúdo será armazenado no sistema de arquivos do dispositivo.
O miniaplicativo programas gerenciado registra cada tentativa, bem-sucedida ou falha, para instalar um arquivo CAB para o dispositivo por meio de DM do OMA. Depois de concluir a instalação, o dispositivo envia um código definido pela OMA-DM padrão para o servidor de gerenciamento em uma nova sessão DM do OMA.
Mas, espere! Há mais!
Os dispositivos Windows Mobile respondem a um subconjunto dos elementos de comando especificados na SyncML. A seguir é alguns elementos de comando que ainda não discuti ainda.
O comando alerta permite que o remetente notificar o destinatário. Por exemplo, um alerta de um servidor de gerenciamento para um dispositivo pode informar o dispositivo para acordar e inicie uma sessão. Ou um alerta pode conter informações que devem ser exibidas ao usuário final por meio da interface do usuário.
O elemento atômico é usado para agrupar os outros comandos que devem todas bem-sucedida ou falhar como uma unidade. Isso é importante quando um grupo de comandos está relacionado e êxito parcial deve deixar o dispositivo em um estado indesejado ou desconhecido. A menos que agrupados em um elemento atômico, três comandos distintos de adicionar seriam bem-sucedida ou falhar independentes umas das outras e gerar três mensagens de resposta separado para o servidor de gerenciamento.
Excluir é o oposto de adicionar. O comando Excluir remove um nó na árvore de dispositivo. Se o nó tiver nós filho, aqueles são removidas, muito. Alguns nós, como o nó DevInfo interno e seus filhos, não podem ser removidos, e tentar removê-los gera um código de erro. O comando replace substitui um nó determinado na árvore de dispositivo.
O comando de Get é usado para consultar a árvore de dispositivo para obter informações e retorna essa informação em uma mensagem SyncML ao remetente. Por exemplo, para obter a quantidade de armazenamento disponível no momento no dispositivo, o seguinte comando Get seria enviado:
<Get>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/DeviceInformation/TotalStorage</LocURI>
</Target>
</Item>
</Get>
O comando de resultado enviado em resposta a um Get, que contém o valor do nó no obter solicitado.
O elemento de seqüência é usado para agrupar nós em uma ordem específica.Se você pretende possuem comandos processados um após o outro, você deve agrupá-los em um elemento de seqüência.Caso contrário, a ordem da execução não é garantida.
E por fim, o elemento de status contém o código de sucesso ou fracasso retornado por uma determinada operação.Um status de 200 geralmente indica êxito.
Colocar SyncML para trabalhar
SyncML começou como um protocolo não para gerenciamento de dispositivos, mas para sincronização de dispositivos.Implementações do protocolo sincronização OMA com base em SyncML são usadas com freqüência para permitir que dispositivos sincronizar o calendário e informações de contato.A especificação do protocolo base SyncML aborda os requisitos para sincronização bem como requisitos de gerenciamento.Isso significa que o protocolo de representação SyncML base contém elementos que nunca são usados no DM do OMA e outros elementos que nunca são usados na sincronização.
Pela primeira vez leitores da especificação SyncML podem descobrir se um pouco confuso, porque a especificação está tentando resolver dois domínios com problemas divergentes.Embora não haja alguma sobreposição entre a sincronização e gerenciamento, duas coisas, sem dúvida, não são iguais.É útil isolar os elementos de SyncML que são usados no gerenciamento conceitualmente por aqueles que são usados em sincronização ao revisar a especificação de representação de protocolo.
Você precisará ter um servidor de gerenciamento para configurar os dispositivos via DM do OMA.Existem várias ofertas comerciais disponíveis, incluindo o Microsoft System Center Gerenciador de dispositivo móvel 2008.E há noncommercial SyncML bibliotecas e implementações disponível também.A quantidade de flexibilidade permitida para fornecedores e implementadores significa que tornando dispositivos e servidores falar usando DM do OMA não é sempre tão simples como um seria conveniente.Mas as dificuldades apresentadas pelo integração de diferentes dispositivos que usam padrões OMA é preferível imensamente a dificuldade de fazer dispositivos interoperar usando o hodgepodge dos métodos de comunicação não relacionada e proprietários que dominado mercado móvel antes do aparecimento das OMA.
Envie suas dúvidas e comentários paragoplaces@Microsoft.com.
Ramon Arjona é uma líder de teste sênior trabalhando em equipe do Windows Mobile na Microsoft.