일반 XML에 비해 XML-RPC의 이점은 무엇입니까?

Question

저희 회사는 잠시 동안 XML-RPC을 사용하고 있지만 요즘에는 XML-RPC가 일반 XML에 비해 어떤 이점이 있는지 궁금합니다. 첫째, 끔찍한 "비만"의 고려 :

<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> 

이 비교 :

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

심지어이 :

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

이 두 번째로, XML-RPC는 상당히 광범위하게 보인다

하지만 꽤을 유비쿼터스와 나는 C + +와 PHP에서 그것에 대한 지원에 감동하지 않았습니다. 나는 두 언어 모두에서 시도한 모든 라이브러리에 문제가있었습니다.

셋째, XML-RPC처럼 쉽게 일반 XML로 원격 프로 시저 호출을 할 수 있다고 생각합니다. {(9/9/2009) : 모든 언어에는 언어 수준 객체를 XML로 직렬화하기위한 라이브러리가 있습니다. XML과 XML-RPC는 응용 프로그램 수준 스키마를 정의해야합니다 (예 : 필드의 철자는 어떻게 지정해야 하나 추가 스키마는 정의 할 필요가 없습니다). 많은 사람들이 일반 XML로 RPC 호출을 수행합니다.}

그래서 XML-RPC의 부가 가치는 무엇입니까?

Answer 1

짧은 대답은 두 프로토콜 모두 원격 프로 시저 호출 (RPC)을 작성하는 데 사용할 수 있습니다. 두 프로토콜 모두 응용 프로그램 수준 스키마를 정의해야하며 일반적으로 프로토콜에는 언어 수준 개체를 serialize하는 방법을 정의하기위한 추가 스키마가 필요하지 않습니다 (자세한 내용은 아래 참조).

그러나 XmlRpc는 XmlRpc 호출을 언어 수준 함수 호출에 직접 (물론 100 % 절대로) 직접 매핑하기 위해 언어의 메타 프로그래밍 (리플렉션) 기능을 사용하는 라이브러리의 지원을 더 많이받습니다. 일반 XML보다 XmlRpc에 대한 지원이 더 좋은 이유는 (a) XmlRpc 지지자의 마케팅 사고 또는 결과, (b) 아래에 나열된 작은 번역 문제의 합계가 XmlRpc.

반면에 XmlRpc는 (1) 약 4 배의 대역폭이 필요하며 (2) XML 스키마 유효성 검사 도구의 의도를 파괴합니다. 모든 패킷은 다음과 같이 간단하게 스탬프 처리됩니다. 응용 프로그램 수준 필드의 철자 오류 및 누락과 상관없이 "예, 유효한 XmlRpc"입니다.

긴 대답은 :

는 달리 대중적인 신념에, 당신은 일반 XML의 언어 수준 개체를 인코딩하는 방법을 정의하는 표준이 필요하지 않습니다 - 응용 프로그램 수준을 제공 한 "분별있는"방법은 (일반적으로이

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

XMLRPC 특별히 facilitat하도록 설계되었습니다 :로 인코딩

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

: 스키마는 XML 속성 여부) 등을 사용할지 여부를 정의합니다 자동으로 RPC 호출에/unserialise 언어 수준 개체를에는 직렬화,이 방식으로 사용하는 경우 등은 몇 가지 사소한 장점을 가지고 도서관의 전자 생성 : 일반 XML로

1. , 그것은을 가진 구조체에 대한 가능 단일 요소가있는 배열과 혼동 될 수 있습니다.

2. XmlRpc는 표준 시간/날짜 형식을 정의합니다. {시간대 및 순수 시간 또는 순수 날짜 시간 소인의 처리는 응용 프로그램 수준에서 정의되지만

3. XmlRpc를 사용하면 함수의 이름을 지정하지 않고 함수에 인수를 전달할 수 있습니다. 일반 XML RPC 호출에는 각 인수의 이름을 지정해야합니다.

4. XmlRpc는 호출되는 메서드의 이름을 지정하는 표준 방법 인 "methodName"을 정의합니다. Plain XML을 사용하면 대안이 가능하지만 일반적으로 루트 노드의 태그가이 용도로 사용됩니다.

5. XmlRpc는 정수, 문자열 등 간단한 시스템을 정의합니다.{정적으로 형식이 지정된 언어의 경우 유형을 대상 객체에 컴파일해야하므로 동적 유형의 언어를 사용하여 int 및 float의 문자열을 서로 바꿔 사용할 수 있습니다. 또한 XmlRpc 형식 시스템은 대개 여러 정수 유형을 가질 수있는 대상 언어의 형식 시스템과 일치하지 않습니다.}

6. XmlRpc 라이브러리는 일반적으로 Http 라이브러리와 직접 통합되는 반면 Xml 직렬화 라이브러리 all (?)을 사용하면 응용 프로그램 프로그래머가 XML 텍스트를 Http 호출에 전달해야합니다. Java/Python/C#과 같은보다 현대적인 언어에서 이것은 사소한 문제입니다. C++.

7. XML이 "문서"를 설명하는 반면 "XmlRpc"는 프로 시저 호출을 위해 설계된 "마케팅 인식"이 있습니다. XmlRpc 메시지를 보내는 것은 서버가 어떤 동작을 수행해야한다는 의무를 지니고 있지만,이 인식은 일반 XML에서는 그리 강하지 않습니다. 위의 반대의 대부분이 관련이있는 경우, - "재귀 하강/DOM/SAX를 사용하여 XML 데이터를 파싱 어쨌든 꽤 쉽게 관심있는 사람"

어떤 사람들은 말 것입니다. Java -

.NET : 여전히 자동으로 생성 모국어 객체를 얻기의 사용의 용이성을 선호하는 사람들을 위해

, 많은 주요 언어가 자동으로 XMLRPC에 의지하지 않고 XML로 언어 수준 개체를에는 직렬화 라이브러리, 예를 - Python

그것은이 같은 XMLRPC의 성공은, 자동으로 언어 수준의 객체를 생성 라이브러리의 가용성에서 유래하고, 차례대로 라이브러리 인해 일반 XML 대응을 통해 이점을 가지고 있다고 할 수있다 리에 문제의 위. XMLRPC의

단점은 다음과 같습니다 질문에서 언급 한 바와 같이

• , 큰 제 3의 라이브러리와의 통합을 필요로하지 않는 보통 일반 XML에 대한

• 지원 유비쿼터스 끔찍 비만입니다. 많은 응용 프로그램은 자동으로 생성 된 객체를 응용 프로그램의 객체로 변환해야합니다.

• 많은 XmlRpc 구현은 프로그래머가 기대하는 진정한 언어 수준의 객체를 생성하지 못하고 대신 예를 들어 필요합니다. 필드 또는 추가 구문의 런타임 조회.

• DTD 파일과 같은 RPC 호출의 유효성을 검사하는 데 스키마 정의 문서를 사용하면 응용 프로그램 수준 스키마를 확인할 수 없게됩니다. DTD 파일은 "유효한 XmlRpc입니다 ". 내 지식에는 XmlRpc 기반 프로토콜로 응용 프로그램 수준 스키마를 정의하는 표준 방법이 없습니다.

Answer 2

저 끝에서 시작하여 거꾸로 가자 :

3) 예, 원격 프로 시저 일반 XML (또는 일반 문자열, 또는 바이너리 프로토콜)와 통화를 할 수 있습니다. 차이점은 XmlRpc는 사용 가능한 구현이 많은 잘 정의 된 프로토콜로, a) 많은 코드를 작성할 필요가없고 b) 코드없이 다른 쪽 끝에있는 사람과 상호 운용 할 수 있다는 것을 의미합니다. 너 또는 그들 서로의 코드를 처리해야합니다. XmlRpc는 브리지 역할을합니다.

2) 저는 quite ubiquitous :-)입니다. Java에서 XmlRpc로 작업 했으므로 C++/PHP 구현 문제에 대해서는 언급 할 수 없습니다.

1)은 위의 (3)으로 인한 것입니다. 프로토콜의 자세한 표시는 상호 운용성의 결과이자 이유입니다.

Answer 3

가장 큰 장점은 누군가가 이미 호출 스키마를 작성했기 때문입니다. 이는 특히 RPC 호출에 복잡한 구조를 전달할 수있는 리플렉션이있는 언어에서 유용하며,이를 XML로 변환하는 방법을 알아낼 수 있습니다. C++에서는 XML-RPC 라이브러리에 모든 데이터 유형이 명시 적으로 무엇인지 알려주지 않아도됩니다.

당신은 그것이 폭풍에 의해 세계를 가져 가지 않았 음이 틀림 없습니다. 도서관에서 발견되는 이상한 점은이 낮은 수준의 관심 때문입니다. 나는 두 사람을 사용했고 둘 다에 버그를 발견했습니다. 두 가지 모두 포기 제품 이었으므로 패치를 다시 보낼 수있는 곳이 없으므로 둘 다 개인 패치 버전이 있습니다. 한숨.

Answer 4

XmlRpc의 주된 가치는 XML-RPC가 함수 호출을 나타내는 미리 정의 된 XML 스키마이므로 XML을 통해 전달되는 XML 문서를 생성하고 구문 분석 할 필요가 없다는 것입니다.

최적의 라이브러리가 아닌 경우에도이 유형의 시스템을 사용하면 원격 인터페이스를 기본 언어 인터페이스 (C++ 추상 클래스, Java 인터페이스 등)로 정의 할 수 있으므로 추가 파생 값이 있습니다. 구성 요소간에 통신하는 데 사용되는 와이어 프로토콜.

유선 프로토콜 (XML-RPC, SOAP 등)과 인터페이스 정의를 분리하면 결국 적절한 대체 프로토콜로 대체 할 수 있습니다. 예를 들어 우리 시스템에서는 Flex 프런트 엔드에 Hessian, .NET 프론트 엔드에는 SOAP (Hessian .Net 라이브러리에는 허가되지 않은 라이센스가 있음)를 사용하여 노출되는 서비스가 있습니다.

XML-RPC를 사용하면 나중에 리팩터링을 최소화하면서 다른 프로토콜로 전환 할 수 있습니다.

Answer 5

쉬운 : XML의 RPC는 메소드 이름

타이핑 시스템을 통과

• 표준 방법을 제공합니다. 나는 전화 번호를 자주 사용한다. 그것들은 문자열이 아니라 숫자이다.
• 표준 XML을 통해 무료

모든이에 대한

성찰 (거의) 오류를 반환하는 표준 방식.