検証 新世代リッチ・クライアントの可能性を探る（前編） 1．本記事の目的と想定する技術・環境 野畠英明 ヒューレット・パッカード・ソリューションデリバリ（株） 2003/05/13

本記事の構成と使用する技術／製品

　本記事では、前編・後編の2回に分けて、Webサービス・クライアントとしてOfficeを利用する具体的な方法、ソリューションの実際について解説していく。このうち今回の前編では、Webサービスに関する簡単な導入と、Office XPにWebサービス機能を追加可能にするOffice XP Web Service Toolkitの紹介、本稿で想定するソリューションの構成、必要となるソフトウェアの導入を行い、最後に簡単なサンプルを紹介する。後編では、実際のソリューション例として営業支援システムを想定し、具体的なシナリオに沿って、Webサービス活用の勘所を洗い出していく。

　すでに触れたものもあるが、本稿では次の技術や製品を使用して具体的なソリューションを構築する。

• Microsoft Office XP（クライアント側）
• Office XP Web Services Toolkit
• Webサービス（HTTP、SOAP、WSDL）
• J2EE、BEA WebLogic Server（サーバ側）

　マイクロソフトのサーバ・ソリューションでは、IIS 5.0（Internet Information Services）＋ASP.NETを利用することになるが、通常の業務システムでは、さまざまなプラットフォームが混在しているものだ。そこで今回は、クライアントとサーバの双方をマイクロソフト製品で統一するのではなく、あえてサーバ側にJavaベースの製品を使用することにした。具体的には、日本BEAシステムズのWebLogic ServerをWebアプリケーション・サーバとして使用する。

Webサービスの現状とこの記事での位置付け

　「Webサービス」という言葉自体は、ほとんどの方がご存じだろう。W3CのWeb Services Glossary（原稿執筆時点での最新版である2002年11月14日版のワーキング・ドラフト）によると、次のような2つの定義がなされている。

• URIで識別されるソフトウェア・システムで、XMLによって公開インターフェイスとバインディングが定義・記述されている。これらの定義はほかのソフトウェア・システムから発見可能で、ほかのシステムは、発見した定義に基づいて、そのWebサービスとXMLベースのメッセージをインターネットの標準的なプロトコルを利用してやりとりできる。

• エンドポイントの集合

　難しい表現だが、「XMLによって公開インターフェイスとバインディング（結び付け）が定義・記述されている」というのは、一般的にはWSDL（Web Services Description Language＝Webサービスが提供する機能を記述するための、XMLベースの言語仕様の1つ）だと理解すればよい。また、「XMLベースのメッセージをインターネットの標準的なプロトコルを利用してやりとりできる」でいう「標準的なプロトコル」は、HTTP上のSOAPを利用するものと理解すればよい。まとめると、標準技術（WSDL、HTTP、SOAP）を使ってアクセスできるサービスを指すと思っておけばいいだろう。インターネットで広く使われている「標準技術」を使用するというところがポイントである。ただアクセスできればよいのであれば、いままでも多数の技術があった。Webブラウザさえあれば、多彩なWebアプリケーションにアクセスできるのと同じように、Webサービスを利用すれば、多彩なシステムとごく普通にアクセスできるところが利点だ。

　WSDLやSOAPといった技術についてもう少し詳しく知りたい方は、以下の記事が参考になるだろう。

• XML & Web Servicesフォーラム：Webサービスの基本

　現在は、SOAPやWSDLをベース・テクノロジとして使用し、さらに高度なセキュリティやトランザクション、ビジネス・プロセス・マネジメントなどのサービスに関する標準化作業が進められている段階である（この詳細については、Insider.NETの「次世代XML Webサービスを試す」を参照）。これに対し、ベース・テクノロジであるHTTPやSOAP、WSDLといった技術に関しては、主要な製品はほぼ対応している。例えばマイクロソフトは、同社の標準Webサービス・プラットフォームである.NET Frameworkに加え、SOAP ToolkitというCOMベースの製品も提供している（SOAP Toolkitについては、Office XP Web Services Toolkitと併せて後述する）。また、Java関連では、各種J2EE準拠のアプリケーション・サーバ製品が対応している。WSDLに基づいて、HTTP上のSOAPで通信するという基本的なWebサービス対応機能なら、主要なアプリケーション・サーバのほとんどが対応しているといっていい状況だ（ただし、複雑なデータ型など、一部相互運用性の問題はある）。

　今度はクライアント側に目を移してみよう。Webサービス・クライアントとしてのOfficeというと、定型フォームを使ったデータの入力支援ツールであり、標準でWebサービス対応機能も持つOffice 2003のInfoPathを思い浮かべる方もいるだろう。確かにInfoPathは魅力的なプラットフォームだが、今回紹介するソリューションでは、あくまでも普段の作業に利用しているOffice製品をそのままWebサービス・クライアントとして活用する。単純に「業務システムのカスタム・ユーザー・インターフェイスを作成する」というよりは、「使い慣れた道具をそのまま使う」「WordやExcelの機能を生かす」というところを狙いとしている。何よりInfoPathを利用するためには、Office 2003を新規に購入する必要がある。またInfoPathは、Office Professional Enterprise Editionのみにバンドルの予定であることから、だれにでもすぐに利用可能な機能とはいえない。InfoPathの詳細については、以下の記事を参照されたい。

• Insider.NET：「InfoPathの衝撃」

　以上を踏まえて、本稿では、現時点で間違いなく利用可能な状態にある基本的な要素技術のレベルで、Webサービスを「異種プラットフォームを簡便につなぐもの」と位置付け、具体的な利用方法を紹介することにする。

Webアプリケーションとのシステム構成比較

　最初に、OfficeをWebサービス・クライアントとして利用すると、既存のWebアプリケーションと比較してどこがどう変わるのか、システム構成の観点から比較してみたい。この比較では、シン・クライアントかリッチ・クライアントかという観点に加え、Webブラウザの特性やOfficeの特性が関係してくる。

タイプ	特徴	適当でないケース
Webアプリケーション	・ クライアントとしてWebブラウザが動作する環境があればよく、多様なデバイスに対応可能 ・ 基本的にサーバ・サイドだけで完結する構成 ・ ポータルという形態にすることで、Webアプリケーション上で、ワン・ストップのサービスを提供したり、システム間の連携を実現したりすることが可能	・ 最終的に作成したいもの（報告書など）がOfficeで作られる場合 ・ リアルタイム性（応答性）が重要な場合 ・ 部署単位、部門単位でアプリケーションをカスタマイズしたり、個別ニーズに合わせて短いサイクルで業務を改善したりする場合 ・ オフラインで作業したい場合
Office＋Webサービス	・ 日常的にOfficeを使っている人なら、ユーザー・インターフェイスには慣れている ・ Officeの豊富な機能を生かせる（Wordなら高度なレイアウトやきれいな印刷、Excelなら表計算やグラフ作成など） ・ サービスの根幹にかかわるような変更でなければ、複数サービスのインテグレーションも含め、サーバ側の変更なしにVBA（Visual Basic for Applications）で作成可能 ・ データの入力やすでに取得したデータの参照であれば、オフラインでも可能	・ Windows以外のOS、PC以外のデバイスから利用する場合 ・ Officeの機能・インターフェイスが生かせない場合
OfficeをWebサービス・クライアントとして利用する場合と、Webアプリケーションを利用する場合の比較

　次に問題となるのは、OfficeをWebサービス・クライアントとして利用することにしたとして、クライアントとサーバでどのように処理を分担するかということである。大ざっぱには、既存のシステムがあるなら、業務レベルで意味のある単位で区切ってWebサービスとして公開し（このような単位を「粒度」と呼ぶ）、それをOfficeから利用することになるだろう。細かいところでは、ケース・バイ・ケースだと思われる。ただし、一般的には次のようなことがいえる。

処理	適切な処理内容
クライアント	・ ユーザー・インターフェイスにかかわる部分 ・ ローカル・リソース（ファイルなど）を参照したり変更したりする処理 ・ サーバの負荷を軽減したい場合（最近のPCの処理能力はかなり高いので、これをうまく使えば、サーバにかかる負荷を軽減することができる） ・ 現場に近いところで頻繁なロジックの変更を行うような処理
サーバ	・ 入力データの正当性チェック。これらは、サーバ側で厳密に（少なくとも、業務やセキュリティ上問題のないレベルで）行う必要がある ・ ロジックの変更などをエンド・ユーザーに透過的に行える、認証・権限などのセキュリティ管理、リソースのコントロール、厳格な運用管理（障害・性能監視など）など。これらをサーバ側で行えば、集中管理が可能になるので有利
クライアント側とサーバ側での処理の切り分け

　以上をまとめると、WebブラウザとOfficeの機能性の違いを考慮した上で、扱う業務の影響範囲によって、構成を適宜選ぶことになる。つまり、全社的に提供すべきサービスや、業務プロセスで比較的安定しているものは、Webアプリケーションが適しているだろうし、部門・部署などより現場に近いところで個別ニーズに合わせる必要のある場合は、Officeを利用して、クライアント・サイドである程度業務プロセスも含めて扱うのがよい。

Office XP Web Services Toolkitとは

　Office XP Web Services Toolkit（以下Office XP WST）は、Office XPでWebサービスを手軽に利用できるようにするために、マイクロソフトが無償公開しているツールキットである。Officeには、VBAでマクロを記述する機能があるが、Office XP WSTはこの開発環境であるVisual Basic Editorのアドインとして動作し、WSDLからプロキシ・クラス（サーバ側のWebサービスをあたかもローカル・クラスのようにプログラムから呼び出し可能にするためのクラス）を自動生成するものだ。開発者の方なら、Visual Studio .NETでのWeb参照と似たものだといえば、ピンとくるかもしれない。

　このツールキットの最新バージョンは2.0で、ランタイムとしてSOAP Toolkit 3.0を用いる。

• Office XP Web Services Toolkit 2.0の入手先
  

　いま、SOAP Toolkit 3.0ランタイムを使用すると述べたことから分かるとおり、Office XP WSTはあくまでも開発環境であり、プロキシ・クラスを生成するためのものなので、実行環境ではインストールの必要はない。実行環境では、SOAP Toolkitのみがあればよい。また開発時にはOffice XPが必要だが、Office XP固有の機能を使っていなければ、作成したものをOffice 2000で利用することも可能である。

　SOAP Toolkitについて簡単に解説しておくと、これはCOMクライアントからWebサービスをアクセスしたり、COMサーバをWebサービス化したりする機能を持った製品で、以下から単体でダウンロード可能である。

• SOAP Toolkit 3.0の入手先（マイクロソフト）

　クライアント側では、OfficeとSOAP Toolkitさえインストールされていれば、後はWordのファイルやExcelファイルを単純に開くだけで、Webサービス・クライアントとして動作する。つまり、利用にあたってセットアップ・プログラムを起動するとか、何かを登録するといった特別なインストール作業は不要である。

サンプルの想定構成

　本記事では、次の図のようなシステム構成を想定する。つまり、1台のWindows PC上で、OfficeとWebLogic Serverが動作しており、WebLogic Server上には、複数のWebサービスが配置されている。ここでOfficeは必要に応じて、複数のWebサービスとアクセスする、という具合である。

今回想定するシステム構成

今回は、このように1台のWindows PC上で、OfficeとWebLogic Serverを動作させ、WebLogic Server上で、複数のWebサービスを配置する。Officeは必要に応じて、複数のWebサービスとアクセス可能とする。

　もちろん、実際の環境では、OfficeとWebLogic Serverは同一マシン上にある必要はないし、Webサービス自体、複数のマシンに分散している場合もあるだろう。また、Webサービスは、WebLogic Server以外の環境で動作するものでもよい。

サンプルで利用するソフトウェアの導入

　それでは、Office XP WSTとWebLogic Serverのインストールを行うことにしよう。WebLogic Serverは有償ソフトウェアであるが、今回はテスト用として、無償でダウンロードできるWebLogic Server 7.0Jの評価版を使うことにする（すでにWebLogic Server 8.1Jが提供されているが、今回はWebLogic Server 7.0Jを利用している）。

　まず、以下のページから、Office XP WSTをダウンロードし、システムにインストールする。

• Office XP Web Service Toolkit 2.0の入手先（マイクロソフト）

　次に、以下の日本BEAシステムズのホームページから、WebLogic Server 7.0の評価版をダウンロードしてシステムにインストールする。

• WebLogic Server 7.0J評価版の入手先（日本BEAシステムズ）

　WebLogic Serverのインスタンスは、パッケージに最初から入っているExamples Serverという付属サンプルのテスト用インスタンスを流用する（ただし、当然ながら実際の運用では、個別ポリシーに応じて設計されるべきであるので、このインスタンスを流用しないでいただきたい）。インスタンスという言葉を使ったが、これはIISでいうサイトのようなもので、ここでは特定の設定で動作するWebLogic Serverのプロセスといった意味で使っている。例えば、同じマシン上で本番用プロセス、テスト用プロセスという2つ設定のWebLogic Serverをセットアップするような状況で、本番用プロセスを「本番用インスタンス」と呼んで区別する。

　WebLogic Serverのインストール時には、次の3つの項目が問い合わせられる。ここでは、以下に示すとおりに指定していただきたい。何かの事情でディレクトリを変える必要がある場合は、必要な部分だけを読みかえていただきたい。

設定項目	本記事での想定
BEAホーム	C:\bea
標準インストールかカスタム・インストールか	標準インストールを選ぶ。これによりExamples Serverがインストールされるので、それを使う
製品インストール・ディレクトリの指定（以降では%WL_HOME%と表記する）	C:\bea\weblogic700
WebLogic Serverインストール時の設定項目

　

INDEX
	新世代リッチ・クライアントの可能性を探る（前編）
	1．本稿の目的と想定する技術・環境
	2．簡単なサンプルの作成と実行
	新世代リッチ・クライアントの可能性を探る（後編）
	1．営業支援システムを作る
	2．営業支援システムの利用シナリオ（1）
	3．営業支援システムの利用シナリオ（2）
	4．サンプル実装の設計

　

検証

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