/

JIS X 7361:2010 Ｗｅｂサービス相互運用性―ＷＳ－Ｉ ベーシックプロファイル１．１ | ページ 2

次のページ
                                                                                              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"

――――― [JIS X 7361 pdf 6] ―――――

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

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

  この規格は名前(この場合,Basic Profile)及び版数(ここでは1.1)で識別される。両方を合わせて,
特定のプロファイルインスタンス(profile instance)を識別する。
  版数の番号はメジャー番号及びマイナー番号で構成され,"メジャー番号.マイナー番号" の形式となる。
これらは,プロファイルの優先度を決定するのに利用できる。(メジャー番号及びマイナー番号の両方を考
慮して)版数の番号が大きい場合,そのインスタンスは新しく,それ以前のインスタンスを置き換える。
  同じ名前のプロファイルの複数のインスタンス(例えば,"Example Profile 1.1","Example Profile 5.0")
は,同じ一般的な適用範囲内にある相互運用性の問題に言及している(もっとも,状況の進展によって,
プロファイルの厳密な適用範囲がインスタンスの間で変わることがある。)。

――――― [JIS X 7361 pdf 7] ―――――

                                                                                              5
                                                                X 7361 : 2010 (ISO/IEC 29361 : 2008)
  この情報は,あるプロファイルの二つのインスタンスが後方互換(backwards-compatible)であるかどう
か(すなわち,前のプロファイルインスタンスへの適合が後のプロファイルインスタンスへの適合を暗示
するものと想定できるかどうか。)を判断するために使用できる。同じ名前とメジャー番号とをもつ複数の
プロファイルインスタンス(例えば,"Example Profile 1.0" 及び "Example Profile 1.1")は,互換性がある
と考えてもよい。これは,逆方向への互換性を暗示するものではないことに注意が必要である。すなわち,
後のプロファイルインスタンスへの適合は,前のプロファイルインスタンスへの適合を暗示するものと想
定することはできない。

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

  このプロファイルに対して適合しているということは,このプロファイルの適用範囲 (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記述,

――――― [JIS X 7361 pdf 8] ―――――

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)の形
をとるかもしれない。

――――― [JIS X 7361 pdf 9] ―――――

                                                                                              7
                                                                X 7361 : 2010 (ISO/IEC 29361 : 2008)
  このプロファイルの適用範囲は,附属書Aの引用規格によって定義され,附属書Bの拡張点によって詳
細化される。

2.4 適合性の表示

  このプロファイルに対する適合性の表示は,Conformance Claim Attachment Mechanisms
(http://www.ws-i.org/Profiles/ConformanceClaims-1.0.html,適合性表示添付メカニズム)の記述に従い,次
に示す各メカニズムを使って行うことができる。この場合,各メカニズムが列挙する対象物に関連付けら
れた,このプロファイルの適用可能要件が満足されていることが条件となる。
     ・ Web サービスインスタンスに対するWSDL 1.1 適合性表示添付メカニズム−MESSAGE
         DESCRIPTION INSTANCE RECEIVER
     ・ WSDL記述の構造に対するWSDL 1.1 適合性表示添付メカニズム−DESCRIPTION
     ・ Web サービスインスタンスに対するUDDI適合性表示添付メカニズム−MESSAGE
         DESCRIPTION INSTANCE RECEIVER
     ・ Web サービス登録に対するUDDI適合性表示添付メカニズム−REGDATA
  このプロファイルの適合性表示URIは,"http://ws-i.org/profiles/basic/1.1" である。

3 メッセージ送受信

  このプロファイルのこの箇条では,次の規格を引用し,その中での拡張点を定義する。
    ・ 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)
          拡張点:

――――― [JIS X 7361 pdf 10] ―――――

次のページ PDF 11

JIS X 7361:2010の引用国際規格 ISO 一覧

  • ISO/IEC 29361:2008(IDT)

JIS X 7361:2010の国際規格 ICS 分類一覧

ページ