三菱UFJのアーキテクトとアリエルのCTOが本音で語る、Java EE 6への取り組み方と導入効果、そしてJava EE 7の価値 【後編】

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

 旧Java EEシステムからJava EE 6に移行する際のポイントは? Java EE 7の注目ポイントはどこか? ユーザー企業のアーキテクトらが本音で議論した。

Java EE 6でシステム・アーキテクチャの選択肢が増える

 前編に続き、日本オラクルが2013年8月22日に開催したITマネジメント層を対象とするセミナー「最新のJavaを3時間で知る! Java解説セミナー」から、最後に実施されたパネル・ディスカッション「Java EE 7 First Impression - Java EE 6導入効果とJava EE 7へ至る道」の模様を紹介する。パネラーとして壇上に立ったのは、Java EE 6の導入に取り組んできた三菱UFJインフォメーションテクノロジーの斉藤賢哉氏(ITプロディース部 部長)と、アリエル・ネットワークの井上誠一郎氏(取締役CTO。ワークスアプリケーションズのゲストフェローを兼務)である。

 実際の取り組みなども通じて、Java EE 6には大きな導入メリットがあると確信した斉藤氏と井上氏だが、今後J2EE 1.4など旧Java EEベースのシステムからJava EE 6へと移行する開発者に対しては、どのようなアドバイスがあるのだろうか。これに関して、斉藤氏は「あまり指摘されていないが、重要なポイントだと感じていることがある」と切り出し、次のように語った。


三菱UFJインフォメーションテクノロジー ITプロディース部 部長の斉藤賢哉氏

 「J2EE 1.4の頃は、J2EEパターンなどで3層構造の重厚長大なアーキテクチャが提唱されていました。プレゼンテーション層とビジネス・ロジック層、エンティティ層に明確に分けて作りましょうというわけです。これは、将来的にプレゼンテーション層の部分がWeb以外のものに変わったときでも、ビジネス・ロジック層から後ろのレイヤが影響を受けないようにという配慮によるものです。私自身、このアプローチで旧UFJ銀行のダイレクト・バンキング・システムを構築するなど恩恵を受けており、この考え方を否定するつもりは毛頭ありません。

 しかし、すべてのシステムを厳密な3層構造で作る必要はないとも感じていました。Ruby on Railsのようなアプローチで小さくコンパクトに作ることができてもよいのではないかと。Java EE 6に関しては、こうした点に関する柔軟が高まっていると強く感じます。Contexts and Dependency Injection(CDI)によってコンポーネント間を疎結合にしたり、EJBコンポーネントをWARファイルに入れられたりするので、小さなWebアプリケーションを手軽に作ることも可能になっているのです。

 こうした点は、開発生産性や保守性の高さと併せてJava EE 6のメリットだと感じる部分でもありますし、旧バージョンの印象からJava EE 6をオーベースペックだと感じている方にとっては、移行を検討する際の重要なポイントでもあると思います」(斉藤氏)

 要はJava EE 6では、システム・アーキテクチャの選択肢が増えているというわけだ。

既存システムをJava EE 6にどう移行するか

 一方、井上氏も、かつてのJava EEが重厚長大なアーキテクチャであったという斉藤氏の指摘に同意し、次のように語った。


アリエル・ネットワーク 取締役CTO/ワークスアプリケーションズ ゲストフェローの井上誠一郎氏

 「私も、かつてのJava EEは少しやりすぎだなと感じていました。問題は、アーキテクチャのレイヤ(論理階層)を分けて管理することと、ティア(物理階層)を分けることに混乱が生じてしまった点にあるのかもしれません。実際のところ、(前編の図でも紹介した)『ドメイン層』や『データソース層』は論理階層であって、これらをEJBとしてカバーしつつ別の物理階層にして疎結合化/分散化を強く押し進めたことが、従来のEJBの問題点の1つではないかと思っています」(井上氏)

 それでは、斉藤氏と井上氏が「極端だった」と指摘する方向性が軌道修正されたJava EE 6に旧Java EE環境やJava+オープンソース・フレームワーク環境から移行する際には、どのようなアプローチをとればよいのだろうか。

 「既存システムをJava EE 6に移行する場合、まず初めにリクエスト処理やレスポンス生成を行うWeb層の部分を他の論理構造から分離します。Javaコードの中にHTMLの断片が入っていたりするようなコードは、HTML5が主流になるこれからのシステム開発ではありえません。まずはここをきちんと分離してください。このときに使えるのがJavaServer Pages(JSP)やJavaServer Pages Standard Tag Library(JSTL)、Expression Language(EL)、JAX-RSなどの技術です」(井上氏)

 JSPは、かつて「HTMLの中にJavaコードの断片を書き込む」というアプローチの典型的な技術だと見なされていたが、現在のJSPはJSTLやELといった補完技術の登場により、「同じ名前を引き継いではいるけれども、実態はまったく異なるものになった」(井上氏)という。

 次のステップでは、コードをCDIベースに置き換えていく。具体的には、多くのシステムで疎結合を実現するために多用されているFactoryパターンを、CDIを使った疎結合で整理していくわけだ。「かなりの大改造になりますが、これも1つの移行ステップです」と井上氏は語る。

 「そのうえで、私なら、次のステップとしてEJBなどを使ってトランザクション境界を明確にします。これも大改造ですが、これをやることにより、先ほどのCDI化と併せてビジネス・ロジックとシステム・ロジックが混在した状態を整理することができます」(井上氏)

 そして最後のステップで手を入れるのが、永続化処理の部分だ。ここでは、SQLで書いた永続化処理をJava Persistence API(JPA)を使った処理に置き換えるが、これに関して井上氏は次のようにアドバイスする。

 「理屈上はすべてJPAに置き換えられるのですが、それには多くのコストがかかりますし、慎重に判断しながら進めていただきたいですね。SQLも大事なソフトウェア資産であることに変わりはないわけですから。大切なのは、SQLの中に入り込んだビジネス・ロジックを分離することであり、そのためにJPAが有効なら使えばよいし、使わずに済むのなら無理にそうする必要はないと思います。もちろん、JPAにデータソースを隠蔽できれば、開発生産性は格段に上がります」(井上氏)

 いずれにせよ、以上のようなステップで既存システムのアーキテクチャを整理しつつ、コストも勘案しながら、既存システムで再利用が可能な部分をうまく活用しながら移行を進めることが肝要だと井上氏は話す。

 「かつてのJava EEにはマイナスな面もありましたが、とても優秀な人たちが知恵を絞り、時間をかけて作り上げてきたものだけあって、今から見ても先進的な部分、優れた部分が沢山ありました。そうした部分を生かして作った資産はうまく活用していきたいですね」(井上氏)

 井上氏が説明した移行ステップには斉藤氏も全面的に賛同したうえで、さらにプロジェクト運営面から、「いきなり大規模プロジェクトに導入するのではなく、まずは小中規模のプロジェクトで実績を積んで定量的な評価も積み重ねておくことが、大規模導入の上申をスムーズに通すうえで重要です」とアドバイスした。