最新Java EE環境への一刻も早い移行が、企業のエンタープライズ開発を危機から救う──Java Day Tokyo 2013レポート

builder by ZDNet Japan Ad Special
2013-07-26 11:15:00
  • このエントリーをはてなブックマークに追加

Java EEはエンタープライズ開発の危機を救う


日本オラクル コンサルティングサービス統括 テクノロジーソリューションコンサルティング統括本部クラウド&ITソリューションコンサルティング本部 ソリューションマネージャーの大橋勝之氏

 Java SEからJava Embedded(組み込みJava)まで、幅広い領域におけるJavaの最新動向をカバーしたJava Day Tokyo 2013において、エンタープライズ開発にフォーカスしたJava EEに関するセッションの1つとして、日本オラクルでJavaに関するコンサルティング・サービスを提供する大橋氏が講演を実施。エンタープライズ開発において、J2EE 1.4など旧来のJava EE環境から最新のJava EE環境への移行が急がれる背景と、それがもたらすメリットを説明した。

 大橋氏は冒頭、エンタープライズJavaプラットフォームの進化の歴史を振り返った。1999年末にリリースされた最初のバージョンであるJ2EE 1.2より、堅牢性やWebサービスなどエンタープライズ・システムに求められる機能を貪欲に取り込むかたちで進化してきたJava EEだが、2006年にリリースされたJava EE 5からは、AOP(アスペクト指向プログラミング)、CoC(Conventions over Configurations:設定から規約へ)、DI(Dependency Injection:依存性の注入)といった最新のコンセプトや技術を取り入れ、より開発生産性や柔軟性の高いプラットフォームとして進化してきた。今年6月にリリースされるJava EE 7は、その最新の成果となる。

 大橋氏は、こうしたJava EE自体の進化と比べると、「日本のエンタープライズ開発の現場は大きく変わっていない」と嘆く。多くの開発現場で、いまだに旧式のJava EEが主流を占めている背景には、企業が独自の開発スタイルやアーキテクチャを持ち、 "車輪の再発明"や独自実装に固執して変化を嫌う風潮があるからだと看破し、そのために「プラットフォームは進化しているのに、業務としての開発は、以前と比べてあまり効率的なものになっていない」(大橋氏)と指摘する。

 こうした現場の状況は、「日本のエンタープライズ開発にとっての危機だ」と大橋氏は警鐘を鳴らす。

 「日本のエンタープライズ開発は、一部の優秀な技術者によって支えられているという現実がある。今、彼らに大きな負担がかかっている。時代遅れのガバナンス、業務の中で旧態依然とした技術としか向き合えないといった状況では、新しい技術や考え方を取り入れ、技術者個人としての価値を継続的に高めていきたいという彼らの欲求には応えられない。このことは結果的に、エンタープライズ開発の現場から優秀な技術者を流出させてしまうことにつながる」(大橋氏)

 企業がJava EEへの移行を進めることは、このような状況を変えるためにも意味があるのだ。

 最新の標準技術であるJava EEを使うことで得られるメリットとして、大橋氏は大きく次の4つを挙げる。

  • システム開発のガバナンス強化
  • 技術者の業務に対する満足度向上による、定着促進と作業品質の向上
  • 社内技術者のスキル向上の容易化
  • 外部からの技術者調達の容易化

 特に「技術者の業務に対する満足度向上」という観点からは、グローバルで通用する標準技術としての Java EEのスキルを高めることにより、 「技術者個人としての価値を向上させられる」ことと、 「開発生産性の向上によって 業務を従来よりも大幅に効率化できる」ことが、優秀な人材の流出を防ぎ、成果物の品質を高めるための大切な要素になる。

Java EEのメリットを生かすための3つのポイント

 続いて大橋氏は、企業が旧式のJava EE環境から最新のJava EE環境への移行を進めるにあたり、最初に念頭に置くべき「3つのポイント」を示した。それらのポイントとは、「(1)DRY化促進による運用維持コストの削減」、「(2)JSFによるコンポーネント・ベース開発」、「(3)CDIによるコンポーネントの疎結合化」である。

  「(1)DRY(Don't Repeat Yourself)化促進による運用維持コストの削減」とは、最新のJava EE環境への移行により、旧式のJava EEをベースにした開発における、さまざまな"重複"のコストを削減していくという視点だ。

 大橋氏によれば、旧Java EEベースの開発を続けていくことで、「サードパーティ製のJava EEフレームワーク」と「非標準のAPIをベースにした独自の業務フレームワーク」の間で重複が発生し、特にプラットフォーム更改時などに検証や対応のコストが高くなりがちになるというデメリットが生じる。最新のJava EE環境への移行は、そうしたフレームワークの重複管理の手間をなくし、なおかつ既存のアプリケーション資産を保護するうえでも有効なのだ。

  「最新のJava EE対応アプリケーション・サーバの上では、J2EE 1.4ベースのアプリケーションを動作させることが可能だ。これにより、最新のプラットフォーム上で実行することによる性能向上などのメリットを享受できる。

 また、Java EE 6以降ではWebアプリケーション・フレームワークが標準機能として取り込まれているので、既存のアプリケーションを動かしつつ、今後開発するシステムについては最新のJava EEへの対応を意識することにより、全体としての生産性向上と運用維持コスト削減の両立が可能になる」(大橋氏)

 具体的には、新規に作るWebアプリケーションについては、リクエスト処理フロー制御で最新のJava EEの標準機能だけを使うように構成すればよい。これにより、更改まで手を付けずにおきたいJ2EE 1.4アプリケーションを動かしつつ、容易かつ徐々に最新のJava EE環境へ移行していけるようになる。

 なお、移行を進める際には、「開発基盤側で用意すべき機能は何か」、「Java EEの標準技術をどう使うか」、「標準技術で足りない機能をどう補完するか」、「今後の周辺環境の変化にどう対応していくか」といったことを含む、エンタープライズ開発に関する戦略の見直しを行うことが重要になる。

JSFによるコンポーネント・ベース開発で生産性を向上

 「(2)JSFによるコンポーネント・ベース開発」に関しては、ユーザー・インタフェース(UI)フレームワークとしてのJSFの活用が鍵になる。大橋氏は、「日本では、Strutsや、それに類似したカスタム・フレームワークからの脱却に前向きでないことが、最新のJava EEへの移行を阻害する要因の1つになっている」と指摘する。

 「実際に現場の方に話を伺うと、『このままではダメで、いつかは変えなければいけない』と感じている方が多い。それでも踏み切れない理由としては、『慣れ』、『新たな技術の習得にかかるコスト』、『(国内における)導入事例情報の少なさ』などが挙げられる。

 もっとも、こうした理由からSIerの皆さんが及び腰な一方で、ユーザー企業の中には最新のJava EEへの移行に積極的なところが出てきている。その背景には、運用維持のコストの削減や開発のグローバル化への対応などのニーズがあるようだ」(大橋氏)

 また、2013年4月にStruts 1の開発停止がアナウンスされたことも、企業が早急に最新のJava EE環境への移行を進めるべき理由の1つだ。

 Java EEの1要素であるJSFは、画面上にUI部品を配置し、それにJavaクラスのフィールドとメソッドをマッピングしていくことで生産性の高い開発が行えるコンポーネント・ベースのフレームワークである。JSFを採用することで、「煩わしいHTTPリクエスト処理の実装が不要となり、開発やテストが容易に行える」、「コンポーネントの再利用が容易になる」といったメリットを受けられる。

 最新のJSF 2.xはWebアプリケーション・フレームワークに必要とされる機能を標準で備えており、これを活用してStrutsなど旧式のフレームワークからの移行を進めることで、Java EE開発の生産性を大幅に高められるのである。

 「パフォーマンス面でJSFに不安を感じるという方もおられるようだが、大規模でスケーラビリティが求められるシステムでは、必要に応じてJAX-RSでアクション・ベースに処理を実装できる。アクション・ベースであっても、コンポーネント・ベースであっても、現在のJava EEにはエンタープライズ・アプリケーションの開発に必要な機能が標準機能としてひととおり備わっている。これらを利用して、徐々にレガシーな環境をなくしていくことが、将来的な維持コストの削減につながる」(大橋氏)

CDIで標準技術ベースのコンポーネント化を促進

 最後の「(3)CDIによるコンポーネントの疎結合化」で挙げられたCDI(Contexts and Dependency Injection)は、Java EEに標準で備わるDI機能だ。これを活用することで、J2EE 1.4のようにサードパーティのプロダクトを使うことなくコンポーネント化を促進し、フレームワーク実装への依存性を弱めることが可能になる。また、バグの局所化やテストの容易化、コンポーネント単位での置き換えなどへの対応も可能になる。

 大橋氏は、CDIを使うことのメリットとして、「業務アプリケーションにフレームワークの部品をインジェクト(注入)することで、フレームワーク実装への依存性を下げ、APIは維持しつつ、さらに周辺技術の変化に対応するかたちで、注入したコンポーネントだけを後から変更することが可能になる」と説明する。

 CDIでは、インジェクトされるインスタンスはコンテキストで管理される。具体的には、スコープ内で初めのインジェクト時にインスタンスが生成され、スコープの終わりに解放されるという動作となり、同一のスコープ内であれば同じインスタンスが注入される。そのため、同一スコープ内でのインスタンスの再利用を意識する必要はない。

  またCDIでは、インスタンスの動的な取得が可能であることを利用し、監視情報のイベントを送出したり、フレームワーク部品のパラメータを動的に変更したりすることなどが可能になるという。これらの特性を活用することで、Java EEアプリケーションの開発やメンテナンスがさらに容易になるのだ。

現場の課題を解決する機能は、すでに最新のJava EEに用意されている

 大橋氏は最後に、まとめとして「3つのポイント」を振り返りながら 「これらはJava EEの要素の一部に過ぎないが、この3つを押さえておけば、Java EE開発の導入としては十分。 そこから先の段階に進んでいくことができる」と語り、次のような言葉で講演を締めくくった。

 「私は、盲目的に『Java EEを使ってほしい』と言うつもりはない。しかし、実際に最新のJava EEは、皆さんの現場が抱える課題を解決するためのさまざまな機能を備えている。今、自社の現場が抱える課題の解決に使えると感じたら、すぐにでも最新のJava EEへの移行を進めてほしい。 そして、来年のJava関連イベントでは、ぜひ皆さんのJava EE導入事例を発表して、それを広くシェアしていただきたい。それが、Java EEのさらなる発展につながり、また他のユーザーにとっても大きなメリットになる」(大橋氏)

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]