Jakie zalety ma XML-RPC zamiast zwykłego XML?

Question

Moja firma od jakiegoś czasu używa numeru XML-RPC, ale ostatnio zastanawiam się, jaką korzyść ma XML-RPC w porównaniu do zwykłego XML. Po pierwsze, to straszne "otyły", należy rozważyć:

<struct> 
    <member> 
     <name>ROOM_ID</name> 
     <value> 
      <int>1</int> 
     </value> 
    </member> 

    <member> 
     <name>CODE</name> 
     <value> 
      <string>MR-101</string> 
     </value> 
    </member> 

    <member> 
     <name>NAME</name> 
     <value> 
      <string>Math Room</string> 
     </value> 
    </member> 

    <member> 
     <name>CAPACITY</name> 
     <value> 
      <int>30</int> 
     </value> 
    </member> 
</struct> 

porównaniu do tego:

<room><ROOM_ID>1</ROOM_ID><CODE>MR-101</CODE> 
<NAME>Math Room</NAME><CAPACITY>30</CAPACITY></room> 

lub nawet poniżej:

<room ROOM_ID=1 CODE=MR-101 NAME=”Math Room” CAPACITY=30 /> 

drugie, XML-RPC wydaje się dość powszechne, ale nie całkiem wszechobecny i nie jestem pod takim wrażeniem wsparcia dla niego w C++ i PHP. Miałem problemy ze wszystkimi bibliotekami, które wypróbowałem w obu językach.

Po trzecie, wydaje mi się, że mogę wykonywać zdalne wywołania procedur za pomocą zwykłego XML tak łatwo, jak przy XML-RPC. {(9/9/2009): Każdy język ma biblioteki do szeregowania obiektów na poziomie języka na XML. Zarówno XML, jak i XML-RPC wymagają zdefiniowania schematów na poziomie aplikacji, na przykład, jak należy pisać pola, ale żaden z nich nie wymaga definiowania dodatkowego schematu. Wiele osób nawiązuje połączenia RPC z prostym kodem XML.}

Czym jest wartość dodana XML-RPC?

Answer 1

Krótka odpowiedź: Oba protokoły mogą być używane do wykonywania zdalnych wywołań procedur (RPC). Oba protokoły wymagają zdefiniowania schematu na poziomie aplikacji, a mówiąc ogólnie, żaden z protokołów nie wymaga żadnego dodatkowego schematu do zdefiniowania serializacji obiektów na poziomie języka (zobacz szczegóły poniżej).

Jednak XmlRpc korzysta z większego wsparcia z bibliotek, które używają funkcji meta-programowania (odbicia) języka do mapowania wywołań XmlRpc, bezpośrednio (no, nigdy w 100% bezpośrednio) do wywołań funkcji poziomu językowego. Przyczyną lepszej obsługi XmlRpc niż zwykły XML jest (a) historyczny wypadek/wynik marketingu ze strony zwolenników XmlRpc, lub (b) suma mniejszych problemów z tłumaczeniem wymienionych poniżej przesądza o skali na korzyść XmlRpc. Z drugiej strony, XmlRpc ma dwie główne wady: (1) wymaga około 4 razy większej przepustowości i (2) podważa zamiar narzędzi do walidacji schematu XML: każdy pakiet będzie po prostu stemplowany jako "tak, to jest poprawny XmlRpc", niezależnie od błędów ortograficznych i zaniedbań w polach poziomu aplikacji.

Długa odpowiedź:

Wbrew powszechnemu przekonaniu, nie trzeba standard do zdefiniowania jak kodować obiektów w zwykłym poziomie języka XML - jest zazwyczaj tylko jedno „rozsądny” sposób (pod warunkiem poziomu aplikacji schemat określa, czy używać atrybutów XML lub nie), np:

class Room { 
    int id=1; 
    String code="MR-101"; 
    String name="Maths room"; 
    int capacity=30; 
}; 

zakodowane jako:

<Room> 
    <id>1</id> 
    <code>MR-101</code> 
    <name>Maths room</name> 
    <capacity>30</capacity> 
</Room> 

xmlrpc został specjalnie zaprojektowany, aby facilitat e tworzenie bibliotek, które automatycznie serialise/unserialise obiektów język poziomu w wywołań RPC, i jako takie ma pewne drobne zalety, gdy stosuje się w ten sposób:

1. zwykły XML, jest to możliwe dla struct z pojedynczy element, którego należy pomylić z tablicą z pojedynczym elementem.

2. XmlRpc definiuje standardowy format godziny/daty. {Chociaż traktowanie stref czasowych i czystego czasu lub czystych datowników jest zdefiniowane na poziomie aplikacji.}

3. XmlRpc pozwala przekazywać argumenty do funkcji bez nazywania ich; Zwykłe wywołania RPC XML wymagają podania każdego argumentu.

4. XmlRpc definiuje standardowy sposób nazywania wywoływanej metody: "methodName". W przypadku zwykłego kodu XML zwykle użyty zostałby znacznik węzła głównego, chociaż możliwe są rozwiązania alternatywne.

5. XmlRpc definiuje prosty system typu: liczby całkowite, ciągi i tak dalej.{Zauważ, że w statycznie napisanych językach, typy muszą być w każdym razie kompilowane do obiektu docelowego, a zatem są znane, a przy dynamicznych typach języków często int i float i stringi mogą być używane zamiennie; zauważmy również, że system typu XmlRpc byłby zwykle kiepskim wyborem dla systemu typów języka docelowego, który może mieć wiele typów liczb całkowitych, i tak dalej.}

6. Biblioteki XmlRpc zazwyczaj integrują się bezpośrednio z biblioteką Http, a Xml biblioteki serializacji all (?) wymagają od programisty aplikacji przekazania tekstu XML do wywołania HTTP. W bardziej nowoczesnych językach, takich jak Java/Python/C#, jest to sprawa trywialna, ale nie na przykład dla C++.

7. Istnieje "percepcja marketingowa", którą XML opisuje "dokumenty", a XmlRpc służy do wywoływania procedur. Percepcja polega na tym, że wysłanie wiadomości XmlRpc zobowiązuje serwer do wykonania pewnej akcji, podczas gdy ta percepcja nie jest tak silna w przypadku zwykłego XML.

Niektórzy ludzie powiedzą „kogo to obchodzi - analizowania danych XML za pomocą zejście rekurencyjne/DOM/SAX jest całkiem proste mimo to”, w którym to przypadku większości z powyższych zarzutów są nieistotne.

Dla tych, którzy nadal preferują łatwość użycia coraz rodzimych obiektów języka stworzonego automatycznie, wiele główne języki mają biblioteki, które automatycznie serialise obiektów język poziomie do XML bez uciekania się do xmlrpc, np:

.NET - Java - Python

być może sukces xmlrpc, jak to jest, wynika z dostępności bibliotek, które automatycznie tworzyć obiekty język poziomie, a to z kolei biblioteki te mają przewagę nad ich zwykłych odpowiedników XML należnych do li powyższe problemy.

Wady xmlrpc są:

• Jak wspomniano w pytaniu, to jest strasznie otyła

• Wsparcie dla zwykłego XML jest wszechobecne i zwykle nie wymaga integracji z dużymi bibliotekami 3rd party. Wiele aplikacji wymaga konwersji automatycznie tworzonych obiektów do własnych obiektów aplikacji.

• Wiele implementacji XmlRpc nie potrafi wygenerować prawdziwych obiektów o poziomie języka, których programiści sortowania oczekują, a zamiast tego wymagają np. wyliczenia pól w czasie wykonywania lub dodatkowa składnia.

• Jeśli do definicji połączeń RPC, takich jak plik DTD, używany jest dokument definicji schematu, utracisz możliwość sprawdzania schematu na poziomie aplikacji - plik DTD po prostu powie Ci, że "to jest poprawna wersja XmlRpc ". Nie ma według mnie żadnego standardowego sposobu definiowania schematu na poziomie aplikacji za pomocą protokołu opartego na XmlRpc.

Answer 2

Zacznę od końca i iść do tyłu:

3) Tak, można zrobić procedura zdalna wymaga zwykły XML (lub zwykłych łańcuchów, lub protokołu binarnego). Różnica polega na tym, że XmlRpc jest dobrze zdefiniowanym protokołem z wieloma dostępnymi implementacjami, co oznacza: a) nie musisz pisać tyle kodu i b) możesz współpracować z kimkolwiek, kto jest na drugim końcu przewodu bez Ty lub oni musicie radzić sobie nawzajem. XmlRpc służy jako most.

2) Powiedziałbym, że to jest quite ubiquitous :-) Pracowałem z XmlRpc w Javie, więc nie mogę komentować problemów z implementacją C++/PHP.

1) jest spowodowane (3) powyżej. Szczegółowość protokołu jest zarówno konsekwencją, jak i powodem jego interoperacyjności.

Answer 3

Podstawową zaletą jest to, że ktoś już wypracował dla ciebie schemat wywołujący. Jest to szczególnie przydatne w językach z refleksją, w których można po prostu na ślepo przekazać, powiedzmy, skomplikowaną strukturę do wywołania RPC, i będzie pracować, jak przetłumaczyć to na XML dla ciebie. Jest mniej wartościowy w, powiedzmy, C++, gdzie musisz powiedzieć bibliotece XML-RPC, co wszystkie typy danych jawnie.

Masz rację, że nie porwała świata przez burzę. Osobliwości znalezione w bibliotekach wynikają z niskiego poziomu zainteresowania. Użyłem dwóch sam i znalazłem błędy w obu. I obie były abandonware, więc nie mam gdzie wysłać poprawek, więc mam prywatne poprawki obu wersji. Westchnienie.

Answer 4

Podstawową wartością XmlRpc jest to, że nie trzeba pisać kodu, aby generować i analizować dokumenty XML przekazywane przez HTTP, ponieważ XML-RPC jest predefiniowanym schematem XML reprezentującym wywołania funkcji.

Nawet z mniej niż optymalnymi bibliotekami, istnieje dodatkowa wartość pochodna, ponieważ użycie tego typu systemu pozwala zdefiniować zdalne interfejsy jako podstawowe interfejsy językowe (Klasa abstrakcyjna C++, interfejsy Java itp.), Które są niezależne od protokół transmisji używany do komunikacji między komponentami.

Rozdzielenie definicji interfejsu z protokołu drutu (XML-RPC, SOAP, itp.) Umożliwia ostateczne zastąpienie w alternatywnych protokołach, tam gdzie jest to właściwe. Na przykład w naszym systemie mamy usługi, które są ujawnione przy użyciu Hessian dla naszych frontów Flex i SOAP dla naszych front endów .NET (biblioteka Hessian .Net ma niedozwoloną licencję).

Trzymając się XML-RPC teraz, masz możliwość przejścia na inny protokół w przyszłości przy minimalnym refaktoryzacji.

Answer 5

proste: XML-RPC zapewnia

• standardowy sposób przekazać nazwę metody
• system typowania. Często używam numerów telefonicznych, są to ciągi, a NIE numery.
• standardowy sposób, aby powrócić błędy
• introspekcji (prawie) za darmo

Wszystko to na standardowym formacie XML.