この規格ページの目次
2
X 7362 : 2010 (ISO/IEC 29362 : 2008)
1.2 他のプロファイルとの関係
このプロファイルは,SOAP with Attachments及びMIMEバインディングに対するサポートを追加し,JIS
X 7361:2010と組み合わせて用いることを意図している。
1.3 表記法
この規格では,“···しなければならない (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" のような場合),その要件が存在する規格の箇条の適合性URI (conformance URI) によって識別さ
れる名前空間に属すると解釈するのが望ましい。名前空間修飾されている場合,その接頭辞は,次に記述
するとおり,そこで有効な名前空間の対応付けに従って解釈するのが望ましい。
幾つかの要件は,引用規格を明確化するだけで,実装に対して追加の制約を課さないものである。便宜
のため,規定の明確化 (clarification) は,次の例のように規定の後に“〔明確化〕”という注意を付けて表現
する。
例 Rnnnn ······は,······でなければならない。〔明確化〕
幾つかの要件は,引用規格の標準化されつつある内容を取り入れたものである。便宜上,そのような規
格の先取りは,次のように注記される: xxxx,ただし,ここで "xxxx" は,規格を示す識別子である(例え
ば,"WSDL20" はWSDL 2.0を示す。)。そのような規格はこの規格の対応国際規格の発行時点では完成し
ておらず,先取りした規格が変更されることもあり得ることに注意が必要である。この情報は,実装者に
対する便宜としてだけ含められている。
基となる規格にある拡張点 (extensibility point) (2.3参照)は,同様に表示される。
Ennnn−拡張点の名前−拡張点の記述
ただし,ここで "nnnn" は,このプロファイル内で一意の拡張点番号で置き換えられる。要件の記述と
同様,拡張点の記述も名前空間によって修飾されていると考えることができる。
この規格では,全体を通して次に示す幾つかの名前空間接頭辞 (namespace prefix) を使用する。各接頭
――――― [JIS X 7362 pdf 6] ―――――
3
X 7362 : 2010 (ISO/IEC 29362 : 2008)
辞に関連付けられた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/"
・ mime−"http://schemas.xmlsoap.org/wsdl/mime/"
・ uddi−"urn:uddi-org:apiv2"
・ wsi−"http://www.ws-i.org/schemas/conformanceClaim"
・ ref−"http://ws-i.org/profiles/basic/1.1/xsd"
1.4 プロファイルの識別及び版数
この規格は,名前(この場合,Attachments Profile)及び版数(ここでは,1.0)で識別される。両方を合
わせて,特定のプロファイルインスタンス (profile instance) を識別する。
版数の番号はメジャー番号及びマイナー番号で構成され,"メジャー番号.マイナー番号" の形式となる。
これらは,プロファイルの優先度を決定するのに利用できる。(メジャー番号及びマイナー番号の両方を考
慮して)版数の番号が大きい場合,そのインスタンスは新しく,それ以前のインスタンスを置き換える。
同じ名前のプロファイルの複数のインスタンス(例えば,"Example Profile 1.1","Example Profile 5.0")
は,同じ一般的な適用範囲内にある相互運用性の問題に言及している(もっとも,状況の進展によって,
プロファイルの厳密な適用範囲がインスタンスの間で変わることがある。)。
この情報は,あるプロファイルの二つのインスタンスが後方互換 (backwards-compatible) であるかどう
か(すなわち,前のプロファイルインスタンスへの適合が後のプロファイルインスタンスへの適合を暗示
するものと想定できるかどうか。)を判断するために使用できる。同じ名前とメジャー番号とをもつ複数の
プロファイルインスタンス(例えば,"Example Profile 1.0" 及び "Example Profile 1.1")は,互換性がある
と考えてもよい。これは,逆方向への互換性を暗示するものではないことに注意が必要である。すなわち,
後のプロファイルインスタンスへの適合は,前のプロファイルインスタンスへの適合を暗示するものと想
定することはできない。
2 プロファイルに対する適合性
このプロファイルに対して適合しているということは,このプロファイルの適用範囲 (scope) 内で,特
定の対象 (target) に対する要件 (requirements) の集合を守ることであると定義されている。この箇条では,
これらの用語について説明し,どのように適合性が定義され使用されるかを説明する。
2.1 適合性の要件
要件 (requirements) は,このプロファイルに対する適合性の基準を提示する。要件は,典型的には既存
の規格を引用し,そこでの相互運用性を向上する詳細化,強化 (amplify),解釈及び明確化を具体化したも
のである。このプロファイルのすべての要件は規定 (normative) と解釈され,引用規格のうちの適用範囲
内の要件(2.3参照)も同様に規定と解釈されるのが望ましい。このプロファイルの要件と引用規格の要件
とが互いに矛盾する場合,プロファイル適合性の観点からは,このプロファイルの要件が優先される。
――――― [JIS X 7362 pdf 7] ―――――
4
X 7362 : 2010 (ISO/IEC 29362 : 2008)
要件レベルは,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記述,
UDDIレジストリデータ)又はどの主体 (party) (例えば,SOAP処理系,エンドユーザ)に要件が適用さ
れるかを識別するのに使われる。
これによって,異なる文脈における適合性の定義であっても,要件の適用可能性をあいまい(曖昧)性
なく解釈されることが保証され,さらに,対象物(例えば,SOAPメッセージ,WSDL記述)及び各種の
Webサービスの主体(例えば,クライアント,サービスのインスタンス)の動作に対する適合性試験が可
能となる。
試験を単純にし,あいまい(曖昧)性を排除するため,要件の適合性対象は可能な限り物理的な対象物
である。
このプロファイルでは,次の適合性対象を使用する。
・ MESSAGE−ENVELOPEを伝送する,プロトコルの構成要素(例えば,SOAP/HTTPメッセージ)
[JIS X 7361:2010 (ISO/IEC 29361:2008) ]
・ ENVELOPE−soap:Envelope要素をシリアライズしたもの及びその内容 [JIS X 7361:2010
(ISO/IEC 29361:2008) ]
・ DESCRIPTION−データ型の記述,メッセージの記述,インタフェース及びそれらの具体的なプ
ロトコル・データ形式へのバインディングの記述,並びにWebサービスに関連付けられたネット
ワーク上のアクセスポイントの記述(例えば,WSDL記述) [JIS X 7361:2010 (ISO/IEC
29361:2008) ]
・ INSTANCE−wsdl:port要素又はuddi:bindingTemplate要素を実装するソフトウェア[JIS
――――― [JIS X 7362 pdf 8] ―――――
5
X 7362 : 2010 (ISO/IEC 29362 : 2008)
X 7361:2010 (ISO/IEC 29361:2008) ]
・ CONSUMER−INSTANCEを起動 (invoke) するソフトウェア [JIS X 7361:2010 (ISO/IEC
29361:2008) ]
・ SENDER−関連付けられたプロトコルに基づき,メッセージを生成 (generate) するソフトウェア
[JIS X 7361:2010 (ISO/IEC 29361:2008) ]
・ RECEIVER−関連付けされたプロトコルに基づき,メッセージを受信 (consume) するソフトウェ
ア(例えば,SOAP処理系) [JIS X 7361:2010 (ISO/IEC 29361:2008) ]
2.3 適合性の適用範囲
このプロファイルは,既存の技術を採用(引用)し,その明確化を行う。言い換えれば,このプロファ
イルは,その適用範囲の中での相互運用性を向上することだけを図っている。一般的には,このプロファ
イルの適用範囲は,それが引用する規格によって限定される。
このプロファイルの適用範囲は,拡張点 (extensibility points) によって更に詳細化される。引用規格は,
拡張メカニズム,及び未規定の又は未確定の構成パラメタを提供していることがある。このプロファイル
で拡張点と認識された場合,そのようなメカニズム又はパラメタはこのプロファイルの適用範囲外であり,
それを使っても使わなくてもこのプロファイルに対する適合性において意味をもたない。
このプロファイルは,さらに,拡張点の使用について,その範囲を制限することなく,要件を課すこと
がある。また,拡張点の特定の使用方法について,このプロファイルが他のプロファイルと組み合わせて
使われた場合に,相互運用性を向上するために,他のプロファイルで制限されることがある。
拡張点の使用は相互運用性を損なうことがあるので,その使用はWebサービスの関係者によって何らか
の形で個別協議するか,文書化するのが望ましい。例えば,これは個別合意 (out-of-band agreement) の形
をとるかもしれない。
このプロファイルの適用範囲は,附属書Aの引用規格によって定義され,附属書Bの拡張点によって詳
細化される。
2.4 適合性の表示
このプロファイルに対する適合性の表示は,Conformance Claim Attachment Mechanisms
(http://www.ws-i.org/Profiles/ConformanceClaims-1.0.html,適合性表示添付メカニズム)の記述に従い,次
に示す各メカニズムを使って行うことができる。この場合,各メカニズムが列挙する対象物に関連付けら
れた,このプロファイルの適用可能要件が満足されていることが条件となる。
・ Webサービスインスタンスに対するWSDL 1.1適合性表示添付メカニズム−MESSAGE
DESCRIPTION INSTANCE RECEIVER
・ WSDL記述の構造に対するWSDL 1.1適合性表示添付メカニズム−DESCRIPTION
・ Webサービスインスタンスに対するUDDI適合性表示添付メカニズム−MESSAGE
DESCRIPTION INSTANCE RECEIVER
このプロファイルに対する適合性表示URIは,"http://ws-i.org/profiles/attachments/1.0" である。
3 添付データのパッケージング
このプロファイルのこの箇条では,次の規格を引用し,その中での拡張点を規定する。
――――― [JIS X 7362 pdf 9] ―――――
6
X 7362 : 2010 (ISO/IEC 29362 : 2008)
・ SOAP Messages with Attachments (http://www.w3.org/TR/SOAP-attachments#SOAPMultipart)
拡張点 :
○
E0001−MIMEパート−SOAP Messages with Attachmentsは,multipart/relatedメッセージの
非ルートパート (non-root part) の型には制限を置かない。
・ 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/) ]
・ RFC2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
(http://ietf.org/rfc/rfc2557)
・ JIS X 5810-1 多目的インターネットメール拡張 (MIME) −第1部 : インターネットメッセージ
本体のフォーマット [RFC2045 Multipurpose Internet Mail Extensions (MIME) art One: Format
of Internet Message Bodies (http://ietf.org/rfc/rfc2045) ]
・ JIS X 5810-2 多目的インターネットメール拡張 (MIME) −第2部 : メディア型 [RFC2046
Multipurpose Internet Mail Extensions (MIME) art Two: Media Types (http://ietf.org/rfc/rfc2046) ]
・ RFC2392 Content-ID and Message-ID Uniform Resource Locators (http://ietf.org/rfc/rfc2392)
SOAP Messages with Attachmentsは,SOAPエンベロープを添付データとともにパッケージングするため
のMIME multipart/related構造を定義する。このプロファイルは,この構造を利用することを必す
(須)としており,その利用方法について,次の制約を課す。
3.1 ルートパート
R2931 multipart/related MESSAGEのルートパート (root part) の実体本体 (entity body)
は,soap:Envelope要素でなければならない (MUST)。
R2945 MESSAGEの中のContent-Type HTTPヘッダフィールドの値は,"multipart/related" 又は
"text/xml" のいずれかでなければならない (MUST)。〔明確化〕
R2932 MESSAGEの中のContent-Type HTTPヘッダフィールドの値が "multipart/related" のメ
ディア型の場合,そのメッセージの中のContent-Type HTTPヘッダフィールドの値は
typeパラメタの値が "text/xml" でなければならない (MUST)。〔明確化〕
いずれのMIMEパートもsoap:Envelope要素を含んでよいが,MIMEパッケージのルートパートの本
体だけが,基本のSOAPエンベロープとして扱われる。非ルートパート (non-root parts) は,添付データと
して参照される。
次に例を示す。
正しい例 :
次のメッセージでは,Content-Type HTTPヘッダフィールドの値は,メディア型が
"Multipart/Related" でtypeパラメタの値が "text/xml" となっている。
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIMEboundary; type=text/xml;
――――― [JIS X 7362 pdf 10] ―――――
次のページ PDF 11
JIS X 7362:2010の引用国際規格 ISO 一覧
- ISO/IEC 29362:2008(IDT)
JIS X 7362:2010の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.100 : 開放型システム間相互接続(OSI) > 35.100.05 : マルチレイヤアプリケーション
JIS X 7362:2010の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX5810-1:2008
- 多目的インターネットメール拡張(MIME)―第1部:インターネットメッセージ本体のフォーマット
- JISX5810-2:2008
- 多目的インターネットメール拡張(MIME)―第2部:メディア型