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

この規格ページの目次

4.8 XML Schemaの使用
5 サービスの公開及び発見
5.1 bindingTemplate
5.2 tModel
6 セキュリティ
JIS X 7361:2010の引用国際規格 ISO 一覧
JIS X 7361:2010の国際規格 ICS 分類一覧

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

――――― [JIS X 7361 pdf 46] ―――――

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

――――― [JIS X 7361 pdf 47] ―――――

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

5 サービスの公開及び発見

  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/uddiv2.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では表現で

――――― [JIS X 7361 pdf 48] ―――――

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サービスの記述

――――― [JIS X 7361 pdf 49] ―――――

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

6 セキュリティ

  ネットワーク指向のすべての情報技術にいえることだが,セキュリティの問題はWebサービスにおいて
も重大である。Webサービスでは,セキュリティは,他の情報技術と同様,攻撃者がとり得る潜在的な脅
威を理解することと,攻撃が成功するリスクを許容可能なレベルまで下げるために,作業的,物理的及び

――――― [JIS X 7361 pdf 50] ―――――

次のページ PDF 51

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

ISO/IEC 29361:2008(IDT)

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

35 : 情報技術.事務機械　>　35.100 : 開放型システム間相互接続(OSI)　>　35.100.05 : マルチレイヤアプリケーション