石鹸

石鹸
状態	アクティブ
初版	1998年6月にXML-RPCとして最初に登場; 26年前
最新バージョン	1.2 ; 2007年4月27日; 17年前
ドメイン	テキストベースのプロトコル
ライセンス	著作権はW3Cが所有し、実装はロイヤリティフリーです
Webサイト	w3.org/TR/soap12/

SOAP は、もともと Simple Object Access Protocol ^[a]の略語で、コンピュータネットワークでのWeb サービスの実装において構造化された情報を交換するためのメッセージングプロトコル仕様です。メッセージ形式にはXML 情報セットを使用し、アプリケーション層プロトコルに依存しています。ほとんどの場合はハイパーテキスト転送プロトコル(HTTP) ですが、一部のレガシーシステムではメッセージのネゴシエーションと送信にSimple Mail Transfer Protocol (SMTP) を介して通信します。

特徴

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

エンベロープはメッセージの構造^[1]とそれを処理する方法を定義する
アプリケーション定義のデータ型のインスタンスを表現するためのエンコード規則のセット
手続きの呼び出しと応答を表す規則

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

拡張性（セキュリティとWS-Addressing は現在開発中の拡張機能です）
中立性（SOAP はHTTP、SMTP、TCP、UDPなどの任意のプロトコル上で動作できます）
独立性（SOAP はあらゆるプログラミングモデルを許可します）

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

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

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

SOAPはXML-RPCの後継として進化しましたが、トランスポートとインタラクションの中立性はWebサービスアドレス指定^[2]から、エンベロープ/ヘッダー/ボディは他の場所(おそらくWDDX )から借用しています。^[要出典]

歴史

SOAPはオブジェクトアクセスプロトコルとして設計され、1998年6月にDave Winer、Don Box、Bob Atkinson、Mohsen Al-GhoseinによってFrontier 5.1の一部としてMicrosoft向けにXML-RPCとしてリリースされました。AtkinsonとAl-GhoseinはMicrosoftで働いていました。^[3]この仕様は1999年9月13日にIETF に提出されるまで公開されませんでした。^[4]^[5] Don Boxによると、これはMicrosoft内の政治的な理由によるものでした。^[6] Microsoftの躊躇により、Dave Winerは1998年にXML-RPCを出荷しました。^[7]

提出されたインターネットドラフトはRFCステータスに達しなかったため、いわゆる「Web 標準」とは見なされません。仕様のバージョン 1.1 は、2000 年 5 月 8 日に W3C ノートとして公開されました。^{[8]バージョン 1.1 は}W3C 勧告ステータスに達しなかったため、「Web 標準」とも見なされません。ただし、仕様のバージョン 1.2 は、2003 年 6 月 24 日にW3C勧告になりました。SOAPはもともと「Simple Object Access Protocol」の略でしたが、標準のバージョン 1.2 ではこの頭字語が削除されました。^[9]

SOAP仕様^[10]は、2009年7月10日にグループが閉鎖されるまで、ワールドワイドウェブコンソーシアムのXMLプロトコルワーキンググループ^{[11]によって保守されていました。}

SOAP は、最初に導入されてから、 WSDL、XSD、UDDIに基づく、より複雑なWeb サービスセットの基盤レイヤーになりました。これらのさまざまなサービス、特に UDDI はあまり関心を集めていませんが、これらを理解することで、Web サービスが実際にどのように進化してきたかと比較して、SOAP に期待される役割を完全に理解することができます。

SOAP用語

SOAP仕様は、プロトコル概念、カプセル化概念、ネットワーク概念という3つの概念的要素から構成されると広く定義できます。^[12]

プロトコルの概念

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

データカプセル化の概念

SOAPメッセージ: 2 つの SOAP ノード間で交換される情報を表します。
SOAP エンベロープ: これは、XML メッセージを SOAP メッセージとして識別する囲み要素です。
SOAP ヘッダーブロック: SOAP ヘッダーには、これらのブロックを複数含めることができます。各ブロックは、ヘッダー内の個別の計算ブロックです。一般に、SOAPロール情報は、パス上のノードをターゲットにするために使用されます。ヘッダーブロックの SOAP ロールが、SOAP ノードが動作するロールの名前である場合、ヘッダーブロックは SOAP ノードをターゲットにしていると言えます。(例: ロール属性がultimateReceiverである SOAP ヘッダーブロックは、このロールを持つ宛先ノードのみをターゲットにします。ロール属性がnextであるヘッダーは、宛先ノードだけでなく各中間ノードもターゲットにします。)
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メッセージの処理ルールを定義する^[15]
SOAP機能とSOAPモジュールの概念を定義するSOAP拡張モデル^[15]
SOAPノード間でSOAPメッセージを交換するために使用できる基礎プロトコルへのバインディングを定義するための規則を記述したSOAP基礎プロトコルバインディングフレームワーク^[15]
SOAPメッセージの構造を定義するSOAPメッセージコンストラクト^[15]

SOAP ビルディングブロック

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

輸送方法

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

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

メッセージ形式

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

金融メッセージングにおいて、SOAPは以前のプロトコルであるFIX（Financial Information Exchange）やCDR（Common Data Representation）よりも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
コンテンツ長:  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:Envelope>

技術批評

利点

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

デメリット

標準実装とデフォルトの SOAP/HTTP バインディングを使用する場合、XML 情報セットは XML としてシリアル化されます。バイナリオブジェクトが埋め込まれた XML の特殊なケースのパフォーマンスを向上させるために、メッセージ転送最適化メカニズムが導入されました。
トランスポートプロトコルとして HTTP を使用し、Web サービスアドレス指定やエンタープライズサービスバスを使用しない場合、対話する当事者の役割は固定されます。一方の当事者 (クライアント) だけが、もう一方の当事者のサービスを使用できます。
SOAP は、名前が示すほど「シンプル」ではありません。プロトコルの冗長性、XML の解析速度の遅さ、標準化された対話モデルの欠如により、HTTPプロトコルをより直接的に使用するサービスが主流になりました。たとえば、REST を参照してください。
SOAP はプロトコルに依存しないため、 REST の Uniform Interfaceやキャッシュなどのプロトコル固有の機能や最適化を活用できず、代わりにそれらを再実装する必要があります ( WS-Addressingの場合など)。

参照

添付ファイル付きSOAP
Java 用 SOAP 添付ファイル API
UDP 経由の SOAP
Web サービスプロトコルのリスト
メッセージ転送最適化メカニズム(MTOM)
XML バイナリ最適化パッケージ(XOP)
拡張ユーザーインターフェイスプロトコル (XUP) – SOAP ベースの UI プロトコル
ウェブソケット
Web サービスセキュリティ
WS-Securityベースの製品とサービス

注記

^ 仕様のバージョン1.2以降、Simple Object Access Protocolの略語ではなくなりました。

参考文献

^ Hirsch, Frederick; Kemp, John; Ilkka, Jani (2007-01-11). モバイル Web サービス: アーキテクチャと実装。John Wiley & Sons (2007 年発行)。p. 27。ISBN 9780470032596. 2014 年 9 月 15 日に取得。Simple Object Access Protocol (SOAP) は、エンベロープの一部 (メッセージ本体) でアプリケーションペイロードを伝送し、別の部分 (メッセージヘッダー) で制御情報を伝送するように設計されたメッセージエンベロープ構造を定義します。
^ 「Web Services Addressing (WS-Addressing)」www.w3.org。2016年9月25日時点のオリジナルよりアーカイブ。2016年9月15日閲覧。
^ 「.NET Developer's Journal "Indigo" 独占インタビュー、Microsoft の Don Box 氏」。Dotnet.sys-con.com。2019 年 1 月 6 日時点のオリジナルよりアーカイブ。2012年 10 月 4 日閲覧。
^ 「SOAP の歴史に関する XML カバーページ」。Coverpages.org。2001 年 3 月 3 日時点のオリジナルからアーカイブ。2003年 7 月 22 日閲覧。
^ 「SOAP: Simple Object Access Protocol」。Ietf Datatracker。1999年9月。2021年2月25日時点のオリジナルよりアーカイブ。 2015年9月20日閲覧。
^ 「Don Box による SOAP の歴史」 XML.com. 2001-04-04。2015-06-18 にオリジナルからアーカイブ。2015-09-20に取得。
^ 「XML-RPC for Newbies」 1998-07-14. 1999年10月12日時点のオリジナルよりアーカイブ。
^ 「W3C Note on Simple Object Access Protocol (SOAP) 1.1」。W3C。2000年5月8日。2021年3月4日時点のオリジナルよりアーカイブ。 2015年9月20日閲覧。
^ 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。W3C。2007年 4 月 27 日。2012 年 6 月 19 日にオリジナルからアーカイブ。2012年 6 月 15 日に取得。注: この仕様の以前のバージョンでは、SOAP 名は頭字語でした。これはもう当てはまりません。(セクション 1. はじめにの下)
^ 「SOAP仕様」。W3C。2021年4月15日時点のオリジナルよりアーカイブ。2014年3月29日閲覧。
^ 「W3C XML Protocol Working Group」。W3C。2018年12月25日時点のオリジナルよりアーカイブ。2014年3月29日閲覧。
^ 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。www.w3.org。2016年 9 月 20 日時点のオリジナルよりアーカイブ。2016年 9 月 14 日閲覧。
^ 「Binding Framework Proposal」www.w3.org。2017年7月11日時点のオリジナルよりアーカイブ。2016年9月14日閲覧。
^ 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。www.w3.org。2016年 9 月 20 日時点のオリジナルよりアーカイブ。2016年 9 月 14 日閲覧。
^ abcd 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。www.w3.org。2017年 4 月 2 日時点のオリジナルよりアーカイブ。2020年 6 月 24 日閲覧。
^ 「IBM Datapower」。306.ibm.com。2011年11月30日。2008年6月22日時点のオリジナルよりアーカイブ。2012年10月4日閲覧。
^ 「IBM Zurich XML Accelerator Engine」(PDF) 。 2012年9月30日時点のオリジナル(PDF)からアーカイブ。 2012年10月4日閲覧。
^ 「高性能ビジネスアプリケーション向け SOAP の評価: リアルタイム取引システム」。Tenermerx Pty Ltd University of Technology、シドニー。2011 年 11 月 30 日。2013 年 8 月 10 日時点のオリジナルよりアーカイブ。2013年 3 月 14 日閲覧。
^ 「SOAP over JMS プロトコル」。IBM。2020年3月22日時点のオリジナルよりアーカイブ。2020年3月22日閲覧。
^ 「SOAP-JMS FAQ」。SOAP-JMS バインディングワーキンググループ。2017 年 7 月 17 日時点のオリジナルよりアーカイブ。2020年3 月 22 日閲覧。

さらに読む

Benoît Marchal、「Soapbox: 私が SOAP を使用する理由」、IBM
Uche Ogbuji、「チュートリアル: SOAP を使用した XML メッセージング」、主任コンサルタント、Fourthought, Inc.

外部リンク

W3C SOAP ページ
SOAP バージョン 1.2 仕様
JavaでSOAPメッセージを作成する

[1] 仕様のバージョン1.2以降、Simple Object Access Protocolの略語ではなくなりました。

[2] Hirsch, Frederick; Kemp, John; Ilkka, Jani (2007-01-11). モバイル Web サービス: アーキテクチャと実装。John Wiley & Sons (2007 年発行)。p. 27。ISBN 9780470032596. 2014 年 9 月 15 日に取得。Simple Object Access Protocol (SOAP) は、エンベロープの一部 (メッセージ本体) でアプリケーションペイロードを伝送し、別の部分 (メッセージヘッダー) で制御情報を伝送するように設計されたメッセージエンベロープ構造を定義します。

[3] 「Web Services Addressing (WS-Addressing)」www.w3.org。2016年9月25日時点のオリジナルよりアーカイブ。2016年9月15日閲覧。

[4] 「.NET Developer's Journal "Indigo" 独占インタビュー、Microsoft の Don Box 氏」。Dotnet.sys-con.com。2019 年 1 月 6 日時点のオリジナルよりアーカイブ。2012年 10 月 4 日閲覧。

[5] 「SOAP の歴史に関する XML カバーページ」。Coverpages.org。2001 年 3 月 3 日時点のオリジナルからアーカイブ。2003年 7 月 22 日閲覧。

[6] 「SOAP: Simple Object Access Protocol」。Ietf Datatracker。1999年9月。2021年2月25日時点のオリジナルよりアーカイブ。 2015年9月20日閲覧。

[7] 「Don Box による SOAP の歴史」 XML.com. 2001-04-04。2015-06-18 にオリジナルからアーカイブ。2015-09-20に取得。

[8] 「XML-RPC for Newbies」 1998-07-14. 1999年10月12日時点のオリジナルよりアーカイブ。

[9] 「W3C Note on Simple Object Access Protocol (SOAP) 1.1」。W3C。2000年5月8日。2021年3月4日時点のオリジナルよりアーカイブ。 2015年9月20日閲覧。

[10] 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。W3C。2007年 4 月 27 日。2012 年 6 月 19 日にオリジナルからアーカイブ。2012年 6 月 15 日に取得。注: この仕様の以前のバージョンでは、SOAP 名は頭字語でした。これはもう当てはまりません。(セクション 1. はじめにの下)

[11] 「SOAP仕様」。W3C。2021年4月15日時点のオリジナルよりアーカイブ。2014年3月29日閲覧。

[12] 「W3C XML Protocol Working Group」。W3C。2018年12月25日時点のオリジナルよりアーカイブ。2014年3月29日閲覧。

[13] 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。www.w3.org。2016年 9 月 20 日時点のオリジナルよりアーカイブ。2016年 9 月 14 日閲覧。

[14] 「Binding Framework Proposal」www.w3.org。2017年7月11日時点のオリジナルよりアーカイブ。2016年9月14日閲覧。

[15] 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。www.w3.org。2016年 9 月 20 日時点のオリジナルよりアーカイブ。2016年 9 月 14 日閲覧。

[auto-16] 「SOAP バージョン 1.2 パート 1: メッセージングフレームワーク (第 2 版)」。www.w3.org。2017年 4 月 2 日時点のオリジナルよりアーカイブ。2020年 6 月 24 日閲覧。

[17] 「IBM Datapower」。306.ibm.com。2011年11月30日。2008年6月22日時点のオリジナルよりアーカイブ。2012年10月4日閲覧。

[18] 「IBM Zurich XML Accelerator Engine」(PDF) 。 2012年9月30日時点のオリジナル(PDF)からアーカイブ。 2012年10月4日閲覧。

[19] 「高性能ビジネスアプリケーション向け SOAP の評価: リアルタイム取引システム」。Tenermerx Pty Ltd University of Technology、シドニー。2011 年 11 月 30 日。2013 年 8 月 10 日時点のオリジナルよりアーカイブ。2013年 3 月 14 日閲覧。

[20] 「SOAP over JMS プロトコル」。IBM。2020年3月22日時点のオリジナルよりアーカイブ。2020年3月22日閲覧。

[21] 「SOAP-JMS FAQ」。SOAP-JMS バインディングワーキンググループ。2017 年 7 月 17 日時点のオリジナルよりアーカイブ。2020年3 月 22 日閲覧。