![]() |
![]() |
|
Loading
|
@IT > .NET/Java相互運用の現在・未来 第2回 .NET/Java相互運用の内部構成と利用可能なテクノロジ |
![]() |
|
前回は、より柔軟で変化に素早く対応できる情報システムを構築するために、異機種間相互運用が不可欠であることについて概論を述べた。引き続き今回は、.NETとJavaの相互運用について、システムの内部構成を意識しながら、さらに一歩踏み込んで整理してみよう。
まずは、.NETとJava(J2EE)ベースで開発された情報システムの構成について概観してみよう。ここでは、業務システムとして広く普及したWebアプリケーションを例にとる。
上図は、.NET/Javaプラットフォームで開発されたWebアプリケーションを構成するテクノロジを、ビジネス・アプリケーションの構成層別に分類したものだ。 ■.NET(Microsoft .NET) .NETは、マイクロソフトが提供するソフトウェア・プラットフォームの総称である。ISO(国際標準化機構)やJIS(日本工業規格)で標準化されたCLI(Common Language Infrastructure)をベースに開発された.NET Frameworkランタイム・ライブラリ上にサーバ、クライアント双方のアプリケーション環境を構築している(最新版の.NET Framework 2.0が先ごろ公開された)。このうちサーバ・アプリケーション向けには、Webアプリケーションのユーザー・インターフェイス設計を支援するASP.NET、Webサービス(後述)/データ・アクセスを支援するサービス・コンポーネントのADO.NETなどが提供されている。 ■J2EE(Java 2 Enterprise Edition) Javaプラットフォームのベースをなすアプリケーション・サーバ規格がJ2EE(Java 2 Enterprise Edition)である。Sun Microsystemsを中心に、Java Community Processと呼ばれる標準化グループによって規格化された。J2EEでは、デスクトップ・アプリケーション向けのJ2SE(Java 2 Platform Standard Edition)の仕様に加え、分散コンポーネント・モデル(EJB)やWebアプリケーション・サーバ機能(サーブレット、JSP、JSF)、Webサービス対応機能(JAX-M/JAX-RPC)、データ・アクセス機能(JDBC)などといった、いわゆる「サーバ・サイドJava」機能が追加されている(以下の用語解説参照)。 本家Sun社のSun One Application Serverに加え、IBM社のWeb Sphere、BEA社のWeb Logic、Oracle社のOracle Application Server、フリー・ソフトウェアのJBossなど、さまざまなベンダからJ2EEに対応したアプリケーション・サーバが提供されている。 本記事執筆時点(2005年11月現在)での最新バージョンはJ2EE 1.4だが、近日中にJava EE 5が登場する予定である(2005年開催のJavaOneにおいて、Sunは“J2EE”などの従来の呼称を“Java EE”に改めた)。
■.NETとJavaの根本的な違い 機能や仕様だけでなく、.NETとJavaの間には根本的な違いがある。Java対応ソフトウェアは、J2EEなどSunがリードして作成した仕様(ドキュメント)に従って、さまざまなソフトウェアベンダやオープンソース・グループが実装を行う。ユーザーは、こうして実装されたアプリケーション・サーバ製品などから仕様するものを選択する。 これに対し.NET対応ソフトウェアは、マイクロソフトが仕様を策定するだけでなく、実装も並行して行い、実際にWindows環境で稼動するソフトウェアとしてユーザーに提供される。 もちろん、サードパーティが開発した.NET対応ソフトウェアも多いが、仕様だけでなく実装にも標準が存在することは、.NETの大きな強みといってよいだろう。
プレゼンテーション層は、ビジネス・アプリケーションのユーザー・インターフェイスを提供するレイヤである。Webアプリケーションであれば、必要な情報をビジネス・ロジック層から取得し、クライアントとなるWebブラウザに対してWebページを生成・送信し、クライアントからのフォーム入力などを受け取ってビジネス・ロジック層に渡す。 前回説明したとおり、プレゼンテーション層は、新しいデバイスへの対応など、変化のサイクルが次に述べるビジネス・ロジック層に比較すると短い。具体的には、ユーザー・インターフェイスを実装した既存のソフトウェアを置き換えたり、一部を拡張したり、逆に既存のソフトウェアを現在のインターフェイス実装に統合したりする必要に迫られる。 この場合、同一のプラットフォームでの置き換えや拡張が順当だが、相互運用をうまく利用できれば、既存ソフトウェアのプラットフォームに依存することなく、.NET/Javaのどちらのテクノロジを使っても置き換えや機能拡張が可能になる。要求に応じて、柔軟に製品や機能を選択できるようになる。 例えば次のケースは、J2EEベースで開発された既存のビジネス・ロジック・コンポーネントと、ASP.NETベースで開発されたユーザー・インターフェイスを相互運用する例である。JSP/サーブレット/JSFに比較すると、ASP.NETは新しい開発環境であり、開発効率が高い。このため、Javaプラットフォームで開発された既存のシステムから、ビジネス・ロジック層はそのまま残して、プレゼンテーション層部分だけを新規開発して置き換える場合などに、この形式の相互運用が求められる可能性がある。
これとは逆に、JSP/サーブレット/JSFで開発されたプレゼンテーション層はそのままに、ビジネス・ロジック層を.NETベースに置き換えるケースも考えられる。
例えば、ユーザー教育の費用など、既存のユーザー・インターフェイスを変更するために莫大なコストがかかるケースでは、このようなシナリオによるシステム更新が必要になるだろう。
プレゼンテーション層では、既存アプリケーションの置き換えや拡張が求められるのに対し、ビジネス・ロジック層では、既存アプリケーションやサービスから、可能な限りコンポーネントを再利用しながら、新たなアプリケーションやサービスを開発したり、両者を統合したりするニーズが高い。 すでに説明したとおり、ビジネス・ロジック層は、比較的ライフサイクルが長い。これに加えビジネス・ロジック層のコンポーネントは、ユーザー認証などのセキュリティに関係するもの、障害発生時のロールバックなどを保証するトランザクション処理に関係するものなど、プレゼンテーション層と比較すると複雑でテストが困難なものが多い。このため実績のある既存のコンポーネントの再利用性を高めれば、開発やテストにかかる工数を大幅に削減できるという特徴がある。 例えば次の図は、.NETベースのアプリケーションから、既存のEJBコンポーネントを使用するケースである。
このケースでは、.NETサービス・コンポーネントとEJBコンポーネントを統合して、.NETアプリケーションから双方のビジネス・ロジック・コンポーネントを利用可能にしている。.NETサービス・コンポーネントは、必要に応じてEJBコンポーネントを呼び出し、応答を得る。このコミュニケーションには、後述するWebサービスなどを使える。
情報システムの運用によって蓄積されたデータベースを新たなアプリケーションやサービスでも利用できるようにすることは、いま述べたビジネス・ロジック層の再利用にも増して重要である。アプリケーションごとに異なるリソースにアクセスするのでは、リソースが二重管理になってしまうし、蓄積された情報の統合的な利用(アプリケーションにまたがる情報を統合的に分析するなど)もできなくなってしまうからだ。 このリソース層には、データベース以外にも、非同期メッセージによるトランザクション処理を行うメッセージ・キューや、ほかのシステムとのインターフェイスとなるブローカーなど(CORBAやDCOMなど、用語解説参照)が含まれる。
例えば次は、.NETアプリケーションとJavaアプリケーションの双方から、共通するデータベースを呼び出している。
この例では、.NETアプリケーションも、Javaプレゼンテーションも、直接的には相手のインターフェイスを呼び出すことはない。データベースが提供するインターフェイスを双方のアプリケーションが呼び出している。詳細は次回に説明するが、このようなデータベースの共通利用の技術はかなり以前から確立されており、すでに多くのビジネス・アプリケーションがこの構成で相互運用を実現している(SQL Serverが提供するJavaアプリケーション向けドライバのJDBC、Oracleが提供する.NETアプリケーション向けのOracle Ole DBプロバイダなど。詳細は次回)。
.NET/Javaアプリケーションの相互運用では、一方のアプリケーションが、他方を呼び出せるようにするためのインターフェイスが必要になる。そしてこれと同時に、そのインターフェイスを通してデータを交換するための取り決めも必要だ。 周知のとおり、現在では、プラットフォームに依存しない汎用のデータ・フォーマットとして、XML(Extensible Markup Language)が広く利用されるようになった。異機種間データ交換においても、XMLの利用が一般的になっている。 XMLは、Webの各種標準を策定するW3Cで標準化されたデータ形式である。XMLは、HTMLやSGML(Standard Generalized Markup Language)と同じマークアップ言語だが、HTMLにあった論理構造記述能力の不備を解消しつつ、その一方で、複雑で実用が困難だったSGMLをシンプルにして実用性を高めたものだ。現在では、多くのプラットフォームでXMLデータ処理機能やライブラリが提供されており、さまざまな環境で容易にXMLデータを扱えるようになった。もちろん、.NET/J2EEとも、XMLデータを処理するためのさまざまなサービス・インターフェイスを用意している。 .NETプラットフォームでは、XMLデータを扱うための基本機能が.NET Frameworkライブラリに標準的に組み込まれている。一方のJavaプラットフォームでも、J2EE本体にさまざまなXML用APIが含まれるほか、XMLパーサ機能を提供するApache XML ProjectのJAXP(Java Architecture for XML Processing)、XMLベースのRPCを提供するJAX-RPX、XMLドキュメントをJavaオブジェクトにマップするためのJAXBなどがサポートされる。 互いのシステムに存在しないデータ型などがあった場合でも、XMLシリアライズ(XML serialization)と呼ばれる手法を使えば、任意のデータ型をXMLドキュメントの内部に埋め込んで相手に送ることが可能だ。
Webサービスが一般化する以前から、分散アプリケーションのための通信方法はいくつか存在していた。例えばマイクロソフトは、自社のコンポーネント・プログラム・テクノロジのCOM(Component Object Model)を発展させたDCOM(Distributed COM)を提供していたし、JavaプラットフォームではJava RMI(Java Remote Method Invocation)と呼ばれる分散コンポーネント仕様が利用可能だった。標準化グループのOMGは、ベンダ非依存の分散システム仕様のCORBAを策定していた。CORBA対応製品の主要ベンダの1つにアイオナ・テクノロジーズ社がある。同社は、Java環境とCOM、あるいは.NETの環境をCORBA技術を使って相互接続することを可能にしている。 ただしいずれの技術も、特定企業や組織内部の分散アプリケーション技術としては一定の成功を収めたが、企業や組織の境界を超えたシステム連携では一般化しなかった。いずれのテクノロジも、インターネットのような広域ネットワーク基盤を前提としていなかったからだ。 これに対し、多くの企業や組織がインターネット接続で利用しているWeb(HTTP/HTTPS)のしくみをうまく利用して、分散アプリケーション環境を構築することを目的に開発されたのがWebサービスである。WebサービスはHTTPやHTTPSを通信プロトコルとして使用可能なため、容易にファイアウォールの境界を超えた通信ができるという特長がある。Webサービスは、XMLテクノロジを使用して、プラットフォームによらないデータ交換を可能にしている。Webサービスを利用すれば、特定のプラットフォームや言語、ベンダなどに依存することなく、異なるアプリケーション同士が連携できる。 もはやWebサービスは、相互運用では欠かせない通信手段となった。マイクロソフトは、.NET Frameworkのコア機能としてWebサービス対応を実装しているし、SunはJ2EEにさまざまなWebサービス対応機能を追加している。さらにこれ以外にも、UNIXベースの主要なWebアプリケーション・サーバの1つであるApacheの開発元であるASF(Apache Software Foundation)はAxisと呼ばれるWebサービス向けフレームワークを、IBMはApache TomcatおよびIBM WebSphereにWebサービスを追加するためのIBM WSTK(Web Service Tool Kit)をそれぞれ提供している。 .NET/Javaアプリケーションのポイント to ポイントの連携に加え、最近では、データベースやメッセージ・キューなどのリソース層コンポーネントとアプリケーションのインターフェイスにも、積極的にWebサービスが利用されるようになってきた。例えばマイクロソフトが先ごろ発表した最新版のSQL Server 2005では、データベース自身がネイティブにWebサービス・インターフェイスを備えている。
複数のプラットフォーム・ベンダがXMLテクノロジやWebサービスへの対応を行い、これらを利用した相互運用システム開発が実用段階に入っていることをご理解いただけただろう。 今回は相互運用の第一歩として、アプリケーション同士、あるいはアプリケーションとリソース層との単純な連携について解説してきた。しかし現実の業務システムでは、単純な同期型の連携ばかりでなく、メッセージングなどの非同期処理が必要になったり、トランザクションを保証したりしなければならない。次回は、特にリソース層に注目し、データベースや非同期メッセージなどのミドルウェアを利用した、相互運用の実際について解説する。またWebサービスについても、セキュリティ機能やトランザクション機能を強化した次世代Webサービス仕様(WS-*)が開発されている。後半では、代表的なWS-*使用と、相互運用の観点から見た技術的なポイントなどについて解説する予定である。
提供:マイクロソフト株式会社
企画:アイティメディア 営業局 制作:@IT 編集部 掲載内容有効期限:2006年1月23日 |
![]()
![]() |