web-dev-qa-db-ja.com

SOAPメッセージをHTTP経由で送信する必要があるのはなぜですか？

以下は、デモSOAPリクエストメッセージです。

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

    <SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
   <SOAP-ENV:Header>
       <t:SessionOrder
         xmlns:t="http://example.com"
         xsi:type="xsd:int" mustUnderstand="1">
           5
       </t:SessionOrder>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
       <GetStockQuote
         xmlns="http://someexample.com">
           <Price>MSFT</Price>
       </GetStockQuote>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

このSOAPメッセージはWebページのようにエンコードされています。なぜHTTPプロトコルを使用する必要があるのですか？SOAPメッセージは一部のXMLでは、情報交換プロトコルとして単にXMLを使用して、HTTPヘッダーを取り除きます（したがって、HTTPはそのままにしておきます）。

どうもありがとう。

更新-1

HTTPはトランスポートレベルのプロトコルではありません。これは単なるアプリケーションレベルのプロトコルです。輸送とは何の関係もありません。実際、私の質問は、HTTPの内容をSOAPメッセージに追加する動機は何ですか？

xmlsoapnetwork-programmingprotocolswebservice-client
22
smwikipedia

SOAPは、さまざまなトランスポートを介して送信できます。 HTTPはその1つにすぎません。

25
Emil Vikström

概観

[〜＃〜] soap [〜＃〜]はメッセージングプロトコルであり、簡単に言えば別のXML言語です。
その目的は、ネットワークを介したデータ交換です。その懸念は、これらのデータのカプセル化とそれらの送受信のルールです。

[〜＃〜] http [〜＃〜]はアプリケーションプロトコルであり、SOAPメッセージはHTTPペイロードとして配置されます。
HTTPのオーバーヘッドはありますが、HTTPはファイアウォールに対して開かれたプロトコルであり、よく理解され、広くサポートされているという利点があります。したがって、Webサービスは、すでに導入されているテクノロジを介してアクセスおよび公開できます。

SOAPメッセージは通常[〜＃〜] http [〜＃〜]を介して交換されます。他の（アプリケーション）プロトコルを使用することは可能ですが、 [〜＃〜] smtp [〜＃〜]または[〜＃〜] ftp [〜＃〜]、非HTTPバインディングはSOAP仕様であり、 WS-BP（相互運用性仕様） ではサポートされていません。
SOAPメッセージをraw TCPを介して交換できますが、相互運用できない（WS-BPに準拠していない）Webサービスがあります。

今日の議論は、SOAPオーバーヘッドがまったくなく、HTTP経由でデータを送信しない理由です（RESTful WS）。

[~~~~] soap [〜＃〜]に[〜＃〜] http [〜＃〜]を使用する理由

私はOPの質問をより詳細に扱い、SOAPにHTTPを使用する理由を尋ねます。

まず最初にSOAPはデータのカプセル化フォーマットを定義し、それがそれです。
現在、Webのトラフィックの大部分はHTTP経由です。 HTTPはどこでも文学であり、サーバーとクライアント（つまりブラウザ）の確立されたインフラストラクチャによってサポートされています。さらに、非常によく理解されているプロトコルです。

SOAPを作成した人々は、この準備が整ったインフラストラクチャと

  1. SOAPメッセージは、HTTP経由でトンネリングできるように設計されています
  2. 仕様では、他の非HTTPバインディングを参照していませんが、転送の例として具体的にHTTPを参照しています。

HTTPを介したトンネリングは、急速な導入に役立ち、実際に役立ちました。 HTTPのインフラストラクチャは既に整っているので、企業は別の種類の実装に追加の費用をかける必要はありません。代わりに、すでに展開されているテクノロジーを使用してWebサービスを公開し、アクセスできます。

特にJavaでは、WebサービスはサーブレットエンドポイントまたはEJBエンドポイントのいずれかとしてデプロイできます。したがって、基盤となるすべてのネットワークソケット、スレッド、ストリーム、HTTPトランザクションなどはコンテナによって処理され、開発者はXMLペイロードのみに焦点を当てます。
したがって、企業はポート80でTomcatまたはJBossを実行しており、Webサービスもデプロイされ、アクセス可能です。トランスポート層でプログラミングを行う必要はなく、堅牢なコンテナが他のすべてを処理します。
最後に、ファイアウォールがHTTPトラフィックを制限しないように構成されているという事実は、HTTPを好む3番目の理由です。

通常、HTTPトラフィックが許可されるため、クライアント/サーバーの通信がはるかに簡単になり、HTTPトンネリングの結果としてのネットワークセキュリティブロッカーの問題がなくてもWebサービスが機能します。

SOAPはXML =プレーンテキストであるため、ファイアウォールはHTTP本文のコンテンツを検査してブロックすることができます。ただし、この場合、内容に応じてSOAPを拒否または受け入れるように拡張することもできます。この問題の原因と思われる部分は、WebサービスまたはSOAPとは関係ありません。ファイアウォールの仕組み。

とは言っても、ファイアウォールは基本的にバイパスされるため、HTTPトラフィックが制限されていないことがセキュリティの問題を引き起こすことがよくあります。そのため、アプリケーションゲートウェイが使用されます。
しかし、これはこの投稿とは関係ありません。

概要

HTTPを使用する理由を要約すると、

  1. HTTPは人気があり成功しています。
  2. HTTPインフラストラクチャが整っているため、Webサービスを展開するための追加費用はかかりません。
  3. HTTPトラフィックはファイアウォールに対して開かれているため、ネットワークセキュリティの結果として、Webサービスの機能中に問題は発生しません。
51
Cratylus

HTTPを使用する動機は、ファイアウォールを通過することでした。ほとんどのネットワークIT担当者は、どのポートも開くことを許可していませんが、何らかの理由で常にWebページ用にポート80を開くことを許可しています。 Webサーバーは何年にもわたってテストされてきたので、それらを保護する方が「簡単」です。 HTTPを使用することで、通信プロトコルを処理するための既存のツールセットが得られます。

7
Andrew T Finnell

TCPも使用できます。以前は.NET Remotingと呼ばれていましたが、現在はWCFの一部です...

2
Numenor

SOAPをHTTP経由で送信する必要はありません。開発者は最も頻繁にHTTPとPOST石鹸を通常のHTTPであるかのように石鹸を使用しますPOSTこれは、すでにREST HTTP経由で実装しています。たとえば、SOAP SMTPメールプロトコル経由で送信する方法です。 Sending = SOAP SMTP経由

HTTPを使用するのは単なる慣行です

1
Sudip Bhandari

もう1つの理由は、（私が正しく覚えていれば）HTTPがインターネットプロトコルの外観/動作方法の「ゴールドスタンダード」としても指定されているため、独自のプロトコルを開発する場合、基本的に（理想的な世界は、少なくとも）すべてのRFCに従った場合、非常によく似たものになります。したがって、世界で最も一般的でよく理解されているプロトコルの1つであるHTTPを使用してみませんか。

0
Stuggi

Simple Object Access Protocolの転送層を選択するのは開発者の責任です。 XMLはネットワークプロトコルではないため、XMLだけを使用してデータを転送することはできません。何かに詰め込む必要があります。

0
Damian Leszczyński - Vash

基本的にSOAPは、XML形式のメッセージの説明を含むWebサービス標準です。そのメッセージ構造は、サービスリクエスタによって呼び出されたWebサービス時に渡されます。 SOAアーキテクチャで最も重要な特性の1つは相互運用性です。SOA SOAPはHTTP/HTTPSを介して渡される大きな役割を果たし、ファイアウォール、DCOM、CORBAなどの他のアーキテクチャを通過できます。 RPCはファイアウォールを通過しません。

0
yogesh wanjari