La risposta breve è: entrambi i protocolli possono essere utilizzati per effettuare chiamate di procedura remota (RPC). Entrambi i protocolli richiedono la definizione di uno schema a livello di applicazione e, in generale, nessuno dei protocolli richiede alcuno schema aggiuntivo per definire come serializzare gli oggetti a livello di linguaggio (vedere sotto per alcuni dettagli).
Tuttavia, XmlRpc gode di un maggiore supporto da librerie che utilizzano le funzionalità di metaprogrammazione (riflessione) del linguaggio per mappare le chiamate XmlRpc, direttamente (beh, mai al 100% direttamente) alle chiamate di funzione a livello di lingua. Il motivo per cui esiste un supporto migliore per XmlRpc rispetto al semplice XML è (a) un incidente storico/risultato del marketing da parte dei sostenitori di XmlRpc, o (b) la somma dei problemi di traduzione minori elencati sotto punta le scale a favore di XMLRPC.
D'altra parte, XmlRpc soffre di 2 svantaggi principali: (1) richiede circa 4 volte la larghezza di banda e (2) sovverte l'intento degli strumenti di convalida dello schema XML: ogni pacchetto verrà semplicemente timbrato come "sì, è valido XmlRpc", indipendentemente dagli errori di ortografia e dalle omissioni nei campi a livello di applicazione.
La risposta lunga:
Contrariamente alla credenza popolare, non è necessario uno standard per definire come codificare oggetti di livello linguaggio XML semplice - v'è generalmente solo un modo "sensibili" (a condizione che il livello di applicazione schema definisce se usate gli attributi XML o non), ad esempio:
class Room {
int id=1;
String code="MR-101";
String name="Maths room";
int capacity=30;
};
codificati come:
<Room>
<id>1</id>
<code>MR-101</code>
<name>Maths room</name>
<capacity>30</capacity>
</Room>
XMLRPC è stato specificamente progettato per agevolarne e la creazione di librerie che puntate automaticamente/oggetti unserialise livello lingua in chiamate RPC, e come tale ha alcuni vantaggi minori quando usato in questo modo:
Con XML pianura, è possibile che una struttura con un membro singolo da confondere con un array con un singolo elemento.
XmlRpc definisce un formato orario/data standard. {Anche se il trattamento di fusi orari e tempo puro o data/ora pura è definito a livello di applicazione.}
XmlRpc consente di passare argomenti alla funzione senza nominarli; Le normali chiamate RPC XML richiedono che il nome di ogni argomento.
XmlRpc definisce un metodo standard per denominare il metodo chiamato "metodoName". Con Plain XML, il tag del nodo radice verrebbe tipicamente usato per questo scopo, sebbene siano possibili alternative.
XmlRpc definisce un sistema di tipo semplice: numeri interi, stringhe e così via.{Si noti che con linguaggi tipizzati staticamente, i tipi devono essere compilati comunque nell'oggetto di destinazione, e quindi sono noti, e con linguaggi tipizzati dinamicamente, spesso int e float e stringhe possono essere usati in modo intercambiabile; si noti inoltre che il sistema di tipo XmlRpc in genere non corrisponde al tipo di sistema della lingua di destinazione che può avere più tipi di interi e così via.}
Le librerie XmlRpc generalmente si integrano direttamente con una libreria Http, mentre Xml tutte le librerie di serializzazione (?) richiedono al programmatore dell'applicazione di passare il testo XML alla chiamata Http. Nei linguaggi più moderni come Java/Python/C#, questo è un aspetto banale, ma non così per es. C++.
Esiste una "percezione di marketing" che XML descrive "documenti", mentre XmlRpc è progettato per le chiamate di procedura. La percezione è che l'invio di un messaggio XmlRpc contenga l'obbligo per il server di eseguire alcune azioni, mentre questa percezione non è così forte con il semplice XML.
Alcune persone dicono "chi se ne frega - analisi dei dati XML utilizzando ricorsiva discesa/DOM/SAX è abbastanza facile in ogni caso", nel qual caso la maggior parte delle obiezioni di cui sopra sono irrilevanti.
Per chi preferisce ancora la facilità d'uso di ottenere oggetti linguaggio nativi creati automaticamente, molte lingue importanti hanno librerie che puntate automaticamente oggetti a livello di lingua in XML senza ricorrere a XMLRPC, ad esempio:
.NET - Java - Python
può essere che il successo di XMLRPC, così com'è, deriva dalla disponibilità delle librerie che creano automaticamente oggetti a livello di linguaggio, e, a sua volta queste librerie hanno un vantaggio rispetto ai loro omologhi XML semplici dovuti al li st dei problemi di cui sopra.
Svantaggi di XMLRPC sono:
Come accennato in questione, non è terribilmente obeso
supporto per XML pianura è onnipresente e di solito non richiede l'integrazione con grandi biblioteche 3rd party. Molte applicazioni richiedono comunque una conversione degli oggetti creati automaticamente sugli oggetti dell'applicazione stessa.
Molte implementazioni XmlRpc non riescono a produrre veri oggetti a livello di linguaggio dei programmatori di ordinamento che si aspetterebbero e invece richiedono ad es. ricerche run-time di campi o sintassi extra.
Se un documento di definizione dello schema viene utilizzato per convalidare le chiamate RPC, come un file DTD, allora si perde la possibilità di controllare lo schema a livello di applicazione - il file DTD ti dirà semplicemente che "questo è XmlRpc valido ". Non è a mia conoscenza un modo standard per definire uno schema a livello di applicazione con un protocollo basato su XmlRpc.
3) Se dovessi effettuare chiamate di procedura remota con semplici stringhe o binari, ciò sarebbe orribile e richiede la progettazione di formati per ogni interazione. Ma l'XML semplice fornisce un formato ben definito per il passaggio di valori strutturati. Non penso che tu abbia risposto alla domanda "che cosa XmlRpc ha su XML?" 1) I miei esempi confrontano XmlRpc con XML e dimostrano che non è necessario essere prolissi per essere interoperabili. XML è considerato un protocollo che è buono per l'interoperabilità. –
Ti stai sbagliando. Prendendo il tuo esempio, '
Non capisco il punto sul fatto di fare affidamento sull'ordine dei campi. In questo caso, gli attributi (o tag) hanno nomi. Perché non dovresti guardare i nomi dei campi piuttosto che l'ordine dei campi? –