Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Visão geral das convenções de protocolo de gerenciamento XML e Junos XML

Um aplicativo de cliente deve cumprir as convenções de protocolo de gerenciamento XML e Junos XML. Cada solicitação do aplicativo do cliente deve ser um documento XML bem formado ; ou seja, ele deve obedecer às regras estruturais definidas no protocolo Junos XML e às definições do tipo de documento Junos XML (DTDs) 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 em contextos legais. Aplicativos em conformidade são mais fáceis de manter no caso de alterações no junos OS ou protocolo Junos XML.

Da mesma forma, cada resposta do servidor de protocolo Junos XML constitui um documento XML bem formado (o servidor de protocolo Junos XML obedece às convenções de protocolo de gerenciamento XML e Junos XML).

As seções a seguir descrevem as convenções de protocolo de gerenciamento Do Junos 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 o envio de solicitações ao servidor de protocolo Junos XML.

Um elemento de tag de resposta representa a resposta do servidor de protocolo Junos XML 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 a resposta do servidor de protocolo Junos XML.

O exemplo a seguir representa uma troca na qual um aplicativo do cliente emite a <get-interface-information> tag de solicitação com a <extensive/> bandeira e o servidor de protocolo Junos XML devolve o <interface-information> elemento de resposta.

Request and Response Tag Elements
Nota:

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 de protocolo Junos XML. 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 a resposta do servidor de protocolo Junos XML. Para obter informações sobre o xmlns atributo na tag de abertura <interface-information> , consulte Solicitando informações operacionais usando o protocolo Junos XML.

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

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 de protocolo Junos XML 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 de protocolo Junos XML 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 de protocolo Junos XML, 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 de protocolo Junos XML ignora o espaço branco (espaços, guias, caracteres de linha nova 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 incluem espaço branco no conteúdo de um elemento de tag que eles estão enviando como uma mudança na configuração do candidato, o servidor de protocolo Junos XML preserva o espaço branco no banco de dados de configuração.

Em suas respostas, o servidor de protocolo Junos XML 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 novos 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 de protocolo Junos XML podem inserir comentários XML a 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 tratar comentários na saída do servidor de protocolo Junos XML 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 de protocolo Junos XML, porque o servidor descarta automaticamente quaisquer comentários que recebe.

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:

Instruções de processamento XML

Uma instrução de processamento XML (PI) contém informações relevantes para um protocolo específico e tem o seguinte formulário:

Algumas PIs emitidas durante uma sessão de protocolo Junos XML incluem informações que um aplicativo do cliente precisa para a operação correta. Um exemplo proeminente é o <?xml?> elemento, que o aplicativo do cliente e o servidor de protocolo Junos XML emitem cada um no início de cada sessão de protocolo Junos XML para especificar qual versão do XML e qual esquema de codificação de caracteres eles estão usando. Para obter mais informações, consulte as sessões de protocolo Do Junos XML.

O servidor de protocolo Junos XML também pode emitir PIs que o aplicativo do cliente não precisa interpretar (por exemplo, PIs destinadas à CLI). Se o aplicativo do cliente não entender um PI, ele deve tratar o PI como um comentário em vez de sair ou gerar uma mensagem de erro.

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 de protocolo Junos XML usa as mesmas referências predefinidas de 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.

Tabela 1: Substituições de referência de entidade predefinidas por valores de conteúdo de tag

Caráter desautorizado

Referência de entidade predefinida

& (ampersand)

&amp;

> (maior que o sinal)

&gt;

< (menos que assinar)

&lt;

A Tabela 2 resume o mapeamento entre caracteres desautorizados e referências predefinidas de entidades para valores de atributos.

Tabela 2: Substituições de referência predefinidas para entidades por valores de atributos

Caráter desautorizado

Referência de entidade predefinida

& (ampersand)

&amp;

' (apóstrofo)

&apos;

> > (maior que o sinal)

&gt;

< (menos que assinar)

&lt;

" (cotação)

&quot;

Como exemplo, suponha que a sequência a seguir seja o valor contido pelo <condition> elemento:

O <condition> elemento se parece com isso (aparece em duas linhas apenas para legibilidade ):

Da mesma forma, se o valor <example> do atributo do heading elemento for Peer’s "age" <> 40, a tag de abertura se parece com isso: