Descripción general de las convenciones del protocolo de administración XML XML y NETCONF
Una aplicación cliente debe cumplir con convenciones de protocolo de administración XML y NETCONF XML. Cada solicitud de la aplicación cliente debe ser un documento XML bien formado; es decir, debe cumplir las reglas estructuradas definidas en las definiciones de tipo de documento (DTD) NETCONF y Junos XML para el tipo de información codificada en la solicitud. La aplicación cliente debe emitir elementos de etiqueta en el orden necesario y solo en los contextos legales. Las aplicaciones que cumplen son más fáciles de mantener en caso de cambios en el Junos OS protocolo NETCONF.
De manera similar, cada respuesta del servidor NETCONF constituye un documento XML bien formado (el servidor NETCONF no acepta convenciones XML y NETCONF).
En las siguientes secciones se describen las convenciones del protocolo de administración XML NETCONF:
Elementos de etiqueta de solicitud y respuesta
Un elemento de etiqueta de solicitud es uno generado por una aplicación cliente para solicitar información sobre el estado o configuración actuales de un dispositivo, o para cambiar la configuración. Un elemento de etiqueta de solicitud corresponde a un CLI operativo o de configuración. Solo puede producirse dentro de una <rpc> etiqueta. Para obtener más información sobre <rpc> el elemento, consulte Enviar solicitudes al servidor NETCONF.
Un elemento de etiqueta de respuesta representa la respuesta del servidor NETCONF a un elemento de etiqueta de solicitud y solo se produce dentro de una <rpc-reply> etiqueta. Para obtener más información sobre <rpc-reply> el elemento, consulte Analizar la respuesta del servidor NETCONF.
El ejemplo siguiente representa un intercambio en el que una aplicación cliente emite el elemento de etiqueta de solicitud con el indicador y el servidor NETCONF devuelve <get-interface-information> el elemento de etiqueta de <extensive/> <interface-information> respuesta.
Aplicación 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>
]]>]]>
En este ejemplo, al igual que todos los demás de esta guía, se muestra cada elemento de etiqueta en una línea independiente, en las secuencias de etiquetas emitidas tanto por la aplicación cliente como por el servidor NETCONF. En la práctica, una aplicación cliente no necesita incluir caracteres de línea nueva entre elementos de etiqueta, ya que el servidor descarta automáticamente dicho espacio en blanco. Para obtener más información, consulte Espacios, Caracteres de línea nueva y otros espacios en blanco.
Para obtener información acerca de los atributos en la etiqueta <rpc-reply> de apertura, consulte Analizar la respuesta del servidor NETCONF. Para obtener más información sobre xmlns el atributo en la etiqueta de <interface-information> apertura, consulte Solicitar información operativa mediante NETCONF. Para obtener más información acerca ]]>]]> de la secuencia de caracteres, consulte Generar documentos XML bien formados.
Elementos de etiqueta secundaria de un elemento de etiqueta de solicitud
Algunos elementos de etiqueta de solicitud contienen elementos de etiquetas secundarias. Para solicitudes de configuración, cada elemento de etiqueta secundaria representa un elemento de configuración (nivel de jerarquía u objeto de configuración). Para solicitudes operativas, cada elemento de etiqueta secundaria representa una de las opciones que proporciona en la línea de comandos al emitir el comando CLI equivalente.
Algunas solicitudes tienen elementos obligatorios de etiqueta secundaria. Para realizar una solicitud de forma correcta, una aplicación cliente debe emitir los elementos de etiqueta obligatorios dentro de las etiquetas de apertura y cierre del elemento de etiqueta de solicitud. Si alguno de los elementos secundarios son ellos mismos elementos de etiqueta de contenedor, la etiqueta de apertura de cada uno debe producirse antes de cualquiera de los elementos de etiqueta que contiene, y la etiqueta de cierre debe producirse antes de la etiqueta de apertura para otro elemento de etiqueta en su nivel jerárquicos.
En la mayoría de los casos, la aplicación cliente puede emitir elementos secundarios que se producen en el mismo nivel dentro de un elemento de etiqueta de contenedor en cualquier orden. La excepción importante es un elemento de configuración que tiene un elemento de etiqueta de identificador,el cual distingue el elemento de configuración de otros elementos de su tipo. El elemento de etiqueta de identificador debe ser el primer elemento de etiqueta secundaria en el elemento de etiqueta de contenedor. Con mayor frecuencia, el elemento de etiqueta de identificador especifica el nombre del elemento de configuración y se denomina <name> . Para obtener más información, consulte Asignación para objetos que tienen un identificador.
Elementos de etiqueta secundaria de un elemento de etiqueta de respuesta
Los elementos de etiqueta secundaria de un elemento de etiqueta de respuesta representan los elementos de datos individuales que devuelve el servidor NETCONF para una solicitud determinada. Los elementos secundarios pueden ser elementos de etiqueta individual (etiquetas vacías o elementos de etiqueta triples) o elementos de etiqueta de contenedor que encierran sus propios elementos de etiqueta secundaria. Para algunos elementos de etiqueta de contenedor, el servidor NETCONF devuelve los elementos secundarios por orden alfabético. Para otros elementos, los niños aparecen en el orden en el que se crearon en la configuración.
El conjunto de elementos de etiqueta secundaria que pueden producirse en una respuesta o dentro de un elemento de etiqueta de contenedor está sujeto a cambios en versiones posteriores de la API XML de Junos. Las aplicaciones cliente no deben confiar en la presencia o ausencia de un elemento de etiqueta determinado en la salida del servidor NETCONF, ni en el orden de los elementos de etiqueta secundaria dentro de un elemento de etiqueta de respuesta. Para la operación más sólida, incluya lógica en la aplicación cliente que controla la ausencia de elementos de etiqueta esperados o la presencia de inesperadas con la mayor elegancia posible.
Espacios, caracteres de línea nueva y otros espacios en blanco
Según lo dictado por la especificación XML, el servidor NETCONF pasa por alto los espacios en blanco (espacios, pestañas, caracteres de línea nueva y otros caracteres que representan un espacio en blanco) que se produce entre los elementos de etiqueta en la secuencia de etiquetas generado por una aplicación cliente. Las aplicaciones del cliente pueden incluir, aunque no es necesario, espacios en blanco entre elementos de etiqueta. Sin embargo, no deben insertar un espacio en blanco dentro de una etiqueta de apertura o cierre. Si incluyen un espacio en blanco en el contenido de un elemento de etiqueta que envían como un cambio a la configuración candidata, el servidor NETCONF conserva el espacio en blanco en la base de datos de configuración.
En sus respuestas, el servidor NETCONF incluye un espacio en blanco entre los elementos de etiqueta para mejorar la legibilidad de las respuestas que se guardan en un archivo: utiliza caracteres de línea nueva para colocar cada elemento de etiqueta en su propia línea, y espacios para sangrar elementos de etiquetas secundarias a la derecha en comparación con los padres. Una aplicación cliente puede ignorar o descartar el espacio en blanco, particularmente si no almacena respuestas para su revisión posterior por parte de usuarios humanos. Sin embargo, no debe depender de la presencia o ausencia de espacios en blanco en ninguna ubicación en particular al analizar la secuencia de etiquetas.
Para obtener más información acerca del espacio en blanco en documentos XML, consulte la especificación XML del World Wide Web Consortium (W3C), Extensible Markup Language (XML) 1.0, a la http://www.w3.org/TR/REC-xml/ .
Comentarios XML
Las aplicaciones cliente y el servidor NETCONF pueden insertar comentarios XML en cualquier punto entre los elementos de etiqueta en la secuencia de etiquetas que generan, pero no dentro de los elementos de etiqueta. Las aplicaciones cliente deben manejar correctamente los comentarios en los resultados del servidor NETCONF, pero no deben depender de su contenido. Las aplicaciones cliente tampoco pueden usar comentarios para transmitir información al servidor NETCONF, ya que el servidor descarta automáticamente los comentarios que recibe.
Los comentarios XML se adjuntan dentro de las cadenas y , y no pueden contener la cadena <!-- --> -- (dos guiones). Para obtener más información acerca de los comentarios, consulte la especificación XML en http://www.w3.org/TR/REC-xml/ .
El siguiente es un ejemplo de un comentario XML:
<!-- This is a comment. Please ignore it. -->
Referencias de entidad predefinidas
Por convención XML, hay dos contextos en los que ciertos caracteres no pueden aparecer en su forma regular:
En la cadena que aparece entre las etiquetas de apertura y cierre (el contenido del elemento de etiqueta)
En el valor de cadena asignado a un atributo de una etiqueta de apertura
Cuando se incluye un carácter no permitido en cualquiera de los contextos, las aplicaciones de cliente deben sustituir la referencia de entidad predefinida equivalente,que es una cadena de caracteres que representa el carácter no permitido. Dado que el servidor NETCONF utiliza las mismas referencias de entidad predefinidas en sus elementos de etiqueta de respuesta, la aplicación cliente debe poder convertirlas en caracteres reales al procesar elementos de etiqueta de respuesta.
En la tabla 1 se resume la asignación entre caracteres no permitidos y referencias de entidad predefinidas para las cadenas que aparecen entre las etiquetas de apertura y cierre de un elemento de etiqueta.
Carácter desaconsanzado |
Referencia de entidad predefinida |
|---|---|
& (ampersand) |
& |
> (mayor que el signo) |
> |
< (menos que signo) |
< |
En la tabla 2 se resume la asignación entre caracteres no permitidos y referencias de entidad predefinidas para los valores de atributo.
Carácter desaconsanzado |
Referencia de entidad predefinida |
|---|---|
& (ampersand) |
& |
' (apóstrofo) |
' |
> (mayor que el signo) |
> |
< (menos que signo) |
< |
" (comillas) |
"" |
Como ejemplo, suponga que la siguiente cadena es el valor contenido por el <condition> elemento tag:
if (a<b && b>c) return "Peer’s not responding"
El <condition> elemento de etiqueta se parece a este (aparece en dos líneas solo para la legibilidad):
<condition>if (a<b && b>c) return "Peer’s not \
responding"</condition>
De forma similar, si el valor del atributo del elemento de etiqueta es, la <example> etiqueta de apertura tiene el siguiente heading Peer’s "age" <> 40 aspecto:
<example heading="Peer's "age" <> 40">