特集 スマート・クライアントの傾向と対策 日本ユニシス 猪股健太郎 2004/05/15
Page1 Page2 Page3 Page4

スマート・クライアントをどうやって作るか

　さて、スマート・クライアントとして「何を」作るかが明確になったら、次は要求を満たすために「どうやって」作るかです。最初に、スマート・クライアントに不可欠な、導入や運用を容易にするための技術について解説します。次に、スマート・クライアントを低コストで実装するプラットフォームについて解説します。

スマート・クライアント・システムの構築技術

■導入・運用コストの削減

●ビジネス・ロジックのサーバ集約化

　クライアント・アプリケーションに、プレゼンテーション、ビジネス、データ・アクセスの3つをすべて含めてしまうと、拡張性や再利用性を高めることが難しいうえに、アプリケーションの更新に大きなコストがかかるため、ビジネス環境の変化に対応していくのが難しくなります。これが、従来の2層クライアント／サーバ型アプリケーションの問題点でした。この問題を解決するために、ビジネスおよびデータ・アクセスのロジックはサーバ側に置き、クライアント・アプリケーションはプレゼンテーションに専念する、いわゆる多層型アプリケーションが考えられました。

　スマート・クライアントでも同様で、運用コストを下げるためにビジネスおよびデータ・アクセスのロジックはサーバ側に置くことが推奨されます。では、スマート・クライアントと、多層クライアント／サーバ型アプリケーションとの違いは何でしょうか。それは、通信プロトコルにあります。

　多層クライアント／サーバ型アプリケーションでは、クライアントとサーバとの通信にはDCOMやCORBAといった分散オブジェクトの技術が使われていました。しかし分散オブジェクト技術はシステム環境に対する制約が多かったため、自由な運用が困難でした。一方、スマート・クライアントではクライアントとサーバとの通信プロトコルはXML Webサービスが基本となります。XML Webサービスを使えば、Javaで作られている既存サーバ・アプリケーションのロジックをXML Webサービスを通じて公開して、.NET Frameworkで作られたスマート・クライアントから再利用する、といったようなシステム構成が可能になります。

　.NET FrameworkでXML Webサービスを作成する方法は2種類あります。異機種環境での相互運用性が重要視される場合にはASP.NETによるXML Webサービスが、分散オブジェクト技術が要求される場合には.NETリモート処理（.NET Remoting）とSOAPフォーマッタの組み合わせが、それぞれ利用できます。

●インストールしない

　Webアプリケーションはなぜ導入・運用が容易なのでしょうか。一番の理由は、アプリケーションはすべてサーバ側にあり、クライアントへのインストールが不要だからだと考えます。インストールがいらないため、クライアント環境とアプリケーションとの間の依存関係をなくすことが可能なのです。

　スマート・クライアントで、そのような「インストールしない」という選択を可能にする技術は3つあります。ノータッチ・デプロイメント、Office XP Web Services Toolkit／Office 2003 Web Services Toolkit、そしてVisual Studio Tools for Microsoft Office Systemです。

1）ノータッチ・デプロイメント
　.NET Frameworkアプリケーションをネットワーク越しに直接起動させることで導入・運用を容易にする配布方法がノータッチ・デプロイメントです。Internet Explorerを使って、アプリケーションへのリンクをクリックすると、アプリケーションが.NETアプリケーションであれば、自動的にダウンロードされ起動します。

　当然のことですが、ネットワークを通じて実行するプログラムはデフォルトで強いセキュリティ制約がかかっています。ローカル資源を活用する業務アプリケーションをノータッチ・デプロイメントで配布する場合は、あらかじめクライアントのセキュリティ・ポリシーを変更しなければなりません（詳細後述）。また、ノータッチ・デプロイメントの詳細は、「特集：ノータッチ・デプロイメント」を参照してください。

2）Office XP Web Services Toolkit／Office 2003 Web Services Toolkit
　Office XP Web Services Toolkitは、Office XPのドキュメントからXML Webサービスを呼び出すためのツールです。このツールがあれば、VBA （Visual Basic for Applications）でXML Webサービスを呼び出すためのプロキシ・クラスを自動生成できます。XML Webサービスを呼び出すようなマクロを埋め込んだOffice XPのドキュメント・ファイルとしてクライアントを作成すれば、ファイルの配布がすなわちアプリケーションの配布となります。クライアントにはOffice XPとOffice XP Web Services Toolkitの両方がインストールされている必要がありますから、厳密には「インストールしない」には当てはまりませんが、少なくとも業務アプリケーションのインストールは不要になります。

　また、Office 2003の場合には、Office 2003 Web Services Toolkitが利用できます。Office 2003ではWebサービスを呼び出すためのOffice SOAP 3.0が初めからインストールされるので、クライアントにはOffice 2003をインストールするだけで、Office 2003 Web Services Toolkitをインストールする必要はありません。

3）Visual Studio Tools for Microsoft Office System
　「クライアントに.NET FrameworkとOffice 2003がインストールされていること」という前提が付きますが、このツールは強力です。このツールを使うと、.NETアセンブリを呼び出すようなWord 2003またはExcel 2003のドキュメントを開発できます。2）の場合は開発環境がVBAでしたが、こちらはVisual Studio .NET上で、C#やVB.NETを使ってアセンブリを開発できるのです。

　そして、ここが強力なところなのですが、クライアントに配布する方法が3種類あるのです。それは、ドキュメントとアセンブリをまとめてローカルのフォルダにコピーしてもらう方法（ローカル＆ローカル）と、ドキュメントをローカルに置き、アセンブリはノータッチ・デプロイメントで実行する方法（ローカル＆ネットワーク）と、ドキュメントもアセンブリもネットワーク上に置く方法（ネットワーク＆ネットワーク）です。詳細は、「技術解説：Office 2003で変わる業務アプリケーション」を参照してください。

●インストールの自動化

　とはいえ、クライアントPCに何もインストールしないままでやれることというのは、実は限られています。先ほどの例を見直してみましょう。

　まず、どの場合であってもアプリケーションの実行プラットフォームとなる.NET FrameworkやOfficeはインストールしなければなりません。それに、ノータッチ・デプロイメントの自由度を上げるためにセキュリティ・ポリシーを変更する場合、ユーザーが手で設定するのは大変なので、設定変更を自動化するようなインストーラを作成したりもします（クライアント全体のセキュリティ・ポリシーの変更については、MSDNの「.NET Framework エンタープライズ セキュリティ ポリシーの管理と導入」や「セキュリティ ポリシーの配置」が参考になります）。マイクロソフトはこの問題を解決するClickOnce（クリックワンス）という技術を準備中ですが、2004年5月時点ではまだ利用できません。

　インストールの自動化に使える既存の道具はないのでしょうか。実はあります。ログオン・スクリプト（ActiveDirectoryのグループ・ポリシーの機能）です。ログオン・スクリプトはActiveDirectoryによって管理されたドメイン内でしか使えませんが、強力な道具です。ユーザーがActiveDirectoryのドメインに参加しているコンピュータにログオンするときに、任意のプログラムを自動実行させることができます。従って、ログオン・スクリプトを使ってスマート・クライアントのインストールや更新を強制することができるというわけです。

●更新の自動化

　そして、クライアントにアプリケーションをインストールしてしまうと、今度はアプリケーションの更新が問題になります。

　業務に変更があり、新しい業務に対応してアプリケーションを修正したとします。修正した部分が業務ロジックの細かな点で、サーバ側のモジュールを変更するだけで済むのであればよいのですが、配布したクライアント・アプリケーションを更新してもらう必要がある場合は問題です。そこで、クライアント・アプリケーションに自分自身を自動的に更新する機能を持たせましょう。クライアントの更新が必要になれば更新を促すダイアログを表示し、ユーザーがボタンをクリックするだけでクライアント・モジュールをダウンロードする、そんな機能です。

　マイクロソフトは、自動更新機能を持ったアプリケーションの開発を手助けするため、さまざまな情報を提供しています。自動更新機能をコンポーネントとしてまとめた「.NET Application Updater Component」や、バックグランド・インテリジェント転送サービス（BITS）を利用したサンプル・コードである「Updater Application Block for .NET」、それからマイクロソフトのエバンジェリストである荒井省三氏による「クライアント・アプリケーション自動更新メカニズムの提案」などです。それぞれメカニズムや実装は異なりますので、必要に応じて使い分けるとよいでしょう。

　また、Office 2003でスマート・クライアントを作成している場合は、MSDNの「方法：配置した Office ドキュメントを更新する 」を参考にしてください。

■コラム 　参考のため、ClickOnce技術についても触れておきます。ClickOnceとは、2005年上半期にリリースが予定されている次期.NET Frameworkで利用可能になる、.NETアプリケーションの配布を簡単にする技術です。詳細はMSDNの「“ClickOnce”によるクライアント アプリケーションの配置の紹介」を読んでいただくとして、ごく簡単にいえばノータッチ・デプロイメントに自動インストール・自動更新を取り込んだ技術です。 　ClickOnceでは、サーバ上にアプリケーションを配置します。ユーザーがそのアプリケーションへのリンクをクリックすると、インストールが不要なアプリケーションであればそのまま実行され、インストールが必要なアプリケーションであればインストールのための確認ダイアログが表示されます。 　なお、アプリケーションの動作のためにセキュリティ設定をゆるめる必要がある場合は確認ダイアログに警告メッセージが付加され、インストールを許可すると、自動的に設定が変更されます。インストールしたアプリケーションを起動すると自動的にサーバに問い合わせて、新しいバージョンが利用可能になっていれば更新のための確認ダイアログが表示されます。ユーザーは自身の判断で更新を受け入れたり拒絶したりできます。また、更新を受け入れたバージョンが正しく動作しないような場合には、ユーザーはアプリケーションを古いバージョンに戻すこともできます。

●バージョン管理

　アプリケーションを更新する際に問題になるのが、ライブラリ（DLL）のバージョンの競合です。複数のアプリケーションが同じライブラリに依存していたとき（つまり、複数のアプリケーションで1つのライブラリを共有していたとき）、あるアプリケーションを更新することで共有しているライブラリも更新されてしまい、そのせいでほかのアプリケーションが動作しなくなる……。このいわゆるDLL地獄（DLL Hell）問題を防ぐのが「サイド・バイ・サイド（Side By Side）アセンブリ」です。

　サイド・バイ・サイド・アセンブリでは、古いライブラリと新しいライブラリが共存できます。また、ライブラリに依存するアプリケーションを作る際には、どのバージョンのライブラリに依存しているのかを指定できます。従って、ライブラリの更新による悪影響がありません。

　サイド・バイ・サイド・アセンブリは、Windows XP以降（Win32アセンブリ）または.NET Framework（.NETアセンブリ）でサポートされている機能です。サイド・バイ・サイド・アセンブリの詳細は、「技術解説：DLL Hellを解消する新しいWindowsインストーラとアセンブリ」の「3．新しいサイド・バイ・サイド・コンポーネントのサポート」や「コラム：.NETとWin32のサイド・バイ・サイド共有コンポーネント」を参照してください。

INDEX
	［特集］スマート・クライアントの傾向と対策
	1．スマート・クライアントの位置付け
	2．スマート・クライアントに何を求めるか
	3．どうやって作るか − 導入・運用コストの削減ために
	4．どうやって作るか − 実装コストの削減のために

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）