ビジネス層、永続化層をどう移すか?──Javaコンサルタントが語る、J2EEからJava EE 7への移行のポイント【後編】

Oracle Java & Developers編集部
2014-08-13 11:00:00
  • このエントリーをはてなブックマークに追加

J2EEやサードパーティ・フレームワークで作ったアプリケーションのビジネス層と永続化層をJava EEに移行する際には、どういった点に注意すればよいのだろうか。主なポイントを、日本オラクルのJavaコンサルタントが解説する。

 本企画では、J2EEやサードパーティ・フレームワークで作られた旧式のアプリケーションを、最新のJava EE 7に移行する際のポイントを紹介している。前回はJBoss Seamで開発したプレゼンテーション層をJava EE 7のJSF 2に移行する際の留意点を説明したが、今回はビジネス層と永続化層の移行におけるポイントを紹介する。解説してくれるのは、日本オラクルのJavaコンサルタント、加藤田益嗣氏(テクノロジーコンサルティング統括本部 ITソリューション本部 インプリメンテーションアーキテクト部 シニアコンサルタント)だ。

ビジネス層の移行──Spring FrameworkからJava EE 7のCDIへ

日本オラクル テクノロジーコンサルティング統括本部 ITソリューション本部 インプリメンテーションアーキテクト部 シニアコンサルタントの加藤田益嗣氏
日本オラクル テクノロジーコンサルティング統括本部 ITソリューション本部 インプリメンテーションアーキテクト部 シニアコンサルタントの加藤田益嗣氏

 一般に、ビジネス層の開発では、これをプレゼンテーション層や永続化層といかに綺麗に分離するかが、アプリケーションの柔軟性や開発生産性を高めるうえで大きな鍵となります。その目的から、これまで広く使われてきたのが「Spring Framework」をはじめとするDI(Dependency Injection)コンテナです。Java EE 7でビジネス層を開発する場合にも、Java EE 6から導入された標準のDIコンテナである「CDI(Contexts and Dependency Injection)」を使うのが基本となります。

 ご存じのとおり、今日のJava EEには、従来サードパーティのフレームワークによって補完していた機能が標準で備わっています。それらの機能でカバーできる部分については、サードパーティのフレームワークを使わずにJava EEの標準機能を使うことが、将来にわたってアプリケーションの保守性を高く保ち、ベンダー・ロックインを避けてアプリケーション資産を長期的に保護していくうえで有利になります。既存のアプリケーションでサードパーティのDIコンテナを使っている場合には、アプリケーション・サーバを最新バージョンに更新するタイミングでCDIに置き換えるのがよいでしょう。

 なお、多くの企業で利用されてきたSpring FrameworkからCDIへの移行は、大きな改修を伴うものではありません。どちらもDIという共通の設計思想に基づいているため、アプリケーションの基本構成は大きく変える必要がないのです。もちろん、アノテーションの書き換えなどの作業は必要になりますが、多くの場合は書き換えパターンに沿って機械的に作業できます。ただし、Spring Frameworkを独自にカスタマイズして使っているアプリケーションでは書き換えパターンが適用できなくなるため、作業に手間がかかります。

ビジネス層と他階層が密結合しているアプリケーションはJava EE 7で再設計するのがお勧め

 ビジネス・ロジックの内容は、どのフレームワークを使っていても同じです。そのため、綺麗に作られたビジネス層は、フレームワークを移行した場合でも、比較的、容易に再実装することができます。

 問題になるのは、ビジネス層がプレゼンテーション層や永続化層と密結合しているアプリケーションです。具体的には、各階層の連携部分を独自に作り込んでいたり、HTTPリクエストをビジネス層や永続化層にまで引き継いでいたりする(つまり、プレゼンテーション層に依存した作りになっている)ケースです。

 そうしたアプリケーションは拡張性に乏しく、いずれ保守性や開発生産性の面で問題に突き当たる可能性が高いため、現状の構成のままJava EE 7で再実装することはお勧めしません。まずはアプリケーションの処理を3つの階層に分けて設計し直す必要があります。プレゼンテーション層から値を取得する部分はCDIで疎結合にし、EJBでビジネス・ロジックを実装するというのが、Java EEを使ったビジネス層の基本的なパターンとなります。

 既存のアプリケーションで3階層の分離がうまく実現できているかどうかは、実際にコードを調べてみなければ判断できません。そのこともあり、自社のアプリケーションの状況を正確に把握できていない企業が少なくないようです。前編で紹介したように、日本オラクルのマイグレーション・サービスでは、非互換チェックやソースレベル分析によってアプリケーション実行基盤の移行時に問題となる個所を特定し、作業工数を見積もります。アプリケーションの現状把握や移行コストの見積もり精度に不安を感じる場合は、こうしたサービスも利用するのも1つの方法でしょう。

永続化層の移行──JPAを使うか、それともSQLを使い続けるか

 続いて、永続化層の移行、具体的にはデータベース・アクセス処理の移行について考えてみましょう。

 まず、すでにJPAを利用しているアプリケーションは、そのままJPAを利用して素直にJava EE 7に移行することができます。一方、iBATISのようなサードパーティのO/Rマッピング・フレームワークを使い、SQL主体で作っている場合は、JPAに移行するか、これまでどおりSQLを使い続けるかの決断を迫られることになります。

 iBATISでは、XMLファイルに記述したSQL文をJavaコードから呼び出して実行します。これをJPAに移行すれば、データベース・アクセスをJavaオブジェクトへのアクセスとして抽象化し、SQLを使わずにJavaでデータベースを操作することが可能になります。ただし、アプリケーションによってはSQLを使う方式のままJava EEに移行したほうがよいケースもあります。

 その1つは、JPAの標準機能ではカバーできないようなデータベース操作をSQLで行っているケースです。この場合、JPAに移行したとしても、同じ操作をJPAのSQL互換クエリ言語である「JPQL(J Persistence Query Language)」で作り込むことになり、"車輪の再発明"のような無駄が生じる可能性があります。

 もう1つは、既存の開発体制がSQLに特化しているケースです。SQLを使い慣れた開発者が多い場合、SQL主体の構成のまま移行したほうが、開発生産性や保守性の面で有利でしょう。

 ただし、今後はSQLを直接使う割合を減らし、サードパーティ・フレームワークへの依存をなくしたい、あるいは開発技術をJava EEで標準化したいといった場合には、JPAへの移行を強くお勧めします。

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