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)。〔明確化〕
――――― [JIS X 7361 pdf 41] ―――――
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) nvelope要素の名前空間が正しくない場合,
"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要素の名前と同じでなければ
ならないと解釈することも可能である。
――――― [JIS X 7361 pdf 42] ―――――
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/" になっている
――――― [JIS X 7361 pdf 43] ―――――
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">
――――― [JIS X 7361 pdf 44] ―――――
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文書に定義されていないヘッダ
――――― [JIS X 7361 pdf 45] ―――――
次のページ PDF 46
JIS X 7361:2010の引用国際規格 ISO 一覧
- ISO/IEC 29361:2008(IDT)
JIS X 7361:2010の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.100 : 開放型システム間相互接続(OSI) > 35.100.05 : マルチレイヤアプリケーション