石鹸

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
石鹸
Webサービスxrpc.png
家族メッセージングプロトコル
によって設計されたデーブ・ワイナードン・ボックス、ボブ・アトキンソン、モーセン・アル・ゴセイン
初登場1998年6月にXML-RPCとして最初に; 23年前 (1998年6月
安定したリリース
1.2 / 2007年4月27日; 14年前 (2007-04-27)

SOAP(旧称の頭文字をとったシンプルオブジェクトアクセスプロトコルは)メッセージであるプロトコルの実装で構造化情報を交換するための仕様のWebサービスでのコンピュータネットワークメッセージ形式XML情報セット使用しアプリケーション層プロトコル、ほとんどの場合ハイパーテキスト転送プロトコル(HTTP)に依存しますが、一部のレガシーシステムはメッセージのネゴシエーションと送信のためにSMTP(Simple Mail Transfer Protocol)を介して通信します。

SOAPを使用すると、開発者は、異なるオペレーティングシステム(WindowsmacOSLinuxなど)で実行されているプロセスを呼び出して、Extensible Markup Language(XML)を使用して認証、承認、および通信できます。HTTPなどのWebプロトコルがすべてのオペレーティングシステムにインストールされて実行されているため、SOAPを使用すると、クライアントは言語やプラットフォームに関係なくWebサービスを呼び出して応答を受け取ることができます。

特徴

SOAPは、Webサービス用のWebサービスプロトコルスタックのメッセージングプロトコル層を提供します。これは、次の3つの部分で構成されるXMLベースのプロトコルです。

  • メッセージ構造[1]とその処理方法を定義するエンベロープ
  • アプリケーション定義のデータ型のインスタンスを表現するための一連のエンコーディングルール
  • プロシージャの呼び出しと応答を表すための規則

SOAPには3つの主要な特徴があります。

  1. 拡張性(セキュリティとWS-Addressingは開発中の拡張機能の1つです)
  2. 中立性(SOAPは、HTTPSMTPTCPUDPなどの任意のプロトコルで動作できます
  3. 独立性(SOAPは任意のプログラミングモデルを可能にします

SOAPプロシージャで実行できることの例として、アプリケーションは、検索用のパラメータを使用して、Webサービスが有効になっているサーバー(不動産価格データベースなど)にSOAP要求を送信できます。次に、サーバーは、SOAP応答(結果のデータを含むXML形式のドキュメント)(価格、場所、機能など)を返します。生成されたデータは標準化されたマシン解析可能な形式で提供されるため、要求元のアプリケーションはそれを直接統合できます。

SOAPアーキテクチャは、次の仕様のいくつかの層で構成されています。

  • メッセージ形式
  • メッセージ交換パターン(MEP)
  • 基礎となるトランスポートプロトコルバインディング
  • メッセージ処理モデル
  • プロトコルの拡張性

SOAPはXML-RPCの後継として進化しましたが、そのトランスポートと相互作用の中立性をWeb Service Addressing [2]から、エンベロープ/ヘッダー/ボディを他の場所(おそらくWDDXからから借用しています。[要出典]

歴史

SOAPは、オブジェクトアクセスプロトコルとして設計され、1998年6月にDave Winer Don Box、Bob Atkinson、およびAtkinsonとAl-Ghoseinが働いていたMicrosoftのMohsenAl-GhoseinによってFrontier5.1の一部としてXML-RPCとしてリリースされました。[3] 仕様は、1999年9月13日IETFに提出されるまで利用可能になりませんでした[4] [5] Don Boxによると、これはMicrosoft内の政治によるものでした。[6] Microsoftの躊躇のため、DaveWinerは1998年にXML-RPC出荷しました。[7]

提出されたインターネットドラフトRFCステータスに達しいないため、「Web標準」とは見なされません。仕様のバージョン1.1は、2000年5月8日にW3Cノートとして公開されました。[8]バージョン1.1はW3C勧告ステータスに達していないため、「Web標準」と見なすこともできません。ただし、仕様のバージョン1.2は、2003年6月24日にW3C勧告になりました

SOAP仕様[9]World Wide WebコンソーシアムのXMLプロトコルワーキンググループ[10]によって、グループが2009年7月10日に閉鎖されるまで維持されていました。SOAPは元々「SimpleObject Access Protocol」の略でしたが、標準のバージョン1.2ではこれが削除されました。頭字語。[11]

SOAPが最初に導入された後、SOAPはWebサービス記述言語(WSDL)、XMLスキーマ 、およびUDDI(Universal Description Discovery and Integration)に基づいた、より複雑なWebサービスのセットの基礎となるレイヤーになりましたこれらのさまざまなサービス、特にUDDIはあまり関心がないことが証明されていますが、それらを理解することで、Webサービスが実際にどのように進化したかと比較してSOAPの期待される役割を完全に理解できます。

SOAP用語

SOAP仕様は、プロトコルの概念、カプセル化の概念、およびネットワークの概念の3つの概念コンポーネントで構成されるように広く定義できます。[12]

プロトコルの概念

石鹸
これは、SOAP送信者とSOAP受信者の間で交換される情報の形式と処理ルールを形式化および管理する一連のルールです。
SOAPノード
これらは、SOAPメッセージの送信/転送、受信、および処理に使用される処理ユニットを備えた物理/論理マシンです。これらは、ネットワーク内のノード類似しています。
SOAPロール
SOAPメッセージのパスを介して、すべてのノードが特定の役割を引き受けます。ノードの役割は、ノードが受信したメッセージに対して実行するアクションを定義します。たとえば、ロール「none」は、どのノードもSOAPヘッダーを処理せず、単にそのパスに沿ってメッセージを送信することを意味します。
SOAPプロトコルバインディング
SOAPメッセージは、ネットワークを介して転送される他のプロトコルと連携して機能する必要があります。たとえば、SOAPメッセージは、メッセージを転送するための下位層プロトコルとしてTCP使用できます。これらのバインディングは、SOAPプロトコルバインディングフレームワークで定義されています。[13]
SOAP機能
SOAPはメッセージングフレームワークのみを提供します。ただし、信頼性、セキュリティなどの機能を追加するように拡張できます。SOAPフレームワークに機能を追加するときに従う必要のあるルールがあります。
SOAPモジュール
SOAPで拡張される新機能を説明するためのSOAPヘッダーのセマンティクスに関する仕様のコレクション。モジュールは、0個以上の機能を実現する必要があります。SOAPでは、モジュールが所定のルールに準拠する必要があります。[14]

データカプセル化の概念

SOAPメッセージ
2つのSOAPノード間で交換される情報を表します。
SOAPエンベロープ
これは、SOAPメッセージとして識別するXMLメッセージの囲み要素です。
SOAPヘッダーブロック
SOAPヘッダーには、これらのブロックを複数含めることができ、それぞれがヘッダー内の個別の計算ブロックになります。一般に、SOAPロール情報は、パス上のノードをターゲットにするために使用されます。ヘッダーブロックのSOAPロールがSOAPノードが動作するロールの名前である場合、ヘッダーブロックはSOAPノードをターゲットにしていると言われます。(例:ultimateReceiverとしてロール属性を持つSOAPヘッダーブロックは、このロールを持つ宛先ノードのみを対象としています。次のロール属性を持つヘッダーは、各仲介者と宛先ノードを対象としています。)
SOAPヘッダー
各SOAPレシーバーを対象とした1つ以上のヘッダーブロックのコレクション。
SOAP本体
SOAPレシーバー向けのメッセージの本文が含まれています。SOAP本体の解釈と処理は、ヘッダーブロックによって定義されます。
SOAP障害
SOAPノードがSOAPメッセージの処理に失敗した場合、SOAPノードは障害情報をSOAP障害要素に追加します。この要素は、子要素としてSOAP本体に含まれています。

メッセージの送信者と受信者の概念

SOAP送信者
SOAPメッセージを送信するノード。
SOAPレシーバー
SOAPメッセージを受信するノード。(中間ノードまたは宛先ノードである可能性があります)。
SOAPメッセージパス
SOAPメッセージが宛先ノードに到達するために通過したすべてのノードで構成されるパス。
最初のSOAP送信者
これは、送信されるSOAPメッセージを発信したノードです。これは、SOAPメッセージパスのルートです。
SOAP仲介者
SOAP発信元と目的のSOAP宛先の間にあるすべてのノード。対象となるSOAPヘッダーブロックを処理し、SOAPメッセージを最終的なSOAPレシーバーに転送するように機能します。
究極のSOAPレシーバー
SOAPメッセージの宛先受信者。このノードは、メッセージ本文とそれを対象とするヘッダーブロックの処理を担当します。

仕様

SOAP構造

SOAP仕様は、以下で構成されるメッセージングフレームワークを定義します。

  • SOAP処理モデル、SOAPメッセージを処理するためのルールを定義する[15]
  • SOAP拡張性モデルSOAP機能およびSOAPモジュールの概念を定義する[15]
  • プロトコルバインディング基礎となるSOAP SOAPノード間のSOAPメッセージを交換するために使用することができる基礎となるプロトコルへの結合を定義するためのルールを記述したフレームワークを[15]
  • SOAPメッセージ構築SOAPメッセージの構造を定義する[15]

SOAPビルディングブロック

SOAPメッセージは、次の要素を含む通常のXMLドキュメントです。

エレメント 説明 必須
封筒 XMLドキュメントをSOAPメッセージとして識別します。 はい
ヘッダ ヘッダー情報が含まれています。 番号
コールアンドレスポンス情報が含まれています。 はい
障害 メッセージの処理中に発生したエラーに関する情報を提供します。 番号

輸送方法

SMTPHTTPどちらもSOAPのトランスポートとして使用される有効なアプリケーション層プロトコルですが、HTTPは今日のインターネットインフラストラクチャでうまく機能するため、広く受け入れられています。具体的には、HTTPはネットワークファイアウォールでうまく機能しますSOAPは、HTTPS(アプリケーションレベルではHTTPと同じプロトコルですが、その下で暗号化されたトランスポートプロトコルを使用します)を介して、単純認証または相互認証のいずれかで使用することもできますこれは、WS-I Basic Profile 1.1記載されているように、Webサービスセキュリティを提供するため推奨されているWS-Iメソッドです。

これは、通常ファイアウォールでフィルタリングされるGIOP / IIOPDCOMなどの他の分散プロトコルに比べて大きな利点です。一部の実装でサポートされているもう1つの可能性は、SOAP overAMQPです。また、SOAPには、送信ノードと受信ノードの両方の知識を必要とするマシンに構成されたセキュリティ権限の影響を受けないというDCOMより優れた利点があります。これにより、DCOMでは不可能な方法でSOAPを緩く結合できますあり、SOAP-オーバーUDP OASISの標準は。

メッセージフォーマット

XML情報セットは、大企業で広く使用されており、オープンソース開発の取り組みが行われているため、標準のメッセージ形式として選択されました。通常、XML情報セットはXMLとしてシリアル化さます。さまざまな無料で利用できるツールにより、SOAPベースの実装への移行が大幅に容易になります。XMLの構文やや長いことは、メリットとデメリットの両方になる可能性があります。人間の可読性を促進し、エラー検出を容易にし、バイトオーダー(エンディアンなどの相互運用性の問題を回避しますが、処理速度が低下し、煩雑になる可能性があります。たとえば、CORBAGIOPICE、およびDCOMは、はるかに短いバイナリメッセージ形式を使用します。一方、XMLメッセージの処理を高速化するためにハードウェアアプライアンスを利用できます。[16] [17] XMLのスループット要件を合理化する手段として、バイナリXMLも検討されています。自己文書化の性質によるXMLメッセージは、通常、オーバーヘッドがメッセージ全体の比較的小さな割合であった以前のプロトコルとは対照的に、実際のデータよりも多くの「オーバーヘッド」(ヘッダー、ネストされたタグ、区切り文字など)を持っています。

財務メッセージングでは、SOAPは、以前のプロトコルFIX(財務情報交換)およびCDR(共通データ表現)よりも2〜4倍大きいメッセージをもたらすことがわかりました[18]

XML情報セットをXMLでシリアル化する必要はありません。例えば、CSVとJSON、XML情報セット表現が存在します。また、一般的な変換フレームワークを指定する必要もありません。SOAPバインディングの概念により、特定のアプリケーションの特定のバインディングが可能になります。欠点は、送信者と受信者の両方がこの新しく定義されたバインディングをサポートする必要があることです。

メッセージの例(HTTPにカプセル化)

以下のメッセージは、AT&Tの株価を要求しています(株式相場記号「T」)。

POST  / InStock  HTTP / 1.1
ホスト www.example.org
コンテンツタイプ application / soap + xml; charset = utf-8 
Content-Length  299 
SOAPAction  "http://www.w3.org/2003/05/soap-envelope"

<?xml version = "1.0"?> 
<soap:Envelope  xmlns:soap = "http://www.w3.org/2003/05/soap-envelope"  xmlns:m = "http://www.example。 org " > 
  <soap:Header> 
  </ soap:Header> 
  <soap:Body> 
    <m:GetStockPrice> 
      <m:StockName> T </ m:StockName> 
    </ m:GetStockPrice> 
  </ soap:Body> 
</石鹸:エンベロープ>

技術批評

利点

  • SOAPの中立性の特性により、SOAPはあらゆるトランスポートプロトコルでの使用に明確に適しています。実装では、トランスポートプロトコルとしてHTTPを使用することがよくありますが、他の一般的なトランスポートプロトコルを使用することもできます。たとえば、SOAPは、SMTP、JMS [19] [20]、およびメッセージキューでも使用できます
  • SOAPをHTTPポスト/レスポンス交換と組み合わせると、既存のファイアウォールとプロキシを簡単にトンネリングできるため、HTTPポスト/レスポンス交換を処理するために存在する広範なコンピューティングおよび通信インフラストラクチャを変更する必要がありません。
  • SOAPは、XML名前空間を使用した簡単な国際化や拡張性など、XMLのすべての機能を利用できます。

短所

  • 標準実装とデフォルトのSOAP / HTTPバインディングを使用する場合、XML情報セットはXMLとしてシリアル化されます。バイナリオブジェクトが埋め込まれたXMLの特殊なケースのパフォーマンスを向上させるために、メッセージ送信最適化メカニズムが導入されました。
  • トランスポートプロトコルとしてHTTPに依存し、Web ServicesAddressingまたはEnterpriseService Busを使用しない場合、相互作用するパーティの役割は固定されています。一方の当事者(クライアント)のみが他方のサービスを使用できます。
  • SOAPは、名前が示すほど「単純」ではありません。プロトコルの冗長性、XMLの解析速度の遅さ、および標準化された対話モデルの欠如により、HTTPプロトコルをより直接的に使用するサービスが優勢になりましたたとえば、RESTを参照してください

も参照してください

参考文献

  1. ^ ヒルシュ、フレデリック; ケンプ、ジョン; イルッカ、ジャニ(2007-01-11)。モバイルWebサービス:アーキテクチャと実装John Wiley&Sons(2007年発行)。NS。27. ISBN  9780470032596取得した2014年9月15日をSimple Object Access Protocol(SOAP)は、エンベロープの一部(メッセージ本文)でアプリケーションペイロードを伝送し、別の部分(メッセージヘッダー)で情報を制御するように設計されたメッセージングエンベロープ構造を定義します。
  2. ^ 「Webサービスアドレッシング(WS-アドレッシング)」www.w3.org 2016年915日取得
  3. ^ 「独占的な.NET開発者ジャーナル「インディゴ」マイクロソフトのドンボックスへのインタビュー」Dotnet.sys-con.com 2012年10月4日取得
  4. ^ 「SOAPの歴史に関するXML表紙」Coverpages.org 2003年7月22日取得
  5. ^ 「SOAP:単純なオブジェクトアクセスプロトコル」1999年9月。
  6. ^ 「SOAPの歴史に関するドンボックス」XML.com。2001-04-04。
  7. ^ 「初心者のためのXML-RPC」1998-07-14。1999年10月12日にオリジナルからアーカイブされまし
  8. ^ 「SimpleObjectAccess Protocol(SOAP)1.1に関するW3Cノート」W3C。2000-05-08。
  9. ^ 「SOAP仕様」W3C 2014年329日取得
  10. ^ 「W3CXMLプロトコルワーキンググループ」W3C 2014年329日取得
  11. ^ 「SOAPバージョン1.2パート1:メッセージングフレームワーク(第2版)」W3C2007年4月27日2012年6月15日取得注:この仕様の以前のバージョンでは、SOAP名は頭字語でした。これはもはや当てはまりません。(セクション1の下。はじめに)
  12. ^ 「SOAPバージョン1.2パート1:メッセージングフレームワーク(第2版)」www.w3.org 2016年914日取得
  13. ^ 「バインディングフレームワークの提案」www.w3.org 2016年914日取得
  14. ^ 「SOAPバージョン1.2パート1:メッセージングフレームワーク(第2版)」www.w3.org 2016年914日取得
  15. ^ a b c d 「SOAPバージョン1.2パート1:メッセージングフレームワーク(第2版)」www.w3.org
  16. ^ 「IBMDatapower」306.ibm.com。2011-11-30 2012年10月4日取得
  17. ^ 「IBMチューリッヒXMLアクセラレータエンジン」(PDF)2012年10月4日取得
  18. ^ 「高性能ビジネスアプリケーションのためのSOAPの評価:リアルタイム取引システム」Tenermerx Pty Ltd工科大学、シドニー。2011-11-30 取得した2013年3月14日を
  19. ^ 「SOAPoverJMSプロトコル」IBM 2020年3月22日取得
  20. ^ 「SOAP-JMSFAQ」SOAP-JMSバインディングワーキンググループ2020年3月22日取得

さらに読む

外部リンク