>サイトトップへ >このカテゴリの一覧へ

 

X 7361:2010 (ISO/IEC 29361:2008) 

(1) 

目 次 

ページ 

序文  1 

1 適用範囲及び序論  1 

1.1 適用範囲  1 

1.2 他のプロファイルとの関係  1 

1.3 Basic Profile Version 1.0からの変更点  2 

1.4 基本原則  2 

1.5 表記法  3 

1.6 プロファイル識別及び版数  4 

2 プロファイルに対する適合性  5 

2.1 適合性の要件  5 

2.2 適合性の対象  5 

2.3 適合性の適用範囲  6 

2.4 適合性の表示  7 

3 メッセージ送受信  7 

3.1 SOAPエンベロープ  8 

3.2 SOAP 処理モデル  11 

3.3 SOAPフォルト  12 

3.4 HTTPでのSOAPの使用  15 

4 サービス記述  19 

4.1 必す(須)記述  20 

4.2 文書構造  20 

4.3 型  27 

4.4 メッセージ  29 

4.5 ポート型  32 

4.6 バインディング  33 

4.7 SOAPバインディング  34 

4.8 XML Schemaの使用  44 

5 サービスの公開及び発見  45 

5.1 bindingTemplate  45 

5.2 tModel  46 

6 セキュリティ  47 

6.1 HTTPSの使用  48 

附属書A(規定)引用規格  50 

附属書B(参考)拡張点  51 

附属書C(参考)参考規格  53 


 

X 7361:2010 (ISO/IEC 29361:2008) 目次 

(2) 

ページ 

附属書D(参考)定義された用語  54 

附属書E(参考)謝辞  55 

附属書JA(参考)用語集  56 

 


 

X 7361:2010 ISO/IEC 29361:2008 

(3) 

まえがき 

この規格は,工業標準化法第12条第1項の規定に基づき,独立行政法人情報処理推進機構(IPA)から,

工業標準原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調査会の審議を経て,経

済産業大臣が制定した日本工業規格である。 

この規格は,著作権法で保護対象となっている著作物である。 

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許

権,出願公開後の特許出願,実用新案権及び出願公開後の実用新案登録出願にかかわる確認について,責

任はもたない。 

 

 

X 7361:2010 (ISO/IEC 29361:2008)


 

  

日本工業規格 

JIS 

 

X 7361:2010 

 

(ISO/IEC 29361:2008) 

Webサービス相互運用性− 

WS-Iベーシックプロファイル1.1 

Information technology-Web Services Interoperability- 

WS-I Basic Profile Version 1.1 

 

序文 

この規格は,2008年に第1版として発行されたISO/IEC 29361を基に,技術的内容及び対応国際規格の

構成を変更することなく作成した日本工業規格である。 

なお,この規格で点線の下線を施してある参考事項及び附属書JAは,対応国際規格にはない事項であ

る。 

 

適用範囲及び序論 

1.1 

適用範囲 

この規格は,WS-I Basic Profile 1.1(以下,このプロファイルという。)を定義する。このプロファイル

は非占有的(non-proprietary)なWebサービス規格で構成され,相互運用性を向上させる規定の明確化,

詳細化,解釈及び強化(amplify)を含んでいる。 

箇条1は,このプロファイルを紹介し,他のプロファイルとの関係を示す。 

箇条2は,このプロファイルに適合しているということはどういう意味かを示す。 

それに続く各箇条は,このプロファイルの構成要素となるそれぞれの規格について示すもので,次の二

つの部分からなる。すなわち,構成要素となる規格及び拡張点(extensibility point)を列挙した概要規定と,

それに続いて,構成要素となる規格の個別の部分について示した細分箇条との二つの部分である。この規

格の箇条番号と,引用規格の箇条番号との間には何の関係もないことに注意が必要である。 

注記 この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。 

ISO/IEC 29361:2008,Information technology−Web Services Interoperability−WS-I Basic Profile 

Version 1.1(IDT) 

なお,対応の程度を表す記号“IDT”は,ISO/IEC Guide 21-1に基づき,“一致している”こ

とを示す。 

1.2 

他のプロファイルとの関係 

このプロファイルはBasic Profile 1.0に基づいており,これまでの正誤を反映するとともに,エンベロー

プのシリアライゼーション及びメッセージにおけるその表現に関連する要件を分離して外に出したもので

ある。これらの要件は現在,Simple SOAP Binding Profile 1.0に別個の適合性要求として含まれている。こ

の分離は,エンベロープ シリアライゼーションの規定を定めるプロファイル(Simple SOAP Binding Profile 

1.0,Attachments Profile 1.0など)と連携してBasic Profile 1.1を構成しやすくするためのものである。Basic 

Profile 1.1及びSimple SOAP Binding Profile 1.0に対する適合範囲を合わせたものは,おおよそ公開された


X 7361:2010 (ISO/IEC 29361:2008) 

  

正誤表を加えたBasic Profile 1.0に対する適合範囲にほぼ同等である。 

このプロファイルはSimple SOAP Binding Profile 1.0と連携して構成されており,Basic Profile 1.0に優先

する。Attachments Profile 1.0はW3CのSOAP Messages with Attachmentsのサポートを追加しており,この

プロファイルと組み合わせて使用することが意図されている。 

1.3 

Basic Profile Version 1.0からの変更点 

この規格はBasic Profile Version 1.0(http://www.ws-i.org/Profiles/BasicProfile-1.0.html)に基づいており,

それに対する公開された正誤表が反映されている。大きな変更点は,次のとおりである。 

 

・ MESSAGE適合性対象−Basic Profile1.0でMESSAGEを適合性対象としていた要件の一部で,新

しい対象であるENVELOPEが使用されるようになった。これによって,Attachments Profileに記

述されているような代わりのメッセージシリアライゼーションが容易になった。 

・ SOAPバインディング−SOAPバインディングのメッセージシリアライゼーションに関する要件

がSimple SOAP Binding Profileに移動したことによって,他のシリアライゼーションが容易にな

った。 

1.4 

基本原則 

このプロファイルは,相互運用性を実現することに関係する一連の原則に沿って開発され,それらの原

則は,全体として,このプロファイルの原理を構成している。この細分箇条ではそれらのガイドラインを

示す。 

相互運用性に対する保証の限界  (No guarantee of interoperability)   

特定のサービスの相互運用性を完全に保証するのは不可能である。しかし,このプロファイルは,実装

経験によって現在までに明らかになった最も一般的な問題について検討している。 

アプリケーションのセマンティクス  (Application semantics)   

アプリケーションのセマンティクスの通信は,このプロファイルを構成する技術によって容易となるこ

とがあるが,そのようなセマンティクスに対する共通理解を保証することは行われていない。 

テスト可能性  (Testability)   

可能な限り,このプロファイルでは要件をテストできるようにしている。しかし,テストが可能である

ことは必す(須)ではない。また,テストはテスト対象に影響を与えない方式(例えば,伝送路上の対象

物を調べるような)で達成できることが望ましい。 

要件の強さ  (Strength of requirements)   

このプロファイルでは,可能な場合にはいつでも,強い要求事項[例えば,“…しなければならない

(MUST)”及び“…してはならない(MUST NOT)”]を課している。そのような要件が満足できない正当

な理由がある場合,推奨事項又は緩い禁止事項[例えば,“…することが望ましい(SHOULD)”及び“…

しないほうがよい(SHOULD NOT)”]を使う。選択可能な又は条件付きの事項は,あいまい(曖昧)さ,

又は複数の実装の間での不整合を引き起こす。 

制限対緩和  (Restriction vs. relaxation)   

引用規格の要件を強化(amplify)する場合,このプロファイルは制限を加えることはあっても,制限を

緩和する[例えば,“…しなければならない(MUST)”を,“…してもよい(MAY)”に変える。]ことは

ない。 

複数のメカニズム  (Multiple mechanisms)   

引用規格が複数のメカニズムの使用を交換可能な形で許している場合,このプロファイルでは,よく理


X 7361:2010 (ISO/IEC 29361:2008) 

 

解され,広く実装され,かつ,有用なものの方を選ぶ。余計な,又は規定不足のメカニズム及び拡張機能

は物事を複雑にし,それによって相互運用性を低下させる。 

将来の互換性  (Future compatibility)   

このプロファイルでは,可能な場合には,要件を引用規格の改正中の版に合わせている。これは実装者

がスムーズに改正版に移行する助けになるし,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.5 

表記法 

この規格では,“…しなければならない(MUST,SHALL)”,“…してはならない(MUST NOT,SHALL 

NOT)”,“必す(須)の…(REQUIRED)”,“…することが望ましい(SHOULD)”,“…しないほうがよい

(SHOULD NOT)”,“推奨の…(RECOMMENDED)”,“…してもよい(MAY)”及び“省略可能の… 

(OPTIONAL)”は,RFC2119(http://www.ietf.org/rfc/rfc2119.txt)に記述されているとおりに解釈する。 

このプロファイルにおける要件(すなわち,2.1に説明されている,適合性に影響するもの)は,次の形

式で提示される。 

 

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

 

ただし,ここで "nnnn" はこのプロファイル内で一意の要件番号で置き換えられ,一意の要件識別子 

(unique requirement identifier)を構成する。 

要件識別子(requirement identifier)は,Namespaces in XML 1.0(JIS X 4158:2005 XML名前空間)の

QNameと互換性をもつように,名前空間修飾されている(namespace qualified)とみなすことができる。

ある要件の識別子に明示的な名前空間接頭辞が存在しない場合(例えば,"bp10:R9999" ではなく "R9999" 


X 7361:2010 (ISO/IEC 29361:2008) 

  

のような場合),その要件が存在する規格の箇条の適合性URI(conformance URI)によって識別される名

前空間に属すると解釈するのが望ましい。名前空間修飾されている場合,その接頭辞は,次に記述すると

おり,そこで有効な名前空間の対応付けに従って解釈するのが望ましい。 

幾つかの要件は,引用規格を明確化するだけで,実装に対して追加の制約を課さないものである。便宜

のため,規定の明確化(clarification)は,次の例のように規定の後に“〔明確化〕”という注意を付けて表

現する。 

 

例 Rnnnn ……は,……でなければならない。〔明確化〕 

 

幾つかの要件は,引用規格の標準化されつつある内容を取り入れたものである。便宜上,そのような規

格の先取りは,次のように注記される: xxxx,ただし,ここで "xxxx" は規格を示す識別子である(例えば,

"WSDL20" はWSDL 2.0を示す。)。そのような規格は,この規格の対応国際規格の発行時点では完成して

おらず,先取りした規格が変更されることもあり得ることに注意が必要である。この情報は,実装者に対

する便宜としてだけ含められている。 

基になる引用規格における拡張点(2.3を参照)も,次のように同様に示される。 

 

Ennnn 拡張点の名前−拡張子の記述 

 

ここで "nnnn" は,このプロファイル内で一意の拡張点番号で置き換えられる。要件の記述と同様,拡

張の記述も名前空間によって修飾されていると考えることができる。 

この規格では,全体を通して次に示す幾つかの名前空間接頭辞(namespace prefix)を使用する。各接頭

辞に関連付けられたURIを,次に示す。名前空間接頭辞は,任意に選択したものであり,どのような文字

列を選択しても意味的に差異がないことに注意が必要である。 

 

・ soap−"http://schemas.xmlsoap.org/soap/envelope/"  

・ xsi−"http://www.w3.org/2001/XMLSchema-instance"  

・ xsd−"http://www.w3.org/2001/XMLSchema"  

・ soapenc−"http://schemas.xmlsoap.org/soap/encoding/"  

・ wsdl−"http://schemas.xmlsoap.org/wsdl/"  

・ soapbind−"http://schemas.xmlsoap.org/wsdl/soap/"  

・ uddi−"urn:uddi-org:api̲v2" 

1.6 

プロファイル識別及び版数 

この規格は名前(この場合,Basic Profile)及び版数(ここでは1.1)で識別される。両方を合わせて,

特定のプロファイルインスタンス(profile instance)を識別する。 

版数の番号はメジャー番号及びマイナー番号で構成され,"メジャー番号.マイナー番号" の形式となる。

これらは,プロファイルの優先度を決定するのに利用できる。(メジャー番号及びマイナー番号の両方を考

慮して)版数の番号が大きい場合,そのインスタンスは新しく,それ以前のインスタンスを置き換える。 

同じ名前のプロファイルの複数のインスタンス(例えば,"Example Profile 1.1","Example Profile 5.0")

は,同じ一般的な適用範囲内にある相互運用性の問題に言及している(もっとも,状況の進展によって,

プロファイルの厳密な適用範囲がインスタンスの間で変わることがある。)。 


X 7361:2010 (ISO/IEC 29361:2008) 

 

この情報は,あるプロファイルの二つのインスタンスが後方互換(backwards-compatible)であるかどう

か(すなわち,前のプロファイルインスタンスへの適合が後のプロファイルインスタンスへの適合を暗示

するものと想定できるかどうか。)を判断するために使用できる。同じ名前とメジャー番号とをもつ複数の

プロファイルインスタンス(例えば,"Example Profile 1.0" 及び "Example Profile 1.1")は,互換性がある

と考えてもよい。これは,逆方向への互換性を暗示するものではないことに注意が必要である。すなわち,

後のプロファイルインスタンスへの適合は,前のプロファイルインスタンスへの適合を暗示するものと想

定することはできない。 

 

プロファイルに対する適合性 

このプロファイルに対して適合しているということは,このプロファイルの適用範囲 (scope) 内で,特

定の対象 (target) に対する要件 (requirements) の集合を守ることであると定義されている。この箇条では,

これらの用語について説明し,どのように適合性が定義され使用されるかを示す。 

2.1 

適合性の要件 

要件(requirements)は,このプロファイルに対する適合性の基準を提示する。要件は,典型的には既存

の規格を引用し,そこでの相互運用性を向上する詳細化,強化(amplify),解釈及び明確化を具体化した

ものである。このプロファイルのすべての要件は規定(normative)と解釈され,引用規格のうちの適用範

囲内の要件(2.3参照)も同様に規定と解釈されることが望ましい。このプロファイルの要件と引用規格の

要件とが互いに矛盾する場合,プロファイル適合性の観点からは,このプロファイルの要件が優先される。 

要件レベルは,RFC2119(http://www.ietf.org/rfc/rfc2119.txt)の用語(例えば,MUST,MAY,SHOULD)

を使い,要件の性質と適合性に対する影響力とを示す。個々の要件記述は,便宜上,個別に(R9999のよ

うな)番号が振られている。 

次に例を示す。 

 

R9999 WIDGET は,丸い形状であることが望ましい (SHOULD)。 

 

この要件は "R9999" という識別子で識別され,適合性対象WIDGETに対して適用され(適合性対象に

ついては後述。),WIDGETに対する条件付きの要件を課す。すなわち,大部分の場合には適合性を維持す

るためにこの要件は満足しなければならないが,それを満足しない正当な理由がある場合もある(それは,

要件それ自体又は付随する文章で説明される。)。 

それぞれの要件は,ちょうど一つの要件レベルキーワード(例えば,"MUST")と適合性対象キーワー

ド(例えば,"MESSAGE")とをもつ。適合性対象キーワードは("MESSAGE"のように)太字で示され

る。太字で示されない他の適合性対象は,その定義のためだけに使用され,適合性対象として使用される

わけではない。補足の文章(根拠,例など)が要件を明確にするために付け加えられることもあるが,要

件記述そのものだけが適合性を判定するときに考慮されなければならない。 

このプロファイルの用語定義は,適合性を決定するという用途において権威あるものとみなされる。 

このプロファイルの要件はいずれも,適合性レベルに関係なく,現実の脅威又は想定される脅威[例え

ば,サービス妨害攻撃(denial of service attack)]に対応して,それ以外の点では適合している実装がセキ

ュリティ対策を講じる能力を制限するものと解釈しない方がよい。 

2.2 

適合性の対象 

適合性対象(conformance target)は,どの対象物(artifact)(例えば,SOAPメッセージ,WSDL記述,


X 7361:2010 (ISO/IEC 29361:2008) 

  

UDDIレジストリデータ)又はどの主体(party)(例えば,SOAP処理系,エンドユーザ)に要件が適用さ

れるかを識別するのに使われる。 

これによって,異なる文脈における適合性の定義であっても,要件の適用可能性をあいまい(曖昧)性

なく解釈されることが保証され,さらに,対象物(例えば,SOAPメッセージ,WSDL記述)及び各種の

Webサービスの主体(例えば,クライアント,サービスのインスタンス)の動作に対する適合性試験が可

能となる。 

試験を単純にし,あいまい(曖昧)性を排除するため,要件の適合性対象は可能な限り物理的な対象物

である。 

このプロファイルでは,次の適合性対象を使用する。 

 

・ MESSAGE−ENVELOPEを伝送する,プロトコル構成要素(例えばSOAP/HTTPメッセージ) 

・ ENVELOPE−soap:Envelope要素及びその内容をシリアライズしたもの 

・ DESCRIPTION−データ型の記述,メッセージの記述,インタフェース及びそれらの具体的なプ

ロトコル・データ形式へのバインディングの記述,並びにWebサービスに関連付けられたネット

ワーク上のアクセスポイントの記述(例えば,WSDL記述)[Basic Profile 1.0 

(http://www.ws-i.org/Profiles/BasicProfile-1.0.html)] 

・ INSTANCE−wsdl:port又はuddi:bindingTemplate を実装するソフトウェア[Basic Profile 

1.0(http://www.ws-i.org/Profiles/BasicProfile-1.0.html)] 

・ CONSUMER−INSTANCEを起動(invoke)するソフトウェア[Basic Profile 1.0 

(http://www.ws-i.org/Profiles/BasicProfile-1.0.html)] 

・ SENDER−関連付けられたプロトコルに基づき,メッセージを生成(generate)するソフトウェ

ア[Basic Profile 1.0(http://www.ws-i.org/Profiles/BasicProfile-1.0.html)] 

・ RECEIVER−関連付けされたプロトコルに基づき,メッセージを受信(consume)するソフトウ

ェア(例えば,SOAP処理系)[Basic Profile 1.0(http://www.ws-i.org/Profiles/BasicProfile-1.0.html)] 

・ REGDATA−Webサービスの登録及び発見に関連するレジストリの要素(例えば,UDDIのtModel)

[Basic Profile 1.0(http://www.ws-i.org/Profiles/BasicProfile-1.0.html)] 

2.3 

適合性の適用範囲 

このプロファイルは,既存の技術を採用(引用)し,その明確化を行う。言い換えれば,このプロファ

イルは,その適用範囲の中での相互運用性を向上することだけを図っている。一般的には,このプロファ

イルの適用範囲は,その引用規格によって限定される。 

このプロファイルの適用範囲は,拡張点(extensibility point)によって更に詳細化される。引用規格は,

拡張メカニズム,及び未規定の又は未確定の構成パラメタを提供していることがある。このプロファイル

で拡張点と認識された場合,そのようなメカニズム又はパラメタはこのプロファイルの適用範囲外であり,

それを使っても使わなくてもこのプロファイルに対する適合性において意味をもたない。 

このプロファイルは,さらに,拡張点の使用について,その範囲を制限することなく,要件を課すこと

がある。また,拡張点の特定の使用方法について,このプロファイルが他のプロファイルと組み合わせて

使われた場合に,相互運用性を向上するために,他のプロファイルで制限されることがある。 

拡張点の使用は相互運用性を損なうことがあるので,その使用はWebサービスの関係者によって何らか

の形で個別協議するか,文書化するのが望ましい。例えば,これは個別合意(out-of-band agreement)の形

をとるかもしれない。 


X 7361:2010 (ISO/IEC 29361:2008) 

 

このプロファイルの適用範囲は,附属書Aの引用規格によって定義され,附属書Bの拡張点によって詳

細化される。 

2.4 

適合性の表示 

このプロファイルに対する適合性の表示は,Conformance Claim Attachment Mechanisms

(http://www.ws-i.org/Profiles/ConformanceClaims-1.0.html,適合性表示添付メカニズム)の記述に従い,次

に示す各メカニズムを使って行うことができる。この場合,各メカニズムが列挙する対象物に関連付けら

れた,このプロファイルの適用可能要件が満足されていることが条件となる。 

 

・ Web サービスインスタンスに対するWSDL 1.1 適合性表示添付メカニズム−MESSAGE 

DESCRIPTION INSTANCE RECEIVER 

・ WSDL記述の構造に対するWSDL 1.1 適合性表示添付メカニズム−DESCRIPTION 

・ Web サービスインスタンスに対するUDDI適合性表示添付メカニズム−MESSAGE 

DESCRIPTION INSTANCE RECEIVER 

・ Web サービス登録に対するUDDI適合性表示添付メカニズム−REGDATA 

 

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

 

メッセージ送受信 

このプロファイルのこの箇条では,次の規格を引用し,その中での拡張点を定義する。 

 

・ Simple Object Access Protocol (SOAP) 1.1  

(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) 

拡張点: 

 E0001−ヘッダブロック−ヘッダブロックはSOAPの根本的な拡張メカニズムである。 

 E0002−処理順序−SOAPエンベロープの構成要素(例えば,ヘッダ)の処理順序は規

定がなく,別途調整(out-of-band negotiation)が必要かもしれない。 

 E0003−中継ノード(intermediaries)の使用−SOAPの中継ノードはSOAP 1.1では規定

が不十分であり,その利用には別途調整(out-of-band negotiation)が必要かもしれない。

また,それを使用するときには,どこでプロファイルの適合性を測定するかについて注

意深い検討が必要になるかもしれない。 

 E0004−soap:actor値−soap:actor属性の値 

(特殊なURI 'http://schemas.xmlsoap.org/soap/actor/next' 以外)は,Webサービスの関係

者間の個別合意を表す。 

 E0005−フォルトのdetail要素−フォルトのdetail要素の内容は,SOAP 1.1では規定さ

れていない。 

 E0006−エンベロープ シリアライゼーション−このプロファイルは,エンベロープが

どのようにメッセージ中にシリアライズされるかについて,幾つかの側面は制約しない。 

 

・ RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 (http://www.ietf.org/rfc/rfc2616.txt) 

拡張点: 


X 7361:2010 (ISO/IEC 29361:2008) 

  

 E0007−HTTP認証−HTTPの認証は,拡張スキーム,任意のダイジェストハッシュア

ルゴリズム及びパラメタを許容している。 

 E0008−規定がないヘッダフィールド−HTTPは任意のヘッダがメッセージに現れるこ

とを許容している。 

 E0009−Expect 拡張−HTTPのExpect/ContinueメカニズムはExpect拡張を許容してい

る。 

 E0010−Content-Encoding−HTTPで許容される内容エンコーディング 

(content-encoding)は無制限であり,'gzip','compress','deflate' 以外のあらゆる形式が

拡張点となる。 

 E0011−Transfer-Encoding−HTTPで許容される伝送エンコーディング 

(transfer-encoding)は無制限である。 

 E0012−Upgrade−HTTPは,Upgrade ヘッダを使うことで,接続を任意のプロトコルに

切り替えることを許容している。 

 E0024−名前空間属性−soap:Envelope要素及びsoap:Header要素の名前空間属性。 

 E0025−soap:Body要素の属性−名前空間修飾された属性も局所属性もSOAP 1.1によっ

て制約されない。 

 

・ RFC2965: HTTP State Management Mechanism (http://www.ietf.org/rfc/rfc2965) 

3.1 

SOAPエンベロープ 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ SOAP 1.1の4 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#̲Toc478383494) 

 

SOAP 1.1は,メッセージを組み立てるための構造(エンベロープ)を定義している。このプロファイル

ではその構造を使用することを必す(須)としており,使用するときには次の制約を課す。 

3.1.1 

SOAPエンベロープの構造 

 

R9980 ENVELOPE は,SOAP 1.1の4 "SOAPエンベロープ" で指定された構造に適合しなけ

ればならない(このプロファイルによる修正に従う。)(MUST)。 

R9981 ENVELOPE は,soap:Body要素の子要素を厳密に0個又は1個もたなければならない 

(MUST)。 

 

R2201及びR2210(4.4.1参照)を合わせて考えるsoap:Body要素の子要素は最大で1個であることは

明らかであるが,この制約を表現する明示的な要件がないと混乱を招くことになるため規定する。 

3.1.2 

SOAPエンベロープの名前空間 

SOAP 1.1は,エンベロープの文書要素の名前空間名(namespace name)が  

"http://schemas.xmlsoap.org/soap/envelope/" でない場合,そのエンベロープを破棄することを規定している。

このプロファイルは,あいまい(曖昧)でないオペレーションを保証するため,その代わりにフォルトが

生成されることを要求している。 

 


X 7361:2010 (ISO/IEC 29361:2008) 

 

R1015 RECEIVER は,文書要素が soap:Envelope要素でないエンベロープを検出した場合

はフォルトを生成しなければならない (MUST)。 

3.1.3 

SOAP 本体の名前空間修飾 

名前空間修飾のない要素名の使用は名前の衝突を起こすかもしれないので,soap:Body要素の子要素

には修飾された名前を使わなければならない。 

 

R1014 ENVELOPEの soap:Body要素の子要素は,名前空間修飾され(namespace qualified)

なければならない (MUST)。 

3.1.4 

禁止されている構造 

XMLのDTD及び処理命令は,エンベロープ内で使用されると,セキュリティ上のぜい(脆)弱性,処

理のオーバーヘッド及びメッセージのセマンティクスのあいまい(曖昧)さを導入するかもしれない。そ

のため,XMLのこれらの機能の処理はSOAP 1.1の3で禁止されている。 

公開された正誤表NE05(http://www.w3.org/XML/xml-names-19990114-errataを参照)では名前空間宣言

xmlns:xml="http://www.w3.org/XML/1998/namespace" が現れてもよいことになっているが,以前の処理系

の中にはこうした宣言をエラーとみなすものもあった。この要件は,適合対象物ができるだけ広範囲の相

互運用性をもてるようにしている。 

 

R1008 ENVELOPE は,文書型宣言(Document Type Declaration)を含んではならない (MUST 

NOT)。〔明確化〕 

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

〔明確化〕 

R1033 ENVELOPE は,名前空間宣言 xmlns:xml="http://www.w3.org/XML/1998/namespace" を含

まないほうがよい (SHOULD NOT)。〔明確化〕 

R1034 DESCRIPTION は,名前空間宣言 xmlns:xml="http://www.w3.org/XML/1998/namespace" を

含まないほうがよい (SHOULD NOT)。〔明確化〕 

3.1.5 

SOAP後続要素 

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

素は禁止する。 

 

R1011 ENVELOPE は,soap:Envelope要素の子要素として,soap:Body要素の後ろにいか

なる要素も付加してはならない (MUST NOT)。 

 

この要件は,SOAP 1.1の規格本文と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> 


10 

X 7361:2010 (ISO/IEC 29361:2008) 

  

  <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> 

3.1.6 

SOAP encodingStyle属性 

soap:encodingStyle属性は,データをXMLにエンコーディングするときに特定のスキームを使う

ことを示すのに使われてきた。しかし,この機能はXML名前空間を使っても実現できるので,複雑さを

導入してしまう。そこで,このプロファイルは,literalの,エンコードされないXMLの方を選択している。 

 

R1005 ENVELOPE は,名前空間名(namespace name) が 

"http://schemas.xmlsoap.org/soap/envelope/" である要素のいずれにも

soap:encodingStyle属性を含んではならない (MUST NOT)。 

R1006 ENVELOPE は,soap:Body要素の子要素のいずれにも soap:encodingStyle属性

を含んではならない (MUST NOT)。 

R1007 rpc-literalバインディングで記述されるENVELOPEは,soap:Body要素の孫要素のいず

れにもsoap:encodingStyle属性を含んではならない (MUST NOT)。 

3.1.7 

SOAP mustUnderstand属性 

soap:mustUnderstand属性は "xsd:boolean" 型を制限したものであり,"0" 又は "1" の値だけを取る。

したがって,この二つの値だけが許されている。 

 

R1013 ENVELOPEがsoap:mustUnderstand属性を含む場合,属性の値として2種類の形式 

"0"及び"1" だけを使用しなければならない (MUST)。〔明確化〕 

3.1.8 

xsi:type属性 

多くの場合,送信側と受信側とは,交換されるエンベロープについて型情報を何らかの形で共有してい

る。 

 

R1017 RECEIVER は,派生型を示すために必要な場合(XML Schema Part 1:Structures, 2.6.1

を参照)を除き,エンベロープにxsi:type属性の使用を必す(須)としてはならない 

(MUST NOT)。 


11 

X 7361:2010 (ISO/IEC 29361:2008) 

 

3.1.9 

SOAP 1.1要素のSOAP 1.1属性 

 

R1032 ENVELOPE のsoap:Envelope要素,soap:Header要素及びsoap:Body要素は,名

前空間 "http://schemas.xmlsoap.org/soap/envelope/" 内の属性をもってはならない (MUST 

NOT)。 

3.2 

SOAP 処理モデル 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ SOAP 1.1の 2 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#̲Toc478383491) 

 

SOAP 1.1ではエンベロープ処理のためのモデルを定義している。特に,ヘッダブロック及びエンベロー

プ本体の処理についてのルールを定義している。また,フォルトの生成に関するルールも定義している。

このプロファイルでは,その処理モデルに対して次の制約を課す。 

3.2.1 

必す(須)ヘッダ 

SOAP 1.1の処理モデルは,必す(須)ヘッダブロックの処理についての規定が不十分である。必す(須)

ヘッダブロックとは,soap:Header要素の子要素で,soap:mustUnderstand属性に "1" の値を設定

しているもののことである。 

 

R1025 RECEIVER は,すべての必す(須)ヘッダブロックに対するチェックが実際の処理の前

に行われているようにエンベロープを処理しなければならない (MUST)。SOAP12 

 

これによって,メッセージの一部分を処理した後で必す(須)ヘッダブロックを見つけることによる,

予期せぬ副作用が発生しないことを保証する。 

3.2.2 

MustUnderstandフォルトの生成 

このプロファイルは,受信側が自分あて(宛)のヘッダブロックを理解できない場合,フォルトを生成

することを要求している。 

 

R1027 エンベロープが(soap:actor値によって)あて(宛)先として指定された受信者(receiver)

に理解できない必す(須)ヘッダブロック(soap:mustUnderstand属性の値が "1" で

あるもの)をもつ場合,RECEIVER は "soap:MustUnderstand" フォルトを生成しなけれ

ばならない (MUST)。SOAP12 

3.2.3 

SOAPフォルトの処理 

フォルトが生成される場合,それ以降の処理は行わないことが望ましい。リクエスト−レスポンスのメ

ッセージ交換では,リクエストの送信側にフォルトメッセージが伝送され,何らかのアプリケーションレ

ベルのエラーがユーザに通知される。 

SOAPとこのプロファイルは共に,SOAPフォルトの作成を意味する用語として '生成(generate)' を使

用している。フォルトの生成はその伝送(場合によっては不要)とは別であるという認識が重要である。 

 

R1028 RECEIVERでフォルトが生成される場合,フォルトが生成される前に行われたエンベロ

ープ処理の影響を復元(rollback)又は補償(compensate)するために必要なものを除き,


12 

X 7361:2010 (ISO/IEC 29361:2008) 

  

SOAPエンベロープに対するそれ以降の処理を行わないほうがよい (SHOULD NOT)。

SOAP12 

R1029 SOAPのエンベロープの処理の正常な結果がSOAPレスポンスの伝送になる場合で,そ

の代わりにフォルトが生成されるとき,RECEIVER はレスポンスの代わりにSOAPフォ

ルトを伝送しなければならない (MUST)。SOAP12 

R1030 フォルトを生成する RECEIVER は,実際にフォルトが生成されたことを,その状況に

適切な手段をもってエンドユーザに通知することが望ましい (SHOULD)。SOAP12 

3.3 

SOAPフォルト 

3.3.1 

SOAPフォルトの識別 

幾つかの利用者(consumer)の実装は,フォルトの存在を識別するのに誤ってHTTPの状態コードだけ

を使用する。WebのインフラストラクチャがHTTP状態コードを変更するような状況も考えられるし,ま

た,一般的な信頼性のためにも,このプロファイルでは,実装がエンベロープも調べることを要求する。

フォルトは,soap:Body要素に単一の子要素としてsoap:Fault要素をもつエンベロープである。 

 

R1107 メッセージのsoap:Body要素が単一の子 soap:Fault要素をもつ場合,RECEIVER は

SOAPメッセージをフォルトと解釈しなければならない (MUST)。 

3.3.2 

SOAPフォルトの構造 

このプロファイルは,soap:Fault要素の内容をSOAP 1.1で明示的に記述されている要素に限定する。 

 

R1000 ENVELOPE がフォルトである場合,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/' > 


13 

X 7361:2010 (ISO/IEC 29361:2008) 

 

  <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> 

3.3.3 

SOAPフォルトの名前空間修飾 

soap:Fault要素の子要素は,局所的であり,名前空間修飾の必要はない。 

 

R1001 ENVELOPE がフォルトである場合,soap:Fault要素の子要素は名前空間で修飾され

ていてはならない (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> 


14 

X 7361:2010 (ISO/IEC 29361:2008) 

  

  <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> 

3.3.4 

SOAPフォルトの拡張性 

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

素が現れることが許されている。 

 

R1002 RECEIVER は,detail要素の子要素として 0 個以上のいかなる数の要素をもつフォル

トも受け付けなければならない (MUST)。それらの子要素は名前空間修飾されていても,

されていなくてもよい。 

R1003 RECEIVER は,detail要素の属性として 0 個以上のいかなる数の名前空間修飾された

属性又はされていない属性をもつフォルトも受け付けなければならない (MUST)。名前空

間修飾されたそれらの属性の名前空間は,"http://schemas.xmlsoap.org/soap/envelope" でな

ければ何でもよい。 

3.3.5 

SOAPフォルトの言語 

faultstring要素は,フォルトの性質について人間が読めるように示したものである。したがって,それが

特定の言語で記述されているとは限らず,xml:lang属性がfaultstringの言語を示すために使用できる。 

この要件はSOAPの名前空間URLで表示されるスキーマと矛盾していることに注意が必要である。矛

盾のないスキーマは "http://ws-i.org/profiles/basic/1.1/soap-envelope-2004-01-21.xsd" にある。 

 

R1016 RECEIVER は,faultstring要素に xml:lang属性をもつフォルトを受け付けなけ

ればならない (MUST)。 

3.3.6 

SOAPの独自フォルトコード 

SOAP 1.1は,ドット記法("dot" notation)を使って独自のフォルトコードがfaultcode要素の内容に

現れることを許している。 

SOAP 1.1で定義されたフォルトコードをこのメカニズムを使って拡張することは,名前空間の衝突を引

き起こし得る。"."(ドット)の右側に同じ名前が違う意味で使われた場合に,相互運用上の問題を引き起

こすことがあるので,その使用は避けるのが望ましい。 

その代わりに,このプロファイルでは,SOAP 1.1で定義されたフォルトコードを使い,フォルトの性質

を表すためにdetail要素の中に追加の情報を入れる方式を推奨している。 

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

許容している。 

幾つかの規格では既にドット記法を使った独自のフォルトコードを定義している。それにもかかわらず,

それらを将来の規格で使うことは推奨しない。 

 


15 

X 7361:2010 (ISO/IEC 29361:2008) 

 

R1004 ENVELOPE が SOAPのfaultcode要素を含む場合,要素の内容はSOAP 1.1で定義

されているフォルトコードの一つであるか(必要であればdetail要素に追加情報を提

供する。),又はフォルトが指定する機関の管理下に名前空間があるQnameであること

が望ましい(この順序が優先順)(SHOULD)。 

R1031 ENVELOPE が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> 

3.4 

HTTPでのSOAPの使用 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ SOAP 1.1の6 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#̲Toc478383526) 

・ HTTP/1.1 (http://www.ietf.org/rfc/rfc2616.txt) 

・ HTTP State Management Mechanism (http://www.ietf.org/rfc/rfc2965.txt) 


16 

X 7361:2010 (ISO/IEC 29361:2008) 

  

SOAP 1.1ではHTTPに対する一つのプロトコルバインディングを定義している。このプロファイルでは

そのバインディングの使用を必す(須)としており,それを使用するときには次の制約を課している。 

3.4.1 

HTTPプロトコルバインディング 

HTTPには幾つかの版が定義されている。HTTP/1.0と比較すると,HTTP/1.1は性能的に有利であり,ま

た,規定がより明確である。 

 

R1141 MESSAGEは,HTTP/1.1又はHTTP/1.0のいずれかを使って送られなければならない 

(MUST)。 

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

 

HTTP/1.1のサポートにはHTTP/1.0のサポートが含まれており,また,中継ノード(intermediaries)が

メッセージのHTTPの版数を変更してしまう可能性があることに注意が必要である(HTTPの版数につい

ては,RFC2145 "Use and Interpretation of HTTP Version Numbers" を参照。)。 

3.4.2 

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,RFC 2774) を

使用してはならない (MUST NOT)。 

 

HTTP拡張フレームワークはHTTPをモジュール化された形で拡張するための実験的なメカニズムであ

る。このメカニズムは広く採用されておらず,また,SOAPでの使用による利点は疑問であることから,

このプロファイルでは使用を許していない。 

3.4.3 

SOAPAction HTTPヘッダフィールド 

テストによって明らかになっているように,HTTPのSOAPActionヘッダフィールドの値に引用符を必

す(須)とすることが実装の間の相互運用性を向上する。HTTP規格はヘッダフィールドの値を引用符で

囲まないことを許容しているが,幾つかのSOAP実装は値が引用符で囲まれていることを必す(須)とし

ている。 

SOAPAction ヘッダフィールドは純粋に処理系に対するヒントである。メッセージの処理に本質的な情

報はすべてsoap:Envelope要素に含まれる。 

 

R1109 HTTPのリクエスト MESSAGEの SOAPAction ヘッダフィールドの値は,引用符で囲

まれた文字列でなければならない (MUST)。〔明確化〕 

R1119 RECEIVER は,メッセージ内のHTTPのSOAPAction ヘッダフィールドの値が引用符

で囲まれていない場合,フォルトを返してもよい (MAY)。〔明確化〕 


17 

X 7361:2010 (ISO/IEC 29361:2008) 

 

R1127 RECEIVER は,メッセージを正しく処理するためにSOAPAction HTTPヘッダフィール

ドの値に依存してはならない (MUST NOT)。SOAP12 

 

次に例を示す。 

 

正しい例: 

WSDL記述に次の要素: 

<soapbind:operation soapAction="foo" />  

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

SOAPAction: "foo"  

 

正しい例: 

WSDL記述に次の要素: 

<soapbind:operation />  

又は 

<soapbind:operation soapAction="" />  

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

SOAPAction: ""  

3.4.4 

HTTPの成功状態コード 

HTTPは2xxの状態コードを成功を示すために使っている。特に200は成功メッセージのデフォルトで

あるが,202もメッセージが処理に投入されたことを示すために使用可能である。付け加えて,その他の

2xx状態コードも,HTTP通信の性質によっては,適切となることもある。 

 

R1124 INSTANCE は,HTTPリクエストの正常な結果を示す 2xx HTTP状態コードをレスポン

スメッセージで使用しなければならない (MUST)。 

R1111 INSTANCE は,フォルトでないエンベロープが含まれるレスポンスメッセージに,HTTP

状態コードとして "200 OK" を使うことが望ましい (SHOULD)。 

R1112 INSTANCE は,SOAP エンベロープは含まれないがHTTPリクエストの正常な結果を示

すレスポンスメッセージに,HTTP状態コードとして "200 OK" 又は "202 Accepted" の

いずれかを使うことが望ましい (SHOULD)。 

 

HTTP/1.1はレスポンス状態コードの "200" と "202" とに異なる意味を割り当てていることは事実であ

るが,このプロファイルの枠組みの中では,リクエストのイニシエータはこれらの状態コードを同等とみ

なすのが望ましい。一部のSOAP実装はHTTPプロトコル実装をほとんど制御せず,これらのレスポンス

状態コードのいずれを送るかを制御できないため,このプロファイルは両方の状態コードを受け入れる。 

3.4.5 

HTTPの転送状態コード 

HTTPの転送(redirect)の状態コードを使う場合,元と同じメソッドを使うか,それともGETメソッド

を使うかという点について相互運用上の問題がある。このプロファイルでは,正しい転送の状態コードと

して "307 Temporary Redirect"(同じメソッドでの転送を意味する。)を要求している。詳細については,

RFC2616の3xx状態コードに関する記述を参照。 


18 

X 7361:2010 (ISO/IEC 29361:2008) 

  

 

R1130 INSTANCEは,リクエストを別のエンドポイントに転送 (redirect) する場合,HTTP状

態コード"307 Temporary Redirect" を使用しなければならない (MUST)。 

R1131 CONSUMER は,レスポンスとしてHTTP状態コード"307 Temporary Redirect" を受け取

った場合,リクエストを自動的に転送 (redirect) してもよい (MAY)。 

 

RFC2616は,ユーザエージェントが自動的にリクエストを転送しないほうがよいとしている。しかし,

この要件はブラウザを想定したものであり,自動的な処理(多くのWebサービスもこれに当たる。)を想

定したものではない。よって,このプロファイルでは,利用者(consumer)が転送を自動的に行うことを

許してはいるが,要求してはいない。 

3.4.6 

HTTPのクライアントエラー状態コード 

HTTPは4xxの状態コードをクライアントのエラーによる失敗を示すために使っている。これらのうち

のいずれかの結果を起こす状況はいろいろあるが,このプロファイルでは,HTTPリクエストのメディア

型が正しくなかった場合と,期待されるメディア型("POST")が指定されなかった場合とを強調している。 

 

R1125 INSTANCE は,リクエストの形式に問題があることを示すレスポンスのHTTP状態コー

ドとして4xxを使用しなければならない (MUST)。 

R1113 INSTANCE は,HTTPリクエストメッセージの形式が正しくない場合,HTTP状態コー

ドとして "400 Bad Request" を使うことが望ましい (SHOULD)。 

R1114 INSTANCE は,HTTPリクエストメッセージのメソッドが "POST" でない場合,HTTP

状態コードとして "405 Method not Allowed" を使うことが望ましい (SHOULD)。 

R1115 INSTANCEは,HTTPリクエストメッセージの Content-Type ヘッダフィールド値がそ

のWSDL記述で許されていない場合,HTTP状態コードとして "415 Unsupported Media 

Type" を返すことが望ましい (SHOULD)。 

 

上記の要件が,インスタンスに対して,リクエストにレスポンスを返すことを強制していないことに注

意する。場合によっては,例えばサービス妨害攻撃(Denial of Service attacks)の場合など,インスタンス

がリクエストを無視することを選択することもある。 

また,SOAP 1.1の6.2(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#̲Toc478383529)は,SOAPフ

ォルトを返す場合は必ずHTTPコードとして500 "Internal Server Error" を使用することを要求している。

このプロファイルはその要件を変更しない。HTTPエラー状態コードとして4xxが使用される場合,レス

ポンスメッセージはSOAPフォルトを含まないことが望ましい。 

3.4.7 

HTTPのサーバエラー状態コード 

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

 

R1126 INSTANCE は,レスポンスのエンベロープがフォルトである場合,HTTP状態コードと

して "500 Internal Server Error" を返さなければならない (MUST)。 

3.4.8 

HTTPクッキー 

HTTP状態管理メカニズム(HTTP State Management Mechanism)は,“クッキー(Cookies)”とも呼ばれ,

Webブラウザとサーバとの間で状態をもったセッションを生成することを可能にしている。ハイパテキス


19 

X 7361:2010 (ISO/IEC 29361:2008) 

 

トのブラウズを前提に設計されたため,クッキーのWebサービスでの動作の定義はあいまい(曖昧)であ

り,しかも,クッキーはエンベロープの外側にあるため,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)として使わないことが望ましい。よって,利用者側でクッキーの内

容を解釈することは許されていない。クッキーは不透明(すなわち,利用者にとって意味のないもの)と

して扱われなければならない。 

 

サービス記述 

このプロファイルでは,サービスの記述にWSDL(Web Services Description Language)を使用する。WSDL

では,メッセージを操作するエンドポイントの集合としてサービスが記述される。 

このプロファイルのこの箇条では,次の規格を引用し,その中での拡張点を定義する。 

 

・ Extensible Markup Language (XML) 1.0 (Second Edition)  

(http://www.w3.org/TR/2000/REC-xml-20001006) 

・ Namespaces in XML 1.0(JIS X 4158:2005 XML名前空間) 

(http://www.w3.org/TR/1999/REC-xml-names-19990114/) 

・ XML Schema Part 1:Structures (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/) 

拡張点: 

 E0017−スキーマの注釈(annotation)−XML Schema は注釈を許しており,データ構

造についての追加の情報を記述するために使ってもよい。 

・ XML Schema Part 2: Datatypes (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/) 

・ Web Services Description Language (WSDL) 1.1  

(http://www.w3.org/TR/2001/NOTE-wsdl-20010315) 

拡張点: 


20 

X 7361:2010 (ISO/IEC 29361:2008) 

  

 E0013−WSDL拡張−WSDLは特定の位置に拡張要素及び拡張属性を入れることを許

す。そのような拡張の使用には別途調整(out-of-band negotiation)が必要である。 

 E0014−妥当性検証モード−WSDL及びXML Schema 文書を読み込むパーサーがDTD

の妥当性検証を行うかどうか。 

 E0015−外部資源の取り込み−WSDL及びXML Schema文書を読み込むパーサーが外

部実体及びDTDを取り込むかどうか。 

 E0016−相対URI−WSDLは,次の相対URIの使い方について適切に規定していない。

soapbind:body/@namespace,soapbind:address/@location,wsdl:import/@location, 

xsd:schema/@targetNamespace,及びxsd:import/@schemaLocation。その使用については,

更に調整が必要である。詳細については,XML Baseを参照。 

4.1 

必す(須)記述 

Web サービスのインスタンスは,その動作を定めたインタフェース仕様が何らかの方法で利用可能とな

っていることが要求されている。 

 

R0001 INSTANCE のWSDL 1.1記述若しくはそのUDDIバインディングテンプレート,又はそ

の両方は,認可された利用者 (authorized consumer) の要求に応じて提供されなければな

らない (MUST)。 

 

これは,認定された利用者が適合サービスインスタンスのサービス記述を要求した場合に,サービスイ

ンスタンスプロバイダは,WSDL文書若しくはUDDIバインディングテンプレート,又はその両方を,そ

の利用者が入手できるようにしなければならないことを意味する。サービスインスタンスはサーバから

WSDL文書にランタイムアクセスできるようにしてもよいが,適合すると見なされることを目的にそうす

る必要はない。同様に,サービスインスタンスプロバイダはUDDIレジストリにインスタンスプロバイダ

を登録してもよいが,適合するとみなされるためにそうする必要はない。こうしたあらゆるシナリオにお

いてWSDLによるインタフェース仕様が存在しなければならないが,このインタフェース仕様は状況に応

じた様々な手段を通して利用可能であればよい。 

4.2 

文書構造 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ WSDL 1.1の2.1 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#̲document-s) 

 

WSDL 1.1は,Webサービスを記述するためのXMLに基づいた構造を定義する。このプロファイルでは

この構造の使用を必す(須)としており,その使用においては次の制約を課す。 

4.2.1 

WSDL スキーマ定義 

WSDL 1.1の附属書4で規定されているスキーマは,規格の本文の規定との間に不整合がある。このプ

ロファイルは,既知の間違いに対する修正を取り入れた新しいスキーマ文書を引用する。 

 

R2028 WSDLの名前空間(このプロファイルでは "wsdl" の接頭辞を用いる。)を使用する 

DESCRIPTION は,"http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd"にあるXML 

Schema に対して妥当 (valid) でなければならない (MUST)。 


21 

X 7361:2010 (ISO/IEC 29361:2008) 

 

R2029 WSDL SOAPバインディングの名前空間(このプロファイルでは "soapbind" の接頭辞を

用いる。)を使用する DESCRIPTION は,

"http://ws-i.org/profiles/basic/1.1/wsdlsoap-2004-08-24.xsd"にあるXML Schema に対し

て妥当 (valid) でなければならない (MUST)。 

 

このプロファイルではWSDL記述がスキーマに対して妥当であることを要求しているが,利用者が

WSDL文書を妥当性検証することを要求しているわけではない。それを保証するのはWSDL文書の作成者

の責任である。 

4.2.2 

WSDL及びスキーマのインポート 

WSDL 1.1の幾つかの例では,XML Schema 定義を取り込むために用いるWSDLのimport文が間違って

いる。このプロファイルでは インポートメカニズムの使用を明確化し,それぞれに整合性をもたせ,守備

範囲を限定している。取り込まれたスキーマ文書は,取り込む側のWSDL文書に対するXMLの版数とエ

ンコーディングとに対する要件に整合するよう,制限されている。 

 

R2001 DESCRIPTIONは,他のWSDL記述を取り込むためにWSDLのimport記述だけを使用

しなければならない (MUST)。 

R2803 DESCRIPTION の中のwsdl:import要素の名前空間属性は,相対URIであってはなら

ない (MUST NOT)。 

R2002 XML Schemaのスキーマ定義を取り込むために,DESCRIPTION はXML Schemaの

import 記述を使用しなければならない (MUST)。 

R2003 DESCRIPTIONは,XML Schemaのimport記述をtypes要素の中のxsd:schema要

素の内部だけで使用しなければならない (MUST)。 

R2004 DESCRIPTION の中のxsd:import要素のschemaLocation属性は,ルート要素が名前空

間 "http://www.w3.org/2001/XMLSchema" に属する "schema" ではない文書に解決されて

はならない (MUST NOT)。 

R2009 DESCRIPTIONから直接的又は間接的に取り込まれるXML Schemaは,Unicodeのバイ

ト順マーク (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/"> 


22 

X 7361:2010 (ISO/IEC 29361:2008) 

  

 

   <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" 

             ... 

   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="..."/> 

   </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> 


23 

X 7361:2010 (ISO/IEC 29361:2008) 

 

4.2.3 

WSDL importのlocation属性の構造 

WSDL 1.1は,wsdl:import要素に location属性が必す(須)かどうか,及びその内容がどうなっ

ていなければならないかについて,明確ではない。 

 

R2007 DESCRIPTIONは,wsdl:import要素の location属性に空ではない値を指定しなけ

ればならない (MUST)。 

 

wsdl:import要素は xsd:import要素になら(倣)ったものであるが,wsdl:import要素には

location属性が必す(須)であるのに対して,xsd:import要素の対応する属性である 

schemaLocationは省略可能である。locationが必す(須)であることと整合性を取るために,その

内容は空であってはならない。 

4.2.4 

WSDL importのlocation属性のセマンティクス 

WSDL 1.1は,WSDL処理系が wsdl:import要素を見つけた場合,その要素のlocation属性に指定

されたURIから実際にWSDL文書を取り出して処理しなければならないのかどうか,明確ではない。 

 

R2008 CONSUMER は,WSDL記述を wsdl:import要素の location属性に指定されたURI

から取り出してもよい(MAY)が,必ずしもそうする必要はない。〔明確化〕 

 

wsdl:import要素のlocation属性の値はヒントである。WSDL処理系は与えられた名前空間の

WSDL記述の位置を特定する,別の手段をもっていてもよい。 

4.2.5 

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"/> 

            


24 

X 7361:2010 (ISO/IEC 29361:2008) 

  

   <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"> 

           ....... 


25 

X 7361:2010 (ISO/IEC 29361:2008) 

 

     </schema> 

   </types> 

            

   <message name="GetLastTradePriceInput"> 

        <part name="body" element="tns:TradePriceRequest"/> 

   </message> 

               ... 

   <service name="StockQuoteService"> 

      <port name="StockQuotePort" binding="tns:StockQuoteSoap"> 

           .... 

      </port> 

   </service> 

</definitions> 

4.2.6 

XML版数の要件 

WSDL 1.1又はXML Schema 1.0のいずれも,XMLの特定の版数を要求してはいない。相互運用性のた

め,WSDL文書及びそれらが取り込むスキーマはXMLの1.0版を使わなければならない。 

 

R4004 DESCRIPTIONは,Extensible Markup Language (XML) の1.0版W3C勧告を使用しな

ければならない (MUST)。 

4.2.7 

XML名前空間宣言 

公開された正誤表NE05(http://www.w3.org/XML/xml-names-19990114-errataを参照)ではこの名前空間宣

言が現れてもよいことになっているが,以前の処理系の中にはこうした宣言をエラーとみなすものもある。

この要件は,適合対象物ができるだけ広範囲の相互運用性をもてるようにしている。 

 

R4005 DESCRIPTION に名前空間宣言 xmlns:xml="http://www.w3.org/XML/1998/namespace" を

含めないほうがよい (SHOULD NOT)。〔明確化〕 

4.2.8 

WSDL及びUnicodeのバイト順マーク 

XML 1.0では,UTF-8文字エンコーディングにおいてもバイト順マーク(BOM)を含めてもよいことに

なっており,WSDL処理系はそれを受け入れる用意がなければならない。 

 

R4002 DESCRIPTION には,Unicodeのバイト順マーク (BOM) を含めてもよい (MAY)。〔明

確化〕 

4.2.9 

許容可能なWSDL文字エンコーディング 

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

る。 

 

R4003 DESCRIPTION は,UTF-8又はUTF-16のいずれかの文字エンコーディングを使わなけ

ればならない (MUST)。 

4.2.10 名前空間の強制変更 

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


26 

X 7361:2010 (ISO/IEC 29361:2008) 

  

れない。 

 

R2005 取り込まれる(imported)側の記述(description)の wsdl:definitions要素の 

targetNamespace属性の値は,取り込む(importing)側の DESCRIPTION の

wsdl:import要素の namespace属性の値と一致しなければならない (MUST)。 

 

4.2.11 WSDLのdocumentation要素 

WSDL 1.1のスキーマと本文とは,wsdl:documentation要素をどこに置いてもよいかについて整合

性がとれていない。 

 

R2030 DESCRIPTION の中のwsdl:documentation要素は,WSDL1.1に記述されている各要素に

加えて,wsdl:import要素,wsdl:part要素及び wsdl:definitions要素 の最初

の子要素として存在してもよい (MAY)。WSDL20 

4.2.12 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)の処理の最中に,利用者(consumer)がWSDL拡張要素を発見し,そ

れがwsdl:required属性に "true" の値を指定されており,かつ,それが理解できない

か又は処理できない場合,CONSUMER は,その処理を失敗(fail)しなければならない 

(MUST)。 

 

WSDL記述を読み込んでWebサービスのソフトウェアのインスタンスを生成する開発ツールは,未知の

WSDL拡張に対する解釈を組み込まれていないかもしれない。したがって,必す(須)の(wsdl:required

属性の値が"true"である。)WSDL拡張は避けるのが望ましい。利用方法及び意味について規格が公開され

ていない必す(須)のWSDL拡張を使用することは,その拡張の作者を除く全員に対して,潜在的に克服

不可能な相互運用上の問題を課してしまう。利用方法及び意味について規格が公開されている必す(須)

のWSDL拡張を使用することは,ここでの要件を規定するに至った相互運用上の問題を軽減するが,解消

するものではない。 

このプロファイルの目的上,"http://schemas.xmlsoap.org/wsdl/" 名前空間のすべての要素は,要素の他に

属性を介しても拡張可能である。WS-Iは,WSDL1.1スキーマのこの可能性を反映したバージョンを 

http://ws-i.org/profiles/basic/1.1/wsdl11.xsdで公開して便宜を図っている。 

 


27 

X 7361:2010 (ISO/IEC 29361:2008) 

 

4.3 

型 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ WSDL 1.1の2.2 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#̲types) 

 

WSDL 1.1のwsdl:types要素は,記述されるWebサービスに適用されるデータ型定義を記述する。こ

のプロファイルでは,このプロファイルに対する適合性を表示するWSDLの要素に参照される

wsdl:types要素の内容の,該当する部分に対して次の制約を課す。 

4.3.1 

QName参照 

XML Schemaは,各QName参照が,対象名前空間(target namespace)又は取り込まれた名前空間(imported 

namespace,xsd:import要素で明示的に指定されたもの)のいずれかを使うことを要求している。入れ

子の取り込み(nested imports)だけによって表現された名前空間へのQName参照は許されていない。 

WSDL 1.1は,WSDL要素からのQName参照にどのスキーマ対象名前空間が適しているかについて,明

らかではない。このプロファイルでは,xsd:schema要素で定義された対象名前空間と,取り込まれた名

前空間との両方に対して,WSDL要素からのQName参照を許している。入れ子の取り込みを通してだけ

定義された名前空間をQName参照することは,許されていない。 

 

R2101 DESCRIPTIONは,取り込まれて(imported)もいなければ,参照する側の(referring)

WSDL文書に定義されてもいない名前空間に属するWSDL構成要素をQNameで参照し

てはならない (MUST NOT)。 

R2102 DESCRIPTION の中でのスキーマの構成要素に対するQName参照は,xsd:schema要

素のtargetNamespace属性に定義された名前空間か,xsd:schema要素の中にある

xsd:import要素の namespace属性で定義された名前空間かの,いずれかを使わなけ

ればならない (MUST)。 

4.3.2 

スキーマのtargetNamespace構造 

wsdl:types要素の子供であるすべてのxsd:schema要素にtargetNamespaceを要求することは良

い方法であり,WSDL文書の作成者に対する負担も最小限で済み,明確に定義されていない状況に陥るこ

とを避けられる。 

 

R2105 DESCRIPTION のwsdl:types要素に含まれるすべてのxsd:schema要素は,

targetNamespace属性に有効なnullでない値をもたなければならない (MUST)。ただ

し,xsd:schema要素が,xsd:import要素若しくはxsd:annotation要素,又はその両方を

唯一の子要素としてもつ場合を除く。 

4.3.3 

soapencの配列 

WSDL 1.1の2.2にある,配列(array)型を宣言することについての推奨は,多様な解釈をされてきたた

め,相互運用性の問題となっている。さらに,配列を宣言するにはより明確な方法がある。 

 

R2110 DESCRIPTION の中では,宣言は soapenc:Array型を拡張も制限もしてはならない 

(MUST NOT)。 


28 

X 7361:2010 (ISO/IEC 29361:2008) 

  

R2111 DESCRIPTION の中では,宣言は型宣言にwsdl:arrayType属性を使用してはならな

い (MUST NOT)。 

R2112 DESCRIPTION の中では,要素の名前は ArrayOfXXX の形式で名前付けしないほうが

よい (SHOULD NOT)。 

R2113 ENVELOPE は,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> 

エンベロープは次のようにシリアライズされる(名前空間宣言は明確化のため省略): 

<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"/> 


29 

X 7361:2010 (ISO/IEC 29361:2008) 

 

  </xsd:sequence> 

</xsd:complexType> 

エンベロープは次のようにシリアライズされる(名前空間宣言は明確化のため省略): 

<MyArray1> 

  <x>abcd</x> 

  <x>efgh</x> 

</MyArray1> 

4.3.4 

WSDL及びスキーマ定義の対象名前空間 

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

る。 

 

R2114 DESCRIPTION の中で,WSDL定義の対象名前空間(target namespace)と,スキーマ定

義の対象名前空間(target namespace)とは,同じであってもよい (MAY)。WSDL20 

4.4 

メッセージ 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ WSDL 1.1の2.3 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#̲messages) 

 

WSDL 1.1ではwsdl:message要素が伝送されるデータの抽象的な定義を表現する。wsdl:binding

要素が抽象的な定義を特定のメッセージシリアライゼーションに結び付ける。このプロファイルでは

wsdl:message要素の使用と,適合するwsdl:binding要素がwsdl:message要素を使用する方法と

に関して次の制約を課す。 

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

 

定義: rpc-literalバインディング 

“rpc-literal バインディング”とは,その子要素のwsdl:operation要素がすべて

rpc-literalオペレーションであるwsdl:binding要素のことである。 

“rpc-literal オペレーション”とは,wsdl:binding要素の子要素である

wsdl:operation要素で,その子孫であるsoapbind:body要素がuse属性に "literal" の

値を指定しており,それが次のいずれかであるもののことである。 

1. 値 "rpc" をもつstyle属性が子要素 soapbind:operation要素で指定される。 

2. 

style属性が子要素soapbind:operation要素に存在せず,それを囲む 

wsdl:binding要素のsoapbind:binding要素が,値 "rpc" をもつstyle属性

を指定する。 

 

定義: document-literalバインディング 

“document-literalバインディング”とは,その子要素のwsdl:operation要素がすべて 

document-literal オペレーションであるwsdl:binding要素のことである。 

“document-literalオペレーション”とは,wsdl:binding要素の子要素である

wsdl:operation要素で,その子孫であるsoapbind:body要素がuse属性に "literal" の


30 

X 7361:2010 (ISO/IEC 29361:2008) 

  

値を指定しており,それが次のいずれかであるもののことである。 

1. 

値 "document" をもつstyle属性が子要素soapbind:operation要素で指定

される。 

2. 

style属性が子要素soapbind:operation要素に存在せず,それを囲む 

wsdl:binding要素のsoapbind:binding要素が,値 "document" をもつ 

style属性を指定する。 

3. 

style属性が,子要素のsoapbind:operation要素及びそれを囲む 

wsdl:binding要素のsoapbind:binding要素のいずれにも存在しない。 

4.4.1 

バインディング及びパート 

何個のwsdl:part要素がdocument-literalバインディング及びrpc-literalバインディングに許容又は要求

されているか,並びにそれらをどのように定義しなければならないかについて,多様な解釈が存在する。 

 

R2201 DESCRIPTION の中の document-literalバインディングは,それぞれの soapbind:body

要素にparts属性が指定された場合,その値として,たかだか1個のパート名をもたな

ければならない (MUST)。 

R2209 DESCRIPTION の中のwsdl:binding要素は,そのwsdl:binding要素が参照する先

のwsdl:portType要素に属するwsdl:message要素の各wsdl:part要素を,バイン

ディング拡張要素にバインドすることが望ましい (SHOULD)。 

R2210 DESCRIPTION の中のdocument-literalバインディングがsoapbind:body要素にparts

属性を指定しない場合,対応する抽象的なwsdl:message要素は,0個又は1個の

wsdl:part要素を定義しなければならない (MUST)。 

R2202 DESCRIPTION の中の wsdl:binding要素は,soap:Body要素を構成する0個のパー

トを指定する soapbind:body要素をもってもよい (MAY)。 

R2203 DESCRIPTION の中のrpc-literalバインディングは,そのsoapbind:body要素の中で,

type属性を使って定義されたwsdl:part要素だけを参照しなければならない (MUST)。 

R2211 rpc-literal バインディングで記述されたENVELOPE は,パートアクセッサに対して

xsi:nil属性に "1" 又は "true" の値を指定したものをもってはならない (MUST NOT)。 

R2207 DESCRIPTIONの中のwsdl:message要素は,rpc-literalバインディングでwsdl:part

要素がsoapbind: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)。 

R2212 ENVELOPE は,エンベロープの対応するsoapbind:body要素にバインドされた 

wsdl:part要素ごとにパートアクセッサを一つだけ含まなければならない (MUST)。 


31 

X 7361:2010 (ISO/IEC 29361:2008) 

 

R2213 soapbind:body要素の parts属性の値が空文字列であるdocument-literal記述では,対

応する ENVELOPE のsoap:Body要素に含まれる要素内容はなしでなければならない 

(MUST)。 

R2214 soapbind:body要素のparts属性の値が空文字列であるrpc-literal記述では,対応する 

ENVELOPE に含まれるパートアクセッサは存在してはならない (MUST)。 

 

スタイルがdocumentでのpart要素が0個のwsdl:message要素の使用は,空のsoap:Body要素を含

むエンベロープを送受信するオペレーションを許容するために,許されている。スタイルがrpcでのpart

要素が0個のwsdl:message要素の使用は,引数,返却値,又はその両方が存在しないオペレーション

を許容するために,許されている。 

document-literalバインディングでは,このプロファイルは,多くとも一つのパートが,抽象レベルにお

いてelement形式を用いて定義され,soap:Body要素にシリアライズされることを要求している。 

wsdl:part要素がtype属性を使って定義された場合,メッセージ内のそのパートのシリアライゼー

ションは,(XML Schemaで)暗黙的に,minOccurs属性の値を "1" に,maxOccurs属性の値を "1" に,

そして nillable属性の値を "false" に,それぞれ指定したものと同等である。 

wsdl:part要素はカージナリティ(cardinality)及び空要素可能性(nillability)のルールを指定するこ

とを許していないので,等価の暗黙的修飾を指定する必要がある。カージナリティ及び空要素可能性のル

ールを指定すると実装間の相互運用性が促進される。nillable属性に対する等価の暗黙的修飾の値は "false" 

である。なぜならば,これを "true" としてしまうと,クライアントから値を送らないことを許容するパー

トしか設計できなくなってしまうからである。wsdl:part要素が空要素可能であることを許すアプリケ

ーションの場合,complexTypeラッパーを生成し,そのラッパーに含まれる要素の空要素可能性のルール

を指定することがアプリケーションに求められる。 

4.4.2 

バインディング及びフォルト 

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要素においても同様で

ある。 

4.4.3 

part要素の宣言 

WSDL 1.1の3.1の例4及び例5は,間違ってwsdl:part要素のelement属性の有効な値としてスキ

ーマのデータ型("xsd:string" など)を示している。 


32 

X 7361:2010 (ISO/IEC 29361:2008) 

  

 

R2206 DESCRIPTION の中のwsdl:message要素がelement属性を使う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> 

4.5 

ポート型 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ WSDL 1.1の2.4 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#̲porttypes)  

 

WSDL 1.1ではwsdl:portType要素が抽象的なオペレーションの集合をグループ化するために使われ

る。このプロファイルではwsdl:portType要素の使用に関して次の制約を課す。 

4.5.1 

part要素の並び順 

parameterOrder属性を許すことは,コードジェネレータがメソッドシグネチャと伝送路上のメッセ

ージのインスタンスとを対応付ける助けになる。 

 

R2301 ENVELOPEのsoap:Body要素の中での要素の並び順は,エンベロープの対応する

soapbind:body要素にバインドされた各wsdl:part要素の並び順を記述した 

wsdl:message要素の中のwsdl:part要素の並び順と同じでなければならない 

(MUST)。 

R2302 DESCRIPTION は,wsdl:operation要素のparameterOrder属性を,コードジェネ

レータに対するヒントとして,返却値及びメソッドシグネチャを示すために使用してもよ

い (MAY)。 

 


33 

X 7361:2010 (ISO/IEC 29361:2008) 

 

4.5.2 

許容されるオペレーション 

WSDL1.1におけるSolicit-Responseオペレーション及びNotificationオペレーションは,十分に規定され

ておらず,さらに,WSDL 1.1はそれらに対するバインディングも定義していない。 

 

R2303 DESCRIPTION は,wsdl:portType要素の定義にSolicit-Responseオペレーション及び 

Notificationオペレーションを使用してはならない (MUST NOT)。 

4.5.3 

区別できるオペレーション 

一つのwsdl:portType要素の中でのオペレーション名の多重定義は,このプロファイルでは禁止して

いる。 

 

R2304 DESCRIPTION の中の一つの wsdl:portType要素の定義を取り出したとき,その中に

定義される operation要素の name属性は,それぞれ別の値をもたなければならない 

(MUST)。 

 

この要件は,一つのwsdl:portType要素の中のwsdl:operation要素に対してだけ適用されること

に注意。wsdl:portType要素は他のwsdl:portType要素に属するwsdl:operation要素と同じオペ

レーション名を使ってもよい。 

4.5.4 

parameterOrder属性の構築 

WSDL 1.1は,wsdl: operation要素(wsdl:portType要素の子)のparameterOrder属性をど

う構築するのがよいか,明らかではない。 

 

R2305 DESCRIPTION の中のwsdl:portType要素の子要素wsdl:operation要素に

parameterOrder属性が存在する場合,このparameterOrder属性は,output要素

で参照されるmessage要素で定義される wsdl:part要素の中から,最大一つの 

wsdl:part要素を取り除いたものとして構築されなければならない (MUST)。 

 

parameterOrder属性の値にあるwsdl:part要素のリストからoutput要素で参照されるmessage要素

に属するwsdl:part要素が一つ省略された場合,その省略されたwsdl:part要素が返却値(return value)

である。返却値の型に制約はない。wsdl:part要素が省略されない場合,返却値はない。 

4.5.5 

type属性及びelement属性の排他性 

WSDL 1.1は,wsdl:message要素のwsdl:part要素を定義するのにtype属性及びelement属性の

両方を指定できないことを明記していない。 

 

R2306 DESCRIPTION の中のwsdl:message要素は,同じwsdl:part要素に対してtype属

性及びelement属性の両方を指定してはならない (MUST NOT)。 

4.6 

バインディング 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ WSDL 1.1の2.5 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#̲bindings) 

 


34 

X 7361:2010 (ISO/IEC 29361:2008) 

  

WSDL 1.1ではwsdl:binding要素が,特定のwsdl:portType要素で定義されたオペレーション及

びメッセージに対する具体的なプロトコル及びデータ形式を提供している。このプロファイルでは適合す

るバインディングの仕様に次の制約を課す。 

4.6.1 

SOAPバインディングの使用 

このプロファイルは,バインディングの選択肢を,十分に定義され,最も一般的に利用されているSOAP

バインディングに限定している。 

 

R2401 DESCRIPTION の中のwsdl:binding要素は,WSDL 1.1の3で定義されたWSDLの

SOAPバインディングを使用しなければならない (MUST)。 

 

ここでは,適合するwsdl:binding要素の構築についての要件を課していることに注意。これは,記

述(description)全体に対する要件を課しているわけではない。特に,WSDL文書が,適合しない

wsdl:binding要素をもつことを禁止しているわけではない。また,バインディングはメッセージのシリ

アライズ方法を変更するWSDL拡張要素を存在させてもよい。 

4.7 

SOAPバインディング 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ WSDL 1.1の3.0 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#̲services) 

 

WSDL 1.1はSOAP 1.1のエンドポイントに対するバインディングを定義する。このプロファイルでは

WSDL 1.1で定義されているSOAPバインディングの使用を必す(須)としており,その使用に関して次

の制約を課す。 

4.7.1 

transport属性の指定 

transport属性について,WSDL 1.1の本文とスキーマとの間の矛盾がある。WSDL 1.1ではそれを必

す(須)としており,スキーマはそれを省略可能としている。 

 

R2701 DESCRIPTION の中の wsdl:binding要素は,その soapbind:binding 子要素が 

transport属性を指定するよう構築されなければならない (MUST)。 

4.7.2 

HTTPトランスポート 

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

 

R2702 DESCRIPTION の中のwsdl:binding要素は,SOAPのHTTPプロトコルバインディ

ングを指定しなければならない (MUST)。具体的には,そのsoapbind:binding子要

素のtransport属性の値は,"http://schemas.xmlsoap.org/soap/http" でなければならない 

(MUST)。 

 

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

4.7.3 

style属性の整合性 

styleが "document" か "rpc" かはwsdl:operation要素のレベルで指定されるので,個々の

wsdl:operation要素に相異なるstyleをもつwsdl:binding要素を許してしまう。これは,相互運


35 

X 7361:2010 (ISO/IEC 29361:2008) 

 

用上の問題となる。 

 

R2705 DESCRIPTION の中のwsdl:binding要素は,rpc-literalバインディング又は 

document-literalバインディングのいずれかでなければならない (MUST)。 

4.7.4 

エンコーディング及びuse属性 

このプロファイルではSOAPエンコーディングを含むエンコーディングの使用を禁止している。 

 

R2706 DESCRIPTION の中の wsdl:binding要素は,すべての soapbind:body要素,

soapbind:fault要素,soapbind:header要素及び soapbind:headerfault要素

に対して,use属性の値を "literal" としなければならない (MUST)。 

4.7.5 

portType要素への複数のバインディング 

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

 

R2709 DESCRIPTION の中のwsdl:portType要素は,同一又は別のWSDL文書の中に,そ

れを参照するwsdl:binding要素を0個以上もってよい (MAY)。 

4.7.6 

オペレーションシグネチャ 

定義: オペレーションシグネチャ 

このプロファイルは "オペレーションシグネチャ"(operation signature)を,WSDLバイン

ディングのオペレーションで記述されたSOAP入力メッセージのSOAP本体の子要素の完全

修飾名であると定義する。 

rpc-literalバインディングの場合,オペレーション名はパートのアクセッサに対するラッパ

ーとして使用される。document-literalバインディングの場合はオペレーション名をもつラッ

パーが存在しないので,メッセージのシグネチャがこの要件を満足するよう,正しく設計さ

れなければならない。 

 

複数のオペレーションをサポートするエンドポイントは,受信する入力メッセージを元に,どのオペレ

ーションが起動されたかをあいまい(曖昧)性なしに識別する必要がある。これは,一つのエンドポイン

トに対して wsdl:binding要素に指定されたすべてのオペレーションが,一意の伝送路シグネチャ(wire 

signature)をもつ場合にだけ可能である。 

 

R2710 DESCRIPTION の中の一つのwsdl:binding要素に属するオペレーションは,それぞ

れ相異なるオペレーションシグネチャをもたなければならない (MUST)。 

4.7.7 

一つのエンドポイントに対する複数のポート 

同一のネットワークエンドポイントにある,二つの異なるwsdl:port要素にあ(宛)てられた入力メ

ッセージが伝送路上で区別できない場合,それによって起動されるwsdl:port要素を決定できなくなる

可能性がある。これは相互運用上の問題になるかもしれない。しかし,(例えば,SOAPのバージョンの違

い,アプリケーションのバージョンの違い,異なるプロファイルへの適合など)一つ以上のport要素を一

つのエンドポイントに置いたほうがよい場合もあり得る。ゆえに,このプロファイルではそれを許してい

る。 

 


36 

X 7361:2010 (ISO/IEC 29361:2008) 

  

R2711 DESCRIPTION は,soapbind:address要素のlocation属性の値が同じwsdl:port

要素を複数もたないほうがよい (SHOULD NOT)。 

4.7.8 

document-literalバインディングの子要素 

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

完全に明確ではない。 

 

R2712 document-literal バインディングは,soap:Body要素の子要素が対応する 

wsdl:message要素の一つの part で参照される大域要素宣言のインスタンスである

ENVELOPEとしてシリアライズされなければならない (MUST)。 

4.7.9 

one-wayオペレーション 

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

 

R2714 one-wayオペレーションの場合,INSTANCE は エンベロープを含むHTTPレスポンスを

返してはならない (MUST NOT)。具体的には,レスポンスのHTTP entity-bodyは空でな

ければならない (MUST)。 

R2750 CONSUMER は,one-wayオペレーションのHTTPレスポンスメッセージで伝送された

エンベロープを無視しなければならない (MUST)。 

R2727 one-wayオペレーションの場合,CONSUMER はHTTPの正常終了レスポンスの状態コ

ード(すなわち,2xx)が,メッセージが正当であるとか,受信側がそれを処理すること

の印であると解釈してはならない (MUST NOT)。 

 

one-wayオペレーションはSOAPレスポンスを生成しない。よって,このプロファイルは,one-wayオペ

レーションのレスポンスとしてSOAPエンベロープを送ることを禁止している。これは,one-wayオペレ

ーションの伝送が,処理レベルのレスポンス又はエラーになってはならないことを意味する。この状況で

は,例えばフォルトを含んだHTTPレスポンス "500 Internal Server Error" を返すことができない。 

one-wayオペレーションにおけるHTTPレスポンスは,メッセージの伝送の成功又は失敗を示す。HTTP

プロトコルでサポートされているレスポンスコードの意味から,このプロファイルは,"200" 及び "202" 

が,one-wayオペレーションにおけるメッセージが受信されたことを示すものと送信者が期待するレスポ

ンス状態コードであると規定している。伝送が成功したことは,SOAP処理層及びアプリケーションロジ

ックがエンベロープを正しいと確認したとか,それを処理することが確定したとかを示すものではない。 

4.7.10 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)。 


37 

X 7361:2010 (ISO/IEC 29361:2008) 

 

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要素の子要素を名前空間修飾することを保証するた

め,省略可能ではなく必す(須)である。 

4.7.11 portType要素及びbinding要素の整合性 

WSDLの記述(description)は,wsdl:portType要素と wsdl:binding要素との両方のレベルで整

合していなければならない。 

 

R2718 DESCRIPTION の中のwsdl:binding要素は,それが参照する先のwsdl:portType要素と同

一のwsdl:operation要素の集合をもたなければならない (MUST)。〔明確化〕 

4.7.12 headerfault要素の記述 

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

 

R2719 DESCRIPTION の中の wsdl:binding要素は,既知のヘッダフォルトが存在しない場

合,soapbind:headerfault要素を指定しなくてもよい (MAY)。 

 

WSDL 1.1のスキーマは,オペレーションのwsdl:input要素及びwsdl:output要素に 

soapbind:headerfault要素を指定することを必す(須)としているが,WSDL 1.1の規格本文では省

略可能になっている。本文が正しい。 

4.7.13 フォルトの列挙 

Webサービスの記述は,サービスの定義時に知られているすべてのフォルトを含むのが望ましい。また,

Webサービスが定義されたときには認識されていなかった,新しいフォルトの生成も許容する必要がある。 

 

R2740 DESCRIPTION の中のwsdl:binding要素は,既知の各フォルトを記述する 

soapbind:fault要素を含むのが望ましい (SHOULD)。 

R2741 DESCRIPTION の中の wsdl:binding要素は,既知の各ヘッダフォルトを記述する 

soapbind:headerfault要素を含むのが望ましい (SHOULD)。 

R2742 ENVELOPE は,対応するWSDL記述内のsoapbind:fault要素によって記述されて

いないdetail要素とともにフォルトを含んでもよい (MAY)。 

R2743 ENVELOPE はSOAPヘッダブロックに,対応するWSDL記述の中の

soapbind:headerfault要素に記述されていないヘッダ処理関連のフォルトの詳細記

述を含んでもよい (MAY)。 


38 

X 7361:2010 (ISO/IEC 29361:2008) 

  

4.7.14 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 NOT)。 

 

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> 

4.7.15 フォルトの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)。 

4.7.16 use属性の省略 

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

 

R2722 DESCRIPTION の中のwsdl:binding要素は,それが含むsoapbind:fault要素に 

use属性を指定してもよい (MAY)。〔明確化〕 


39 

X 7361:2010 (ISO/IEC 29361:2008) 

 

R2723 DESCRIPTION の中のwsdl:binding要素の中で,それが含むsoapbind:fault要素

にuse属性が存在する場合,その値は "literal" でなければならない (MUST)。 

 

WSDL 1.1の3.6はsoapbind:fault要素にuse属性が必す(須)としているが,スキーマではuse

属性が省略可能になっている。このプロファイルでは,soapbind:body要素と整合性を取るため,この

属性を省略可能としている。 

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

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

だけにしている。 

4.7.17 use属性のデフォルト 

WSDL 1.1に,soapbind:body要素,soapbind:header要素及びsoapbind:headerfault要素に

おいて,use属性は省略可能かどうか,そして省略可能な場合,省略したときの意味はどうなるかという

点について,本文とスキーマとの間に不整合がある。 

 

R2707 DESCRIPTION の中の wsdl:binding要素が soapbind:body要素,

soapbind:fault要素,soapbind:header要素又は soapbind:headerfault要素

に use属性を指定しなかった場合,use属性は "literal" の値をもつものとみなさなけれ

ばならない (MUST)。 

4.7.18 エンベロープと記述との整合性 

次の要件は,インスタンスが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)。 

4.7.19 レスポンスのラッパー 

WSDL 1.1の3.5は,RPCレスポンスのラッパー要素がwsdl:operation要素の名前と同じでなければ

ならないと解釈することも可能である。 

 


40 

X 7361:2010 (ISO/IEC 29361:2008) 

  

R2729 rpc-literalバインディングで記述されたレスポンスの ENVELOPE は,ラッパー要素の名

前を,対応する wsdl:operation要素の名前の後ろに "Response" という文字列を付け

たものとしなければならない (MUST)。 

4.7.20 パートアクセッサ 

rpc-literalのエンベロープにおいて,WSDL 1.1は,パラメタ及び返却値のアクセッサ要素がどの名前空

間に属するのか(もし何かの名前空間に属するとして)という点が不明確である。処理系によってこの解

釈が異なり,相互運用の問題となる。 

 

R2735 rpc-literalバインディングに記述された ENVELOPE は,引数及び返却値に使用されるパ

ートアクセッサが,いかなる名前空間にも属さないものとして取り扱わなければならない 

(MUST)。 

R2755 rpc-literalバインディングで記述された MESSAGE 内のパートアクセッサは,対応する

wsdl:part要素の name属性と同じ値の局所名をもたなければならない (MUST)。 

 

いずれかの選択肢の一つにしぼることが,相互運用を達成するためには不可欠である。このプロファイ

ルは,単純で,すべての場合をカバーし,論理的に矛盾しないことから,アクセッサ要素をどの名前空間

にも属させないことにした。 

4.7.21 パートアクセッサの子要素の名前空間 

rpc-literalのエンベロープにおいて,WSDL 1.1は,対応する抽象的なpartがWSDL記述の

targetNamespaceとは違う名前空間に属する型であると定義される場合に,パートアクセッサの子要素

の正しい名前空間修飾は何なのか,明確ではない。 

 

R2737 rpc-literalバインディングで記述された ENVELOPE は,パラメタと返却値とに使用され

るパートアクセッサの子孫を,そのパートアクセッサの型が定義されているスキーマでの

定義のとおりに名前空間修飾しなければならない (MUST)。 

 

WSDL 1.1の3.5は,次のように規定している。 

Part要素のname属性,type属性及びnamespace属性の値は,すべてエンコーティングに対する入力だが,

namespace属性は,抽象型によって明示的に定義されなかった内容に適用されるだけである。 

しかし,[複合型(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/" になっている 


41 

X 7361:2010 (ISO/IEC 29361:2008) 

 

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"> 


42 

X 7361:2010 (ISO/IEC 29361:2008) 

  

     <input> 

       <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 のエンベロープを,次に示す: 

 

<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> 

4.7.22 必す(須)のヘッダ 

WSDL 1.1は,WSDL文書のSOAPバインディングの部分にあるwsdl:operation要素の wsdl:input

要素又はwsdl:output要素に指定されたすべてのsoapbind:header要素が,伝送されるときに結果

として生成されるエンベロープの中に含まれなければならないのかどうか,明確に規定していない。WSDL 

1.1ではヘッダが省略可能であることを指定する方法がないので,このプロファイルではすべてのヘッダを

必す(須)とした。 

 

R2738 ENVELOPE は,wsdl:binding要素のwsdl:operation要素に記述された 

wsdl:input要素又はwsdl:output要素に指定されたすべての soapbind:header

要素を含まなければならない (MUST)。 

4.7.23 記述にないヘッダの許容 

ヘッダはSOAPの拡張メカニズムである。様々な理由によって,WSDL文書に定義されていないヘッダ


43 

X 7361:2010 (ISO/IEC 29361:2008) 

 

がエンベロープに含まれる必要があるかもしれない。 

 

R2739 ENVELOPE は対応するWSDL記述の wsdl:binding要素の部分に記述されていない

SOAPヘッダブロックを含んでもよい (MAY)。 

R2753 適切な wsdl:binding要素に記述されていないSOAPヘッダブロックをもつ 

ENVELOPE は,それらのSOAPヘッダブロックのmustUnderstand属性を '1' に設

定してもよい (MAY)。 

4.7.24 ヘッダの並び順 

記述(description)の中のsoapbind:header要素の並び順と,メッセージのSOAPヘッダブロックの

並び順との間には何の関係もない。同様に,指定されたそれぞれのSOAPヘッダブロックがメッセージに

一つ以上現れてもよい。 

 

R2751 DESCRIPTION のsoapbind:binding要素部にあるsoapbind:header要素の並び順

は,エンベロープの中のSOAPヘッダブロックの並び順とは独立しているものとみなさ

なければならない (MUST)。 

R2752 ENVELOPE は,対応する記述 (description) の中のsoapbind:binding要素の適切な

子要素の中の各soapbind:header要素について,一つ以上のSOAPヘッダブロックを

もってよい (MAY)。 

4.7.25 SOAPActionの記述 

相互運用性テストによって明らかになっているように,HTTPのSOAPActionヘッダフィールドの値に

引用符を必す(須)とすることが実装の間の相互運用性を向上する。HTTP規格はヘッダフィールドの値

を引用符で囲まないことを許容しているが,幾つかの実装は値が引用符で囲まれていることを必す(須)

としている。 

SOAPActionヘッダフィールドは純粋に処理系に対するヒントである。メッセージの処理に本質的な情

報はすべてエンベロープに含まれる。 

 

R2744 HTTPのリクエスト MESSAGE は,HTTPのSOAPActionヘッダフィールドの値とし

てsoapbind:operation要素のsoapAction属性(DESCRIPTIONに存在する場合)

の値と同じ値を引用符で囲ったものを指定しなければならない (MUST)。 

R2745 HTTPのリクエスト MESSAGE は,soapbind:operation要素のsoapAction属性

が DESCRIPTION に存在しないか,又は存在するがその値として空文字列を指定された

場合,HTTPのSOAPActionヘッダフィールドの値として引用符で囲まれた空文字列を

指定しなければならない (MUST)。 

 

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

次に例を示す。 

 

正しい例: 

WSDL記述に次の要素: 

<soapbind:operation soapAction="foo" />  


44 

X 7361:2010 (ISO/IEC 29361:2008) 

  

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

SOAPAction: "foo"  

 

正しい例: 

WSDL記述に次の要素: 

<soapbind:operation />  

又は 

<soapbind:operation soapAction="" />  

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

SOAPAction: ""  

4.7.26 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)。 

4.8 

XML Schemaの使用 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ XML Schema Part 1: Structures (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/) 


45 

X 7361:2010 (ISO/IEC 29361:2008) 

 

・ XML Schema Part 2: Datatypes (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/) 

 

WSDL 1.1はXML Schemaを型付けシステムの一つとして使用する。このプロファイルではWSDLによ

るWebサービスの記述に対する型付けシステムとしてXML Schemaを使用することを必す(須)としてい

る。 

 

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

R2801 DESCRIPTION は,XML Schema 1.0勧告をユーザ定義のデータ型及び構造の基盤とし

て使用しなければならない (MUST)。 

 

サービスの公開及び発見 

UDDIは,Webサービスの公開(publication)及び発見(discovery)が必要な場合のためにこのプロファ

イルが採用した,Webサービスプロバイダとその提供するWebサービスとを記述するためのメカニズムで

ある。ビジネス,想定される用途及びWebサービス型の記述はUDDIの用語で行われ,詳細な技術的記述

はWSDLの用語で行われる。これら二つの規格は重なり合うデータの記述を定義しており,両方の形式の

記述が使われるが,このプロファイルは,これらの記述が衝突しないよう規定している。 

WebサービスインスタンスをUDDIレジストリに登録することは必す(須)ではない。すべての利用シ

ナリオがUDDIの提供する種類のメタデータと発見とを必要とするわけでは全くないが,そのような機能

が必要な場合は,UDDIはそのために使用すべきメカニズムである。 

UDDI V2を構成するWebサービスはBasic Profile 1.0に完全に適合するとはいえないことに注意が必要

である。なぜならば,メッセージのエンベロープにおける文字エンコーディングとして,このプロファイ

ルではUTF-8又はUTF-16のいずれでもよいとしているが,UDDI V2を構成するWebサービスは,UTF-8

だけを受け付けるからである。UDDI V2がこのプロファイル以前に設計され,多くの場合実装されている

ことを考えれば,そのような食い違いがあることは別に不思議ではない。UDDIの設計者はUDDI V2の不

適合を意識しており,将来考慮に入れるだろう。 

このプロファイルのこの箇条では,次の規格を引用する。 

 

・ UDDI Version 2.04 API Specification, Dated 19 July 2002 

(http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm) 

・ UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002 

(http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm) 

・ UDDI Version 2 XML Schema (http://uddi.org/schema/uddi̲v2.xsd) 

5.1 

bindingTemplate 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ UDDI Version 2.03 Data Structure Referenceの7 

(http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm#̲Toc25130769) 

 

UDDIは,WebサービスのINSTANCEをuddi:bindingTemplate要素として表現する。

uddi:bindingTemplate要素は,wsdl:port要素にほぼ相当する役割を果たすが,WSDLでは表現で


46 

X 7361:2010 (ISO/IEC 29361:2008) 

  

きない付加機能を提供する。INSTANCEのWSDL記述とUDDI記述との間の整合性を保つために,このプ

ロファイルはuddi:bindingTemplate要素の構成方法に対して次の制約を課す: 

WSDLのsoapbind:address要素は,インスタンスのネットワークアドレスが直接指定されている必

要がある。それに対して,UDDI V2では,インスタンスのネットワークアドレスを指定するのに二つの選

択肢がある。一つは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> 

5.2 

tModel 

このプロファイルのこの細分箇条では,次の規格(又はその箇条)を引用する。 

 

・ UDDI Version 2.03 Data Structure Referenceの8 

(http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm#̲Toc25130775)  

 

UDDIはWebサービスの型をuddi:tModel要素で表現する[UDDI Data Structuresの8.1.1

(http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm#̲Toc25130777)を参照]。それらは(URI

を使って)実際の記述を含む文書を指し示すことができるが,そうしなくてもよい。さらに,UDDIはWeb

サービスの型を記述するのに使われるメカニズムには何も規定していない。しかし,Webサービスの記述


47 

X 7361:2010 (ISO/IEC 29361:2008) 

 

がなかったり,記述形式がバラバラだったりすると相互運用が複雑になるので,このプロファイルで何も

規定しないわけには行かない。 

UDDI API Specificationの附属書I.1.2.1.1 

(http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm# Toc25137792)ではuddi:tModel

要素がWebサービスの記述にWSDLを使用することを許しているが,それを要求しているわけではない。

しかし,それを要求しないことは,どの記述言語が使われるか分からないことになるので,相互運用上問

題になる。 

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

ている。 

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

 

R3002 適合するWebサービス型を表現する uddi:tModel型の REGDATA は,記述言語とし

てWSDLを使用しなければならない (MUST)。 

 

適合するWebサービスの型がWSDLを使用することを指定するために,このプロファイルではそれを

主張するUDDIの分類科目を採用している。 

 

R3003 適合するWebサービス型を表現するuddi:tModel型の REGDATA は,UDDI Type分

類法に対応する分類科目の値として"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版

(http://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using-wsdl-v108-20021

110.htm )に従わなければならない (MUST)。 

 

uddi:tModel要素から参照される wsdl:binding要素がこのプロファイルに適合していない場合,

不整合になるだろう。 

 

R3011 uddi:tModel型の REGDATA から参照されるwsdl:binding要素は,それ自体がこ

のプロファイルに適合していなければならない (MUST)。 

 

セキュリティ 

ネットワーク指向のすべての情報技術にいえることだが,セキュリティの問題はWebサービスにおいて

も重大である。Webサービスでは,セキュリティは,他の情報技術と同様,攻撃者がとり得る潜在的な脅

威を理解することと,攻撃が成功するリスクを許容可能なレベルまで下げるために,作業的,物理的及び


48 

X 7361:2010 (ISO/IEC 29361:2008) 

  

技術的な対抗手段をとることとから成り立っている。“リスクの許容可能なレベル”がアプリケーションに

よって大きく変わること,及び対抗手段を実現するためのコストも同様に大きく変わることから,Webサ

ービスをセキュアにするための,どこにでも適用できる“正解”などというものはあり得ない。対抗手段

と許容可能なリスクとの間の完全なバランスを取ることは,個別の場合ごとにしかできないだろう。 

それでも,多くのWebサービスにおいてリスクを許容可能なレベルに下げる経験的な対抗手段の共通パ

ターンというものは存在する。このプロファイルは,それらのうち最も広く使われているものを,使用を

強制はしないが,採用している。それはTLS 1.0又はSSL 3.0のいずれかで暗号化されたHTTP(HTTPS)

である。すなわち,適合するWebサービスはHTTPSを使用してもよい。他の対抗手段と併用してもよい

し,何も使わなくてもよい。 

HTTPSは,基本的なレベルの秘匿性を実現する,暗号化トランスポート接続の枯れた標準であると,広

く認められている。したがって,HTTPSは,多くの現実世界のWebサービスアプリケーションが必要と

する基本的なセキュリティ機能を実現する,最も単純な手段となっている。HTTPSは,クライアント証明

書を使うことによって,クライアント認証に使用してもよい。 

このプロファイルのこの箇条では,次の規格を引用し,その中での拡張点を定義する。 

 

・ RFC2818: HTTP Over TLS (http://www.ietf.org/rfc/rfc2818.txt) 

・ RFC2246: The TLS Protocol Version 1.0 (http://www.ietf.org/rfc/rfc2246.txt)  

拡張点: 

 E0019−TLS暗号化スイート−TLSは,任意の暗号化アルゴリズムの使用を許してい 

る。 

 E0020−TLS拡張−TLSは,ハンドシェイク段階で拡張を許している。 

・ The SSL Protocol Version 3.0 (http://wp.netscape.com/eng/ssl3/draft302.txt)  

拡張点:  

 E0021−SSL暗号化スイート−SSLは,任意の暗号化アルゴリズムの使用を許している。 

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

(http://www.ietf.org/rfc/rfc2459.txt)  

拡張点:  

 E0022−認証局−認証局の選択は,通信当事者間の個別合意による。 

 E0023−証明書拡張−X509は,任意の証明書拡張を許している。 

6.1 

HTTPSの使用 

HTTPSは,とても有用かつ広く理解されている基本的なセキュリティ機構なので,このプロファイルで

使用を許す必要がある。 

 

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

R5001 INSTANCE がHTTPSの使用を必す(須)とする場合,wsdl:port定義にある

soapbind:address要素のlocation属性は,"https" スキームのURIでなければ

ならない (MUST)。そうでない場合,それは "http" スキームのURIでなければならな

い (MUST)。 

 

単純なHTTPSは,利用者(consumer)によるWebサービスインスタンスの認証機能を提供するが,イ


49 

X 7361:2010 (ISO/IEC 29361:2008) 

 

ンスタンスによる利用者の認証機能は提供しない。多くの場合,これは相互運用のリスクを高すぎるレベ

ルにしてしまう。HTTPSの相互認証機能をこのプロファイルに含めることで,インスタンスが利用者を認

証するという対抗手段を許容する。利用者によるインスタンスの認証では不十分な場合,これは相互運用

のリスクを十分に引き下げることになる。 

 

R5010 INSTANCE は,相互認証(mutual authentication)のHTTPSの使用を必す(須)として

もよい (MAY)。 

 


50 

X 7361:2010 (ISO/IEC 29361:2008) 

  

附属書A 

(規定) 
引用規格 

 

次の規格の要件は,このプロファイルで置き換えられたものを除き,引用することでこのプロファイル

に取り込まれている。 

 

・ Namespaces in XML 1.0 (http://www.w3.org/TR/1999/REC-xml-names-19990114/) 

注記 JIS X 4158:2005 XML名前空間は,Namespaces in XML 1.0  

(http://www.w3.org/TR/1999/REC-xml-names-19990114/)に対応している。 

・ Simple Object Access Protocol (SOAP) 1.1 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) 

・ RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 (http://www.ietf.org/rfc/rfc2616.txt) 

・ RFC2965: HTTP State Management Mechanism (http://www.ietf.org/rfc/rfc2965.txt) 

・ Extensible Markup Language (XML) 1.0 (Second Edition) 

(http://www.w3.org/TR/2000/REC-xml-20001006) 

注記 JIS X 4159:2005 拡張可能なマーク付け言語(XML)1.0は,Extensible Markup Language 

(XML) 1.0 (Third Edition) (http://www.w3.org/TR/2004/REC-xml-20040204) に対応してい

る。 

・ XML Schema Part 1: Structures (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/) 

・ XML Schema Part 2: Datatypes (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/) 

・ Web Services Description Language (WSDL) 1.1 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315) 

・ UDDI Version 2.04 API Specification, Dated 19 July 2002 

(http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm) 

・ UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002 

(http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm) 

・ UDDI Version 2 XML Schema (http://uddi.org/schema/uddi̲v2.xsd) 

・ RFC2818: HTTP Over TLS (http://www.ietf.org/rfc/rfc2818.txt)  

・ RFC2246: The TLS Protocol Version 1.0 (http://www.ietf.org/rfc/rfc2246.txt) 

・ The SSL Protocol Version 3.0 (http://wp.netscape.com/eng/ssl3/draft302.txt) 

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

(http://www.ietf.org/rfc/rfc2459.txt) 


51 

X 7361:2010 (ISO/IEC 29361:2008) 

 

附属書B 

(参考) 

拡張点 

 

この附属書では,“1.1 適用範囲”の中で,このプロファイルの構成要素の仕様として定義した,規格の

拡張点を列挙する。 

これらのメカニズムはこのプロファイルの適用範囲外である。これらを使うことが相互運用性に影響す

るかもしれないし,Webサービスの関係者での個別合意が必要かもしれない。 

 

Simple Object Access Protocol (SOAP) 1.1 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/):  

 

・ E0001−ヘッダブロック−ヘッダブロックはSOAPの根本的な拡張メカニズムである。 

・ E0002−処理順序−SOAPメッセージの構成要素(例えば,ヘッダ)の処理順序は規定がなく,

別途調整(out-of-band negotiation)が必要かもしれない。 

・ E0003−中継ノード(intermediaries)の使用−SOAPの中継ノードはSOAP 1.1では規定が不十分

であり,その利用には別途調整(out-of-band negotiation)が必要かもしれない。また,それを使用

するときには,どこでプロファイルの適合性を測定するかについて注意深い検討が必要になるか

もしれない。 

・ E0004−soap:actor値−soap:actor属性の値(特殊なURI 'http://schemas.xmlsoap.org/soap/actor/next' 

以外)は,Web サービスの関係者間の個別合意を表す。 

・ E0005−フォルトのdetail要素−フォルトのdetail要素の内容はSOAP 1.1では規定されていな

い。 

・ E0006−エンベロープ シリアライゼーション−このプロファイルは,エンベロープがどのように

メッセージ中にシリアライズされるかについて,幾つかの側面は制約しない。 

 

RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 (http://www.ietf.org/rfc/rfc2616.txt):  

 

・ E0007−HTTP認証−HTTPの認証は,拡張スキーム,任意のダイジェストハッシュアルゴリズ

ム及びパラメタを許容している。 

・ E0008−規定がないヘッダフィールド−HTTPは任意のヘッダがメッセージに現れることを許容

している。 

・ E0009−Expect拡張−HTTPのExpect/ContinueメカニズムはExpect拡張を許容している。 

・ E0010−Content-Encoding−HTTPで許容される内容エンコーディング(content-encoding)は無制

限であり,'gzip','compress','deflate' 以外のあらゆる形式が拡張点となる。 

・ E0011−Transfer-Encoding−HTTPで許容される伝送エンコーディング(transfer-encoding)は無

制限である。 

・ E0012−Upgrade−HTTPは,Upgradeヘッダを使うことで,接続を任意のプロトコルに切り替え

ることを許容している。 

・ E0024−名前空間属性−soap:Envelope要素及びsoap:Header要素の名前空間属性。 


52 

X 7361:2010 (ISO/IEC 29361:2008) 

  

・ E0025−soap:Body要素の属性−名前空間修飾された属性も局所属性もSOAP 1.1によって制約さ

れない。 

 

XML Schema Part 1: Structures (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/) 

 

・ E0017−スキーマの注釈(annotation)−XML Schemaは注釈を許しており,データ構造について

の追加の情報を記述するために使ってもよい。 

 

Web Services Description Language (WSDL) 1.1 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315):  

 

・ E0013−WSDL拡張−WSDLは特定の位置に拡張の要素及び属性を入れることを許す。そのよう

な拡張の使用には別途調整(out-of-band negotiation)が必要である。 

・ E0014−妥当性検証モード−WSDL及びXML Schema文書を読み込むパーサーがDTDの妥当性

検証を行うかどうか。 

・ E0015−外部資源の取り込み−WSDL及びXML Schema文書を読み込むパーサーが外部実体及び

DTDを取り込むかどうか。 

・ E0016−相対URI−WSDLは次の相対URIの使い方について適切に規定していない。

soapbind:body/@namespace,soapbind:address/@location,wsdl:import/@location, 

xsd:schema/@targetNamespace,及びxsd:import/@schemaLocation。その使用については,更に調整

が必要である(詳細については,XML Baseを参照)。 

 

RFC2246: The TLS Protocol Version 1.0 (http://www.ietf.org/rfc/rfc2246.txt):  

 

・ E0019−TLS暗号化スイート−TLSは任意の暗号化アルゴリズムの使用を許している。 

・ E0020−TLS拡張−TLSはハンドシェイク段階で拡張を許している。 

 

SSL Protocol Version 3.0 (http://wp.netscape.com/eng/ssl3/draft302.txt):  

 

・ E0021−SSL暗号化スイート−SSLは任意の暗号化アルゴリズムの使用を許している。 

 

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

(http://www.ietf.org/rfc/rfc2459.txt):  

 

・ E0022−認証局−認証局の選択は通信当事者間の個別合意による。 

・ E0023−証明書拡張−X509は任意の証明書拡張を許している。 

 


53 

X 7361:2010 (ISO/IEC 29361:2008) 

 

附属書C 
(参考) 
参考規格 

 

附属書Aに列挙されている,プロファイル化された規格に加えて,次の規格が参照される。 

 

・ RFC2119, http://ietf.org/rfc/rfc2119, Key words for use in RFCs to Indicate Requirement Levels, S. 

Bradner, March 1997. 

・ WS-I Basic Profile 1.0, http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html, K. Ballinger et al., 

April 2004. 

・ Namespaces in XML 1.0(XML名前空間1.0)(Second Edition),  

http://www.w3.org/TR/2006/REC-xml-names-20060816, T. Bray et al.,August 2006. 

・ WS-I Conformance Claim Attachment Mechanisms Version 1.0,  

http://www.ws-i.org/Profiles/ConformanceClaims-1.0-2004-11-15.html, M.Nottingham et al., November 

2004. 

・ XML Base (http://www.w3.org/TR/2001/REC-xmlbase-20010627/) 

 


54 

X 7361:2010 (ISO/IEC 29361:2008) 

  

附属書D 
(参考) 

定義された用語 

 

次に列挙する用語は,このプロファイルのための権威ある特定の定義をもつ。 

 

rpc-literal バインディング 

“rpc-literalバインディング”とは,その子要素のwsdl:operation要素がすべてrpc-literal

オペレーションであるwsdl:binding要素のことである。 

“rpc-literalオペレーション”とは,wsdl:binding要素の子要素であるwsdl:operation

要素で,その子孫であるsoapbind:body要素がuse属性に "literal" の値を指定しており,

それが次のいずれかであるもののことである。 

1. 

値 "rpc" をもつstyle属性が子要素soapbind:operation要素で指定される。 

2. 

style属性が子要素soapbind:operation要素に存在せず,それを囲む

wsdl:binding要素のsoapbind:binding要素が,値 "rpc" をもつstyle属

性を指定する。 

 

document-literal バインディング 

“document-literalバインディング”とは,その子要素のwsdl:operation要素がすべて 

document-literalオペレーションであるwsdl:binding要素のことである。 

“document-literalオペレーション”とは,wsdl:binding要素の子要素である

wsdl:operation要素で,その子孫であるsoapbind:body要素がuse属性に "literal" の

値を指定しており,それが次のいずれかであるもののことである。 

1. 

値 "document" をもつstyle属性が子要素soapbind:operation要素で指定

される。 

2. 

style属性が子要素soapbind:operation要素に存在せず,それを囲む

wsdl:binding要素のsoapbind:binding要素が,値 "document" をもつ

style属性を指定する。 

3. 

style属性が,子要素のsoapbind:operation要素とそれを囲む 

wsdl:binding要素のsoapbind:binding要素とのいずれにも存在しない。 

 

オペレーションシグネチャ 

このプロファイルは "オペレーションシグネチャ" を,WSDLバインディングのオペレー

ションで記述されたSOAP入力メッセージのSOAP本体の子要素の完全修飾名であると定義

する。 

rpc-literalバインディングの場合,オペレーション名はパートのアクセッサに対するラッパ

ーとして使用される。document-literalバインディングの場合はオペレーション名をもつラッ

パーが存在しないので,メッセージのシグネチャがこの要件を満足するよう,正しく設計さ

れなければならない。 


55 

X 7361:2010 (ISO/IEC 29361:2008) 

 

附属書E 

(参考) 

謝辞 

 

(対応国際規格では,規格策定の貢献者を列挙しているが,この規格では不要であり,不採用とした。) 

 


56 

X 7361:2010 (ISO/IEC 29361:2008) 

  

附属書JA 

(参考) 

用語集 

 

この附属書は,用語の使用方法の例を示すものであり,規格の一部ではない。 

 

JA.1 

バインディング(binding) 

バインディングは,サービスの仕様を表現したインタフェースと,インタフェースで定義されたメッセ

ージを伝送するための具体的な伝送プロトコル及びデータフォーマットとを関連付けるものである。バイ

ンディングの指定は,SOAPバインディング,HTTPバインディングなどそれぞれの箇所で行う。 

 

JA.2 

バイト順マーク(BOM) 

データの記録・送信を行うときのバイトの並び順パターンであるエンディアン(big-endian,little-endian)

を識別するために,ファイルの先頭に付与される符号。 

 

JA.3 

複合型(complex Type) 

子要素又は属性をもつ要素の型。そのような型は,XML SchemaにおいてはcomplexType要素を使って

定義される。 

 

JA.4 

内容エンコーディング(Content-Encoding) 

HTTPヘッダにおいて,メッセージ本体がどのように符号化されているかを示すのに用いられる。具体

的には,メッセージ本体をデータ圧縮する場合の圧縮形式を指定するのに用いられる。 

例 Content-Encoding: gzip 

 

JA.5 

中継ノード(intermediary) 

SOAPメッセージを中継するノード。SOAPメッセージは,メッセージの発信ノードから最終的な受信

ノードまでの間に複数のノードを中継することが考慮されており,発信ノードと最終的な受信ノードとの

間にあるノードを中継ノードと呼ぶ。中継ノードとしては,単にメッセージのルーティングをするもの,

メッセージの一部を処理して変更するものなどがある。 

 

JA.6 

名前空間(namespace) 

特定のXML標準スキーマによって定められた要素名及び属性名の集合。XMLインスタンスでは,要素

を“名前空間接頭辞:要素名”,属性を“名前空間接頭辞:属性名”という形式で記述する。名前空間接頭


57 

X 7361:2010 (ISO/IEC 29361:2008) 

 

辞によって,要素及び属性がどの名前空間に属するかを見分ける。この書き方を使って,複数のXMLス

キーマで定義された要素及び属性を,一つのXMLインスタンス内で混在させて使うことができる。 

 

JA.7 

パート(part) 

パートはメッセージの構成要素である。パートによってメッセージの論理的構造・抽象的構造を柔軟に

表現できる。パートのバインディング固有の情報を指定するために,バインディングでパートの名前を参

照しなければならない場合がある。例えば,RPCでメッセージを伝送する場合には,パートは引数を表す

可能性があるが,パートの実際の意味を決めるためにはバインディングを確認する必要がある。メッセー

ジが複数の論理的構造を含む場合には,マルチパート要素で表現する。 

 

JA.8 

処理命令(processing instruction) 

XML文書内で,""<?""及び""?>"" で囲まれる範囲に,アプリケーションに対する処理命令を指定する。

""<?""の直後の文字列が,その処理命令のターゲットとなるアプリケーションを示す。XML文書冒頭の

XML宣言も処理命令の一種である。 

例 <?xml version=""1.0"" encoding=""Shift̲JIS""?> 

 

JA.9 

シリアライゼーション,シリアル化(serialization) 

SOAPでRPCを行うためには,メソッドの引数及び戻り値に使われる変数,配列,オブジェクトなどを

XML文書に変換したり,元に戻したりする必要がある。データをXML文書に変換することを“エンコー

ド”又は“シリアライズ”,元に戻すことを“デコード”又は“デシリアライズ”という。シリアライゼー

ションは,シリアライズする行為である。 

 

JA.10 

シグネチャ(signature) 

オペレーションを一意に識別するときには,オペレーション名,そのオペレーションに対する引数の総

数,並びにそのすべての引数の型及び出現順序を用いる。この情報をまとめてシグネチャと呼ぶ。例えば,

同じオペレーション名であっても,引数の型又は数が異なれば異なるシグネチャとなり,別のオペレーシ

ョンとして扱われる。 

 

JA.11 

伝送エンコーディング(Transfer-Encoding) 

HTTPヘッダにおいて,送受信のときに,メッセージ本体にどのようなタイプの変換が行われるかを示

すのに用いられる。HTTP1.1では,設定される値としてchunkedだけが規定されている。chunkedが指定

された場合,メッセージ本体は幾つかの塊(chunk)に分割されて送受信される。 

例 Transfer-Encoding: chunked 

 

 


58 

X 7361:2010 (ISO/IEC 29361:2008) 

  

JA.12 

エンドポイント(endpoint) 

WSDLは,ネットワーク上で提供されるサービスをエンドポイントの集合として表現するためのXML

形式である。エンドポイントは,バインディングとURIで表されるネットワークアドレスとの間の関連で

あり,サービスのインスタンスと通信を行うために使われる。エンドポイントは,特定のプロトコル及び

データ形式を用いて,サービスを利用するための場所を特定する。 

 

JA.13 

イニシエータ(initiator) 

HTTPリクエストの元々の発行者。HTTPリクエストを仲介するプロキシ,ゲートウェイなどのことでは

ない。 

 

JA.14 

シンボル空間(symbol space) 

シンボル空間は,名前空間を定義の種類ごとに更に分けた空間である。シンボル空間が異なれば,出現

する文脈が異なるので,同じ名前が存在してもよい。各々のシンボル空間内では,名前は一意である。 

WSDL 2.0では,インタフェース,バインディング及びサービスに対して,それぞれのシンボル空間を

定義する。そのため,例えば,同じ名前をもつインタフェースとバインディングとが存在しても問題はな

い。XMLスキーマをWSDLの型記述システムとして利用する場合には,大域要素宣言,大域属性宣言,

名前付きモデルグループ,名前付き属性グループ,型定義及びキー制約の六つのシンボル空間が追加され

る。