Loading
|
|
|
|
Loading
|
| ＠IT > .NETプラットフォームが選ばれた6つのテクニカル・アドバンテージ＜後編＞ |
 |
|
|
Webアプリケーションのプラットフォームとして2大勢力となった.NETとJ2EE。どちらのアーキテクチャを採用すべきか、その選択に有効と思われる技術情報を提供する本記事は、前編で「Webアプリケーション・サーバの技術基盤」「ビジネス統合ミドルウェア」「統合開発環境」の3つの側面から考察を行った。後編となる本稿では「クラスタリング・システム構築の基盤」「リッチクライアント環境」「ユーザー／サーバ管理機能」についてさらなる検討を行う。
.NETとJ2EEでは、どちらのプラットフォームも分散型コンポーネントを実装していることは前編で指摘しておいた。このテクノロジを導入する目的は、Webアプリケーションに高可用性とスケーラビリティを付加するため、クラスタリング・システムの導入が不可欠だからである。ここではクラスタリング・システム構築における.NETとJ2EEの基盤技術の差異を明らかにしよう。また、分散環境における非同期型メッセージングに対応したミドルウェア製品についても検討する。 （1）クラスタリング・ソフトウェア まず、クラスタリング・システムの実現に当たって、.NETとJ2EEの根本的な違いを指摘しておこう。J2EEは、Javaの基本アーキテクチャであるマルチプラットフォームの制約を受ける。つまり、複数のサーバから構成されるクラスタリング環境で、ロードバランシング機能や分散型コンポーネントのセッション管理、障害時のフェイルオーバーといった機能は、J2EEサーバ製品に同梱されるクラスタリング・ソフトウェアを使用することが推奨されている。採用するサーバOSがUNIXやLinux、Windowsであっても共通のクラスタリング機能を利用できる反面、必要なソフトウェアをインストールし、環境設定やチューニングを行う必要が開発者に生じる。 これに対して、Webアプリケーションに必要な統合システムを単一ベンダが提供する.NETでは、Windows Server 2003（Enterprise Edition／Datacenter Edition）の提供するクラスタリング機能は.NET Frameworkと密接に統合されており、J2EEのように新たにソフトウェアをインストールする必要はない。OSの提供する基本機能を利用できることは開発負荷を軽減することになるだろう。 J2EEのクラスタリング・システムの一例として、WebSphereにおけるクラスタ・アーキテクチャを検討してみよう。WebSphereファミリ製品で負荷分散と高可用性を実現するには「WebSphere Application Server Network Deployment」という上位製品が必要となる。このパッケージにはJ2EEサーバである「WebSphere Application Server」に加えて、
など、マルチ・サーバ環境に必要なコンポーネントが含まれる（Edge ComponentはWebSphere Edge Serverという製品から負荷分散とキャッシング・プロキシの機能を取り出したコンポーネント）。WebSphereでの典型的なクラスタリング・システム構成では、2台のHTTPサーバと2台のJ2EEサーバを稼働させ、クライアントからの要求はHTTPサーバの手前に配置されたNetwork Dispatcher（Edge Componentが提供する）がネットワーク負荷分散を行う。さらにHTTPサーバに組み込まれたWebサーバ・プラグインによって、J2EEサーバの負荷分散も行われる。いずれのサーバマシンにも、WebSphere独自のコンポーネントを組み込むことでクラスタリング環境を実現している。 .NETが推奨するクラスタリング・システムは図1のようになる。.NETではHTTPサーバである「IIS」、ネットワーク負荷分散を実現する「NLB」、セッション管理を行う「ASP.NET State Service」など、クラスタリング・システムを構築するためのソフトウェアは、サーバOSであるWindows Server 2003の基本インストールで提供されているのだ。詳細についてはMSDNの技術文書「Windowsエンタープライズ システムのスケーラビリティ／可用性／セキュリティ概要」の該当個所を以下より参照していただきたい。
.NETとJ2EEのクラスタリング・ソフトウェアの違いをまとめると、.NETはOSであるWindows Server 2003が基本機能として提供しているソフトウェアを利用でき、必要な構成設定はグラフィカルな管理ツールから行えばよく、非常にシンプルで確実なパフォーマンスが期待できる。J2EEでは上述のWebSphereのように、J2EEサーバが提供するクラスタリング・ソフトウェアを用いるため、必要なコンポーネントをOSごとにインストールするのだが、その過程で予期せぬトラブルに見舞われる可能性もある。この現象についての詳細は、「Microsoft .NETとIBM WebSphere／J2EEの比較」という資料を参考にしていただきたい。
J2EEはマルチプラットフォーム対応であるためシステム構成の自由度は高いが、使用するOSおよび各種ミドルウェアごとの専門知識が必要となるなど、開発者の負荷は増大する。前述の「Microsoft .NETとIBM WebSphere／J2EEの比較」の資料においても、.NETの構成とチューニング・プロセスの概要の部分は7ページ程度となっているが、WebSphereの構成およびチューニング・プロセスの概要の部分は30ページも紙面を割いており、J2EEにおける各種設定・チューニングの複雑さを垣間見ることができる。.NETを選択すれば、単一のWindowsプラットフォームに開発者の知識を集中させればよく、シンプルかつ強力なクラスタリング環境を容易に構築できるだろう。 （2）MOM（メッセージ指向ミドルウェア） 例えばオンラインで自動車を販売するECサイトがあったとしよう。このECサイトでは自動車ローンの申請を代行するサービスも提供している。顧客が自動車の購入と同時にローンも申し込んだとすると、ECサイトでは提携する自動車ローン会社に申請を代行し、数日の審査期間後にローンの可／不可の通知を受け、それを元に顧客の購入トランザクションをコミット／ロールバックする。 このような長期にわたるトランザクションを必要とするシステムでは、非同期メッセージ・システムの構築は不可欠である。前編で検討したSOAによるビジネス統合のシナリオでも、非同期型のメッセージング・システムは非常に重要な要素である。この非同期メッセージ製品はMOM（Message Oriented Middleware：メッセージ指向ミドルウェア）と呼ばれ、.NETアーキテクチャではMSMQ（Microsoft Message Queuing）、J2EE環境ではIBM社のWebSphere MQがよく知られている。
J2EEで非同期型メッセージングを利用する場合は、JMSと呼ばれるAPIを使用することで、特定のMOM製品を意識せずに実装できる。ただし、「WebSphere MQ」やソニック社の「Sonic MQ」などの製品を購入し、環境構築を行う必要がある。これに対し、「MSMQ」はWindows Serverに標準で搭載されており、.NET Frameworkと密接に統合されているところが特徴といえる。MSMQを有効にするには、Windows Serverの管理画面から最小限の設定を行えばよい。またBizTalk Serverのオーケストレーションにもシームレスに統合されている。開発生産性の向上ばかりでなく、システム設計がシンプルになるメリットも見逃せない。MSMQに関する詳細な情報は以下のMSDNを参照していただきたい。
（1）リッチクライアント .NETおよびJ2EEという2つのプラットフォームは、これまで検討してきたように、分散型システムによるスケーラビリティと高可用性を獲得し、フレームワークと開発ツールを洗練させることで開発生産性を向上させた。そしてSOAと呼ばれる新たなアプローチにより、企業のシステム統合からオーケストレーションによるビジネスプロセス管理（BPM）までを担う存在に成長した。サーバサイドの技術革新は目覚しいものがあった。 ところで、サーバサイドがこれだけ進化したにもかかわらず、Webアプリケーションのクライアントサイドは、Webブラウザで表現できる貧弱な機能しか与えられてこなかった。Webブラウザをクライアントにすることで、クライアント／サーバ・アプリケーション時代に直面したアプリケーションの配布とバージョン管理というやっかいな問題を解決できたが、一方でWebブラウザの貧弱なユーザー・インターフェイス、ユーザビリティに不満が表出されるようになった。簡単にいえば、クライアント／サーバ・アプリケーションと同様の“リッチな”操作性を求める声が高まっている。これに対応するテクノロジとして登場してきたのが「リッチクライアント」だ。 リッチクライアントという言葉が示す範囲は、現在のところ非常にあいまいで、かなり広義に捕らえるなら10個以上のアーキテクチャが乱立している。大手ベンダから独立系ベンダまでが入り乱れて、さまざまなテクノロジをリッチクライアントと称しているのが現状だ。 J2EE陣営で主だったリッチクライアントを挙げてみると、まずJ2EEサーバ製品が一様にサポートしているJSF（JavaServer Faces）がある。JSFはJ2EEと同様のJavaサーバサイド・テクノロジに基づくコンポーネント指向のユーザーインターフェイス（UI）構築フレームワークで、これを基にJ2EEサーバ・ベンダが独自の機能拡張を施している。IBM社の「WebSphere Studio」などが代表的な製品だろう。JSFは今後、J2EEの主要なリッチクライアント基盤となる可能性を持っているが、現時点ではまだ本格的に普及しているとはいえず、利用できるUIコンポーネントも本格的な業務アプリケーションを構築するのに十分とはいえない状況だ。 JSF以外でクライアントに“リッチな”操作性を提供するJava環境の技術には、Webブラウザに専用のプラグインを組み込むタイプと、クライアント・アプリケーションを用意してサーバを通じてバージョン管理や機能変更をコントロールするタイプに大別できる。前者はマクロメディアの「Flash」「Flex」、アクシスソフトの「Biz/Browser」が代表的な製品だろう。後者には「Eclipse RCP（Rich Client Platform）」「Java Web Start」などがある。 .NET陣営で提供しているリッチクライアントは後者のタイプに相当し、リッチクライアントと呼ばず「スマートクライアント」という用語を用いる。スマートクライアントとは、従来のクライアント／サーバの展開や管理に伴うTCOの増大といった問題点、およびWebブラウザでの貧弱な操作性やオフラインで動作し得ないといった問題点の両方を解決するソリューションである。スマートクライアントを導入することで、クライアントCPUを有効に利用した操作性の高いアプリケーションをオフラインでも動作可能にでき、クライアントへのアプリケーションの展開やバージョンアップを自動化することが可能になる。いわば次世代のWebアプリケーションと呼べるポテンシャルがあるといえる。詳細についてはMSDNの技術文書「ユーザー エクスペリエンス活用で情報システムの価値を最大化するマイクロソフトのクライアント ソリューション」の該当個所を以下より参照していただきたい。
また、業務用アプリケーションとして普及しているOfficeアプリケーション（WordやExcel）をWebアプリケーションと連携させてリッチクライアント的に活用する方法も提供されている。これはOffice 2003から導入されたOffice InfoPath 2003（以下、InfoPath）で実現される。InfoPathはOfficeドキュメントのデータをXML化して入出力できる機能で、サーバサイド・アプリケーションとWebサービスを使ってインタラクティブな動作を行うことが可能になる。新たに登場したInfoPathもOfficeの基本的な操作性を踏襲しており、エンドユーザーが日常的に使用しているOffice製品をWebサービスのクライアントとして利用することで、バックエンドのさまざまなデータを親しみやすい高い操作性で利用することが可能となる。
.NETとJ2EEのリッチクライアントを検討するに当たって、投資保護と開発生産性に着目してみると、両者の違いがはっきりしてくるだろう。まず投資保護だが、Java環境のリッチクライアント製品はいずれもベンダ固有のテクノロジであり、また誕生して間もないものであるため、将来どの製品が生き残るか（消滅するか）、現時点で見通すことは不可能だ。たまたま選択したリッチクライアント製品が数年後にサポート終了となる懸念は捨てきれない。 .NETのスマートクライアントも特定ベンダの製品であることには変わりないが、WindowsアプリケーションやOffice製品のエンドユーザーへの普及度、依存度は高いので、投資が無駄になるとは考えにくい。さらに、エンドユーザーが使い慣れたWordやExcelを利用するのは、業務生産性の観点からもメリットは大きいだろう。詳細についてはMSDNの技術文書「ユーザー エクスペリエンス活用で情報システムの価値を最大化するマイクロソフトのクライアント ソリューション」の該当個所を以下より参照していただきたい。 開発生産性では、J2EE陣営のリッチクライアント技術は、いずれも独自製品に付随した開発ツールに依存するため、エンジニアの学習コストは少なくない。.NETのスマートクライアントは、従来までのWindowsアプリケーション開発と大きく変わらないため、開発者の獲得や教育コストは大きな負担となることはない。 （2）BIソリューション リッチクライアントと同様にユーザーサイドの生産性に寄与するのがBI（ビジネスインテリジェンス）、つまり膨大な企業情報データを統合的に管理し、これを日々の経営戦略に有効利用させるための各種機能の充実度である。これは主に、データベース・サーバによって蓄積されたデータウェアハウスから、日々の経営戦略に有効な情報を抽出するテクノロジだ。J2EE陣営では、データベースはJ2EEサーバとは別製品として提供されており、IBM社のDB2やオラクル社のOracleデータベースなどが主流である。これらの基幹系データベースでは、BIソリューションを提供するための各種ソフトウェアはデータベース製品とは別に購入し、環境を構築する必要がある。例えば、DB2であれば「DB2 UDB Data Warehouse Edition」といったデータ・ウェアハウスを構築するトータル・ソリューション製品が必要だ。 .NETでは、マイクロソフト社のリレーショナル・データベースである「SQL Server 2000」には、「Reporting Services」が用意されている。これは本来、SQL Server 2005に標準搭載される予定だった機能であり、現行のSQL Server 2000でも利用できるように無償で配布されている製品だ。データベース・サーバの基本コンポーネントにBI機能が搭載されているのは、非常に高いコストパフォーマンスを生むと同時に、環境構築に要する開発コストも大幅に削減できる。さらに、Office製品をクライアントとして、SQL Serverの生成したBIレポートを参照することも可能で、このようなデータベースサーバと連動したリッチクライアントを既存のユーザーアプリケーションで実現できるのは、Windows Server環境の大きなメリットといえるだろう。J2EEによるWebアプリケーションを選択しても、バックエンドのデータベースにSQL Server 2000を導入し、レポーティング機能を活用するといった選択肢も考えられる。詳細についてはMSDNの技術文書「ユーザー エクスペリエンス活用で情報システムの価値を最大化するマイクロソフトのクライアント ソリューション」の該当個所を以下より参照していただきたい。
ここまで読み進めてこられた方には、すでに.NETとJ2EEの根本的な違いに気付いているだろう。それは、クライアント／サーバ製品を単一のベンダが提供するメリットが、オープン系のJavaに比べてより低コストで高い開発生産性をもたらすことである。 オープン系システムは、標準化された技術を利用することでエンジニアの技術習得を容易にし、テクノロジの継承を促進させるメリットはある。たしかに、かつてのメインフレームやオフコン時代のように、単一ベンダの狭い世界に閉じたテクノロジに大きな投資を行うのはリスクがあった。しかし、サーバサイドの基幹システムを一気にJavaとUNIX／Linuxのオープン系システムに移行させたここ数年の流れから、非常に深刻な問題が起こっている。 例えば、OSはA社のサポートするLinuxディストリビューション、サーバマシンはB社製、J2EEサーバはC社製、データベース・サーバはD社製としよう。そこでJ2EEアプリケーションに深刻なパフォーマンス問題が起こったとしたら、ユーザーはどのベンダにサポートを依頼したらよいだろうか。実際に、各ベンダから派遣されたサポート人員が互いに責任を押しつけ合って、一向に問題が解決しないといった悲惨な状況も起こっている。もし、すべてのサーバ製品をマイクロソフト製品に統一しているなら、サポートはマイクロソフト1社で対応できるから、問題の切り分けや対処方法の発見はより迅速に行われることだろう。 単一ベンダがすべてのサーバ製品を提供するメリットは、運用管理業務の負荷軽減にも大きな影響を及ぼす。.NET Frameworkを中核にすべてのサーバ製品が密に統合されているWindows Server製品群には、システムの全体を監視できるサーバ管理製品「Microsoft Operations Manager 2005（以下、MOM 2005）」が提供されている。MOM 2005には「イベント、パフォーマンス管理」「管理タスクの自動化」「サーバアプリケーションの監視」「レポーティング機能」「大規模環境での運用サポート」といった機能が用意されている。 またWindows環境では、クライアントPCを管理する「Microsoft Systems Management Server 2003（以下、SMS 2003）」も提供されている。最近のセキュリティ被害は、サーバサイドよりもクライアントサイドの問題によって引き起こされることが多い。例えば、ノートPCを社外に持ち出してウイルスに感染したまま社内ネットワークに接続し、一気に社内にウイルス感染が広まるといったケースだ。SMS 2003ではWindows Serverの提供するディレクトリ管理システム「Active Directory」と連携し、クライアントPCのセキュリティ・プログラムの自動更新といった管理業務を一元的に行うことが可能だ。今後、MOM 2005とSMS 2003を統合した「System Center 2005」がリリースされる予定もあり、これが実現すればよりユーザー／サーバ管理は容易になることだろう。詳細についてはMSDNの技術文書「Windowsエンタープライズ システムのスケーラビリティ／可用性／セキュリティ概要」の該当個所を以下より参照していただきたい。 J2EE陣営になると、例えばIBM社の「Tivoli」といった統合システム管理ソフトウェア製品を用意することになるが、Tivoliブランドにはサーバサイドのアプリケーション監視からクライアント管理まで20種類以上の製品群から構成され、製品選定やコストの見積もりなど、非常に複雑な導入計画を練らなくてはならないだろう。
前・後編でお届けした本記事では、.NETとJ2EEの提供する個別のテクノロジを検討してきた。Webアプリケーションのプラットフォームにどちらを選択するかは、個々のテクノロジの比較も重要だが、両者が提供するソリューションの総合的な価値を見極めることも肝要だろう。 Windows Serverに組み込まれたアプリケーション・サーバ機能による初期投資や各種設定、チューニングコストの軽減、より容易なWebアプリケーション開発による開発生産性の向上、Officeを含めたさまざまなクライアントの選択肢によるエンドユーザーの生産性向上など、サーバからクライアントまですべてをカバーし、OSや各種プロダクトとの統合が図られた実行環境および開発環境である.NET FrameworkとVisual Studio .NETによりシステム構築に伴う複雑さが軽減され、製品相互の連携やパフォーマンスにも安定した性能が期待できる。一方のJ2EEは、複数のベンダが提供する製品を組み合わせることでシステムの自由度を大きくすることは可能だが、同時にさまざまな「複雑さ」「難しさ」を引き受ける覚悟は必要だ。 両者のトレードオフ関係を十分に把握したうえで、導入を計画しているWebアプリケーションにとって最適なプラットフォームを選択していただきたい。
提供：マイクロソフト株式会社
企画：アイティメディア 営業局 制作：アイティメディア 編集局 掲載内容有効期限：2005年5月2日 |
|
||||||||||||||||||||||||||||||
