アプリケーションサーバを自在に操れ！：28歳から挑戦するITアーキテクト（10）〜実践編〜

アプリケーション構築を行う場合、前回「システム全体を連続稼働に持ち込め！」述べたとおりハードウェア構成やネットワークなどを把握したうえで構築しなければならない。今回は、さらにその上、ソフトウェアの世界であっても、土台となるアプリケーションサーバが登場してくる。現在、企業向けアプリケーションを構築する場合、「アプリケーションサーバ」という名のミドルウェア上で作成するのがほとんどの場合だろう。このアプリケーションサーバ、果たして本当に理解して利用しているだろうか？

切っても切れない関係

　現在の主流プラットフォームであるJava EE、および.NET Frameworkでは、そのほとんどの機能についてアプリケーションサーバ（またはそれ相当の機能）の存在が前提となっている。

　JavaであればJava EE（旧J2EE）対応のアプリケーションサーバだ。.NET Frameworkの場合、IISやMTS等のOSの追加機能の中に入り込んでいるため目立たないが、これはこれで立派なアプリケーションサーバとみることもできるだろう。

　つまり、特に何でもかんでもフルスクラッチのお手製で作る特例を除き、エンタープライズ系の開発の場合、好む好まざるにかかわらず、どうやってもこのアプリケーションサーバが付きまとってくる。

アプリケーションサーバは“ウザい”？

　もともとアプリケーションサーバは、1から作るには難し過ぎる機能や、当たり前過ぎて毎回作るのも問題がある機能などを包含した商用製品からスタートしている。これらの機能は各社各様の勝手仕様だったため、ある程度標準化された結果の仕様がJava EEと考えていいだろう。一方.NET Frameworkは（言語仕様などはISO標準化が進められているものの）事実上マイクロソフトが自社エンタープライズ系製品活用のための統一APIとして策定された経緯があるが、その分便利な機能が一覧できる形で大量に準備されている。

　このため、アプリケーションサーバには調べれば調べるほど魅力的な機能がたくさん用意されているのだ。これらは単なる道具なので使いこなしてこそ生きるのだが、概して筆者の部下をはじめ周りのプログラマはこのアプリケーションサーバを避けたがる。多分読者の方も“ウザい”と思われている方の方が多いことだろう。

　アプリケーションの土台となる比類なき重要な個所にもかかわらず、なぜみんな避けたがるのか。筆者はしばらく想像もつかなかったが、おおよそこんなところなのだろう。

• 細かな内容を調べて動かすのが面倒だし時間がかかる（順応性の退化？）
• 他人が作った機能を信用できない （疑心暗鬼？）
• とにかく自分で作り上げたい （唯我独尊？）

　確かにその主張は理解できないでもないが、やはりすでにある機能を二重に作りデバッグするのは客観的に工数の無駄以外の何物でもない。特に理由がなければ、できる限り標準機能として準備されているアプリケーションサーバ側の機能を積極的に利用したいところだ。

アプリケーションサーバの使い方

　Microsoft .NET Frameworkを利用する場合であれば、否応なくOS側の機能、つまりアプリケーションサーバに相当する機能は多かれ少なかれ利用することになる。開発者が選択すべき範囲は小さいため、それほど困ることもない。問題はJava EE開発の場合だ。

　Javaの場合、多くのOS側が提供する機能、特にネットワークやデータベースに接続するための低レベル機能がJ2EE（現Java EE）の登場する以前からJDK（現Java SE）の標準機能として古くから提供されているため、作り込んだ独自機能を各組織がすでに抱えていることが多い。また、J2EE登場直後の黎明期には、数多くのトラブルや誤解に基づいた混乱が多発したのも事実だ。アプリケーションサーバ側の起動が遅くメモリ食いで開発時の足を引っ張ったことも悪印象として筆者の記憶にも焼き付いている。

　このため、過去古参のプログラマを中心にアプリケーションサーバを避け、「軽量に」独自実装しようという動きもあった。また、オープンソースにて類似機能が大量に出回っているため、選択の幅がはるかに広いことも特徴となる。

　しかし、Java EEが提供する非常にリッチな機能を、長期間にわたり安定して利用・管理するためには、やはり業界挙げて支持されているデファクト・スタンダードとしての機能を（多少使いづらかろうが何だろうが）使う以外選択肢がないのもまた事実だ。開発時の短期費用削減よりも、管理時やマイグレーション時の長期コストまで含めた場合、標準であることの意義は想像よりもはるかに大きい。

　つまり、オープンソースAPI等を基本として渡り歩き毎回つまみ食いするよりも、本腰を入れて業界標準のアプリケーションサーバをまず「飼いなら」し、そのうえで足りない機能を補う方が長期的にリーズナブルである、というのが筆者のこれまでの結論だ（図）。

図 アプリケーションサーバを飼いならせ

アプリケーションサーバの裏で動いている機能

　さて、アプリケーションサーバを飼いならすといっても、何の機能があるのか理解しなければ話は始まらない。

　この表はJava EEと.NET Frameworkの目立った機能を列挙したものだが、エンタープライズ系アプリケーションに必要な機能がおおよそ両者とも網羅されているのが分かるだろう。両者とも名前とまとめ方が違うのだが、実現しようとしている内容も（開発者にとって便利かどうかという差は当然あるが）結果的に大半は似たり寄ったりとなっている。

　特にこの中では、Java ServletやASP.NETなどがよく知られた（目立った）内容だが、アプリケーションサーバが実現している内容はその数倍〜数十倍多岐にわたっており、よくよく調べてみると「あー、そんな機能があったのならスクラッチで作り込むんじゃなかった!!」と後悔することがありがちになる。

　かくいう筆者もJ2EEの黎明（れいめい）期、すでにアプリケーションサーバ側で用意されていた機能を知らず、工数を掛けて作り込んでしまったことがある。納品後その重複に気付いたのだが、非常に後味の悪い記憶として残っている。限られた予算・納期で目的を達成しなければならないITアーキテクトとしては、これはあってはならないことだろう。

アプリケーションサーバを積極的に使い倒せ

　過去、特にJavaの開発シーンでは「フレームワーク」という単語が躍っていた時期がある（筆者もそこで仕事をしていた1人だ）。実はその多くがアプリケーションサーバ側にすでに用意されている機能である場合もあったりしたのだが、それ以上に年月をかけてJava EE側が遅れながらも標準機能としてすでに取り込んでいってしまった個所が多い。

　また、標準に準備されていた場合でも、機能に不足がある場合が多々ある。こうした機能は米国文化圏で策定・実装される場合が多く、特に日本語周りの処理がお粗末であることが意外にもまだ多い。回避すらできない場合もあるため、そのわなに引っ掛からないようにしなければならない。

　つまり、すでに多くの機能は、アプリケーションサーバ側が準備していることが多く、開発側はそれらがどの範囲を、どの程度網羅しているのかという点を常に把握しておかなくてはならないということだ。

　アプリケーションサーバは単なる機能が準備された土台でしかないのだが、それらの機能を熟知し効果的に利用すれば、高品質・短納期という、相反する課題を克服できる可能性が高い。そのための技術的裏付けやプロジェクト方針の決定は、ITアーキテクトが行わなければならないということになる。

　特に新規開発の場合など選択に迫られることが多い立場であれば、アプリケーションサーバの現状や新製品の動向には常に注意を払っておくべきだし、プロを自任するならば、自らの好き嫌いを超えた次元で、それらの選択について戦略的に判断を下すべきだろう。