第1回（次世代プラットフォームはWebサービスで決まり）でも触れたように、アプリケーション・サーバはJSP（JavaServer Pages）とServletから成るWebアプリケーションや、EJB（Enterprise JavaBeans）の実行を第1の目的としている。従って、ある業務をアプリケーション・サーバ上で稼働させるには、適切な開発ツールを使用して、JavaまたはJSPベースの業務アプリケーションを作成することになる。そのための開発ツールの条件については、第2回（競争力を左右する統合開発環境）で取り上げた。

　しかし、多くの企業にとっては、業務アプリケーションをゼロから作成することはなるべく避けたいものだ。それは、Javaのコードが書けるプログラマが少ないこともあるが、より本質的なことは、コストと期間をかけて自作するより、市販の業務パッケージや既存の業務システムと接続させた方が安くできるという経済的な理由による。このような事情から、Webサービス時代でも、採用するアプリケーション・サーバを決める際の重要な判断材料は、ほかのソフトウェアとどのように組み合わせることができるかにある。

　アプリケーション・サーバとほかのソフトウェアを連携させる方法は、大別すると2つしかない。入り口となるユーザー・インターフェイスの部分で接続する（つなぐ）か、アプリケーション・サーバのコンテナから呼び出すかだ（図1）。

図1　アプリケーション・サーバから業務パッケージや既存業務システムを呼び出すさまざまな方法

　技術的な難易度で決めるのであれば、入り口でつなぐ方法が簡単でよい。この方法は、一般に企業情報ポータル（Enterprise Information Portal：EIP）と呼ばれるもので、クライアントPCのWebブラウザに表示させるWebページをいくつかに分割し、それぞれに異なる業務アプリケーションを割り当てる。それぞれの分割画面はポートレット（ポータルという言葉に「小さなもの」を示す接尾辞-etteを付けた表現）と呼ばれ、論理的にはそれぞれ独立したWebページとして動作する。

　ポートレットに表示できるのは、アプリケーション・サーバ用開発ツールで作成したJSPベースのWebページだけとは限らない。Webベースのユーザー・インターフェイスを持つ業務パッケージやスタティックなHTMLドキュメントなど、広範囲のソフトウェア画面やデータが表示できるので、低コストで複数業務システムの切り替えを行いたい場合には適している。

　ただし、ポートレットは基本的には独立した存在のため、一方のポートレットで行った処理の結果を他方のポートレットに反映させることができないことには注意する必要があるだろう。例えば、販売管理システム、顧客請求システム、財務会計システムの3つのシステムが独立している場合を考えてみよう。販売管理システムのポートレットに売上データを入力して税込み請求額を計算させても、その結果は他システムのポートレットには反映されない。3つのシステムを統合させるには、顧客請求システムと財務会計システムのポートレットにユーザーが数字を再度打ち込む必要があるのだ。もちろん、ポートレット間連携機能を備えたEIP製品であれば、このような面倒な作業は必要ない。

　次に、アプリケーション・サーバから呼び出す方法を見てみよう。利用するのがBtoB/BtoCなどのコマース関連や、顧客関係管理（CRM）、営業支援システム（SFA）、サプライ・チェーン管理（SCM）などの場合は、アプリケーション・サーバ・ベンダが販売しているファミリ製品から選ぶとよいだろう。そのような製品では、アプリケーション・サーバのWebコンテナやEJBコンテナとの連携能力が最初から確保されているので、ユーザーが試行錯誤して苦労しなくても済むからである。また、同一ファミリに属する製品なので、ユーザー・インターフェイスを共通にできたり、顧客や商品のデータを共通のデータベースに登録して統合管理ができたりといった利点もある。

　それに比べると、統合業務パッケージ（ERP）や既存業務システムのつなぎ込みには、かなり高度なテクニックを必要となる。この種のシステムは、専用のクライアント・ソフトウェアか、独自フォーマットのデータファイルをベースに処理を行う仕組みになっているので、Webアプリケーションから呼び出すには、連携用のプログラムを作成しなければならないことが多いからだ。これを回避する方法としてよく使われるのは、次のような方法である。

●ラッパーによるカプセル化
●CORBA経由の呼び出し
●メッセージ・キュー経由の受け渡し（OLTPの場合）
●ファイル転送（FTP）による送り込み
●ファイル渡し（バッチ方式でよい場合）

　また、接続したい業務パッケージや既存業務システムの数が多い場合は、企業アプリケーション間連携（EAI）を使うのもよい方法だ。EAIは異なるシステム間の仲立ちを目的とするソフトウェアで、データフォーマットの相互変換をするためのツールと、呼び出すアプリケーションとその順番をデータ種類ごとに定義するワークフローの2つの部分で構成されている。フォーマット変換の仕方とワークフローの内容は、ユーザー側で指定する必要はあるが、業務パッケージや既存業務システムごとに、インターフェイスを個別に作るよりは、早くかつ簡単にできるはずだ。もともとEAIはアプリケーション・サーバとは関係のないジャンルであったが、最近ではアプリケーション・サーバから直接利用できる製品が目立つ。

　IBMのアプリケーション・サーバ「WebSphere Application Server」は、業務パッケージや既存業務システムとの統合・連携能力が非常に優れている。世界中でこの製品が高いシェアを占めている理由の1つは、この点にあるといってもいいだろう。また、170種類以上あるファミリ製品という、層の厚さもほかを圧している。ここでは、具体的な製品ごとの優位点を紹介しよう。

　まず、フロントエンドでの統合と連携を実現するEIPには「WebSphere Portal Family V2.1」が用意されている（図2）。EIPとしてのフレームワークはオープンソースの「Jetspeed」をベースとしており、BtoE、BtoB、BtoCのいずれにも対応できるなど、フレームワークとしての拡張性は非常に高い。ポートレット間連携機能も装備されているので、業務アプリケーションの連携を取る目的で使用するのにも適している。ロータスの「K-station」（ナレッジ・ポータル製品）や「Sametime」（リアルタイム・コラボレーション製品）と連携させて使えば、ナレッジワーカーの生産性を高めるのにも大きな効果がある。

図2　「WebSphere Portal Family V2.1」で実現できるEIPの分割Webページ画面の仕組み（画面をクリックすると、拡大表示されます）

　次に、BtoB/BtoCコマース用の「WebSphere Commerce V5」や開発ツールの「WebSphere Commerce Studio」、カタログ作成ツールの「WebSphere Catalog Manager」を利用することで、ECサイトの構築から運用までのすべての作業ができる。また、「WebSphere Commerce Suite, Pro Edition」を利用すれば、ルール・ベースのパーソナライゼーションとリレーションシップ・マーケティングの機能によって、One to Oneマーケティングやオークション機能もサポートできる。

　バックエンドにおける既存業務システムとの統合と連携では、メッセージ・キューを介してこれを実現する「WebSphere MQ」（以前のMQSeries製品）が活躍する。接続可能なプラットフォーム数は35以上と多く、Java関連ではJ2EEのJMS（Java Message Service）にも対応している。MQSeriesは、メッセージ・キューの実質的な業界標準なので、他ベンダのOLTP製品でも採用例は非常に多い。また、WebSphere MQにはEAI関係のソフトウェアも含まれており、データのフォーマット変換を行う「WebSphere MQ Integrator」（旧称MQSeries Integrator）、社内業務間の関係を定義する社内ワークフローの「WebSphere MQ Process Manager」（旧称MQSeries Workflow）、企業間の業務の関係を定義する企業間ワークフローの「WebSphere Partner Agreement Manager」、全体をまとめるビジネス・インテグレーションの「WebSphere Business Integrator」などが利用できる。

　ビジネス向けのシステム開発に携わるエンジニアの間では、「サーバ・コンピューティングは、アプリケーション・サーバ上のJ2EEで」が常識だ。機能や処理速度の面でもほかの方式をしのぐまでになった。来るべきWebサービス時代にも、この方式が必ずやメインストリームとなるだろう。そのため、IBMの「WebSphere Application Server」が、Webサービス時代にも最良のアプリケーション・サーバとして、企業ユーザーに選ばれるのは確実だろう。

Index
Webサービス時代のプラットフォームの条件
	第1回	次世代プラットフォームはWebサービスで決まり
	第2回	競争力を左右する統合開発環境
	第3回	Webアプリケーション・サーバを業務に導入する場合のポイント