X

An Oracle blog about WebLogic Channel

「Webアプリケーションのモバイル/スマート・デバイス対応も見据え、まずはフロントから」──伊賀敏樹氏(いがぴょん)がJava EE 6への移行をすすめる理由

Guest Author
開発生産性の向上や軽量化が図られ、従来から大きく刷新されたJava EE 6。WebLogic Serverなど主要なアプリケーション・サーバでの対応も進み、目の利くアーキテクトらは、その恩恵を享受すべくJava EE 6への移行に動き始めている。その1人、長年Java EE開発に携わってきたNTTデータビジネスブレインズの伊賀敏樹氏は、「Java EE 6の登場で、それまでの Java EEへの印象をいったんリセットする必要があると感じた」と語る。今後、需要が高まるモバイル/スマート・デバイス対応Webアプリケーションの開発効率改善も見据えてJava EE 6の採用を順次進めようとしている伊賀氏に、今、Java EE 6を試すべき理由、移行する理由を聞いた。(編集部)

かつては、EJBも Java EEもネガティブ扱いだった


 2013年2月に開催された「WebLogic Server 12c Forum 2013」のパネル・ディスカッション「Java EE 6の現在とJava EE 7、そしてその先へ」に登壇し、Java EE 6活用の現状について話してくれた伊賀氏。その中で氏は、「Java EE 6が登場し、それまでの Java EEに対する(ネガティブな)印象をいったんリセットする必要があると感じた」と語った。その理由、Java EE 6のどこに大きな価値を感じているのかを改めて聞いた。


 Java EEの黎明期より、「いがぴょん」のハンドル・ネームでIT系メディアやブログや書籍などを通じて技術情報の発信に努めるほか、各種オープンソース・フレームワークの開発にも尽力してきた伊賀氏。現在はNTTデータデータビジネスブレインズのシニア・スペシャリストとして、Java EEや.NETを使った大小さまざまな規模の開発案件に携わっている。


 そんな伊賀氏はこれまで、Java EE全般に対して、あまり良い印象を持っていなかったと振り返る。

WebLogic Server 12c Forum 2013のパネル・ディスカッションに登壇した伊賀敏樹氏。「いがぴょんの日記」、「いがぴょんのウェブページ」より情報発信中

 「かつてのJava EE、特にEJBは、仕様が複雑で使いこなすのが難しい技術でした。1つのEJBコンポーネントを開発するために多くのファイルを作らなければならず、しかも当時の標準的なマシン上では EJB コンテナがのろのろと重たく動作するという状況でした。面倒さの割にはメリットが見えづらいものであったため、EJBを使わずにPOJO(Plain Old Java Object)を使うアプローチに流れていくエッジな Java エンジニアを多く見てきたものです」(伊賀氏)


 とは言え、Java EEと袂を分かったわけではなく、業務でかかわるJava EEプロジェクトの開発効率化にアーキテクトとして尽力する傍ら、Java EE開発を効率化する各種オープンソース・ソフトウェア(OSS)の開発にも参画してきた。


 例えば、伊賀氏がコミッターを務めるフレームワーク「blanco Framework」も、そうしたOSSの1つだ。blanco Frameworkでは、Excel上で必要な情報を入力すると、DAO層のプログラムやファイル入出力用プログラムなど、必要なコードを自動生成してくれる(blanco Framework 自体は、Java、C#.NET、JavaScript、VB.NET、PHP、Ruby、Pythonのコード生成に対応)。こうしたフレームワークを実案件でも活用し、システムの開発生産性や品質を高めているのだ。


 伊賀氏は、Java EEなどの新しい技術に対する自身のスタンスを、次のように説明する。


 「私は、新しい技術は少しずつ実プロジェクトに取り入れていくのが良い取り組み方だと考えています。エンタープライズ・システムにおいては “いっぺんに” 新技術に入れ替えてしまうのはリスクが高くなりがちです。慣れ親しんだデータベース層の実装技術を短か目のサイクルで更新していくのはメリットが出にくいことも懸念されるため、『まずフロント部分から新技術を採用することができないか検討する』ような判断基準を基本としています」

JSF 2(Facelets)を試して、Java EEを見る目が変わった


 この持論の下、開発効率や品質の向上に常に目を光らせてきた伊賀氏は、折に触れてJava EEの新技術の吟味も続けてきた。特に注目してきたのがWebアプリケーションのフロント部分の開発技術だ。


 「これまで長い間、フロント部分の開発では、Struts 1が多くの現場で採用されてきました。Struts 1 であれば、対応できる開発者も多くいるため、大規模なプロジェクトであっても要員を比較的集めやすい傾向にあるものと感じられます。


 しかし今日、Struts 1 は開発生産性をはじめとして多くの課題に直面しています。


 例えば、JSPのカスタム・タグ・ライブラリによる部品開発は現時点ではひどく煩雑な
ものに見えてしまいます。また、Webページ(JSPファイル)内に直接コードを書けてしまうScriptletsのような仕組みは、手軽で便利ではあるものの本来バックエンドに置いておきたいロジックがフロントに配置できてしまうことから、セキュリティ面における問題を引き起こしてしまう場合があります」(伊賀氏)


 そのため、Struts 1 に代わる新たなフロント開発技術を常に探してきたわけだ。そうした中、Java EEの新たなフロント開発技術としてJSFが登場する。ただし当初、JSF そのものに対する印象は芳しくなかった。


 「2004年にJSF 1.0が登場したときは、APIがまだ全然足りていないという印象でした。繰り返し処理の適切な仕組みもなかったので、ちょっとした複雑な画面の開発ですら生産性が落ちてしまうようなものでした。


 その後、2006年にJSF 1.2が登場し、Java EE 5に取り込まれたのを機に、改めて実際の評価を行ってみました。当時の時点でも API は不足気味であったので、いくつかのOSSのフレームワークを組み合わせたうえでGlassFish 2上にシステムを組んでみたのです。しかし、ここでも残念なことに、組み合わせに用いたOSS同士の相性の問題などもあり、満足のいく生産性を当時は得ることができませんでした」(伊賀氏)


 だが、「いずれはJava EEの標準技術だけですべてをまかなえるようにしたい」と考えていた伊賀氏は、引き続きJSFに注目。2009年のバージョンアップでJSF 2となってFacelets が組み込まれ、これがJava EE 6に取り込まれると、改めて小規模な実案件でJSF 2を採用してみたという。


 「JSF 2では、テンプレート技術としてFaceletsが導入されており、これを恐る恐る試してみました。GlassFish 3上にJSF 2ベースでフロント部分を組んだのですが、このとき、Faceletsベース開発における生産性の高さに非常に感心しました」(伊賀氏)


 伊賀氏が「それまでのJava EEへの印象をいったんリセットしないといけない」と感じた瞬間である。

開発生産性、セキュリティ、安心感、そしてStruts 1のEOL──JSF 2/Java EE 6への移行をすすめる理由


 Faceletsでは、部品となるコンポーネントを組み合わせて画面を構成する「Composite Component(CC)」のアプローチを採用している。個々のコンポーネントは複数の画面で再利用することができ、コンポーネントの差し替えにより、複数ページの該当部分をまとめて変更することが可能だ。このCCにより、従来のJSP(カスタム・タグ・ライブラリ)による画面部品開発のアプローチと比べて開発生産性を大幅に高めることができる。


 今日のWebアプリケーションでは必須になりがちなAjaxとの親和性の高さも大きな魅力だ。JSF 2ではAjax対応機能が追加され、AjaxアプリケーションをJavaScriptを直接手で書くことなく簡単に開発できるようになっている。


 さらに伊賀氏は、セキュリティの高さもJSF 2(Facelets)の大きなメリットだと強調する。


 「Faceletsには、JSPのScriptletsに相当する機能が基本的に存在しません。このため、Webページに直接ロジックが書き込まれることに起因するセキュリティ・ホールの発生をかなり低く抑えることができます。また、画面遷移の順を飛ばしてWebページを表示させようとするとエラーが発生する仕組みや、画面上のドロップボタンやラジオボタンの選択について値が妥当かどうかの検証を行う仕組みもデフォルトで最初から組み込まれて有効になっています。


 こうした仕組みのおかげで、Webアプリケーションに対して最近よく使われる典型的な攻撃手法の多くが初めから無力化されますので、Facelets は“天然でよりセキュア”なのです。Facelets において Scriptletsを書けないと聞くと、JSPに慣れた方にとってはデメリットなだけであるように感じられるかもしれませんが、私は Web システムのセキュアさ向上のためには、そもそもScriptletsは書けないほうが有利であるとすら思っています。ちなみに、Scriptlets の代わりは JSFのManagedBeanを呼び出すことによって代替することができます」(伊賀氏)


 実際に、いくつかのWebアプリケーションのWeb セキュリティ診断を受診した結果からは、JSF 2(Facelets)ベースによるWeb アプリケーションはStruts 1ベースのものに対して有利な評価を得る傾向にあるという。


 「JSFの今後のバージョンでは、クロスサイト・スクリプティングやクロスサイト・リクエスト・フォージェリへの対応が追加および強化される予定があるとのことですので、Webセキュリティ面はますます強固になっていくことが期待されます。このような JSF(Facelets)のセキュリティ面におけるメリットについては、オラクルさんから、もっと宣伝していただきたいくらいです(笑)」(伊賀氏)


 加えて、JSFをはじめとするJava EE 6では「EoD(Ease of Development:開発容易性)」を指向してコードが簡略化されているため、ソースコードが読みやすくなるように改善されており、レビューなどで間違いを見つけやすい点も大きな利点である。


 そして何より、Java EEの標準技術ですべてをカバーできるという安心感がある。


 「Java EEの標準技術の中ですべてを完結させられるメリットは大きいですね。これまでは独自にOSSなどを組み合わせてアプリケーション基盤を準備することが多かったのですが、それら複数のOSSを組み合わせていくと、相互の相性や依存するライブラリのバージョン管理などがどうしても煩雑になりがちです。


 Java EE 6なら、そうした苦労や責任はアプリケーション・サーバ・ベンダーが担ってくれます。アプリケーション・サーバ・ベンダーが開発して提供するAPI実装を使い、彼らからサポートを受けることができ、セキュリティ維持の営みの多くの部分について肩代わりしてもらえるのですから、これをうまく活用しない手はありません。


 それに、Java標準技術であるので、いざとなったらアプリケーション・サーバを別のものに移行することもできます。特定の製品やフレームワーク、技術にロックインされる心配がないことや、利用している技術がガラパゴス化してしまうリスクを回避できるということも大きなメリットでしょう」(伊賀氏)

Struts 1がついにEOLを迎えた(EOLを告げるアナウンス・ページ)

 もう1つ、伊賀氏が早くJava EE 6への移行を進めたい困った事情がある。それは、Struts 1のEOL(End Of Life:開発停止)の問題だ。


 「2013年4月、ついにStruts 1のEOLがアナウンスされました。今後、セキュリティ上の問題点などが見つかったとしても、それが開発元(アパッチ・ソフトウェア・ファウンデーション)によって修正されなくなってしまったのです。


 国内には、まだStruts 1ベースのシステムが多く稼働していることでしょう。それらのシステムのうち、特にインターネット上に接続されているものについては、今後何らかの対応が必要になってくる可能性があります。Struts 1に依存するフレームワークについても影響を受ける可能性があるので、場合によってはシステム基盤そのものの刷新が必要になるケースも出てくることでしょう。


 こうした点からも、古いJava EE基盤は見直しを検討すべき時期を迎えてしまった可能性があります。Struts 1は大きな成功を収めたフレームワークですが、今となっては開発生産性もそれほど高いものではありません。Struts 1 の過去の成功体験にしがみつきたい気持ちはよくわかりますが、将来的にリスクを抱え込んでしまう可能性にも留意する必要があるのではないでしょうか」(伊賀氏)

小規模プロジェクト、アジャイル・プロジェクト、モバイル/スマート・デバイス対応──Java EE 6を試すタイミング


 このように、Java EE 6への移行の機が熟してきたとはいえ、いきなりすべてを刷新するのは難しい。先述したように、伊賀氏も「まずは変化の激しいフロント部分から」と考えている。


 それでは、どのような機会にJava EE 6の利用を検討すればよいのだろうか。


 「まずは小規模なプロジェクトで試してみるのが良いように考えます。私は10人月程度の規模のプロジェクトから適用を始めてみました。


 効果をすぐに実感できるという点では、アジャイル開発プロジェクトにおいて試すのも1つの手です。JSFにはEoDに関する改善が多く含まれているので、新規に開発する場合はもちろんのこと、変更要求に対してもさまざまな面で有利なことが多いものと考えます。FaceletsでCCを使っている場合であれば、それらの変更要求に対してごくわずかな修正作業だけで対応が済んでしまうこともあります。


 さらに最近、ユーザー企業の中にJava EE 6への移行に積極的に取り組むところが出てきているように聞き及びます。なるほどSIerよりもユーザー企業の内製プロジェクトのほうが、Java EE 6のような新しい技術に取り組みやすいのかもしれませんね」(伊賀氏)


 今後、Webアプリケーション開発の世界ではモバイル/スマート・デバイス対応の需要が大きくなると見られるが、これに関してもJava EE 6には大きな強みがある。


 「今後のWebアプリケーション開発ではHTML5が主流になっていくことでしょう。HTML5に取り組む場合、XML形式に親和性が高いFaceletsを使うのは技術的に自然な発想ですね。XMLウェルフォームド妥当性検証ひとつとっても、JSPの場合は基本的にいったん表示させたうえでしか妥当性検証が実施できませんが、Faceletsは元からXML形式となっていて妥当性検証は簡単に実施できます。


 モバイル/スマート・デバイス向けに新しく作るWebアプリケーションについてもHTML5ベースになることは多くなるでしょうから、そこでもFaceletsを使うと効果が高いものと思います。Java EE 6なら、RESTやSOAPを使ったアプリケーションを従来に比べて非常に簡単に記述できるのも魅力です。モバイル/スマート・デバイス向けWebアプリケーションのうち、トランザクションを多く扱うようなアプリケーションであれば特にJava EEの強みが生かせますし、何より私にとっては安心感があります。


 モバイル/スマート・デバイス向けは、今後のWebアプリケーション開発の“主戦場”の1つとなるでしょう。その状況に備えて、今から開発効率や品質を高めやすい技術を準備しておかないと間に合いません。これも、Java EE 6を試す大きな動機付けになっていくことでしょう」(伊賀氏)

レガシーでありながらも革新的に──これからのJava EEへの期待


 以上のように、Java EE 6への移行は企業に多くの恩恵をもたらす可能性があるが、一方で伊賀氏は、Java EE 6を取り巻く現状に課題も感じている。


 「英語でも日本語でも、まだまだ技術情報が少ないですね。今後は日本でも多くの方にJava EE 6を試していただき、そこで得た情報をブログなどで発信していただきたいと期待しています」(伊賀氏)

Manjyuにおける、コードを書くことなく、Ajaxアプリケーションを作ることができる実装例

 参考にできるサンプル・アプリケーションがまだ充実していない点も改善すべき点の1つだ。この状況の改善に少しでも貢献すべく、伊賀氏は自身がJSF 2の機能検証のために試作したURL管理用のサンプル・システム「Manjyu」をOSSとして公開している。


 「Manjyuは、JSF 2の機能検証のために開発したものです。サンプル・アプリケーションであるのと同時に、さまざまなJSF 2 Faceletsの機能を確認するための “陳列棚”にもなっています。もちろん、Facelets の魅力機能の1つである、ノンプログラミングでAjaxアプリケーションを実装する例も盛り込んでありますよ。ぜひ多くの方に試していただき、JSF 2の便利さを知っていただきたいと思って公開しています」(伊賀氏)


 それでは、今後のJava EEに対しては何を期待しているのだろうか。


 「現在のJavaは、人によってはレガシーな技術だと考えられているかもしれません。レガシーというとどうもネガティブな印象で見られがちですが、私はJavaに、今後もレガシーだからこそ実現できる、安定(Stable)で、成熟(Mature)な技術であり続けてほしいと思っています。だから正直なところ、言語仕様などはあまり変えてほしくないくらいです。このため、例えばクロージャのような新技術����言語仕様に取り込む際に、それを無効化するオプション機能を付けて欲しいと思うほどです。


 ただし一方で、引き続き革新的でもあってほしいです。例えば、今後はPHPに代表されるようなLightweight Language(LL)では実現されているマルチテナント対応能力について強化していただきたいです。現状、Javaでサービスを作っても、それを安くホスティングできるホスト先はまだまだ少ないように感じます。一方で PHPであれば安いホスティング・サービスはたくさんありますよね。こんな状況ではJavaはLLに太刀打ちできません。今後、クラウドという手法がITにおいてますます普及していくであろうことを考えると、マルチテナントで安くホスティングできて、さらにスケールもできるようにするための基本的な仕組みがJava EEの機能として提供されていることが必須なのです」(伊賀氏)


 “プロフェッショナルな” Webアプリケーション開発との親和性のさらなる向上にも期待している。


 「Webデザイナーと共同作業する “見栄え” が重要なWebアプリケーション開発では、 divタグやCSSで微調整が施された “ぎりぎりの” HTML ファイルを扱うことが多くなってきたように思われます。ところが、Faceletsが生成するHTMLの中に余計な空白や改行などが含まれているケースがあり、これがレイアウト崩れを引き起こしてしまい作業効率が落ちる場面があるのです。他方、モバイル/スマート・デバイス向けの場合にHTMLファイルなどのファイル転送量を1バイトでも減らすことが重要なケースもあります。それらも考慮し、生成するHTMLは無駄が省かれた極力シンプルなものになるよう改善していってほしいですね」(伊賀氏)


 伊賀氏は今後も、身の回りのプロジェクトについて、可能なものから順次Java EE 6を採用していきたいのだという。また、Java EE 6のノウハウも可能な範囲でIT系のメディアや OSS などのかたちを通じて発信していきたいとのことだ。本記事をお読みのアーキテクト諸氏にも、ぜひ伊賀氏の情報/ノウハウを活用していただくとともに、日本のJava開発者のスキル向上のために、ぜひ情報発信の輪に加わっていただきたい。


 「古くからJava EE開発にかかわり、現在は開発標準の整備などを担っているアーキテクトの方々の中には、EJBやJSF 1.Xなどを試して辛酸をなめてしまい、その悪い印象から最近のJava EEの利用についても躊躇しておられる方々も多くいらっしゃることでしょう。


 しかし、JSF 2、そしてJava EE 6は、これまでのJSF/Java EEとはかなり違うものであると感じられます。APIも充実してきており、アプリケーション・サーバにおける対応も進んできています。これまでのWebアプリケーション開発の成功体験のエッセンスがJava EEというかたちに結実し、安心して使い続けられる技術へと成熟したように感じられます。私たちアーキテクトにとって、非常に魅力的なプラットフォームだと思いますので、ぜひ試してみてください」(伊賀氏)

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.