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>
――――― [JIS X 7361 pdf 16] ―――――
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要素の中に追加の情報を入れる方式を推奨している。
別の方式として,独自のフォルトコードを規定する機関の管理下にある名前空間の中で定義することも
許容している。
幾つかの規格では既にドット記法を使った独自のフォルトコードを定義している。それにもかかわらず,
それらを将来の規格で使うことは推奨しない。
――――― [JIS X 7361 pdf 17] ―――――
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)
――――― [JIS X 7361 pdf 18] ―――――
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)。〔明確化〕
――――― [JIS X 7361 pdf 19] ―――――
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状態コードに関する記述を参照。
――――― [JIS X 7361 pdf 20] ―――――
次のページ PDF 21
JIS X 7361:2010の引用国際規格 ISO 一覧
- ISO/IEC 29361:2008(IDT)
JIS X 7361:2010の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.100 : 開放型システム間相互接続(OSI) > 35.100.05 : マルチレイヤアプリケーション