J2EEの「常識」は常に動いている

星暁雄

2004.04.13

　J2EEによるシステムの「作り方」には，唯一の正解はない。現実のシステム構築事例を見てみると，J2EEの利用技術も変化し，成長していることが分かる。

現状のEJBはまだ未成熟？

　J2EEの技術体系の中では，ユーザー・インタフェースに関する技術と，データ・アクセスに関する技術は変化が大きい。筆者の目には，ユーザー・インタフェースとデータ・アクセスは，J2EEという「領土」の辺境にある国境線のように見える。

　ユーザー・インタフェースに関しては，多くの読者が既にご存じの通り，JSF（JavaServer Faces）の登場で「国境」が変わりつつある。Servlet/JSPから，JSFというよりレベルが高い技術へとシフトしようとしているのだ。先週末に，JSF対応ツールのSun Java Studio CreatorのEA版が利用可能となった。この種のツールを使ってみると，まさに技術のベースが変わりつつあることが実感できる。

　一方，J2EEのデータ・アクセスは，議論が多い分野である。より抽象化のレベルが高い方向，すなわちオブジェクト指向の方向に向かってはいるのだが，本命となる技術を見定めにくい状況なのだ。

　J2EEの技術体系の中では，EJB（Enterprise JavaBeans）がデータ・アクセスの中核的な技術と位置づけられている。そして，EJB技術に含まれるCMP Entity Beanは最も進んだデータ・アクセス機能を持っている。使いこなせば，SQL文を書かないシステム開発が可能になるはずである。

　ところが，現状のEJBを活用したシステムでは，Stateless Session Beanの利用が多い。CMP Entity Beanは，様々な理由で利用が見送られている場合が多い。J2EEの技術群の中でも最も多くの努力が傾けられた機能が，なかなか使われていないのが実際なのだ。

　こうした状況を「J2EEの歪み」と指摘する声もある。現状では，Stateless Session Beanにデータ・アクセス用のSQL文まで何もかも詰め込んでしまうようなシステムが多く，何のためのオブジェクト指向設計だか分からなくない，というのだ。

販売管理システムで，EJBとO-Rマッピング・フレームワークを併用

　先日取材したある事例では，この「歪み」を是正するアプローチが見られた。

　システムの内容は，化粧品の製造販売とエステ店の経営を手がけるフェスタ（本社，東京都千代田区）の販売管理システムである。システムを開発したのは富士通中国システムズ。J2EEによるシステムで，中心となるのは，富士通のアプリケーション・サーバーINTERSTAGEである。全国で100近い店舗からの在庫管理，販売管理などを一手に引き受ける基幹システムを再構築した。

　技術面でのポイントは，アプリケーション・サーバーを取り巻くソフトウエアは最先端のオープンソース製品を投入したことである。Web層ではStruts1.1に，ユーザー・インタフェース部品のライブラリを組み合わせた。一方，データ・アクセス層は，INTERSTAGEが提供するEJB機能（Stateless Session Beanを利用）と，オープンソースのO-R（オブジェクト-リレーショナル）マッピング・フレームワークHibernateを組み合わせた。

　Stateless Session BeanとO-Rマッピング・フレームワークという組み合わせにより，ビジネス・ロジックとデータ・アクセスを分離している。これは，J2EEによるシステム開発のスタイルとして現実的なものといえる。

　原則としてSQLはなるべく使わない方針で開発した。Hibernateにはキャッシュの機能があり，検索系の処理に関しては「下手なSQLを書くより高速」という。ただし，集計処理など，一部の処理に関しては，SQLを発行するJavaクラスを作成して利用している。完全な「SQLレス」はまだ難しい部分もあるようだ。

　このシステムは2003年12月より本格稼働中で，レスポンスも良好という。EJBとO-Rマッピングの組み合わせが有用であることが立証された事例といえる。

既存のJ2EE技術の隙間を埋めるO-Rマッピング

　このように視野を広げてみると，データ・アクセスに関する手段は実はEJB以外にも整いつつあることが分かる。上の事例のように，「O-R（オブジェクト-リレーショナル）マッピング」に関するソフトがいくつか登場し，実際に使われ始めているのだ。

　O-Rマッピングの標準APIとして，JDO（Java Data Objects）がある。ただし，JDOは現在J2EEを構成するAPIセットには含まれておらず，したがってJ2EEアプリケーション・サーバー製品にも実装されていない。

　米BEA Systems社のCTO（最高技術責任者），Scott Dietzen氏は，JDOに関して「J2EEには入れたくない」と語っている。おそらく，同社の立場としてEJB技術の完成度を高める方向にフォーカスしたいということだろう。

　つまり，「EJBを発展・成熟させよう」という考え方と，「EJBにこだわらず，データ・アクセスの効率化を図ろう」という考え方が，J2EEをとりまくエンジニアの中にはある。Java技術の進化やアプリケーション・サーバー製品の進化を戦略的に考えている人は前者の立場に，一方で目の前のシステム開発を極力合理的に実行したい人は後者の立場に立つことになりそうだ。

軽量コンテナ登場，J2EEの将来へ投げかける波紋

　こうした状況で登場してきたものが，「サーブレット，EJBに続く第3のコンテナ」とも言うべきIoC（Inversion of Control）コンテナである。EJBとは違い，POJO（Plain Old Java Object，EJBのような特殊なオブジェクトではない普通のオブジェクト）のコンテナとして機能する。IoCコンテナについてはarton氏の記事に詳しい。この記事に登場するIoCコンテナのSeasar2，Spring Framework，HiveMindなどは，J2EEという技術体系を補完するという見方もできるし，見方によっては，EJBのアンチテーゼといえるかもしれない。

　これらの技術群は，J2EEの将来に対して投げかけられた疑問符でもある。ユーザー・インタフェース分野で，オープンソースのStrutsフレームワークの普及がJava標準フレームワークであるJSF（JavaServer Faces）に大きく影響したように，次世代のデータ・アクセス，そしてソフトウエア・コンポーネントの技術に対して，O-RマッピングやIoCコンテナの分野のオープンソース製品がなんらかの影響を与える可能性もある。