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

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)を含んでいる。

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

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

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

つの部分からなる。すなわち,構成要素となる規格及び拡張点(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 に対する適合範囲を合わせたものは,おおよそ公開された


2

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)

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


3

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"


4

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

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

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


5

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 記述,


6

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)の形

をとるかもしれない。


7

X 7361

:2010 (ISO/IEC 29361:2008)

このプロファイルの適用範囲は,

附属書 の引用規格によって定義され,附属書 の拡張点によって詳

細化される。

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)

拡張点:


8

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

でない場合,そのエンベロープを破棄することを規定している。

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

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


9

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 の で禁止されている。

公開された正誤表 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 

例 は,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 

例 及び例 は,間違って 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 
(参考) 
参考規格

附属書 に列挙されている,プロファイル化された規格に加えて,次の規格が参照される。

・ 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 の型記述システムとして利用する場合には,大域要素宣言,大域属性宣言,

名前付きモデルグループ,名前付き属性グループ,型定義及びキー制約の六つのシンボル空間が追加され

る。