17

私の会社ではしばらくの間XML-RPCを使用していますが、最近、単純な XML と比較して XML-RPC の利点は何なのか疑問に思っています。まず、それは恐ろしい「肥満」です。

<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 のサポートにはあまり感銘を受けません。両方の言語で試したすべてのライブラリで問題が発生しました。

第 3 に、XML-RPC と同じくらい簡単にプレーンな XML を使用してリモート プロシージャ コールを作成できるように思えます。{(2009 年 9 月 9 日): どの言語にも、言語レベルのオブジェクトを XML にシリアル化するためのライブラリがあります。XML と XML-RPC の両方で、アプリケーション レベルのスキーマを定義する必要があります。たとえば、フィールドの綴り方などです。ただし、追加のスキーマを定義する必要はありません。多くの人がプレーンな XML で RPC 呼び出しを行っています。}

では、XML-RPC の付加価値とは何でしょうか?

4

5 に答える 5

10

主な利点は、誰かが既に呼び出しスキーマを作成していることです。これは、たとえば複雑な構造を RPC 呼び出しにやみくもに渡すことができるリフレクションを備えた言語で特に役立ち、それを XML に変換する方法を解決してくれます。たとえば、XML-RPC ライブラリにすべてのデータ型を明示的に伝える必要がある C++ では、あまり価値がありません。

それが世界を席巻していないのはあなたの言うとおりです。図書館で見つけた奇妙なものは、この関心の低さによるものです。私は自分で2つ使用しましたが、両方にバグが見つかりました。どちらも放棄されたものであり、パッチを送り返すことができる場所がないため、私は両方のパッチを適用したプライベート バージョンを持っています。はぁ。

于 2009-09-04T00:46:09.863 に答える
3

簡単：XMLRPCが提供する

  • メソッド名を渡す標準的な方法
  • タイピングシステム。私はかなり頻繁に電話番号を扱います。それらは文字列であり、番号ではありません。
  • エラーを返す標準的な方法
  • （ほぼ）無料で内省

これはすべて、標準のXMLを超えています。

于 2010-10-19T07:55:20.093 に答える
2

XmlRpc の主な価値は、HTTP 経由で渡される XML ドキュメントを生成および解析するためのコードを記述する必要がないことです。これは、XML-RPC が関数呼び出しを表す事前定義された XML スキーマであるためです。

最適ではないライブラリでも、追加の派生値があります。このタイプのシステムを使用すると、リモート インターフェイスを基本言語インターフェイス (C++ 抽象クラス、Java インターフェイスなど) として定義できるため、使用されるワイヤ プロトコルに依存しません。コンポーネント間で通信します。

インターフェイス定義をワイヤ プロトコル (XML-RPC、SOAP など) から分離することで、必要に応じて最終的に別のプロトコルに置き換えることができます。たとえば、私たちのシステムでは、Flex フロント エンドにはHessianを使用して公開され、.NET フロント エンドには SOAP を使用して公開されているサービスがあります (Hessian .Net ライブラリには許可されていないライセンスがあります)。

現在 XML-RPC に固執することで、将来、最小限のリファクタリングで他のプロトコルに切り替えることができます。

于 2009-09-04T00:47:19.523 に答える
1

最後から始めて、さかのぼってみましょう。

3) はい、プレーンな XML (またはプレーンな文字列、またはバイナリ プロトコル) を使用してリモート プロシージャ コールを行うことができます。違いは、XmlRpc は多くの利用可能な実装を備えた明確に定義されたプロトコルであることです。つまり、a) それほど多くのコードを記述する必要がなく、b) ネットワークの反対側にいる誰とでも相互運用できます。あなたまたは彼らはお互いのコードを処理する必要があります。XmlRpc はブリッジとして機能します。

2）私はそれがかなり遍在していると思います:-)私はJavaでXmlRpcを使用したことがあるので、C ++ / PHPの実装の問題についてコメントすることはできません.

1)は上記(3)によるものです。プロトコルの冗長性は、相互運用性の結果でもあり、理由でもあります。

于 2009-09-04T00:45:49.130 に答える