WS-I の最新動向 - XML Consortiumxmlconsortium.org/seminar/m25/data/20040315-04.pdf · httpのpostメッセージを利用 httpヘッダのsoapactionは、引用符(“”)で囲む

Copyright © 2004 Fujitsu Limited; Hitachi, Ltd.; NEC Corporation; Oracle Corporation Japan; Beacon Information Technology Inc.; Nomura Research Institute, Ltd.; SAP Japan; and Ricoh Co., Ltd. All Rights Reserved. 1

WS-I の最新動向

2004年3月15日

成田雅彦 (富士通)沼田利典 (富士通)

戸田隆一郎 (野村総合研究所)

2

Copyright © 2004 Fujitsu Limited; Hitachi, Ltd.; NEC Corporation; Oracle Corporation Japan; Beacon Information Technology Inc.; Nomura Research Institute, Ltd.; SAP Japan; and Ricoh Co., Ltd. All Rights Reserved.

目次

1. WS-I とは1.1 WS-I の目的

1.2 WS-I のめざす相互運用性

1.3 WS-I の主な活動と成果物

2. Basic Profile 1.0 の概要2.1 SOAP (MESSAGE)2.2 WSDL (DESCRIPTION)2.3 UDDI (REGISTRY)2.4 セキュリティ

3. Basic Profile 1.1 に向けて

4. Testing Tools の概要

3


目次

5. サンプルアプリケーション

6. まとめ

4


1. WS-I とは

正式名称: Web Services Interoperability Organizationhttp://www.ws-i.org/

活動内容:プラットフォーム、アプリケーション、プログラム言語にまたがるWebサービスの相互運用性の促進を図ることを目標にしたオープンな業界横断の団体

相互運用できるWebサービスを開発するためのガイドライン、ベストプラクティス、ツールなどを提供する

設立: 2002年2月

参加団体: 140社超 (2003年8月現在)

5


1.1 WS-Iの目的

Webサービスの相互運用性の達成プラットフォームやアプリケーションを超えて

共通で明確なWebサービスの定義づけ

関連する標準化団体の仕様を統合

Webサービスの採用の促進顧客、企業、エンドユーザが集まって

産業界のコンセンサスを形成

情報交換できるフォーラムの形成

Webサービスの普及を加速実装ガイドラインとベストプラクティスの提供

ツールとサンプルアプリケーションの提供※WS-I 概説より抜粋

6


相互運用性が問題となる状況 (1)

Webサービスのクライアント側とサーバ側で異なるプラッ

トフォームを利用した場合、接続できない可能性がある。

仕様のサポート範囲や

解釈が微妙に異なる

サーバ側は、プラットフォーム(B)を利用

クライアント側は、プラットフォーム(A)を利用

Webサービスの期待を裏切ることに...

7


相互運用性が問題となる状況 (2)

公共サービスシステムは、動的に様々なシステムと接続する必要があるが、事前に接続確認を行っていないプラットフォームを利用している場合、接続できない可能性がある。

公共システム事前に接続を

確認していない

事前に接続を確認済み



Webサービスの特徴である動的な接続が保証できない

8


1.2 WS-I のめざす相互運用性

WS-I Basic Profile を定めて、プラットフォームの機能範囲を規定して、Webサービスの相互運用性を高める。

WS-I テストツールによってWebサービスのWS-I準拠を検証する。

プラットフォーム製品でも、WS-I互換の機能をサポート。

サーバ側のプラットフォーム(B)

ユーザ側のプラットフォーム(A)

WS-I準拠のWebサービスの相互運用性を保証できる。

9


相互運用性を高めるアプローチ

各プラットフォーム毎に、SOAP、UDDI、WSDLのサポート範囲が異なるので、共通部分をWS-I Basic Profile として定義。

サポート範囲

アプリケーション

プラットフォームA

クライアントシステム


プラットフォームB

サーバシステム

WS-IBP

ﾌﾟﾗｯﾄﾌｫｰﾑB

ﾌﾟﾗｯﾄﾌｫｰﾑA

WS-I Basic Profileで定義されたサポート範囲の機能を使用して、 WS-I準拠のWebサービス（アプリケーション）を作ることができる。

サポート範囲


プラットフォームB

サーバシステム

WS-IBP

ｱﾌﾟﾘ

ﾌﾟﾗｯﾄﾌｫｰﾑB


プラットフォームA

クライアントシステム

10


1.3 WS-I の主な活動と成果物

Basic ProfileSOAP 1.1, WSDL 1.1, UDDI 2.0 を中心に相互運用できる指針を規定し、Basic Profile 1.0 として2003年8月に正式決定し公開

2003年12月には、SOAP Messages with Attachments の使用指針を規定した Attachments Profile 1.0のドラフト仕様を公開

Testing ToolsBasic Profile に沿ったサービスであるかどうかを検証するテストツールのドラフト版を無料で公開(Java版、C#版)

Sample ApplicationsSCMをテーマに、Webサービスのサンプルコードを提供

Basic Security Profileセキュリティ要件を検討したSecurity Scenariosを作成し、それを元にWS-Security を中心に相互運用性のための仕様を策定中

Requirements相互運用性に対する要求を収集

GlossaryWebサービスの用語集の作成

11


WS-I Japan SIG の活動

日本におけるWS-Iの活動を推進するために結成

技術検証活動WS-I Basic Profileなど, WS-Iで開発される技術資料の翻訳

Testing ツールの日本語環境での検証と問題のフィードバック

マーケティング活動Webサービス相互運用性に関する広報宣伝活動

Webサービス相互運用性に関する講演活動(セミナー, イベント)

その他の活動国内関連団体との連携 (XMLコンソーシアム, DOPGなど)

参加メンバ (15社: Japan SIG 発足時)

12


2. Basic Profile 1.0 の概要

Basic Profile の解決する課題SOAP や WSDL, UDDI の仕様、及び仕様中に使われている例に曖昧性や誤りがある。

SOAP や WSDL, UDDI の仕様に相互に冗長性や矛盾がある。

SOAP や WSDL が XML Schema の仕様策定以前に策定されたので、現在の XML Schema に従わない独自のエンコーディングを利用している。

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

13


Basic Profile 1.0の参照する仕様

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

14


適合性(Conformance)の基準

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

Basic Profile 1.0 は「Webサービスの実装」に対する適合性を規定

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

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

15


適合性の対象

適合性の対象MESSAGE

Web サービスを呼び出すメッセージの構成要素(たとえば，SOAP)

DESCRIPTIONWebサービスのインタフェースを定義する記述 (たとえば，WSDL 記述)

REGDATAREGISTRYに登録するWeb サービスについての記述 (たとえば，UDDI tModel)

セキュリティメッセージ経路のセキュリティ(たとえば, HTTPS)

Basic Profile の中では、総数161個の要件を定義必須(MUST/MUST NOT)、推奨 (SHOULD/SHOULD NOT)、許容 (MAY)に分類

必須推奨許容計

§3. プロファイルへの適合性 9 0 3 12§4. メッセージング (SOAP) 32 12 4 48§5. サービスの記述 (WSDL) 66 8 19 93§6. サービスの公開と発見 (UDDI) 5 0 0 5§7. セキュリティ (HTTPS) 1 0 2 3

合計 113 20 28 161

16


2.1 SOAP (MESSAGE)SOAPの基本フォーマットについての制限/許容範囲を明確化文字コードは

UTF-8かUTF-16

<?xml version="1.0"?> <soap:Envelopexmlns: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の

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

mustUnderstand属性の値は0か1の

QNAME

xsi:type 指定がなくても

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

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

soap:Body要素は

17


SOAP in HTTP

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

HTTPのPOSTメッセージを利用

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

HTTP 状態コード

成功時には、2XX返信内容がある時は200返信内容がない時は200または202

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

18


2.2 WSDL (DESCRIPTION)

WSDL 1.1 に対して仕様を明確化definitions

types: XML Schema によるデータ型定義

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

portType: 複数の message をまとめた論理操作を定義

binding: 論理操作をプロトコル上のメッセージにバインド

service: サービスのアクセスポイントの物理的な位置

port: binding と address の組み合わせでアクセスポイントを指定

19


WSDLに対する要求の概要

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" …targetNamespace="http://example.org/bar/"xmlns:foo="http://example.org/foo/"> <document> … </document><import namespace="http://example.com/stockquote/base"

location="http://example.com/stockquote/stockquote.wsdl"/> <types>

<xsd:schema targetNamespace="http://example.org/foo/" …> <xsd:import … /> …

</xsd:schema></types><message name="BarMsg">

<part name="BarAccessor" type="foo:fooType"/></message> <portType name="BarPortType">

<operation name="BarOperation"> <input message="bar:BarMsg"/> </operation> </portType> <binding name="BarSOAPBinding" type="bar:BarPortType">

<soapbind:binding transport="http://schemas.xmlsoap.org/soap/http/"style="rpc"/>

<operation name="BarOperation"><input message="bar:BarMsg"> <soapbind:body use="literal"/> </input>

</operation></binding><service name="serviceName">

<port name="BarSOAPPort" binding="bar:BarSOAPBinding"> <soapbind:address location="http://example.org/myBarSOAPPort"/>

</port> </service> </definitions>

document, import,

typesの順番

wsdl:importはlocationが必須

つけてよい targetNamespaceと一致

XML Schemaをimportする時は、xsd:schemaの中で

xsd:importを使用

xsd:schemaには、targetNamespaceが必須

は type属性は

属性を使用operation nameの

オーバーロードは禁止

は、soapbindに限定

use属性の指定がない場合、

literalと解釈

のlocationportを持つ

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

BOMを UTF-8又はUTF-16

wsdl文書をimport。namespace は、元wsdlの

soapbind:bodyで利用する場合は、

rpc-literaldocument-literalelement

biding

addressが同じ

べきではない

20


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

2種類の方式が存在

literal 方式 (use="literal")WSDL の中の types 要素で定義する XML Schemaで、メッセージ内のデータ構造を指定する

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

Basic Profile では literal 方式だけを採用

21


配列の問題

DESCRIPTION 中の array 宣言は、soapenc:Array 型の拡張

であってはいけない。

DESCRIPTION 中の array 宣言は、その型宣言にwsdl:arrayType 属性を使用してはいけない。

DESCRIPTION 中では、array 宣言に対する要素名に、ArrayOfXXX という名前付けをすべきではない。

MESSAGE は、soapenc:arrayType 属性を持ってはいけない。

<xsd:element name="MyArray1" type="tns:MyArray1Type"/> <xsd:complexType name="MyArray1Type"> <xsd:sequence>

<xsd:element name="x" type="xsd:string"minOccurs="0"

maxOccurs="unbounded"/> </xsd:sequence>

</xsd:complexType>

WSDL例<MyArray1>

<x>abcd</x>

<x>efgh</x> </MyArray1>

SOAP例

22


2.3 UDDI (REGDATA)

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

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>

23


2.4 セキュリティ (HTTPS)

HTTPS (SSL 3.0/TLS 1.0) を必須とするサービスを提供することが可能

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

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

サービスを提供する URL は次のいずれかであること:

HTTPS を使う場合 "https" スキーム

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

24


3. Basic Profile 1.1 に向けて

SOAP with Attachments の仕様に対する相互運用性の基準を策定中

2003年12月にドラフト版を一般公開Basic Profile の文書体系を変更

Basic Profile1.0

BP1.0 の体系

AttachmentsProfile

1.0

Basic Profile1.1

Simple SOAP Binding

Profile 1.0

BP1.1 の体系

ProfileConformanceFramework

同等

25


Attachments Profile 1.0

Attachments つきメッセージMIME multipart/related の root part は、SOAP Envelope でなければならない

root part でない部分は、どのようなエンコーディングでもよい

もし、attachments がないメッセージの場合は、直接text/xml で送っても、multipart/related で送ってもよい

MIME BindingWSDL の binding に、MIME Binding を指定しない場合は、Attachments つき SOAP メッセージを送付してはいけない

26


Security Scenarios

Basic Security Profileの利用シナリオ

通信相手の識別と認証

データ作成元の識別と認証

データの完全性伝送路での完全性

SOAPメッセージの完全性

データの機密性伝送路での機密性

SOAPメッセージの機密性

メッセージの一意性

27


4. Testing Tools の概要

「Testing Tools and Material」ワーキンググループでは、テストツールと補足ドキュメントを作成している。

WebサービスがWS-I Basic Profileのinteroperability guidelineに適合しているかどうかを検査するツール。

モニターツール（Monitor）が、Webサービスから/へのメッセージを収集してログファイルを出力する。

解析ツール（Analyzer）が、Monitorが収集したメッセージを解析し、WS-Iのプロファイルとの互換性のために、Webサービスのdescriptionとregistration artifactsを評価して適合分析結果を出す。

現在、V1.0.1 を公開中

テストツール（Monitor/Analyzer）はC#(.NET)版とJava版の両方が提供される。

28


Testing Toolの構成（１）

Port番号で切替

Testing Tools V1.0 User Guideより抜粋

29


Testing Toolの構成（２）

Testing Tools V1.0 User Guideより抜粋

30


Analyzer レポート構造

ConformanceReport

ConfigurationEnvironment

Artifact Assertion results

Summaries

Discovery Description Message

ResultAll

ResultArtifact

type

ResultAssertion

Result per target

Result per target

Result per target

ResultAll

ResultArtifact

typeWSDL MessageUDDI

31


ツールのデモ

サーバクライアント SOAPメッセージ

ab+‘日本語’+cd‘日本語’

‘ab日本語cd’

log.xml

Monitor

WS-I Testing Tools – 1.0.1http://www.ws-i.org/implementation.aspx

Java 2 SE Ver.1.4.2_03、Axis Release 1.1、Apache Tomcat 5.0.19

デモ中は、ローカルに持つ日本語Basic Profileを使用

Analyzer report.xml

32


テスティングツールの検証範囲

アプリケーション単位でWS-I準拠の検証を行うので、その機能範囲で相互運用性が保証される。

プラットフォーム製品WS-I BP準拠機能

アプリケーション(A)

アプリAの検証範囲

アプリケーション(B)

アプリBの検証範囲

WS-I Basic Profileの規定範囲

33


5. サンプルアプリケーション

現在公開中の資料

利用シナリオ (WS-I Usage Scenarios)SCMユースケース (Supply Chain Management Use Cases)SCMサンプルアーキテクチャ (Supply Chain Management Sample Architecture)

サンプルアプリケーション実装

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

34


利用シナリオ

３種類の基本シナリオ

One-way (一方向)レスポンスなしの一方向通信

Synchronous request/response (同期リクエスト/レスポンス)

同期型メッセージ交換

Basic Callback (基本コールバック)非同期型メッセージ交換

35


SCMユースケース対象となるSCMシステム

小売店が消費者に電気製品を販売するB2Cモデル

SCMシステムの高レベルなユースケースを提供UC1: Purchase Goods (商品の購入)UC2: Source Goods (商品の調達)UC3: Replenish Stock (在庫の補給)UC4: Supply Finished Goods (完成品の供給)UC5: Manufacture Finished Goods (完成品の製造)UC6: Configure and Run Demo (設定とデモの実行)UC7: Log Events (イベントの記録)UC8: View Events (イベントの表示)

36


SCMアーキテクチャ

小売店システムアーキテクチャ (Retailer System Architecture)生産システムアーキテクチャ(Manufacturing System Architecture)デモシステムアーキテクチャ (Demo System Architecture)基本となるサンプルアプリケーションの設計指針

37


サンプルアプリケーションの構成

38


6. まとめ

基本プロトコルは標準化から実用化の時期へSOAP, WSDL, UDDI, XML SchemaWS-Iが利用のガイドライン（プロファイル）を規定

拡張プロトコルの標準化の時期へWS-Security, WS-Reliability, …標準化団体でのオープンな議論

ロイヤリティーフリー下での標準仕様の利用

順次WS-Iに盛り込まれる

WS-Iは標準仕様をプロファイル化する

Documents

WS-I の最新動向 - XML Consortiumxmlconsortium.org/seminar/m25/data/20040315-04.pdf · httpのpostメッセージを利用 httpヘッダのsoapactionは、引用符(“”)で囲む