レベル: 初級 米持 幸寿, テクノロジー・エバンジェリスト, IBM
2006年 10月 10日 この資料は、現存するWebSphereとWebサービスを使ってWebSphere上のサーバー・アプリケーションと.NETのクライアントコードを連携させる検証を行った結果をまとめたものです。
1. 目的
画面定義の簡単さや、クライアント・サーバー型アプリケーションの使いやすさから、マイクロソフトの.NETを利用したいというケースが増えています。しかし、「.NETはデスクトップ、あるいはクライアントの技術。サーバー側は信頼性が高くアプリケーションの可搬性が高いJ2EEを使いたい。」という声が多いのが現実です。
XMLとSOAPをプロトコルに使うWebサービスを使うとWebSphereのアプリケーションと.NETのクライアントを接続することができます。しかし、実際にやってみるとうまくいかないことがたくさん発生します。
この資料は、現存するWebSphereとWebサービスを使ってWebSphere上のサーバー・アプリケーションと.NETのクライアントコードを連携させる検証を行った結果をまとめたものです。
この検証は、閉鎖的に行われた試験結果であり、検証結果を保証するものではないことをお断りしておきます。
すべてのミドルウェアを対象にすることは実質不可能なので、今回は、以下のミドルウェアを対象にしています。また、ミドルウェア単体では手作業で開発することが前提となってしまうため、それぞれが想定する標準の統合開発環境（IDE）を併用することとします。
- IBM SOAP（WebSphere Application Server V4.0-V5.01）
＋ IBM WebSphere Studio V4.0x-V5.01
- IBM WebSphere Application Server V5.02（注1）
＋ IBM WebSphere Studio V5.1
- Microsoft .NET Framework V1.1
＋ WSDL.EXE（この検証は、VisualStduio.NET 2003と同じと考えています。）
注1：WAS V5.02では、Axisをベースとした新しいSOAPエンジンを搭載しておりJAX-RPC、SOAPV1.2、WS-I Basic Profile 1.0に対応しています。
2. 検証条件
検証においては、以下の条件にて行いました。
2.1 接続方法
SOAPによる接続は、XMLを利用しており、多くのミドルウェアはSOAPのXMLメッセージに直接アクセスできるAPIを備えています。これらを使えば、どんなメッセージ・フォーマットでもある意味接続可能です。
しかしながら、WebサービスでSOAPとWSDLがペアで使われることの大きな意味は、自動プログラミングにあり、その機能が正しく機能することはWebサービス技術にとって重要です。そこで、この検証では、次の条件を課すことにします。
サービスのデプロイやクライアント・プロキシーの生成は、ミドルウェアが標準としている方式のみを利用し、メッセージを直接アクセスしたり、（デ）シリアライザーを手作業で作成する作業は行わないこととする。
2.2 プロバイダーとリクエスターの検証
すべてのミドルウェア同士で、プロバイダー、リクエスターを実装し、相互接続してみる。このとき、WSDLは、プロバイダーが提供し、リクエスターが利用する形態とする。
2.3 データ型
利用するデータ型は、JAX-RPC（JSR-101）で決められている以下の型の中から一部を採用します。（4.2章から抜粋）ただし、単純型（SimpleType）での接続性は、長きにわたって検証が行われており、いまさら検証する必要はないと考えられますので、ここでは、これらの型を使ったオブジェクトと配列（2.4）を検証対象とします。
以下の型をすべて検証することとする。
int型、long型、float型、double型、boolean型、String型 これは、JAX-RPCで決められているマッピングから簡単なもののみを抽出した。
2.4 オブジェクトと配列アプリケーション開発において、複合オブジェクトと配列の送受信は必要不可欠です。本検証では、2.3で挙げたすべての型に対して単純配列とそれを含むオブジェクト、さらにそれを配列化したものをそれぞれ接続検証対象とします。
2.5 検証に利用した実装検証には、次の実装を利用しました。
source.zip
(8KB)
検証対象となっているオブジェクトは、以下のような種類です。
1.TestSimple：シンプルな値を引数にするメソッド
2. TestArrayOfSimple：単純な値の配列を引数や戻り値に利用するメソッド
3. 単純な値をプロパティーに持つオブジェクトを引数や戻り値に使うメソッド
4. 単純な値の配列や、Valueオブジェクトの配列をプロパティーに持つ複雑なオブジェクトを引数や戻り値に使うメソッド。
5. 複雑なオブジェクトの値の配列をラッパークラス配列に置き換えたもの。
3. 検証結果
3.1
.NET（リクエスター） ->
WebSphere Studio V4.0-V5.01（プロバイダー）
- TestSimple
- プロキシー生成：成功
接続：成功
- TestArrayOfSimple
- プロキシー生成：成功
接続：失敗
理由：配列のXMLマッピング方法が違うため（.NETは参照配列、WebSphereは内包配列）
- TestValue
- プロキシー生成：失敗
理由：.NETのWSDL処理で、ネストしたimportの処理がうまくいかない
回避：WSDLをひとつにまとめると、プロキシー生成、接続まで可能
- TestArrayOfValue
- プロキシー生成：失敗
理由：.NETのWSDL処理で、ネストしたimportの処理がうまくいかない
回避：不可/WSDLを合体させても、配列処理が失敗
- TestComplex
- プロキシー生成：失敗
理由：.NETのWSDL処理で、ネストしたimportの処理がうまくいかない
回避：不可/WSDLを合体させても、配列処理が失敗
- TestClassComplex
- プロキシー生成：失敗
理由：.NETのWSDL処理で、ネストしたimportの処理がうまくいかない
回避：不可/WSDLを合体させても、配列処理が失敗
3.2 WebSphere Studio V5.02と.NETの接続
- TestSimple
- プロキシー生成：成功
接続：成功
- TestArrayOfSimple
- プロキシー生成：成功
接続：失敗
理由：配列の長さが0（SOAPメッセージには正しく含まれている）Uploadは問題なし
- TestValue
- プロキシー生成：成功
接続：成功
注意：メソッド引数がUploadオブジェクトに内包される形式になる
- TestArrayOfValue
- プロキシー生成：成功
接続：失敗
理由：配列の長さが0（SOAPメッセージには正しく含まれている）Uploadは問題なし
- TestComplex
- プロキシー生成：成功
接続：失敗
理由：WebSphere側が、intとIntegerなどを混同する
- TestClassComplex VS.NETと接続する手順を別途準備しました。
- プロキシー生成：成功
接続：成功
4. 結論
- 単純な型を交換する場合は、メソッドにそのまま指定してかまわない。また、WAS4.0＋.NETでも接続可能。
- 配列、複合型を利用するときは、全体をまとめあげるオブジェクト型を作り、それを利用する。この場合、WAS5.02＋Studio 5.1が推奨される。
- 複合型に入れる配列には、基本型ではなくラッパー型を利用する。
VS.NETがWS-Iに準拠することで、さらに状況はよくなると考えられます。
著者について  | | | 1987年に日本アイ・ビー・エム入社。メインフレームOS、ミドルウェアの障害対応、障害解析ソフトウェアの開発、ワークフローシステム開発、オブジェクト指向開発、Web開発など経験。2000年より、ソフトウェアのテクノロジーエバンジェリストとして活動中。 |
記事の評価
| 
