【特別企画】アプリケーションサーバで変わるWebサービス（第1回）～アプリケーションサーバとは？

業種を問わずビジネスニーズとトレンドから、企業システムに対する変更要求は年々その数とスピードを増している。こうした変更要求に対する解決策として最も注目されているものに、アプリケーションサーバと呼ばれる存在がある。

　アプリケーションサーバとその取り巻きを中心としたソリューションを認識してはいるが、うっかりしている間にその存在は進化し、複雑度を増し、周囲と結合し、距離が遠くなっていると感じている人が多いのではないだろうか。この機会を利用してアプリケーションサーバとはなんぞやという観点で、最初はテクニカルな話は避けつつ、改めて取り上げていきたいと思う。
　パートナーやお客様を始めとした、さまざま方々と取り組むシステム構築プロジェクトという仕事の中で、最近はアプリケーションサーバという存在が必ずつきまとう。筆者は、以前とある金融機関に勤めており、ユーザーという立場でアプリケーションサーバに関わっていたが、その存在を無視できなくなった頃から、アプリケーションサーバという言葉の持つ意味が曖昧であると感じていた。
　コミュニケーションにおいて言葉の意味が曖昧だと、伝えたい内容が伝わらない。誤解を生じたまま話が進んでしまい、気がついたときのロスが大きくなる。
　誰もが知らないことを聞くことを恥だと思わなければよいのだが、知ったふりをするのは意思決定権のある人間であることも多いため始末が悪い。

アプリケーションサーバに至るまで

　日本の高度成長期からバブルの始まりまでの時代を中心に、これまで企業の基幹システムはメインフレーム上でファイルシステム型のデータベースを使用し、アセンブラやCOBOLといった言語を使って作られてきた。その後、バブルが弾け始めた90年代初頭から、安価になったPCをシステムに利用する流れが生まれた。クライアント／サーバ型システムである。
　信頼性よりも安価であるという点が注目されたが、目的は変化に対応するためであったり、競合他社よりも先駆となるためであったりと、ユーザーの本音はさまざまであったと思う。
　しかし、クライアント／サーバ型には欠点があった。クライアント側とサーバ側は依存性が高く、接続性と保守性が低く不安定であり、思いのほかコストが高くついたのである。これを解決するため、3層型のシステムアーキテクチャが登場した。これは、クライアント側とサーバ側の間にミドル層を置くことで、双方の依存性を小さくするという試みである。ある意味、このミドル層がミドルウェアとしてのアプリケーションサーバという考えの赤ん坊といえるかもしれない。
　とはいえ、まだ問題もあった。メインフレームではビジネスルールにあたるビジネスロジックは、当然メインフレーム内部に実装されるわけだが、クライアント／サーバ型や3層型のシステムではクライアント、ミドル、サーバと各層にビジネスロジックが分散することになる。
　しかも、ビジネスロジック的に依存関係を排除しつつ分散することは、極めて高度な設計と実装が求められる結果となり、多くの場合、保守性の低下とコスト増大のカオスは解決されなかったといえる。
　人間の考えることは、大きな流れで捉えると教訓を元に調和が取れる方向に向かう。そういう意味で、3層型のシステムでの問題を受け、解決するやり方を人は考えるのである。ビジネスロジックの依存性を少なくし独立性を高め、保守性も高め、誰でも訓練を積めば高度な設計実装が一握りの天才抜きで可能になる......そんな現実的なシステム構築ができないものだろうかと。この頃から「アプリケーションサーバ」という発想の源泉が生まれたといえる。
　ところが、時を同じくして誰もが想像しなかった巨大なうねりが始まる。今ではあたり前のインターネットとその関連技術である。
　当初のインターネットは、書籍と同様な静的なページの閲覧に加えて、メールやニュースといったサービス程度だった。現在ではショッピングやオークション、金融商品のトレーディング、ブロードキャストにビデオ会議、携帯電話に家庭用ゲーム機、イントラネットからエクストラネット、VPNによる企業間システム接続と、時空を超えるインフラとして定着しているのは明らかであろう。新たなチャネルの成立である。そのチャネルの形態に応じたサービス技術全般は、Webサービスと呼ばれている。今後も新たな技術が開発され、Webサービスが多様化していく流れはとまりそうにない。

エンタープライズシステムに要求されるもの

　企業システムから見て、新たなチャネルの成立はビジネスチャンスでもある。ユーザーニーズが技術を発展させ、技術は新たなユーザーニーズを生み出す。ユーザーニーズを満足させることがビジネスの原則でもある。
　しかし、ビジネスチャンスを活かすために与えられる時間はあまりにも短く、米国主導のグローバリズムで激しい競争にさらされている。特にグローバル化した企業にとって、取りうる選択肢は2つに1つしかない。戦うか、撤退し敗北するかである。
　現実には軍資金に限りがあり、その中で最大限の効果を発揮する武器が求められる。武器となるシステムが必要であり、システムの根幹である優れたシステムアーキテクチャが求められる。
　戦いに勝つためにシステムアーキテクチャがクリアしなければならない課題はなんであろうか。新たなチャネルのように変化せざるをえないもの、自社のビジネスルールのように原則的に決算期サイクル程度に長期的な期間にわたって変更されないもの、業種によるが国際法および国内法によって取り決められる長期的だが不定期に変更せざるをえないものなど、企業システムが対応しなければならない対象は生存期間（ライフサイクル）が異なる。システムアーキテクチャは、こういった多様なライフサイクルへの対応が必須といえる。

ミドル同士が接続することで実現するモデル

　新たなチャネルのひとつに、企業間取引というものがある。BtoBといわれるモデルのことである。　ここでいう企業とは、取引所や日本銀行といった公共性の高い組織をも含む。以前からローカルルールに基づいた接続もあるのでまったく新しいわけではないが、より汎用的かつ標準的な接続手法という意味では新たな領域となる。さらに、北米や欧州で採用され推進されている、ISOによる標準化の影響もある。
　同じ技術に基づいた標準的な接続手法を用いて、部品や資材調達から商品の発注と決済までを行い、ヒト・モノ・カネの徹底的な合理化があらゆる業種で求められている。そういった標準的な接続手法に自前のシステムが対応するために、ゼロから作り直すのは現実的ではない。金も時間もかかり、完成する頃には世の中の状況が変わっていたりする。こういった場合は、3層モデルのクライアントにあたる層が接続先他社システムとなり、ミドル同士が接続することで実現するモデルとなる。変更はミドル同士の接続部分に限定できれば、現実的かつ理想的なシステムアーキテクチャといえよう（図1）。
　BtoCのモデルは、インターネットによってチャネルがもっとも多様化されたといえる。初期の頃のWebサイトは、HTMLファイルをエディタやツールを使用して手作業で作成したページを、ブラウザで閲覧するというスタイルだった。そこから扱う情報量が増え、人手にかかる人件費の採算割れを防ぐために、ページ作成を自動化する発想が出てくる。
　また、たとえば何がしかの注文を受けつけるWebサイトでは、双方向でのデータ授受を行うために24時間365日人手は張りつけられない。応答処理を自動化し、データベース処理を行う必然性や、セキュリティが万全であること、トランザクションやセッションの保持という課題が持ちあがってくる。ブラウザという新たなチャネルから生じた新たな要求も、システムアーキテクチャとして実現しなければならなくなった。

図2 標準化されたシステムアーキテクチャ

　BtoCモデルは、ブラウザのようなユーザー作業による直接的な処理要求と異なる側面もある。たとえば、米国では国民がPC上の会計ソフト経由で税務署に申告を行っている。日本でも着々と準備は進んでいるようで、来年の2月から名古屋国税局を皮切りに段階的に始まる予定だそうだ。厳密にいえばCtoBなのかもしれないが、金融機関から自己の取引情報をデータの形で自動取得した内容が、そのまま確定申告書に反映され、確認後に送信するだけという流れが実現しそうだ。こうなれば、BtoCtoBモデルである。そしてB（企業）側には不特定多数のC（ユーザー）とやり取りするための、C側にも不特定多数のBとやり取りするための標準化されたシステムアーキテクチャが求められる（図2）。
　こうしたエンタープライズシステムに要求されるものを実現するための中心となるのが、アプリケーションサーバである。もちろんデータベースやインフラを支える、さまざまなサーバなしでは成り立ちをえない。