Visão geral das convenções de protocolo de gerenciamento XML e NETCONF XML
Um aplicativo de cliente deve cumprir as convenções de protocolo de gerenciamento XML e NETCONF XML. Cada solicitação do aplicativo do cliente deve ser um documento XML bem formado ; ou seja, ele deve obedecer às regras estruturais definidas nas definições do tipo de documento NETCONF e Junos XML (DTD) para o tipo de informação codificada na solicitação. O aplicativo do cliente deve emitir elementos de tag na ordem necessária e apenas nos contextos legais. Aplicativos em conformidade são mais fáceis de manter no caso de mudanças no junos OS ou protocolo NETCONF.
Da mesma forma, cada resposta do servidor NETCONF constitui um documento XML bem formado (o servidor NETCONF obedece às convenções XML e NETCONF).
As seções a seguir descrevem as convenções de protocolo de gerenciamento NETCONF XML:
Elementos de tag de solicitação e resposta
Um elemento de tag de solicitação é um gerado por um aplicativo do cliente para solicitar informações sobre o status ou configuração atual de um dispositivo, ou alterar a configuração. Um elemento de tag de solicitação corresponde a um comando operacional ou de configuração da CLI. Ela só pode ocorrer dentro de uma <rpc>
tag. Para obter informações sobre o <rpc>
elemento, consulte Enviar solicitações ao servidor NETCONF.
Um elemento de tag de resposta representa a resposta do servidor NETCONF a um elemento de tag de solicitação e ocorre apenas dentro de uma <rpc-reply>
tag. Para obter informações sobre o <rpc-reply>
elemento, consulte Parse a resposta do servidor NETCONF.
O exemplo a seguir representa uma troca na qual um aplicativo do cliente emite o <get-interface-information>
elemento de tag de solicitação com a <extensive/>
bandeira e o servidor NETCONF devolve o <interface-information>
elemento de tag de resposta.
Aplicativo do cliente
<rpc> <get-interface-information> <extensive/> </get-interface-information> </rpc> ]]>]]>
Servidor NETCONF
<rpc-reply xmlns="URN" xmlns:junos="URL"> <interface-information xmlns="URL"> <!-- children of <interface-information> --> </interface-information> </rpc-reply> ]]>]]>
Este exemplo, como todos os outros neste guia, mostra cada elemento de tag em uma linha separada, nos fluxos de tag emitidos tanto pelo aplicativo do cliente quanto pelo servidor NETCONF. Na prática, um aplicativo do cliente não precisa incluir caracteres de linha novos entre elementos de tag, porque o servidor descarta automaticamente esse espaço branco. Para mais discussões, consulte Spaces, Newline Characters e Other White Space.
Para obter informações sobre os atributos na tag de abertura <rpc-reply>
, consulte o Parse the NETCONF Server Response. Para obter informações sobre o xmlns
atributo na tag de abertura <interface-information>
, consulte Solicitar informações operacionais usando o NETCONF. Para obter informações sobre a sequência do ]]>]]>
personagem, consulte Gere documentos XML bem formados.
Elementos de tag infantil de um elemento de tag de solicitação
Alguns elementos de tag de solicitação contêm elementos de tag infantil. Para solicitações de configuração, cada elemento de tag infantil representa um elemento de configuração (nível de hierarquia ou objeto de configuração). Para solicitações operacionais, cada elemento de tag infantil representa uma das opções que você fornece na linha de comando ao emitir o comando CLI equivalente.
Algumas solicitações têm elementos de tag infantil obrigatórios. Para fazer uma solicitação com sucesso, uma aplicação do cliente deve emitir os elementos de tag obrigatórios dentro das tags de abertura e fechamento do elemento de tag de solicitação. Se alguma das crianças for ela mesma elementos de tag de contêiner, a tag de abertura de cada um deve ocorrer antes de qualquer um dos elementos de tag que contém, e a tag de fechamento deve ocorrer antes da tag de abertura para outro elemento de tag em seu nível de hierarquia.
Na maioria dos casos, o aplicativo do cliente pode emitir crianças que ocorrem no mesmo nível dentro de um elemento de tag de contêiner em qualquer ordem. A exceção importante é um elemento de configuração que tem um elemento de tag identificador, que distingue o elemento de configuração de outros elementos do seu tipo. O elemento de tag do identificador deve ser o primeiro elemento de tag infantil no elemento de tag de contêiner. Com mais freqüência, o elemento de tag do identificador especifica o nome do elemento de configuração e é chamado <name>
. Para obter mais informações, consulte mapeamento para objetos que tenham um identificador.
Elementos de tag infantil de um elemento de tag de resposta
Os elementos de tag infantil de um elemento de tag de resposta representam os itens de dados individuais devolvidos pelo servidor NETCONF para uma solicitação específica. As crianças podem ser elementos de tag individuais (etiquetas vazias ou tríplices do elemento tag) ou elementos de tag de contêiner que incluem seus próprios elementos de tag infantil. Para alguns elementos de tag de contêiner, o servidor NETCONF devolve as crianças em ordem alfabética. Para outros elementos, as crianças aparecem na ordem em que foram criadas na configuração.
O conjunto de elementos de tag infantil que podem ocorrer em uma resposta ou dentro de um elemento de tag de contêiner está sujeito a alterações em versões posteriores da API Junos XML. Os aplicativos do cliente não devem depender da presença ou ausência de um elemento de tag específico na saída do servidor NETCONF, nem no pedido de elementos de tag infantil dentro de um elemento de tag de resposta. Para a operação mais robusta, inclua a lógica no aplicativo do cliente que lida com a ausência de elementos de tag esperados ou a presença de elementos inesperados da forma mais graciosa possível.
Espaços, personagens newline e outros espaços brancos
Conforme ditado pela especificação XML, o servidor NETCONF ignora o espaço branco (espaços, guias, caracteres newline e outros caracteres que representam espaço branco) que ocorre entre elementos de tag no fluxo de tag gerado por um aplicativo do cliente. Os aplicativos do cliente podem, mas não precisam, incluir espaço branco entre elementos de tag. No entanto, eles não devem inserir espaço branco dentro de uma tag de abertura ou fechamento. Se eles incluirem espaço branco no conteúdo de um elemento de tag que estão enviando como uma mudança na configuração do candidato, o servidor NETCONF preserva o espaço branco no banco de dados de configuração.
Em suas respostas, o servidor NETCONF inclui espaço branco entre elementos de tag para melhorar a capacidade de leitura das respostas que são salvas em um arquivo: ele usa caracteres de linha novas para colocar cada elemento de tag em sua própria linha, e espaços para elementos de tag infantil à direita em comparação com seus pais. Um aplicativo do cliente pode ignorar ou descartar o espaço branco, especialmente se ele não armazenar respostas para revisão posterior por usuários humanos. No entanto, ele não deve depender da presença ou ausência de espaço branco em qualquer local específico ao analisar o fluxo de tags.
Para obter mais informações sobre o espaço branco nos documentos do XML, consulte a especificação XML do World Wide Web Consortium (W3C), Extensible Markup Language (XML) 1.0, em http://www.w3.org/TR/REC-xml/ .
Comentários da XML
Os aplicativos do cliente e o servidor NETCONF podem inserir comentários XML em qualquer ponto entre elementos de tag no fluxo de tags que geram, mas não dentro de elementos de tag. Os aplicativos do cliente devem lidar com comentários na saída do servidor NETCONF de maneira graciosa, mas não devem depender de seu conteúdo. Os aplicativos do cliente também não podem usar comentários para transmitir informações ao servidor NETCONF, porque o servidor descarta automaticamente quaisquer comentários recebidos.
Os comentários do XML estão fechados <!--
dentro das cordas e -->
não podem conter a corda --
(dois hífens). Para obter mais detalhes sobre comentários, consulte a especificação do XML em http://www.w3.org/TR/REC-xml/ .
A seguir, um exemplo de um comentário da XML:
<!-- This is a comment. Please ignore it. -->
Referências de entidades predefinidas
Por convenção XML, existem dois contextos em que determinados caracteres não podem aparecer em sua forma regular:
Na corda que aparece entre tags de abertura e fechamento (o conteúdo do elemento tag)
No valor de string atribuído a um atributo de uma tag de abertura
Ao incluir um personagem desautorizado em ambos os contextos, os aplicativos do cliente devem substituir a referência de entidade predefinida equivalente, que é uma série de caracteres que representa o caráter desautorizado. Como o servidor NETCONF usa as mesmas referências predefinidas da entidade em seus elementos de tag de resposta, o aplicativo do cliente deve ser capaz de convertê-los em caracteres reais ao processar elementos de tag de resposta.
A Tabela 1 resume o mapeamento entre caracteres desautorizados e referências predefinidas de entidade para strings que aparecem entre as tags de abertura e fechamento de um elemento de tag.
Caráter desautorizado |
Referência de entidade predefinida |
---|---|
e (ampersand) |
e |
> (maior que o sinal) |
> |
< (menos que assinar) |
< |
A Tabela 2 resume o mapeamento entre caracteres desautorizados e referências predefinidas de entidades para valores de atributos.
Caráter desautorizado |
Referência de entidade predefinida |
---|---|
e (ampersand) |
e |
' (apóstrofo) |
e apos; |
> (maior que o sinal) |
> |
< (menos que assinar) |
< |
" (cotação) |
e cotar; |
Como exemplo, suponha que a sequência a seguir seja o valor contido pelo <condition>
elemento tag:
if (a<b && b>c) return "Peer’s not responding"
O <condition>
elemento de tag se parece com isso (ele aparece em duas linhas apenas para legibilidade):
<condition>if (a<b && b>c) return "Peer’s not \ responding"</condition>
Da mesma forma, se o valor do <example>
atributo do heading
elemento tag for Peer’s "age" <> 40
, a tag de abertura se parece com isso:
<example heading="Peer's "age" <> 40">