.NET／Java相互運用の現在・未来 ― .NET／J2EE相互運用の基礎から最新テクノロジまで ― 第3回　リソース層の相互運用と最新Webサービス事情

　前回（第2回）は、以下のような.NET／Javaベース・アプリケーションの相互運用におけるプレゼンテーション層、ビジネス・ロジック層に注目した。引き続き今回は、データベースの相互運用や非同期メッセージングなどのリソース層での相互運用について注目しよう。

.NET／JavaベースのWebアプリケーションの構成技術（再掲）

　.NETアプリケーションとJavaアプリケーションで1つのデータベースを共有することは、単純だが効果的な相互運用形式である。.NETにせよJavaにせよ、アプリケーションは抽象化されたデータベース・アクセス・ドライバを利用できるため、単一データベース内のテーブルやレコード、フィールドなどを、互いに共有するようなアプリケーションを開発することは比較的容易だ。歴史的な経緯から、JavaアプリケーションといえばOracleやIBM DB2などを利用することが、.NETアプリケーションはマイクロソフトのSQL Serverを利用することが一般的だが、必要ならJavaアプリケーションからSQL Serverにアクセスすることも、.NETアプリケーションからOracleやDB2にアクセスすることも困難ではない。

■JavaアプリケーションからSQL Serverへのアクセス

　J2EE（J2EE 1.3仕様）には、JDBC（Java Database Connectivity）と呼ばれるデータベース・アクセス用APIが提供されている。Javaアプリケーションは、このJDBC APIを通して、データベース内のテーブルやレコード、フィールド、ストアード・プロシージャにアクセスできる。Javaアプリケーションから呼び出されたJDBC APIは、JDBCドライバと呼ばれるレイヤを通して物理的なデータベースにアクセスする。このJDBCドライバでデータベースの違いを吸収し、抽象化しているわけだ。従って適切なJDBCドライバさえあれば、Javaアプリケーションから異なるデータベースに透過的にアクセス可能になる。主要なデータベース製品向けのJDBC互換ドライバは、データベース・ベンダ自身、またはサードパーティから無償／有償で提供されている。

　マイクロソフトは、SQL Server向けのJDBCドライバ（Type 4 JDBCドライバ）を同社のインターネット・サイトで無償公開している。これを利用すれば、Javaアプリケーション（EJBコンポーネント）からSQL Serverにアクセス可能になる。

• Microsoft SQL Server 2000 Driver for JDBC

JavaアプリケーションからSQL Serverへのアクセスを可能にするJDBCドライバ

■.NETアプリケーションからOracleデータベースへのアクセス

　.NETアプリケーションから、SQL Server以外のデータベースにアクセスすることももちろん可能だ。古くはODBCドライバ*1なども利用可能だったが、ADO.NETでは、「データ・プロバイダ」と呼ばれるしくみでデータベースの物理的な違いを吸収できるようにしている。マイクロソフトは、自社のSQL Server向けのデータ・プロバイダに加え、Oracleデータベース向けのデータ・プロバイダ（.NET Framework Data Provider for Oracle）を無償 提供しており、これを利用することで、.NETアプリケーションからOracleデータベースにアクセスできるようになる。この場合でも、.NETアプリケーションは、何ら制限を受けることなく、ADO.NETのすべての機能を利用可能だ。

• .NET Frameworkデータ・プロバイダの詳細解説

.NETアプリケーションからOracleデータベースへのアクセスを可能にするOracle OLE DBプロバイダ

　これまでは、通信する主体同士が同期的に処理を実行するという前提で相互運用の話を進めてきた。つまり、呼び出したアプリケーション側では、相手から応答があるまで処理を中断して待ち、呼び出された側では、送信されたメッセージをすぐに受信して処理を開始し、応答を返すという前提である。

同期型の処理 同期型処理では、送信されたメッセージはいつでも受信され、想定される時間内に相手から応答が返るものと想定している。

　しかし現実の異機種間連携では、一方が他方を呼び出しても、呼び出された側がメッセージをすぐに受信できない場合があるかもしれない。典型的な例としては、業務時間の違いが挙げられる。例えば、呼び出し側は20:00まで営業していても、呼び出し先のシステムは19:00で営業を終了しているかもしれない。この場合、19:00以降に発生した呼び出しは受信されないので、相手の応答を待ち続ける設計にしてしまうと、処理がそこでロックしてしまう。

送信メッセージが何らかの理由からすぐには受信されない例

　たとえメッセージがすぐに受信されたとしても、受信側が要求された処理を実行して応答を返すまでに長い時間がかかる場合もある。例えば、取引先企業の信用を調査するような処理なら、信用情報をさまざまなソースから収集して結果を返すまでに、数時間とか、場合によっては数日かかるかもしれない。この場合も、相手の応答をいつまでも待つ設計にしてしまうと、呼び出し側アプリケーションはそこでロックしてしまうことになる。

受信メッセージの処理に長い時間がかかる例

　これらのケースでも、お互いの情報システムがロックすることなく正常に処理を継続するためには、非同期型のメッセージ処理メカニズムを導入する必要がある。非同期型のシステムでは、相手がメッセージを受信しなかった場合や、処理に長時間がかかる場合でも、その応答は待たずに別の処理を行うようにする。そしてメッセージ処理が完了したら、応答を受けて処理を続行する。このような非同期処理を実現するには、いつだれがどのようなメッセージをだれに発信したのか、どのメッセージは処理中で、どのメッセージ処理は完了したのかというトランザクションを正確に記録しておかなければならない。

　幸い、このような非同期メッセージ処理を行うためのミドルウェア製品が利用できる。マイクロソフトは、Microsoft Message Queuing（MSMQ）と呼ばれる製品を、IBMはWebSphere MQ（MQ Series）と呼ばれる製品をそれぞれ提供している。これらのメッセージ・キュー製品では、中央に配置したメッセージ・キューを経由させることで、複数の.NET／Javaアプリケーションをそれぞれ異なるタイミングで実行させながら、互いに通信させることが可能になる。

　同期型／非同期型にかかわらず、今後のシステム連携では、接続インターフェイスとしてWebサービスが主流になることは明かだ。MSMQ／WebSphere MQは、いずれも送受信のエンド・ポイント（接続インターフェイス）としてWebサービスをサポートしている。なお必要であれば、MSMQとWebSphere MQの間で、メッセージを交換することも可能だ。これはMSMQ−WebSphere MQブリッジと呼ばれる。

　マイクロソフトは、単純な非同期メッセージ処理だけでなく、異なる複数のシステム間でのビジネス・プロセス処理を可能にするBizTalk Serverと呼ばれる製品も提供している。BizTalk Server向けには、データベースやERP、CRMなどの外部ミドルウェア製品などを接続するためのさまざまなアダプタが提供されており、これらを部品として使用し、全体のビジネス・プロセスをデザイン可能にする。もちろんBizTalk Serverと.NET／Javaアプリケーションも、Webサービスなどを介して接続できる。BizTalk Serverは、SOA（Service Oriented Architecture）によるビジネス・システム連携を加速するミドルウェアとして注目を集めている。

　これまで述べてきたとおり、.NET／Javaアプリケーションだけでなく、あらゆる異機種間接続において、Webサービスが標準的な通信プロトコルとして使用されるようになってきた。当初のWebサービス仕様は、非常にシンプルで応用範囲の広いアーキテクチャだが、ビジネス・システムに適用しようとすると、あまりにプリミティブで柔軟性が高いため、管理が複雑化しやすく、またビジネスでは不可欠なセキュリティの確保やトランザクション保証などをシステムごとに実装しなければならず、システムごとに実装がまちまちになってしまうという問題があった。

　この問題に対し、ビジネス・システムでの利用を前提として、さらに一歩踏み込んでWebサービスの拡張仕様を策定しようとする動きがマイクロソフトやIBMを中心として開始された。当初このWebサービス拡張仕様はGXA（Global XML Web Service Architecture）と呼ばれていたが、現在ではWSA（Web Service Architecture）と呼ばれている。WSAは、機能ごとにモジュール化され、必要に応じて組み合わせ可能ないくつかのWebサービス拡張プロトコル群で構成されている。これらはいずれも、XML＋SOAP基盤の上に構築されており、WS-Security、WS-Addressingなど各仕様の先頭に“WS-”が付くことから、まとめて“WS-*（ダブリュ・エス・アスター）”と呼ばれる場合もある。

　WS-*の仕様策定は標準化団体やベンダなどの間で現在も進行中であり、仕様の見直しや、旧仕様を整理継承した新仕様の策定などが活発に行われている。原稿執筆時点（2005年12月現在）での主要なWSAの構成をまとめると次のようになる。

WSAの構成

　このようにWSAでは、基礎となるメッセージング機能上に、セキュリティや信頼性の向上、トランザクション処理に関する拡張仕様を策定している。メタデータは、Webサービス同士が接続し会話を開始するためのスキームを提供するプロトコル群である。WS-*の各仕様を簡単にまとめると以下のようになる。

　マイクロソフト／Sunとも、すでにWS-*仕様の実装を提供しており、以下のサイトから関連ファイルをダウンロードし、実際にプログラム開発を行うことができる。

• Web Service Developer Center（米Microsoft）
• Sun Develolper Network（米Sun）

　まだまだ発展途上ではあるが、これらの拡張Webサービス仕様が洗練されることで、Webサービスはよりいっそう効率的で、より信頼性や安全性の高い相互運用基盤となっていくだろう。

　これまで3回にわたり、.NET／Javaアプリケーションの相互運用の現在とこれからについてまとめた。.NETとJavaは互いを排除しようとする競争相手と考えられた時代もあったが、実際には、相互運用によって互いを補完する関係に発展しつつある。これは.NET／Javaアプリケーションが、興味本位の対立関係ではなく、ビジネスの現場に定着した結果であり、相互運用性をビジネスの現場が求めているということだ。

　相互運用性を語るうえで、特に注目すべきはWebサービスの存在である。プレゼンテーション層、ビジネス・ロジック層、リソース層というあらゆるアプリケーション層の接続プロトコルとしてすでに中心的な位置付けになっており、さらにWSAの拡張仕様によって、より高機能で安全性や信頼性の高いアプリケーション間通信が可能になりつつある。

　規模や目的にかかわらず、今後の情報システムは、ビジネスの変化に柔軟に対応できなければならない。これには、異機種接続性の確保が不可欠である。たとえ異機種接続が目前の要件でないにしても、いつでも対応できる準備が必要である。