La respuesta corta es: Ambos protocolos se pueden utilizar para hacer llamadas a procedimiento remoto (RPC). Ambos protocolos requieren un esquema de nivel de aplicación para ser definido, y en términos generales, ninguno de los protocolos requiere ningún esquema adicional para definir cómo serializar los objetos de nivel de lenguaje (ver más abajo algunos detalles).
Sin embargo, XmlRpc goza de una mayor compatibilidad de las bibliotecas que utilizan características de meta-programación (reflexión) del lenguaje para asignar llamadas XmlRpc, directamente (bueno, nunca 100% directamente) a llamadas a funciones de nivel de lenguaje. La razón por la cual hay mejor soporte para XmlRpc que XML simple es (a) un accidente histórico/resultado de marketing por parte de los proponentes de XmlRpc, o (b) la suma de los problemas menores de traducción enumerados a continuación inclinan la balanza a favor de XmlRpc.
Por otro lado, XmlRpc adolece de dos desventajas principales: (1) requiere aproximadamente 4 veces más ancho de banda, y (2) subvierte la intención de las herramientas de validación de esquemas XML: cada paquete simplemente se marcará como "sí, esto es XmlRpc válido", independientemente de los errores de ortografía y las omisiones en los campos de nivel de aplicación.
La respuesta larga:
Contrariamente a la creencia popular, no es necesario un estándar para definir cómo codificar objetos de nivel de idioma en XML sin formato - en general hay sólo una manera de "sensible" (siempre que el nivel de aplicación esquema define si se utiliza atributos XML o no), por ejemplo:
class Room {
int id=1;
String code="MR-101";
String name="Maths room";
int capacity=30;
};
codificados como:
<Room>
<id>1</id>
<code>MR-101</code>
<name>Maths room</name>
<capacity>30</capacity>
</Room>
XmlRpc fue diseñado específicamente para facilitat e la creación de bibliotecas que serializar automáticamente objetos de nivel de idioma/unserialise en llamadas RPC, y como tal tiene algunas ventajas menores cuando se usa de esta manera:
Con XML sin formato, es posible que una estructura con una miembro único que se debe confundir con una matriz con un solo elemento.
XmlRpc define un formato de hora/fecha estándar. {Aunque el tratamiento de las zonas horarias y las marcas de tiempo de fecha y hora pura se define en el nivel de aplicación.}
XmlRpc le permite pasar argumentos a la función sin nombrarlos; Las llamadas RPC XML simples requieren que nombre cada argumento.
XmlRpc define una forma estándar para nombrar el método que se llama: "methodName". Con Plain XML, la etiqueta del nodo raíz normalmente se utilizará para este fin, aunque las alternativas son posibles.
XmlRpc define un sistema de tipo simple: números enteros, cadenas, y así sucesivamente.{Tenga en cuenta que con los lenguajes tipados estáticamente, los tipos deben compilarse en el objeto de destino de todos modos, y por lo tanto son conocidos, y con los lenguajes tipados dinámicamente, a menudo las cadenas int y float se pueden usar indistintamente; tenga en cuenta también que el sistema de tipo XmlRpc normalmente no coincidiría lo suficiente con el sistema de tipos del idioma de destino que puede tener múltiples tipos enteros, etc.}
Las bibliotecas XmlRpc generalmente se integran directamente con una biblioteca Http, mientras que Xml todas las bibliotecas de serialización (?) requieren que el programador de aplicaciones pase el texto XML a la llamada Http. En idiomas más modernos como Java/Python/C#, este es un tema trivial, pero no así para, por ejemplo, C++.
hay una "percepción de marketing" que describe XML "documentos", mientras que XmlRpc está diseñado para llamadas de procedimiento. La percepción es que enviar un mensaje XmlRpc contiene una obligación para el servidor de realizar alguna acción, mientras que esta percepción no es tan fuerte con XML simple.
Algunos dirán "a quién le importa - analizar los datos XML utilizando descendente recursivo/DOM/SAX es bastante fácil de todos modos", en cuyo caso la mayor parte de las objeciones anteriores son irrelevantes.
Para aquellos que todavía prefieren la facilidad de uso de conseguir objetos de lenguaje nativo creado automáticamente, muchas de las principales lenguas tienen bibliotecas que serializar automáticamente objetos de nivel de idioma en XML sin tener que recurrir a XmlRpc, por ejemplo:
.NET - Java - Python
puede ser que el éxito de XmlRpc, tal como es, se deriva de la disponibilidad de las bibliotecas que crean automáticamente objetos de nivel de idioma, ya su vez estas bibliotecas tienen una ventaja sobre sus homólogos XML lisos debido al li San de los problemas anteriores.
desventajas de XmlRpc son:
Como se menciona en la pregunta, que es terriblemente obesos
soporte para XML llano es ubicua y por lo general no requiere integración con bibliotecas 3 ª parte grandes. Muchas aplicaciones requieren una conversión de los objetos creados automáticamente a los objetos de la aplicación de todos modos.
Muchas implementaciones xmlrpc no producen verdaderos objetos de nivel de lenguaje de los programadores ordenar esperaría, y en su lugar, por ejemplo, requerirá búsquedas en tiempo de ejecución de campos o sintaxis adicional.
Si se utiliza un documento de definición de esquema para validar las llamadas RPC, como un archivo DTD, se pierde la capacidad de verificar el esquema de nivel de aplicación; el archivo DTD simplemente le dirá que "esto es XmlRpc válido" ". No tengo conocimiento de ninguna forma estándar para definir un esquema de nivel de aplicación con un protocolo basado en XmlRpc.
3) Si tuviera que realizar llamadas a procedimientos remotos con cadenas simples o binarias, esto sería horrible y requeriría diseñar formatos para cada interacción. Pero XML simple proporciona un formato bien definido para pasar valores estructurados. No creo que hayas respondido a la pregunta "¿qué tiene XmlRpc sobre XML?" 1) Mis ejemplos comparan XmlRpc con XML, y prueban que no necesita ser prolijo para ser interoperable. XML se considera un protocolo que es bueno para la interoperabilidad. –
Estás equivocado. Tomando su ejemplo, '
No entiendo el punto de confiar en el orden de campo. En este caso, los atributos (o etiquetas) tienen nombres. ¿Por qué no miras los nombres de los campos en lugar del orden de los campos? –