Vantagens de usar o protocolo de gerenciamento NETCONF XML e a API Junos XML
O protocolo de gerenciamento NETCONF XML e a API Junos XML documentam totalmente todas as opções para cada solicitação operacional Junos OS suportada e todos os elementos em todas as declarações de configuração do Junos OS. Os nomes de tag indicam claramente a função de um elemento em uma declaração de solicitação ou configuração operacional.
A combinação de nomes de tags significativos e as regras estruturais em um DTD torna mais fácil entender o conteúdo e a estrutura de um conjunto de dados ou documento marcado por XML. Os elementos de tag NETCONF e Junos XML tornam mais simples para os aplicativos do cliente que solicitam informações de um dispositivo para analisar a saída e encontrar informações específicas.
Saída de dispositivo de análise
O exemplo a seguir ilustra como a API Junos XML facilita analisar a saída do dispositivo e extrair as informações necessárias. Ele compara versões de saída formatadas de ASCII e XML de um dispositivo que executa o Junos OS. O ASCII formatado segue:
Physical interface: fxp0, Enabled, Physical link is Up Interface index: 4, SNMP ifIndex: 3
A versão XML marcada correspondente é:
<interface> <name>fxp0</name> <admin-status>enabled</admin-status> <operational-status>up</operational-status> <index>4</index> <snmp-index>3</snmp-index> </interface>
Quando um aplicativo do cliente precisa extrair um valor específico da saída ASCII formatada, ele deve depender da localização do valor, expressa de forma absoluta ou em relação a rótulos ou valores em campos adjacentes. Suponha que o aplicativo do cliente queira extrair o índice de interface. Ele pode usar um utilitário de correspondência de expressão regular para localizar strings específicos, mas uma dificuldade é que o número de dígitos no índice de interface não é necessariamente previsível. O aplicativo do cliente não pode simplesmente ler um determinado número de caracteres após o Interface index:
rótulo, mas deve, em vez disso, extrair tudo entre o rótulo e o rótulo subsequente, que é
, SNMP ifIndex
Um problema surge se o formato ou pedido de saída mudar em uma versão posterior do Junos OS, por exemplo, se um Logical index
campo for adicionado seguindo o número do índice de interface:
Physical interface: fxp0, Enabled, Physical link is Up Interface index: 4, Logical index: 12, SNMP ifIndex: 3
Um aplicativo que extrai o número do índice de interface delimitado pelos Interface index:
rótulos SNMP ifIndex
agora obtém um resultado incorreto. O aplicativo deve ser atualizado manualmente para procurar o seguinte rótulo:
, Logical index
Por outro lado, a natureza estruturada da saída marcada por XML permite que um aplicativo do cliente recupere o índice de interface extraindo tudo dentro da tag de abertura <index>
e marca de fechamento </index>
. O aplicativo não precisa depender da posição de um elemento na cadeia de saída, de modo que o servidor NETCONF possa emitir os elementos de tag infantil em qualquer ordem dentro do <interface>
elemento de tag. Adicionar um novo <logical-index>
elemento de tag em uma versão futura não afeta a capacidade de um aplicativo de localizar o <index>
elemento tag e extrair seu conteúdo.
Exibição da saída do dispositivo
A saída marcada por XML também é mais fácil de transformar em diferentes formatos de display. Por exemplo, você pode querer exibir diferentes quantidades de detalhes sobre um determinado componente do dispositivo em momentos diferentes. Quando um dispositivo retorna a saída ASCII formatada, você precisa projetar e escrever rotinas especiais e estruturas de dados em seu programa de exibição para extrair e armazenar as informações necessárias para um determinado nível de detalhes. Em contraste, a estrutura inerente da saída XML é uma base ideal para as próprias estruturas de um programa de exibição. Também é fácil usar a mesma rotina de extração para vários níveis de detalhes, simplesmente ignorando os elementos de tag que você não precisa ao criar um display menos detalhado.