ws-i basic profile 1.0 の概説 - xml...

Copyright © 2003 Hitachi, Ltd.; NEC Corporation; and Fujitsu Limited. All Rights Reserved. 1

WS-I Basic Profile 1.0 解説

2004年5月18日

藤田悟（NEC）

沼田利典（富士通）


発表の内容

1. Basic Profile 策定の背景

2. Basic Profile 1.0 の章構成

3. 適合性(Conformance)の基準

4. MESSAGE5. DESCRIPTION6. REGDATA7. セキュリティ (HTTPS)8. 今後の計画


WS-I とは

• 正式名称:– Web Services Interoperability Organization

http://www.ws-i.org/

• 活動内容:– プラットフォーム、アプリケーション、プログラム言語に

またがるWebサービスの相互運用性を図ることを目的

としたオープンな業界横断の団体

– 相互運用できるWebサービスを開発するためのガイド

ライン、ベストプラクティス、ツールなどを提供する

• 設立: 2002年2月

• 参加団体: 140社超（2003年8月現在）

• 2003年8月、Basic Profile 1.0a を完成し、公開


WS-I の活動

• プロファイルの策定– Basic Profile (SOAP/WSDL/UDDI の基本仕様)– Attachments Profile (SOAP メッセージへのファイル添

付)– Basic Security Profile (WS-Security の利用方法)

• テストツールの開発

– 個別のプロファイルに対応してテストプログラムを提供

• サンプルアプリケーションの開発– Supply Chain Management をモデルにプロファイルの

利用サンプルを作成し、設計資料とともに公開


1. Basic Profile 策定の背景

• 各ベンダーのWebサービス技術に非互換

性がある。その原因に以下のものがある。– SOAP や WSDL、 UDDI の仕様、及び仕様中に使わ

れている例に曖昧性や誤りがある。

– SOAP や WSDL、 UDDI の仕様に相互に冗長性や矛

盾がある。

– SOAP や WSDL が XML Schema の仕様策定以前に策定されたので、現在の XML Schema に従わない独

自のエンコーディングを利用している。

[Basic Profile の目的]以上の問題を解決し、相互運用できる標準を規定する基本仕様の集合を定めたい。

[Basic Profile の目的]以上の問題を解決し、相互運用できる標準を規定する基本仕様の集合を定めたい。


SOAP 1.1 仕様書の5.4.1 Compound values … の例The following is an example of a struct of type "Book":

<e:Book><author>Henry Ford</author><preface>Prefatory text</preface><intro>This is a book.</intro>

</e:Book>And this is a schema fragment describing the above structure:

<element name="Book"><complexType><element name="author" type="xsd:string"/><element name="preface" type="xsd:string"/><element name="intro" type="xsd:string"/></complexType></e:Book>

author やprefaceの

namespaceは？

</element>の間違い？


WSDL 1.1 仕様書の2.1.2 Authoring Style の例

http://example.com/stockquote/stockquote.xsd<?xml version="1.0"?> <schema targetNamespace="http://example.com/stockquote/schemas"

xmlns="http://www.w3.org/2000/10/XMLSchema">…

http://example.com/stockquote/stockquote.wsdl<?xml version="1.0"?><definitions name="StockQuote"

targetNamespace="http://example.com/stockquote/definitions" xmlns="http://schemas.xmlsoap.org/wsdl/">

<import namespace="http://example.com/stockquote/schemas" location="http://example.com/stockquote/stockquote.xsd"/>

….http://example.com/stockquote/stockquoteservice.wsdl<?xml version="1.0"?><definitions name="StockQuote"

targetNamespace="http://example.com/stockquote/service" xmlns="http://schemas.xmlsoap.org/wsdl/">

<import namespace="http://example.com/stockquote/definitions" location="http://example.com/stockquote/stockquote.wsdl"/>

…

Schema定義ファイルをimportできる？

types の schema の中で import する

こととの違いは？

こちらは、wsdlファイルのimport


Basic Profile の策定方針

• 現在利用されている仕様をもとに規定する（SOAP 1.1、WSDL 1.1 など）

• 既存の仕様を参照し、ここで新しい仕様を規定することはない

• 現在検討中の仕様に方向性を合わせる（SOAP 1.2、WSDL 1.2 などとは矛盾しないように）

• 基本仕様の要件を変更する場合、要件を制限することはあっても緩和することはない


2. Basic Profile 1.0 の章構成

• 1章: 序文• 2章: 適用範囲• 3章: 適合性についての定義• 4章: メッセージング (SOAP)• 5章: サービス記述 (WSDL)• 6章: サービスの公開と発見 (UDDI)• 7章: セキュリティ (HTTPS)


3. 適合性(Conformance)の基準

何に対しての適合性を判断するのか？何に対しての適合性を判断するのか？

• Basic Profile 1.0 は「Webサービスの実装」

に対する適合性を規定

• テストツールで適合性を検証

• 開発ツールやプラットフォームは Basic Profile 1.0 の適用範囲外 (out of scope)

• 将来のプロファイルでは、ツールやプラットフォームの適合性を規定する可能性あり


適合性の対象

• MESSAGE– Web サービスを呼び出すにあたり、ネットワーク上で交換される

プロトコルの構成要素(たとえば、SOAP/HTTP メッセージ)

• DESCRIPTION– Webサービスにアクセスするためのインタフェース情報(データ型、

メッセージなど)と、その具体的なプロトコルバインディング、アクセスポイントを定義する記述 (たとえば、WSDL 記述)

• REGDATA– REGISTRYに登録するWeb サービスについての記述 (たとえば、

UDDI tModel)


Basic Profile 1.0の

参照する仕様

• SOAP 1.1• WSDL 1.1• UDDI 2.0• XML Schema Part 1, 2• XML 1.0• HTTP 1.1• TLS 1.0• SSL 3.0• X.509 Public Key Infrastructure Certificate


適合サービスの提供者と利用者の関係• INSTANCE: デプロイされた Web サービスその

もの (wsdl:port 又は uddi:bindingTemplate で指定されるもの)

• CONSUMER: サービスのインスタンスの利用者

ある一つの形の適合文書を生成

INSTANCEある一つの形の適合回答文書を生成

あらゆる形の適合文書を受信

CONSUMERあらゆる形の適合回答文書を受信

例えば、MESSAGEの文字コードについて、UTF-8とUTF-16が許されるとき、送信側: UTF-8かUTF-16のどちらかのMESSAGEを送信して良い受信側: UTF-8とUTF-16の両方のMESSAGEを受信できなければ

ならない。

例えば、MESSAGEの文字コードについて、UTF-8とUTF-16が許されるとき、送信側: UTF-8かUTF-16のどちらかのMESSAGEを送信して良い受信側: UTF-8とUTF-16の両方のMESSAGEを受信できなければ

ならない。


4. MESSAGE• SOAPの基本フォーマットについての制限/許容

範囲を明確化

<?xml version="1.0"?> <soap:Envelope

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" /><soap:Header>

<wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />

</soap:Header><soap:Body>

<m:GetLastTradePrice xmlns:m="Some-URI"><symbol xsi:type="string">DEF</symbol>

</m:GetLastTradePrice></soap:Body>

</soap:Envelope>

soap:encodingStyle属性をつけてはいけない。

適合性表示をつけても良い。

BOMを

つけても良い。

XML宣言を

つけても良い。

soap:Bodyの

後ろに要素をつけてはいけない

文字コードはUTF-8かUTF-16

mustUnderstand属性の値は0か1soap:Bodyの

要素はQNAME

xsi:type 指定がなくても

解釈できなければいけない

※XML例は、BP1.0の仕様から引用し、それを一部部修正


MESSAGE に対する条件の理由づけ

XML 文書である理由による条件– UTF-8, UTF-16 を受理できなければならない。– UTF-8/16 共に BOM を解釈できなければならない。– XML 宣言 <?xml version=…?> をつけてもよい。

XML Schema を利用することによる条件– soap:encodingStyle を利用してはいけない。

SOAP の仕様解釈による条件– soap:Body の要素は、QNAME でなければならない。– mustUnderstand は、0 か 1。(false, true ではない)

WSDL との組み合わせによる条件– soap:Body の要素には、xsi:type が指定されなくても

解釈できなければならない。


Fault について• faultについては、XML文書構造の問題と、処理(faultがあっ

たら、それ以上処理を進めない等)のモデルについて規定。

• HTTP の状態コードに関わらず、soap:Faultがあるときだけを、Faultの状態と判断する。

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >

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

</soap:Fault>

soap:Faultの子要素は、faultcodefaultstringfaultactordetailだけ

soap:Faultの子要素は、

namespaceで

修飾しない。

detailの中には、

いかなる要素も許される。

faultcodeは、SOAP1.1のfaultcode、あるいは、namespace 修飾された

faultcode が望ましい。

※XML例は、BP1.0の

仕様から引用


qualified と prefixed name の対応

• Qualified name とは、namespace 修飾された名前。Prefixed name を用いるか、default の namespace 宣言との組み合わせによって表現される。

• Prefixed name とは、namespace を指し示す prefixとセミコロンで結合された qualified name の表現

方法。 soap:Body の要素は、qualified

soap:Fault の要素は、unqualified

なし

あり

-

default namespace宣言

○×

×○unprefixed

×○prefixed

unqualifiedqualified


Default namespaceを使っている場合

• 上位のXMLノードで、 default namespace を利用していて、soap:Fault を利用する場合は、default namespace の効果の打ち消しが必要。

<?xml version="1.0"?> <Envelope

xmlns="http://schemas.xmlsoap.org/soap/envelope/" /><Header></Header><Body>

<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> <detail>…</detail>

</soap:Fault></Body>

</Envelope>


SOAP in HTTP• HTTPのバージョン: 1.0か1.1。1.1が望ましい。

• HTTPのPOSTメッセージを利用

• HTTPヘッダのSOAPActionは、引用符(“”)で囲む

• HTTP 状態コード

– 成功時には、2XX• 返信内容がある時は200

• 返信内容がない時は200 (OK)、または202(Accepted)がよい

– リダイレクトは、307(Temporally Redirect)– リクエスト形式に問題があるときは、4XX– サーバのエラーは、5XX


5. DESCRIPTION• WSDL 1.1 に対して仕様を明確化

definitions

types: スキーマによるデータ型・要素の定義

import: WSDLファイルの取り込み

message: 送受信されるメッセージの定義

part: メッセージの構成要素（引数・返却値など）

portType: 抽象的なサービスの定義

operation: オペレーションの抽象的な定義

input: 入力メッセージ（クライアント→サーバー）

fault: フォルトメッセージ（両方向）

output: 出力メッセージ（サーバー→クライアント）


WSDLの構造（続き）

definitionsbinding: portType のサービス定義を具体的なプロトコルにバインド

operation: オペレーションの具体的な定義

input/output/fault: message を指定

soapbind:body: SOAPメッセージのBodyに対応

soapbind:header: SOAPメッセージのHeaderに対応

soapbind:fault: SOAPのフォルトメッセージに対応

soapbind:headerfault: SOAPヘッダーのフォルトメッセージに対応

soapbind:binding: SOAPの下位層プロトコルへのバインド

service: サービスのインスタンスを定義

port: binding を指定

soapbind:address: サービスを提供するURL


documentation 要素の扱い

• WSDL 1.1の本文・スキーマで食い違いが

ある– スキーマでは WSDL 仕様で定義された全て

の要素の最初の子要素

– 本文 2.1 WSDL Document Structure ではdefinitions 要素については import 要素の次、import 要素には存在しない

– 本文 2.1.4 Documentation では要素名がdocument

• スキーマの解釈を採用する


types 要素の扱い

• types 要素の位置が本文・例・スキーマで

食い違う– 本文 2.1 WSDL Document Structure では

import 要素の次、その他全ての要素の前

– 本文 3.1 SOAP Examples の例 Example 3 では最後の要素になっている

– スキーマでは位置に制限なし

• 本文 2.1 の解釈を採用する


import 要素の扱い

• WSDL 1.1 には import 要素があり、別WSDL ファイルを取り込める

• XML Schema 1.0 にも import 要素がある

• WSDL 1.1 本文 2.1.2 Authoring Style にある例ではスキーマを WSDL の import 要素で取り込んでいる →間違い！

• WSDL の import 要素では WSDL ファイルのみ取り込み、XML Schema の import 要素はスキーマのみ取り込む


メッセージのスタイル

• 2種類のスタイルが存在

• RPC スタイル (style="rpc")– メソッドに引数を渡して呼び出し、返却値を受

け取る方式

• ドキュメントスタイル (style="document")– XML 文書（伝票など）をやり取りする方式

• Basic Profile では両方の方式を許す


RPCスタイルの扱い

• types要素で使用するデータ型を定義

• message 要素では個別の part が引数・返却値を

示す– soap:Body を構成する part は0個以上の任意個数

– part は、type 属性でデータ型を参照する（本文 3.1 SOAP Examples の例 Example 4 で element 属性を

使っているのは間違い）

• soap:Body の子要素（ラッパー要素）名は:– input はオペレーション名

– output はオペレーション名 + “Response” （本文 3.5 soap:body の記述では「オペレーション名と同一」とい

う解釈も可能）


ドキュメントスタイルの扱い

• types 要素で使用する要素の構造をグロー

バル要素宣言で定義

• message 要素では part は交換する文書を

示す– soap:Body を構成する part は0個又は1個

– part は、element 属性でグローバル要素宣言

を参照する

• soap:Body の子要素名はグローバル要素

宣言で示される要素の名前


引数の順序

• RPCの場合、SOAP メッセージ上での引数

の順序をどこで指定するか– message 要素内での part 要素の順序?– portType 要素内の operation 要素に指定され

た parameterOrder 属性の値の順序?– binding 要素内の soapbind:body 要素に指定

された parts 属性の値の順序?• message 要素内での part 要素の順序を引

数の順序とする


portTypeについての規定

• operation のメッセージ交換パターン:– Request-Response (input-output の順)– One-Way (input のみ)– Solicit-Response (output-input の順)– Notification (output のみ)→Request-Response 及び One-Way のみ有効（それ以

外のメッセージ交換パターンは規定が不十分なため）

• 同一 portType 内で同じ名前の operation は禁止

する（オペレーション名のオーバーロード禁止）


メッセージでのデータ型指定

• 2種類の方式が存在

• literal 方式 (use="literal")– WSDL の中にあるスキーマでメッセージの構

造を指定する（SOAP メッセージ上にはデータ

型情報は含まれない）

• encoded 方式 (use="encoded")– SOAP メッセージにデータ型情報を付加して送

る (SOAP Encoding を使用)• Basic Profile では、XML Schema 対応のた

め literal 方式だけを採用


style/use の組み合わせ

• 次の組み合わせが有効

style use literal encoded

document ○ ×

rpc ○ ×


ヘッダーについての規定

• soapbind:header で記述する

• soapbind:header で記述されたヘッダーブ

ロックは省略不可

• soapbind:header で記述されないヘッダーブ

ロックがメッセージに現れてもよい

• ヘッダーブロックの順序・個数は任意でよい

• soapbind:headerfault で記述されないヘッ

ダーフォルトが発生してもよい


6. REGDATA• UDDI 2.0 とは

– Web サービスの登録・検索を行うためのレジストリー仕様

– 必要な Web サービスを探し出すための「電話帳」の役割を果たす

– Web サービスの技術仕様や URL を登録可能

• UDDI と WSDL との間には機能的に類似・重複する部分があるので、組み合わせる場合には両者のすり合わせが必要


bindingTemplate の要件

• UDDI の bindingTemplate は WSDL のport に相当する

• bindingTemplate では accessPoint 要素でアドレスを指定すること（hostingRedirectorは WSDL と不整合なので使用不可）

<uddi:bindingTemplate bindKey="…">

<uddi:accessPoint>http://example.com/myService</uddi:accessPoint>

<uddi:tModelInstanceDetails>…</uddi:tModelInstanceDetails>

</uddi:bindingTemplate>


tModel の要件

• tModel (Technical Model の略) は Web サービスの「技術仕様」を記述する

• UDDI と WSDL の組み合わせ方を説明したUsing WSDL in a UDDI Registry 1.08 版(UDDI Best Practice 文書) の記述に従うこ

と

• UDDI の tModel の記述と WSDL のwsdl:binding の記述とが矛盾しないこと


7. セキュリティ (HTTPS)• HTTPS (SSL 3.0/TLS 1.0) を必須とする

サービスを提供することが可能

• HTTPS の次の認証機能を使用可能– サーバー認証

– サーバー認証及びクライアント認証を使用した相互認証

• サービスを提供する URL は次のいずれかであること:– HTTPS を使う場合 "https" スキーム

– HTTPS を使わない場合 "http" スキーム


8. 今後の計画- Attachments Profile 1.0 -

• W3C Noteである “SOAP Messages with Attachments” (2000年12月11日) を取り込んだ Attachments Profile 1.0 を策定中。

• 同時に、Attachments Profile と組み合せやすくなるよう、Basic Profile を改訂中 (Basic Profile 1.1)。

• Basic Profile 1.1 と組み合わせて利用することを想定。


- Basic Security Profile -

• XMLレイヤのセキュリティに関する Profileを規定する。

• Basic Profile に対する拡張プロファイルと

して規定。

• Basic Profile とは別のWG (Basic Security Profile WG) で策定中。(2003/05～)

• OASISで策定中の WS-Security を取り込

む。

ws-i basic profile 1.0 の概説 - xml...

Documents