Java EE 7とJavaScript/HTML5による次世代のリッチ・クライアント開発──Java EEエバンジェリストのレザ・ラーマンが展望を語る

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

Java EE 7によるWebアプリケーション開発では、JavaScriptとHTML5が重要なテクノロジーとなる。これらとJava EE 7を組み合わせたリッチ・クライアント開発について、米国オラクルのJava EEエバンジェリスト、レザ・ラーマン氏が展望を語る。

 Java EE 7の特徴的な点の1つは、Webアプリケーションの開発言語として普及するJavaScriptと、Webページ記述言語からWebアプリケーション記述言語へと進化を遂げたHTML5への対応に力を入れている点だ。このことは、Java EE 7によるWebアプリケーション開発において、JavaScript/HTML5とJava EEをうまく組み合わせて使うことが重要になることを意味する。この新たなWebアプリケーション開発スタイルについて、米国オラクルのJava EEプラットフォーム・グループでJava EEエバンジェリストを務めるレザ・ラーマン氏が展望を語る。

 ※ 本記事は、2014年5月に東京で開催された「Java Day Tokyo 2014」におけるレザ・ラーマン氏のセッション「Java EE 7とJavaScript/HTML 5を使用したリッチ・クライアント開発について」を基に作成しています。

企業コンピューティングの黎明期から続く「クライアントは、シンか、リッチか」の議論

米国オラクル Java EEプラットフォーム・グループ Java EEエバンジェリストのレザ・ラーマン氏
米国オラクル Java EEプラットフォーム・グループ Java EEエバンジェリストのレザ・ラーマン氏

 この記事では、今後、Java開発者にとって重要となる2つのエコシステムをテーマにします。1つは業界標準の企業システム開発モデルである「Java EE」、もう1つは現在、高い注目を集めているエコシステムの1つである「JavaScriptとHTML5によるリッチ・クライアント(以下、JavaScript/HTML5 Rich Client)」です。現状、2つのエコシステムは互いに独立していますが、Java開発者は今後、これらを1つのエコシステムと捉えていくことになるのです。

 以降では、初めにJavaScript/HTML5 Rich Clientが登場した経緯を説明したうえで、このエコシステムとJava EE 7の整合性をどう取るのか解説します。そして最後に、Java EE 7とJavaScript/HTML5 Rich Clientを使ったWebアプリケーションのデモを紹介します。皆さんには、この新しい開発スタイルを、ぜひ実際のJava EE開発で試していただきたいと思います。

 それでは、まずJavaScript/HTML5 Rich Clientに至るクライアント・アプリケーションの変遷を振り返ってみましょう。過去を正しく理解すれば、今後のことも理解しやすくなるはずです。

 企業コンピューティングの世界において、長らく議論されてきたテーマの1つに「シン・クライアントか、リッチ・クライアントか」というものがあります。コンピュータが企業で使われ始めた当初、すなわちメインフレームの時代には、計算処理はすべてサーバ側(メインフレーム側)で行われ、ユーザーが利用するクライアントは処理結果を表示するたけのシン・クライアント型でした。

 その後、1980年代にクライアント/サーバ(C/S)アーキテクチャが登場すると、Visual Basicなどの開発ツールを使い、多くの処理をクライアント側で行うアプリケーションが作られます。これらのアプリケーションでは、サーバ側で行う処理はデータベース・アクセス程度でした。

 続いて1990年代に入ると、.NETやWebブラウザなどの技術が登場し、クライアントとサーバの関係は再び逆転します。JSF(JavaServer Faces)やStruts、Spring Frameworkといったサーバ側で多くの処理を行うアプリケーション・フレームワークが登場したのです。これらのフレームワークは現在も利用されています。

 このように、アプリケーションで主に処理を行う場所は、その時代の技術やIT環境に応じてサーバ側とクライアント側の間を行きつ戻りつしている感がありますが、全般的な動きとしては1990年代後半からリッチ・クライアント型に緩やかにシフトしています。その背景には、「もう少しWebブラウザ上でやれることを増やそう」という意識がありますが、これはサーバ側で行っていた処理をすべてクライアント側で置き換えようというものではありません。AjaxやPrimeFaces、GWT(Google Web Toolkit)、Vaadinといった技術を使い、処理の大半をサーバ側で行いつつ、一部の処理をAjaxを使ってクライアント側で実行するというアーキテクチャが指向されたのです。

現在はJavaScriptとHTML5でリッチ・クライアント化が進行中

 そして今日では、大半の処理がクライアント側に移り、リッチ・クライアントになりつつあります。その理由は、Google V8 JavaScript EngineやSpiderMonkeyといった高速なJavaScriptエンジンが提供されるようになったためです。これまで、Webブラウザはアプリケーションの有望なユーザー・インタフェース(UI)ではありませんでしたが、今後、その評価は大きく変わるでしょう。

 また、Webブラウザに依存しないスクリプト記述ツールとして、今後はJavaScript用のライブラリである「JQuery」が重要になります。そのほか、「AngularJS」、「Backbone」、「Ember」など、従来のサーバ側開発と同様のスタイルでJavaScriptによるクライアント開発が行えるMVCフレームワークも登場しています。これらのフレームワークには、JavaScriptのコードをロジカルにし、メンテナンス性を高められるというメリットがあります。

 さらに、CSS3やHTML5、WebSocketなど、Webブラウザの標準技術も進化しています。まだ標準化の初期段階ですが、「Web Components」により、HTMLによるUI要素を独自に定義して使うことも可能になります。

JavaScript/HTML5 Rich Clientは有望なクライアント技術だが、万能薬ではない

 JavaScript/HTML5 Rich Clientには、いくつかの特徴があります。例えば、「ダイナミックでインタラクティブなインタフェースに適している」、「複雑かつ豊富な機能が必要なUIに向いている」といった点です。Webブラウザ上で動作する表計算アプリケーションなどは、JavaScriptを高度に活用したリッチ・クライアントの代表的な事例です。また、画面遷移なしで利用できるシングル・ページ・アプリケーションを作るテクニックとしても有効です。これはアプレットを作る技術と似ています。

 ただし、JavaScript/HTML5 Rich Clientは万能薬ではありません。高度なフォームやワークフローのようなアプリケーションは、JavaScriptを使うよりもサーバ側のフレームワークを使ったほうがレンダリングなどの効率が良いこともあるでしょう。

 サーバ側のフレームワークを使う場合、処理の大半がサーバ上で実行されるため、パフォーマンスや信頼性が高くなります。JQueryやAngularJSを使う場合は、さらに追加のJavaScriptを書かなければならず、そのコードはWebブラウザに依存します。しかも、書いたコードが意図どおりに動作しないこともあります。

 UI全体をJavaScriptで書くことは、Java開発者にとってあまり幸せなことではありません。なぜなら、大量のJavaScriptを記述しなければならないためです。サーバ側のフレームワークのほうが、さまざまな面で優れていることから、このタイプのフレームワークを拡張するほうが良いと考えるJava開発者もいます。

 私自身は、今後JavaScriptだけでリッチ・クライアントを拡張していくのは難しいと感じています。一定期間、2つは共存していくでしょうが、やがてAjaxと同等のリッチ・クライアントの仕組みがサーバ側のフレームワークに組み込まれるといったことが起きるかもしれません。AngularJSで満足できる開発者もいれば、満足できない開発者もいるでしょう。開発者によって考え方が違うのです。

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