支えるテクノロジー
先に述べた企業システムにおいて、システムアーキテクチャの要求を絞り込むと、「ライフサイクルの違い」、「ミドル接続での吸収」、「多様化するチャネルと標準化」に表される。
ライフサイクルの違いは、コンポーネント化やオブジェクト指向といった技術で実現される。
ミドル接続での吸収は、メッセージキューイングやメッセージハブと呼ばれる製品、J2EE（Java2 Enterprise Edition）で規定されるJMS（Java Message Service）、MDB（Message Driven Beans）といった技術が該当する。
多様化するチャネルと標準化も、コンポーネント化やオブジェクト指向を手段とし、さらにフレームワークやXML（ISOで規定されたものも含む）などのアプリケーションプロトコルが技術的な要素となる。こういったテクノロジーをサポートし、企業システムとしてのシステムアーキテクチャを実装するための存在はアプリケーションサーバといえる。
■製品状況
 |
|---|
| システムの層構造 |
主要なアプリケーションサーバ製品を表1にまとめてみた（2003年7月14日現在）。日本国内で販売サポートが行われているものと、国産のもの、オープンソースソフトウェアのものである。今回は、Linuxで稼動する製品に限定した。結果的にJ2EEが前提の製品のみとなっている。
アプリケーションサーバは、ビジネスロジックやシステム製品などのライフサイクルの違いからくる修正要求に対して、影響を最小限にするために層構造になっている（図3）。
各ベンダーは差別化のため独自拡張機能があるが、多くはJ2EEフレームワーク上に構築される。またベンダー独自拡張が、あとで標準的なフレームワークとしてJ2EEに採用されることもある。基本的にはJ2EEに準拠し、ハードウェアやOS、アプリケーションサーバの独自機能を使わなければ、どのアプリケーションサーバでもアプリケーションプログラムは稼動する。J2EEフレームワークよりも下の層で、より高いコストパフォーマンスと信頼性のバランスが適した製品を再選択することも理論上は可能となり、ベンダーの都合に振り回される可能性も小さくできるといえよう。
| 製品名 | 国内提供元 |
|---|---|
| WebSphere Application Server 5.0.2 | 日本IBM |
| BEA WebLogic Server 8.1J | 日本BEAシステムズ |
| Oracle9i Application Server R2 | 日本オラクル |
| Sun ONE Application Server 7 | サン・マイクロシステムズ |
| Borland Enterprise Server 5.2 | ボーランド |
| Interstage V 6 | 富士通 |
| ActiveGlobe WebOTX V5.2 | 日本電気 |
| Tomcat 4.2 | Apache Jakarta Project |
| JBoss 3.2 | JBoss Group, Inc. |
| Enhydra 5.0 | Enhydra.org Project |
J2EE
J2EEは複数のテクノロジーの集合である。それらのテクノロジーはJCP（Java Community Process、http://www.jcp.org/）によって仕様が策定されている。世界最大の半導体メーカーから日本の電機メーカー、世界中のITベンダーが参画しており、公正であるといえる（ただし、マイクロソフトは参画していない）。
実際にはJ2EEはJava言語によって作成され、アプリケーションサーバのようなサーバサイドで動作するプログラムモジュールの仕様である。これらは、プレゼンテーション用、コンポーネント用、メッセージング用、接続用、管理用に分類できる。表2に、通常のJavaであるJ2SDKに含まれるものもあわせてまとめた。
・プレゼンテーション
ServletとJSPは、Webページを動的に生成するための仕組みである。両者は、ロジック実装に近いのがServletであり、決まった枠を用意してテンプレート的な実装を行うのがJSPである。Webページの特性やデータ量に応じて選択する。
Servletはロジック実装の中心となることもできるため、典型的な落とし穴としてプレゼンテーションとビジネスロジック、それらをコントロールするロジックを混在させて記述してしまうことがあった。昨今はこの問題を解決するデザインとして、MVCモデルという考え方がある。MVCはModel、View、Controllerの頭文字だが、ビジネスロジックとプレゼンテーション、アプリケーション制御という役割ごとに依存関係を排除し、変更に強いシステムとすることが目的である。代表的なのがStrutsというフレームワークである。これはApache Jakartaプロジェクト（http://jakarta.apache.org/）でServletを作成したCraig R McClanahan氏が主となっていることもあってか、Servletの落とし穴を解決し、柔軟性の高いフレームワークとして現在注目を浴びている。
プレゼンテーション層は最もシステムユーザーに近い層で動作するため、特にBtoCの場合に多様性の実現と開発効率、見た目のパフォーマンスは重要といえる。
・コンポーネント
コンポーネントとは部品のことであり、単体では単純な機能しか提供できないが、その部品が寄り集まって何がしかの機能を実現するものである。
子供のころに遊んだおもちゃのブロックから巨大なビルまでの建造物、昨今の工業製品など、これらはほぼすべてが部品の集合体である。自動車業界では、メーカーの系列を越えて部品の共通化を行っていたりする。それは、短期間に多品種少量生産を低コストで行い、勝ち残るために自ずと出てきた答えでしかない。
J2EEでもEJBというコンポーネントの仕様に準拠して作成すれば、アプリケーションサーバの系列を越えて利用することができる。ある意味、最も重要なロジック実装を行うという、大切な役割を担う。
EJBはSession Bean、Entity Bean、MDB（Message Driven Bean）という3つのコンポーネントがある。ビジネスロジックはSession Beanに記述し、Entity Beanはデータベース接続を表現し、MDBはメッセージをトリガーとして非同期のEJBインスタンスを起動するものである。これら3つのEJBとプレゼンテーションを司るServletとJSPを設計し、作成して開発を行うこととなる。
EJBのようなコンポーネントでは設計が最も重要になる。オブジェクト指向の理解と、UML（Unified Modeling Language）を駆使し、デザインパターンに基づいた要件定義と設計の過程が有効となっている。再利用性が高く、ビジネスロジックの変更にも強く、短期間でかつ高品質が求められる。したがってシステム構築を請け負うSIベンダー側でも、こういったプロセスを簡易化するためのさまざまなフレームワーク開発に力を入れている。
・メッセージング
ユーザー向けの報告書の郵便や電子メール、システム間通信は同じメッセージ送受信のチャネルの違いでしかない。これまでは送受信先ごとに電文設計を行い、開発していた。現在はこれらのプロセスが統合する方向にあるといえる。この要となるのがXMLである。XMLによって注文や決済というトランザクションデータと、プルーフリストが同じデータストリームとして実現され、結果を暗号化して報告書として送信する際も同じデータストリームを使用できる。
事実上のデファクトになっているPDFもXML対応がなされたため、PDF化も容易になった。
各社のRDBMSもXMLデータストリーム格納への対応が進み、企業間通信で使用されるメッセージキューイングやメッセージハブ製品でもXMLが当たり前のように使われる。データベースから取り出したデータを加工してチャネルごとに送受信するプログラムを作成しなくて済むわけだから、インパクトは大きい。この点を踏まえてJ2EEのメッセージングを理解したほうがよい。
JMSは、XMLに限らずあらゆるデータを送受信する機能を標準化するので、システム間通信で有効である。
JavaMailは、その名の通り電子メールの送受信機能を標準化する。
JAXPとJAXRは、XMLデータの送受信時の手続きを標準化する。
・接続
データベースとの接続や、一貫性のあるトランザクション制御、名前解決（ディレクトリサービス対応）、セキュリティ認証などが必要となる。これらを標準化し、実際の接続先を抽象化する機能が用意されている。
JTAはトランザクションサービスを提供し、JCAはシステム間接続の作成を標準化する機能である。
JDBCはデータベース接続を、JNDIはディレクトリサービス接続を、JAASは認証機能をそれぞれ標準化する。
・管理
初期のJ2EEには管理機能はなかったが、今日では整備されてきた。JMXでアプリケーションサーバのリソース管理が標準化され、J2EE Deploymentでアプリケーションサーバへの配布が標準化された。このことで、システム運用と保守といった際に、ベンダーツールの品質とコスト面でも有利といえ、独自のカスタマイズを行った場合でもそのノウハウが永続的なものとなる。つまり、安価でかつ高品質なシステム稼動に結びつくことになる。
| 用途 | 名称 |
|---|---|
| プレゼンテーション | Servlet JSP（Java Server Pages） |
| コンポーネント | EJB（Enterprise Java Beans） |
| メッセージング | JMS（Java Message Service） JAXP（Java API for XML Parsing） JAXR（Java API for XML Registries） |
| 接続 | JTA(Java Transaction Architecture) JCA(J2EE Connector Architecture) JDBC（Java Database Connectivity） JNDI（Java Naming and Directory Interface） JAAS（Java Authentication and Authorization Service） |
| 管理 |
JMX（Java Management Extensions） J2EE Deployment |
アプリケーションサーバの相関モデル
アプリケーションサーバが連携する場合の例として、相関関係を表した場合は図4のようになる。 これは、とある金融機関の個人向けサービスと、その社内オペレーション、自社のディーリングと市場への接続といった関係を、アプリケーションサーバを中心に、どういったモデルイメージになるかを表す。まずはこういったモデルイメージがあることが重要だ。そこでどういった相手と接続することになり、どういった技術と機能が必要になるかが直感的にわかる。そこからデータトランザクション量に基づいてサーバ数などのシステム全体サイズを決定し、ライセンスコストや導入実績、現行自社システムからの移行コスト、アプリケーションサーバ提供ベンダーのサポート体制などを加味して、最適なアプリケーションサーバ製品を選択するのが理想だといえる。
開発ツールと開発方法論
システム開発の現場の人間が使うツールに関しても、アプリケーションサーバとの協調が重要となる。特に、開発ツールは使い勝手や将来にわたっての永続性と教育コストやライセンスコストなど、システム規模が大きくなるほどコストインパクトが大きくなる。
中でもBorlandのJBuilderは、中立性と対応するアプリケーションサーバの数から、開発ツールのマーケットシェアで有利な状況にあったが、eclipse（http://www.eclipse.org/）推進企業によるオープンコミュニティが立ち上がり、開発ツールのプラットフォームが定義された。基本機能は無償で使用可能なので非常に注目度が高く、ユーザー数が増えているようだ。元々は、IBMが開発ツールとして提供しているWebSphere Studioという製品のベース部分を公開したものである。そのほかにも、アプリケーションサーバ提供ベンダーが製品化している開発ツールもあり、多少限定的にはなるがアプリケーションサーバとの親和性が高い。
開発方法論が企業方針として決定されることが多くなっており、大手のシステム構築ベンダーやコンサルティングファームには独自の方法論を持っている場合もある。体系化された製品としてRationalのRUP（Rational Unified Process）採用を公式に発表する企業もある。アジャイルプロセスや、エクストリームプログラミングなど、先鋭的な開発方法が模索されているのも、短期間高品質低コストというグローバリズムへの対応が企業システムに求められていることから必然かもしれない。
アプリケーションサーバの世界
 |
|---|
| アプリケーションサーバにおける相関関係 |
アプリケーションサーバを主体とした基幹システムの事例は増えている。業種の傾向として保守的な部類に入る金融でも増加しているのが現状だ。
一般的に先鋭的なシステムを持つ企業は「勝ち組」に多く、旧来のシステムの問題を引きずり続けている企業は「負け組」が多い。
旧来のシステムからの脱却は決して容易では無い。多様化する中で、インフラストラクチャーやハードウェアにソフトウェア、過去のアプリケーションとの関連やその量、対応チャネルにビジネスモデルとビジネスプロセス、システム構築プロセスと各種ツール群と体制、あらゆる要素に万全である必要がある。システムを作る側と依頼をする側、それぞれにアプリケーションサーバに対する理解が求められる。
新たなシステム構築プロセスとツールで効率を上げ、コストを下げるためにシステムを作る側は人的にも物理的にも投資を行わなければならない。結果的に、初期コストは安くはならない。安くなるのは新たなシステムとの連携や統合と、追加および改修のコストである。得るものは時間が短くなることによって生じる機会利益だ。
機会利益は先行者利益と非常に近い。悪循環な負け組は、初期コストが安くない時点で諦め、旧来のシステムを使い続け、先行者利益が限りなくゼロになった頃に動き始めることもある。
短い記事ではあるが、何らかのヒントやきっかけになっていただければ幸いである。次回以降はより詳細かつ具体的な話を進める予定である。
