「J2EE(Java2 Platform, Enterprise Edition)」と聞いて,あなたはどのようなイメージを持つだろうか。

 「なんだ,Javaプログラマではない自分は関係ないさ」と思う読者もおられるかもしれない。そう思った方には,ぜひこの記事の最後まで目を通していただきたい。なぜなら,すべての企業ユーザーが,遅かれ早かれJ2EEと向き合うことになるからだ。なるべく多くの方に読んでいただけるよう,この記事では専門用語をなるべく使わずJ2EEのインパクトを説明してみたい。

 最もシンプルにJ2EEを定義するなら,企業システム構築に関するJava API(アプリケーション・プログラム・インタフェース)の集合である――ということになる。だが,これではダメだ。インパクトがまったく分からない。Java APIを「フレームワーク」と言い換えてみよう(注1)。多少マシになったが,まだ分かりにくい。

注1)Java言語の設計者James Gosling氏は「すべてのJava APIはフレームワークであり,すべてのJavaオブジェクトはコンポーネントだ」と語っている。「フレームワーク」という用語の適用範囲に関してはいろいろな考え方があるが,Java技術の思想としては,こういうことなのだ。

 J2EEとは,情報化投資を積み上げて行くための土台である。「プログラマが知っていればいい」というレベルの理解ではもう済まされない。J2EEを選択するか否か,あるいはどのように利用するのか。ある規模以上のシステム開発に携わる人間なら,必ず直面する問題である。小規模のシステム構築技術には選択肢がいくつもあるが,大規模になるとJ2EEは避けて通れなくなるからだ。

 まずは,実際にJ2EEによるシステム開発に携わった方々の声から紹介したい。

「J2EEは,カオスの中に現れた新秩序」

 「J2EEは,混沌とした時代に,新たな秩序をもたらすもの」。こう語るのは,日立ソフトウェアエンジニアリング インターネットビジネス部部長の中村輝雄氏である。

 IBMメインフレームの全盛期には,IBMという一つの会社がシステム・アーキテクチャを作り上げ,製品として実装し,システム構築に適用して実績を作るまで,すべてを取り仕切っていた。同社が提供していたのは,単にメインフレームという箱だけではない。その上のシステム開発のための技術体系,習得すべきスキルセットを「込み」にして提供していたのだ。

 1990年代,PCの実力が企業システムの要求に耐えるまでに向上し,PCクライアントとDBサーバーを組み合わせたクライアント/サーバー・システムが登場した。クライアント/サーバー・システムとは,PC,開発ツール,データベース,ネットワークなど,複数のベンダーの製品の組み合わせであり,それぞれのベンダーの戦略に大きく左右される。PCの価格対性能比の良さは,システム開発のコストを引き下げたが,同時にメインフレーム時代の秩序,スキルセットを破壊した。90年代のシステム開発は,混沌とした時代だった。

 この状況のもと,J2EEは登場し,普及した(注2)。誰もが,複数のベンダーの製品に共通して使える,末永く使える技術を必要としていたのだ。

注2)中村氏の技術論は,新刊「入門 J2EEシステム開発」に詳しい。本コラムはJ2EEのインパクトに絞って説明したが,この書籍ではソース・コードを交えてJ2EEの概要を説明している。

「リスク・ミニマムならJ2EE」

 J2EEベースのアプリケーション・サーバーを全社インフラとして導入しつつある清水建設情報システム部課長の安井昌男氏は,「リスク・ミニマムを考えるとJ2EEになった」と語る(注3)。

注3)本日(2002年9月25日)から開催中のJavaOneでは,ユーザー事例報告のセッションが多数ある(同社の事例については,筆者が担当する「J2EEユーザー・パネル」で取り上げる)。

 「まず実績と,技術情報の流通量。3層システム,Webベース。そしてオブジェクト指向設計との親和性,可用性,レスポンス,保守性,安定性,共通部門の業務を「横串」のように各部門から見ることができるシステムを作れること。こうしたいろいろな要件を積み上げて行くと,プラットフォームは必然的にJ2EEになった」(同氏)

 決して先端的なシステムを作りたい訳ではなかった。要は,確実に動けばそれでいいのである。この前提からJ2EE採用という結論が出てきた。J2EEが普通のシステム技術になったことが分かる。

「長期的な開発ならEJB」

 1998~99年という早い段階に,EJB(Enterprise JavaBeans,J2EEの要素技術の一つ)に基づく基幹システム再構築を決めたカスミ取締役(当時,現・顧問)の神林飛志氏は「あえて言うと,J2EEは必須条件ではない」と語っている。「なぜなら,J2EEであるだけでは品質を保証したことにはならない」と。

 こうした厳しい言い方をする一方で,氏は「EJBによる基幹システム構築」という,当時としては冒険的な着想を実行に移した張本人でもある。何年間も保守,拡張しつづける基幹システムには,長期的に利用可能な技術が必要。それは「EJBしかなかった」と言い切る。実際,EJBは,安易に導入できるものではない。基幹系で長期にわたり利用する場合に有効な技術なのだ。

 今,カスミの基幹システムは,開発に協力したイーシー・ワンからパッケージとして外販中である。このシステムはEJBコンポーネントの集合であり,必要な部分をカスタマイズすることにも対応可能という。同社は,ユーザーの立場から,コンポーネント提供者の立場に移った。現状では先端的な事例に見えるかもしれないが,こうした展開は将来は当たり前になる可能性もある。J2EEとは,それだけのポテンシャルを持った技術だからだ。

J2EEを支えるJCP

 J2EEとは,1999年にJava技術の開発元であるSun Microsystems社が提唱した新しい技術体系である。では,J2EEとはSunという一つの会社が定める技術なのだろうか? それなら,Sunという会社の方針が変わったら,消えてしまうかもしれないではないか。

 「J2EEとはSunが定めたもの」という説明は1999年には正しかったが,今では不正解だ。J2EEを構成する技術群の仕様を決めているのはJCP(Java Community Process)と呼ぶ仕組みである。平たく言うと,Java技術の「標準化団体」だと思えばよい。そこにはライバル関係にある何十もの企業・団体が集まり,議論と投票を繰り返して仕様策定を進めている。1社がすべてを決めているわけではない。

 Sun,IBM,Oracle,BEA Systems,Borland,IONA,Macromedia,富士通,日立製作所など,競合している会社同士が,J2EEという一つの技術体系を共同で開発し,製品化している。この記事を執筆している最中にも,SAP R/3が開発環境として新たにJ2EEをサポートするとの発表があった。各社は,互いに競合関係にあったとしても,J2EEという技術体系に関しては運命共同体なのだ。業界標準としてのJ2EEのインパクトを維持しているのは,このJCPの枠組みだといってよい。

 今では製品だけでなく,J2EEの要素技術を実装したオープンソース・ソフトウエアも出回っている。Servletコンテナとしてよく使われているApache Tomcatや,EJBサーバーのJBossが代表例だ。

 一昔前のコンピュータ産業を知る者としては,これだけ競合が激しい分野で各社の足並みが揃っている状況は信じがたいことである。信じがたいことが起きた理由は,「企業インフラ向けの共通の開発環境」が本当に必要だった,ということに尽きる。1社で開発環境を整え,開発者支援(教育,サポートなど)の体勢を作り上げ,アップデートを続けて行くことは,大変な仕事である。J2EEは,ちょうどタイミングよく登場し,共通の開発環境としての地位を占めたのだ。

 むろん,J2EEは万能ではない。J2EEとは開発環境,つまり「作る」技術である。システム構築の局面では,実装以前に分析・設計のフェーズが重要だし,作った後の運用も大事だ。J2EEですべてが完結するわけではなく,設計や運用の方法論と一緒に使うべきものだ。幸い,オブジェクト指向設計とJ2EEは元々相性がいい。UML記述からシステムのかなりの部分を自動生成する仕組みを開発中のベンダーもある。運用支援の分野では,J2EE対応のパフォーマンス監視ツールなども登場している。

 また,システム同士を「つなぐ」技術としてWebサービス技術が台頭してきている。Java技術によるWebサービス対応は現時点で可能ではあるが,J2EEという形での標準化は進行中の段階である。これは今後の課題ということになる。J2EEは難易度が高いと感じ,手軽に使える開発環境がもっと出てきてほしいと考える企業ユーザーもいる。ただし,これらは技術的に解決可能な問題である。いずれ解決されるだろう。

 今まで見てきたように,必要な情報は,「J2EEを採用すべきか」から「J2EEにどう取り組むか」に移っている。こうした思いから,IT ProにJ2EEサイトを設置した。このサイトをより良いものに育てていきたいと考えている。

(星 暁雄=日経Javaレビュー編集長)