初めてのJava EE 6開発! 最初の壁をどう乗り越えた?──最新Java EE開発“虎の穴” 第1回 菊田洋一氏

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

それまで業務でC#一筋だった構造計画研究所の菊田洋一氏は、ある日突然、Java EEで開発を行うことになった。右も左もわからないJava EEの世界に飛び込んだ菊田氏は、最初の壁をどう乗り越えたのか?

世界の潮流はJava EE 6へ。先行者はどのようにして壁を乗り越えたのか?

 バージョン 5以降、オープンソース分野で普及した技術も意欲的に取り込みながら進化してきたJava EE。Java EE 6では、これまで独自フレームワークやオープンソース・フレームワークで補完されてきた機能が標準で備わり、企業が中長期にわたって安心して使えるシステム構築基盤に生まれ変わった。欧米企業ではJava EE 6など最新のJava EE環境への移行が急ピッチで進んでおり、この動きは日本国内にも波及しようとしている。

 それでは、これからJava EE 6への移行や導入を進める開発者は、具体的にどのようなポイントに留意しながら取り組みを進めればよいのだろうか。本企画では、実際にJava EE 6開発に取り組む開発者らへのインタビューを通して、彼らが突き当たった壁と、その壁を乗り越えるためのノウハウ、参考情報などを紹介する。

 初回となる今回は、構造計画研究所の菊田洋一氏に登場いただこう。

 菊田氏が所属する製造ビジネス・ソリューション部 ETO(Engineer To Order)技術室では、主に製造業向けの販売管理システムや生産管理システムなどを.NETで受託開発してきた。それが昨年、システムで使用している海外製コンフィグレータ・エンジン※1の機能をフルに活用するために、販売管理システムをJavaで開発することになった。

 2005年の入社以来、.NET一筋で開発に当たってきた菊田氏にも、また他のチーム・メンバーにも、Javaによる開発経験は皆無。そんな菊田氏らがJavaよる多階層システムの開発技術として選んだのは、StrutsでもSpring Frameworkでもなく、国内で導入が広がり始めたJava EE 6である。菊田氏らは2012年9月からJava EE開発に関する事前調査を始め、同年12月よりプロジェクトに着手。2013年の中頃、無事にJava EE 6版の生産管理システムをリリースした。

※1 製造業で扱う多くの製品は多数の仕様から構成されており、ある項目で使用する仕様が決まると、それが制約条件となって他の項目で使用できる仕様やオプションが決まる。こうした仕様間の適合条件を記述した論理式に応じて仕様のマッチング判定を行うのがコンフィグレータ・エンジンだ。菊田氏らが開発するシステムでは米国製のエンジンを利用しているが、このエンジンには.NET用とJava用のAPIが用意されている。これまでは.NET版システムで.NET用APIを介してコンフィグレータ・エンジンを使用してきたが、Java用APIのほうがより多くの機能を使えるため、販売管理システムの機能強化の一環としてJava版のシステムを開発することになった。

 文字どおりゼロからJava EE開発について学び始めた菊田氏らは、果たしてどのようにして"初めてのJava EE 6開発"の壁を乗り越えたのだろうか。

Strutsはもう主流ではなかった。これからのスタンダードとしてJava EE 6を選択


構造計画研究所 製造ビジネス・ソリューション部 ETO技術室の菊田洋一氏。ブログは「Challenge Java EE !」、Twitterアカウントは「@kikutaro_」

──菊田さんは今回、まったく未経験の状態からJava EE、それもJava EE 6による開発に取り組まれたわけですよね。

 もちろんJavaのWeb開発技術があることは知っていましたが、使った経験はなく、詳しいこともわかりませんでした。当時は「J2EEは難しい」と聞いていたので、JavaでWeb開発と言われたときは「ええっ!?」という感じでしたよ(笑)

──最初に3カ月かけて事前調査を行い、その中で本当にJava EE 6で開発できるかどうかを確認されたとのことですが、そこでは何から手を付けられたのでしょうか?

 まずは「情報収集」です。私は技術的な調べ物をする際、大型書店に出向いて関連書籍の棚を見渡し、刊行されている書籍などの状況から、何がメインストリームで、どういった関連技術があるのかを把握します。今回も、書店に行ってJava EE関連の技術書を見回してみたのですが、Strutsの書籍が沢山並んでいたため、Java EE開発ではStrutsがメインストリームの技術で、私たちもこれを使って開発すればよいのかと思っていました。

 ところが、情報収集の一環として日本オラクルが主催するJava関連セミナーに参加し、Javaエバンジェリストの寺田佳央さんのセッションを聴講して、どうやらそうではなさそうだということがわかってきました。

 寺田さんの説明によれば、欧米の企業ではすでにStrutsは下火となっており、現在ではStrutsと同等以上の機能を標準仕様でカバーしたJava EE 6の採用が進んでいるとのこと。そこで、これからJava EEに取り組むのなら、Java EE 6で行こうと決めたのです。

 振り返ってみると、「Strutsや他のフレームワークにするか、それともJava EE 6にするか」という選択が、私たちにとって最初の壁だったのかもしれません。.NETのように単一のフレームワーク/実装で完結する世界とは異なり、Java EEの世界ではさまざまなベンダーやコミュニティが仕様の実装を提供しており、多様な選択肢があります。そうしたことも最初はよくわかっていなくて、寺田さんのセッションで初めて、StrutsのほかにSpring FrameworkやSeasarといったフレームワークがあることを知ったくらいです。

──なるほど、そうした海外の最新動向を知る場が最近は少なくなっており、寺田さんもセミナーなどでは積極的にそうした話題を紹介しているそうですが、それがお役に立ったんですね。それでは、Java EE 6で行くと決めたら、次に何をされたのでしょうか?

 次に検討したのは、「何を使うか」ということです。

 先ほどもお話したように、Java EEの世界には、さまざまなライブラリやフレームワークがありますし、実行環境となるアプリケーション・サーバについても、無償のTomcatやGlassFishなどから有償のOracle WebLogic Serverなどまで、さまざまな実装があります。開発環境にしても、EclipseやNetBeansなど無償のものから、(Java EE開発では)有償のIntelliJ IDEAなど、いろいろな選択肢があります。それらの中から自由に選べるわけですが、実際にどれを使うかで悩みました。

──そのようにいろいろな選択肢がある中で、どのようにして採用する技術やツールを決めていったのでしょうか?

 とにかく、実際に試してみながら決めていきましたね。

 例えば、セミナーで寺田さんが勧めておられたので、開発環境としてNetBeansを試してみました。実際に使ってみると、GlassFishとの連携が便利だし、O/RマッパーとしてEclipseLinkがデフォルトで使えるといった具合で、これらを使用すれば意外と簡単にWebアプリケーションを作れることがわかりました。そこで、こんなに簡単にできるのならNetBeansを使おうといった具合に決めていったのです。

──選定の際、特に迷ったのはどの部分でしょう?

 やはりデータベース周りは性能にもかかわる部分ですし、JPA(Java Persistence API)の実装として何を使うか悩みましたね。Hibernateの情報が圧倒的に多いのですが、NetBeansではEclipseLinkがとても使いやすいのと、英語ですがドキュメントも一通り揃っており、海外での利用情報もあったため、私たちはEclipseLinkを選びました。

Java EEは難しくない!小さなサンプルを作って少しずつ理解する

──Java EE 6の各技術の習得には、どのように取り組みましたか?

 JSF(JavaServer Faces)やJPA、EJB(Enterprise JavaBeans)といった技術について、初めは「一体何だろう、どうやって使うんだろう」と疑問だらけでしたが、これは小さなサンプルを作りながら理解していきました。

 例えば、JSFはバージョン1の評判が良くなくて、その影響からか、まだ「JSFは今ひとつ」という声も聞かれます。しかし、私はJSF 2.xから入ったので、実際に試してみて「言われているほど悪いものじゃない」と感じました。

 WebアプリケーションのViewに関しては、コンポーネントを配置しながら画面を組み立てていくところが.NETのWindows Formsと似ていますしね。コンポーネントを配置して「おぉ、動いた」と感動しながら、徐々に実際の業務アプリケーション画面に合わせて作り込むといった具合に使い方を学びました。Strutsなどの時代のWebアプリケーション開発の経験がなかったことも、JSFにすんなりと入れた理由かもしれません。

 Modelに当たるManaged Beanについても、初めは「それって何?」という感じでしたが、これも実際にサンプルを作ってみながら、Beanの管理スコープなどを理解していきました。

 JSFとCDI(Container Dependency Injection)のManaged Beanの違いなども、実際に作ってみることで把握しました。

 EJBもそうです。「EJBはロールバック処理などを自分で書かなくても、トランザクション管理はコンテナが自動でやってくれる」と言われても、初めはどういうことかわかりませんでした。私が.NETで開発していたときは、自分でトランザクション管理を書かないといけなかったので、"自動"というのがピンとこなくて。しかし、これも実際にサンプルを書いて試してみて、「なるほど、なるほど」と納得しながら進めました。

 JPAのO/Rマッピングも便利でした。それまでの開発では自社で作った"オレオレ"なO/Rマッパーを使っていて、それこそ社内の"職人"しか触れないようなものだったのですが、Java EEでは標準でJPAがO/Rマッパーを提供してくれるのですからね。

──それでは、JPAにもすんなりと入っていけたのですね。

 ええ。ただし、後でいろいろ調べていく中で、性能面の優劣やO/Rマッパーとしての善しあしがあり、使う際には気をつけるべき点があることがわかりました。

 そこで、JPAを使う際、自分なりに工夫したところもあります。例えば、NetBeansはバージョン7.3.1から、NetBeans上でJPQLの問い合わせを行えるようになりました。つまり、NetBeans上でJPQLを書くと、発行されるSQLが表示され、結果まで確認できるのですが、そのSQLの実行性能を測り、JPQLが発行するSQLに性能面の問題がないかどうかを検証しながら使い方を考えました。O/Rマッパーの使い方を工夫したことで、性能面の問題はクリアしたシステムにできたと思います。

──工夫して使えば、弱点をうまく克服できる場合もあるということですね。それでは、菊田さんがJava EE 6に取り組む中で技術面で初めに乗り越えた壁は、「JSF」、「Managed Bean」、「EJBの自動トランザクション管理」、「JPA(JPQL)」の4つということになりますね。

 はい、この4つを理解したことで、それなりのシステムを作れる自信がつきました。Java EEは機能が豊富で、初めて取り組む方はさまざまな用語を前にして戸惑われるかもしれませんが、実際にサンプルを作りながら試していけば、きちんと理解できると思います。「重厚長大で取っ付きづらい技術」だなどという話も聞きますが、私はそうは思いませんでした。

菊田さんからのワンポイント・アドバイス

「JSF」、「Managed Bean」、「EJBの自動トランザクション管理」、「JPA(JPQL)」に取り組んだ際に試行錯誤したことなどのメモをブログに書いています。Java EE 6に初めて取り組む方には、次のブログ記事も参考になるかもしれません。