CodeZine(コードジン)

特集ページ一覧

【デブサミ2015】19-D-6 レポート
2015年、Java EE 7の時代が到来! モダンなアプリケーション開発をする上で押さえておきたいWebSocketsとCDI

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2015/04/08 14:00

 2013年5月に正式版が上がって以来、サーバサイド技術者から熱い注目を集めているJava EE 7。とはいえ、長らく商用対応製品がなかったために、魅力的な仕様ながら、なかなかビジネスの本舞台で使用されなかった。しかし2015年、有力なアプリケーションサーバーが続々と対応。「いよいよJava EE 7の時代が到来!」との呼び声も高い。本セッションでは、日本アイ・ビー・エムのソフトウェア事業本部 WebSphere 事業部 テクニカル・セールスの田中孝清氏が登壇し、Java EE 7の新機能、実際にWebSphere Application Serverが提供する価値について解説した。

目次
日本アイ・ビー・エム株式会社 ソフトウェア事業本部
WebSphere 事業部 テクニカル・セールス 田中 孝清氏
日本アイ・ビー・エム株式会社 ソフトウェア事業本部 WebSphere 事業部 テクニカル・セールス 田中 孝清氏

2015年、新たなフレームワークとしてJava EE 7の時代が到来!

 技術者の注目度が高いJava EE 7。田中氏はその背景について、「多くの企業で現在使用しているアプリケーションのフレームワークを次世代に切り替える必要があるという危機感を抱いている」と語る。国内では、MVC形式のフレームワーク「Struts」が、業務システムのベースとして使われているが、2013年に4月にサポートを終了。2014年には深刻な脆弱性も発見されており、対応を迫られたことも記憶に新しい。Seasar2も主要開発者のプロジェクト離脱により、一部を除いた新機能追加がなされず、サービス対応の不備もあって不安に思っているユーザーも少なくない。

 従来のJavaの世界でアプリケーションを開発する場合、J2EEの機能を直接使うのではなく、なんらかのフレームワークの上で構築することが一般的だった。というのも、登場したてのJ2EEの仕様は力不足であり、作りにくさや機能不足を補うためにオープンソース系、ベンダー系、自社独自系など、多くのフレームワークが登場したという経緯がある。しかし、その多くが開発終了となり、新たなフレームワークが模索されているというわけだ。

 これに対し、Java EE 7はこうしたフレームワークで使われてきた機能を貪欲に取り込み、単体としても完成度の高いフレームワークとなっているため、直接ここに開発を行うといった「Java EEへの回帰」が進みつつあるという。標準的なアプリケーション構成として、画面デザインにJSFとEL、外部システム連携にJAX-RSとWebSocket、インタフェイスとバックエンドを連携させるビジネスロジックにおいてはDI/EJB/JTA、DB連携・ORマッピングにはJPAなどが採用され、今後はこれに則って新たなアプリケーションが追加されると考えられる。

 なおJava EE 7については、「HTML5環境への対応」「開発生産性の向上」「エンタープライズニーズへの対応」という3つのゴールが策定されている。これらに対応するために、多くの仕様が更新された。そのなかでも田中氏は、「HTML5環境への対応」への目玉として「WebSocket」、そして「開発生産性の向上」に対する「CDI(Contexts and Dependency Injection for Java EE)」に注目しているという。

Java EE 7の3つのゴール
Java EE 7の3つのゴール

自由自在の双方向通信を実現する「WebSocket」

 「WebSocket」は、「HTML5環境への対応」への目玉として追加された。長年策定されてきたHTML5もようやく2014年10月に正式勧告。従来のHTMLが画面構成にとどまるのに対し、HTML5は加えてJavaScriptを利用してブラウザ上で動くアプリケーションを構築することを目的としている。この活用においては、Webアプリケーションの作り方が変わってきていることを意識すべきだろう。従来のアプリケーションでは基本的にサーバサイドで処理が行われてきたが、HTML5の世界ではクライアント側でJavaScriptによる何らかのロジックをリストするということが広く行われるようになってきた。こうした「サーバサイドMVC」から「クライアントMVC」へすべてをすぐに移行するのは難しいが、要所要所の画面で少しずつ、たとえば1ページ内で処理を継続するような「シングルページアプリケーション」などが少しずつ増えていくことが考えられるという。

 こうしたアプリケーションは、ブラウザ側ではJavaScriptで実装されるが、サーバ側ではどうなっていくのか。今まで基本的にHTMLとJSPなどを使用していたものが、ブラウザの上で動くJavaScriptと通信を行い、何らかの情報や業務のリクエストの授受を行う。そのための機能がサーバ側にも求められるようになる。これを実装するにあたり、HTTPの原則にしたがった簡潔なシステム間連携の設計手法「RESTful」などが通信方法として使われるようになり、データ型としてはJavaScriptのオブジェクトとしてそのままパースできるテキスト形式のデータ表記法「JSON」が使われるだろう。

 「RESTful」と同様、通信方法として注目されるのが、ブラウザとWebサーバの間で双方向通信を可能にする「WebSocket」である。従来、双方向通信を行おうとすると、定期的にポーリングを行う「Ajax」やイベントが発生するまで応答を遅延させる「Comet」などを使用してきた。しかし、それぞれタイムラグが発生したり、クライアント側のイベント通知に不向きだったりなど一長一短がある。そうした双方向通信を「WebSocket」なら容易に実現できる。自由な方向に自由なタイミングで送信することができるというわけだ。田中氏は「非常に自由度が高く、かつサーバやブラウザへの負荷も低いという意味で、大いに使いやすい」と評価する。

 現在プロトコルはRFCで標準化が終了し、W3Cの方で仕様化され公開されている。またIE 8と9を除くモダンなブラウザの大部分がサポートしており、2014年10月時点で約7割以上が対応している。

 Java EE 7でWebSocketアプリ開発を行うには、「JSR 356: Java API for WebSocket 1.0」を使用する。これはJavaでWebSocket通信を実装するためのAPIであり、クライアントとサーバの両方をサポートしている。Java SE環境での実行も考慮された仕様だが、タブレット端末との連携時には若干“ややこしい”手順を踏む必要があり、注意が必要だという。さらにアノテーションをベースとしたモダンなプログラミングスタイルで、Encoder/Decoderにより扱うデータ型を柔軟に制御できることも特徴としている。

 クライアントとサーバのそれぞれのコンポーネントに実装することで、双方向通信が可能になるわけだが、クライアントはブラウザで実装することが多いので、一般にはJava EEではサーバ側のEndpointを実装する。またEndpointの実装にはjavax.websocket.Endpointを継承したクラスもあるが、アノテーションをつけたPOJOで実装するほうが容易だという。

 Endpointの実装はServletと似ているが、Servletでは1つのインスタンスに対して複数のセッションで共有するのに対し、Endpointではセッションごとに毎回インスタンスが生成され、セッションの情報をインスタンス変数に保存し、必要に応じて送り返すことができる。なお、時間のかかる初期化処理はここでは入れ込まないようにするのが得策である。またマルチスレッドを考える必要がないが、複数にまたがる際には状況に応じて排他制御が必要になる。

 他、ピアへのメッセージの送信、HTTPヘッダ・HttpSessionへのアクセス、ConfiguratorからEndpointへの情報伝達といった内容が紹介された。さらに詳細はIBM developerWorksで公開中とのことなので、興味のある人はアクセスしてみるとよいだろう。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:【デブサミ2015】セッションレポート

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5