このプレゼンテーションは情報提供を唯一の目的と...

このプレゼンテーションは情報提供を唯一の目的とするものであり、いかなる契約または協定にも組み込むことはできません。

本書は情報提供のみを目的としています。

本書は、マテリアルやコード、機能の提供を確約するものではなく、

また、購買を決定する際の判断材料とはなりえません。

本書に記載されている機能の開発、リリースおよび時期については、

弊社の裁量により決定いたします。

本書には、書式、ソフトウェアまたは印刷物のいかんによらず、

オラクルが独占的に所有する独自の情報が含まれています。

本書とここに含まれる情報は、オラクルの事前の同意を得ることなく、

オラクル以外の者に開示、複写、複製または配布することが禁じられて

います。本書は、ライセンス契約の一部をなすものではなく、

オラクル、その子会社または関連会社とのいかなる契約上の

合意事項にも組み込まれるものではありません。

Eric RajkovicPrincipal Member of Technical Staff OC4JおよびWebサービス

Tugdual GrallPrincipal Product Manager OC4JおよびWebサービス

このプレゼンテーションは情報提供を唯一の目的とするものであり、いかなる契約または協定にも組み込むことはできません。

J2EE™と.NET Webサービス間に

おける真の相互運用性：

開発者向けの実用的アドバイス

Oracle Fusion Middleware

グリッド・コンピューティング

エンタープライズ・アプリケーション・サーバー

開発ツールコンポジションとプロセス・オーケストレーション

情報の集計と分析

セキュリティ

管理

コラボレーティブ・エンタープライズ・ポータル

モデル化、開発ツール、フレームワーク

BPM、ESB、B2B

ポータル、コラボレーション、モバイル、デスクトップ、検索

ETL、ハブ、コンテンツ管理、BI、BAM システム管理

ID、セキュリティ管理J2EE、WS-*、イベント、メタデータ、レジストリ

クラスタ、リソース管理、高可用性

議題（対象セクションをハイライト）

問題のある領域

相互運用性に関する問題の解決

サーバーの変更

WSDLの変更

クライアントの変更

ベスト・プラクティス – トップダウン設計

3大考慮事項

2個のSOAPスタック？N個のSOAPスタック

Java

.NET

ApacheSOAP

ApacheAxis 1.1/1.2

OracleJAX-RPC

SunJAX-RPC

BEAJAX-RPC

IBMJAX-RPC

MicrosoftSOAP

Toolkit 3. 0

.NET Framework

1.1Indigo

.NET Framework

2.0W

SE

1.1W

SE

2.0

WS

E 3.0

何度も繰り返される2つのシナリオ

開発者による開発者によるJavaJavaクラスの構築クラスの構築開発者による開発者によるC#C#クラスの構築クラスの構築

クラスをボトムアップし、クラスをボトムアップし、WebWebサービスとして公開サービスとして公開

クラスをボトムアップし、クラスをボトムアップし、WebWebサービスとして公開サービスとして公開

..NETNETからからWSDLWSDLを参照を参照 JavaJavaツールからツールからWSDLWSDLを参照を参照

C#C#クライアントの構築クライアントの構築 JavaJavaクライアントの構築クライアントの構築

クライアントの実行クライアントの実行クライアントの実行クライアントの実行

エラーエラーエラーエラー

業界に支持されたメカニズムによる問題の解決とさまざまな成功

•WS-I•プロファイル（BP、BSP、AP）•サンプル・アプリケーション

•テスト

•SOAPBuilders•WSDL 1.1•SOAP 1.1•RPC/encoded、Doc/literal

WS-Iプロファイル

仕様への

リンク

表記規則と

ベスト・

プラクティス

問題

• 従来のSOAPスタックと最新のSOAPスタック

間での相互運用性の確立

• WS-I以前のスタックとWS-I以降のスタックの

両方に相互運用性の問題あり

• WS-Iへの準拠自体が相互運用性を保証する

わけではない

• 各種のMicrosoftスタックとJavaスタックにより、シリアライズとWSDL生成に特異性が生まれる

はじめに、毎回の実行時に発生するプロセスを理解する

クライアントサービス

C#

XML

HTTP

Java

XML

HTTP

アプリケーション・コード

.NET Frameworkアプリケーション・コード

JAX-RPCWSDL

リクエスト

レスポンス

リクエスト

レスポンス

デシリアライズ

シリアライズ

デシリアライズシ

リアライズ

メッセージ形式

• 次に、両方の世界で使用されるメッセージ形式を理解する

Document IiteralDocument Iiteral（（WSWS--II方式、方式、

別名ラップ・別名ラップ・スタイル）スタイル）

Document LiteralDocument Literal（（例：ベア・スタイル、例：ベア・スタイル、

AxisAxisを使用したを使用した

メッセージ･スタイルメッセージ･スタイルと同様）と同様）

RPC LiteralRPC Literal（（ラップされたラップされた

ドキュメント・リテラルのドキュメント・リテラルのミラー・アナログ）ミラー・アナログ）

RPC EncodedRPC Encoded（（SOAPSOAPエンコーディング・エンコーディング・

ルールのルールの第第55章に限定）章に限定）

RPC EncodedRPC Encoded、、型指定なし型指定なし（例：（例：MSFTMSFT））

RPC EncodedRPC Encoded、、独自仕様の拡張独自仕様の拡張（例：コレクション）（例：コレクション）

を含むを含む

メッセージ形式の調査

• 2005年XMethodsより（http://www.xmethods.com)

Doc/LiteralRPC/Encoded混合

.NETJavaWindowsそのほか

出典：http://www.xmethods.net/inspection.wsil - 2005年5月13日金曜日

最後に、相互運用性の問題を解決するためのアプローチを確認する

• 開始前の問題解決

• 相互運用性を念頭に置いて開始

• 機能する既知のパターンにしたがう

• トップダウン・アプローチ、またはよく知られたボトム・アップ・アプローチ

• 事後の問題解決

• サービス実装の変更

• サービスの配置オプションの変更

• 公開されたWSDLの変更[サーバー側]• WSDLのローカル・コピーの編集[クライアントの回避策]• 生成されたコードの編集[クライアント・ハック]





WSDLの変更



3大考慮事項

サーバーを変更する理由

• メッセージ形式が一致しない• Doc/LiteralとRPC/Encodedの通信

• RPC/Encoded（型指定なし）とRPC/Encodedの通信

• ソリューション：サーバー構成を変更する

• データ型がサポートされていない• .NETデータセット、Java WebRowSets• Javaコレクション

• 配列内のNillable値• ソリューション：サーバー実装を変更し、両方の実装で

サポートされる型を使用

• 問題のあるWSDL生成

• SOAPアクション

• ソリューション：サーバー実装を変更し、生成済みWSDLを修正

単純なシナリオ：Add Serviceの経過バージョニング

C#およびJavaから3つのエンドポイントを呼び出すと、その結果は？

1) 最初のサービスから両方

のクライアントを生成

2) 両方のクライアントから

各サービスを順番に呼出し

C# Mathクライアント

Java Mathクライアント

D E M O N S T R A T I O N

　

Use case #1

サーバーの変更から得られる教訓

• 特定のクライアントが最適に機能するのは1つのサービス

に対してのみ

• サーバーとクライアントの両方のバージョニングを計画すること

• それぞれを比較できるように、WSDLをバージョニングすること

• 交換可能なサービスにより、WSDLに定義された同一の

コントラクトを実装する必要がある

• 公開サービスの変更は、既存のクライアントに問題を発生させやすい

• プラットフォームによってデシリアライズの問題の処理方法が異なる[MathService2.asmx]

• SOAPActionに空値（""）を使用する





WSDLの変更



3大考慮事項

WSDLを変更する理由

• WSDLは、一般的にメッセージ交換やシリアライズ

に依存しない

• 準拠することが両側から暗黙的に合意されている契約である

• 結果的に、通常は適切なクライアントの生成に使用される

• 受信されたメッセージがWSDLに一致しない場合、

不正なクライアントが生成される

• ソリューション：WSDLの修正

一般的なWSDL編集

• xsd:anyまたはxsd:anyType• インポートにおけるロケーションの欠落

• 名前空間の接頭辞の未指定

• 同一の名前空間に対する異なる接頭辞の再利用

• xsd:booleanまたはsoapenc:boolean• SOAP配列

• maxOccurs="unbounded" （"*"ではない）

• minOccurs="0" （配列を空にできない場合を除く）

WSDLエラーの診断

• SOAPScopeなどの

ツールを使用

例1：XMLスキーマ -xsd:anyワイルドカード

XMLスキーマの作成および生成に関する一般的な問題

• スキーマ内でタイプとしてanyを使用<element name="QuotesResponse“ type="any"/>

• メッセージの一部で、タイプとしてanyを使用<message name="QuotesResponse">

<part name="result" type="xsd:any"/></message>

• 要素属性で、名前付き要素としてanyを使用<message name="QuotesResponse">

<part name="result" element="xsd:any"/></message>

例1：XMLスキーマ -xsd:anyワイルドカードWSDLの変更によりこれを解決する2つの方法

• 正しいXMLタイプであるanyTypeを使用

<element name="QuotesResponse" type="anyType"/><message name="QuotesResponse">

<part name="result" type="xsd:anyType"/></message>

• 複合型で、名前付き要素のかわりにワイルドカードとしてanyを使用

<element name=“result” nillable=true” minOccurs=“0”…><complexType><sequence><any/>

</sequence></complexType>

例2：XMLスキーマ -インポートとロケーション

別のスキーマの参照方法として頻繁に使用される

• xsd:importからロケーション属性が不足している例<schema xmlns="http://www.w3.org/2001/XMLSchema"xmlns:apachesoap="http://xml.apache.org/xml-soap"targetNamespace="http://message.samples"elementFormDefault="qualified"><import namespace="http://xml.apache.org/xml-soap"/><element name="elem" type="apachesoap:Element" />

</schema>

• WSDLプロセッサは、名前空間が誤っていることを認識

例2：XMLスキーマ -インポートとロケーション

WSDLの変更によりこれを解決する2つの方法

• スキーマの場所が分かっている場合はロケーションを追加<schema xmlns="http://www.w3.org/2001/XMLSchema"xmlns:apachesoap="http://xml.apache.org/xml-soap"targetNamespace="http://message.samples"elementFormDefault="qualified"><import namespace="http://xml.apache.org/xml-soap"

location="http://xml.apache.org/some-url.xsd" /><element name="elem" type="apachesoap:Element" /></schema>

• そうでない場合、インポートを削除して代わりのタイプを使用<element name="elem" type=“anyType" />


　

Java WSに対する.NETクライアントの構築

WSDL編集から得られた教訓

• 名前空間のスコープ･ルールを理解する

• 名前空間のコピーに注意すること

• 複数のツールキットを使用してWSDLを検証する

• 1つのツールでは相互運用性は保証されない

• XMLSpyでは不十分

• スキーマのバージョンに注意する

• 常に2001を使用するが、1999も参照すること

• WSDL仕様は10/2000を使用するので、これを使用しないこと

• XMLスキーマ・タイプの使用方法に注意する

• 選択、グループ、再定義・・・





WSDLの変更



3大考慮事項

クライアントを変更する理由

• クライアント生成が失敗する

• クライアント生成は成功したが、実行時に失敗する

• サーバー実装にアクセスできない

• サーバーWSDLにアクセスできない

• ソリューション：

• WSDLをローカルで変更し、クライアントを再生成する

• クライアントを変更する

例：NULLが返される

・・・なぜか？

• C#クライアントの生成

• クライアント・コードの検査

• プログラムの出力

• リクエストとレスポンスの取得

• レスポンスのペイロードの確認

• WSDLとペイロードの比較

• 生成コードの変更による問題の回避


"真"の相互運用性

クライアントの変更から学んだ教訓

NULLが返される理由

• 受信したレスポンスの形式を確認する

• サーバーが空のレスポンスを送信している• リクエストのデシリアライズに失敗している可能性が高い

• サーバーが正しいレスポンスを送信している• レスポンスのデシリアライズに失敗している可能性が高い

• 重要なのは、受信したメッセージがWSDLに示されたスキーマにしたがっていないということ





WSDLの変更



3大考慮事項

ベスト・プラクティス：トップダウン設計 - WSDLからJavaへ

SOAPスタブ

クライアント実装

サーバー実装

SOAPスケルトン

WSDL

代表的なアプローチ

• インバウンド・メッセージとアウトバウンド・メッセージにXMLスキーマを作成する

• スキーマ・ディクショナリを維持する企業も多い

• 作成されたXMLスキーマに対してプロトタイプのWSDLを使用し、メッセージ形式を設定する

• WS-Iに準拠したテンプレートを使用する

• データ・バインディングを選択する

• SAAJ、JAXB、またはJAX-RPCバインディング

トップダウンによるおもな問題

• 複雑さ

• トップダウン向けのツールが限定されている

• サード・パーティ製の.NET拡張

• Java - Oracle、Sun RI、Axis（？）

• Indigo• コードによるコントラクト・ドリブンは遠い将来

• JAX-WS• 不明確な推奨メカニズムが進行中


　

トップダウンWebサービス

議題




WSDLの変更



3大考慮事項

3大考慮事項

• 複数のWebサービス・ツールキットを使用して

サービスのテストを実施すること

• 送受信されるメッセージを取得できるツールを使用すること

• SOAPScope、JDeveloper、WSE、IBM、BEA、Axisなど

• トップダウン設計により相互運用性の機会を最大化すること

• ツールについてはベンダーにお問い合わせください





WSDLの変更



3大考慮事項

質　疑質　疑

応　答応　答

Oracle Fusion Middleware

テクノロジーを学ぶOTNサイト（otn.oracle.com）を参照してください

ソフトウェアを試すMoscone West 1003、1004のハンズオン・ラボにて

エキスパートに聞くOracle Fusion Middlewareのデモグラウンド、セッション

このプレゼンテーションは情報提供を唯一の目的と...

Documents