Web...

1

04.04. WebWebサービス・アプリケーション開発設計サービス・アプリケーション開発設計

2006/11 SOA 2006/11 SOA ““WebWebサービス及びサービス及びESBESB””基盤構築基盤構築WorkshopWorkshop

WebWebサービス・アプリケーション開発設計サービス・アプリケーション開発設計

ISE. WebISE. Webインフラストラクチャーインフラストラクチャー高浜高浜めぐみめぐみ清水清水八恵八恵Copyright IBM Japan Co.,Ltd 2006

2



Disclaimer

� 当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含みます。� この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エムシステムズ・エンジニアリング株式会社の正式なレビューを受けておりません。� 当資料は、資料内で説明されている製品の仕様を保証するものではありません。� 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2006年11月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意下さい。� 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。

3



目次

� WS-I

� Webサービス・プロバイダー開発

� 開発方法� サービス定義

� WSDLの構造� JAX-RPCのデータ・マッピング� SOAPメッセージ・モデル� データ・マッピングに関するHint & Tips

� Webサービス・リクエスター開発

�例外処理

�バージョニング

� （補足資料）XMLテクノロジー

4



Webサービス開発設計ポイント

相互運用性相互運用性開発生産性を上げるポイント開発生産性を上げるポイント WS-I

WS-I BasicProfile

WS-I テスト・ツールサービス開発方法サービス定義（WSDL）JAX-RPCのデータ・マッピングリクエスター開発例外処理基本基本

バージョニングサービスの変更管理サービスの変更管理このセッションでは、Webサービスを開発・設計する上で重要となるポイントを説明します。Webサービス開発の基本的な開発方法、WSDLの中身を理解することはもちろん重要ですが実際の開発を実施する上ではそれ以外の箇所でつまずいてしまうことが多々あります。このセッションでは開発生産性が高いと言われるWebサービスで、つまづいてしまわないようにポイントを押さえていきます。また、相互運用性を取り上げられることも多いですが、ただ開発するだけでな相互運用性は保たれません。開発全般に渡って相互運用性を考慮していく必要があります。Webサービスの変更が発生した場合に、どのようにすれば効率よくバージョン管理を行えるか、また変更が必要なのかどうかサービスの変更管理についても触れていきます。

5



WS-I

Webサービスの相互運用性を考慮する上で欠かせないWS-Iについて説明します。

6



WS-Iとは

� WS-I (Web Services Interoperability Organization)

� Webサービスの相互運用性（インターオペラビリティ）を推進するための団体� 2002年2月発足� URL ・・・ http://www.ws-i.org/

� 活動目的� Webサービスの相互運用性向上� Webサービスの普及

� 活動内容� 各種Profileの作成� WS-I適合テスト・ツールの作成� ユースケースの必要事項と利用シナリオの作成� マルチベンダー・サンプルアプリケーションの作成

WS-Iは、異なるプラットフォーム、OS、ミドルウェア、プログラミング言語、およびツールに跨るWebサービスの相互運用性を推進するために設立されたオープンな業界の団体です。この団体には、以下のようなWebサービスを推進しているメジャーな企業が参加しており、ここで決められた事項は業界標準と言うことができます。

IBM、Microsoft、BEA、HP、SUN、Oracle、SAP、インテル、富士通、その他140社以上が参加SOAPやWSDLを使用したWebサービスは相互運用性が高いと言われてきましたが、実際には製品間での相互運用性を実現するにはWebサービス開発者による試行錯誤が必要で簡単には実現できませんでした。例えば、Apache SOAPとMSの.NETを接続させるにはこの分野に高度なスキルを持つ人が作成しないと簡単にはWebサービスで接続することができませんでした。WS-Iはこうした状況を改善するために作られた組織であり、Webサービスの現実的な相互運用性を実現するために様々な活動をしています。WS-Iは実際の活動をするにあたって、Webサービス関連の各種標準を策定しているW3CやOASISと連携しながら活動しています。それ以外の団体とも協調しながら業界の標準となるものを作成しています。WS-Iの活動のメインは、Profileと呼ばれるインターオペラビリティに関するガイドを作成することです。それ以外にも上記のようなサンプルや相互運用性をテストするツールを作成しています。

7



Profile

� 『Profile』の考え方� Webサービス仕様による実装のガイドライン

� 相互運用性の実現に必要な仕様を選択し組み合わせて、矛盾、曖昧性が無いようにガイドラインを提供する。� "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD

NOT", "RECOMMENDED", "MAY", and "OPTIONAL"

� WS-I Basic Profile 1.1

� WS-I Simple SOAP Binding Profile 1.0 (WS-I SSBP)

� WS-I Atachment Profile 1.0 (WS-I AP)

� WS-I Basic Security Profile 1.0 (WS-I BSP)

WS-*仕様には曖昧な言い回しが多いWS-*仕様には曖昧な言い回しが多い

Profileとは、相互運用性の実現に必要な仕様を選択し組み合わせて、矛盾、曖昧性が無いようにガイドしたものです。WS-Iでは、新しく仕様を作成することはありません。あくまでも既に存在する複数の標準規格を用いて相互運用性を保つにはどのようにしたらよいかをProfileとして文書化して公開しています。ユースケースや使用法のシナリオ要求を満たすためには、仕様や標準では「MUST」や「MUST NOT」と記述されるべきですが、「MAY」や「SHOULD」とされている記述（相互運用性の問題を起しがち）について、ガイドラインは言及しています。

8



WS-I Basic Profile

� WS-I Basic Profile 1.1

� Webサービスの基本仕様に関するProfile� 相互接続性相互接続性相互接続性相互接続性をををを向上向上向上向上するためにするためにするためにするために各仕様各仕様各仕様各仕様のののの明確化明確化明確化明確化とととと修正修正修正修正をををを進進進進めためためためた規定規定規定規定� 基本仕様は厳密でなく、解釈により各製品での実装が異なる

� 2004年8月正式公開� WS-I Basic Profile1.1ではメッセージ部分をSimpleSOAPBindingProfileとして切り出して規定

� Basic Profile V1.1 + Simple SOAP Binding Profile V1.0= Basic Profile V1.0 + errata

� 対象となる仕様SOAP v1.1

WSDL v1.1

UDDI v2.0

XML v1.0

XML Schema Part1、XML Schema Part2

RFC2246:The Transport Layer Security(TLS) Protocol v1.0

RFC2459:Internet X.509 Public Key Infrastructure Certificate and CRL Profile

RFC2616:Hyper Text Transfer Protocol v1.1

RFC2818:HTTP over TLS

RFC2965:HTTP State Management Mechanism

SSLProtocol v3.0

SOAP v1.1

WSDL v1.1

UDDI v2.0

XML v1.0

XML Schema Part1、XML Schema Part2

RFC2246:The Transport Layer Security(TLS) Protocol v1.0

RFC2459:Internet X.509 Public Key Infrastructure Certificate and CRL Profile

RFC2616:Hyper Text Transfer Protocol v1.1

RFC2818:HTTP over TLS

RFC2965:HTTP State Management Mechanism

SSLProtocol v3.0

WS-I Basic Profileは，Webサービスにおける基盤技術であるXML，XML Schema，SOAP，WSDL，UDDIの相互接続性を向上するために各仕様の明確化と修正を進めた規定です。http://www.ws-i.org/Profiles/BasicProfile-1.1.htmlこれらのWebサービスにおける基盤技術の仕様は厳密に決定されておらず，仕様の解釈により各製品での実装が異なるため，相互接続ができない，Webサービスのランタイム( WAS，Apache Axis，WebLogic，.NETなど )によって，WSDL，SOAPを解釈できないなどの弊害が起きていました。そこで，各仕様の曖昧さをなくし，各製品の実装差をなくすため，WS-I Basic Profileが制定されました。しかし，WS-I BasicProfileが相互接続性の向上を目指しているといっても，現在のところその仕様は完全でありません。WS-I Basic Profile 1.0からWS-I Basic Profile 1.1での変更点は、WS-I Basic Profile 1.0のメッセージに関する部分をSimpleSOAPBindingProfileとして切り出して別のProfileで規定しています。

9



WS-I Basic Profile v1.1ハイライト

� エンコーディングはdocument/literalかrpc/literal

� プロトコルバインディングはSOAP/HTTP(HTTPS)

� SOAP Faultのレスポンスを受け取ったらHTTP 500を返す。� リクエスはHTTP POSTを使用する� WSDL1.1を使用する実行環境とアプリケーションの双方がWS-Iに準拠する必要がある

WS-I Basic Profieのハイライトを示します。WS-I Basic ProfieではWebサービスのアプリケーションだけでなく実行環境についての動作も規定されています。実行環境とアプリケーションの双方がWS-Iに準拠する必要があります。WASではv5.0/5.1でWS-I BP V1.0に、v6.0/6.1でWS-I BP V1.1に準拠した実行環境となっています。

10



WS-I tools

� WS-I Testing Tools

� WS-I Basic Profileに準拠しているかチェックするツール� テストツールは、Java版とC#版が提供されている。機能や仕組みは同じ� 代替としてRADv6とAST6.1にも同様の機能を搭載

� RationalApplicationDeveloperv6.0

� WebSphere ApplicationServerToolkit 6.1

WS-IではWebサービスで交換されるメッセージがWS-I BPに準拠しているかどうかをチェックするためのテスト・ツールが提供されています。Webサービス間のインタラクションをモニターし分析します。同じ機能や仕組みを持った、Java版とC#版が提供されています。WS-Iで提供されているテスト・ツールの代替として、RAD、WID、ASTにも同様のチェック機能が搭載されており使用することができます。次ページから設定について説明します。

11



RAD v6によるWS-I準拠チェック機能

� 準拠レベルの設定

・WS-I Basic Profile v1.1.2・WS-I Simple Soap Binding Profile v1.0.3・WS-I Attachment Profile v1.0

・WS-I Basic Profile v1.1.2・WS-I Simple Soap Binding Profile v1.0.3・WS-I Attachment Profile v1.0

必要：非準拠Webサービス生成を許可しない準拠：非準拠Webサービスに対し警告を生成無視：警告も行わない必要：非準拠Webサービス生成を許可しない準拠：非準拠Webサービスに対し警告を生成無視：警告も行わない

準拠のレベルはワークスペース、またはプロジェクト・レベルで設定できます。Webサービス・ウィザード、ランタイム環境、WSDLエディター、および提供されているその他のWebサービス・ツールは、WS-Iに準拠するサービスの開発をサポートしています。WS-I SimpleSoapBindingProfile(WS-I SSBP)とWS-I AttachmentProfile(WS-I AP)について、準拠レベルを設定することが可能です。デフォルトではWS-I SSBP非準拠のWebサービス・オプションが選択された場合に警告が出され、WS-I

AP非準拠の選択は無視されます。ワークスペース・レベルでの設定は、RADのツール・バーより「ウィンドゥ」＞「設定」をクリックして、「設定」画面を表示します。画面左側のツリーより「Webサービス」＞「WS-I 準拠」と展開し「WS-I準拠」画面を表示します。各WS-Iプロファイルの準拠レベルの設定を行うことができます。準拠レベルは以下のようになります。・必要：非準拠の要素がある場合、Webサービスを生成しません。ツールを使用したWSDLやスケルトンの生成時にエラーが発生します。・準拠：非準拠の要素がある場合、ツール上で警告を生成します。RADの「問題」タブ上でWS-I警告メッセージが表示されることになります。・無視：非準拠の要素があっても、何も示しません。警告メッセージを表示させたくない場合に設定します。プロジェクト・レベルでの設定は、プロジェクトを選択し右クリック＞「プロパティ」を選択し、プロパティ画面を表示します。画面左側のツリーから「WS-I準拠」を選択して、ワークスペース・レベルと同様の設定が可能です。

12



AST v6.1におけるWS-I準拠チェック機能

�準拠レベルの設定

・WS-I Basic Security Profile・WS-I Basic Profile v1.1・Simple Soap Binding Profile v1.0・WS-I Attachment Profile v1.0

・WS-I Basic Security Profile・WS-I Basic Profile v1.1・Simple Soap Binding Profile v1.0・WS-I Attachment Profile v1.0

AST V6.1はWAS V6.1用のアプリケーション開発・テスト・デプロイを支援するツールになります。WAS

V6.1では新たにWS-I Basic Security Profile(WS-I BSP)をサポートするようになりましたので、AST V6.1ではWS-I BSPの準拠チェック機能が搭載されています。準拠レベル設定方法はRADと同様になります。「設定」画面のツリーから「Webサービス」＞「WS-I BSP 準拠」を選択してWS-I BSPの準拠レベルを設定可能です。

13



WSDLファイルのWS-I準拠チェック機能

� WSDL ファイルの妥当性検査� WSDL V1.1とWS-I BP仕様に基づいて検査を実施� WS-I 準拠レベルの設定に応じてWS-I検査は実施

� 「WS-I準拠を無視」の場合は、WSDLの妥当性のみ検査されるWS-I違反イベントを問題ビューでの警告表示WS-I違反イベントを問題ビューでの警告表示

ツールを使用してWSDLファイルを作成した場合、生成したWSDLファイルは有効ですが、WSDLファイルをインポートした場合や、独自に作成したWSDLファイルの場合は、WSDLファイルを検証して有効であるか確認する必要があります。「プロジェクト・エクスプローラー」ビューでWSDLファイルを選択し右クリック＞「WSDLファイルの妥当性検査」を選択すると検査が開始し、ポップアップ画面で検査結果が表示されます。「WS-I 準拠」の設定ページで「WS-I準拠が必須」または「WS-I準拠を推奨」を選択した場合、その検証でWS-I準拠についても検査されます。「WS-I準拠を無視」を選択していると、バリデーターではWSDLの妥当性のみが検査されることになります。WSDLバリデーターでは、プロジェクト内のWSDLをWSDL1.1仕様及び、WS-I BP仕様と比較します。プロジェクトの再作成時やリソースの保管時にWSDLバリデーターが自動的に実行されるように設定可能です。「ウィンドゥ」メニューから、「設定」＞「妥当性検査」を選択します。「WSDLのバリデーター」にチェックが付いていれば自動的に実行されます。（デフォルトでONになっています）

14



SOAPメッセージのWS-I準拠チェック機能

� WS-I メッセージvalidation

� TCPIP Monitorでキャプチャーしたメッセージのチェックが可能� .Netクライアントからのメッセージキャプチャー＆バリデーションなどにも

◎

Webサービス開発時に、WS-I準拠レベルを設定するだけでなく、WebサービスがTCP/IPモニター経由で生成するSOAPメッセージのWS-I準拠についても検証することができます。【前提条件】検証ツールを使用してSOAPメッセージのWS-I準拠チェックを行う前に、あらかじめ以下の手順を実行しておく必要があります。・Webサービス・プロバイダーの生成・生成されたWSDLの妥当性検証・Webサービス・リクエスター（テスト用に生成されるサンプル・アプリケーションでも可）・TCP/IPモニターのセットアップ以下の手順で検証を実施します。１．Webサービス・サンプル・アプリケーション内のメソッドを起動して、TCP/IPモニター経由のトラフィックを生成する。２．そのWebサービスがWS-I準拠であるか確認するには、上図のアイコンをクリックしてログ・ファイルを生成します。３．開いたダイアログ・ボックスで、ログ・ファイルの名前を選択し、その保管場所を指定します。このログ・ファイルには、Webサービスとの間で送受信されたメッセージがWS-I準拠であるかどうかが表示され、準拠していないエレメントがすべてリストされます。ログ・ファイルはXMLエディターで開いて内容を確認することができます。

15



(参考)WebSphere interoperability

� 異なるバージョンのWAS間では相互運用性を保つ� IBM SOAPエンジンはWS-Iに非準拠� WS-Securityを実装しているWAS

v5.0.2/5.1-v6間では相互運用性はなし� WS-SecurityがDraftとv1.0で互換性がないため

WS-I Basic Security Profile V1.0上図では、WASの各バージョンによるWebSphereランタイム環境とWebサービス機能を示しています。異なるバージョンのWAS間では相互運用性は保たれています。（異なるランタイム環境では相互運用性はありません）ただし、IBM SOAPエンジンはWS-Iに非準拠になるので、他ベンダーとの相互運用性はありません。WAS V5.0.2/5.1とWAS V6.0/6.1では、共にWS-Securityをサポートしています。しかし、WS-SecurityのDraft版とV1.0では互換性がないため、WASのV5とV6間での相互運用性はありません。

16



Webサービス・プロバイダー開発

Webサービス・プロバイダー開発について説明します。

17



Webサービス開発

� JAX-RPCを使用したサービス開発� Webサービス・プロバイダーの開発

� ビジネス・ロジック� サービスのインターフェース（WSDL）

� Webサービスのクライアント開発� クライアント・アプリケーション

Webサービス・リクエスター Webサービス・プロバイダーーPort

Service Endpoint

Interface(SEI)

Java Bean

EJB

サービス側が提供するインターフェースサービス側が提供するインターフェースサービス側が実装するビジネス・ロジックサービス側が実装するビジネス・ロジックメソッド定義メソッド実行メソッド実行Servlet

サービス呼び出しを行うクライアント・アプリケーションサービス呼び出しを行うクライアント・アプリケーションSOAPメッセージSOAPメッセージJava⇔⇔⇔⇔XML

Java⇔⇔⇔⇔XML

JAX-RPCを使用したWebサービスの開発には、サービスを提供するWebサービス・プロバイダーの開発とサービスを実行するWebサービス・リクエスターの開発という２つの視点が必要になります。プロバイダー側では、サービスを実行するビジネスロジックとクライアント側に提供するインターフェース（WSDL）を作成する必要があります。開発方法としては、既存のビジネスロジックからWSDLを生成するBottom upの方法と、インターフェースを定義し、WSDLを作成してから実装クラスを生成するTop downの2種類の方法があります。クライアント側では、サービスから提供されたWSDLを元に、サービス呼び出しを実施するクライアント・アプリケーションの開発が必要になります。

18



Webサービス・プロバイダー開発の流れ－Top down－

� Webサービス・プロバイダー開発は以下のような流れで行う既存WSDLor新規WSDLWSDL SEISEISEISEI＆＆＆＆構成構成構成構成ファイルファイルファイルファイル生成生成生成生成SEI 実装モジュール作成EJB Java EJB JavaEAR

SEI SEIパッケージングパッケージングパッケージングパッケージングデプロイ構成ファイル構成ファイル WSDL

開発ツール使用Top downTop down

� WSDLを作成し、新規に実装モジュールを作成する� メッセージに使用するXMLスキーマを自分で定義� 開発ツールを使用すれば、ウィザードでSEIや実装コードのスケルトン、メッセージで扱う

JavaBeanなどが生成されるWebサービス・プロバイダーの開発はTop downで画面のような流れで行っていきます。ツールによって自動生成されるSEIなどのクラス・ファイル群は以下になります。•SEI(Service Endpoint Interface):Webサービスとして公開するメソッドをJavaのインターフェースとして定義します。Webサービスのリクエスター側の視点からWebサービスの定義を表し、EJBのリモート・インターフェースを表します。java.rmi.Remoteインターフェースを継承する必要があります。•スケルトンクラス：ビジネス・ロジックを実装、またはビジネス・ロジックを呼び出す実装クラスです。•オブジェクト・マッピングファイル：Webサービスの要求/応答メッセージでJavaオブジェクトを使用している場合に、シリアライザーとデシリアライザーとなるオブジェクトのマッピングファイルです。構成ファイルには以下のものが生成されます。•JAX-RPCマッピング・ファイル：WSDLとJavaのインターフェースのマッピング情報を定義します。以下は、Webサービス用のデプロイメント記述子で、Web services for J2EEの仕様で定められた内容を表します。•Webサービスデプロイメント記述子の拡張ファイル•Webサービスデプロイメント記述子

19



Webサービス・プロバイダー開発の流れ－Bottom up－

� Webサービス・プロバイダー開発は以下のような流れで行うEJB JavaEAR既存モジュールor新規モジュール SEISEISEISEI生成生成生成生成 WSDLWSDLWSDLWSDL＆＆＆＆構成構成構成構成ファイルファイルファイルファイル生成生成生成生成SEI WSDL EJB JavaEAR

SEI SEIパッケージングパッケージングパッケージングパッケージングデプロイ構成ファイル構成ファイルWSDL

開発ツール使用� 既存のアプリケーションをWebサービス化する� 開発ツールを使用する場合、JavaBeanなどを入力としてウィザードを実行して作成� SEIやWSDLなどが自動で生成される� メッセージで扱うJavaBeanなどは自動的にXMLスキーマに定義される

Bottom upBottom up

サービスの開発はBottom upで画面のような流れで行っていきます。サービスの実装通常のモジュールとして実装 or 既存のモジュールを使用普通のJava Beanクラス（Webコンテナー）StatelessSessionBean（EJBコンテナー）ツールによって自動生成されるSEIなどのクラス・ファイル群は以下になります。

•SEI(Service Endpoint Interface):Webサービスとして公開するメソッドをJavaのインターフェースとして定義します。Webサービスのリクエスター側の視点からWebサービスの定義を表し、EJBのリモート・インターフェースを表します。java.rmi.Remoteインターフェースを継承する必要があります。•Webサービス実装クラス：ビジネス・ロジックを実装、またはビジネス・ロジックを呼び出す実装クラスです。•オブジェクト・マッピングファイル：Webサービスの要求メッセージでJavaオブジェクトを使用している場合に、シリアライザーとデシリアライザーとなるオブジェクトのマッピングファイルです。構成ファイルには以下のものが生成されます。•WSDL：WebサービスのインターフェースをXMLで定義したファイルです。•JAX-RPCマッピング・ファイル：WSDLとJavaのインターフェースのマッピング情報を定義します。以下は、Webサービス用のデプロイメント記述子で、Web services for J2EEの仕様で定められた内容を表します。•Webサービスデプロイメント記述子の拡張ファイル•Webサービスデプロイメント記述子構成ファイル

Webサービス用ディプロイメント・ディスクリプターwebservices.xml

20



Top down -design the WSDL and XSD first-

� When

� 新規開発のケース� 標準的なインターフェースの提供が必要な場合� 相互運用性を重視する場合

� WS-Iに準拠したインターフェースの作成可能� インターフェースが既に決まっていて変更不可能な場合

� 考慮点� 実装可能なインターフェースを設計すること� 複雑なスキーマ定義になることがあるので注意

� 複雑なスキーマは実装が困難� 深い階層のスキーマ定義はパフォーマンス劣化に繋がる

� 既存クラスに対応したデザインがよい� 既存クラスを再利用すると開発生産性が高い

� Assistance

� WSDL/XML エディターを使用� インターフェース・エディター(WID)

WSDLをトップダウンで生成するのはどのような場合か、そのときの考慮点についてまとめます。

21



Bottom up -design the service implementation first-

� When

� レガシー・システムとの連携があり、プロトコルや接続形態の変更を目的としている場合� 実装の変更が困難な場合

� インターフェースの変更が容易な場合� Webサービスの制約によって、インターフェースの変更が生じることがあります

� クライアントが管理下にあり、インターフェースの変更に対応可能� 考慮点

� WSDLとXSDを明確に分離することができない� 実装に依存したデザインになる

� 実装言語に依存したデータマッピングになる� ツールキットは独自のエンコーディング/データマッピングを使用します

� 相互運用性が低くなる可能性がある� Top downよりも開発が長期間になる場合がある

� Assistance

� ツールを使用してWSDLを生成WSDLをボトムアップで生成するのはどのような場合か、そのときの考慮点についてまとめます。

22



サービス定義

� WSDLの構造�WSDLとJava実装のマッピング�JAX-RPCのデータ・マッピング�SOAPメッセージ・モデル�データ・マッピングに関するHint&Tips

23



WSDL V1.1の構造

� WSDL V1.1ドキュメントの構造� XML形式でサービスのインタフェースを記述

抽象的な定義（言語やプラットフォームに非依存）抽象的な定義（言語やプラットフォームに非依存）インターフェース定義<definitions>

<types> データ型定義<portType> 論理操作単位(request&response)の定義<message> メッセージのデータフォーマット定義

<binding> 論理操作に接続方法をマッピング<service> 実際のアクセスポイント定義

<port> binding 要素と実際のURLの結びつけ具体的な記述（Webサイトに固有の情報）具体的な記述（Webサイトに固有の情報）<operation>論理操作で実行するメソッドに相当

WSDLは、XML形式でWebサービスのインターフェースを記述するための仕様です。WSDL (Web Services Description Language) 1.1は、2001年3月にW3Cにノートとして提出されました。XMLでWebサービスのインターフェースを記述するための仕様です。WSDLは、データ型やメッセージの形式を定めている抽象的な定義の部分と、そのWebサービスに実際にどのように、どこにアクセスしたらよいかという具体的な記述部分に分かれています。

24



WSDLの詳細①

1. <?xml version="1.0" encoding="UTF-8"?>

2. <wsdl:definitions targetNamespace="http://web.ws.jp.ibm.com" xmlns:impl="http://web.ws.jp.ibm.com" xmlns:intf="http://web.ws.jp.ibm.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

3. <wsdl:types>

4. <schema targetNamespace="http://web.ws.jp.ibm.com" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

5. <complexType name="UserInfo">

6. <sequence>

7. <element name="prodId" type="xsd:int"/>

8. <element name="prodName" nillable="true" type="xsd:string"/>

9. </sequence>

10. </complexType>

11. <element name="executeResponse">

12. <complexType><sequence>

13. <element name="executeReturn" type="xsd:int"/>

14. </sequence></complexType>

15. </element>

16. <element name="execute">

17. <complexType><sequence>

18. <element name="userInfo" nillable="true" type="impl:UserInfo"/>

19. </sequence></complexType>

20. </element>

21. </schema>

22. </wsdl:types>

データ型の定義

名前空間の宣言

（次ページから参照される）例として、シンプルなサービス定義を表しているWSDLを示します。

25



WSDLの詳細②

1. <wsdl:message name="executeResponse">

2. <wsdl:part element="impl:executeResponse" name="parameters"/>

3. </wsdl:message>

4. <wsdl:message name="executeRequest">

5. <wsdl:part element="impl:execute" name="parameters"/>

6. </wsdl:message>

7. <wsdl:portType name="HelloWSWebBean">

8. <wsdl:operation name="execute">

9. <wsdl:input message="impl:executeRequest" name="executeRequest"/>

10. <wsdl:output message="impl:executeResponse" name="executeResponse"/>

11. </wsdl:operation>

12. </wsdl:portType>

13. <wsdl:binding name="HelloWSWebBeanSoapBinding" type="impl:HelloWSWebBean">

14. <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

15. <wsdl:operation name="execute">

16. <wsdlsoap:operation soapAction=""/>

17. <wsdl:input name="executeRequest">

18. <wsdlsoap:body use="literal"/>

19. </wsdl:input>

20. <wsdl:output name="executeResponse">

21. <wsdlsoap:body use="literal"/>

22. </wsdl:output>

23. </wsdl:operation>

24. </wsdl:binding>

portTypeの定義バインディングの定義

（前ページを参照）

（次ページから参照される）

送受信されるメッセージと、扱うデータ型を定義<wsdl:types>で定義したデータ型を参照メッセージの定義

一つの論理的な操作に使用されるメッセージを指定SEIにマップされるメソッドに相当

論理操作に具体的な接続方法を定義メッセージング形式と各operationのエンコード方式を定義<wsdl:portType>で定義した論理操作を参照

26



WSDLの詳細③

1. <wsdl:service name="HelloWSWebBeanService">

2. <wsdl:port binding="impl:HelloWSWebBeanSoapBinding" name="HelloWSWebBean">

3. <wsdlsoap:address location="http://localhost:9085/HelloWSWeb/services/HelloWSWebBean"/>

4. </wsdl:port>

5. </wsdl:service>

6. </wsdl:definitions>

（前ページを参照）サービスの定義binding要素に実際のアクセスポイントをマッピング

27



(参考)WSDLの作成

� RAD/WIDを使用したWSDLの作成� WSDLエディターを使用

複合型データWSDLエディターはWSDLの構造と同じフィールドが提供されているため、WSDLの構造を知っていれば簡単にWSDLの作成が可能です。

28



WSDLとJava実装のマッピング

<definitions>

<types> データ型定義<portType> 論理操作単位(request&response)の定義<message> メッセージのデータフォーマット定義<binding> 論理操作に接続方法をマッピング<service> 関連するportをまとめたサービスの定義

<port> binding 要素と実際のURLの結びつけ<operation> 論理操作で実行するメソッドに相当Port Compornent

Port Compornent

JAX-RPCランタイムJAX-RPCランタイムProtcolTransport

Service Endpoint

Imprementation

Service Endpoint

Imprementation

Service Endpoint Interface

XML to Java mapping

Serialize / Deserialize

Service

WSDLドキュメントとJavaのマッピングについて説明します。wsdl:portType：Service Endpoint Interface(SEI)にマップされます。java.rmi.Remoteインターフェースを拡張します。wsdl:operation：SEIで定義されるメソッドにマップされます。WSDL1.1は固有にすべき操作名については何も述べていないため、同じ名前でパラメーターが異なる操作が多重定義される場合があります。さらに、JAX-RPC仕様は、WSDL仕様で定義されているように一方向の要求/応答操作しかサポートしないことに注意する必要があります。要求/応答または通知スタイルの操作はサポートしません。wsdl:binding：JAX-RPCはwsdl:bindingの標準のJava表現を定義していません。これは、実行時に必要なバインディングを定義できることを意味します。JAX-RPC実行時システムはRPC型とdocument型のSOAPバインディングを少なくともサポートしています。wsdl:service：このWSDLの具体的な定義は、一連のサービス・エンドポイント（つまりwsdl:ports）をグループ化します。JAX-RPCはwsdl:serviceをJavaサービス・クラスにマップします。このサービス・クラスは、javax.xml.rpc.Serviceインターフェースを実装するか、wsdl:service定義にマップされている生成されたJavaインターフェースを実装して、次いでjavax.xml.rpc.Serviceを実装します。

29



（参考）WSDL V1.1 各要素の関係

� WSDLはいくつもの要素を含んでいますが、以下のような関係の元に定義することができます

WSDLはいくつもの要素から成り立っていますが、各々は上図のような対比関係にあります。この関係の元にWSDLは定義され、また実装にも反映されていきます。

30



データ型定義

� サービスで扱うデータの型定義は、XMLスキーマと実装言語、共に考慮が必要<definitions>

<types> データ型定義<portType> 論理操作単位(request&respons)の定義<message> メッセージのデータフォーマット定義<binding> 論理操作に接続方法をマッピング

<service> 実際のアクセスポイント定義<port> binding 要素と実際のURLの結びつけ<operation>論理操作で実行するメソッドに相当

XMLスキーマによる型定義XMLスキーマによる型定義Javaではどう扱われる？？

サービスで扱うデータの型定義はWSDLの<types>要素内でXMLスキーマを使用して行われます。Javaで使用可能な全てのデータ型をXMLスキーマで定義できるわけではありません。XMLスキーマでは定義できないJavaのデータ型や、また全く異なるデータとして扱われるケースもあります。データ定義を行う際に、XMLスキーマの型定義とJavaのデータ型がどのようにマッピングされるかを把握することは非常に重要です。

31



JAX-RPCのデータ型マッピング

� JAX-RPCでは、XMLからJavaへのマッピングを定義� JAX-RPCでサポートされる型

� JavaのPrimitive型とそのwrapperクラス� スタンダードJavaクラス� 定義外のスタンダードJavaクラスはシリアライザーとデシリアライザーを定義することで使用可能

Java to XML

mapping

XML to Java

mapping

XML to Java

mapping

Java to XML

mapping

SOAPメッセージJAX-RPC

Client

JAX-RPC

Server

Input

Output

JAX-RPCの主な役割のひとつに、JavaとXMLのマッピングがあげられます。JAX-RPCでは、WSDLに記述されている内容を、Javaのプログラム上ではどのようなクラスとして定義するか、あるいはその逆について定義されています。これを「データ型マッピング」と呼びます。JavaオブジェクトをXMLメッセージに変換することをシリアライザー，XMLメッセージをJavaオブジェクトに変換することをデシリアライザーと呼びます。標準マッピングとして，Java-XML間マッピングとXML-Java間マッピングがあげられます。ただし，JavaのCollectionクラスなどJAX-RPCランタイムの標準マッピングとして定義されていないものに関しては，シリアライザー，デシリアライザーを自作する必要があります。JAX-RPCでは，JavaからXMLへのマッピングに関する仕様が定義されています。Javaのクラスや変数名は，XMLに付けられた名前(要素名)にマッピングされます。次ページからはJAX-RPC仕様で定義されたJavaからWSDL/XMLへのマッピングについて，プリミティブ型と標準Javaクラスについて記述します。その他，JAX-RPCで扱えるデータ型として，配列やユーザー定義型Java Beanクラスなどもあります。

32



JAX-RPCでサポートされる型（１）

� Java Primitive Type

� 右図のprimitive型� これらの型のwrapperクラス

� java.lang.Boolean

� java.lang.Byte

� java.lang.Short

� java.lang.Integer

� java.lang.Long

� java.lang.Float

� java.lang.Doublexsd:doubledouble

xsd:floatfloat

xsd:longlong

xsd:intint

xsd:shortshort

xsd:bytebyte

xsd:booleanboolean

XML Data TypeJava Primitive Type

JAX-RPCでサポートされているプリミティブ型を画面の表に示します。JAX-RPCの仕様でJavaのプリミティブ型とXMLのデータ型との対応が規定されています。

33



JAX-RPCでサポートされる型（２）

� Standard Java Class

� 一部のスタンダードJavaクラス（以下の表のもの）� 他のスタンダードjavaクラスは、シリアライザーおよびデシリアライザーを定義することにより使用可能

xsd:anyURIjava.net.URI

xsd:QNamejavax.xml.namespace.QName

xsd:dateTimejava.util.Date

xsd:dateTimejava.util.Calendar

xsd:decimaljava.math.BigDecimal

xsd:integerjava.math.BigInteger

xsd:stringjava.lang.String

XML Data TypeJava Class

JAX-RPCでサポートされているスタンダードJavaクラスを画面の表に示します。JAX-RPCの仕様でスタンダードJavaクラスとXMLのデータ型との対応が規定されています。

34



JAX-RPCでサポートされる型（３）

� JAX-RPC Value Class

� JAX-RPCで交換可能なデータ型で一定の条件を満たすもの� publicなデフォルト・コンストラクターをもつこと� java.rmi.Remoteインターフェースをimplementsしていないこと� すべてのpublicフィールドが、JAX-RPCでサポートされる型をもつこと� JavaBeansである場合は、すべてのBeanプロパティが、JAX-RPCでサポートされる型をもつこと� XML SchemaのComplex Typeにマップされる� WSDLのtypesセクションで<complexType>タグを使用して型定義

� 例外クラス� java.lang.Exceptionのサブクラスとして定義された例外クラス

� ただし、java.lang.RuntimeExceptionのサブクラスでないもの。� これらのサポート対象クラスの配列

� 多次元配列を含むJavaのprimitive型とそのwrapperクラスやスタンダードJavaクラスのほかに、一定の条件を満たして定義されたJavaクラスのデータを、Webサービス・クライアントとエンドポイントの間で交換可能としています。これは、JAX-RPC Value Typeと呼ばれます。

•publicなデフォルト・コンストラクター（引数のないコンストラクター）をもつこと。•java.rmi.Remoteインターフェースをimplementsしていないこと。ただし、他のinterfaceのimplementsや、他のクラスのextendsはかまいません。•すべてのpublicフィールドが、JAX-RPCでサポートされる型をもつこと。•private, protected,およびpackage-levelフィールドについてはこの制限はありませんが、データはシリアライズされません（XMLにマップされるのは、transitentあるいはfinal宣言のないpublicフィールドのみとなります）。•JavaBeansである場合は、すべてのBeanプロパティが、JAX-RPCでサポートされる型をもつこと

JAX-RPC Value Typeは、XML SchemaのComplex Typeとにマップされます。Complex Typeの定義はWSDLの<types>セクションにおいて行われることになります。JAX-RPCでのサービス・エンドポイント・インターフェースの各メソッドは、java.rmi.RemoteExceptionをthrow可能ですが、このほか、各メソッドで独自に定義したExceptionをthrowすることができます。この場合、throwされる例外クラスは、java.lang.Exceptionのサブクラスであって、java.lang.RuntimeExceptionのサブクラスではないもの（チェック例外）でなければなりませんJAX-RPCによってサポートされるクラスの配列は、JAX-RPCのサポート対象となります。多次元配列も含まれます。

35



SOAPメッセージ・モデル

� 実際のSOAPメッセージにいくつかのタイプがある<definitions>

<types> データ型定義<portType> 論理操作単位(request&respons)の定義<message> メッセージのデータフォーマット定義<binding> 論理操作に接続方法をマッピング

<service> 実際のアクセスポイント定義<port> binding 要素と実際のURLの結びつけ<operation>論理操作で実行するメソッドに相当実際の

SOAPメッセージは？？

要求・応答のメッセージ定義要求・応答のメッセージ定義

WSDLでは<portType>要素や<binding>要素で実際に送受信するSOAPメッセージの定義を行います。<binding>要素の設定によって、SOAPメッセージのタイプが異なります。

36




� SOAPメッセージは、メッセージング形式（document/RPC）とエンコーディング方式（encoded/literal）のそれぞれの組み合わせで内容が異なる� 全5種類のメッセージ・モデル

� メッセージング形式� SOAPを利用してWebサービス通信を行う際のメッセージの形式（文書構造）� SOAPボディの構造

� エンコーディング方式� SOAPメッセージを交換する際のデータの形式� SOAPボディの符号化方法

document/literalrpc/literalliteral

document/encodedrpc/encodedencoded

documentRPCエンコード方式メッセージング形式+document/literal wrapped

SOAPエンベロープSOAPヘッダーSOAPボディ

WebサービスのSOAPメッセージはSOAPボディの構造を表すメッセージング形式（RPCまたはdocument）とSOAPボディの符号化方法を表すエンコード方式（encodedまたはliteral）のそれぞれの組み合わせでメッセージ・モデルが異なります。document/literal形式に修正を加えたdocument/litaral

wrappedと呼ばれる形式を含めて全5種類のメッセージ・モデルが存在します。

37



メッセージング形式

� メッセージング形式� SOAPを利用してWebサービス通信を行う際のメッセージの形式（文書構造）� SOAPボディの構造

� document型� SOAPを利用してXMLドキュメントを送信� SOAPボディの構造は<wsdl:types>のXMLスキーマで定義

� RPC型� SOAPを通じてRPCを実現� SOAPボディはSOAP-RPCの規約に従う

� Operation要素の子要素としてInput/Outputデータが含まれるSOAPエンベロープ

SOAPヘッダーSOAPボディ

XML

SOAPエンベロープSOAPヘッダーSOAPボディSOAP-RPCの規約に則る

メッセージング形式ではSOAPメッセージのボディ構造を指定します。document型とRPC型の2種類があります。document型はSOAPボディの構造は自由に定義することができます。WSDL文書の<wsdl:types>のXMLスキーマで定義します。RPC型はSOAP-RPCの規約に従って、Operation名(メソッド名にあたる)の要素の子要素として、メソッドの引数や戻り値などのパラメーターが含まれる構造となります。SOAPボディの構造としてどちらを使用するかは、WSDL文書のstyle属性で指定します。

38



エンコーディング方式

� エンコーディング方式� SOAPメッセージを交換する際のデータの形式� SOAPボディの符号化方法

� encoded

� SOAP仕様のSOAPエンコーディングに従って符号化� literal

� <wsdl:types>で指定したXMLスキーマの定義に従って符号化� 通常のXMLドキュメントと同様の形

� document/literal wrapped

� document/literalの拡張� Microsoftの.NETとの相互運用性が高く、業界標準となっている

エンコーディング方式とは、SOAPボディの符号化方式を表すもので、encoded型とliteral型の2種類があります。encoded型は、SOAPボディの符号化をSOAP仕様のSOAPエンコーディングに従って行います。literal型は、SOAPボディのデータの符号化を、<wsdl:types>で指定したXMLスキーマの定義に従って行います。エンコーディング方式としてどちらを使用するかは、WSDL文書のuse属性で指定します。document/literal wrappedはdocument/literalを拡張したもので、SOAPボディの要素名がOperation名（メソッド名）となります。.Netとの互換性も高いためこのスタイルがデファクト・スタンダードとなっています。

39



（参考）SOAPエンコーディング

� SOAPエンコーディング (SOAP-ENC)

� 基本的なデータ型をXMLで表現するための、SOAPで規定されたエンコーディング方式� encoded型のSOAPメッセージで使用されるエンコーディング方式� SOAP 1.1仕様セクション５

� Simple Types

� XML Schema Part2: Datatypes (XSD)の組み込みデータ型をそのまま使用� EnumerationについてもXSDの機構をそのまま使用

� Compound Types

� Struct� Complex Typeとして記述。� href属性を使用したデータ参照による記述が可能

� Array� SOAP-ENC:Arrayという独自記法を採用� 同じデータを表現するのに複数の記法を許す

通常、encoded型のSOAPメッセージ中では、エンコーディング方式として、SOAP 1.1仕様のセクション５で規定されたエンコーディング方式「SOAP エンコーディング」が使用されます。SOAPエンコーディングでは、単純な型については、XMLスキーマの組み込みデータ型で規定された型をそのまま使用します。この中には、string型やenumeration型も含まれます。複雑な構造を持つ型については、SOAPエンコーディング独自の規定を行っています。•Struct型は、それぞれの値が要素名によってのみ区別される（その要素の出現順序は関係ない）データについて使用するものです。href属性を使用して、参照によりデータを表現することができます。•Array型は、それぞれの値が要素の出現順序によって区別されるデータについて使用するものです。<SOAP-ENC:Array>という独自記法によって型定義を行います。同一のデータに対して複数の記法を許しているため、相互接続の際に問題になることがあります。

40



SOAPメッセージ・モデルの選択

� SOAPメッセージ・モデル� どのSOAPメッセージ・モデルを使用するか?

業界標準WS-I準拠使用しないWS-I準拠WS-I非準拠WASでサポートされるが、使用は推奨されない説明

○(文書/リテラル)

××○(RPC/リテラル)

○(RPC/エンコード)

RADのウィザードで生成(RADでの表記)

document/

literal wrapped

document/

literal

(document/

encoded)

RPC/

literal

RPC/

encoded


「「「「document/literal wrapped」」」」(RADのののの「「「「文書文書文書文書/リテラルリテラルリテラルリテラル」」」」)のののの使用使用使用使用をををを推奨推奨推奨推奨encoded形式は、WS-Iにおいて、使用が禁止されています。相互運用性の観点から、現在、業界標準となっている「document/literal wrapped」を使用することが推奨されます。尚、RADのウィザードにおいては、「文書/リテラル」のエンコード・スタイルを選択することにより、「document/literal wrapped」形式のWSDLファイルが生成されます。

41



document/literal wrapped

� messageで扱うデータを要素（element）でラップする� 要素名はoperation名と同じ

<wsdl:message>が含む<wsdl:part>は１つのみこのpartはelement属性を使用して、<element>を参照する必要があるラッパー・エレメント（callName）の名前は<wsdl:operation>の名前と同じでなければならない<wsdl:types> ・・・・・・・

<element name="callName"><complexType>

<sequence><element name="message" nillable="true" type="xsd:string"/><element name="n" nillable="true" type="impl:NameInfo"/>

</sequence></complexType>

</element><complexType name="NameInfo">

<sequence><element name="FName" nillable="true" type="xsd:string"/><element name="LName" nillable="true" type="xsd:string"/>

</sequence></complexType>・・・・・・・・</wsdl:types>

<wsdl:message name="callNameRequest"><wsdl:part element="impl:callName" name="parameters"/>

</wsdl:message><wsdl:message name="callNameResponse">

<wsdl:part element="impl:callNameResponse" name="parameters"/></wsdl:message>

ラッパー・エレメント

RADを使用してボトムアップのサービス開発を実施した場合、生成されるWSDLファイルはdocument/literal wrapped形式になります。トップダウンでサービス開発を行う場合に、document/literal

wrapped形式のWSDLを作成するには以下の点に注意します。document/literal wrapped形式は、messegeで扱うデータを要素でラップします。この際に、ラッパー・エレメントの名前は、operation名と同じでなければなりません。また、<wsdl:message>が含むことのできる<wsdl:part>は１つのみであり、複数定義することはWS-Iに準拠しません。

42



<wsdl:types>・・・・・・<element name="message" nillable="true" type="xsd:string"/><complexType name="NameInfo">

<sequence><element name="FName" nillable="true" type="xsd:string"/><element name="LName" nillable="true" type="xsd:string"/>

</sequence></complexType><element name="NameInfo" nillable="true" type="impl:NameInfo"/>・・・・・ </wsdl:types>

<wsdl:message name="callNameRequest"><wsdl:part element="intf:message" name="message"/><wsdl:part element="intf:NameInfo" name="n"/>

</wsdl:message>

（参考）ラップされないdocument/literal型

<wsdl:message>が複数の<wsdl:part>を含む各々のpartがelement属性を使用して<element>を参照ラップされていないdocument/literal型の例を示します。

43



（参考）SOAPメッセージ・モデル Sample

� 以下のインターフェースを実装するWebサービスの実行で送受信されるSOAPメッセージを比較

package com.ibm.ws;

public interface HelloWSWeb_SEI extends java.rmi.Remote{public java.lang.String[ ] callName(java.lang.String message,com.ibm.ws.NameInfo n);

}

SEISEI

public class NameInfo {

private String fName = null;private String lName = null;

public NameInfo(){}public String getFName() { return fName; }public void setFName(String name) { fName = name; }public String getLName() { return lName; }public void setLName(String name) { lName = name; }

}

オブジェクト型を引数とする

SOAPメッセージ・モデルによって、送受信されるメッセージ内容がどのように異なるのか、上図のサンプル・インターフェースを例に次ページから示していきます。サンプルのインターフェースでは、要求パラメーターではString型とオブジェクト型(NameInfo)を扱い、応答にString型の配列を返します。

44



(参考)rpc/literal

<soapenv:Body>

<p295:callName ><message>hello</message><n>

<FName>taro</FName><LName>yamada</LName>

</n></p295:callName>

</soapenv:Body>

<soapenv:Body>

<p295:callNameResponse ><callNameReturn>

<string>hello</string><string>taro</string><string>yamada</string>

</callNameReturn>

</p295:callNameResponse></soapenv:Body>

<wsdl:message name="callNameRequest">

<wsdl:part name="message" type="xsd:string"/>

<wsdl:part name="n" type="impl:NameInfo"/>

</wsdl:message>

<wsdl:message name="callNameResponse">

<wsdl:part name="callNameReturn" type="impl:ArrayOf_xsd_nillable_string"/>

</wsdl:message>

<wsdl:portType name="HelloWSWeb">

<wsdl:operation name="callName"parameterOrder="message n">

<wsdl:input message="impl:callNameRequest" name="callNameRequest"/>

<wsdl:output message="impl:callNameResponse" name="callNameResponse"/>

</wsdl:operation>

</wsdl:portType>

WSDL SOAP Message

【request】【response】

WS-I 準拠WS-I 準拠

45



（参考）doc/literal wrapped

<soapenv:Body>

<p295:callName ><message>hello</message><n><FName>taro</FName>

<LName>yamada</LName></n></p295:callName></soapenv:Body>

<soapenv:Body>

<p295:callNameResponse ><callNameReturn><string>hello</string><string>taro</string><string>yamada</string></callNameReturn></p295:callNameResponse></soapenv:Body>


<wsdl:part element="impl:callName" name="parameters"/>

</wsdl:message>


<wsdl:part element="impl:callNameResponse" name="parameters"/>

</wsdl:message>


<wsdl:operation name="callName">

<wsdl:input message="impl:callNameRequest" name="callNameRequest"/>

<wsdl:output message="impl:callNameResponse" name="callNameResponse"/>

</wsdl:operation>

</wsdl:portType>

WS-I 準拠WS-I 準拠業界標準業界標準WSDL抜粋SOAP Message

【response】【request】

46



（参考）doc/literal

<soapenv:Body>

<p295:message>hello</p295:message><p295:NameInfo>

<FName>taro</FName><LName>yamada</LName>

</p295:NameInfo></soapenv:Body>

<soapenv:Body>

<p295:ArrayOf_xsd_nillable_string ><string>hello</string><string>taro</string><string>yamada</string>

</p295:ArrayOf_xsd_nillable_string></soapenv:Body>


<wsdl:part element="intf:ArrayOf_xsd_nillable_string" name="callNameReturn"/>

</wsdl:message>


<wsdl:part element="intf:message" name="message"/>

<wsdl:part element="intf:NameInfo" name="n"/>

</wsdl:message>



<wsdl:input message="intf:callNameRequest" name="callNameRequest"/>

<wsdl:output message="intf:callNameResponse" name="callNameResponse"/>

</wsdl:operation>

</wsdl:portType>


SOAP MessageWSDL

WS-I 準拠WS-I 準拠

47



（参考）rpc/enc

<soapenv:Body

soapenv:encodingStyle="http://schemas.xmlsoap.o

rg/soap/encoding/">

<p295:callName ><message

xsi:type="xsd:string">hello</message>

<n xsi:type="p295:NameInfo"><FName xsi:type="xsd:string">aaa</FName>

<LName xsi:type="xsd:string">bbb</LName>

</n>

</p295:callName></soapenv:Body>

<soapenv:Body

soapenv:encodingStyle="http://schemas.xmlsoap.

org/soap/encoding/">

<p295:callNameResponse >

<callNameReturn soapenc:arrayType="xsd:string[3]" xsi:type="soapenc:Array">

<item>hello</item>

<item>aaa</item>

<item>bbb</item>

</callNameReturn>

</p295:callNameResponse></soapenv:Body>


<wsdl:part name="message" type="xsd:string"/>

<wsdl:part name="n" type="impl:NameInfo"/>

</wsdl:message>


<wsdl:part name="callNameReturn"

type="impl:ArrayOf_xsd_nillable_string"/>

</wsdl:message>



<wsdl:input message="impl:callNameRequest"

name="callNameRequest"/>

<wsdl:output message="impl:callNameResponse"

name="callNameResponse"/>

</wsdl:operation>

</wsdl:portType>型のエンコード方式情報がパフォーマンス低下を招く

48



データ・マッピングに関するHint&Tips

�複合型データ・タイプ

� xsd:any vs xsd:anyType

� Javaコレクション・タイプ

相互運用性のあるWebサービスを構築する際、SOAPメッセージで扱うデータ型を考慮する必要があります。本節では、Webサービス開発でも検討されることの多い、以下のデータ型のJAX-RPCでの扱いについて説明します。•複合型データ・タイプ•xsd:any vs xsd:anyType

•Javaコレクション・タイプ

49



複合型データ・タイプ

� XMLスキーマの複合型データはgetter/setterをもつJavaBeanにマップされます� 複合型でxsd:sequenceが含まれている場合でも、JavaBeanでは要素の順番は保たれない

� 要素属性maxOccursに正の値が設定されている複合型は、対応する型のJava配列にマップされます<xsd:complexType name="Book">

<sequence>

<element name="author" type="xsd:string" maxOccurs="10" />

<element name="price" type="xsd:float" />

</sequence>

<xsd:attribute name="reviewer" type="xsd:string" />

</xsd:complexType>

<xsd:complexType name="Book">

<sequence>

<element name="author" type="xsd:string" maxOccurs="10" />

<element name="price" type="xsd:float" />

</sequence>

<xsd:attribute name="reviewer" type="xsd:string" />

</xsd:complexType>

public class Book{

private float price;

private String[] author;

private String reviewer;

//…………………….

public String[] getAuthor(){…….}

public setAuthor(String[] atuhor){................}

public float getPrice(){…………….}

public void setPrice(float price){…..}

public String getReviewer(){……..}

public void setReviewer(String reviewer){………}

}

public class Book{

private float price;

private String[] author;

private String reviewer;

//…………………….

public String[] getAuthor(){…….}

public setAuthor(String[] atuhor){................}

public float getPrice(){…………….}

public void setPrice(float price){…..}

public String getReviewer(){……..}

public void setReviewer(String reviewer){………}

}

XMLスキーマの複合型は、getterおよびsetterによってJavaBeansにマップされ、複合型内の各要素にアクセスできるようにします。これらの型を扱う場合に、いくつかの考慮点があります。まず、複合型にxsd:sequenceが含まれている場合でも、JavaBeansでは要素の順番は保たれません。また、要素属性maxOccursに正の値が設定されている複合型は、対応する型のJava配列にマップされます。このような型は、minOccursとmaxOccursの可能なすべての組み合わせを定義するわけではありません。

50



xsd:any vs xsd:anyType①

� xsd:any

� XMLスキーマのパーティクル� 任意の要素を記述可能

� xsd:anyをなぜ使用する？� サービスを変更してもAPIを変更する必要がない

� XMLは単独で存在することは稀で、実装言語とマップされ、相互に作用する� xsd:anyが実装言語にどのようにバインディングされるかを知っておく必要がある

<xsd:any namespace="出現可能な要素の属する名前空間のURIまたはキーワードのリスト"processContents="スキーマ認識プロセッサの検証に関するキーワード"

minOccurs="出現最低回数" maxOccurs="出現最高回数"/>

<xsd:any namespace="出現可能な要素の属する名前空間のURIまたはキーワードのリスト"processContents="スキーマ認識プロセッサの検証に関するキーワード"

minOccurs="出現最低回数" maxOccurs="出現最高回数"/>柔軟性

XMLスキーマの内容モデルのある位置に任意の要素を記述するためにxsd:anyを使用することがあります。名前空間を指定することで、他の名前空間に属する要素を出現させることも可能です。minOccurs/maxOccursを使用することで、要素の出現回数を指定することも可能です。xsd:anyで要素を定義しておくと、たとえサービスのインターフェースが変更されても実装のAPIの変更が少なくても済みます。こういった柔軟性からxsd:anyを使用されることが多々あります。WebサービスではXMLを単独で使用することは稀で、実装言語とマップされ、相互に作用することになります。xsd:anyを使用する場合は、Webサービスの実装言語でどのようにマッピングされるかを知っておく必要があります。

51



xsd:any vs xsd:anyType②

� XMLスキーマにおける記述<xsd:element name="setInfo">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="lastname" type="xsd:string"></xsd:element>

<xsd:element name="firstname" type="xsd:string"></xsd:element>

<xsd:any></xsd:any>

</xsd:sequence>

</xsd:complexType>

</xsd:element>パラメーターが何かわからない！

xsd:anyを使用したWSDLの抜粋リクエスターとプロバイダー間で事前に規約を決めてデータを送受信する必要があるリクエスターとプロバイダー間で事前に規約を決めてデータを送受信する必要がある

<xsd:any>を使用した場合のXMLスキーマの記述例を示します。本来の要素宣言では要素名とそのデータ型を定義する必要がありますが、<xsd:any>ではいずれも定義されない空要素となります。サービスの変更に柔軟に対応できる一方で、事前にWebサービスのリクエスターとプロバイダー間で規約を決めてデータを送受信する必要があります。

52



xsd:any vs xsd:anyType③

� JAX-RPCでのマッピング� xsd:anyはSAAJ仕様で定義されたjavax.xml.SOAPElementにマップされる

� クラスをSOAPElementにプッシュする方法はSAAJでは規定されていない� JAX-RPCではクラスのインスタンスとSOAPElementとの間の変換の方法は提供していない

package com.ibm.jp.data;

public class InputUserInfo2SOAPImpl implements InputUserInfo2_PortType{UserInfo setInfo(String lastname, String firstname, javax.xml.soap.SOAPElement any)

throws java.rmi.RemoteException {return null;

}}

xsd:anyを使用したWSDL用のJavaインターフェース

WSDLのユーザーには優しくない（DOM、SAX、SAAJの技術が必要）<xsd:any>がJAX-RPCでどのようなJavaクラスにマッピングされるのか知っておく必要があります。JAX-

RPCでは<xsd:any>はSAAJ仕様で定義されたjavax.xml.SOAPElementにマップされています。クラスをSOAPElementにプッシュする方法はSAAJでは規定されておらず、JAX-RPCではクラスのインスタンスとSOAPElementとの間の変換方法は提供していません。DOM、SAX、SAAJに関する知識を有する開発者に取っては問題ないかもしれませんが、それ以外の一般的にWSDLを扱う開発者には扱いにくいWSDLとなります。

53



xsd:any vs xsd:anyType④

� xsd:anyの代わりに組み込みデータ型のxsd:anyTypeを使用可能� 任意の型を使用することができる

� JAX-RPCでマッピングが定義されていない� ベンダーがこのXMLタイプをマップする場合でも、移植可能コードではない� 一部のベンダーがjava.lang.Objectなどの便利なタイプにマップしている

� WASのSOAPエンジンはjava.lang.Objectにマップ� 以下の考慮点がある

� コードは移植可能なものではない� サービスとクライアントの両方のランタイム環境が、xsd:anyTypeのデータ・マッピングを備えていないと使用できないサポートされているJAX-RPCマッピングではない

<xsd:any>の使用が困難な場合、<xsd:any>と似た特性を持つ<xsd:anyType>を使用することを考えてみましょう。<xsd:anyType>はXMLスキーマで定義されている組み込みデータ型で任意のデータ型を許します。しかし、JAX-RPCでJavaクラスとのマッピングは定義されていません。一部のベンダーはjava.lang.Objectなどの便利なタイプのクラスにマップしていますが、他ベンダーとの相互接続性を考えると<xsd:anyType>を使用した移植可能コードを記述することはできません。WASのSOAPエンジンは<xsd:anyType>をjava.lang.Objectにマップしています。一部のベンダーは<xsd:anyType>をjava.lang.Objectにマップしてしますが、Webサービスのリクエスターとプロバイダーの双方でxsd:anyTypeのマッピングを備えていないと使用できません。サポートされたJAX-RPCのマッピングではなく、コードは他ベンダーのWebサービスランタイム環境に移植可能なものではありません。

54



xsd:any vs xsd:anyType⑤

<xsd:element name="setInfo">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="lastname" type="xsd:string"></xsd:element>

<xsd:element name="firstname" type="xsd:string"></xsd:element>

<xsd:any></xsd:any>

<xsd:element name="optionalinfo" type="xsd:anyType"></xsd:element></xsd:sequence>

</xsd:complexType>

</xsd:element>

package com.ibm.jp.data;

public class InputUserInfo2SOAPImpl implements InputUserInfo2_PortType{

public UserInfo setInfo(String lastname, String firstname,

javax.xml.soap.SOAPElement any, java.lang.Object optionalinfo)

throws java.rmi.RemoteException {

return null;

}

}

xsd:anyTypeを使用したWSDLの抜粋xsd:anyTypeを使用したWSDL用のJavaインターフェース要素名を指定することができる

xsd:anyTypeを使用したWSDLの例と、そのWSDLからJAX-RPCによって生成されるSEIを示します。

55



Javaコレクション・タイプのマッピング①

� Javaコレクション・タイプ� List,HashMap,Vector,TreeSet

� 例：java.util.Listを使用したクラスpublic class CustomerService {

public List getCustomer(String name1,String name2){List list = new ArrayList();

Customer customer1 = new Customer();customer1.setFName(name1);

Customer customer2 = new Customer();customer2.setFName(name2);

list.add(customer1);list.add(customer2);

return list; } }

public class Customer {private String fName = null;

public String getFName() {return fName;

}public void setFName(String name) {

fName = name;}

}

WSDLを作成すると多くのアプリケーションでコレクション・タイプのクラスは頻繁に使用されており、引数として送受信されるケースも多いと言えます。コレクション・タイプのオブジェクトを引数としてWebサービスで扱う場合にはどのような型にマッピングされるのでしょうか。上記に示す、CustomerServiceクラスを例に説明していきます。CustomerServiceクラスではString型の引数を送信し、コレクション・タイプのListクラスを戻すgetCustomer()メソッドを実装しています。String型のフィールドを保持するCustomerクラスを、コレクションタイプのListクラスにプットしています。

56



Javaコレクション・タイプのマッピング②

� コレクション・タイプはJAX-RPCでサポートされていないため、xsd:anyTypeにマッピングされる

<wsdl:types><schema targetNamespace="http://col.ws.ibm.com" xmlns="http://www.w3.org/2001/XMLSchema"><element name="getCustomer"><complexType><sequence>

<element name="name1" nillable="true" type="xsd:string"/><element name="name2" nillable="true" type="xsd:string"/></sequence></complexType></element>

<element name="getCustomerResponse"><complexType>

<sequence><element name="getCustomerReturn" nillable="true" type="impl:ArrayOfXSDAnyType"/>

</sequence></complexType>

</element>

<complexType name="ArrayOfXSDAnyType">

<sequence>

<element maxOccurs="unbounded" minOccurs="0" name="anyType" nillable="true"

type="xsd:anyType"/>

</sequence>

</complexType></schema></wsdl:types>

Customerクラスがシリアライズ不可能ため、このままでは使用できません前ページで示したクラスからWSDLを生成すると、上記のようになります。（型定義の箇所のみ抜粋）コレクション・タイプはJAX-RPCでサポートされていないため、Listはxsd:anyTypeの配列にマッピングされます。xsd:anyTypeは任意の要素を示しますが、JAX-RPCではObject型にマップされるためクライアント側にCustomer型のオブジェクトを送信することはできません。Customer型のオブジェクトをシリアライズできずにエラーが発生してしまいます。

57



Javaコレクション・タイプのマッピング③

� コレクション・タイプはサービス・インターフェースで使用しない� 配列を使用� WS-I Basic Profileにも準拠

public class CustomerService {public Customer[] getCustomer(String name1,String name2){

Customer[] customers = new Customer[2];

Customer customer1 = new Customer();customer1.setFName(name1);Customer customer2 = new Customer();customer2.setFName(name2);

customers[0] = customer1;customers[1] = customer2;

return customers;} }

public class Customer {private String fName = null;

public String getFName() {return fName;

}public void setFName(String name) {

fName = name;}

}

WSDLを作成するとコレクション・タイプを引数として持つアプリケーションでは、コレクション・タイプの代わりに配列を使用することでJAX-RPCで対応可能なアプリケーションになります。配列の使用はWS-I BPにも準拠しているため相互運用性も保たれます。上記にList型ではなく同じ内容で配列型を引数として扱った例を示します。

58



Javaコレクション・タイプのマッピング④

� 複合型タイプの配列として定義<wsdl:types><schema targetNamespace="http://array.ws.ibm.com" xmlns="http://www.w3.org/2001/XMLSchema"><element name="getCustomer"><complexType><sequence>

<element name="name1" nillable="true" type="xsd:string"/><element name="name2" nillable="true" type="xsd:string"/>

</sequence></complexType></element><element name="getCustomerResponse">

<complexType><sequence>

<element name="getCustomerReturn" nillable="true" type="impl:ArrayOfCustomer"/></sequence>

</complexType></element>

<complexType name="Customer">

<sequence>

<element name="FName" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="ArrayOfCustomer">

<sequence>

<element maxOccurs="unbounded" minOccurs="0" name="Customer" nillable="true"

type="impl:Customer"/>

</sequence>

</complexType></schema></wsdl:types>前ページで示したクラスからWSDLを生成すると、上記のようになります。WSDLにはCustomerクラスも

XMLスキーマによって型定義されおり、Customer型の配列が定義されていることがわかります。

59



Javaコレクション・タイプのマッピング⑤

� SOAPメッセージは以下のように送受信される<soapenv:Body>

<p420:getCustomer xmlns:p420="http://array.ws.ibm.com">

<name1>yamada</name1>

<name2>kato</name2>

</p420:getCustomer>

</soapenv:Body>

<soapenv:Body>

<p420:getCustomerResponse xmlns:p420="http://array.ws.ibm.com">

<getCustomerReturn>

<Customer>

<FName>yamada</FName>

</Customer>

<Customer>

<FName>kato</FName>

</Customer>

</getCustomerReturn>

</p420:getCustomerResponse>

</soapenv:Body>


実際のWebサービス呼び出しで送受信されるSOAPメッセージは上記のようになります。Customer型が保持するフィールド"Fname"の中身も正常に送受信されていることがわかります。

60



Javaコレクション・タイプのマッピング⑥

� 既存のクラスでコレクション・タイプを使用している場合は、サービス・インターフェースとしてラッパー・クラスを用意すると簡単に対応できる� コレクションのインターフェースを配列のインターフェースに変換する

public class CustomerServiceWrapper {

protected CustomerService innerService = new CustomerService();

public Customer[] getCustomer(String name1,String name2){

return (Customer[])innerService.getCustomer(name1,name2).toArray(new Customer[0]);

}

}

コレクション・タイプを扱う既存クラスをインスタンス化既存クラスを呼び出し、コレクションを配列に変換して戻す

パラメーター、メソッド名は配列のインターフェースと同一

しかしながら、コレクション・タイプのクラスを扱う既存のクラスが既に存在している場合、コード編集が困難な場合があります。そのような場合の比較的簡単な対処方法として、サービスとして公開したいインターフェースに対してラッパー・クラスを作成する方法があります。コレクション・タイプを使用するインターフェースを配列を使用するインターフェースに変換するラッパー・クラスを生成します。CustomerServiceクラスを例にすると上記のCustomerServiceWrapperクラスのようになります。CustomerServiceクラスを呼び出し、List型の戻り値を配列に変換して返すメソッドを実装します。このようにして、既存のコレクション・タイプを扱うインターフェースはそのままに、Webサービスのインターフェースを生成することができます。Javaでは多くのコレクション・タイプのクラスを提供していますが、どれも言語から中立しておらず、XMLへシリアライズするのは困難であり時には不可能です。コレクション・タイプのオブジェクトを扱う方法で推奨されるのは配列の活用で、WS-I BPもこのアプローチを推奨しています。

61



Webサービス・クライアント開発

Webサービス・クライアント開発について説明します。

62



Webサービス・クライアント開発の流れ

� クライアントの開発は次のような流れで行う

WSDLの取得WSDL SEISEISEISEI＆＆＆＆構成構成構成構成ファイルファイルファイルファイル（（（（& Stub& Stub& Stub& Stub））））生成生成生成生成SEI クライアント・アプリケーション作成Client ClientEARSEIWSDL

パッケージングパッケージングパッケージングパッケージング構成ファイル構成ファイルStub Stub

開発ツール使用デプロイWASV5.0.2で実装されていたWebサービスでは、クライアントの構成ファイルとして、webservicesclient.xmlがありましたが、WASV6ではそのファイル自体はなくなり、web.xmlに吸収されています。（IBMの拡張部分であるibm-webservicesclient-ext.xmiやibm-webservicesclient-bnd.xmiは残っています。）RADウィザードを用いた場合にはさらに、PortTypeProxyクラスも作成されます。このクラスは、PortTypeクラスのサブクラスとして提供され、setEndpoint など、クライアントを実装する上で使い勝手のよいメソッドが追加されています。生成されたWebサービス・クライアント(プロキシファイル)の稼動確認を行うなどの目的で利用できる便利なクラスです。静的スタブとして実装しているため、動的プロキシベースにてWebサービスアクセスを行いたい場合は使用しません。（図の補足；生成されるプロキシクラスについて）■XXXX_Service.java

javax.xml.rpc.Serviceを継承したインターフェースです。SEIを取得するメソッドを宣言しています。■XXXX_ServiceInformation.java

WebサービスのQNameや名前空間など、Webサービスにアクセスするための情報を保持するクラスです。■XXXX_ServiceLocator.java

XXXX_Serviceインタフェースの実装クラスです。JNDI名によるサービスlookupを行います。＊上記の情報はRAD V6.0時点のものであり、今後の製品バージョンアップに伴い生成されるクラス名などは変更される可能性があります。

63



クライアントプログラミングモデル

� サービスを呼び出すクライアントプログラムの記述方法� 以下の３パターンから選択

� 静的スタブ� 動的プロキシ� DII（Dynamic Invocation Interface）

Webサービスのクライアントには３つのプログラミングモデルがあります。サンプルを交えつつ、３つの方法について順次ご紹介します。

64



静的スタブ

� 各Webサービス固有のServiceクラスを使用してSEIのインスタンスを取得する� SEIのインスタンスに対してWebサービスを実行する� コンパイル時に各WebサービスのStubクラスとSEIが必要

� 通常は実行環境のツールで作成する� Stubクラスは実行環境により変わる� コンパイル時に型チェックが可能であり、実行時の動的なキャスト例外を未然に防ぐことができる// ～try {InitialContext ctx = new InitialContext();// ServiceLocatorクラス(WSHello_Service)のLookupWSHello_Service hello = (WSHello_Service) ctx.lookup("java:comp/env/service/WSHello");// SEIの取得。実行メソッド名はStub依存WSHello_PortType portType = hello.getWSHello();// Webサービスの実行String ret = portType.hello(name);} catch (Exception e){// エラー処理}// ～

Client AppClient AppClient AppClient AppClassClassClassClassLocatorLocatorLocatorLocatorClassClassClassClassJNDI（ServiceLocator） SEI取得SEISEISEISEI

Web サービス実行静的スタブを用いたJAX-RPCクライアントでは、各ベンダーが提供しているツールが自動生成するプロキシクラスを用いてWebサービスにアクセスします。(WebSphereではWSDL2JavaやRADといったツールが提供されます。)実行時には、以下の順序でWebサービス呼び出しを行います。

1. 各Webサービス固有のServiceLocatorをインスタンス化する。2. ServiceLocatorクラスを使用して、Service Endpoint Interface(SEI)のインスタンスを取得する。3. SEIインスタンスに対してWebサービスを実行する。

* SEIインスタンスの呼び出し先はクライアントスタブであり、クライアントスタブがWebサービスとのやりとりを行う。静的スタブ使用時は、WSDL2JavaやRADといったツールにより生成したプロキシクラスをあらかじめクライアントマシンに配置しておく必要があります。

65



動的プロキシ

� JAX-RPCで規定されているServiceインターフェースを使用してSEIのインスタンスを取得する� SEIのインスタンスに対してWebサービスを実行する� コンパイル時にはSEIのみ必要// ～try {InitialContext ctx = new InitialContext();// ServiceのLookupService srv = (Service) ctx.lookup("java:comp/env/service/WSHelloService");// getPort()を使用してSEIを取得WSHello helloBean = (WSHello) srv.getPort(WSHello.class);// Webサービスの実行String ret = helloBean.hello(name);} catch (Exception e){// エラー処理}// ～

Client AppClient AppClient AppClient AppClassClassClassClassServiceServiceServiceServiceInterfaceInterfaceInterfaceInterfaceJNDI(Service) SEI取得SEISEISEISEIWeb サービス実行

動的プロキシのクライアントでは、以下の順序でWebサービス呼び出しを行います。1. Webサービスのクライアント側を表すServiceクラスをlookupする。2. 1.のServiceインターフェースのgetPortメソッドを使用してSEIのインスタンスを取得する。(SEIでキャストする)

3. SEIインスタンスを介してWebサービスを実行する。静的スタブでは、Serviceクラスがサービス固有のクラスでした。動的プロキシではサービス固有ではないServiceインターフェースを用いる点が異なります。動的プロキシの場合、Webサービスのオペレーション(メソッド)が呼び出された時点で、スタブが生成されます。よって実行時には、WSDLファイルをJAX-RPCランタイムが取得可能な場所に配置しておく必要があります。

66



DII (Dynamic Invocation Interface)

� ServiceインターフェースからJAX-RPCのCallインスタンスを取得する� Callインスタンスに対して実行するWebサービスの情報をセットし、実行する� コンパイル時には特に必要なものはないtry {InitialContext ctx = new InitialContext();Service srv = (Service)ctx.lookup("java:comp/env/service/WSHelloService");// Callインスタンス取得Call call = srv.createCall();// CallインスタンスにWebサービスの情報をセットcall.setOperationName( new QName("http://wssample.ise.com", "hello") );call.addParameter("helloRequest", XMLType.XSD_STRING, String.class, ParameterMode.IN);call.setReturnType(XMLType.XSD_STRING);call.setTargetEndpointAddress(“http://localhost:9080/WSSample/services/WSHello”);// Webサービスの実行String[] inputParams = {name};String ret = (String) call.invoke(inputParams);} catch (Exception e){// エラー処理}

Client AppClient AppClient AppClient AppClassClassClassClassServiceServiceServiceServiceInterfaceInterfaceInterfaceInterfaceCall取得CallCallCallCall Web サービス実行Webサービスの情報をセット

JNDI(Service)

Webサービスのサービスの場所、リクエストやレスポンスのデータ型などのインターフェースが可変である場合にDIIの使用を検討します。DII のJAX-RPCアプリケーションの実行ステップは以下3ステップです。

1. WSDL無しのDII Serviceクラスをインスタンス化する。2. Serviceクラスを使用してDII Callオブジェクトのプロキシをインスタンス化し、オペレーションに関する情報などをセットする。3. Callオブジェクトのinvokeメソッドを呼び出す。

67



各プログラミング・モデルの比較

� クライアント・プログラミング・モデルの選択基準コンパイルコンパイルコンパイルコンパイル時時時時にににに既既既既ににににWSDLがががが存在存在存在存在するかするかするかするか（（（（インターフェースインターフェースインターフェースインターフェースがががが決決決決まっているかまっているかまっているかまっているか））））1. 静的静的静的静的スタブスタブスタブスタブ

Tightly bound to the

locator class

Not dynamic

2. 動的動的動的動的プロキシープロキシープロキシープロキシーLoosely bound to the

locator class

Partially dynamic

3. Dynamic InvocationInterface (DII)

Locator class not used

Fully dynamic

パフォーマンスパフォーマンスパフォーマンスパフォーマンスととととポータビリティーポータビリティーポータビリティーポータビリティーののののどちらをどちらをどちらをどちらを重視重視重視重視するかするかするかするかStatic StubとDynamic

Proxyの作成には、Service Endpoint

Interface がコンパイル時に必要各ベンダーのツールが生成するStub（生成コード）は必要ない．JAX-RPCで規定されている標準のAPIを使用．実行時にWebサービスの情報をレジストリーから取得するプログラミングも可能

YESYES NONO

PortaPorta

bilitybilityPerforPerfor

mancemance各ベンダーのツールが生成するStub（生成コード）のメソッドを使用．3種類あるうちどのプログラミングモデルが適切であるか、選択基準を示しているチャートです。

68



例外処理

Webサービスの例外処理について説明します。

69



例外処理

� Webサービスで発生する例外

� システム例外� クライアント側へは以下のいずれかの例外として通知

� RemoteException

� RuntimeException

� SOAPFaultException

� サービス固有の例外(ユーザー定義例外)

� クライアント側へはユーザー定義例外として通知Webサービスサービスサービスサービス・・・・クライアントクライアントクライアントクライアント

システムシステムシステムシステム例外例外例外例外WebサービスサービスサービスサービスString

ユーザーユーザーユーザーユーザー定義例外定義例外定義例外定義例外ユーザーユーザーユーザーユーザー定義例外定義例外定義例外定義例外RemoteExceptionRuntimeException

SOAPFaultException

例外インスタンスの中のメッセージを取り出し可能例外インスタンスの中のメッセージを取り出し可能サービスのシステム例外はRemoteExceptionRuntimeException

SOAPFaultExceptionのいずれかでキャッチサービスのシステム例外はRemoteExceptionRuntimeException

SOAPFaultExceptionのいずれかでキャッチ<wsdl:fault>

マッピングString String

String

Webサービス実行時に発生する例外について説明します。JAX-RPCには、サービス・エンドポイント・インタフェースのメソッドを定義する際には、必ずjava.rmi.RemoteExceptionをスローする必要があるということが明記されています。JSR101/JSR109で定義されているシステム例外として、javax.xml.rpc.JAXRPCExceptionがあります。javax.xml.rpc.JAXRPCExceptionは、JAX-RPCの実行環境に関連するコアAPIからスローされる例外です。Webサービスのリモートメソッド呼び出し、実行中にJAXRPCExceptionがスローされると、これはjava.rmi.RemoteExceptionにマップされます。したがって、クライアント側では、java.rmi.RemoteExceptionとしてキャッチされます。また、アプリケーション例外を定義する必要がある場合、つまりサービス固有の例外をスローすることもできます。このようなWebサービスを開発した場合、サービス･エンドポイント・インタフェースのメソッド定義で、java.rmi.RemoteExceptionに加えて、アプリケーション例外をスローする宣言を追加する必要があります。サービス固有のアプリケーション例外は、java.lang.Exceptionから派生したクラスにしなければなりません。サービス固有のアプリケーション例外は、WSDLには<wsdl:fault>エレメントで表されます。

70



ユーザー定義例外

� アプリケーションからスローするユーザ定義の例外クラス� java.lang.Exceptionクラスを直接的または間接的に継承する

� ただしjava.lang.RuntimeExceptionは継承しない� チェック例外である必要がある� 継承する例外クラスは、コンストラクタの実装に関する制限を満たす必要がある

� 独自のフィールドを定義できる� すべてのフィールドにgetterを定義する必要あり� すべてのフィールドを引数に取るコンストラクタが必要

� コンストラクタの引数の順序は、getterの定義順序と同じ� getter以外のメソッド（setter含め）の作成は任意

� スローされたユーザ定義例外は、SOAPFaultとしてリクエスターに渡されるインターフェース(WSDL)定義の一部として、

ユーザ定義例外を事前に定めておくことが望ましい

ここからは、ユーザ定義例外とシステム例外について解説します。ユーザ定義例外は、ユーザ(＝開発者)が自由に定義することのできる例外です。ユーザ定義例外は、Webサービスのプロバイダーがスローし、最終的にリクエスターに伝搬され、プロバイダー側で何らかの（通常はアプリケーションレベルの）問題が発生したことを伝達するものです。設計のポイントとして、Webサービスでは例外のスタックトレースをリクエスターまで運ぶことができません。よって、リクエスターが「どのような例外」であり「その例外を受け取ったときに何をすればよいか」が明確に把握できるように、事前に分類化した上で定義することが望ましいです。

71



システム例外

�システム例外発生時の対応

� リクエスター側でシステム例外を受け取った場合、基本的に原因は特定できない� キャッチした場合はエンドユーザにエラー画面を返すなど、単一的な対応しか取れない

� 以下のような方法で一部の原因を判別することは可能（ただし、あくまで限定的）� JAX-RPCハンドラーを実装する� Webサービスを呼び出すプログラムの中で例外ストリングの文字列を取得し

(Exception.toString()メソッドなど) 、特定現象を特定できる文字列が含まれているかを判別するシステム例外はプロバイダーのJVMがリクエスターに伝達するもので、アプリケーションを実行できない事態が発生した場合にスローされます。現状ではシステム例外の原因の特定が困難なことから、システム例外を受け取った場合、リクエスターではエンドユーザにエラー画面を返すなど、画一的な対応を行うことが現実解といえます。また、システム間が疎結合である場合にお互いのランタイム例外の詳細情報をスローしても正しく処理される保証はないため、スローする例外に詳細情報は含めないという考え方もあります。

72



（参考）JAX-RPC例外クラス

� java.rmi.RemoteException

� JAX-RPC仕様では、全てのリモートメソッドがRemoteExceptionをスローするよう定めている� ただし、アプリケーションから特定のRemoteExceptionをスローすることはできないため、例外原因を特定することはできない。

� java.lang.RuntimeException

� リクエスター側では、RuntimeExceptionもしくはSOAPFaultExceptionにマップされるため、例外原因を特定することはできない。� javax.xml.SOAPFaultException

� RuntimeExceptionのサブクラス� SOAPFaultExceptionフィールドにセットした値はそのままSOAPFaultメッセージに格納される。� 通常はJAX-RPCハンドラが使用する例外クラスであり、アプリケーションからはスローすべきでない。

JAX-RPCのAPIにてWebサービスを開発する場合、Webサービスからユーザ定義例外以外の例外クラスを明示的にスローすべきではありません。Webサービスでスローすることのできる例外クラスが、そのままリクエスターに伝搬されるわけではないためです。

73



例外処理のアプローチ

� Webサービスでは、4種類の例外クラスがリクエスターにスローされる� RemoteException

� RuntimeException

� SOAPFaultException

� ユーザ定義例外� アプリケーションからスローすべきはユーザ定義例外のみ� その他例外クラスはスローするべきではない

� JAX-RPCランタイムのベンダー間で上記3種類のExceptionクラスの意味や扱いが同じである保証が無いためWebサービスのプロバイダー側では上記4種類の例外クラスがリクエスター側にスローされますが、プロバイダー側のアプリケーションからスローすべきなのはユーザー定義例外のみです。JAX-RPCのランタイムではRemoteException/RuntimeException/SOAPFaultExceptionは、Exceptionクラスの意味や扱いがベンダー間で同一である保証はなく、これらの使用は相互運用性の観点からも避けたほうがよいと言えます。

74



バージョニング

Webサービスのバージョニング方法について説明します。

75



Webサービスの互換性とバージョニング

� Webサービスの変更の影響

� SOAではサービスの再利用性が重視される。一つのサービスが多くのリクエスターから利用される為、サービスインターフェース(WSDL)に変更があった場合の影響範囲は大きいと言える。� Webサービスの変更管理

� 既存リクエスターに影響を与える変更と影響を与えない変更にはどのようなものがあるか？� 既存リクエスターに影響を与える変更を行う場合、既存リクエスターがその変更の影響を受けないようにするにはどうしたらよいか？→バージョニング

SOAではサービスの再利用性が重視されます。それは、一つのサービスが多くのリクエスターから利用されることを意味します。そのため、サービスインターフェース(WSDL)に変更があった場合の影響範囲は大きいと言えます。Webサービスの変更については、既存リクエスターに影響を与える変更と影響を与えない変更があります。ここでは、その変更の例を紹介します。また、既存リクエスターに影響を与える変更を行う場合、既存リクエスターがその変更の影響を受けないように管理する方法として、バージョニングについて紹介します。

76



後方互換性

� あるWebサービスのインターフェースの変更が、それを使用している既存リクエスターにどのような影響を与えるか

� 後方互換性のある変更� 既存リクエスターが影響を受けない変更

� WSDLが変更されても、既存のリクエスターは新しいサービスにそのままアクセスが可能� 後方互換性のない変更

� 既存リクエスターが影響を受ける変更� WSDLが変更されると、既存のリクエスターは新しいサービスにアクセスできない→バージョニングで対応が可能V1.0 リクエスターV1.1 リクエスターV1.0 リクエスター

V1.0 サービスV1.1 サービス WSDLの変更××××

Webサービスという意味での後方互換性とは、「あるWebサービスのインターフェースの変更が、それを使用している既存リクエスターにどのような影響を与えるか」を言います。後方互換性のある変更とは、既存リクエスターが影響を受けない変更を意味し、WSDLが変更されても、既存のリクエスターは新しいサービスにそのままアクセスが可能です。後方互換性のない変更とは、既存リクエスターが影響を受ける変更を意味し、WSDLが変更されると、既存のリクエスターは新しいサービスにアクセスできないため、引き続き、既存リクエスターから古いサービスへのアクセスを可能にするためには、サービス側の変更に対応するための方法が必要になります。これはバージョニングにより対応できます。

77



Webサービスに対する変更管理

１．その変更が後方互換かどうかを評価する

２．後方互換でなければ、古いインターフェースをサポートする

ことが必要かどうかを評価する

３．もし必要であれば、古いインターフェースと新しいインター

フェースの両方を同時にサポートできるように変更管理方法

を決定し、実装する

４．事前定義された猶予期間後、古いインターフェースを廃止す

る

Webサービスのインターフェースの変更については、次のような手順で計画的に対応する必要があります。１．その変更が後方互換かどうかを評価する後方互換性のある変更とない変更の例について、次ページ以降で紹介します。２．後方互換でなければ、古いインターフェースをサポートすることが必要かどうかを評価する新しいサービスへの切り換えや古いサービスの廃止を厳格に行ってしまうと、ビジネス上の影響が生じるかも知れません。これについてはビジネス上の判断が必要です。３．もし必要であれば、古いインターフェースと新しいインターフェースの両方を同時にサポートできるように変更管理方法を決定し、実装するこれは、バージョニングにより対応可能です。４．事前定義された猶予期間後、古いインターフェースを廃止する

78



後方互換性のあるWSDLの変更

� 既存リクエスターに影響を与えずに行える変更の例

� 新しいオペレーションを追加する･･･ (1)

� 新しいインプット・パラメータ（任意選択）を追加する･･･ (2)

� 必須だったインプット・パラメータを任意選択に変更する･･･ (3)

� インタフェースには影響を与えずにサービス実装を変更する� 戻り値のデータ構造にあらかじめxsd:anyTypeを定義しておく（今後、アウトプット・パラメータを追加することがわかっている場合、あらかじめ定義しておくと、後で追加しても既存リクエスターに影響を与えない。）＜オペレーション（実装するメソッド）＞

accountNumber create(name, street, suburb, postcode, state, country) amount deposit(accountNumber, amount) amount withdraw(accountNumber, amount) amount balance(accountNumber)

amount transfer(fromAccountNumber, toAccountNumber, amount)

(1)新しいオペレーションの追加(3)必須だったインプット・パラメータを任意選択に変更（2）新しいインプット・パラメータ（任意選択）の追加

以下のようなWSDL変更の場合には、既存リクエスターに影響を与えず、リクエスターから透過的にサービスを変更できます。・新しいオペレーションを追加する新しいオペレーションが追加されても、既存のリクエスターは使用しないので影響はありません。・新しいインプット・パラメータ（任意選択）を追加する。インプット・パラメータに minOccurs=“0”のパラメータが新規追加された場合は、既存リクエスターに影響を与えません。例） <xsd:element name=“country" type="xsd:string" minOccurs=“0" maxOccurs="2"/> ・必須だったインプット・パラメータを任意選択に変更する古いWSDLでは必須であったインプット・パラメータが minOccurs=“0”に変更された場合は、既存リクエスターに影響を与えません。・インターフェースには影響を与えずにサービス実装を変更する・戻り値のデータ構造にあらかじめxsd:anyTypeを定義しておく（補足）xsd:anyType をあらかじめ定義した場合についてxsd:anyTypeは、あらゆる型を許可する（子要素や属性を持つことができる）データ型です。あるシステムで、バージョン1.0のサービスインタフェースを定義するとき、戻り値としてParam1とParam2を返すサービスがあるとします。現行、バージョン1.0のリクエスターはParam1とParam2を受け取り処理します。しかし、バージョン1.0のサービスは、今後、戻り値としてParam3も返す可能性があります。このとき、WSDLバージョン1.0の定義としてParam1とParam2だけを定義すると、WSDLバージョン1.1でParam3を追加した場合、バージョン1.0のリクエスターではエラーになり使用できません。しかし、WSDLバージョン1.0の定義として、Param1、Param2、およびanyType（Param3のため）を定義しておくと、バージョン1.1のサービスとしてParam1、Param2、Param3の戻り値を持つサービスに変更されたとしても、バージョン1.0のリクエスターはそのまま使用できます。

79



後方互換性のないWSDLの変更

� 既存リクエスターに影響を与える変更の例

� 既存オペレーションを削除する･･･ (1)

� 新しいアウトプット・パラメータを追加する･･･ (2)

� 必須だったアウトプット・パラメータを任意選択に変更する･･･ (2)

� インプット/アウトプット・パラメータのデータ型を変更する･･･ (3)

� 影響を与えるようなビジネス・ルールやビジネス・プロセスを変更する･･･ (4)＜オペレーション（実装するメソッド）＞accountNumber create(name, street, suburb, postcode, state) amount deposit(accountNumber, amount) amount withdraw(accountNumber, amount) amount balance(accountNumber) amount transfer(fromAccountNumber, toAccountNumber, amount)

boolean authorize(accountNumber, amount)

(1)既存のオペレーションの削除(2)・新しいアウトプット・パラメータの追加・必須だったアウトプット・パラメータを任意選択に変更

(3)インプット/アウトプット・パラメータのデータ型の変更例）decimal から float へ(4)影響を与えるようなビジネス・ルールやビジネス・プロセスの変更（オペレーション間に依存関係があり、依存関係の変更がリクエスター側に影響を与える場合）例）認証オペレーション（authorize）の追加自体は後方互換だが、

authorizeオペレーションを実行済みでないと、次のオペレーションを実行できなくなった場合以下のようなWSDL変更の場合には、既存リクエスターに影響を与えます。・既存のオペレーションを削除するオペレーションが削除されると、そのオペレーションを使用している既存リクエスターは動作できなくなります。・新しいアウトプット・パラメータを追加する既存リクエスターは新しいアウトプット・パラメータの存在は知らないので、受信することはできません。・必須だったアウトプット・パラメータを任意選択に変更するもとはminOccurs=“1以上”だったインプット・パラメータが minOccurs=“0”に変更された場合は、既存リクエスターは動作できなくなります。・インプット/アウトプット・パラメータのデータ型を変更するインプット/アウトプット・パラメータのデータ型に対する変更は、ほとんどの場合、後方互換を持ちません。decimal型からfloat型に変更するような単純な変更であっても、既存リクエスターは動作できなくなります。・影響を与えるようなビジネス・ルールやビジネス・プロセスを変更する（オペレーション間に依存関係があり、依存関係の変更がリクエスター側に影響を与える場合）新規にオペレーションが追加されるだけであれば影響はありませんが、オペレーション間の依存関係により、他のオペレーションの前提として新規オペレーションの実行が必要になった場合は、既存リクエスターは新規オペレーションを呼び出すことはないため、動作できなくなります。これらのような変更の場合には、バージョニングなどの措置をとります。

80



バージョニング

�新旧のインターフェースを混在させ、複数のバージョンのサー

ビスを利用可能にする

� 既存のリスエスターがアプリケーションを新しいWebサービスに移行する際に、後方互換性を確保できる期間を設けたい時には、新旧両サービスを共に利用可能にしておく必要がある� 新旧の両方のインターフェースをサポートする方法

� オペレーションによるバージョニング� サービス名によるバージョニング� URLによるバージョニング

古いバージョンのサービスも新しいバージョンのサービスも共に利用可能にしておく必要がある場合、両方のインターフェースをサポートするための方法が必要です。ここで説明するバージョニングの方法では、既存インターフェースを削除することなく、新しいインターフェースをWebサービスに導入することができます。オペレーションによるバージョニング、サービス名によるバージョニング、URLによるバージョニングの３つの方法があります。

81



オペレーションによるバージョニング

�方法

� 古いオペレーションをもとに新しいオペレーションを作成し、両方のオペレーションを同じサービスインターフェース中に保持する。�メリット

� バージョニングの実装は容易。�デメリット

� 新旧バージョンの両方のオペレーションが同じWebサービス内に実装されるため、旧バージョンのオペレーションの削除は容易ではない。� さらにバージョンが追加されると、同じWebサービスの中に膨大な数のオペレーションが存在する可能性がある。� 複数のオペレーションに影響を与える変更（複数のオペレーションで共有されるデータ型への変更など）が必要になると、それぞれのオペレーションの新旧バージョンが存在することになり、メンテナンスが複雑になる可能性がある。（例）旧バージョンのオペレーション

accountNumber create(name, street, suburb, postcode, state) 新バージョンのオペレーションAccount createV2(name, street, suburb, postcode, state, country) 必須の新しいインプットパラメータの追加オペレーションによるバージョニングでは、古いオペレーションをもとに新しいオペレーションを作成し、両方のオペレーションを同じサービスインターフェース中に保持することで、後方互換性を保つことができます。旧バージョンのオペレーションは、利用可能なままにしておきます。これにより、変更は後方互換となり、旧バージョンと新バージョンの両方のオペレーションを共存させることができます。

82



サービス名によるバージョニング

�方法

� 新しい名前でサービスを定義する。� 旧バージョンのサービスに影響を与えることなく、新バージョンのサービス内のオペレーションに対して、新しいあるいは変更された機能を実装する。

�メリット

� Webサービス全体をバージョニングするため、オペレーションによるバージョニングより変更範囲は広いが、旧バージョンの削除は容易。�デメリット

� ツールによって自動生成されるクラスがサービス名を含む場合、リスエスター側のアップデート時の既存コードへの影響が大きくなる可能性がある。(WSDLの<service>の記述例）<wsdl:service name="AccountService">

<wsdl:port binding="impl:AccountSoapBinding" name="AccountService"><wsdlsoap:address location="http://bigbank.com/BigBank/services/AccountService"/>

</wsdl:port></wsdl:service>

<wsdl:service name="AccountServiceV2"> <wsdl:port binding="impl:AccountSoapBindingV2" name="AccountServiceV2">

<wsdlsoap:address location="http://bigbank.com/BigBank/services/AccountServiceV2"/></wsdl:port>

</wsdl:service>

旧バージョンのサービス名新バージョンのサービス名例えば、AccountServiceという、ある既存のWebサービスがある場合、AccountServiceV2という新しいサービスを定義します。そうすると、既存のAccountServiceというサービスに影響を与えることなく、AccountServiceV2でのオペレーションに対して、新しいあるいは変更された機能を実装することができます。

83



URLによるバージョニング

�方法

� 新バージョンを新しいエンドポイントのURLに置く。� 新バージョンには必要な変更が行われた一連のオペレーションがすべて含まれる。� Webサービス名とオペレーション名は旧バージョンと同じまま。

�メリット

� オペレーション名とサービス名に変更が生じないため、リスエスター側のアップデート時の既存コードへの影響は小さい。�デメリット

� コンテキストルートを変更するため、Webサービスプロバイダー側で、バージョン毎にWebモジュールを作成する必要がある。（例）旧バージョンのURLhttp://bigbank.com/BigBank/services/AccountService新バージョンのURL

http://bigbank.com/BigBank1/services/AccountService

例えば、既存のWebサービスが次のURLにある場合、http://bigbank.com/BigBank/services/AccountService新しいバージョンは、既存のWebサービスに影響を与えることなく、次のURLに置くことができます。http://bigbank.com/BigBank1/services/AccountServiceこの新しいバージョンには、必要な変更が行われた一連のオペレーションがすべて含まれています。そのため、リスエスターは、このWebサービスにアクセスするために、どちらか一方のURLのみを使用することができます。このバージョン管理方法では、Webサービスとオペレーションの名前は同じままなので、新しいバージョンを利用できるようにリスエスター側をアップデートするために必要な変更の量は、これまで紹介した2つの方法よりも少なくて済みます。

84



（参考）URLによるバージョニングの実装例

�サンプルの内容

� 旧バージョンのURL

http://localhost:9080/HelloWSWeb/services/HelloWSWeb

� 新バージョンのURL

http://localhost:9080/HelloWSWeb1/services/HelloWSWeb

� サービスの変更内容HelloWSWebサービスのcallNameオペレーションにインプット・パラメータとアウトプット・パラメータとして必須のパラメータ(country）を追加します。・旧バージョンのオペレーション UserInfo callName(NameInfo n, String message)・新バージョンのオペレーション UserInfo callName(NameInfo n, String message, String country)旧バージョンのサービスは、相変わらず旧URLで利用可能であり、新バージョンのサービスは、新URLで利用可能になります。

� テスト環境IBM WebSphere Integration Developer バージョン: 6.0.1.2

URLによるバージョニングの実装方法を説明します。ここで使用したサンプルでは、 HelloWSWebという既存サービスに対し、インプット・パラメータとアウトプット・パラメータとして必須のパラメータを追加して新しいサービスを作成します。旧バージョンのサービスは、相変わらず旧URLで利用可能であり、新バージョンのサービスは、新URLで利用可能になります。

85



手順１．新バージョンのサービスのWSDLの作成・WSDLファイルのバージョン管理・名前空間のバージョン管理２．新サービス・プロバイダー・コンポーネントの作成・Javaパッケージのバージョン管理３．クライアント・アプリケーションのアップデート・Javaパッケージのバージョン管理４．旧バージョンのサービスの廃止旧リクエスター新リクエスター旧バージョンのサービス(HelloWSWeb)新バージョンのサービス(HelloWSWeb1)新リクエスター１，２サービスの作成３アップデート４廃止

１．新バージョンのサービスのWSDLの作成WSDLファイルのバージョン管理方法を説明します。また、URLによるバージョニングを行う際のWSDLの変更内容と名前空間のバージョン管理方法を説明します。２．新サービス・プロバイダー・コンポーネントの作成Javaパッケージのバージョン管理方法を説明します。３．クライアント・アプリケーションのアップデートJavaパッケージのバージョン管理方法を説明します。４．旧バージョンのサービスの廃止

86



１．新バージョンのサービスのWSDLの作成

旧バージョンのWSDLファイル新バージョンのWSDLファイル

� WSDLのバージョン管理の例� WSDLファイルは別のプロジェクトの中に置き、フォルダー名に日付をつけて管理します。

87




� 新バージョンのWSDLファイル・新しい名前空間の作成<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="http://ws.ibm.com/2006/11" xmlns:impl="http://ws.ibm.com/2006/11"

xmlns:intf="http://ws.ibm.com/2006/11" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:types><schema targetNamespace="http://ws.ibm.com/2006/11" xmlns="http://www.w3.org/2001/XMLSchema"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:impl="http://ws.ibm.com/2006/11">：・新しいフィールドの追加

<element name="callName"><complexType><sequence><element name="n" nillable="true" type="impl:NameInfo"/><element name="message" nillable="true" type="xsd:string"/><element name="country" type="xsd:string" minOccurs="1" maxOccurs="1" nillable="false"/></sequence></complexType></element><complexType name="UserInfo"><sequence><element name="string1" nillable="true" type="xsd:string"/><element name="string2" nillable="true" type="xsd:string"/><element name="string3" nillable="true" type="xsd:string"/><element name="string4" type="xsd:string" minOccurs="1" maxOccurs="1" nillable="false"/></sequence></complexType>：

旧バージョンのサービスに対する名前空間を変更して日付のバージョンを持つようにしますインプットパラメータとしてcountryを追加しますアウトプットパラメータを1つ追加します

88




� 新バージョンのWSDLファイル（続き）・エンドポイントの変更<wsdl:service name="HelloWSWebService">

<wsdl:port binding="impl:HelloWSWebSoapBinding" name="HelloWSWeb"><wsdlsoap:address location="http://localhost:9080/HelloWSWeb1/services/HelloWSWeb"/>

</wsdl:port>：新バージョンのサービスにアクセスするためには、リクエスターはこのエンドポイントを使用します

89



(1) 新しいWebモジュール(HelloWSWeb1)のスケルトンの作成Build/wsdl/schema200611下のWSDLファイル(HelloWSWeb.wsdl)に対して、「Web サービス」-「Java beanスケルトンを生成」を選択します。サービス・デプロイメント構成では、「サービス・プロジェクト」にHelloWSWeb1を指定します。

２．新サービス・プロバイダー・コンポーネントの作成

90



２．新サービス・プロバイダー・コンポーネントの作成

Javaパッケージ名に日付を含めるために、以下の定義をします。Webサービス・スケルトンJava Beanの構成では、「名前空間からパッケージへのカスタム・マッピングを定義します」をチェックします。Webサービス・スケルトンのネームスペースからパッケージへのマッピングでは、パッケージ名に日付を含めたものを指定し、WSDLファイルで定義した名前空間にマッピングします。

Javaパッケージ名に日付を含めることで、バージョン管理をしやすくします。この方法によって、バージョン毎の名前空間とJavaパッケージの対応がわかりやすくなります。

91



２．新サービス・プロバイダー・コンポーネントの生成

(2) 新バージョンのビジネスロジックの実装AccountSoapBindingImpl.java（生成されたJava bean Web サービス・スケルトン）に対し、新バージョンのビジネス・ロジックを実装します。

日付を含んだJavaパッケージ名前ページの手順により、Javaパッケージ名は、日付を含んだ名前で作成されています。AccountSoapBindingImpl.java （生成されたJava bean Web サービス・スケルトン）に対し、新バージョンのサービスのビジネス・ロジックを実装します。これで、リクエスターは2つのバージョンのサービスを同時に利用することができます。旧バージョンは相変わらず変更なく利用可能ですが、旧バージョンのサービスは、通常、一定期間後には廃止されるでしょう。リクエスターは、旧バージョンが廃止される前に、新バージョンを使うようにクライアント・アプリケーションをアップデートする必要があります。今回は、旧バージョンのテスト用クライアント・アプリケーションをHelloWSWebCltモジュールの中に作りました。次に、このモジュールをアップデートして新バージョンのサービスを使用できるようにします。

92



３．クライアント・アプリケーションのアップデート

(1) 旧バージョンに対する参照の削除HelloWSWebCltに対するWebデプロイメント記述子を開き、旧バージョンのHelloWSWebService対するサービス参照を削除します。

93




(2) 旧バージョンのサービスに対するリスエスター・コンポーネントの削除右の図で、網掛けしたファイルを削除します。

94




(3) 新バージョンのサービスに対するJavaプロキシーの作成Build/wsdl/schema200611/HelloWSWe

b.wsdlのWSDLファイルに対して、「Web サービス」-「クライアントを生成」を選択します。クライアント環境構成では、「クライアント・プロジェクト」にHelloWSWebCltを指定します。

ここでは、HelloWSWebCltプロジェクトの中に新バージョンのサービスに対するWebサービス・プロキシーを作成します。

95




Javaパッケージ名に日付を含めるために、以下の定義をします。Webサービス・プロキシー・ページでは、「ネームスペースからパッケージへのカスタム・マッピングを定義します」をチェックします。Webサービス・クライアントのネームスペースからパッケージへのマッピングでは、パッケージ名に日付を含めたものを指定し、WSDLファイルで定義した名前空間にマッピングします。

96




(4) クライアントアプリケーションの変更・新しいパッケージ名のWebサービスのプロキシー・クラス名を使用するように変更します。・新しいインターフェース（新しいインプット／アウトプットパラメーターの追加）に対応するように変更します。

日付を含んだJavaパッケージ名

前ページの手順により、クライアントのJavaパッケージ名は、日付を含んだ名前で作成されています。このあとは、生成された新しいWebサービス・プロキシーを使用するようにクライアント・アプリケーションを変更します。また、クライアント・アプリケーションには、新しいインターフェースを使用するための変更も必要です。

97



４．旧バージョンのサービスの廃止

(1) サービスを使用不可にするWebデプロイメント記述子の中のサーブレット定義をコメントアウトします。

(2) サービスを完全に削除する右の図で、網掛けしたファイルを削除します。

サービスを廃止する方法はいくつかあります。ここでは、デプロイメント記述子(HelloWSWeb/WebContent/WEB-INF/web.xml)の中のサーブレット定義をコメントアウトしています。もし、Webモジュールが他のサービスを含んでいる場合には、それらのサービスに必要なファイルやデプロイメント記述子のエントリーなどを削除しないように注意する必要があります。

98



まとめ

� WS-I

� 相互運用性を保つためにはWS-Iで提供されているプロファイルに準拠する必要があります� RAD/WID/ASTなどのWS-I準拠テスト・ツールを有効に使用しましょう

� Webサービス開発� Webサービスの制約、JAX-RPCの制約についてはあらかじめ調査が必要です。� ボトムアップでサービス開発を行う場合、JAX-RPCのデータ・マッピングには注意しましょう

� 例外処理� Webサービスでスローすべき例外はユーザー定義例外のみです。あらかじめ

WSDLで定義しておきましょう� バージョニング

� SOAでは、Webサービスの変更を管理するための手法と指針を決めることは重要です。こうした手法や指針は、市場のニーズへの即応性を維持するためにサービスの変更を行う際、変更がサービスのプロバイダーとコンシューマー双方に及ぼす影響を最小限にとどめるのに役立ちます。

99



参考文献

� IBM Redbooks 「Web Services Handbook for WebSphere Application Server 6.1」http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247257.html?OpenDocument

� Standards and Web services

http://www-128.ibm.com/developerworks/webservices/standards/

� xsd:any：教訓話http://www-06.ibm.com/jp/developerworks/xml/060113/j_ws-tip-xsdcaution.shtml

� SOAPそしてJAX-RPCと共にコレクション・タイプを使用http://www-06.ibm.com/jp/developerworks/webservices/040723/j_ws-tip-coding.html

� Javaコーディング規約とRoundtrip

http://www-06.ibm.com/jp/developerworks/webservices/040702/j_ws-tip-roundtrip2.html

� Webサービスに後方互換性を持たせて進むhttp://www-06.ibm.com/jp/developerworks/webservices/060616/j_ws-soa-backcomp.shtml

� Webサービスに後方互換性のあるマイナーチェンジhttp://www-06.ibm.com/jp/developerworks/webservices/050128/j_ws-backward.html

� xsd:choiceの代わりにpolymorphismを使うhttp://www-06.ibm.com/jp/developerworks/webservices/051104/j_ws-tip-xsdchoice.shtml

� XML Schemaでのヌルの表現http://www-06.ibm.com/jp/developerworks/webservices/050902/j_ws-tip-null.shtml

100



（補足資料）XMLテクノロジー

� XMLの特徴�XMLスキーマ�名前空間�XMLスキーマの構造

101



XMLの特徴

� XMLには以下の特徴があります� 構造化データを記述するテキスト形式のマークアップ言語� マークアップ言語を定義するメタ言語

� XMLのスキーマ記述� スキーマは，使用する要素や属性の名前やデータ型，要素の構造を表す内容モデルを規定� DTD や，XMLスキーマなどのスキーマ定義言語で記述

� XMLの例XMLを使用する場合，まずスキーマ (XMLデータで使用するタグ・セット) を設計し，スキーマで定めたルールに従って要素や属性を記述したXML文書を作成しますXMLを使用する場合，まずスキーマ (XMLデータで使用するタグ・セット) を設計し，スキーマで定めたルールに従って要素や属性を記述したXML文書を作成します

<?xml version='1.0' encoding='UTF-8' ?>

<member id=“01">

<name>山田太郎</name>

<age>24</age>

</member>

XML宣言XMLインスタンス member

(id=01)

name age山田太郎 24

XML文書スキーマXMLインスタンス要素

スキーマ設計 XML文書作成

XMLには言語として以下の２つの特徴があります。•構造化データを記述するテキスト形式のマークアップ言語•マークアップ言語を定義するメタ言語*マークアップ言語：タグを使用してデータを記述する言語*メタ言語：言語を定義する言語XMLを使用する場合、まずスキーマ（XMLで使用するタグ・セット）を設計し、スキーマで定めたルールに従って要素や属性を記述したXML文書を作成します。XMLのスキーマ記述では、使用する要素や属性の名前やデータ型、要素の構造を表す内容モデルを規定します。スキーマ記述はXML1.0で定義しているDTD(Document Type Definition)や、XMLスキーマなどのスキーマ定義言語で記述します。XMLで記述するデータ全体をXML文書と呼びます。XML文書はXML宣言、DTD、XMLインスタンスの３つで構成されており、XML宣言、DTDの記述は任意です。XMLインスタンスは、要素の単位で構成され、全体として１つの木構造で表現されます。XMLでは大文字・小文字を区別します。また、開始タグと終了タグの対応がとれており、親子関係にある要素のタグは入れ子になっている必要があります。

102



XMLスキーマ

� XMLスキーマ(XML Schema)

� XML文書の構造や内容をXMLで記述� タグの構造を定義� データ型を指定可能

� XMLのスキーマ言語として2001年にW3Cより勧告� http://www.w3.org/XML/Schema

� XMLスキーマの特徴� スキーマ自身がXMLデータとして表記

� XSLTによるスキーマの構造変換� DOMやSAXを使用してスキーマへの直接アクセスが可能

� 名前空間の使用� 要素の内容や属性値のデータ型を詳細に指定することができる XML文書スキーマ

XMLインスタンス

<xsd:schema ….>

<xsd:element name="A" type="…"/>

<xsd:element name="B">

<xsd:complexType>・・・・・<xsd:attribute …/>

</xsd:complexType>

</xsd:element>

</xsd:schema>

要素宣言要素宣言複合型定義属性宣言最上位要素XMLスキーマの構造

XMLスキーマとは、DTDと同様にXMLインスタンスの持つデータの構造・型を定義するためのスキーマ言語の一種です。DTD は、XML 文書の定義をあたえますが、DTD 自体は XML とは異なる文法に従っています。そのため、XML の書き方とは別に、DTD の書き方を学ばなければなりません。これに対して、XML スキーマは、それ自身が XML ファイルになっています。そのため、XML の書き方を知っていれば、容易に XML スキーマも書けるようになります。また、プログラミングの効率という点からも、XML スキーマが XML になっているということは重要です。つまり、文法チェックをするときに、XML用とは別のプログラムを用意する必要がなくなるからです。また、XSLTでスキーマの構造変換をしたり、DOMやSAXを使って直接スキーマにアクセスするプログラムの作成が可能になりました。スキーマ言語は多くの場合、妥当性検証の目的で使用されます。例えば、XML文書をスキーマに対して妥当性を検証することにより、文書の内容が処理する側の規則に沿った形で受け取られ、処理を単純化することができます。XMLスキーマは、XMLに対するスキーマ言語（XMLの文書構造定義）であり、2001年5月2日にW3Cから勧告が発表されました。Part 0: Primer、Part 1: Structures、Part 2: Datatypesの３部構成となっており、Part 0はチュートリアル、Part 1は全体の構文に関する定義、Part 2がデータ型に関する定義となっています。

103



XML名前空間

� XML名前空間� XML文書で利用する要素や属性をどのスキーマに属するか指定したもの� 様々なスキーマで定義された要素や属性を混在させて使用可能

� 名前空間が異なれば要素名が同じでも別扱い� 名前空間の宣言

� 別名として名前空間のプレフィックスを使用� 名前空間の使用

� 要素や属性が名前空間に属することを表すには、要素名、属性名をプレフィックスで修飾する� 使用例

他のスキーマで定義された要素を使用できる<要素 xmlns : prefix ="URIで表現された名前空間名"> ：通常の名前空間の宣言

prefix :要素名：名前空間接頭辞で修飾する。<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 名前空間宣言名前空間プレフィックス識別子（名前空間URI）名前空間宣言の開始「要素名の先頭にxsd:と付いたら、

http://www.w3.org/2001/XMLSchemaで定義された要素である」という宣言XML Schemaで定義されているschema要素XML名前空間 (Namespaces in XML) は，XML文書で利用する要素や属性がどのスキーマに属するかを指定できるようにしたものです。これにより，XML文書において，様々なスキーマで定義された要素や属性を混在させて使うことが可能となりました。XMLでは、それぞれの業務や分野独自の情報をタグ使って、データの構造やデータの型を定義する。しかし、1つのXML文書内に同じ名前の要素や属性が、異なる意味で定義されていると混乱を招いてしまう可能性がある。名前空間とは、要素と属性をある名前に属するように定義をして、こうした名前の衝突を防ぐためのものです。例えば，企業と社員の両方のスキーマに，phone(電話番号)という要素が定義されている場合でも，企業や社員のスキーマが定義する要素と属性の集合を別々の名前空間として認識し，phone要素がどの名前空間に属するかを指定することによって，同じXML文書で，企業と社員のスキーマで定義された要素や属性を使い分けることができます。

104



XMLスキーマと名前空間

� XMLスキーマの名前空間指定方法� targetNamespace属性

� このスキーマによって定義したい名前空間� スキーマ内で定義された要素や属性は指定した名前空間に属する� XMLスキーマの最上位要素のみで定義される属性

<xsd:schema xmlns:xsd="http://www.w3c.org/2001/XMLSchema"

targetNamespace="対象名前空間対象名前空間対象名前空間対象名前空間URI"

xmlns:名前空間接頭辞="対象名前空間URI">スキーマ・コンポーネントを使って記述する</xsd:schema>

XMLスキーマでは、スキーマ自身が名前空間をサポートする仕組みを提供しています。targetNamespace属性でスキーマ自身の名前空間を定義することができます。スキーマ内で定義された要素や属性は指定した名前空間に属することになります。名前空間を使用してスキーマを定義すると、スキーマ定義を再利用することによって、無駄を省いた効率のよいスキーマ構築が可能になります。名前空間で指定するURIは、スキーマの一意性を示すもので、スキーマを定義したファイルの置き場所となっている必然性はありません。

105



いろいろな名前空間

定義名前空間URI接頭辞XSD で定義のインスタンス名前空間http://www.w3.org/2000/10/XMLSchema-instancexsi

XSD で定義のスキーマ名前空間http://www.w3.org/2000/10/XMLSchemaxsd

SOAP 1.1 で定義のエンベロップ名前空間http://schemas.xmlsoap.org/soap/envelope/soapenv

SOAP 1.1 で定義のエンコーディング名前空間http://schemas.xmlsoap.org/soap/encoding/soapenc

WSDL SOAP バインディングのためのWSDL 名前空間http://schemas.xmlsoap.org/wsdl/soap/ soap

WSDL フレームワークのためのWSDL 名前空間http://schemas.xmlsoap.org/wsdl/ wsdl

� 既に各団体で定義されている名前空間� 新たに要素定義を行わずに、名前空間に定義されている要素を使用することができる

106



XMLスキーマの構造 -スキーマ・コンポーネント-

� XMLスキーマの構造� XMLスキーマは、要素や属性の名前と構造を定義するスキーマ・コンポーネントの組み合わせで構成される� 最上位要素「xsd:schema」の中にスキーマ・コンポーネントを含める� スキーマ・コンポーネントは１３種類あり、これらを使ってXMLインスタンスのスキーマ定義を行う� すべてのスキーマ・コンポーネントは名前空間「http://www.w3c.org/2001/XMLSchema」に属する

スキーマを使う人およびアプリケーションへの情報注釈記法に名前をつける定義記法宣言要素や属性の値が一意になるように指定したり、他の要素や属性と同じ値を同じになるように定義一意性制約定義外から参照可能にするための名前を定義属性グループ定義要素が持つ属性の参照属性使用任意の要素や属性の定義ワイルドカード外から参照可能にするために名前をつける定義モデルグループ定義要素の出現の仕方を指定モデルグループ内容モデルの構成や、それぞれの要素の出現回数を定義パーティクル要素や属性を持つ型を定義する複合型定義テキストのみを含むデータ型を指定単純型定義属性の名前を宣言して、どの型定義を使用するかを指定属性宣言要素の名前を宣言して、どの型定義を使用するかを指定要素型宣言説明スキーマ・コンポーネント名<xsd:schema xmlns:xsd="http://www.w3c.org/2001/XMLSchema">スキーマ・コンポーネントを使って記述</xsd:schema>

XMLスキーマは、要素や属性の名前と構造を定義するスキーマ・コンポーネント（schema component）の組み合わせで構成されます。スキーマ・コンポーネントは１３種類あり、これらを使ってXMLインスタンスのスキーマ定義を行います。スキーマ・コンポーネントのXML表現は，XMLスキーマの名前空間"http://www.w3.org/2001/XMLSchema"で定義されています。スキーマ文書の最上位要素は，schema要素になります。schema要素でXMLスキーマの名前空間を宣言します。

107



XMLスキーマの構造 -要素宣言-

� 要素宣言 <xsd:element>

� 要素の名前とデータ型を宣言する� 要素の構造定義（データ型定義）

� 単純型定義(Simple Type)� テキストのみを持つデータ型を定義� 要素宣言、属性宣言に使用

� 複合型定義(Complex Type)� テキスト以外に子要素や属性を持つ<xsd:simpleType name="型の名前">単純型の派生定義

</xsd:simpleType>

<xsd:complexType name="型の名前">複合型定義</xsd:complexType>

<xsd:schema ….>

<xsd:element name="A" type="…"/>

<xsd:element name="B">

<xsd:complexType>・・・・・<xsd:attribute …/>

</xsd:complexType>

</xsd:element>

</xsd:schema>

要素宣言要素宣言複合型定義属性宣言最上位要素XMLスキーマの基本的な構造

XMLスキーマの基本的な構造は、要素や属性の宣言とデータ型で定義されます。要素宣言は、要素の名前とその要素のデータ型を定義します。要素を記述する場合には<xsd:element>を用います。要素のデータ型は単純型定義と複合型定義の2種類があります。単純型定義（Simple Type）は内容としてテキストのみを持つデータ型を定義します。要素宣言や属性宣言に使用されます。テキストのデータ型はXMLスキーマで定義されている組み込みデータ型と、ユーザー派生データ型の2種類があります。複合型定義（Complex Type）は内容としてテキスト以外にも子要素や属性が定義されます。

108



XMLスキーマの構造 -要素宣言-

� グローバル宣言とローカル宣言<xsd:schema>

<xsd:element name="pubDate" type="xsd:string" />

<xsd:element name="book">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="title" type="xsd:string" />

<xsd:element name="author" type="xsd:string" />

<xsd:element ref="pubDate" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:complexType name="user_model">

<xsd:sequence>

<xsd:element name="first_name" type="xsd:string" />

<xsd:element name="last_name" type="xsd:string />

</xsd:sequence>

</xsd:complexType>

<xsd:element name="user" type="user_model">

</xsd:schema>

グローバル宣言複合型モデルにname属性を使用しない場合は、定義された要素内のみ参照可能既に定義済みの要素の参照には<xsd:element:ref="要素">を使用要素宣言の外部にある複合型モデルは、name属性の値を使用して要素を参照ローカル宣言

スキーマ文書のルート要素はxsd:shemaであり、その直下に宣言される宣言はグローバルなものと位置づけされ、スキーマ文書全体を通して利用することができます。利用方法は、明示的にname="要素名"で名前をつけて、それを参照するという方法です。複合型定義では、要素をローカルなものとして宣言することができますが、この場合、宣言の再利用（他からの参照）はできません。このように要素宣言にはグローバル宣言とローカル宣言があります。【グローバル宣言】•スキーマ文書のルートの直下にて宣言される•スキーマ文書全体から参照が可能•ref属性を持たない【ローカル宣言】•型定義や、モデル・グループ、属性グループ定義の内容で宣言される要素•複合型モデル(xsd:complexType)内のみ参照可能

109



XMLスキーマにおける型定義

� 組み込みデータ型（Built-in types ）� すべてSimple Type

� built-in primitive types

� built-in derived types

� ur types

� ユーザー派生型（User derived types）� SimpleType

� <simpleType>タグで定義� ComplexType

� <complexType>タグで定義

XML Schema Part 2: Datatypes (WSD)では、XML文書において標準として使用可能な組み込みデータ型（Built-in Type)と呼ばれるデータの型の定義を詳細に行っています。組み込みデータ型はすべて単純型（Simple Type）であり、Primitive Typeと、Primitive Typeを元に値の範囲を限定するなどの制限を行ったDerived Typeに分類されます。なお、XMLスキーマにおける型定義の階層のルート

にあたる特殊な型としてur typesが定義されています。組み込みデータ型のうち、Primitive Typeには以下のものがあります：string, boolean, decimal, float, double duration, dateTime, time, date,

gYearMonth, gYear, gMonthDay, gDay, gMonth, hexBinary, base64Binary,

anyURI, QName, NOTATIONまた、組み込みデータ型のほか、ユーザー自身が<simpleType>あるいは<complexType>タグを利用して既存の型を拡張したユーザー定義型のデータを利用することができます。

110



XMLスキーマの構造 -型の派生-

� 組み込データ型を拡張した新しいデータ型の任意定義や、既存のデータ型を派生させることができる� データ型の派生方法には以下の2通り

� 制限(restriction)：データ型に制約をつけて適用範囲を制限� 拡張(extension)：複合型に新たに子要素や属性を追加

� 制約ファセット� データ型に付ける制約

値の小数部の桁数の最大値xsd:fractionDigits

値の桁数の最大値xsd:totalDigits

値の範囲の最小値（指定値を含まない）xsd:minExclusive

値の範囲の最小値（指定を含む）xsd:minInclusive

値の範囲の最大値（指定値を含まない）xsd:maxExclusive

値の範囲の最大値（指定値を含む）xsd:maxInclusive

値の空白記号の保持を指定するxsd:whiteSpace

値の候補xsd:enumeration

値を正規表現にしたがって指定するxsd:pattern

値の長さの最大値xsd:maxLength

値の長さの最小値xsd:minLength

値の長さxsd:length

説明制約ファセット

XMLスキーマでは、あらかじめ組み込みデータ型が用意されていますが、その他にも、新しいデータ型を任意に定義することや、既存のデータ型を派生させることが可能です。XMLスキーマではデータ型の派生方法に制限と拡張の2通りがあります。•制限(restriction)：データ型に制約をつけて適用範囲を制限する•拡張(extension)：複合型の内容に新たに子要素や属性を追加するこの2通りの派生では、制限は単純型定義によるデータ型の制限に使われ、拡張は複合型による型の制限と拡張に使用されます。単純型定義によるデータ制限とは、あらかじめ用意されたデータ型をもとに制約を付け加える機能になります。ある型から別の型を派生することができますが、これをファセット(facet)と呼び、単純型定義によるデータ型の制限は、この制約ファセットを使用して定義します。

111



XMLスキーマの構造 -型の派生の例①-

� 単純型定義によるデータ型の制限<xsd:simpleType name="ユーザー派生データ型の名前">

<xsd:restriction base="基準とするデータ型を参照する修飾名">制約ファセット</xsd:restriction>

</xsd:simpleType>

<xsd:element name="firstname"><xsd:simpleType>

<xsd:restriction base="xsd:string"><xsd:minLength value="5"/><xsd:maxLength value="10"/>

</xsd:restriction></xsd:simpleType>

</xsd:element>

<xsd:element name="product_code"><xsd:simpleType>

<xsd:restriction base="xsd:string"><xsd:pattern value="製品番号¥d(3)-¥d(4)"/>

</xsd:restriction></xsd:simpleType>

</xsd:element>単純型定義におけるデータ型の派生の例を示します。<xsd:restriction>を使用して組み込みデータ型に制限を付けた例となります。

112



XMLスキーマの構造 -型の派生の例②-

� 複合型定義による型の制限と拡張� 複合型定義の拡張派生の例

<xsd:complexType name="sendto"><xsd:sequence>

<xsd:element name="name" type="xsd:string"/><xsd:element name="address" type="xsd:string"/>

</xsd:sequence></xsd:complexType>

<xsd:complexType name="us-sendto"><xsd:complexContent>

<xsd:extension base="sendto"><xsd:sequence>

<xsd:element name="state" type="xsd:string"/></xsd:sequence>

</xsd:extension></xsd:complexContent>

</xsd:complexType>

複合型定義におけるデータ型の派生の例を示します。複合型の派生ではあらかじめ宣言した複合型から拡張を行うことができます。複合型から派生させる場合には、<xsd:complexContent>を型定義から派生させて、属性を含める場合は、<xsd:extension>を、制限させる場合には、<xsd:restriction>を使用します。

113



XMLスキーマの構造 -内容モデル-

� 内容モデル� 複合型定義において下位要素の出現回数や出現順序を規定するもの

� パーティクル� 内容モデルを構築する際にまとまりとなる構成要素

要素参照宣言xsd:element

任意の要素が出現可xsd:any

モデルグループ参照xsd:group

順不同に出現させる指定xsd:all

いずれか一つを出現させる指定xsd:choice

順番に出現させる指定xsd:sequence

説明XMLスキーマのパーティクル

要素の開始タグと終了タグの間に現れる下位の要素やテキストの出現順序/出現回数を規定するものを内容モデルと呼びます。XMLスキーマでは内容モデルを構築する際に、まとまりとなる構成要素をパーティクルと呼びます。画面の表にXMLスキーマのパーティクルを示します。

114



XMLスキーマの構造 -パーティクルの例-

� 要素の出現回数の指定<xsd:element ref="要素名" minOccurs="出現最低回数" maxOccurs="出現最高回数" />

� 出現場所：xsd:complexTypeの子孫で、xsd:sequenceかxsd:choiceかxsd:allの子要素� minOccurs属性とmaxOccurs属性のデフォルトは１� 無制限である場合にはmaxOccurs="unbound"とする� ref属性による要素の参照ではなく、name属性を使ってローカル要素宣言をして書くこともできる

� 要素を順番に出現させる指定<xsd:sequence minOccurs="出現最低回数" maxOccurs="出現最高回数" >

xsd:element,xsd:sequence,xsd:choice,xsd:any,xsd:groupを出現する順番に記述</xsd:sequence>

� 出現場所：xsd:complexTypeの子孫で、xsd:sequenceかxsd:choiceかxsd:allの子要素� minOccurs属性とmaxOccurs属性のデフォルトは１

Web...

Documents

Transcript of Web...