Cover Page for the Japanese Translation

WS-I

Basic Profile Version 1.0a

Final Specification

Date: 2003/08/08 17:00:01

Editors:
Keith Ballinger, Microsoft
David Ehnebuske, IBM
Martin Gudgin, Microsoft
Mark Nottingham, BEA Systems
Prasad Yendluri, webMethods
Administrative contact:
secretary@ws-i.org
Translator (日本語訳):
NUMATA Toshinori, Fujitsu Limited / 沼田 利典 (富士通株式会社)
Translation Reviewers (日本語訳レビュー):
IWAMOTO Yukio, Beacon IT Inc. / 岩本 幸男 (株式会社ビーコンIT)
FUJITA Satoru, NEC Corporation / 藤田 悟 (日本電気株式会社)
SATO Yoshihiro, NEC Corporation / 佐藤 佳宏 (日本電気株式会社)
SUZUKI Toshihiro, Oracle Corporation Japan / 鈴木 俊宏 (日本オラクル株式会社)
TODA Ryuichiro, Nomura Research Institute / 戸田 隆一郎 (株式会社野村総合研究所)
YAMAMOTO Yohei, Ricoh Company, Ltd. / 山本 陽平 (株式会社リコー)

Copyright © 2002-2003 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members.  All Rights Reserved.

This document is a translation of a Web Services-Interoperability Organization document. In the event of a disagreement between this translation and the English version, or an omission in this translation, the original English document should be considered the definitive source.

この文書は Web Services-Interoperability Organization (WS-I) の文書の翻訳である。 この翻訳と英語版との間に食い違いがあった場合,又は,翻訳に省略がある場合,原文の英語文書が決定版として扱われるべきである。



WS-I

Basic Profile Version 1.0a

Final Specification

Date: 2003/08/08 17:00:01

This revision:
http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.html
Editors:
Keith Ballinger, Microsoft
David Ehnebuske, IBM
Martin Gudgin, Microsoft
Mark Nottingham, BEA Systems
Prasad Yendluri, webMethods
Administrative contact:
secretary@ws-i.org

Copyright © 2002-2003 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members.  All Rights Reserved.


Abstract (概要)

この文書は WS-I Basic Profile 1.0 を定義する。WS-I Basic Profile 1.0 は非占有的 (non-proprietary) な Web サービス仕様で構成され,相互運用性を向上させる仕様の明確化を含んでいる。

Status of this Document (この文書の位置付け)

これは最終仕様 (final specification) である。 正誤表又は更新版については,WS-I.org のサイトを参照のこと。

Notice (通告)

ここに含まれる内容は,この内容の著者若しくは開発者又は WS-I が所有又は管理する知的財産権に対するライセンスを,明示的にも暗示的にも示すものではない。 ここに含まれる内容はそのまま (AS IS) の形式で提供され,適用可能な法律に許される最大限の範囲において,そのままの形で欠陥を含んだまま (AS IS AND WITH ALL FAULTS) 提供される。 この内容の著者及び開発者並びに WS-I は,ここに,明示的,暗示的,又は法定による, 市場性,特定目的への適用性,応答の精度若しくは完全性,結果,職人的努力,ウィルスがないこと,又は過失のないことについての, 暗示的な保証,義務又は条件を含む (しかし,それに限定されない), その他すべての保証及び条件を否認する。 さらに, この内容に関する権利,安全な居住,安全な所有,記述への対応又は侵害不在性について,いかなる保証又は条件も存在しない。

この内容の著者若しくは開発者又は WS-I のいずれも, 他者に対して, 損害の可能性の事前通告の有無にかかわらず, これ又はこの内容についてのその他のいかなる合意によって起こされる損害に対して, 契約,不法行為,保証その他による, 代替する物資若しくは服務の購入,逸失利益,用途損失,データ損害,又はいかなる偶発的,結果的,直接,間接,若しくは特別な損害を補償する責任を持たない。

Feedback (フィードバック)

可能な限り最良の相互運用性ガイドを提供するため, この仕様に不明確な点がある場合や,誤り又は抜けが発見された場合, WS-I に連絡されたい。

メールの送信又はその他の手段で WS-I に対して通信することによって,あなた (個人を代表する場合はあなた自身,会社を代表してフィードバックを送る場合はあなたの会社) は,WS-I, WS-I のメンバー及びその他あなたのフィードバックをアクセスできる者に対して,この文書についてあなたが提供するフィードバックに対する,使用,公開,複写,ライセンス,修正,サブライセンス,その他いかなる形式による配布及び活用に対しても,非制限的で,譲渡不可能な,国際的で,永続的で,取り消し不可能な,ロイヤリティなしのライセンスを許諾するものとみなされる。 あなたは,あなたが提供するいかなるフィードバックに対しても,秘匿性についていかなる期待ももたないことに同意しなければならない。 あなたは,あなたがフィードバックを送る権利をもつことを表明し,保証しなければならない。あなたが会社を代表してフィードバックを送る場合,あなたが会社を代表してフィードバックを送る権利をもつことを表明し,保証しなければならない。 WS-I には,この文書の将来の版において,あなたのフィードバックの一部又は全部をレビューし,議論し,使用し,検討し,あるいはいかなる方法においても取り入れる義務はないということも,あなたは同意しなければならない。WS-I がこの文書の将来の版にあなたのフィードバックの一部又は全部を取り入れる場合,WS-I は,この文書の貢献者のリストにあなたの名前 (又は,あなたが会社を代表する場合には,会社の名前) を入れるかもしれないが,そうする義務はない。 上記の内容があなた又はあなたが代表する会社にとって受け入れられない場合,いかなるフィードバックも送らないでほしい。

この文書に対するフィードバックは wsbasic_comment@ws-i.org に送ること。


Table of Contents (目次)

1. Introduction (序文)
1.1 Guiding Principles (基本理念)
1.2 Notational Conventions (表記)
2. Scope of the Profile (プロファイルの適用範囲)
3. Profile Conformance (プロファイルに対する適合性)
3.1 Conformance of Artifacts (対象物の適合性)
3.2 Conformance of Services, Consumers and Registries (サービス,利用者及びレジストリーの適合性)
3.3 Conformance Annotation in Descriptions (記述における適合性注記)
3.4 Conformance Annotation in Messages (メッセージにおける適合性注記)
3.5 Conformance Annotation in Registry Data (レジストリーデータにおける適合性注記)
4. Messaging (メッセージング)
4.1 XML Representation of SOAP Messages (SOAP メッセージの XML 表現)
4.1.1 SOAP Messages and the Unicode BOM (SOAP メッセージと Unicode の BOM)
4.1.2 SOAP Fault Syntax (SOAP フォルトの構文)
4.1.3 SOAP Faults and Namespaces (SOAP フォルトと名前空間)
4.1.4 SOAP Fault Extensibility (SOAP フォルトの拡張性)
4.1.5 SOAP Fault Language (SOAP フォルトの言語)
4.1.6 SOAP Custom Fault Codes (SOAP の独自フォルトコード)
4.1.7 SOAP encodingStyle Attribute (SOAP の encodingStyle 属性)
4.1.8 SOAP's use of XML (SOAP での XML の使用)
4.1.9 SOAP and XML Declarations (SOAP と XML 宣言)
4.1.10 SOAP Trailers (SOAP 後続要素)
4.1.11 Acceptable SOAP Character Encodings (許容可能な SOAP 文字エンコーディング)
4.1.12 SOAP mustUnderstand Attribute (SOAP mustUnderstand 属性)
4.1.13 SOAP Body and Namespaces (SOAP Body と名前空間)
4.1.14 SOAP Envelope Namespace (SOAP Envelope の名前空間)
4.1.15 Use of xsi:type Attributes (xsi:type 属性の使用)
4.2 SOAP Processing Model (SOAP 処理モデル)
4.2.1 Mandatory Headers (必須ヘッダー)
4.2.2 Generating mustUnderstand Faults (MustUnderstand フォルトの生成)
4.2.3 SOAP Fault Processing (SOAP フォルトの処理)
4.3 Use of SOAP in HTTP (HTTP での SOAP の使用)
4.3.1 HTTP Versions (HTTP のバージョン)
4.3.2 Identifying SOAP Faults (SOAP フォルトの識別)
4.3.3 HTTP Methods and Extensions (HTTP のメソッドと拡張)
4.3.4 SOAPAction Header Syntax (SOAPAction ヘッダーの構文)
4.3.5 HTTP and TCP Ports (HTTP と TCP のポート番号)
4.3.6 HTTP Success Status Codes (HTTP の成功状態コード)
4.3.7 HTTP Redirect Status Codes (HTTP の転送状態コード)
4.3.8 HTTP Client Error Status Codes (HTTP のクライアントエラー状態コード)
4.3.9 HTTP Server Error Status Codes (HTTP のサーバーエラー状態コード)
4.3.10 HTTP Cookies (HTTP クッキー)
5. Service Description (サービス記述)
5.1 Document Structure (文書構造)
5.1.1 WSDL Schema Definitions (WSDL スキーマ定義)
5.1.2 WSDL and Schema Import (WSDL とスキーマの import)
5.1.3 WSDL Import location Attribute Syntax (WSDL import の location 属性の構文)
5.1.4 WSDL Import location Attribute Semantics (WSDL import の location 属性の意味)
5.1.5 Placement of WSDL import Elements (WSDL import 要素の位置)
5.1.6 XML Version Requirements (XML 版数の要件)
5.1.7 WSDL and the Unicode BOM (WSDL と Unicode の BOM)
5.1.8 Acceptable WSDL Character Encodings (許容可能な WSDL 文字エンコーディング)
5.1.9 Namespace Coercion (名前空間の強制変更)
5.1.10 WSDL documentation Element (WSDL の documentation 要素)
5.1.11 WSDL Extensions (WSDL 拡張)
5.2 Types (型)
5.2.1 QName References (QName 参照)
5.2.2 Schema targetNamespace Syntax (スキーマの targetNamespace 構文)
5.2.3 soapenc:Array (配列)
5.2.4 WSDL and Schema Definition Target Namespaces (WSDL とスキーマ定義の対象名前空間)
5.3 Messages (メッセージ)
5.3.1 Bindings and Parts (バインディングと part)
5.3.2 Bindings and Faults (バインディングとフォルト)
5.3.3 Unbound portType Element Contents (バインディングされていない portType 要素の内容)
5.3.4 Declaration of part Elements (part 要素の宣言)
5.4 Port Types (ポート型)
5.4.1 Ordering of part Elements (part の並び順)
5.4.2 Allowed operations (許容されるオペレーション)
5.4.3 Distinctive operations (区別できるオペレーション)
5.4.4 parameterOrder Attribute Construction (parameterOrder 属性の構築)
5.4.5 Exclusivity of type and element Attributes (type 及び element 属性の排他性)
5.5 Bindings (バインディング)
5.5.1 Use of SOAP Binding (SOAP バインディングの使用)
5.6 SOAP Binding (SOAP バインディング)
5.6.1 Specifying the transport Attribute (transport 属性の指定)
5.6.2 HTTP Transport (HTTP トランスポート)
5.6.3 Consistency of style Attribute (style 属性の整合性)
5.6.4 Encodings and the use Attribute (エンコーディングと use 属性)
5.6.5 Default for use Attribute (use 属性のデフォルト)
5.6.6 Multiple bindings for portType Elements (portType 要素への複数のバインディング)
5.6.7 Wire Signatures for operations (オペレーションの伝送路シグネチャ)
5.6.8 Multiple ports on an Endpoint (一つのエンドポイントに対する複数の port)
5.6.9 Child Element for Document-Literal Bindings (document-literal バインディングの子要素)
5.6.10 One-Way Operations (one-way オペレーション)
5.6.11 Namespaces for soapbind Elements (soapbind 要素の名前空間)
5.6.12 Consistency of portType and binding Elements (portType 及び binding 要素の整合性)
5.6.13 Describing headerfault Elements (headerfault 要素の記述)
5.6.14 Enumeration of Faults (フォルトの列挙)
5.6.15 Type and Name of SOAP Binding Elements (SOAP バインディング要素の型と名前)
5.6.16 name Attribute on Faults (fault の name 属性)
5.6.17 Omission of the use Attribute (use 属性の省略)
5.6.18 Consistency of Messages with Descriptions (メッセージと記述との整合性)
5.6.19 Response Wrappers (レスポンスのラッパー)
5.6.20 Namespace for Part Accessors (part アクセサーの名前空間)
5.6.21 Namespaces for Children of Part Accessors (part アクセサーの子要素の名前空間)
5.6.22 Required Headers (必須のヘッダー)
5.6.23 Allowing Undescribed Headers (記述にないヘッダーの許容)
5.6.24 Ordering Headers (ヘッダーの並び順)
5.6.25 Describing SOAPAction (SOAPAction の記述)
5.6.26 SOAP Binding Extensions (SOAP バインディング拡張)
5.7 Use of XML Schema (XML Schema の使用)
6. Service Publication and Discovery (サービスの公開と発見)
6.1 bindingTemplates (bindingTemplate)
6.2 tModels (tModel)
7. Security (セキュリティ)
7.1 Use of HTTPS (HTTPS の使用)
Appendix I: Referenced Specifications (参照仕様)
Appendix II: Extensibility Points (拡張点)
Appendix III: Acknowledgements (謝辞)

1. Introduction (序文)

この文書は WS-I Basic Profile 1.0 (以下,「このプロファイル」と呼ぶ) を定義する。WS-I Basic Profile 1.0 は非占有的 (non-proprietary) な Web サービス仕様で構成され,相互運用性を向上させる仕様の明確化及び敷衍を含んでいる。

第1節は,このプロファイルを紹介し,相互運用性に対してこのプロファイルがとった考え方を説明する。

第2節,Scope of the Profile (プロファイルの適用範囲) は,このプロファイルが向上させる相互運用性の範囲を限定する。

第3節, Profile Conformance (プロファイルに対する適合性) は,Basic Profile に適合するとはどういう意味かを説明する。

それに続く各節は,このプロファイルの構成要素となるそれぞれの仕様について述べるもので,次の2つの部分からなる。 すなわち,構成要素となる仕様及び拡張点 (extensibility point) を列挙した概要説明と, それに続いて,構成要素となる仕様の個別の部分について述べた小節との2つの部分である。 この文書の節番号と,参照される仕様のそれとの間には何の関係もないことに注意が必要である。

1.1 Guiding Principles (基本理念)

このプロファイルは,相互運用性を実現することに関係する一連の原則に沿って開発され, それらの原則は,全体として,このプロファイルの原理を構成している。 この節ではそれらのガイドラインを説明する。

相互運用性に対する保証の限界 (No guarantee of interoperability)
特定のサービスの相互運用性を完全に保証するのは不可能である。 しかし,このプロファイルは,実装経験によって現在までに明らかになったもっとも一般的な問題について検討している。
アプリケーションのセマンティクス (Application semantics)
アプリケーションのセマンティクスの通信はこのプロファイルを構成する技術によって容易となることがあるが, そのようなセマンティクスに対する共通理解を保証することは行われていない。
テスト可能性 (Testability)
可能な限り,このプロファイルでは要件をテストできるようにしている。 しかし,テストが可能であることは必須ではない。 また,テストはテスト対象に影響を与えない方式 (たとえば,伝送路上の対象物を調べるような) で達成できることが望ましい。
要件の強さ (Strength of requirements)
このプロファイルでは,可能な場合にはいつでも,強い要件 (たとえば,MUST や MUST NOT) を課している。 そのような要件が満足できない正当な理由がある場合,条件付きの要件 (たとえば,SHOULD や SHOULD NOT) を使う。 オプションや条件付きの要件は,曖昧さや複数の実装の間での不整合を引き起こす。
制限対緩和 (Restriction vs. relaxation)
参照される仕様の要件を敷衍する場合,このプロファイルは要件を制限することはあっても,緩和する (たとえば,MUST を MAY に変える) ことはない。
複数のメカニズム (Multiple mechanisms)
参照される仕様が複数のメカニズムの使用を交換可能な形で許している場合, このプロファイルではよく理解され,広く実装され,有用なものの方を選ぶ。 余計な,あるいは規定不足のメカニズムや拡張機能は物事を複雑にし,それによって相互運用性を低下させる。
将来の互換性 (Future compatibility)
このプロファイルでは,可能な場合には,要件を参照先仕様の改訂中の版 (たとえば SOAP 1.2 や WSDL 1.2) に合わせている。 これは実装者がスムーズに改訂版に移行する助けになるし,WS-I が基本仕様の検討内容と違う方向に進まないことを保証している。 このプロファイルが参照先の仕様の課題に言及できない場合, その情報は基本仕様の検討グループに送って,確実に検討されるようにしている。
展開済みのサービスとの互換性 (Compatibility with deployed services)
展開 (deploy) 済みの Web サービスとの後方互換性はこのプロファイルの目標ではないが,考慮はする。 このプロファイルは, 相互運用上の課題を解決するのでない限り, 参照される仕様の要件を変更することはない。
相互運用性への焦点 (Focus on interoperability)
参照される仕様にはさまざまの潜在的な矛盾や設計上の欠陥がありうるが,このプロファイルは相互運用性に影響するものだけについて言及している。
適合性対象 (Conformance targets)
このプロファイルでは,可能な場合には,対象物を送信・受信するソフトウェアの動作や役割に対してではなく,対象物そのもの (たとえば,WSDL 記述や SOAP メッセージ) に対して要件を課している。 対象物は具体的なものなので,検証することが容易で,その結果,適合性は理解することが簡単になり,間違いを起こしにくくなる。
下位層の相互運用性 (Lower-layer interoperability)
このプロファイルはアプリケーション層における相互運用性について言及している。下位層のプロトコル (たとえば,TCP, IP, Ethernet) の相互運用性は適切で,よく理解されていることが想定されている。 同様に,アプリケーション層下位プロトコル (たとえば,SSL/TLS, HTTP) に対する要件は, Web サービス固有の課題がある場合にのみ課せられる。 WS-I は,それらのプロトコルの相互運用性を全体として保証しようとしているわけではない。 これは,WS-I の Web サービス標準に対する専門知識と焦点とが有効に活用されることを保証する。

1.2 Notational Conventions (表記)

この文書では, 「~しなければならない (MUST, SHALL)」,「~してはならない (MUST NOT, SHALL NOT)」, 「必須の~ (REQUIRED)」,「~することが望ましい (SHOULD)」,「~すべきではない (SHOULD NOT)」,「推奨の~ (RECOMMENDED)」, 「~してもよい (MAY)」及び「省略可能の~ (OPTIONAL)」は, RFC2119 に記述されているとおりに解釈する。

[訳注: この訳文では,該当する用語の訳の直後に,括弧でくくって原文の用語を示している。 また,キーワードの訳語はできる限り JIS Z 8301 規格票の様式 に合わせた。]

このプロファイルにおける要件 (すなわち,Profile Conformance [プロファイルに対する適合性] の節に説明されている,適合性に影響するもの) は, 次の形式で提示される:

Rnnnn 要件の文章がここに入る。

ただし,ここで nnnn は要件番号で置き換えられる。 それぞれの要件は,ちょうど一つの要件レベルキーワード (MUST のような) と適合性対象キーワード (MESSAGE のような) とをもつ。

いくつかの要件記述は,参照される仕様を明確化するだけで,実装に対して追加の制約を課さないものである。 便宜のため,仕様の明確化 (clarification) は次のように注記される: C

いくつかの要件記述は,参照される仕様の標準化途中の内容を取り入れたものである。 便宜上,そのような仕様の先取りは次のように注記される: xxxx, ただし,ここで xxxx は仕様を示す識別子である (たとえば,"SOAP12" は,現在検討中の SOAP 1.2 仕様を示す)。 そういう仕様は完成しておらず,先取りした仕様が変更されることもありうることに注意が必要である。 この情報は,実装者に対する便宜としてのみ含められている。

この仕様では,全体を通して次に示すいくつかの名前空間プレフィックス (namespace prefix) を使用する。 各プレフィックスに関連付けられた URI を次に示す。 プレフィックスの選択は恣意的なものであり,どのような文字列を選択しても意味的に差異がないことに注意が必要である。

2. Scope of the Profile (プロファイルの適用範囲)

このプロファイルの適用範囲 (scope) は,その検討する技術を詳細化する。 言い換えれば,このプロファイルは,その適用範囲の中での相互運用性を向上することだけを図っている。 最初は,このプロファイルの適用範囲は,それが参照する仕様によって限定される。 このプロファイルが参照する仕様の完全なリストは,Appendix I を参照のこと。

このプロファイルの適用範囲は,拡張点 (extensibility points) によってさらに洗練される。 参照される仕様はたいてい拡張メカニズム及び未規定の若しくは無制限のコンフィギュレーションパラメーターを提供している。 拡張点と認識された場合,そのようなメカニズム又はパラメーターはこのプロファイルの適用範囲外であり, その使用はこのプロファイルに対する適合性表示 (conformance claim) の対象とはならない。

拡張点の使用は相互運用性を損なうことがあるので, その使用は Web サービスの関係者によって何らかの形で協議又は文書化されるべきである。 たとえば,これは私的な合意 (out-of-band agreement) の形をとるかもしれない。

このプロファイルは,それでも,拡張点の使用について,その範囲を制限することなく,要件を課すことがある。 また,拡張点の特定の使用方法について,このプロファイルが他のプロファイルと組み合わせて使われた場合に,相互運用性を向上するために,他のプロファイルで制限されることがある。

このプロファイルの拡張点の完全なリストは,Appendix II を参照のこと。

3. Profile Conformance (プロファイルに対する適合性)

このプロファイルに対して適合しているということは, このプロファイルの適用範囲内で, 特定の対象に対する要件の集合を守ることであると定義されている。

このプロファイルの適用範囲は前節 (Scope of the Profile) で定義されている。 このプロファイルに対する適合性は,参照される適用範囲内の仕様に対する適合性に依存するが, 参照される仕様がこのプロファイルの要件と対立する場合,このプロファイルの要件が優先される。

要件 (requirements) は,適用範囲内での,このプロファイルに対する適合性の基準を述べている。 要件は,そこでの相互運用性を向上する改良,解釈及び明確化を具体化したものである。 要件レベルは,RFC2119 の用語 (たとえば,MUST, MAY, SHOULD) を使い, 要件の性質と適合性に対する影響力とを示す。 個々の要件記述は,便宜上,個別に (R9999 のような) 番号が振られている。

補足の文章 (根拠や例など) が要件を明確にするために付け加えられることもあるが,要件記述そのものだけが適合性を判定する際に考慮されるべきである。

適合性対象 (targets) は,適合性の記述をさまざまな文脈で記述することで, (たとえば SOAP メッセージや WSDL 記述のような) 対象物 (artifacts),Web サービスのインスタンス,及び Web サービスの利用者 (consumer) に対する適合性試験 (conformance testing) と認定 (certification) とを可能にしている。 次の節では,このプロファイルの適合性対象を説明する。

サービスがこのプロファイルに対する適合性を示すために,メッセージ (message),記述 (description),及びレジストリーデータ (registry data) は適合性表示 (conformance claims) で注記することができる。 適合性表示は,特定のプロファイルに対する適合性を表明するためにある URI を使用する。

このプロファイルの適合性表示 URI は "http://ws-i.org/profiles/basic/1.0" である。

3.1 Conformance of Artifacts (対象物の適合性)

最も基本的なレベルの適合性は,対象物 (artifact) に対するものである。このプロファイルでは,次の3種類の対象物に対して要件記述を行う:

上記の対象物のインスタンスは,それに対する要件のすべてを満足したときに,適合しているものと見なされる。

3.2 Conformance of Services, Consumers and Registries (サービス,利用者及びレジストリーの適合性)

展開 (deploy) された Web サービスのインスタンス (wsdl:port 又は uddi:bindingTemplate で指定されるもの) は, 適合する対象物 (artifact) のみを生成し, 適合する対象物を (それが適切な場合には) 受け付ける場合に,適合しているものと見なされる。 これは,複数の適合する対象物があり得る場合には,適合するサービスは, そのすべてを受け付けられなければならない (たとえば,送信側は XML をエンコードするのに UTF-8 又は UTF-16 のいずれかを選べるのに対して,受信側はどちらでも受け付けられなければならない) という意味である。

同様に,サービスのインスタンスの利用者 (consumer) は,適合する対象物のみを生成 (produce) し, それが適切な場合には,適合する対象物を受容 (consume) する能力がある場合に,適合しているものとみなされる。

最後に,レジストリーは,REGISTRY という対象物に対するこのプロファイルの要件を満足する場合に,適合しているものとみなされる。

適合する Web サービスのインスタンス (instance) は,INSTANCE に対するすべての要件記述を満足しなければならない。

同様に,適合する利用者 (consumer) は,CONSUMER に対するすべての要件記述を満足しなければならない。

適合する Web サービスのインスタンス (instance) 及び利用者 (consumer) は,いずれも,それが適切な場合には,次に示す適合性対象に対するすべての要件記述を満足しなければならない:

インスタンスに対する適合性はサービス全体には適用されず,port にのみ適用されることに注意が必要である。 したがって,このプロファイルでは wsdl:service の定義にはいかなる制約も課さない。 特に,wsdl:service は複数の wsdl:port をもつことができ,それぞれの wsdl:port は適合してもよいし,しなくてもよい。

Web サービスの型 (wsdl:binding 及び wsdl:portType で記述される) は,正しく実装され,動作することを意図された環境に展開された場合に, 適合するインスタンスになるときに,適合していると見なされる。

さらに, Web サービスのインスタンスはサービスの運用に用いられる契約 (contract) を何らかの形で開示しなければならない。

R0001 INSTANCE は WSDL 1.1 のサービス記述,UDDI のバインディングテンプレート,又はその両方で記述されなければならない (MUST)。

ここで「記述される」とは, アクセス権のある利用者 (authorized consumer) が適合するサービスインスタンスのサービス記述を WSDL 1.1 文書で欲しいと要求した場合, サービスインスタンスのプロバイダーは, WSDL 文書,UDDI のバインディングテンプレート,又はその両方をその利用者に開示しなければならないという意味である。 サービスインスタンスはサーバーから実行時に WSDL 文書を提供してもよいが,これは適合のためには必須ではない。 同様に,任意のサービスインスタンスのプロバイダーは UDDI レジストリーにそのインスタンスプロバイダーを登録してもよいが, それは適合のためには必須ではない。 上記のすべてのシナリオにおいて, WSDL の契約は存在していなければならないが,状況によっては,別の形態で開示されるかもしれない。

3.3 Conformance Annotation in Descriptions (記述における適合性注記)

適合性表示は特定の要素 (たとえば wsdl:portType) に関連付けて,適用範囲をその構造に限定することも可能である。

R0002 DESCRIPTION は, インスタンスに対する適合性の表示を, 適合性表示スキーマ (conformance claim schema) に規定された通りの形で, 含んでもよい (MAY)。

R0003 DESCRIPTION の適合性の表示は, wsdl:port, wsdl:binding, wsdl:portType, wsdl:operation (wsdl:portType の子要素の方で,wsdl:binding の子要素ではない) 及び wsdl:message 要素の中の wsdl:documentation 要素の子要素でなければならない (MUST)。

ある要素における適合性の表示は,その要素 (及び port の場合,その要素が代表するインスタンス) が,それが遵守していると表示するプロファイルの要件に (当該要素に適用可能な範囲において) 適合していることを意味する。

ある要素における適合性の表示は, その要素が使用するすべての要素に対して同じ表示がなされていることを暗黙のうちに含み, 次に示す継承規則に基づき,再帰的に適用される:

適合性表示スキーマ (conformance claim schema) は次の通り:

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://ws-i.org/schemas/conformanceClaim/"
  xmlns:tns="http://ws-i.org/schemas/conformanceClaim/"
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified" >

  <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/"
    schemaLocation="http://schemas.xmlsoap.org/soap/envelope/" />

  <xsd:element name="Claim" >
    <xsd:complexType>
      <xsd:sequence>
        <xsd:any namespace="##any" processContents="lax"
         minOccurs="0" maxOccurs="unbounded" />
      </xsd:sequence>
      <xsd:attribute name="conformsTo" type="xsd:anyURI" use="required"/>
      <xsd:attribute ref="soap:mustUnderstand" use="prohibited" />
      <xsd:anyAttribute namespace="##any" processContents="lax"/>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>

次に例を示す:

正しい例:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
  xmlns:tns="http://example.org/myservice"
  xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap"
  xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/"
  targetNamespace="http://example.org/myservice">
  <wsdl:portType name="MyPortType">
      ...
  </wsdl:portType>
  <wsdl:binding name="MyBinding" portType="MyPortType" >
      ...
  </wsdl:binding>
  <wsdl:service name="MyService" >
    <wsdl:port name="MyPort" binding="tns:MyBinding" >
      <wsdl:documentation>
        <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" />
      </wsdl:documentation>
      <soapbind:address location="http://example.org/myservice/myport" />
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions> 

3.4 Conformance Annotation in Messages (メッセージにおける適合性注記)

このプロファイルの新しい版や,その他のプロファイルがリリースされるに従い, 一つのサービスが複数のプロファイルをサポートする可能性がある。 メッセージを受信する際に,メッセージがどのプロファイルに適合しているかを,サービスが識別できるようにしたいと思うかもしれない。 SOAP メッセージがどのプロファイルに適合しているかを示せるようにするために,WS-I は SOAP ヘッダーとしての wsi:Claim 要素の使い方を規定する。

R0004 MESSAGE は,適合性表示を, 適合性表示スキーマ (conformance claim schema) に規定された通りの形で, 含んでもよい (MAY)。

R0005 MESSAGE の適合性表示は,SOAP ヘッダーブロックに格納しなければならない (MUST)。

R0006 MESSAGE は,一つ以上のプロファイルに対する適合性表示を含んでもよい (MAY)。

R0007 SENDER は,適合性表示を含む SOAP ヘッダーブロックを送る際に, soap:mustUnderstand 属性を使用してはならない (MUST NOT)。

SOAP メッセージは,SOAP ヘッダーブロックとして適合性表示をもち, 受信側に対して送信側がメッセージの一つ以上のプロファイルへの適合を表示することができる。 メッセージに適合性表示のないことが, メッセージが一つ以上のプロファイルに対する適合の有無を示すものと解釈してはならない。 また,適合性表示のヘッダーブロックは参考であるとみなされ, そのため必須ヘッダーブロックであってはならない。 そこで,このプロファイルでは soap:mustUnderstand 属性の適合性表示ヘッダーブロックでの使用を禁止している。

次に例を示す:

正しい例:

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
  <soap:Header>
    <!-- other headers -->
    <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0"
     xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
    <!-- other headers -->
  </soap:Header>
  <soap:Body>
    <!-- body content -->
  </soap:Body>
</soap:Envelope>

3.5 Conformance Annotation in Registry Data (レジストリーデータにおける適合性注記)

WSDL 記述のさまざまな要素に対してプロファイルの適合性表示を行うことが有用なのと同様に, uddi:tModel 要素にそれを行うことも有用である。 UDDI で uddi:tModel に属性を追加する自然な方法は,カテゴリーシステムを定義して使うことである。 このプロファイルは,uddi:tModel が WS-I プロファイルに対する適合性を示すためにこのメカニズムを採用し, 特にこのプロファイルへの適合性を示す方法を指定している。

R3020 プロファイルへの適合性を表示する uddi:tModel 型の REGDATA は, ws-i-org:conformsTo:2002_12 のタキソノミーを使用してカテゴライズされなければならない (MUST)。

R3030 プロファイルへの適合性を表示する uddi:tModel 型の REGDATA は, ws-i-org:conformsTo:2002_12 のカテゴライゼーションに, そのプロファイルに対応する適合性表示 URI を使用しなければならない (MUST)。

R3021 REGISTRY は, ws-i-org:conformsTo:2002_12 の tModel 定義をレジストリーの内容として追加することによって, WS-I 適合性カテゴリーシステムをサポートしなければならない (MUST)。

ws-i-org:conformsTo:2002_12 の tModel の内容は次のとおりである:

<tModel tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0">
  <name>ws-i-org:conformsTo:2002_12</name>
  <description xml:lang="EN">Category system used for UDDI entities
  to point to the WS-I concept to which they conform to</description>
  <overviewDoc>
    <overviewURL>http://ws-i.org/schemas/conformanceClaim/</overviewURL>
  </overviewDoc>
  <categoryBag>
  <keyedReference
    keyName="uddi-org:types:categorization"
    keyValue="categorization"
    tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" />
  </categoryBag>
</tModel>

次に例を示す:

正しい例:

<tModel tModelKey="...">
   <name>BarSOAPService</name>
   <description xml:lang="EN">Bar's SOAP Service</description>
   <overviewDoc>...</overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0"
         keyName="ws-I_conformance:BasicProfile1.0"
         keyValue="http://ws-i.org/profiles/basic/1.0" />
   </categoryBag>

wsdl:service 要素は必ずしも一つの uddi:businessService に対応付けられるわけではなく, また,適合性表示 (conformance claim) の対象になるわけではないので, uddi:businessEntity 又は uddi:businessService 要素がこのプロファイルに対する適合性を表示した場合, それがどういう意味になるかが不明確になるだろう。 また, uddi:bindingTemplate 要素は, UDDI V2 の XML Schema がそれに対する categoryBag を提供していないので, カテゴライズすることができない。 よって, wsdl:port 要素による適合性の表示は,対応する uddi:bindingTemplate には記述できない。

R3005 適合する Web サービス型を表現する uddi:tModel 要素以外の REGDATA が ws-i-org:conformsTo:2002_12 のタキソノミーと "http://ws-i.org/profiles/basic/1.0" のカテゴライゼーションを使用してカテゴライズされてはならない (MUST NOT)。

uddi:tModel の適合性の表示が,それの使っている wsdl:binding の適合性の表示と矛盾していた場合,解釈に困るだろう。

R3004 uddi:tModel 型の REGDATA は, その uddi:tModel に示される適合性の表示が, それの参照する wsdl:binding に示される適合性の表示と整合するように構成されなければならない (MUST)。

4. Messaging (メッセージング)

プロファイルのこの節では,次の仕様を参照し,その中での拡張点を定義する:

4.1 XML Representation of SOAP Messages (SOAP メッセージの XML 表現)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

SOAP 1.1 ではメッセージ伝送のための XML ベースの構造を定義している。このプロファイルではそれを使用することを必須とし,その使用に際しては次の制約を課す:

4.1.1 SOAP Messages and the Unicode BOM (SOAP メッセージと Unicode の BOM)

XML 1.0 では,UTF-8 エンコーディングにおいても BOM を含めてもよいことになっており,メッセージの受信側はそれを受け入れる用意がなければならない。 BOM は,UTF-16 でエンコードされた XML では必須である。

R4001 RECEIVER は,Unicode の Byte Order Mark (BOM) を含むメッセージを受け付けなければならない (MUST)。 C

4.1.2 SOAP Fault Syntax (SOAP フォルトの構文)

SOAP フォルトとは,soap:Body 要素に1つの子要素があり,それが soap:Fault 要素であるような SOAP メッセージのことである。 このプロファイルは,soap:Fault要素の内容を SOAP 1.1 で明示的に記述された要素に制限する。

R1000 MESSAGE が soap:Fault 要素を含む場合,その要素は faultcode, faultstring, faultactor 及び detail以外の子要素をもってはならない (MUST NOT)。

次に例を示す:

間違っている例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>There were <b>lots</b> of elements in the message
  that I did not understand
  </detail>
  <m:Exception xmlns:m='http://example.org/faults/exceptions' >
    <m:ExceptionType>Severe</m:ExceptionType>
  </m:Exception>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>
     <m:msg xmlns:m='http://example.org/faults/exceptions'>
         There were <b>lots</b> of elements in the message that I did not understand
     </m:msg>
     <m:Exception xmlns:m='http://example.org/faults/exceptions'>
       <m:ExceptionType>Severe</m:ExceptionType>
     </m:Exception>
   </detail>
</soap:Fault>

4.1.3 SOAP Faults and Namespaces (SOAP フォルトと名前空間)

soap:Fault 要素の子要素はローカルであり,名前空間修飾の必要はない。

R1001 MESSAGE が soap:Fault 要素を含む場合,その子要素は名前空間修飾なし (unqualified) でなければならない (MUST)。

次に例を示す:

間違っている例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:faultcode>soap:Client</soap:faultcode>
  <soap:faultstring>Invalid message format</soap:faultstring>
  <soap:faultactor>http://example.org/someactor</soap:faultactor>
  <soap:detail>
      <m:msg xmlns:m='http://example.org/faults/exceptions'>
          There were <b>lots</b> of elements in the message that
          I did not understand
      </m:msg>
  </soap:detail>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
			xmlns='' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>
      <m:msg xmlns:m='http://example.org/faults/exceptions'>
          There were <b>lots</b> of elements in the message that
          I did not understand
      </m:msg>
  </detail>
</soap:Fault>

4.1.4 SOAP Fault Extensibility (SOAP フォルトの拡張性)

拡張性のために, detail 要素に追加の属性が現れること, 及び, detail 要素に子要素として追加の要素が現れることが許されている。

R1002 RECEIVER は, detail 要素の子要素として (0 個を含む) いかなる数の要素をもつフォルトメッセージも受け付けなければならない (MUST)。 それらの子要素は名前空間修飾されていても,されていなくてもよい。

R1003 RECEIVER は, detail 要素の属性として (0 個を含む) いかなる数の名前空間修飾された又はされていない属性をもつフォルトメッセージも受け付けなければならない (MUST)。 名前空間修飾されたそれらの属性の名前空間は, "http://schemas.xmlsoap.org/soap/envelope" でなければ何でもよい。

4.1.5 SOAP Fault Language (SOAP フォルトの言語)

faultstring は,Fault の性質について人間が読めるように示したものである。 したがって,それが特定の言語で記述されているとは限らず,xml:lang 属性が faultstring の言語を示すために使用できる。

R1016 RECEIVER は, faultstring 要素に xml:lang 属性をもつ フォルトメッセージを受け付けなければならない (MUST)。

4.1.6 SOAP Custom Fault Codes (SOAP の独自フォルトコード)

SOAP 1.1 は,ドット表記 ("dot" notation) を使って独自のフォルトコードが faultcode 要素の内容に現れることを許している。

SOAP 1.1 で定義されたフォルトコードをこのメカニズムを使って拡張することは,名前空間の衝突を引き起こしうる。 "." (ドット) の右側に同じ名前が違う意味で使われた場合に, 相互運用上の問題を引き起こすことがあるので,その使用は避けるべきである。

その代わりに,このプロファイルでは, SOAP 1.1 で定義されたフォルトコードを使い, フォルトの性質をあらわすために detail 要素の中に追加の情報を入れる方式を推奨している。

別の方式として, 独自のフォルトコードを規定する機関の管理下にある名前空間の中で定義することも許容している。

いくつかの仕様では既にドット表記を使った独自のフォルトコードを定義している。 それにもかかわらず,それらを将来の仕様で使うことは推奨しない。

R1004 MESSAGE が SOAP の faultcode 要素を含む場合, 要素の内容は SOAP 1.1 仕様で定義されているフォルトコードの一つであるか,又は名前空間修飾されたフォルトコードであることが望ましい (SHOULD)。

R1031 MESSAGE が SOAP の faultcode 要素を含む場合, フォルトの意味を詳細化するために SOAP 1.1 のドット表記を使うべきではない (SHOULD NOT)。

独自のフォルトコードを必要とするアプリケーションは, SOAP 1.1 で定義されたフォルトコードを使い detail 要素に追加の情報を供給するか, それらのコードを規定する機関の管理下にある名前空間で定義するかの, いずれかを推奨する。

次に例を示す:

間違っている例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>soap:Server.ProcessingError</faultcode>
  <faultstring>An error occurred while processing the message
  </faultstring>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>c:ProcessingError</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Server</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>

4.1.7 SOAP encodingStyle Attribute (SOAP の encodingStyle 属性)

soap:encodingStyle 属性は, データを XML にエンコーディングする際に特定のスキームを使うことを示すのに使われてきた。 しかし,この機能は XML 名前空間を使っても実現できるので,複雑さを導入してしまう。 そこで,このプロファイルは,literal の,エンコードされない XML のほうを優先している。

R1005 MESSAGE は,名前空間名 (namespace name) が "http://schemas.xmlsoap.org/soap/envelope/" である要素のいずれにも soap:encodingStyle 属性を含んではならない (MUST NOT)。

R1006 MESSAGE は,soap:Body 要素の子要素のいずれにも soap:encodingStyle 属性を含んではならない (MUST NOT)。

R1007 rpc-literal バインディングで記述される MESSAGE は,soap:Body 要素の孫要素のいずれにも soap:encodingStyle 属性を含んではならない (MUST NOT)。

4.1.8 SOAP's use of XML (SOAP での XML の使用)

XML の DTD 及び PI は,SOAP のメッセージに使用された場合, セキュリティ上の脆弱性,処理のオーバーヘッド及びメッセージのセマンティクスの曖昧さを導入するかもしれない。 そのため,XML のこれらの機能の処理は SOAP 1.1 の 3. 節で禁止されている。

R1008 MESSAGE は文書型宣言 (Document Type Declaration) を含んではならない (MUST NOT)。C

R1009 MESSAGE は処理命令 (Processing Instructions) を含んではならない (MUST NOT)。C

4.1.9 SOAP and XML Declarations (SOAP と XML 宣言)

XML 宣言の有無は相互運用性に影響しない。処理系によっては必ず XML 宣言をつけるかもしれない。

R1010 RECEIVER は,XML 宣言 (XML Declaration) を含むメッセージを受け付けなければならない (MUST)。 C

4.1.10 SOAP Trailers (SOAP 後続要素)

soap:Body 要素の後ろに兄弟要素が現れた場合の解釈は明らかではない。 よって,そのような要素は禁止する。

R1011 MESSAGE は soap:Envelope 要素の子要素として, soap:Body 要素の後ろにいかなる要素も付加してはならない (MUST NOT)。

この要件は,SOAP 1.1 の,仕様本文と XML Schema 文書との間の食い違いを明確化する。

次に例を示す:

間違っている例:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p='http://example.org/Operations' />
  </soap:Body>
  <m:Data xmlns:m='http://example.org/information' >
  Here is some data with the message
  </m:Data>
</soap:Envelope>

正しい例:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p='http://example.org/Operations' >
	  <m:Data xmlns:m='http://example.org/information' >
  Here is some data with the message
      </m:Data>
    </p:Process>
  </soap:Body>
</soap:Envelope>

4.1.11 Acceptable SOAP Character Encodings (許容可能な SOAP 文字エンコーディング)

このプロファイルでは,相互運用性の向上のため, すべての XML 処理系が "UTF-8" 及び "UTF-16" の文字エンコーディング をサポートすることを義務付けている。

この結果として, SOAP 1.1 の text/xml メディア型 (デフォルトの文字エンコーディングは "us-ascii") を使うべきであるという要件と合わせると, SOAP エンベロープのメディア型に charset パラメーターが常に存在しなければならないことになる。 さらなる結果として, XML 1.0 及び RFC3023 "XML Media Types" の要件との整合性をとると, メッセージの中の XML 宣言にある encoding 擬似属性は, 常に無視されることになる。

R1012 MESSAGE は UTF-8 又は UTF-16 のいずれかの文字エンコーディングでシリアライズされなければならない (MUST)。

R1018 MESSAGE のエンベロープのメディア型は, charset パラメーターを使って正しい文字エンコーディングを指定しなければならない (MUST)。

SOAP が HTTP バインディングで使われる場合, メディア型は HTTP の Content-Type ヘッダーフィールドに格納される。

4.1.12 SOAP mustUnderstand Attribute (SOAP mustUnderstand 属性)

soap:mustUnderstand 属性は "xsd:boolean" 型を制限したものであり,"0" 又は "1" の値のみを取る。 よって,この2つの値だけが許されている。

R1013 MESSAGE が soap:mustUnderstand 属性を含む場合,属性の値として 2 種類の形式 "0" 及び "1" のみを使用しなければならない (MUST)。C

4.1.13 SOAP Body and Namespaces (SOAP Body と名前空間)

名前空間修飾のない要素名の使用は名前の衝突を起こすかもしれないので,soap:Body の子要素には修飾された名前を使わなければなければならない。

R1014 MESSAGE の soap:Body 要素の子要素は, 名前空間修飾され (namespace qualified) なければならない (MUST)。

4.1.14 SOAP Envelope Namespace (SOAP Envelope の名前空間)

SOAP 1.1 は, Envelope 要素の名前空間名 (namespace name) が "http://schemas.xmlsoap.org/soap/envelope/" でない場合,メッセージを破棄することだけを規定している。 このプロファイルは,曖昧でないオペレーションを保証するため,その代わりにフォルトが生成されることを要求している。

R1015 RECEIVER は,メッセージの Envelope 要素の名前空間 URI が "http://schemas.xmlsoap.org/soap/envelope/" でないものに遭遇した場合,フォルトを生成しなければならない (MUST)。

4.1.15 Use of xsi:type Attributes (xsi:type 属性の使用)

多くの場合,送信側と受信側とは,交換されるメッセージについて型情報を何らかの形で共有している。 xsi:type 属性は,そのようなスキーマの存在しない場合にのみ必要であり, それは,両者がすべての交換される内容を "xsd:anyType" と想定している場合である。

R1017 RECEIVER は,派生型を示すために必要な場合 (XML Schema Part 1: Structures, 2.6.1 節を参照) を除き,メッセージに xsi:type 属性の使用を必須としてはならない (MUST NOT)。

4.2 SOAP Processing Model (SOAP 処理モデル)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

SOAP 1.1 ではメッセージ処理のためのメッセージ交換モデルを定義している。 特に,メッセージのヘッダーブロックとボディの処理についてのルールを定義している。 また,フォルトの生成に関するルールも定義している。 このプロファイルでは,その処理モデルに対して次の制約を課す:

4.2.1 Mandatory Headers (必須ヘッダー)

SOAP 1.1 の処理モデルは,必須ヘッダーブロックの処理についての規定が不十分である。 必須ヘッダーブロックとは,soap:Header 要素の子要素で, soap:mustUnderstand 属性に "1" の値を設定しているもののことである。

R1025 RECEIVER は,すべての必須ヘッダーブロックに対するチェックが実際の処理の前に行われているように動作しなければならない (MUST)。 SOAP12

これによって,メッセージの一部分を処理した後で必須ヘッダーブロックを見つけることによる,予期せぬ副作用が発生しないことを保証する。

4.2.2 Generating mustUnderstand Faults (MustUnderstand フォルトの生成)

このプロファイルは,受信側が自分宛のヘッダーブロックを理解できない場合,フォルトを生成することを要求している。

R1027 メッセージが (soap:actor によって) 宛先として指定された受信者 (receiver) に理解できない必須ヘッダーブロック (soap:mustUnderstand 属性の値が "1" であるもの) をもつ場合, RECEIVER は "soap:MustUnderstand" フォルトを生成しなければならない (MUST)。

4.2.3 SOAP Fault Processing (SOAP フォルトの処理)

フォルトが生成される場合,それ以降の処理は行われるべきではない。request-response のメッセージ交換では, リクエストメッセージの送信側にフォルトメッセージが伝送され, 何らかのアプリケーションレベルのエラーがユーザーに通知される。

R1028 RECEIVER でフォルトが生成される場合, フォルトが生成される前に行われた処理の影響を復元 (rollback) 又は補償 (compensate) するために必要なものを除き, SOAP メッセージに対するそれ以降の処理を行うべきではない (SHOULD NOT)。

R1029 SOAP のメッセージの処理の正常な結果が SOAP レスポンスの伝送になる場合で,その代わりに SOAP フォルトが生成されるとき, RECEIVER はレスポンスの代わりに SOAP フォルトメッセージを伝送しなければならない (MUST)。

R1030 SOAP フォルトを生成する RECEIVER は, 実際に SOAP フォルトが生成されたことを, その状況に適切な手段をもってエンドユーザーに通知することが望ましい (SHOULD)。

4.3 Use of SOAP in HTTP (HTTP での SOAP の使用)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

SOAP 1.1 では HTTP に対する一つのプロトコルバインディングを定義している。このプロファイルではそのバインディングの使用を必須とし,その使用に際しては次の制約を課している:

4.3.1 HTTP Versions (HTTP の版数)

HTTP にはいくつかの版が定義されている。 HTTP 1.0 と比較すると,HTTP 1.1 は性能的に有利であり,また,仕様もはっきりと規定されている。

R1140 MESSAGE は HTTP 1.1 を使って送られることが望ましい (SHOULD)。

R1141 MESSAGE は HTTP 1.1 又は HTTP 1.0 のいずれかを使って送られなければならない (MUST)。

HTTP 1.1 のサポートには HTTP 1.0 のサポートが含まれており, また中継ノード (intermediaries) がメッセージの版数を変更してしまう可能性があることに注意が必要である。 HTTP の版数については RFC2145 "Use and Interpretation of HTTP Version Numbers" を参照。

4.3.2 Identifying SOAP Faults (SOAP フォルトの識別)

いくつかの利用者 (consumer) の実装は,SOAP フォルトの存在を識別するのに HTTP の状態コードのみを使用する。Web のインフラストラクチャが状態コードを変更するような状況も考えられるし,また,一般的な信頼性のためにも,このプロファイルでは,実装がエンベロープも調べることを要求する。

R1107 RECEIVER は soap:Fault 要素のみを含む SOAP メッセージをフォルトと解釈しなければならない (MUST)。

4.3.3 HTTP Methods and Extensions (HTTP のメソッドと拡張)

SOAP 1.1 仕様は HTTP バインディングに,HTTP の POST メソッドと HTTP 拡張フレームワーク (HTTP Extension Framework) の M-POST メソッドとの,2種類のいずれかが使用可能となるよう規定している。 このプロファイルでは HTTP の POST メソッドだけを使用することを要求し,HTTP 拡張フレームワークの使用を禁止している。

R1132 HTTP のリクエスト MESSAGE は,HTTP の POST メソッドを使用しなければならない (MUST)。

R1108 MESSAGE は HTTP 拡張フレームワーク (HTTP Extension Framework) [RFC2774] を使用してはならない (MUST NOT)。

HTTP 拡張フレームワークは HTTP をモジュラーな形で拡張するための実験的なメカニズムである。このメカニズムは広く採用されておらず,また,SOAP での使用による利点は疑問であることから,このプロファイルでは使用を許していない。

4.3.4 SOAPAction Header Syntax (SOAPAction ヘッダーの構文)

テストによって明らかになっているように, HTTP の SOAPAction ヘッダーフィールドの値に引用符を必須とすることが実装の間の相互運用性を向上する。 HTTP 仕様はヘッダーフィールドの値を引用符で囲まないことを許容しているが, いくつかの SOAP 実装は値が引用符で囲まれていることを必須としている。

SOAPAction ヘッダーフィールドは純粋に処理系に対するヒントである。 メッセージの処理に本質的な情報はすべて soap:Envelope に含まれる。

R1109 HTTP のリクエスト MESSAGE の SOAPAction ヘッダーフィールドの値は,引用符で囲まれた文字列でなければならない (MUST)。C

R1119 RECEIVER は,HTTP の SOAPAction ヘッダーフィールドの値が引用符で囲まれていない場合,フォルトを返してもよい (MAY)。C

次に例を示す:

正しい例:

WSDL 記述に次の要素:

<soapbind:operation soapAction="foo" />

を含む場合,対応する SOAPAction HTTP ヘッダーは次のとおり:

SOAPAction: "foo"

正しい例:

WSDL 記述に次の要素:

<soapbind:operation />

又は

<soapbind:operation soapAction="" />

を含む場合,対応する SOAPAction HTTP ヘッダーは次のとおり:

SOAPAction: ""

4.3.5 HTTP and TCP Ports (HTTP と TCP のポート番号)

SOAP は HTTP のインフラストラクチャを利用するように設計されている。しかし,有害な副作用をもたらす場合 (たとえば,プロキシー,ファイアウォール,その他の中継ノードがからむ場合) がある。結果として,インスタンスは HTTP のデフォルト (80) とは別のポートを使った方がよい場合もある。

R1110 INSTANCE は,TCP の 80 番ポート (HTTP) での接続を受け付けてもよい (MAY)。C

W3C 及び IETF において, HTTP にバインディングされた SOAP メッセージを 80 番ポートで使うことの妥当性について, 相当な議論が続けられてきた。 これは許容できるやり方だというのが,結論である。

4.3.6 HTTP Success Status Codes (HTTP の成功状態コード)

HTTP は 2xx の状態コードを成功を示すために使っている。 特に 200 は成功メッセージのデフォルトであるが, 202 もメッセージが処理に投入されたことを示すために使用可能である。 付け加えて,その他の 2xx 状態コードも,HTTP 通信の性質によっては,適切となることもある。

R1124 INSTANCE は,リクエストの結果が成功であることを示すレスポンスの HTTP 状態コードとして 2xx を使用しなければならない (MUST)。

R1111 INSTANCE は,SOAP フォルトではない内容のレスポンスの HTTP 状態コードとして, "200 OK" を使うことが望ましい (SHOULD)。

R1112 INSTANCE は, SOAP メッセージを内容として含まないが HTTP リクエストの結果としては成功であるレスポンスの HTTP 状態コードとして, "200 OK" 又は "202 Accepted" のいずれかを使うことが望ましい (SHOULD)。

4.3.7 HTTP Redirect Status Codes (HTTP の転送状態コード)

HTTP の転送 (redirect) の状態コードを使う場合,元と同じメソッドを使うか,それとも GET メソッドを使うかという点について相互運用上の問題がある。 このプロファイルでは,正しい転送の状態コードとして "307 Temporary Redirect" (同じメソッドでの転送を意味する) を要求している。 詳細については,RFC2616 の 3xx 状態コードに関する記述を参照。

R1130 INSTANCE は,リクエストを別のエンドポイントに転送 (redirect) する場合,HTTP の状態コード "307 Temporary Redirect" を使用しなければならない (MUST)。

R1131 CONSUMER は,レスポンスとして "307 Temporary Redirect" を受け取った場合, リクエストを自動的に転送 (redirect) してもよい (MAY)。

RFC2616 は,ユーザーエージェントが自動的にリクエストを転送すべきではないとしている。 しかし,この要件はブラウザーを想定したものであり,自動的な処理 (多くの Web サービスもこれにあたる) を想定したものではない。 よって,このプロファイルでは,利用者 (consumer) が転送を自動的に行うことを許してはいるが,要求してはいない。

4.3.8 HTTP Client Error Status Codes (HTTP のクライアントエラー状態コード)

HTTP は 4xx の状態コードをクライアントのエラーによる失敗を示すために使っている。 これらのうちのいずれかの結果を起こす状況はいろいろあるが, このプロファイルでは,HTTP リクエストのペイロードが正しいメディア型 (すなわち,SOAP/HTTP バインディングで要求されている "text/xml") でなかった場合と, 期待されるメディア型 ("POST") が指定されなかった場合とを強調している。

R1125 INSTANCE は,リクエストの形式に問題があることを示すレスポンスの HTTP 状態コードとして 4xx を使用しなければならない (MUST)。

R1113 INSTANCE は,リクエストのメッセージが HTTP リクエストとして正しい形式ではない,又は XML が整形式 (well-formed) ではない場合, HTTP 状態コードとして "400 Bad Request" を使うことが望ましい (SHOULD)。

R1114 INSTANCE は,リクエストのメソッドが "POST" でない場合, HTTP 状態コードとして "405 Method not Allowed" を使うことが望ましい (SHOULD)。

R1115 INSTANCE は,HTTP リクエストの Content-Type ヘッダーの値が input のメッセージに対応するバインディングで指定された値と整合していなかった場合, HTTP 状態コードとして "415 Unsupported Media Type" を返すことが望ましい (SHOULD)。

上記の要件が,インスタンスに対して,リクエストにレスポンスを返すことを強制していないことに注意。 場合によっては,たとえばサービス妨害攻撃 (Denial of Service attacks) の場合など, インスタンスがリクエストを無視することを選択することもある。

4.3.9 HTTP Server Error Status Codes (HTTP のサーバーエラー状態コード)

HTTP は 5xx の状態コードをサーバーのエラーによる失敗を示すために使っている。

R1126 INSTANCE は,レスポンスのメッセージが SOAP フォルトである場合, HTTP 状態コードとして "500 Internal Server Error" を使わなければならない (MUST)。

4.3.10 HTTP Cookies (HTTP クッキー)

HTTP 状態管理メカニズム (HTTP State Management Mechanism) は,「クッキー (Cookies)」とも呼ばれ, Web ブラウザーとサーバーとの間で状態をもったセッションを生成することを可能にしている。 ハイパーテキストのブラウズを前提に設計されたため,クッキーの Web サービスでの動作の定義は曖昧であり, しかも, クッキーは SOAP エンベロープの外側にあるため,SOAP 1.1 又は WSDL 1.1 のいずれの仕様にも取り込まれていない。 しかし,複数のサーバーの負荷分散やクッキーを使う既存のサーバーの統合など,クッキーを使うことが必要な状況もある。 そこで,このプロファイルではクッキーを全面否定するのではなく,その用途を限定するにとどめている。

R1120 INSTANCE は HTTP 状態メカニズム [HTTP state mechanism] (クッキー) を使ってもよい (MAY)。

R1122 クッキーを使用する INSTANCE は RFC2965 に適合することが望ましい (SHOULD)。

R1121 INSTANCE は,正常動作のために利用者 (consumer) のクッキーのサポートを必須とすべきではない (SHOULD NOT)。

R1123 クッキーの値は CONSUMER にとって不透明 (opaque) なものとみなされなければならない (MUST)。

このプロファイルでは,クッキーはインスタンスの正常動作に必須とはしないことを推奨している。 クッキーはヒントであり,最適化に使われるもので, Web サービスの実行に実質的に影響を与えないものであるべきだ。 しかし,既存のサービスの統合などの例外的な用途でクッキーが必要になるかもしれないので, クッキーを要求することでインスタンスが不適合になるわけではない。 よって,クッキーはインスタンスにとって意味があるかもしれないが, インスタンスと利用者 (consumer) との間でのデータ通信の抜け道 (out-of-bound data channel) として使われるべきではない。 よって,利用者側でクッキーの内容を解釈することは許されていない。クッキーは不透明 (すなわち,利用者にとって意味のないもの) として扱われなければならない。

5. Service Description (サービス記述)

このプロファイルでは,Web Services Description Language (WSDL) を使って,メッセージを操作するエンドポイントの集合として,サービスを記述する。

プロファイルのこの節では,次の仕様を参照し,その中での拡張点を定義する:

5.1 Document Structure (文書構造)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

WSDL 1.1 は, Web サービスを記述するための XML に基づいた構造を定義する。このプロファイルではこの構造の使用を必須とし,その使用においては次の制約を課す:

5.1.1 WSDL Schema Definitions (WSDL スキーマ定義)

WSDL 1.1 仕様の Appendix 4 で規定されているスキーマは,仕様の本文の規定との間に不整合がある。 このプロファイルは,既知の間違いに対する修正を取り入れた新しいスキーマ文書を参照する。

R2028 WSDL の名前空間 (このプロファイルでは "wsdl" のプレフィックスを用いる) を使用する DESCRIPTION は, "http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd" にある XML Schema に対して妥当 (valid) でなければならない (MUST)。

R2029 WSDL SOAP バインディングの名前空間 (このプロファイルでは "soapbind" のプレフィックスを用いる) を使用する DESCRIPTION は, "http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd" にある XML Schema に対して妥当 (valid) でなければならない (MUST)。

このプロファイルでは WSDL 記述がスキーマに対して妥当であることを要求しているが, 利用者が WSDL 文書を妥当性検証することを要求しているわけではない。 それを保証するのは WSDL 文書の作成者の責任である。

5.1.2 WSDL and Schema Import (WSDL とスキーマの import)

WSDL 1.1 のいくつかの例では, XML Schema 定義の取り込むために用いる WSDL の import 文が間違っている。 このプロファイルでは import メカニズムの使用を明確化し,それぞれに整合性をもたせ,守備範囲を限定している。 取り込まれたスキーマ文書は, 取り込む側の WSDL 文書に対する XML の版数とエンコーディングとに対する要件に整合するよう, 制限されている。

R2001 DESCRIPTION は,他の WSDL 記述を取り込むために WSDL の import 記述だけを使用しなければならない (MUST)。

R2002 XML Schema のスキーマ定義を取り込むために, DESCRIPTION は XML Schema の import 記述を使用しなければならない (MUST)。

R2003 DESCRIPTION は, XML Schema の import 記述を types 要素の中の xsd:schema 要素の内部のみで使用しなければならない (MUST)。

R2004 DESCRIPTION は, ルート要素が "http://www.w3.org/2001/XMLSchema" の名前空間にある schema 要素ではない任意の文書から スキーマ定義を取り込むために XML Schema の import 記述を使用してはならない (MUST NOT)。

R2009 DESCRIPTION から直接的又は間接的に取り込まれる XML Schema は, Unicode の Byte Order Mark (BOM) を含んでもよい (MAY)。

R2010 DESCRIPTION から直接的又は間接的に取り込まれる XML Schema は, UTF-8 又は UTF-16 のエンコーディングを使用しなければならない (MUST)。

R2011 DESCRIPTION から直接的又は間接的に取り込まれる XML Schema は, Extensible Markup Language (XML) の 1.0 版 W3C 勧告を使用しなければならない (MUST)。

次に例を示す:

間違っている例:

<definitions name="StockQuote"
   targetNamespace="http://example.com/stockquote/definitions"
   xmlns:xsd1="http://example.com/stockquote/schemas""
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

   <import namespace="http://example.com/stockquote/schemas"
         location="http://example.com/stockquote/stockquote.xsd"/>

   <message name="GetLastTradePriceInput">
        <part name="body" element="xsd1:TradePriceRequest"/>
    </message>
               ...
</definitions>

正しい例:

<definitions name="StockQuote"
      targetNamespace="http://example.com/stockquote/definitions">
      <import namespace="http://example.com/stockquote/definitions"
           location="http://example.com/stockquote/stockquote.wsdl"/>
      <message name="GetLastTradePriceInput">
         <part name="body" element="..."/>
      </message>
                  ...
   </definitions>

正しい例:

<definitions name="StockQuote"
   targetNamespace="http://example.com/stockquote/"
   xmlns:xsd1="http://example.com/stockquote/schemas"
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

   <import namespace="http://example.com/stockquote/definitions"
        location="http://example.com/stockquote/stockquote.wsdl"/>

   <message name="GetLastTradePriceInput">
      <part name="body" element="xsd1:TradePriceRequest"/>
   </message>
               ...
</definitions>

5.1.3 WSDL Import location Attribute Syntax (WSDL import の location 属性の構文)

WSDL 1.1 は,wsdl:import 要素に location 属性が必須かどうか, あるいは,その内容がどうあるべきかについて,明確ではない。

R2007 DESCRIPTION は wsdl:import 要素の location 属性に空ではない値を指定しなければならない (MUST)。

wsdl:importxsd:import に倣ったものであるが, wsdl:import には location 属性が必須であるのに対して, xsd:import の対応する属性である schemaLocation は省略可能である。 location が必須であることと整合性を取るために,その内容は空であってはならない。

5.1.4 WSDL Import location Attribute Semantics (WSDL import の location 属性のセマンティクス)

WSDL 1.1 は,WSDL 処理系が wsdl:import を見つけた場合,その要素の location 属性に指定された URI から実際に WSDL 文書を取り出して処理しなければならないのかどうか,明確ではない。

R2008 DESCRIPTION の中では, wsdl:import 要素の location 属性の値はヒントとして扱うことが望ましい (SHOULD)。C

これは,WSDL 処理系が WSDL 記述を wsdl:import 要素の location 属性に指定された URI から取り出してもよいが,必ずしもそうする必要はないことを意味する。 というのも,WSDL 処理系は与えられた名前空間の WSDL 記述の位置を特定する,別の手段をもっていてもよいからである。 たとえば,WSDL 処理系は WSDL 記述を キャッシュ又は組み込みでもっていてもよいし, メタデータリポジトリー又は UDDI サーバーから取り出してもよい。

5.1.5 Placement of WSDL import Elements (WSDL import 要素の位置)

WSDL 1.1 の 3.1 節の例 3 は,wsdl:import の位置についての混乱を引き起こす。

R2022 DESCRIPTION の中に wsdl:import 要素が現れる場合,それは, wsdl:documentation を除く, WSDL 名前空間の他のすべての要素よりも前になければならない (MUST)。

R2023 DESCRIPTION の中に wsdl:types 要素が現れる場合,それは, wsdl:documentation 及び wsdl:import を除く, WSDL 名前空間の他のすべての要素よりも前になければならない (MUST)。

次に例を示す:

間違っている例:

<definitions name="StockQuote"
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

   <import namespace="http://example.com/stockquote/definitions"
         location="http://example.com/stockquote/stockquote.wsdl"/>

   <message name="GetLastTradePriceInput">
       <part name="body" type="tns:TradePriceRequest"/>
   </message>
               ...
   <service name="StockQuoteService">
      <port name="StockQuotePort" binding="tns:StockQuoteSoap">
           ....
      </port>
   </service>

   <types>
      <schema targetNamespace="http://example.com/stockquote/schemas"
               xmlns="http://www.w3.org/2001/XMLSchema">
           .......
      </schema>
   </types>
</definitions>

正しい例:

   <definitions name="StockQuote"
      targetNamespace="http://example.com/stockquote/definitions">

     <import namespace="http://example.com/stockquote/base"
       location="http://example.com/stockquote/stockquote.wsdl"/>

      <message name="GetLastTradePriceInput">
         <part name="body" element="..."/>
      </message>
                  ...
   </definitions>

正しい例:

<definitions name="StockQuote"
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

  <types>
     <schema targetNamespace="http://example.com/stockquote/schemas"
          xmlns="http://www.w3.org/2001/XMLSchema">
           .......
     </schema>
   </types>

   <message name="GetLastTradePriceInput">
        <part name="body" element="tns:TradePriceRequest"/>
   </message>
               ...
   <service name="StockQuoteService">
      <port name="StockQuotePort" binding="tns:StockQuoteSoap">
           ....
      </port>
   </service>
</definitions>

5.1.6 XML Version Requirements (XML 版数の要件)

WSDL 1.1 又は XML Schema 1.0 のどちらも,XML の特定の版数を要求してはいない。 相互運用性のため, WSDL 文書及びそれらが取り込むスキーマは XML の 1.0 版を使わなければならない。

R4004 DESCRIPTION は, Extensible Markup Language (XML) の 1.0 版 W3C 勧告を使用しなければならない (MUST)。

5.1.7 WSDL and the Unicode BOM (WSDL と Unicode の BOM)

XML 1.0 では,UTF-8 文字エンコーディングにおいても BOM を含めてもよいことになっており,WSDL 処理系はそれを受け入れる用意がなければならない。

R4002 DESCRIPTION には Unicode の Byte Order Mark (BOM) を含めてもよい (MAY)。C

5.1.8 Acceptable WSDL Character Encodings (許容可能な WSDL 文字エンコーディング)

このプロファイルでは SOAP と WSDL との両方に一貫して UTF-8 又は UTF-16 のいずれかを要求している (R1012 参照)。

R4003 DESCRIPTION は UTF-8 又は UTF-16 の いずれかの文字エンコーディングを使わなければならない (MUST)。

5.1.9 Namespace Coercion (名前空間の強制変更)

wsdl:import における名前空間の強制変更 (namespace coercion) は, このプロファイルでは許されない。

R2005 取り込まれる (imported) 側の記述 (description) の wsdl:definitions 要素の targetNamespace 属性の値は, 取り込む (importing) 側の DESCRIPTION の wsdl:import 要素の namespace 属性の値と一致しなければならない (MUST)。

5.1.10 WSDL documentation Element (WSDL の documentation 要素)

WSDL 1.1 仕様のスキーマと本文とは,wsdl:documentation 要素をどこに置くべきかについて整合性がとれていない。

R2020 wsdl:documentation 要素は,DESCRIPTION の wsdl:import 要素の子要素として現れてもよい (MAY)。WSDL12

R2021 wsdl:documentation 要素は,DESCRIPTION の wsdl:part 要素の子要素として現れてもよい (MAY)。WSDL12

R2024 wsdl:documentation 要素は, DESCRIPTION の wsdl:definitions 要素の最初の子要素として現れてもよい (MAY)。WSDL12

5.1.11 WSDL Extensions (WSDL 拡張)

この,又は他の WS-I プロファイルで明示的に規定されていない WSDL 拡張のサポートを要求することは, それらの拡張を理解するように作られていない開発ツールとの間の,相互運用性の問題に発展する。

R2025 WSDL 拡張を含む DESCRIPTION は, このプロファイルの他の要件と矛盾する拡張を使用してはならない (MUST NOT)。

R2026 DESCRIPTION は, このプロファイルへの適合性を表示するいかなる要素 (wsdl:binding, wsdl:portType, wsdl:message, wsdl:types 又は wsdl:import) にも wsdl:required 属性の値が "true" である拡張要素を含むべきではない (SHOULD NOT)。

R2027 記述 (description) の中の WSDL 名前空間の要素の処理の最中に, 利用者 (consumer) がその子要素の中に WSDL 拡張要素を発見し, それが wsdl:required 属性に "true" の値を指定されており, かつそれが理解できない又は処理できない場合, CONSUMER は,その WSDL 名前空間内の要素の処理を失敗 (fail) しなければならない (MUST)。

WSDL 記述を読み込んで Web サービスのソフトウェアのインスタンスを生成する開発ツールは, 未知の WSDL 拡張に対する解釈を組み込まれていないかもしれない。 よって,必須の (required) WSDL 拡張は避けるべきである。 利用方法及び意味について仕様が公開されていない必須の WSDL 拡張を使用することは, その拡張の作者を除く全員に対して,潜在的に克服不可能な相互運用上の問題を課してしまう。 利用方法及び意味について仕様が公開されている必須の WSDL 拡張を使用することは, ここでの要件を規定するに至った相互運用上の問題を軽減するが, 解消するものではない。

次に示す要素は,属性による拡張だけが有効である:

次に示す要素は,属性のほかに,要素による拡張も有効である:

5.2 Types (型)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

WSDL 1.1 の wsdl:types 要素は,記述される Web サービスに適用されるデータ型定義を記述する。 このプロファイルでは,このプロファイルに対する適合性を表示する WSDL の要素に参照される wsdl:types 要素の内容の,該当する部分に対して次の制約を課す:

5.2.1 QName References (QName 参照)

XML Schema は, 各 QName 参照が, 対象名前空間 (target namespace) 又は取り込まれた名前空間 (imported namespace) [xsd:import 要素で明示的に指定されたもの] のいずれかを使うことを要求している。 入れ子の取り込み (nested imports) のみによって表現された名前空間への QName 参照は許されていない。

WSDL 1.1 は,WSDL 要素からの QName 参照にどのスキーマ対象名前空間が適しているかについて,明らかではない。 このプロファイルでは, xsd:schema 要素で定義された対象名前空間と, 取り込まれた名前空間との両方に対して, WSDL 要素からの QName 参照を許している。 XML Schema と同様に, (xsd:schematargetNamespace 属性を通して, 又は, xsd:importnamespace 属性を通して) WSDL ファイルから直接に参照されていない名前空間も,QName 参照して使うことができる。 入れ子の取り込みを通してのみ定義された名前空間を QName 参照することは,許されていない。

R2101 DESCRIPTION は, 取り込まれて (imported) もいなければ,参照する側の (referring) WSDL 文書に定義されてもいない 名前空間に属する要素を QName で参照してはならない (MUST NOT)。

R2102 DESCRIPTION の中でのスキーマの構成要素に対する QName 参照は, xsd:schema 要素の targetNamespace 属性に定義された名前空間か, xsd:schema 要素の中にある xsd:import 要素の namespace 属性で定義された名前空間かの, いずれかを使わなければならない (MUST)。

5.2.2 Schema targetNamespace Syntax (スキーマの targetNamespace 構文)

wsdl:types 要素の子供であるすべての xsd:schema 要素に targetNamespace を要求することはよい方法であり, WSDL 文書の作成者に対する負担も最小限で済み,明確に定義されていない状況に落ちることを避けられる。

R2105 DESCRIPTION の wsdl:types 要素に含まれるすべての xsd:schema 要素は, targetNamespace 属性に有効な null でない値をもたなければならない (MUST)。 ただし,xsd:schema 要素が,xsd:import, xsd:annotation 又はその両方だけを子要素としてもつ場合を除く。

5.2.3 soapenc:Array (配列)

WSDL 1.1 の 2.2 節にある,配列 (array) 型を宣言することについての推奨は, 多様な解釈をされてきたため,相互運用性の問題となっている。 さらに,配列を宣言するにはもっと明確な方法がある。

R2110 DESCRIPTION の中では 配列 (array) 宣言は soapenc:Array 型を拡張又は制限してはならない (MUST NOT)。

R2111 DESCRIPTION の中では 配列 (array) 宣言は型宣言に wsdl:arrayType 属性を使用してはならない (MUST NOT)。

R2112 DESCRIPTION の中では 配列 (array) 宣言のラッパー要素の名前は ArrayOfXXX の形式で名前付けすべきではない (SHOULD NOT)。

R2113 シリアライズされた配列をもつ MESSAGE は soapenc:arrayType 属性を含んではならない (MUST NOT)。

次に例を示す:

間違っている例:

次の WSDL 記述が与えられた場合:

<xsd:element name="MyArray2" type="tns:MyArray2Type"/>
<xsd:complexType name="MyArray2Type"
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" >
  <xsd:complexContent>
     <xsd:restriction base="soapenc:Array">
       <xsd:sequence>
          <xsd:element name="x" type="xsd:string"
           minOccurs="0" maxOccurs="unbounded"/>
       </xsd:sequence>
       <xsd:attribute ref="soapenc:arrayType"
        wsdl:arrayType="tns:MyArray2Type[]"/>
   </xsd:restriction>
 </xsd:complexContent>
</xsd:complexType>

SOAP メッセージは次のようにシリアライズされる (名前空間宣言は明確化のため省略):

<MyArray2 soapenc:arrayType="tns:MyArray2Type[]" >
  <x>abcd</x>
  <x>efgh</x>
</MyArray2>

正しい例:

次の WSDL 記述が与えられた場合:

<xsd:element name="MyArray1" type="tns:MyArray1Type"/>
<xsd:complexType name="MyArray1Type">
  <xsd:sequence>
   <xsd:element name="x" type="xsd:string"
    minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

SOAP メッセージは次のようにシリアライズされる (名前空間宣言は明確化のため省略):

<MyArray1>
  <x>abcd</x>
  <x>efgh</x>
</MyArray1>

5.2.4 WSDL and Schema Definition Target Namespaces (WSDL とスキーマ定義の対象名前空間)

スキーマで定義された名前と, WSDL 定義で割り当てられた名前とは, 別々のシンボル空間に属している。

R2114 DESCRIPTION の中で, WSDL 定義の対象名前空間 (target namespace) と, スキーマ定義の対象名前空間 (target namespace) とは,同じであってもよい (MAY)。 WSDL12

5.3 Messages (メッセージ)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

WSDL 1.1 では wsdl:message 要素が伝送されるデータの抽象的な定義を表現する。 wsdl:binding 要素が抽象的な定義を特定の伝送路上の形式 (wire format) に結びつける。 このプロファイルでは wsdl:message 要素の使用と,適合する wsdl:binding 要素が wsdl:message 要素を使用する方法とに関して次の制約を課す:

この節では,要件を簡略化し分かりやすくするため,次の定義が使われる。

「rpc-literal バインディング」とは, その子要素の wsdl:operation がすべて rpc-literal オペレーションである wsdl:binding 要素のことである。

「rpc-literal オペレーション」とは, wsdl:binding の子要素である wsdl:operation で, その子孫である soapbind:body 要素のそれぞれが use 属性に "literal" の値を指定しており, そのそれぞれが次のいずれかであるもののことである:

  1. style 属性に "rpc" の値を指定している,又は,
  2. style 属性に "rpc" の値を指定している soapbind:binding の子要素であり, かつ,それ自体には style 属性を指定していない。

「document-literal バインディング」とは, その子要素の wsdl:operation がすべて document-literal オペレーションである wsdl:binding 要素のことである。

「document-literal オペレーション」とは, wsdl:binding の子要素である wsdl:operation で, その子孫である soapbind:body 要素のそれぞれが use 属性に "literal" の値を指定しており, そのそれぞれが次のいずれかであるもののことである:

  1. style 属性に "document" の値を指定している,
  2. style 属性に "document" の値を指定している soapbind:binding の子要素であり, かつ,それ自体には style 属性を指定していない,又は,
  3. style 属性を指定していない soapbind:binding の子要素であり, かつ,それ自体には style 属性を指定していない。

5.3.1 Bindings and Parts (バインディングと part)

何個の wsdl:part 要素が document-literal 及び rpc-literal バインディングに許容又は要求されているか,そして,それらはどのように定義されるべきかについて,多様な解釈が存在する。

R2201 DESCRIPTION の中の document-literal バインディングは,それぞれの soapbind:body 要素に parts 属性が指定された場合,その値として, 多くとも 1 個の part をもたなければならない (MUST)。

R2210 DESCRIPTION の中の document-literal バインディングが soapbind:body 要素に parts 属性を指定しない場合, 対応する抽象的な wsdl:message は,0個又は1個の wsdl:part を定義しなければならない (MUST)。

R2202 DESCRIPTION の中の wsdl:binding は,soap:Body を構成する0個の part を指定する soapbind:body 要素をもってもよい (MAY)。

R2203 DESCRIPTION の中の rpc-literal バインディングは,その soapbind:body 要素の中で, type 属性を使って定義された wsdl:part だけを参照しなければならない (MUST)。

R2211 rpc-literal バインディングで記述された MESSAGE は, part のアクセサー要素に対して xsi:nil 属性に "1" 又は "true" の値を指定したものをもってはならない (MUST NOT)。

R2207 DESCRIPTION の中の wsdl:message は, rpc-literal バインディングで wsdl:partsoapbind:body に参照されていない限りにおいて, element 属性を使う wsdl:part をもってもよい (MAY)。

R2204 DESCRIPTION の中の document-literal バインディングは, その soapbind:body 要素のそれぞれにおいて, element 属性を使って定義された wsdl:part 要素だけを参照しなければならない (MUST)。

R2208 DESCRIPTION の中のバインディングは, その soapbind:body 要素によって参照されるのと 同じ wsdl:message の中の wsdl:part を参照する soapbind:header 要素をもってもよい (MAY)。

Document スタイルでの part が 0 個の wsdl:message 要素の使用は, 空の soap:Body を含むメッセージを送受信するオペレーションを許容するために, 許されている。 RPC スタイルでの part が 0 個の wsdl:message 要素の使用は, 引数,返却値,又はその両方が存在しないオペレーションを許容するために, 許されている。

document-literal バインディングでは,このプロファイルは,多くとも1つの part が, 抽象レベルにおいて element 形式を用いて定義され, soap:Body にシリアライズされることを要求している。

wsdl:part 要素が type 属性を使って定義された場合, その part の伝送路上の形式は, (XML Schema で) 暗黙的に, minOccurs 属性の値を "1" に, maxOccurs 属性の値を "1" に,そして nillable 属性の値を "false" に, それぞれ指定したものと同等である。

5.3.2 Bindings and Faults (バインディングとフォルト)

soapbind:fault, soapbind:header 及び soapbind:headerfault を記述する wsdl:part 要素をどう定義すべきかについて,いくつかの解釈がある。

R2205 DESCRIPTION の中の wsdl:binding は, その soapbind:header, soapbind:headerfault 及び soapbind:fault 要素のそれぞれにおいて, element 属性を使って定義された wsdl:part 要素だけを参照しなければならない (MUST)。

フォルトやヘッダーにはパラメーターが含まれないため, soapbind:fault, soapbind:header 及び soapbind:headerfault は, WSDL 1.1 に従い, style 属性の値が "document" であることを想定している。 R2204 は, style 属性の値が "document" である wsdl:part 要素で soapbind:body にバインドされたものはすべて element 属性で定義されることを要求している。 この要件は,soapbind:fault, soapbind:header 及び soapbind:headerfault においても同様である。

5.3.3 Unbound portType Element Contents (バインディングされていない portType 要素の内容)

WSDL 1.1 は, wsdl:bindingwsdl:portType で定義される内容のバインディングを指定しないままでおいておくことが許されるのかどうか,明らかではない。

R2209 DESCRIPTION の中の wsdl:binding は, そのバインディングが参照する先の wsdl:portType に属する wsdl:message の各 part を, soapbind:body, soapbind:header, soapbind:fault 又は soapbind:headerfault のいずれか一つにバインドすることが望ましい (SHOULD)。

portType は名前付けされたオペレーション一式とそれに関連付けられた抽象的なメッセージとをもつ抽象的な契約 (abstract contract) を定義する。 禁止されているわけではないが, portType に指定される抽象的な input, output 及び fault メッセージの各 part は, WSDL 1.1 の 3 節で定義されている SOAP バインディングを使う場合, soapbind:body, soapbind:header 等の適切な部分にバインドされることが想定されている。

5.3.4 Declaration of part Elements (part 要素の宣言)

WSDL 1.1 の 3.1 節の例 4 及び 5 は,間違って wsdl:part 要素の element 属性の有効な値としてスキーマのデータ型 ("xsd:string" など) を示している。

R2206 DESCRIPTION の中の wsdl:messageelement 属性を使う wsdl:part をもつ場合, その属性の中で,グローバル要素宣言を参照しなければならない (MUST)。

次に例を示す:

間違っている例:

  <message name="GetTradePriceInput">
      <part name="tickerSymbol" element="xsd:string"/>
      <part name="time" element="xsd:timeInstant"/>
  </message>

間違っている例:

  <message name="GetTradePriceInput">
      <part name="tickerSymbol" element="xsd:string"/>
  </message>

正しい例:

  <message name="GetTradePriceInput">
      <part name="body" element="tns:SubscribeToQuotes"/>
  </message>

5.4 Port Types (ポート型)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

WSDL 1.1 では wsdl:portType 要素が抽象的なオペレーションの集合をグループ化するために使われる。このプロファイルでは wsdl:portType 要素の使用に関して次の制約を課す:

5.4.1 Ordering of part Elements (part の並び順)

parameterOrder 属性を許すことは, コードジェネレーターがメソッドシグネチャと伝送路上のメッセージのインスタンスとを対応づける助けになる。

R2301 MESSAGE の soap:Body の中での要素の並び順は, それを記述した wsdl:message の中の wsdl:part の並び順と同じでなければならない (MUST)。

R2302 DESCRIPTION は wsdl:operation 要素の parameterOrder 属性を,コードジェネレーターに対するヒントとして,返却値及びメソッドシグネチャを示すために使用してもよい (MAY)。

5.4.2 Allowed operations (許容されるオペレーション)

Solicit-Response 及び Notification は WSDL 1.1 では十分に規定されておらず, さらに,WSDL 1.1 はそれらに対するバインディングも定義していない。

R2303 DESCRIPTION は wsdl:portType の定義に Solicit-Response 及び Notification 型のオペレーションを使用してはならない (MUST NOT)。

5.4.3 Distinctive operations (区別できるオペレーション)

一つの wsdl:portType の中でのオペレーション名のオーバーロードは, このプロファイルでは禁止している。

R2304 DESCRIPTION の中の一つの wsdl:portType の定義を取り出したとき, その中に定義される operationname 属性は,それぞれ別の値をもたなければならない (MUST)。

この要件は,一つの wsdl:portType の中の wsdl:operation に対してのみ適用されることに注意。 wsdl:portType は他の wsdl:portType に属する wsdl:operation と同じオペレーション名を使ってもよい。

5.4.4 parameterOrder Attribute Construction (parameterOrder 属性の構築)

WSDL 1.1 は,wsdl:portTypeparameterOrder 属性がどう構築されるべきか,明らかではない。

R2305 DESCRIPTION の中の wsdl:portTypeparameterOrder 属性が存在する場合, この parameterOrder は, outputmessage 要素に定義される wsdl:part 要素の中から,最大1つの wsdl:part を取り除いたものとして 構築されなければならない (MUST)。

parameterOrder 属性の値にある wsdl:part のリストから outputmessage に属する wsdl:part が1つ省略された場合, その省略された wsdl:part が返却値 (return value) である。 返却値の型に制約はない。 wsdl:part が省略されない場合,返却値はない。

5.4.5 Exclusivity of type and element Attributes (type 及び element 属性の排他性)

WSDL 1.1 は, wsdl:messagewsdl:part を定義するのに type 及び element 属性の両方を指定できないことを 明記していない。

R2306 DESCRIPTION の中の wsdl:message は, 同じ wsdl:part に対して type 及び element 属性の両方を指定してはならない (MUST NOT)。

5.5 Bindings (バインディング)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

WSDL 1.1 では wsdl:binding 要素が,特定の wsdl:portType で定義された operation 及び message に対する具体的なプロトコル及びデータ形式を提供している。 このプロファイルでは適合する binding の使用に次の制約を課す:

5.5.1 Use of SOAP Binding (SOAP バインディングの使用)

このプロファイルは,バインディングの選択肢を,十分に定義され,最も一般的に利用されている SOAP バインディングに限定している。 MIME 及び HTTP GET/POST バインディングは,このプロファイルでは許されていない。

R2401 DESCRIPTION の中の wsdl:binding 要素は, WSDL 1.1 の第 3 節で定義された WSDL の SOAP バインディングを使用しなければならない (MUST)。

ここでは,適合する wsdl:binding 要素の構築についての要件を課していることに注意。 これは,記述 (description) 全体に対する要件を課しているわけではない。 特に,WSDL 文書が,適合しない wsdl:binding 要素をもつことを禁止しているわけではない。

5.6 SOAP Binding (SOAP バインディング)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

WSDL 1.1 は SOAP 1.1 のエンドポイントに対するバインディングを定義する。 このプロファイルでは WSDL 1.1 で定義されている SOAP バインディングの使用を必須とし, その使用に関して次の制約を課す:

5.6.1 Specifying the transport Attribute (transport 属性の指定)

transport 属性について,WSDL 1.1 仕様の本文とスキーマとの間の矛盾がある。 WSDL 1.1 仕様ではそれを必須とし,スキーマはそれを省略可能としている。

R2701 DESCRIPTION の中の wsdl:binding 要素は, その soapbind:binding 子要素が transport 属性を指定するよう構築されなければならない (MUST)。

5.6.2 HTTP Transport (HTTP トランスポート)

このプロファイルでは,トランスポートのプロトコルを HTTP に制限している。

R2702 DESCRIPTION の中の wsdl:binding は, SOAP の HTTP プロトコルバインディングを指定しなければならない (MUST)。 具体的には,その soapbind:binding 子要素の transport 属性の値は, "http://schemas.xmlsoap.org/soap/http" でなければならない (MUST)。

この要件は HTTPS の使用を制限しているわけではないことに注意。R5000 参照。

5.6.3 Consistency of style Attribute (style 属性の整合性)

style が "document" か "rpc" かは wsdl:operation のレベルで指定されるので, 個々の wsdl:operation に相異なる style をもつ wsdl:binding を許してしまう。これは,相互運用上の問題となる。

R2705 DESCRIPTION の中の wsdl:binding は, rpc-literal バインディング又は document-literal バインディングのいずれかを使用しなければならない (MUST)。

5.6.4 Encodings and the use Attribute (エンコーディングと use 属性)

このプロファイルでは相異なるエンコーディングを (SOAP エンコーディングを含め) 禁止している。

R2706 DESCRIPTION の中の wsdl:binding は, すべての soapbind:body, soapbind:fault, soapbind:header 及び soapbind:headerfault 要素に対して, use 属性の値を "literal" としなければならない (MUST)。

5.6.5 Default for use Attribute (use 属性のデフォルト)

WSDL 1.1 仕様に, soapbind:body, soapbind:header 及び soapbind:headerfault 要素において, use 属性は省略可能かどうか,そして省略可能な場合,省略したときの意味はどうなるか という点について,本文とスキーマとの間に不整合がある。

R2707 DESCRIPTION の中の wsdl:bindingsoapbind:body, soapbind:fault, soapbind:header 又は soapbind:headerfault 要素に use 属性を指定しなかった場合, use 属性は "literal" の値をもつものとみなさなければならない (MUST)。

5.6.6 Multiple bindings for portType Elements (portType 要素への複数のバインディング)

このプロファイルでは同じ portType に対する複数のバインディングを明示的に許容する。

R2709 DESCRIPTION の中の wsdl:portType は, 同一又は別の WSDL 文書の中に, それを参照する wsdl:binding を0個以上もってよい (MAY)。

5.6.7 Wire Signatures for operations (オペレーションの伝送路シグネチャ)

複数のオペレーションをサポートするエンドポイントは, 受信する入力メッセージを元に, どのオペレーションが起動されたかを曖昧性なしに識別する必要がある。 これは, 一つのエンドポイントに対して wsdl:binding に指定されたすべてのオペレーションが, 一意の伝送路シグネチャ (wire signature) をもつ場合にのみ可能である。

R2710 DESCRIPTION の中の1つの wsdl:binding に属する operation は, それぞれ相異なる伝送路シグネチャをもたなければならない (MUST)。

このプロファイルでは,wsdl:binding の中にある operation の伝送路シグネチャ (wire signature) を, それが記述する SOAP 入力 (input) メッセージの soap:Body の子要素の完全修飾名 (fully qualified name) であると定義している。 soap:Body の内容が空の場合,伝送路シグネチャは空文字列である。

rpc-literal バインディングの場合,operation の名前は part のアクセサーに対するラッパーとして使用される。 document-literal バインディングの場合は operation の名前をもつラッパーが存在しないので, メッセージのシグネチャがこの要件を満足するよう,正しく設計されなければならない。

5.6.8 Multiple ports on an Endpoint (一つのエンドポイントに対する複数の port)

1つのネットワーク上のエンドポイントにある,2つの異なる wsdl:port に宛てられた input のメッセージが伝送路上で区別できない場合, それによって起動される wsdl:port を決定できなくなる可能性がある。 これは相互運用上の問題になるかもしれない。 しかし,(たとえば,SOAP のバージョンの違い,アプリケーションのバージョンの違い,異なるプロファイルへの適合など) 1つ以上の port を1つのエンドポイントに置いた方がいい場合もありうる。 ゆえに,このプロファイルではそれを許している。

R2711 DESCRIPTION は,soapbind:address 要素の location 属性の値が同じ wsdl:port を複数もつべきではない (SHOULD NOT)。

5.6.9 Child Element for Document-Literal Bindings (document-literal バインディングの子要素)

WSDL 1.1 は, document-literal バインディングにおいて soap:Body の子要素が何であるかについて, 完全に明確ではない。

R2712 document-literal バインディングは, 伝送路上において, soap:Body の子要素が 対応する wsdl:message の一つの part で参照されるグローバル要素宣言のインスタンスである MESSAGE として表現されなければならない (MUST)。

5.6.10 One-Way Operations (one-way オペレーション)

one-way のオペレーションを行う場合,どのように HTTP を使うべきかについていくつかの解釈がある。

R2714 One-way オペレーションの場合,INSTANCE は SOAP エンベロープを含む HTTP レスポンスを返してはならない (MUST NOT)。 具体的には,レスポンスの HTTP entity-body は空でなければならない (MUST)。

R2750 CONSUMER は,one-way オペレーションからのレスポンスとして返される SOAP レスポンスを無視しなければならない (MUST)。

R2727 One-way オペレーションの場合,CONSUMER は HTTP の正常終了レスポンスの状態コード (すなわち,2xx) が, メッセージが正当であるとか,受信側がそれを処理することの印であると解釈してはならない (MUST NOT)。

one-way オペレーションは SOAP レスポンスを生成しない。 よって,このプロファイルは,one-way オペレーションのレスポンスとして SOAP エンベロープを送ることを禁止している。 これは,one-way オペレーションの伝送が,処理レベルのレスポンス又はエラーになってはならないことを意味する。 たとえば,SOAP の Fault 要素を含む HTTP の "500 Internal Server Error" レスポンスは返されてはならない。

one-way オペレーションにおける HTTP レスポンスは,メッセージの伝送の成功又は失敗を示す。 HTTP プロトコルでサポートされているレスポンスコードの意味から, このプロファイルは, "200" 及び "202" が, one-way メッセージが受信されたことを示すものと送信者が期待すべきレスポンス状態コードであると規定している。 伝送が成功したことは,SOAP 処理層及びアプリケーションロジックがメッセージを正しいと確認したとか, それを処理することが確定したとかを示すものではない。

HTTP 1.1 がレスポンス状態コードの "200" と "202" とに違う意味を割り当てているのにもかかわらず, このプロファイルでは,リクエストの発信者がそれらを同じとみなさなければならない。 このプロファイルが両方の状態コードを受け付けるのは,SOAP の実装によっては下位にある HTTP 層をほとんど制御できず,どちらの状態コードを送るか制御できないからである。

5.6.11 Namespaces for soapbind Elements (soapbind 要素の名前空間)

どの名前空間が soap:Envelope の多様な子供の子要素と関連付けられているかについて混乱があり, 相互運用を困難にしている。 このプロファイルではそれらを規定している。

R2716 DESCRIPTION の中の document-literal バインディングは, それが含む soapbind:body, soapbind:header, soapbind:headerfault 及び soapbind:fault 要素に namespace 属性を指定してはならない (MUST NOT)。

R2717 DESCRIPTION の中の rpc-literal バインディングは,それが含む soapbind:body 要素に namespace 属性が指定されなければならず (MUST), その値は絶対 URI でなければならない (MUST)。

R2726 DESCRIPTION の中の rpc-literal バインディングは,それが含む soapbind:header, soapbind:headerfault 及び soapbind:fault 要素に namespace 属性を指定してはならない (MUST NOT)。

document-literal の SOAP バインディングでは, soap:Body のシリアライズされた子要素は, その要素を定義したスキーマの targetNamespace から名前空間を得る。 soapbind:body 要素の namespace 属性の指定はその要素の名前空間をオーバーライドするかもしれない。 それはこのプロファイルでは許されていない。

それとは反対に, rpc-literal の SOAP バインディングでは, soap:Body のシリアライズされた子要素はラッパー要素であり, その名前空間は soapbind:body 要素の namespace 属性の値であり, そのローカル名 (local name) はオペレーションの名前か, あるいはオペレーションの名前の最後に "Response" をつけたものである。 namespace 属性は,soap:Body 要素の子要素を名前空間修飾することを保証するため,省略可能ではなく必須である。

5.6.12 Consistency of portType and binding Elements (portType 及び binding 要素の整合性)

WSDL の記述 (description) は,wsdl:portTypewsdl:binding との両方のレベルで整合していなければならない。

R2718 DESCRIPTION の中の wsdl:binding は, wsdl:operation の集合が,それが参照する先の wsdl:portType と同一でなければならない (MUST)。C

5.6.13 Describing headerfault Elements (headerfault 要素の記述)

soapbind:headerfault について,WSDL の仕様本文とスキーマとの間の矛盾がある。

R2719 DESCRIPTION の中の wsdl:binding は, 既知のヘッダーフォルトが存在しない場合, soapbind:headerfault 要素を指定しなくてもよい (MAY)。

WSDL 1.1 のスキーマは,オペレーションの wsdl:input 及び wsdl:output 要素に soapbind:headerfault を指定することを必須としているが, WSDL 1.1 の仕様本文では省略可能になっている。本文が正しい。

5.6.14 Enumeration of Faults (フォルトの列挙)

Web サービスの記述は,サービスの定義時に知られているすべてのフォルトを含むべきである。 また, Web サービスが定義されたときには認識されていなかった,新しいフォルトの生成も許容する必要がある。

R2740 DESCRIPTION の中の wsdl:binding は,既知の各フォルトを記述する soapbind:fault を含むべきである (SHOULD)。

R2741 DESCRIPTION の中の wsdl:binding は,既知の各ヘッダーフォルトを記述する soapbind:headerfault を含むべきである (SHOULD)。

R2742 MESSAGE は SOAP フォルトに, 対応する WSDL 記述の中の wsdl:fault 要素に記述されていない フォルトの detail エントリーを含んでもよい (MAY)。

R2743 MESSAGE は SOAP ヘッダーブロックに, 対応する WSDL 記述の中の wsdl:headerfault 要素に記述されていない ヘッダー処理関連のフォルトの詳細記述を含んでもよい (MAY)。

5.6.15 Type and Name of SOAP Binding Elements (SOAP バインディング要素の型と名前)

WSDL 1.1 のスキーマは WSDL 1.1 の仕様本文との間に, soapbind:header 及び soapbind:headerfault 要素の属性の名前と型とについて 食い違いがある。

R2720 DESCRIPTION の中の wsdl:binding は, それが含むすべての soapbind:header 要素及び soapbind:headerfault 要素に対して, 属性名 part をスキーマ型 "NMTOKEN" として使用しなければならない (MUST)。

R2749 DESCRIPTION の中の wsdl:binding は, soapbind:header 及び soapbind:headerfault 要素に対して parts という名前の属性を指定してはならない (MUST)。

WSDL のスキーマは属性名 "parts" でスキーマ型 "NMTOKENS" としている。 soapbind:header 及び soapbind:headerfault 要素は一つの wsdl:partを参照するので,スキーマが間違っている。

次に例を示す:

正しい例:

<binding name="StockQuoteSoap" type="tns:StockQuotePortType">
  <soapbind:binding style="document"
                transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="SubscribeToQuotes">
      <input message="tns:SubscribeToQuotes">
        <soapbind:body parts="body" use="literal"/>
        <soapbind:header message="tns:SubscribeToQuotes"
             		part="subscribeheader" use="literal"/>
     </input>
   </operation>
</binding>

5.6.16 name Attribute on Faults (fault の name 属性)

WSDL 1.1 の仕様本文とスキーマとの間に不整合がある。WSDL 1.1 のスキーマには name 属性はない。

R2721 DESCRIPTION の中の wsdl:binding は, それが含むすべての soapbind:fault 要素に対して name 属性を指定しなければならない (MUST)。

R2754 DESCRIPTION の中で, soapbind:fault 要素の name 属性の値は, その親の wsdl:fault 要素の name 属性の値と一致しなければならない (MUST)。

5.6.17 Omission of the use Attribute (use 属性の省略)

WSDL 1.1 の仕様本文とスキーマとの間に,use 属性に関する不整合がある。

R2722 DESCRIPTION の中の wsdl:binding は, それが含む soapbind:fault 要素に use 属性を指定してもよい (MAY)。 C

R2723 DESCRIPTION の中の wsdl:binding の中で, それが含む soapbind:fault 要素にuse 属性が存在する場合, その値は "literal" でなければならない (MUST)。

R2728 DESCRIPTION の中の wsdl:binding が, それが含む soapbind:fault 要素に use 属性を定義しない場合, その値は "literal" と等しいと考えなければならない (MUST)。 C

WSDL 1.1 の 3.6 節は soapbind:fault 要素に use 属性が必須としているが, スキーマでは use 属性が省略可能になっている。 このプロファイルでは,soapbind:body と整合性を取るため,この属性を省略可能としている。

use 属性が省略可能なので,このプロファイルでは省略されたときのデフォルト値を決めている。

最後に, プロファイル自身が整合していることを確かにするため, use 属性の許される値を "literal" だけにしている。

5.6.18 Consistency of Messages with Descriptions (メッセージと記述との整合性)

次の要件は, インスタンスが WSDL 記述に合わないメッセージを受け取った場合, インスタンスがそれにも関わらずそのメッセージを処理する責任を負う場合を除いて, フォルトが生成されるべきであるということを規定している。

SOAP 処理モデルに規定されている通り, (a) Envelope 要素の名前空間が正しくない場合,"VersionMismatch" フォルトが生成されなければならない (b) インスタンスが,soap:mustUnderstand 属性の値が "1" になっている SOAP ヘッダーを理解できない場合,"MustUnderstand" フォルトが生成されなければならない。 それ以外で,メッセージが WSDL 記述と矛盾している場合,"Client" フォルトが生成されるべきである。

R2724 INSTANCE が WSDL 記述と矛盾するメッセージを受け取った場合, "MustUnderstand" 又は "VersionMismatch" のフォルトが生成されるのでなければ, faultcode が "Client" の soap:Fault を生成することが望ましい (SHOULD)。

R2725 INSTANCE が WSDL 記述と矛盾するメッセージを受け取った場合, "VersionMismatch", "MustUnderstand" 及び "Client" の フォルトの条件を,この順に調べなければならない (MUST)。

5.6.19 Response Wrappers (レスポンスのラッパー)

WSDL 1.1 の 3.5 節は, RPC レスポンスのラッパー要素が wsdl:operation の名前と同じでなければならないと解釈することも可能である。

R2729 rpc-literal バインディングで記述されたレスポンスの MESSAGE は, ラッパー要素の名前を, 対応する wsdl:operation の名前の後ろに "Response" という文字列を付けたものとしなければならない (MUST)。

5.6.20 Namespace for Part Accessors (part アクセサーの名前空間)

rpc-literal の SOAP メッセージにおいて,WSDL 1.1 は,パラメーター及び返却値のアクセサー要素がどの名前空間に属するのか (もし何かの名前空間に属するとして) という点が不明確である。 処理系によってこの解釈が異なり,相互運用の問題となる。

R2735 rpc-literal バインディングに記述された MESSAGE は, 引数及び返却値に使用される part のアクセサー要素が, いかなる名前空間にも属さないものとして取り扱わなければならない (MUST)。

いずれかの選択肢の一つに絞ることが,相互運用を達成するためには不可欠である。 このプロファイルは,単純で,すべての場合をカバーし,論理的に矛盾しないことから,アクセサー要素がどの名前空間にも属させないことにした。

5.6.21 Namespaces for Children of Part Accessors (part アクセサーの子要素の名前空間)

rpc-literal の SOAP メッセージにおいて, WSDL 1.1 は, 対応する抽象的な part が WSDL 記述の targetNamespace とは違う名前空間に属する型であると定義される場合に, part のアクセサー要素の子要素の正しい名前空間修飾は何なのか, 明確ではない。

R2737 rpc-literal バインディングに記述された MESSAGE は, パラメーター及び返却値に使用される part アクセサー要素の子要素を, それらの型が定義された targetNamespace に属するものとして名前空間修飾しなければならない (MUST)。

WSDL 1.1 の 3.5 節は次のように規定している:

パートの name、type、および namespace 属性の値は、すべてエンコードに対する入力ですが、namespace 属性は、抽象型によって明示的に定義されなかった内容に適用されるだけです。
[訳注: http://www.microsoft.com/japan/developer/workshop/xml/general/wsdl.asp で公開されている参考訳より引用。]

しかし, 抽象型 (complexType) の要素及び属性の内容は,それらの定義された targetNamespace で修飾されると明示的に規定していない。 WSDL 1.1 は XML Schema とかなりの部分で同様に機能することを意図して規定されている。 よって,実装は XML Schema と同じルールに従わなければならない。 targetNamespace "A" で定義された complexType が targetNamespace "B" のスキーマに取り込まれ,その中の要素宣言で参照された場合, その complexType の子要素の要素及び属性の内容は名前空間 "A" で修飾され, その要素自体は名前空間 "B" で修飾されるだろう。

次に例を示す:

正しい例:

次の WSDL では,wsdl:types で "http://example.org/foo/" の名前空間のスキーマを定義しているが, その定義は targetNamespace 属性の値が "http://example.org/bar/" になっている wsdl:definitions に含まれる。 (よって,ここではある名前空間で定義された型が,別の名前空間で定義された要素に含まれていることになる。):

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:bar="http://example.org/bar/"
targetNamespace="http://example.org/bar/"
xmlns:foo="http://example.org/foo/">
<types>
   <xsd:schema targetNamespace="http://example.org/foo/"
       xmlns:tns="http://example.org/foo/"
       xmlns:xsd="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">
       <xsd:complexType name="fooType">
          <xsd:sequence>
             <xsd:element ref="tns:bar"/>
             <xsd:element ref="tns:baf"/>
          </xsd:sequence>
       </xsd:complexType>
       <xsd:element name="bar" type="xsd:string"/>
       <xsd:element name="baf" type="xsd:integer"/>
   </xsd:schema>
</types>
<message name="BarMsg">
   <part name="BarAccessor" type="foo:fooType"/>
</message>
<portType name="BarPortType">
   <operation name="BarOperation">
     <input message="bar:BarMsg"/>
   </operation>
</portType>
<binding name="BarSOAPBinding" type="bar:BarPortType">
   <soapbind:binding
    transport="http://schemas.xmlsoap.org/soap/http/"
    style="rpc"/>
   <operation name="BarOperation">
     <input message="bar:BarMsg">
       <soapbind:body use="literal" namespace="http://example.org/bar/"/>
     </input>
   </operation>
</binding>
<service name="serviceName">
  <port name="BarSOAPPort" binding="bar:BarSOAPBinding">
    <soapbind:address location="http://example.org/myBarSOAPPort"/>
  </port>
</service>
</definitions>

結果として生成される BarOperation の SOAP メッセージを次に示す:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:foo="http://example.org/foo/">
  <s:Header/>
    <s:Body>
      <m:BarOperation xmlns:m="http://example.org/bar/">
         <BarAccessor>
            <foo:bar>String</foo:bar>
            <foo:baf>0</foo:baf>
         </BarAccessor>
      </m:BarOperation>
    </s:Body>
</s:Envelope>

5.6.22 Required Headers (必須のヘッダー)

WSDL 1.1 の仕様は, WSDL 文書の SOAP バインディングの部分にある wsdl:operation 要素の wsdl:input 又は wsdl:output 要素に指定されたすべての soapbind:header が, 伝送される際に SOAP メッセージの中に含まれなければならないのかどうか, 明確に規定していない。 WSDL 1.1 ではヘッダーが省略可能であることを指定する方法がないので, このプロファイルではすべてのヘッダーを必須とした。

R2738 MESSAGE は, wsdl:bindingwsdl:operation に記述された wsdl:input 又は wsdl:output に指定されたすべての soapbind:header を 含まなければならない (MUST)。

5.6.23 Allowing Undescribed Headers (記述にないヘッダーの許容)

ヘッダーは SOAP の拡張メカニズムである。 さまざまな理由により, WSDL 文書に定義されていないヘッダーが SOAP メッセージに含まれる必要があるかもしれない。

R2739 MESSAGE は対応する WSDL 記述の wsdl:binding の部分に記述されていない SOAP ヘッダーブロックを含んでもよい (MAY)。

R2753 適切な wsdl:binding に記述されていない SOAP ヘッダーブロックをもつ MESSAGE は, それらの SOAP ヘッダーブロックの mustUnderstand 属性を '1' に設定してもよい (MAY)。

5.6.24 Ordering Headers (ヘッダーの並び順)

記述 (description) の中の soapbind:header の並び順と, メッセージの SOAP ヘッダーブロックの並び順との間には何の関係もない。 同様に,指定されたそれぞれの SOAP ヘッダーブロックがメッセージに1つ以上現れてもよい。

R2751 DESCRIPTION の soapbind:binding 部にある soapbind:header 要素の並び順は, メッセージの中の SOAP ヘッダーブロックの並び順とは独立しているものとみなさなければならない (MUST)。

R2752 MESSAGE は,対応する記述 (description) の中の soapbind:binding 要素の適切な子要素の中の各 soapbind:header 要素について, 一つ以上の SOAP ヘッダーブロックをもってよい (MAY)。

5.6.25 Describing SOAPAction (SOAPAction の記述)

相互運用性テストによって明らかになっているように, HTTP の SOAPAction ヘッダーフィールドの値に引用符を必須とすることが実装の間の相互運用性を向上する。 HTTP 仕様はヘッダーフィールドの値を引用符で囲まないことを許容しているが, いくつかの実装は値が引用符で囲まれていることを必須としている。

SOAPAction ヘッダーフィールドは純粋に処理系に対するヒントである。 メッセージの処理に本質的な情報はすべてエンベロープに含まれる。

R2744 HTTP のリクエスト MESSAGE は,HTTP の SOAPAction ヘッダーフィールドの値として soapbind:operationsoapAction 属性 (DESCRIPTION に存在する場合) の値と同じ値を引用符で囲ったものを指定しなければならない (MUST)。

R2745 HTTP のリクエスト MESSAGE は,soapbind:operationsoapAction 属性が DESCRIPTION に存在しないか,又は存在するがその値として空文字列を指定された場合, HTTP の SOAPAction ヘッダーフィールドの値として引用符で囲まれた空文字列を指定しなければならない (MUST)。

SOAPAction についての更なる議論は,R1119 及び関連する要件を参照のこと。

次に例を示す:

正しい例:

WSDL 記述に次の要素:

<soapbind:operation soapAction="foo" />

を含む場合,対応する SOAPAction HTTP ヘッダーは次のとおり:

SOAPAction: "foo"

正しい例:

WSDL 記述に次の要素:

<soapbind:operation />

又は

<soapbind:operation soapAction="" />

を含む場合,対応する SOAPAction HTTP ヘッダーは次のとおり:

SOAPAction: ""

5.6.26 SOAP Binding Extensions (SOAP バインディング拡張)

wsdl:required 属性は広く誤解されており, WSDL 記述者に間違って soapbind:header が省略可能であることを示すものとして使われることもある。 wsdl:required は,WSDL 1.1 の規定によれば, WSDL 処理系に対する拡張メカニズムである。 この属性は,新しい WSDL 拡張要素をスムーズに導入するためのものである。 wsdl:required の意図は, WSDL 処理系に対して,その WSDL 記述を正常に処理するために その拡張要素が WSDL 処理系によって認識され理解される必要があるかどうかを知らせることである。 ある構文がメッセージに含まれることが条件付きであるとか省略可能であるとかを知らせるためのものではない。 たとえば,soapbind:header 要素に wsdl:required 属性の値として "false" が指定された場合, それは WSDL 処理系に対して WSDL 記述から生成されるメッセージにそのヘッダーが条件付きあるいは省略可能であることを知らせるものとして解釈してはならない。 それは, 「この記述を soapbind:header 要素に含むエンドポイントにメッセージを送るためには, WSDL 処理系は,その soapbind:header 要素によって暗示される意味 (semantic) を理解しなければならない (MUST)」 と解釈すべきものである。

WSDL 1.1 の SOAP バインディング拡張要素に対する wsdl:required 属性のデフォルトの値は "false" である。 現実の大部分の WSDL 記述は SOAP バインディング拡張要素に対して wsdl:required 属性を指定しておらず, それは,WSDL 処理系によって,それらの拡張属性は無視してもよいと解釈されるかもしれない。 このプロファイルは, 拡張要素における wsdl:required 属性の有無や値の如何に関わらず, WSDL の SOAP 1.1 拡張のすべてが利用者 (consumer) に理解され処理されることを必須としている。

R2747 CONSUMER は, 拡張要素における wsdl:required 属性の有無や,存在する場合その値の如何に関わらず, WSDL 1.1 の SOAP バインディング拡張要素のすべてを理解し処理しなければならない (MUST)。

R2748 CONSUMER は, soapbind 拡張要素に wsdl:required 属性が "false" の値をもって存在した場合, それを,その拡張要素が WSDL 記述に基づき生成されるメッセージにおいて省略可能であるという意味に解釈してはならない (MUST NOT)。

5.7 Use of XML Schema (XML Schema の使用)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

WSDL 1.1 は XML Schema を型付けシステムの一つとして使用する。このプロファイルでは WSDL による Web サービスの記述に対する型付けシステムとして XML Schema を使用することを必須とする。

R2800 DESCRIPTION は XML Schema 1.0 の任意の構文を使用してもよい (MAY)。

R2801 DESCRIPTION は, XML Schema 1.0 勧告を利用者定義のデータ型及び構造の基盤として使用しなければならない (MUST)。

6. Service Publication and Discovery (サービスの公開と発見)

UDDI は,公開 (publication) 及び発見 (discovery) が必要な場合のためにこのプロファイルが採用した, Web サービスプロバイダーとその提供する Web サービスとを記述するためのメカニズムである。 ビジネス,想定される用途,及び Web サービス型の記述は UDDI の用語で行われ,詳細な技術的記述は WSDL の用語で行われる。 これら2つの仕様は重なり合うデータの記述を定義しており,両方の形式の記述が使われるが, このプロファイルは,これらの記述が衝突しないよう規定している。

Web サービスインスタンスを UDDI レジストリーに登録することは必須ではない。 すべての利用シナリオが UDDI の提供する種類のメタデータと発見とを必要とするわけでは全くないが, そういう機能が必要な場合は,UDDI はそのために使用すべきメカニズムである。

UDDI V2 を構成する Web サービスは Basic Profile 1.0 に完全に適合するとはいえないことに注意が必要である。なぜならば,プロファイルに要求されているように,UTF-8 及び UTF-16 の両方の文字エンコーディングのメッセージを受け付けないからだ。(UTF-8 だけを受け付ける。) UDDI V2 がこのプロファイル以前に設計され,多くの場合実装されていることを考えれば,そのような食い違いがあることは別に不思議ではない。 UDDI の設計者は UDDI V2 の不適合を意識しており,将来考慮に入れるだろう。

プロファイルのこの節では,次の仕様を参照し,その中での拡張点を定義する:

6.1 bindingTemplates (bindingTemplate)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

UDDI は Web サービスの INSTANCE を uddi:bindingTemplate 要素として表現する。 uddi:bindingTemplatewsdl:port にほぼ相当する役割を果たすが, WSDL では表現できないオプションを提供する。 INSTANCE の WSDL 記述と UDDI 記述との間の整合性を保つために, このプロファイルは uddi:bindingTemplate 要素の構成方法に対して次の制約を課す:

WSDL の soapbind:address 要素はインスタンスのネットワークアドレスが直接指定されている必要がある。 それに対して,UDDI V2 では,インスタンスのネットワークアドレスを指定するのに2つの選択肢がある。 一つは uddi:accessPoint で,WSDL 同様に直接アドレスを指定する。 もう一つは uddi:hostingRedirector で,アドレスを解決するために Web サービスを使った間接的なメカニズムを提供するが,これは WSDL のメカニズムと不整合である。

R3100 適合する INSTANCE を表現する uddi:bindingTemplate 型の REGDATA は, uddi:accessPoint 要素を含まなければならない (MUST)。

次に例を示す:

間違っている例:

<bindingTemplate bindingKey="...">
   <description xml:lang="EN">BarSOAPPort</description>
   <hostingRedirector bindingKey="..."/>
   <tModelInstanceDetails>
      ...
   </tModelInstanceDetails>
</bindingTemplate>

正しい例:

<bindingTemplate bindingKey="...">
   <description xml:lang="EN">BarSOAPPort</description>
   <accessPoint>http://example.org/myBarSOAPPort</accessPoint>
   <tModelInstanceDetails>
      ...
   </tModelInstanceDetails>
</bindingTemplate>

6.2 tModels (tModel)

プロファイルのこの節では,次の仕様 (又はその節) を参照する:

UDDI は Web サービスの型を uddi:tModel 要素で表現する。 (UDDI Data Structures 8.1.1 節参照。) それらは (URI を使って) 実際の記述を含む文書を指し示すことができるが,そうしなくてもよい。 さらに,UDDI は Web サービスの型を記述するのに使われるメカニズムには何も規定していない。 しかし, Web サービスの記述がなかったり,記述形式がバラバラだったりすると相互運用が複雑になるので,プロファイルで何も規定しないわけには行かない。

UDDI Specification, Appendix I.1.2.1.1 では uddi:tModel が Web サービスの記述に WSDL を使用することを許しているが,それを要求しているわけではない。しかし,それを要求しないことは,どの記述言語が使われるか分からないことになるので,相互運用上問題になる。

そこでこのプロファイルでは, Web サービスを記述する uddi:tModel 要素の書き方に次の制約を課している:

このプロファイルは,類似言語の中で最も普及しているので, WSDL を記述言語として選ぶ。

R3002 適合する Web サービス型を表現する uddi:tModel の REGDATA は, 記述言語として WSDL を使用しなければならない (MUST)。

適合する Web サービスの型が WSDL を使用することを指定するために,このプロファイルではそれを主張する UDDI のカテゴライゼーションを採用している。

R3003 適合する Web サービス型を表現する uddi:tModel 型の REGDATA は, uddi-org:types のタキソノミーと "wsdlSpec" カテゴライゼーションとを使用して カテゴライズされなければならない (MUST)。

uddi:tModel に含まれる uddi:overviewURL から wsdl:binding を導き出すためには, プロファイルは一つの WSDL 文書に含まれる複数の wsdl:binding からそれを区別する何らかの方式を採用する必要がある。 UDDI Best Practice for Using WSDL in a UDDI Registry はもっとも広く受け入れられている方式を規定している。

R3010 適合する Web サービス型を示す uddi:tModel 型の REGDATA は, WSDL を UDDI と合わせて使うために UDDI Best Practice for Using WSDL in a UDDI Registy の 1.08 版に従わなければならない (MUST)。

uddi:tModel から参照される wsdl:binding がこのプロファイルに適合していない場合,不整合になるだろう。

R3011 uddi:tModel 型の REGDATA から参照される wsdl:binding は, それ自体がこのプロファイルに適合していなければならない (MUST)。

7. Security (セキュリティ)

ネットワーク指向のすべての情報技術にいえることだが,セキュリティの問題は Web サービスにおいても重大である。 Web サービスでは,セキュリティは,他の情報技術と同様,攻撃者がとりうる潜在的な脅威を理解することと,攻撃が成功するリスクを許容可能なレベルまで下げるために,作業的,物理的及び技術的な対抗手段をとることとから成り立っている。「リスクの許容可能なレベル」がアプリケーションによって大きく変わることと,対抗手段を実現するためのコストも同様に大きく変わることから, Web サービスをセキュアにするための,どこにでも適用できる「正解」などというものはあり得ない。対抗手段と許容可能なリスクとの間の完全なバランスを取ることは,個別の場合ごとにしかできないだろう。

それでも,多くの Web サービスにおいてリスクを許容可能なレベルに下げる経験的な対抗手段の共通パターンというものは存在する。Basic Profile は,それらのうち最も広く使われているものを,使用を強制はしないが,採用している。それは TLS 1.0 又は SSL 3.0 のいずれかで暗号化された HTTP (HTTPS) である。すなわち,適合する Web サービスは HTTPS を使用してもよい。他の対抗手段と併用してもよいし,何も使わなくてもよい。

HTTPS は,基本的なレベルの秘匿性を実現する,暗号化トランスポート接続の枯れた標準であると,広く認められている。HTTPS は,よって,多くの現実世界の Web サービスアプリケーションが必要とする基本的なセキュリティ機能を実現する,最も単純な手段となっている。 HTTPS は,クライアント証明書を使うことにより,クライアント認証に使用してもよい。

プロファイルのこの節では,次の仕様を参照し,その中での拡張点を定義する:

7.1 Use of HTTPS (HTTPS の使用)

HTTPS は,とても有用かつ広く理解されている基本的なセキュリティ機構なので, プロファイルで使用を許す必要がある。

R5000 INSTANCE は HTTPS の使用を必須としてもよい (MAY)。

R5001 INSTANCE が HTTPS の使用を必須とする場合, wsdl:port 定義にある soapbind:address 要素の location 属性は, "https" スキームの URI でなければならない (MUST)。 そうでない場合,それは "http" スキームの URI でなければならない (MUST)。

単純な HTTPS は,利用者 (consumer) による Web サービスインスタンスの認証機能を提供するが,インスタンスによる利用者の認証機能は提供しない。多くの場合,これは相互運用のリスクを高すぎるレベルにしてしまう。HTTPS の相互認証機能をこのプロファイルに含めることで,インスタンスが利用者を認証するという対抗手段を許容する。利用者によるインスタンスの認証では不十分な場合,これは相互運用のリスクを十分に引き下げることになる。

R5010 INSTANCE は,相互認証 (mutual authentication) の HTTPS の使用を必須としてもよい (MAY)。

Appendix I: Referenced Specifications (参照仕様)

次の仕様の要件は,このプロファイルで置き換えられたものを除き,参照することでこのプロファイルに取り込まれている。

Appendix II: Extensibility Points (拡張点)

この節では,Scope of the Profile で定義されたとおり, このプロファイルの構成要素となる仕様の拡張点を列挙する。

これらのメカニズムはこのプロファイルの適用範囲外である。 これらを使うことが相互運用性に影響するかもしれないし, Web サービスの関係者での私的な合意が必要かもしれない。

Simple Object Access Protocol (SOAP) 1.1:

RFC2616: Hypertext Transfer Protocol -- HTTP/1.1:

Web Services Description Language (WSDL) 1.1:

XML Schema Part 1: Structures:

RFC2246: The TLS Protocol Version 1.0:

The SSL Protocol Version 3.0:

RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile:

Appendix III: Acknowledgements (謝辞)

このプロファイルは WS-I Basic Profile Working Group の成果物であり,WG は次のメンバーを含む:

Mark Allerton (Crystal Decisions Corporation), George Arriola (Talking Blocks, Inc.), Keith Ballinger (Microsoft Corporation), Ilya Beyer (KANA), Rich Bonneau (IONA Technologies), Don Box (Microsoft Corporation), Andrew Brown (Verisign), Heidi Buelow (Quovadx), David Burdett (Commerce One, Inc.), Luis Felipe Cabrera (Microsoft Corporation), Maud Cahuzac (France Telecom), Bhaskar Chakrabarti (United Airlines), Chia Chao (IONA Technologies), Martin Chapman (Oracle Corporation), Richard Chin (Avinon), Roberto Chinnici (Sun Microsystems), Sergio Compean (Avanade, Inc.), Tim Cooke (Onyx Software), Ugo Corda (SeeBeyond Tech), Paul Cotton (Microsoft Corporation), Joseph Curran (Accenture), Ayse Dilber (AT&T), Dave Ehnebuske (IBM), Mark Ericson (Mindreef Inc.), Colleen Evans (Sonic Software), Tim Ewald (Microsoft Corporation), Chuck Fay (FileNet Corporation), Chris Ferris (IBM), Daniel Foody (Actional Corporation), Toru Fujii (NTT), Satoru Fujita (NEC Corporation), Shishir Garg (France Telecom), Yaron Goland (BEA Systems), Hans Granqvist (Verisign), Martin Gudgin (Microsoft Corporation), Marc Hadley (Sun Microsystems), Bob Hall (Unisys Corporation), Scott Hanselman (Corillian), Muir Harding (Autodesk, Inc.), Loren Hart (Verisign), Harry Holstrom (Accenture), Larry Hsiung (Quovadx), Hemant Jain (Tata Consultancy), Steve Jenisch (SAS Institute), Erik Johnson (Epicor Software Corporation), Bill Jones (Oracle Corporation), Menno Jonkers (Tryllian BV), Anish Karmarkar (Oracle Corporation), Takahiro Kawamura (Toshiba), Bhushan Khanal (WRQ, Inc.), Sunil Kunisetty (Oracle Corporation), Canyang Kevin Liu (SAP AG), Jonathan Marsh (Microsoft Corporation), David Meyer (Plumtree Software, Inc.), Jeff Mischkinsky (Oracle Corporation), Tom Moog (Sarvega Inc.), Gilles Mousseau (Hummingbird Ltd.), Richard Nikula (BMC Software, Inc.), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Jesse Pangburn (Quovadx), TJ Pannu (ContentGuard, Inc.), Eduardo Pelegri-Llopart (Sun Microsystems), Vijay Rajan (Novell), Eric Rajkovic (Oracle Corporation), Graeme Riddell (Bowstreet), Claus von Riegen (SAP AG), Tom Rutt (Fujitsu Limited), Roger Sanborn (Crystal Decisions Corporation), Krishna Sankar (Cisco Systems, Inc.), Don Schricker (Micro Focus), Dave Seidel (Mindreef Inc.), Akira Shimaya (NTT), Yasser Shohoud (Microsoft Corporation), David Smiley (Mercator Software, Inc.), Seumas Soltysik (IONA Technologies), Joseph Stanko (Plumtree Software, Inc.), Keith Stobie (Microsoft Corporation), Yasuo Takemoto (NTT), Nobuyoshi Tanaka (NEC Corporation), Jorgen Thelin (Cape Clear Software), Sameer Vaidya (Talking Blocks, Inc.), William Vambenepe (Hewlett-Packard), Rick Weil (Eastman Kodak Company), Scott Werden (WRQ, Inc.), Ajamu Wesley (IBM), Shannon Wheatley (Kinzan, Inc.), Ian White (Micro Focus), Sue Worthman (Tryllian BV), Prasad Yendluri (webMethods Inc.).

以上