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）」に注目しているという。
自由自在の双方向通信を実現する「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で公開中とのことなので、興味のある人はアクセスしてみるとよいだろう。
「CDI」でテスト切り替えを容易にし、技術的依存を排除
続いて紹介されたのが「開発生産性の向上」に対する依存性を解消するための技術「CDI（Contexts and Dependency Injection for Java EE）」だ。様々なところで使用されてきたが、コンテナが提供するオブジェクトだけでなく、ユーザーが定義したオブジェクトについても依存性注入できるという大きな特徴を持つ。これによって、たとえば外部接続のパラメーターのハードコーディングの防止やコンポーネント間の依存性の除去が可能になる。つまり、ファイルの切り替えだけで、テスト環境と本番環境を簡単に切り替えることができるというわけだ。
さらにコンテナによるライフライクルの管理をおこなってくれるという機能も持つ。たとえば、1つのリクエストにあたり1つのインスタンスを生成する際に利用すれば、リクエストをServlet、EJB、JSPで分担して行う場合、それぞれに利用可能なコンテキストという形で、これらのオブジェクトを利用することができる。また、インターセプターというメソッド呼び出しの前に処理を割りこませることも可能だ。
CDIは現在1.1のメンテナンスリリースとして1.2が最新バージョンであり、2016年には2.0がリリース目標となっている。WebSphereでは1.0と1.2が実装されており、アプリケーションには影響はないが、DIコンテナを利用している場合は注意が必要となる。なお1.0とそれ以降の最も大きな変更点は「Bean-Discovery-Mode」が導入されたことにある。1.0や1.2ではなくてもよいということにはなっているが、デフォルトでの動作についてインジェクション対象が複雑に変更されているため、beans.xmlをアーカイブに追加し、かつ「Bean-Discovery-Mode」を対応させるとよい。
「Bean-Discovery-Mode」のインジェクションクラスについて以前は制御する方法がなかったが、1.1移行は「all」、「annotated」（デフォルト／推奨）、「none」の3つから選ぶことができる。1.0以前はアーカイブに大量のクラス（数万～）が入っていると、すべてが対象となり、起動時間の遅延やJavaヒープの大量使用などが生じて大規模システムで使用しにくかった。それを回避することができるわけだ。この他、Bean定義アノテーションや、インジェクション対象となるクラスの実装方法などが紹介された。
IBMが提供する新しいJava EE7の実行環境「Libertyプロファイル」
最後に田中氏は、IBMが提供する新しいJava EE7の実行環境「Libertyプロファイル」について紹介した。軽量で起動が速く、自動化ツールや統合ツールとの連携も密に行え、WebProfile準拠はもちろん、簡単な構成と動的変更、簡便なUnzipによる導入とデプロイといった利点を備えている。
「かつて『WebSphere Application Server』は、オールインワンの形で提供していたが、『Libertyプロファイル』についてはFeatureという形で必要な機能だけを組み合わせて使えるのが大きな特徴。設定されたものと依存関係にあるものだけがメモリにロード・初期化されるため、軽く起動が速いのが大きな利点」と田中氏は評する。
Liberty Repositoryで新しいFeatureを入手可能であり、機能追加や調整も簡単。Java EE 7についてはベータ版の形でほぼすべて提供しており、先に紹介された「WebSocket」も用意されている。また、それ以外のJava EE 7を構成する仕様も順次公開する予定だという。マイグレーションする必要なく、そのまま使うことができ、アプリケーションで新仕様が必要なければ従来版をそのまま利用可能。ただし、対応するJDKのバージョンは変更される可能性がある。
田中氏は「『お高いんでしょう？』と聞かれるが、『WebSphere Application Server for everyone』という形で、Javaヒープ総量が2Gに制限されるものの、3月出荷予定のWAS V8.5.5.5より、Libertyフロファイルの本番使用が無料になる。製品版も併せて、ぜひご検討してほしい」と語り、セッションを終えた。
