HTTP/SOAPが「厚い」とみなされる理由

Question

SOAP/HTTP Webサービスコールスタックが「厚い」または「重い」との意見を聞いたことがあります。 SOAPエンベロープとメッセージのシリアライゼーション/デシリアライゼーションのために厚いと考えられますか？それは本当に重量のある操作ですか？

固定接続を介した生/バイナリデータ転送と比べて、単に「厚い」と見なされますか？

他の理由はありますか？誰かがこれについていくつかの光を当てることができますか？

Answer 1

SOAPは、HTTP以外のトランスポートを使用するのに十分抽象的に設計されています。つまり、は、ではHTTPの特定の側面（URLとメソッドのほとんどがRESTfulな使い方、たとえばPUT /customers/1234またはGET /customers/1234）を利用していません。

SOAPは同じ理由でトランスポートに依存しないため、既存のTCP/IPメカニズムもバイパスします。これは、シーケンス管理、フロー制御、サービスディスカバリ（よく知られているポート上の接続を意味する）などのトランスポートを利用できないことを意味します。

SOAP使用すべてのシリアライゼーションのXML - データはXMLパーサだけで「普遍的に読める」ことを意味しますが、効率的に機能するためには本当にSOAPパーサーが必要な定型文が多く導入されています。そして、その時点で（ソフトウェア消費者としての）あなたはXMLの利点をとにかく失いました。とにかくそれを処理するためにlibSOAPが必要な場合、有線を介してペイロードの外観を気にします。

SOAPでは、インターフェイスを記述するためにWSDLが必要です。 WSDL自体は問題ではありませんが、実際よりもはるかに「動的」なものとして宣伝される傾向があります。多くの場合、単一のWSDLが作成され、プロデューサ/コンシューマコードが自動的に生成され、変更されることはありません。全体的には、元々の問題（異なるサーバー間でのやりとり方法）を実際には解決できず、多くのツールを必要とします。また、ほとんどのSOAPサービスはHTTP経由で実行されるため、元の問題はで、すでにで始まりました。

Answer 2

まず、サービスがどのように実装されているか（つまり、メソッドシグネチャの仕組みに注意するだけでペイロードを減らすことができます）に大きく依存します。

これは、石鹸のエンベロープだけでなく、メッセージ自体も、簡素化されたバイナリ形式ではなく、むしろXMLでより大きくなる可能性があると述べています。適切なクラスとメンバ名を選択するだけで、それを大幅に減らすことができます。

以下の例は、一連のメソッドから返されたものです。繰り返されるデータ（リスト/コレクション/配列など）を返す場合、クラス/ラッパーとメンバーの正しい[シリアル化]名を選択するだけで、シリアル化されたSOAPリクエスト/レスポンスの冗長性が大きく変わることがあります。

ブリーフ/短い名前：

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ShortIDName> 
    <id>0</id> 
    <name>foo 0</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>1</id> 
    <name>foo 1</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>2</id> 
    <name>foo 2</name> 
    </ShortIDName> 
    ... 
</ArrayOfShortIDName> 

長い名前：

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    ... 
</ArrayOfThisClassHasALongClassNameIDName> 

Answer 3

私はそれが特に、SOAPエンベロープは、メッセージを構築するオーバーヘッドを大量に追加することを主だと思います少数の、深く構造化されていないパラメータを持つ単純な要求の共通のケースです。パラメータがURLクエリに単純に含まれているRESTスタイルのWebサービスと比較してください。その後

ことにWSDLと、典型的な「企業」ライブラリの実装の複雑さを追加...

Answer 4

は、私はそれがあるため、包装やメッセージを開梱に関わる比較的大きなオーバーヘッドの「厚い」（シリアライズとデシリアライズと考えられ）。

2つの32ビット整数をとるAddというWebメソッドを使用するWebサービスを考えてみましょう。呼び出し側は2つの整数をパッケージ化し、応答で1つの整数を受け取ります。実際にはわずか96ビットの情報しか送信されない場合、SOAPパケットを追加するとおそらく各方向に約3,000以上の余分なビットが追加されます。 30倍の増加。

これに加えて、メッセージをUTF-8（または何でも）XMLにシリアライズおよびデシリアライズすることに関連する比較的遅いパフォーマンスが追加されています。確かに、今日はかなり高速ですが、それは自明ではありません。

Answer 5

SOAPの信号対雑音比が低すぎます。単純な会話では、データ値のない構造オーバーヘッドが多すぎます。あまりにも明示的な設定が必要です（暗黙的な設定（JSONなど）と比較して）。

これは始まったわけではありませんでしたが、標準委員会が参加したときの良いアイデアは何のために起こったのでしょうか。

Answer 6

1 - XMLスキーマは、WSDL仕様の重要な部分ですが、実際には大きくて複雑です。実際には、XMLスキーマをプログラミング言語構造にマップするようなツールを使用すると、XMLスキーマ機能の一部しかサポートされません。

2 - WS- *仕様（WS-SecurityやWS-SecureConversationなど）は、やはり大きく複雑です。彼らは、マイクロソフトやIBMが完全に実装することができる人数よりも少ないリソースはほとんどないように設計されています。

Answer 7

SOAPとWSDLは非常に複雑な標準であり、標準のさまざまなサブセットをサポートする多くの実装があります。 SOAPは、XML-RPCと同じように、単純な外部関数インターフェイスにはあまりよくマッピングされません。代わりに、正しいSOAPメッセージを生成するために、XML名前空間、エンベロープ、ヘッダー、WSDL、XMLスキーマなどを理解する必要があります。 XML-RPCサービスを呼び出すために必要なことは、それを定義し、エンドポイントしてメソッドを呼び出すことだけです。例えば、Rubyで：

require 'xmlrpc/client' 

server = XMLRPC::Client.new2("http://example.com/api") 
result = server.call("add", 1, 2) 

XML-RPCに加えて、このようなプレーンXMLまたはHTTP上JSONとしても、はるかに簡単かつ軽量であることができる他の技術が、存在することが意味も（しばしば、RESTと称される特定の他の設計上の考慮事項）。 HTTPよりもXMLやJSONのようなものの利点は、JavaScriptやフォーム提出のダムのWebページからでも簡単に使用できることです。 curlのようなツールを使ってコマンドラインから簡単にスクリプトを作成することもできます。 HTTPライブラリー、XMLライブラリー、JSONライブラリーはほぼすべての場所で使用でき、JSONパーサーが使用できない場合でも、独自のものを作成するのは非常に簡単です。

編集：私は、私は概念的ヘビー級SOAPがどのように言及していますことを明確にすべき、重いとは対照的に、それはデータの生の量です。私は、生データの量はそれほど重要ではないと考えています（ただし、小さなリクエストをたくさん処理する必要がある場合はすばやく追加されます）が、コンセプトヘビーウェイトは非常に重要です。非互換性がある場合があります。

Answer 8

私は最初のポスターに同意しますが、追加したいと思います。厚くて薄い定義は相対的です。 JSONやRESTのようなトランスポートでは、新たなSOAPが「hello world」の例のために表面に重く見えます。今では、SOAPを何重にし、WS 2.0を一般的に企業/堅牢な機能にするのかを知っているかもしれません。 JSONは、WS 2.0と同じように安全ではありません。私は厚さと呼ばれるSOAPを聞いていないが、多くの非XMLナットはこれらの仕様を重くまたは厚く見ている。明確にするために、私は両方のためにどちらかの場所を持っているかのどちらかに反対して話していません。 XMLはより冗長で人間が読めるので、「太く」なります。最後の部分は、AJAXのような新しいウェブトレンドでは、大きなページに掲載するのではなく、永続的な接続プロトコルであるHTTPをHTTPで見ている人がいるということです。実際には何のメリットもないので、接続のオーバーヘッドは大きいです。

要約すると、本当の理由はありません誰かがSOAP/HTTPを厚く呼びたいのではなく、それはすべて相対的です。すべてのシナリオで完璧な基準はほとんどありません。スマートなWeb開発者が、XML技術がどのように、そしてJSONがいかに優れていると思っているかを話すことで、スマートになっていると思います。それぞれには場所があります。