Posts tagged ‘Java EE’

Java EE 8 の新機能概要のご紹介


この記事は、「Java EE Advent Calendar 2014」の19日目の記事となります。
昨日は、@nagaseyasuhitoさんの「JPAでマスター/スレーブ構成のMySQLを使うぞ」でした。明日は、@kokuzawa さんのご担当となります。

本エントリでは、今年の JavaOne で発表された、Java EE 8 (JSR-366) の今後の動向についてまとめたいと思います。

本エントリの内容は、JJUG CCC 2014 Fall で発表した内容に追加情報を加えた内容になっています。SlideShare で資料をご覧頂きたい方、もしくは PDF ファイルを入手されたい方は上記スライドをご参照ください。

本エントリの記載内容は、2014年12月時点での内容ですので、下記に記載する内容は今後大幅に変更する可能性もあることをどうぞご理解の上でご覧下さい。


まず、Java EE 8 のリリースに伴い、Java EE のスペックリードは本当に必要とされる技術が何なのかを改めて考えてみました。その際、業界のトレンドを観察し必要な技術は何なのかを検討したり、また Java の技術者の皆様にアンケートをとり、実際に技術者の皆様から求められている機能はどのような内容なのかも確認しました。アンケートの結果、JSON Binding, Security, JCache, Action ベース MVC 等が上位に占められていました。

こうして検討を重ねた結果、次の Java EE 8 のテーマを決めました。Java EE 8 では3つのテーマを元に機能提供を検討しています。

● HTML5
 + JSON Binding : JSR-367
 + JSON-P : JSR-374
 + Server-Sent Events : JSR は未定(JAX-RS,Servlet, WebSocket の何れか)
 + Action Base MVC : JSR-371
 + HTTP/2 のサポート(Servlet 4.0) : JSR-369
 + WebSocket の改善

● かんたん開発
 + CDI の適用範囲の拡大 : JSR-365
 + セキュリティ・インターセプタ
 + 仕様の削減

● クラウド環境への対応
 + Java EE Management 2.0 : JSR-373
 + Java™ EE Security API 1.0 : JSR-375

最新の Web 系の技術トレンドに対応するために、HTTP/2 への対応を Servlet 4.0 内で行うほか、Server-Sent Events の標準化、新しい Action ベースの MVC 等の導入も検討しています。また Java EE 5 以降、6,7 と継続してかんたん開発のテーマに取り組んでいますが、これは Java EE 8 でも継続します。例えば CDI の適用範囲をひろげ Java SE 環境でも CDI を利用できるようにします。さらにクラウド対応という点では、今まで Java EE アプリケーションを監視する際に使用していた、管理・監視用の JMX を改め、JAX-RS による監視を可能にする他、今までアプリケーション・サーバ毎に個別設定していた認証・認可の設定・実装(レルム)を標準化し、より簡単にユーザ管理のアプリケーションを実装できるようにします。これらの各種技術概要を見るだけでも Java EE 8 が待ち遠しくなりますが、それぞれの検討内容を下記にまとめて紹介します。

HTML 5 への対応として、ここに列挙する内容が検討されています。これらを順に説明します。

JSON Binding : JSR-367
JSON Binding は JSON と Java オブジェクトをマッピングし相互変換を簡単に実現するための機能です。

今までも、XML を利用する場合には、JAX-B を利用したり、データベースのテーブルと Java オブジェクトをマッピングするために、JPA を利用してきましたが、JSON-B はこれらと類似の方法で JSON と Java オブジェクトをマッピングできるようになります。またこれを実装する事によって JPA の Entity を使用したデータベース・テーブルから JSONへの相互変換や、JAXB を使用した XML と JSON への相互変換も容易になります。
JSON-B は JSON の Java へのマッピングにおいてできるだけ実装コードを少なくするため、Configuration by Exception のルールに乗っ取り標準でデフォルトのマッピング・ルールが提供されます。またクラスの継承も可能です。このデフォルトのルールに従う場合は、Java を簡単に JSON に変換できます。そしてもちろん、デフォルトのルールをカスタマイズしたい場合には、専用のアノテーションを付加する事でデフォルト・ルールを上書きする事もできます。
また、Java EE 7 で導入された JSON-Processing との連携も容易にできます。

JSON-B の参照実装は、Eclipse link MOXy で開発が進められています。


それでは、実際に Java と JSON のバインディングについて見ていきましょう。ここでは、Employee というクラスに、インスタンス変数、id, firstName, lastName, email が定義されており、Employee クラスのインスタンス (e) を生成した後、それぞれに値を代入しています。この Java オブジェクトを JSON で扱う場合、デフォルトのルールに従うとインスタンス変数名が、JSON の KEY になり、変数に代入された値が JSON の value として代入されます。

また、JAX-B をご利用した事のある方であれば、用語の説明は不要かと想定しますが、Java から JSON への変換を Marshal (マーシャル) といい、逆に JSON から Java への復元の事を Unmarshal (アンマーシャル) といいます。


Marshal (JavaからJSONへの変換), Unmarshal (JSONからJavaへの変換) を行うために、まず JsonContext オブジェクトのインスタンスを生成します。JsonContext のインスタンスを生成するためには、デフォルトで用意されているファクトリ・メソッド JsonContext#newInstance() を利用する事ができます。また下記のように JsonContextBuilder を通じてインスタンスを生成する事もできます。

JsonContext context = new JsonContextBuilder()
                  .setScope (MyClass.class, ...)
                  .excludeField(“field”, MyClass.class)
                  .addFilter(myContextFilterImplementation)
                  .build();

生成した JsonContext のインスタンスから、それぞれ createMarshaller() で Marshaller オブジェクトを、createUnmarshaller() で Unmarshaller のオブジェクトを生成します。


一旦、Marshaller オブジェクトを生成すると、変換したいオブジェクトを marshall() メソッドの引数に渡す事で簡単に JSON を含む String オブジェクトを取得したり、Writer として取り出す事もできます。


同様に、unmarshaller() メソッドの引数に JSON を含む String 、もしくは Reader から Java オブジェクトを渡す事で簡単に Java オブジェクトに復元する事もできます。


今まで JsonContext から Marshaller や Unmarshaller を生成し各処理を行う方法を紹介しましたが、よりかんたんに直接相互変換を行うためのユーティリティ・クラス Jsonb の作成も検討中です。Jsonb のメソッドを利用すると直接、marshal, unmarshal を実行する事もできるようになります。


JSON-B ではプリミティブ型や、参照型に対するデフォルトのマッピングルールを提供します。しかし、デフォルトのルールに従わず独自にカスタマイズしたい場合には、下記のようなアノテーションを付加しカスタマイズする事もできます。


例えば、デフォルトのルールに従うと、Java クラス中のインスタンス変数名は、JSON のキーに同一の名でマッピングされます。しかし、Java クラス中のインスタンス変数名と、キー名を変更したい場合は、@JsonPropertyアノテーションを付加して変更する事ができます。


また、Java のクラス中に含まれる特定のインスタンス変数を JSON にマッピングさせたくない場合、@JsonTransient アノテーションを付加し無効化する事ができます。


さらに、JSON ドキュメント中のキーの記載順に意味があるような場合、デフォルトでは Java クラスのインスタンス変数の記載順にマッピングされますが、その順番を変更するために、@JsonPropertyOrder アノテーションを付加し引数内に順番を指定する事ができます。


JSON-B では継承やポリモーフィズムにも対応予定で、また Marshal の前後、もしくは Unmarshal の前後に処理をインターセプトして何らかの処理を付け加えて実行したい場合に、それらを実現するための API (JsonPre***, JsonPost***) も用意しています。


JSON-Processing は Java EE 7 に JSR-353 として導入されました。JSON-P は Stream を利用して JSON の解析、生成を行うための低レベル API を提供し、XML における StAX や DOM のような機能を提供しています。
Java EE 8 では Java EE 7 で提供されている機能に加え、JSON の標準仕様に準拠した最新機能 (JSON ポインタや JSON パッチ) にも対応します。


まず、JSON ポインタについてご紹介します。


JSON ポインタは IETF RFC 6901 : JavaScript Object Notation (JSON) Pointer で定義される仕様で、JSON ドキュメント内に存在する特定の値を参照するための構文です。


たとえば、この例をご覧ください。この例では JSON 配列の中に、2つの JSON オブジェクト(名前が Duke と Jane)があります。そして人に関する情報(名前、性別、電話番号)が JSON オブジェクトとして記載されています。それではこの中から携帯電話の電話番号 (650-234-5678) を取得するにはどうすればよいでしょうか。JSON ポインタを利用すると、”/何番目/phones/mobile” といった形式で一意に値を取得する事ができるようになります。例では “0/phones/mobile” と 0 番目を指定する事で値を取得しています。


それでは、Java で JSON ポインタを扱うためにはどのようにすれば宜しいでしょうか。まず、先ほどの JSON ドキュメント(名前が Duke と Jane)が JsonArray のインスタンス contacts として表されている事とします。 この時、Json クラスのクラスメソッド createPointer() の引数に、参照したい JSON 値への参照パス(“/0/phones/mobile”)を渡し、JsonPointer のインスタンスを生成します。ポインタの getValue() を実行する事で JsonValue を取得する事ができます。またポインタに対して、replace を実行する事で、指定した参照の値を変更した結果の JsonArray を取得する事ができます(※ オリジナルを直接書き換えるわけではない)。


JsonPointer クラスには、ここで示すように様々なメソッドが用意されています。しかし、ここで1点注意をしなければならない事があります、add, replace, remove 等のメソッドは直接オリジナルの JSON ドキュメントに対する変更を行うわけではないという点です。JsonObject や JsonArray はイミュータブル(不変)のデータなので、直接それを変更するわけではなく、変更した後に新しい JsonArray や JsonObject を生成するという点に気を付けてください。オリジナルの JSON ドキュメントを編集したい場合は、JsonPointer ではなく、次に紹介する JsonPatch を利用します。


続いて、JSON パッチについて紹介します。
JSON パッチは、IETF RFC 6902 : JavaScript Object Notation (JSON) Patchで定義される仕様で、特定の JSON ドキュメントに対して行う操作(追加、変更、削除等)内容が記載された JSON のドキュメントのフォーマットです。JSON パッチのドキュメントは、op (add,replace,remove 等) と path (JSON ポインタ)が必須で、それ以外は必要に応じて追加できます。また、MIME タイプ “appliaction/json-patch+json” を指定し、HTTP の PATCH メソッドを利用できます。

※ JsonArray や JsonOBject はイミュータブル(不変)なオブジェクトなので、直接変更を加える事ができません。そこでオリジナルの JSON ドキュメントに対して、変更(追加、変更、削除など)を加えたい場合、新たに処理内容を記載した JSON ドキュメントを作成し、指定したドキュメントに対して操作を行う事ができるようになります。

下記に HTTP の PATCH メソッドの利用例をご紹介します。


PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: “abc123”

[
    { “op”: “test”, “path”: “/a/b/c”, “value”: “foo” },
    { “op”: “remove”, “path”: “/a/b/c” },
    { “op”: “add”, “path”: “/a/b/c”, “value”: [ “foo”, “bar” ] },
    { “op”: “replace”, “path”: “/a/b/c”, “value”: 42 },
    { “op”: “move”, “from”: “/a/b/c”, “path”: “/a/b/d” },
    { “op”: “copy”, “from”: “/a/b/d”, “path”: “/a/b/e” }
]


それでは、実際に JSON パッチのドキュメント記載方法と利用方法について説明します。まず、左側に示す、”mobile”:”650-234-5678″ の電話番号を (“650-111-2222”) に変更する場合を考えてみましょう。変更するために処理内容を記載した、JSON パッチのドキュメントを生成しますが、先ほど説明したように、op と path は必須です。ここでは既存の値を変更したいので、op には “replace” を指定します。また変更対象の値は、JSON ポインタで “/0/phones/mobile” と表す事ができますので、path にこの値を記載します。最後に value に変更後の値を指定する事で、電話番号を変更するための JSON パッチのドキュメントができあがりました。


また次に既存の JSON ドキュメントから要素を削除する例を確認してみましょう。この例では、0 番目を全部削除する場合を考えます。削除するために、JSON パッチのドキュメントを生成しますが、先ほどと同様 op と path は必須で、それぞれ remove と JSON ポインタで対象を指定します。


さて、基本的な JSON パッチの概念が理解できましたので、Java でどのようにしてパッチを扱うかについてご紹介します。オリジナルの JSON のドキュメントが JsonArray の target に代入されている事とします。また JSON パッチの記載内容が JsonArray の patch に代入されている事とします。Json クラスのクラス・メソッド createPatch(patch) を実行し、JsonPatch のオブジェクトを取得します。そして JsonPatch の apply メソッドをターゲットに対して実行します。このようにとても簡単にパッチを適用できます。


最後に、JSON クエリに対する Lambda & Stream API の適用についてご紹介します。JSON-P で提供される API の javax.json.JsonObject, javax.json.JsonArray はそれぞれ、java.util.Map, java.util.List インタフェースを実装したクラスです。そして、Map や List は Java SE 8 で導入された Lambda 式や Stream API を利用してバルク(一括)操作を行う事ができるようになります。具体的には、JSON ドキュメント中のデータのフィルタリングや変更(マッピング)などのバルク(一括)処理ができるようになります。下記に Java SE 8 の Lambda 式や Stream API を使用して JSON データに含まれるデータの抽出を行う例を紹介します。


Stream を取得するために、JsonObject, JsonArray で getValuesAs(JsonObject.class).stream() を実行します。一旦 Stream のインスタンスを取得した後は、java.util.stream.Stream で提供される filter や map といった中間操作用のメソッド、collect といった終端操作用のメソッドを、通常の Stream API と同様実行する事ができます。この例では、filter メソッド内で、性別が女性の方をフィルタリングし、 JsonObject として抽出しています、次に map メソッドで、抽出した JsonObject 中から、女性の名前を getString(“name”) で取得し、結果として String のストリームを返しています。最後に collect メソッド内で、結果を List として返しています。つまり List<String> femaleNames には女性の名前の一覧が代入されてます。

Lambda 式と Stream API を利用して JSON ドキュメントのデータの抽出等がかんたんにできる事が分かりました。しかし、Stream API の終端操作 Collectors で標準に提供する機能では、配列やリストなどへの変換しかできません。Stream API を利用して任意の中間操作を行った後、最終的に終端操作で直接、JsonObject や JsonArray のオブジェクトを取得できるとさらに有用です。そこで、Java EE 8 では java.util.stream.Collectors クラスを拡張した JsonCollectors を新たに提供する予定です。JsonCollectors では最終的に JsonObject や JsonArray を取得するためのメソッドを追加したり、groupingBy メソッドで結果のグルーピングをおこなうためのメソッドも提供する予定です。


具体的に JsonCollectors の利用例を紹介します。先ほどの例では collect で List を返していましたが、その代わりに collect で JsonCorrectors.toJsonArray() を指定する事で、結果 JsonArray オブジェクトとして結果を取得する事ができます。


最後に、今までご紹介してきた、JSON ポインタ、JSON パッチ、Lambda 式 & Stream API を使用して、オリジナルの JSON ドキュメントに対して一気に変更を加える例を紹介します。ここでは、電話番号のエリアコード(地域識別番号)で 415 を含むデータのみを抽出し、そのエリアコードを 415 から 650 に一括変更するための処理を記載します。まず、Stream を取得した後、filter メソッドで電話番号のエリアコードが 415 を含む JSONObject の Stream を取得します。次に、map メソッドで エリアコードの部分を 415 から 650 に変換するための JSON パッチを動的に生成し、生成した JsonObject の Stream を返します。最後に collect メソッドで、条件に一致する全ての変更用のパッチを含む JsonArray を生成し返します。パッチ用の JSON ドキュメント生成後、オリジナルの JSON ドキュメント(contacts) に対して、Json.createPatch(patch).apply(contacts) でパッチを適用する事で結果を取得しています。
このように、Lambda 式 & Stream API を利用する事で、より簡単にパッチの適用ができるようになります。

JSON-B に関する詳細は下記 JavaOne の発表資料「Java API for JSON Binding
Introduction and update
」もご参照ください。

ここでご紹介した API に関して、ご意見、ご要望がある場合は、メーリングリスト、JIRA などでお問い合わせください。
https://java.net/projects/jsonb-spec/
https://java.net/jira/browse/JSONB_SPEC/

続いて、Server-Sent Events (以降 SSE) について説明します。


歴史を少し振り返ると、サーバ側で発生するイベントをリアルタイムに通知するための仕組みは、今まで Ajax を使った Polling, Comet(Long Polling,Streaming), WebSocket が利用できました。Polling や Comet は、パフォーマンスが非常に悪く、大量のリクエストを捌くサービスを提供する事が困難でした。WebSocket はハイ・スケーラブルで双方向通信を実現できますが、専用のプロトコルを利用するため、これをサポートするクライアント、サーバ、さらに HTTP プロキシ等が必要でした。一方で SSE は純粋な HTTP を使用し、サーバ側からクライアントに対する一方向へのメッセージ通知としては利用できます。双方向通信ではなく、サーバからの一方向通信でよい場合、SSE は有用です。

SSE は、現在 W3C で仕様がドラフトとしてまとめられています。
http://www.w3.org/TR/eventsource/

SSE は、クライアントからサーバに接続しコネクションが確立した後は、サーバからクライアントに対して一方向でデータを送信します。この際、サーバ側で発生するイベントに応じて、何度も同一コネクションを利用してデータ転送する事ができます。MIME タイプとして専用のメディア・タイプ “text/event-stream” を利用します。SSE はクライアントがサーバに対してサブスクライブ(購読)要求をだして、サーバがサブスクライブしているクライアントに対してパブリッシュ(配信)するという点で JMS のパブリッシュ・サブスクライブのモデルに似ています。


現在、Java EE 上で SSE の実装を検討中ですが、どのレイヤーで実装するかを今まさに議論中です。具体的には Servlet 上、WebSocket 上、JAX-RS 上、もしくは独自のコンテナ上で実装する案があがっており、これらを検討中です。

検討案の説明資料:
https://java.net/downloads/javaee-spec/SSE-in-EE8.pdf

上記をエキスパート・グループメンバーに問い合わせ中ですが、現在、スペックリードとしては JAX-RS が一番適切ではないかと考えています。なぜならば、JAX-RS で既に HTTP のリソースに対するストリーミングをサポートしており小さな変更ですむためです。

● 小さな変更で実現
  例えば、JAX-RS でサーバ、クライアントにそれぞれ下記の API を追加します
  サーバの API として : EventOutput に対し新しいメディアタイプを追加
  クライアントの API として:Server側のイベントに対する新しいハンドラを追加
● 他のHTTPの操作と組み合わせる際に便利:新しいメディアタイプ
● Jersey(JAX-RS RI)は既に SSE をサポート済み
Jersey を利用した実装例はコチラ

JavaOne で発表された、次の JAX-RS で組み込む機能紹介の概要は下記よりご参照ください。
Let’s Talk JAX-RS.next! JSR-370 – What to expect in JAX-RS in Java EE 8

また、JAX-RS の参照実装 Jersey で既に実現している SSE の実装方法については下記をご参照ください。
Chapter 14. Server-Sent Events (SSE) Support


オリジナルの資料では Java EE 7 から導入された Concurrency Utilities for EE を使って説明されていなかったため、Concurrency Utilities for EE を使って書き直したコードを下記に記載します。ここでは、ManagedExecutorService を @Resource アノテーションでインジェクトした後、別スレッドで SSE のイベント通知を行っています。別スレッドの処理内容の例は、StockThread に記載しています。実際に SSE でメッセージ通知は EventOutput#send()メソッドで行っています。

また、SSE ではクライアント用の API も用意しています。これにより、JavaFX 等のスタンドアローン・アプリケーションでも SSE クライアントを実装し、SSE のサーバ・サイドからの通知を受信して何らかの別処理を行う事ができます。


次に、Action ベースの新しい MVC フレームワークについて紹介します。
Java EE 7 まで Web アプリケーションの開発を行う際、JavaServer Faces(以降 JSF), もしくは JAX-RS を利用できました。この中で JSF はコンポーネント・ベースの MVC フレームワークとして Java EE 5 以降標準の Web 開発フレームワークとして導入されています。一方、アクション・ベースの MVC フレームワークも世の中には多く存在します。例えば Struts や SpringMVC 等がこれに当てはまります。

Java EE の開発者にアンケートを実施した所「アクション・ベースの MVC は改めて必要でしょうか?」という質問に対し、約 6 割の方々が ハイと答えました。またその際、アクション・ベースのMVC を実装するために、「参考にすべき技術(デファクト・スタンダードな技術)はありますか?」と質問した所、75% の開発者は分からない、もしくは存在しないと答えました。

当初、JAX-RS のエキスパート・グループ・メンバーを中心に新しいアクション・ベースの MVC について議論を行いましたが、様々な議論を行った結果、JAX-RS とは別途、検討・実装した方がよいという結論になり、グループを再編し、スタンドアローンのAPI として、新しく JSR 371: Model-View-Controller (MVC 1.0) Specification として仕様策定を進めています。

※ 現在まさに仕様を検討中ですので、下記に紹介する内容は今後大きく変更する可能性があります。その点をどうぞご注意ください。


まず、MVC の各構成にどのような技術を適用するかを紹介します。アンケートの結果、参考にすべきアクション・ベース MVC が無い、もしくは分からないというご意見が多数あったため、既存の資産を有効活用するため Java EE で現在提供されている機能を組み合わせて、それらをつなぎ合わせて実装できるような MVC フレームワークを検討中です。Movel には CDI, Bean Validation, JPA 等を View は Facelets, JSP, 任意のテンプレート・エンジン(プラグイン可能なテンプレートエンジンが入れられると望ましい)等が予定されています。

一方で、現時点でまだ Controller 部分の実装が決まっていません。スペックリードが現在(10/29 から)この新しい MVC フレームワークのコントローラ部分をどのような環境で提供すべきかアンケートも実施しています。
https://java.net/projects/mvc-spec/lists/users/archive/2014-10/message/68

(A) Layer MVC on top of the Servlet API: define new set of annotations, new URI mapping algorithm and new data binding layer for controllers. This option implies no MVC + REST controllers, at least not in a elegant manner (see example on e-mail thread).

(B) Layer MVC on top of the JAX-RS API: reuse existing set of JAX-RS annotations, URI mapping algorithm and data binding layer for controllers. This option implies that MVC + REST controllers will be possible, but also that our runtime will depend on the JAX-RS runtime.

メーリングリストでの回答の多くは、(A) の Servlet API 上に Controller 実装を希望している方が多く見られるようです。一方、Oracle (Santiago) としては (B) に投票予定のようです。

(3) Oracle’s Vote: We have been busy writing some prototypes and evaluating
MVC frameworks for the last few weeks. We are not taking this decision
lightly as it obviously has a great impact on future work. Our main concern
has always been familiarity of existing APIs and duplication of work,
especially around matching (routing) and binding. These are the list of
annotations that JAX-RS defines for this:

* Matching: ApplicationPath, Consumes, Produces, GET, PUT, POST, DELETE,
HEAD, OPTIONS, Path, HttpMethod

* Binding: BeanParam, CookieParam, DefaultValue, Encoded, FormParam,
HeaderParam, MatrixParam, PathParam, QueryParam, Cookie, Form

And this is just annotations, no matching and binding semantics, etc.
This fact, together with the existence of several MVC frameworks built on top
of JAX-RS, has led us to the conclusion that JAX-RS is right technology for
MVC to be layered on. Thus, Oracle votes for option (B).

下記に JavaOne 発表時のサンプル・コードを示しますが、上記の投票結果や今後の進捗によって今後大きく変更される可能性があります。






上記では、JSP や Facelets で <form action=”/rough-example/form1a.jsp”> を記載し、ページ内に EL 式を用いてデータ・バインディングができるようになっています。またサーバ側では、クライアントのリクエストに対応する処理を @Path を付加したメソッド内で記述し、メソッドの戻り値として画面遷移先を返しています。

Java EE におけるアクション・ベースの MVC フレームワークのプロジェクトはまだ始まったばかりです。ご興味のある方は是非、java.net に存在するプロジェクトやメーリング・リストにご参加ください。

JSR 371: Model-View-Controller (MVC 1.0) Specification
The MVC specification project : java.net


HTML 5 関連で最後に、HTTP/2 対応についてご紹介します。
HTTP/2 は Internet Engineering Task Force(IETF)の Hypertext Transfer Protocol Bis (HTTPbis)のワーキング・グループで標準化が進められている、次バージョンの HTTP プロトコルです(現在はまだドラフト)。HTTP/2 の特徴として下記のような物があげられます。

* レイテンシを軽減
* Head of Line Blocking 問題の対応
* 並列処理のサポート(複数コネクションは不要)
* HTTP 1.1 の意味は保持
* HTTP 1.x との連携を定義

Java EE で HTTP/2 に対応するために、JSR 369: Java™ Servlet 4.0 Specification で対応を行います。Servlet API は、HTTP/1.x に対応していたため、単一リクエストに対し単一レスポンスを返すアーキテクチャになってました。この問題点として、例えば、同一クライアントからサーバに対して大量の HTTP リクエストを行うような場合、特定のリクエストで処理時間を多く要した場合、後続の処理が待ち状態になり全体としてパフォーマンスが低下する場合がありました。しかし HTTP/2 ではよりデータ転送の効率化をはかるために、単一コネクションで、リクエストとレスポンスを多重化できるようになります。これにより、例え一つのリクエスト処理に時間を要しても後続の処理に影響が発生しにくくなるため、より効率的なデータ転送を行う事ができるようになります。

Servlet 4.0 における変更点の詳細は下記に記載していますので、下記をご覧ください。

また、JSF 2.3 における変更点は下記ごご覧ください。


続いて、「かんたん開発」の分野における Java EE 8 の拡張ポイントについて説明します。まず、CDI の適用範囲が大幅に広がります。

CDI は Java EE 6 で導入され、Java EE 7 まで、Java EE のコンテナ、つまりアプリケーション・サーバ上で利用されてきました。実際、CDI の仕様である JSR 299 は Contexts and Dependency Injection for the Java™ EE platform として記載されていました。しかし Java EE 8 からは、JSR 365 として Contexts and Dependency Injection for Java™ 2.0 に名前を変え、CDI の適用範囲を Java EE 外にもひろげ、Java SE 環境でも利用できるようにします。これにより、EJB の組み込み可能コンテナと同様に、JUnit のテストコード等でも CDI を利用できるようになります。

Java EE 8 に含まれる CDI 2.0 では、大きな機能拡張としてここにあげる3つの機能があります。

また、上記以外にも下記のような機能拡張も予定されています。

● イベント処理の拡張
● インターセプター・デコレータの仕様への対応
● SPI の拡張
● コンテキストの拡張
● Java 8 機能への対応(タイプ・アノテーション、アノテーションのくり返し、Lambda, Stream, デフォルト・メソッド、型推論)

詳しくはWorking method for CDI 2.0をご参照ください。


まず、Java SE 環境で利用可能にするために、CDI を Java SE 環境で起動するための Bootstrap 用 API が提供されます。

CDI 2.0 first Face to face meeting feedback によると、下記のようなクラスの提供を検討しているようです(まだ議論中との事)。上記会議での議論の内容は CDI 2.0 の新機能を理解する上で重要ですのでご興味のある方はどうぞご覧ください。

public class ContainerBoot {

    /**
     * Simple boot
     */
    static BeanManager initialize() {
      ...
    }

    /**
     * Boot with parameters
     */
    static BeanManager intialize(Map&lt;?,?&gt;) {
      ...
    }
    void shutdown() {}
}

つづいて、モジュール化について説明します。CDI は Java EE 6 における標準化以降、Java EE において非常に重要な機能になっています。そして、EJB 等で培ってきた経験を元に、EJB が持つ機能も多く CDI に取り込まれて利用できるようになってきており、この方向性は今後も引き続き継続されそうです。この中で CDI が機能を持てば持つ程、CDI 自身が大きく、重量になる事も懸念されてます。そこで、CDI 自身を引き続き継続して軽量に扱う事ができるように、CDI 自身のモジュール化を検討しています。

上記では①、②、③と示しましたが、実際にはより細かく検討されています。

A. 単純な DI の機能
B. Observer パターンを利用した CDI によるイベント管理機能
C. 対象型の発見方法の拡張
デプロイしたアプリケーションの起動時に型検査を行う
D. (A+B+C+AOP:インターセプタ、デコレータ)
E. D+コンテキスト管理

詳細は CDI 2.0 modularity proposal をご覧ください

また、EJB の MDB に変わり、CDI でも非同期メッセージを受信するための新しい API も検討中です。現在の MDB の実装は、たくさんの設定が必要で MessageListener を implements したクラスの実装も必要でした。
今回、JMS をさらに簡単に利用でき、任意の CDI に対して利用ができるようにします。また、MessageListener を implements したクラスの実装も不要で、直接メソッドに @JMSListener のアノテーションを付加し、監視する Queue を destinationLookup で指定し実装できるようになります。

また、Java EE 7 までの MDB と同等の振る舞いを実装するためには、該当の CDI に対して @Singleton アノテーションを付加する事で MDB と同等の振る舞いを実現できます、また @Transactional アノテーションを付加する事でコンテナ管理のトランザクションも正しく動作します。ここに記載したコード例のように既存の MDB の実装に比べより簡単に実装できるようになります。


Java EE 7 まで提供されてきた認可(Authorization)用のアノテーションとして、@RolesAllowed や @RunAs といったアノテーションが存在しました。これらのアノテーションは多くの利用場面に有用でした。しかしより複雑な認可処理が必要な場合、別途、認可用のプログラミングを実装するか、もしくは新しく CDI のインターセプタを実装する必要がありました。また認可用のアノテーションを実装する際に、EL 式が評価できるようになる事でより多くのユースケースにかんたんに対応できるようになります。

今回、ロールに基づく認可の他、Java EE のコンテキスト情報にもアクセスし、コンテキスト情報から認可情報(プリンシパル名、ロールチェック、認可チェック)を取得する事も可能な新しいアノテーションを、CDI のインターセプタとして実装する予定です。

詳細は、JIRA に登録されている JAVAEE_SPEC-29 : EL-Enabled Authorization Annotation をご覧ください。

また、上記以外にも、CDI との連携をより強化するために、様々な場所でクリーン・アップを行います。例えば、WebSocket の実装においても CDI のスコープを利用できるようにしていますが、このように CDI が他の仕様でも幅広く利用されている事がわかります。

WebSocket の拡張に関しては下記の Slide もご参照ください。


また、Java EE 8 では Pruning (剪定:仕様の削減) 候補として EJB 2.x のリモート、およびローカルのクライアント・ビュー(EJBObject, EJBLocalObject, EJBHome, EJBLocalHome インタフェース)があげられています。さらに CORBA : (Prune CORBA interoperability) もあげられています。理由として昨今 SOAP や REST で通信を行う事が多く CORBA の利用場面が大幅に減ってきているためです。現在これらを用いて実装している場合は、アップデートをご検討ください。


最後に、Java EE プラットフォームの近代化(クラウド環境への対応)を行うための機能を紹介します。


まず、Java EE Management & Deployment API について説明します。
JSR 77: J2EE™ Management という JSR において、Java EE のプラットフォームで提供される管理オブジェクトを定義していました。これらの管理オブジェクトの各インスタンスは、構造化された OBJECT_ID で識別され、管理オブジェクトは追加機能を提供するために、コンテナ側で下記インタフェースを実装する事もできました。そして、これらの管理オブジェクトは、JConsole 等のツールを利用して管理、監視を行ったり、独自に管理・監視機能実装してアプリケーション全体の運用管理を行う事ができました。

EventProvider : 設定イベントの通知 : GlassFish 実装
StatisticsProvider:統計情報採取 : GlassFish 実装
StateManageable:状態管理(基本的なライフサイクル) : GlassFish 実装

今回提案する仕様では、現在の実装方法に代わり、REST インタフェースで管理可能な、管理オブジェクトを定義する事を目的としています。これにより、既存の HTTP のツールやライブラリを用いてかんたんに Java EE アプリケーションの管理ができるようになります。またこれにあわせ、エキスパート・グループ・メンバーは、既存の Management EJB の API や JMX API をオプションにするべきかどうかも検討中です。これは仕様をかんたんにするためという理由だけではなく、今回提案する REST インタフェースをより積極的に採用していただくためです。

新しい REST インタフェースは、既存で提供している OBJECT_NAME を URL に変換し、また個々の管理オブジェクトに対する CRUD 操作も可能です。EventProvider のイベント通知に Server-Sent Events もサポートする予定で(WebSocket も検討中だが、対応ツール(HTTPのアップグレードは不要)リアルタイムで監視する事ができるようになります。

また、JSR 88: Java™ EE Application Deployment という JSR において、デプロイ・ツール用のインタフェースが定義されていました。そしてこれに準拠したデプロイ・ツールから、個々のアプリケーション・サーバに対して直接アプリケーションをインストールする事ができました。JSR 88 のサポートは Java EE 7 からオプション化されています。

デプロイ用の API も上記、REST インタフェース内に取り込む予定です。このインタフェースを利用する事で、アプリケーション・サーバのインスタンスに対して、REST インタフェースを通じて直接アプリケーションをインストールする事ができるようになります。その際、依存するリソース定義や管理も REST インタフェースを通じてできるようになります。


次にセキュリティについて説明します。現在、セキュリティの設定・実装に関する多くがアプリケーション・サーバ固有設定になっており、これにより移植性が大きく損なわれていました。今回、これらサーバ独自の設定を排除し標準化する事で、クラウド環境でより柔軟に移植性の高いアプリケーションの構築が可能になります。
これらは、JSR 375: Java™ EE Security API で検討中です。

まず、パスワード・エイリアスを導入します。これまで、アプリケーション・サーバからデータベースや、LDAP 等の外部リソースへの接続するためには、サーバ側の設定でユーザ名、パスワードを設定していました。所がこのユーザ名、パスワード管理はアプリケーション・サーバ固有で、一部のアプリケーション・サーバでは生のパスワードを記載しなければならない場合もありました。データベースや LDAP への接続用のユーザ名やパスワードを生の形で見えるようにしておくのは非常に危険です。そこで、生パスワードを記入しなくてもよい標準の方法を提供します。

@DataSourceDefinition{
  name=“java:app/MyDataSource”,
  className=“com.example.MyDataSource”,
  …
  user=“duke”,
  password=“${ALIAS=dukePassword}”)

上記の構文は、現在 Java EE の参照実装 GlassFish で採用されているパスワード・エイリアスの指定方法で、標準化にあたりこれをベースにしていますが、パスワードの値には、実パスワードを参照するためのエイリアス(仮の名前)が設定されており、実行環境が必要に応じてエイリアスから元の実パスワードを参照するようになっています。

ご参照:Password Aliasing for EE 7

続いてユーザ管理について説明します。Java EE 7 までユーザ管理(認証・認可)を扱うアプリケーションの実装は、各アプリケーション・サーバ・ベンダーに依存していました。つまり統一的なユーザ管理用の API も用意されていなかったため、概念は共有できても実装コードは個別に行う必要がありました。以前、GlassFish v4 で始める Java EE JDBC レルム ハンズオン・ラボ として GlassFish 上で Java EE6/7 利用者向けのハンズオン・ラボを公開しましたが、ここで記載した内容は他のコンテナではそのままでは利用できません。そこで、このようなユーザ管理を行うアプリケーションを作成する際の、標準化を行い移植性の高いアプリケーションを構築するため、ユーザ管理機能の標準化が行われます。
この仕様もまた、JSR 375: Java™ EE Security API 内で行われています。また、JIRA に登録されている JAVAEE_SPEC-9 : Simplify and standardize authentication & role mapping もご参照ください。



ユーザ管理を行うために、3つのコア・クラスを提供します。これらを順に紹介します。

● UserSourceDefinition:データ・ソース(DB, LDAP, ファイルなど)を定義
● UserService:ユーザの管理(追加、変更、削除など)機能を定義
● UserInfo:ユーザ情報の定義(ユーザ名、パスワード、有効期限など)

UserSource(DB, LDAP, ファイル、その他)のリソース中に含まれるユーザ、グループを UserService で処理し、個々のユーザは UserInfo として管理され、ユーザ名、パスワードだけでなく、有効期限や、アカウントのロック状態なども管理ができるようになります。

具体的に、LDAP からユーザ、パスワードを参照するアプリケーションを作成する例をここで紹介します。@LdapUserSourceDefinition というアノテーションを付加し、ユーザ情報が含まれる LDAP ディレクトリをしていします。またこれを利用する為には、@Resource アノテーションを付加し UserService をインジェクトしています。UserService のインスタンスを取得した後は、下記に示すメソッド(現時点での仮案)を利用してユーザ管理、グループ管理を行う事ができるようになります。


+ UserInfo:loadUserByUsername(username)
+ changePassword
+ createUser
+ deleteUser
+ updateUser
+ userExists
+ createGroup
+ addUserToGroup
+ removeUserFromGroup
+ isUserInGroup

また、UserInfo のインスタンスは下記のフィールドを持ち、ユーザ自身の管理も標準で用意にできるようになります。

+ Username
+ Password
+ AccountExpired
+ AccountLocked
+ PasswordExpired
+ Enabled
+ Attributes


続いて、ロール・マッピングについて説明します。ロール・マッピングもユーザ管理同様、アプリケーション・サーバ固有に設定・実装が必要でした。ロールマッピングの実装もまた標準化を行います。

ロール管理を行うために、2つのコア・クラスを提供します。これらを順に紹介します。

● RoleMapper:ロール情報が保存されるデータ・ソース(DB, LDAP, ファイルなど)を定義
● RoleService:ロールの管理(権限の付加、排除、権限の有無チェックなど)機能を定義


RoleMapper(DB, LDAP, ファイル、その他)のリソース中に含まれるロール情報を RoleService で処理します。

ここでは、メモリに存在するロール情報を元に、ロール管理を行うアプリケーションを作成例を紹介します。ここでは、@MemoryRoleMapperDefinition アノテーションを付加し、その中でロール情報を定義しています。ここで定義されたロール情報を元に @Resource アノテーションで RoleService をインジェクトしインスタンスを生成しています。getRolesメソッドの引数で与えられたユーザが持つ全てのロール一覧を取得するために、getRolesForUser(username) を実行しています。RoleService が提供するメソッドの一覧(現時点での仮案)は下記の通りです。


+ grantRoleToUser(username, role)
+ revokeRoleFromUser(username, role)
+ hasRoleForUser(username, role, includeGroups)
+ getRolesForUser(username, includeGroups)
+ getUsersWithRole(role, includeGroups)
+ grantRoleToGroup(group, role)
+ revokeRoleFromGroup(group, role)
+ hasRoleForGroup(group, role)
+ getRolesForGroup(group)
+ getGroupsWithRole(role)

このように、ユーザ管理用の API やロール管理用の API が標準化される事で、よりかんたんにユーザ管理アプリケーションが実装できるようになるだけでなく、移植性の高い認証・認可のアプリケーションを構築できるようになります。

Java EE 8 は 2016 年の秋頃を目処に仕様を FIX し提供する予定です。

また、これに向け Java EE 8 は JSR 366 として登録され投票の結果、満場一致で承認されました。

詳細なロードマップは上記ですが、Java EE 8 の正式リリース時には、今までと同様 GlassFish が参照実装として提供される予定です。

現時点で登録済みの Java EE 8 関連の JSR 一覧を下記に示します。下記 JSR もどうぞご参照ください。

● JSR 366: Java Platform, Enterprise Edition 8 (Java EE 8) Specification
● JSR 107: JCACHE – Java Temporary Caching API
● JSR 365: Contexts and Dependency Injection for Java™ 2.0
● JSR 367: Java™ API for JSON Binding (JSON-B)
● JSR 368: Java™ Message Service 2.1
● JSR 369: Java™ Servlet 4.0 Specification
● JSR 370: Java™ API for RESTful Web Services (JAX-RS 2.1) Specification
● JSR 371: Model-View-Controller (MVC 1.0) Specification
● JSR 372: JavaServer Faces (JSF 2.3) Specification
● JSR 373: Java™ EE Management API 2.0
● JSR 374: Java™ API for JSON Processing 1.1
● JSR 375: Java™ EE Security API

その他、メンテナンス・リリースとしてここに示す各既存 API の改善も検討されています。

Java EE 8 の今後にご興味のある方は Java EE プロジェクトにご参加頂き、メーリング・リスト等でフィードバックをください。


Adopt-A JSR プロジェクトを通じて、日本 Java ユーザ・グループの一員としてフィードバック等をおこなってください。

最後に、Java EE 7 が日本で本格的に導入されるのは 2015 年からですが、Java EE 7 のプロジェクトを開始するにあたり、その先の Java EE 8 の変更点等を理解し意識した上でプロジェクトを進めていく事は、将来の移行、更新において非常に有用です。例えば、Pruning 予定の EJB 2.x の機能を使っているかた、Java で CORBA の利用をご検討中の方は時代の流れをいち早くつかみ、そうしたコードを排除する事がより安全に長く使っていただくための秘訣です。また認証・認可の実装コードも将来標準化される予定のクラスやメソッド・シグネチャを理解しておく事で、移行も用意になるかと想定します。Java EE 8 が市場で投入されるようになるのは、2017 年後半〜2018年辺りになる事が予想されるので随分先の内容ですが、将来の動向もみながらどうぞ今のプロジェクトをお勧めください。2016 年にリリース予定の Java EE 8 をどうぞ楽しみにしてください。

2014年12月19日 at 10:00 AM 1件のコメント

Java EE 7 ローンチ (US 時間: 06/12 午前9時)


US 時間で 2013 年 6 月 12 日 午前 9 時より Java EE 7 のローンチ・イベントが開始します (日本では 2 回目のローンチ・イベントで 6 月 13 日 午後 1 時から参加頂けます)。Java EE 7 は、 2009 年にリリースされた Java EE 6 をベースに、4 つの新機能 (WebSocket, JSON, Batch, Concurrency Utilities for EE) と、既存の機能に対する大幅な更新 (JSF 2.2, JAX-RS, EL 3.0, JMS 2.0)を加えた、最新のエンタープライズ向け Java 標準技術です。

Java EE 7 に含まれる各種技術に触れたい場合、Java EE 7 の参照実装である GlassFish v4 を入手した上で、Java EE 7 のチュートリアルをご参照いただきお試しください。また、GlassFish v4.0 をバンドルし、 Java EE 7 の開発に対応した NetBeans 7.3.1 を入手いただく事で余計な設定は不要でいち早く Java EE 7 の開発を体験していただく事ができます。

Java EE 7 の新機能

  • Web Socket API
  • JSON Processing
  • Batch
  • Concurrency Utilities for Java EE

今日は、Java EE 7 の正式リリースを記念して、私が今まで様々な所で紹介してきた Java EE 7 のプレゼン資料をまとめ、また過去に発表した内容の中で、正式リリース時点で変更してしまった部分等も改めて見直し、最新情報にアップデートした資料を下記に共有します。全部で P165 ありますので、必要に応じて SlideShare よりダウンロードしてご参照ください。




本ブログをご参照頂いた皆様へ:
もしよろしければ、下記のアンケートにご協力頂けないでしょうか。今後の情報提供の際に役立てたいと思います。(※ アンケートにお応え頂くと他の方の結果をご覧頂けます。)



下記に Java EE 7 の技術のうち新規追加された 4 つの機能について簡単にご紹介します。

* Java API for WebSocket 1.0 (JSR-356):


WebSocket は RFC 6455 で定義された HTTP をアップグレードした TCP ベースのプロトコルで、双方向・全二重の通信が可能なプロトコルです。最新バージョンのブラウザであれば IE 10 を含む、ほぼ全てのブラウザが WebSocket に対応しています。JSR-356 は Java EE に含まれる技術ですのでアプリケーション・サーバ上で動作する WebSocket を実装する事はもちろんできますが、Java SE の環境上でも WebSocket のプログラムを実装するための API を提供しています。サーバ、クライアント共にクラスに対してアノテーション(@ServerEndpoint, @ClientEndpoint) を付加、もしくは javax.websocket.Endpoint クラスを継承したクラスを定義し実装します。クラス内には WebSocket の各ライフサイクルで必要な実装をそれぞれ、OnOpen, OnClose, OnError, OnMessage 内で実装します。
WebSocket はクライアントとサーバ間の通信において、HTTP のように通信時に余分なデータ(HTTP ヘッダ)を互いに送り合う事はなく通信コストを大幅に削減し、リアルタイム通信が必要な環境などで大きな注目を浴びている技術です。今まで、Comet, Reverse Ajax 等の技術を使って実装していたリアルタイムの情報配信システムにとっては、大幅にパフォーマンス向上が可能なWebSocket が標準の Java EE に含まれる事で、エンタープライズ環境でも安心して使う事ができます。

参考資料:

● Java EE 7新機能の目玉「WebSocket対応」、「バッチ処理」をアルン・グプタが解説──Java Day Tokyo 2013レポート
● Java EE 7 チュートリアル : WebSocket API
● DZone : JSR 356, Java API for WebSocket
● java.net WebSocket Spec

* Java API for JSON Processing (JSR-342)


JSON-P は JSON の処理(パース、生成、クエリなど)を Java で実施するための API を提供します。実装は、ストリーミング API もしくは オブジェクト・モデル API の2種類の方法のいずれかを利用することができます。
ストリーミング API は、イベント・ベースのパーサを利用して、発生するイベントに応じて JSON の解析処理、生成処理などのプログラミングを行う事ができます。開発者はコールバックイベントではなく、次に発生するイベントの処理を実装していきます。ストリーミング API を利用するためには、javax.json.stream パッケージ内の JsonParser や JsonGenerator を利用します。

オブジェクト・モデル API はメモリ上に JSON のデータをオブジェクトのツリー構造として表現し、開発者はこのツリーに対して解析や修正を行います。この方法はとても簡単でさらに直感的に扱う事ができますが、その一方で Streaming モデルよりも若干遅く、またメモリもより消費します。オブジェクト・モデル API を利用するためには、javax.json パッケージ内の JsonReader, JSonWriter, ビルダー(JsonObjectBuilder, JsonArrayBuilder)等を利用します。

参考資料:

● Java EE 7 チュートリアル:JSON
● java.net : JSON
● Java EE エキスパートグループ・メンバー(Markus Eisele):Test driving Java API for Processing JSON with GlassFish 4.0
● InfoQ :
JSON用標準JavaAPI

* Batch Application for the Java Platform (JSR-352)


バッチは、ユーザとのインタラクティブな操作が不要な処理を実行します。jBatch ではバッチ・ジョブの定義、実装方法を提供します。ジョブ仕様言語を XML で定義し 、バッチ関連アノテーション、インタフェースから構成されるビジネスロジックを実装します。またバッチ・コンテナでバッチ・ジョブの実行を管理します。

バッチ・ジョブはチャンク形式とタスク(Batchlet)形式のステップを含んでいます。
チャンク形式のステップはデータ・ソースからデータを読み込み、各データに対してビジネスロジックを適用し結果を保存します。
チャンク形式は3つの要素(入力、操作、出力)から構成されます。まず、はじめにデータ入力の部分では、データ・ソースから一度に一つのデータを読み込みます。たとえばデータベースのエントリやファイル、ディレクトリ、ログファイルに含まれるエントリ等がこれに当てはまります。次にビジネス・ロジックの適用部分では、アプリケーションで定義されたビジネス・ロジックを使用して一度に一つのデータの操作を行います。例えばデータのフィルタリング処理、データのフォーマットなどがこれに当てはまります。最後の出力部分では処理が行われたデータの保存を行います。データの入力では、javax.batch.api.chunk.ItemReader インタフェースを実装したクラスを定義します。データの処理には、javax.batch.api.chunk.ItemProcessor インタフェースを実装したクラスを定義します。出力ではjavax.batch.api.chunk.ItemWriter インタフェースを実装したクラスを定義します。

タスク形式のステップは、データ・ソースからデータを取得して処理を行うのではなく、任意のタスクを実行します。例えば、ディレクトリの作成、削除、ファイルの変更、データベース・テーブルの作成・破棄、リソース設定等がこれに当てはまります。タスク・ステップはチャンク形式とは異なり通常短時間で終わる処理を実装します。タスク形式のステップでは、javax.batch.api.chunk.Batchlet インタフェースを実装したクラスを定義します。

参考資料:

● Java EE 7新機能の目玉「WebSocket対応」、「バッチ処理」をアルン・グプタが解説──Java Day Tokyo 2013レポート
● Introducing JSR-352 – Batch Applications for the Java Platform

* Concurrency Utilities for Java EE (JSR-236)


Concurrency Utilities for Java EE はエンタープライズ環境における並列処理タスクの実装方法を提供します。Java EE 6 まではWeb コンテナ(JSP/Servlet)、もしくは EJB コンテナ(EJB)上から新しいスレッドを生成する事は禁止されていました。これは、これらのコンテナ上からスレッドを生成した場合、生成されたスレッドがコンテナ外部で動作しコンテナから生成されたスレッドを管理する事ができなくなるためです。Concurrency Utilities for Java EE ではコンテナ上で安心して新しいスレッドを生成する方法を提供します。

最も簡単に並列タスクを EE 環境で利用するためには、javax.enterprise.concurrent.ManagedExecutorService を利用します。ManagedExecutorService は Java SE の Concurrency Utilities で提供されるjava.util.concurrent.ExecutorService インタフェースを継承していますが ManagedExecutorService は Java EE の実行環境(つまりアプリケーション・サーバ)で実装されています。サーバ側の ManagedExecutorService の実装への参照を、自身のプログラム上で JNDI ルックアップ、もしくは @Resource アノテーションを使用してインジェクトし利用できるようにします。リソースをインジェクトした後は、Runnable, Callable インタフェースを実装したタスクを execute(), submit(), invokeAll(), invokeAny() 等のメソッドを呼び出して実行します。

参考資料:

● JSR 236 スペックリード:Anthony Lai の説明資料 (PDF) : Concurrency Utilities for Java EE
● Concurrency Utilities for EE の説明(私のブログ)
● ZDNet builder : マルチコア時代のCPUリソースを有効活用–Java EE 7で進化した並列処理を理解する
● @IT : エンタープライズ環境におけるマルチスレッド/並列処理の過去・現在・未来
● DZone : Modern concurrency and Java EE



以上が Java EE 7 で提供される新機能です。Java EE 7 の参照実装である GlassFish v4 をダウンロードして頂き、Java EE 7 の新機能を是非お試しください。

※ 下記に JSF 2.2 と EL 3.0 に関して説明していますが、これらは Java EE 6 から更新された技術です。

JavaServer Faces 2.2(JSR-344)


JSF は Java EE 環境におけるデフォルトの Web 開発フレームワークで世界中で幅広く使用されています。Java EE 6 の正式リリース時には JSF 2.0 が標準で提供され、その後、JSF 2.1 がリリースされました。
JSF 2.1 では JSP ベースのページを .jspx ファイルとする事で、Facelets として扱う事ができるようなり、JSF 1.2 で実装されたコードをマイグレーションしやすいような方法を抵抗した他、プラグイン可能な Facelet のキャッシュ機能を実装しています。また ServletContainerInitializer が追加されデフォルトの設定で問題ない場合、web.xml での設定は不要となりました。
そして、Java EE 7 では JSF 2.2 としてさらに大きな変更が加わりました。

* HTML 5 への対応(Pass-througu の属性が追加)
* 画面遷移における新機能の追加
Faces Flow
* ステートレス・モードの追加
* リソース・ハンドリング機能の改善
(マルチ・テンプレート機能は次のバージョンへ持ち越されました)
/contracts, META-INF/contracts にテンプレートのリソースを配置
* その他

この中で、特筆すべき事は JSF にステートレス・モードが追加された事です。JSF は 1.x のリリース当初から JSF における View の全てのステート(状態の情報)を保持していました。これはメモリも大量に消費し、パフォーマンスも良くありませんでした。そこで JSF 2.0 からは、部分的に状態を保存する Partial State Saving の機能が追加され、JSF 1.x の頃に比べパフォーマンスを改善する事ができました。そして JSF 2.2 からはついに状態を持たないステートレス・モードが JSF 2.2 に追加されました。これは現在の流行にそう形ですが、パフォーマンスが大幅に改善しメモリの使用量も減ります。またクラスタ環境で任意のノードに対してリクエストを送信する事が可能になります。今まで JSF をパフォーマンスの観点から見送っていた方々も JSF 2.2 の stateless (<f:view transient=”true”>)モードをご使用ください。

* Expression Language 3.0 (JSR-341)


EL は Java Beans のプロパティやメソッドとのバインディングに使用する式言語で、通常、JSP, JSF のビューから CDI で実装されたバッキング・ビーンのプロパティやメソッド呼び出しなどを結びつけるために使用します。
EL 3.0 では新たな構文が追加されています。新たに Java のコレクションに対して LINQ式を記述できるようになった他、Lambda 式も EL 式内に記述できるようになりました。ただし、EL における LINQ 式はコレクションに対する操作のみが許可されているため、直接 DB を操作する事はできません。また、EL 内で記述する Lambda 式は Java SE 8 で提供される Lambda 式の文法と同一ですが、動作環境は Java SE の環境には依存しません。つまり Java SE 7 の環境上でも EL 式内においてのみ Lambda 式を記載できるようになっています。
また EL は今まで Java EE の環境でしか動作しませんでしたが、EL 3.0 では Java SE 環境上でも動作するようになりました。

最後に、本日正式リリースされた Java EE 7 は Java EE 6 をベースに、プラスαの要素をご理解いただく事で、簡単に Java EE 7 に移行する事ができます。

2013年6月12日 at 7:07 PM 2件のコメント

JJUG CCC 2013 Spring の発表資料について


本日、JJUG CCC 2013 Spring が開催されました。Oracle からはUS Oracle Corporation からJim Weaver (Twitter : @JavaFXpert) が基調講演で「What’s New for JavaFX in JDK 8」を発表し、午後一のセッションで、「Java EE 6 から Java EE 7 に向かって」というセッションを担当しそれぞれ発表しました。2人の発表資料を公開しましたのでご報告します。

(※ 私のプレゼン資料ですが、SlideShare にアップロードした際、SlideShare 側の問題で、フォントが無いせいか、私が使用しているオリジナル・フォントからは変わって表示されています。その点ご了承頂ければ幸いです。)


基調講演-2 What’s New for JavaFX in JDK 8


H-1 Java EE 6 から Java EE 7 に向かって

今日の私のプレゼン中で行った EL(Expression Language) 3.0のデモのソース・コードも下記に公開します。デモ用に簡単に作ったものであるため、本来 JPA で DB 接続すべき所を簡単にダミーデータ(Person#createDummyData())を作成しています。

本コードは JSF 2.0 と CDI をご存知の方であれば容易にご理解いただけるかと思いますが、「全データ抽出」のボタンを押下すると、CDI の getAllData() が呼び出され、indexManagedBean.data(ArrayList) に全データがコピーされ、その一覧が dataTable に表示されます。

次に、「年齢フィルタ」のテキストフィールド(デフォルト:0)に対して年齢を入力すると、入力された年齢以上のデータを表示しています。内部的には Ajax を使って、入力された年齢情報(indexManagedBean.ageFileter)をサーバに送信し、Ajax のリスナーとして定義しているindexManagedBean.updateData()を実行していいます。ただ、indexManagedBean.updateData()は処理は何もしていません、ここでは execute=”ageFilter” をサーバに送信し、その結果を render=”tabledata” 、つまり dataTable の内容を更新するためだけにupdateData()を呼び出しています。

<h:dataTable id="tabledata" value="#{afilter = indexManagedBean.ageFileter;indexManagedBean.data.stream().filter(p-> p.age >= afilter).toList()}" var="person" border="1">

この例では、一度 DBに対してクエリを実行し、その結果をコレクションにコピーした後、さらにそのコピーしたデータに対して絞り込みを行っています。DB に対して再度クエリをなげるのではなく、EL 3.0 の Lambda 式を使って、一旦取得したデータを元に再フィルタリングを 行っています。

セッション中でも話をしましたが EL 3.0 で Lambda 式(及び LINQ 式)が使えるようになった事でビューにロジックを埋め込む事が可能になりますが、あまりやりすぎると可読性の低下にもつながりますので使う範囲はよくご検討頂いた方がよいのではないかと思います。(※ .Net の LINQ 式は DB に対しても操作可能ですが、EL 3.0 における LINQ 式はコレクションに対してのみ有効です。)

今回の例では、一旦取得したデータのフィルタンリグ等でご使用頂く事で、DB に対する負荷、インメモリ・グリッドにあるキャッシュから取得するよりもパフォーマンスがよくなる事を想定し記載しています。なぜならばヒープメモリ内にあるデータを直接操作する方がパフォーマンス的に優れるためです。(※ コレクションに対して有効な操作である事をご認識頂き用途は十分にご検討ください。)

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:h="http://java.sun.com/jsf/html"
      >
    <h:head>
        <title>Facelet Title</title>
    </h:head>
    <h:body>
        <h:form>
            <h:commandButton value="全データ抽出" action="#{indexManagedBean.getAllData()}"/><br/>

            <h:outputLabel value="年齢フィルタ"/>:
            <h:inputText id="ageFilter" value="#{indexManagedBean.ageFileter}" autocomplete="off">
                <f:ajax event="keyup" execute="ageFilter" render="tabledata" listener="#{indexManagedBean.updateData()}"/>
            </h:inputText>

            <h:dataTable id="tabledata" value="#{afilter = indexManagedBean.ageFileter;indexManagedBean.data.stream().filter(p-> p.age >= afilter).toList()}" var="person" border="1">
                <h:column> 
                    <f:facet name="header">
                        <h:outputText value="名前"/> 
                    </f:facet>
                    <h:outputText value="#{person.name}"/>
                </h:column> 
                <h:column> 
                    <f:facet name="header">
                        <h:outputText value="年齢"/> 
                    </f:facet>
                    <h:outputText value="#{person.age}"/>
                </h:column> 
                <h:column> 
                    <f:facet name="header">
                        <h:outputText value="性別"/> 
                    </f:facet>
                    <h:outputText value="#{person.sex}"/>
                </h:column> 
            </h:dataTable>
        </h:form>
    </h:body>
</html>
package jp.co.oracle.ee7samples.cdi;

import java.util.ArrayList;
import javax.faces.view.ViewScoped;
import javax.inject.Named;
import jp.co.oracle.ee7samples.model.Person;

@Named
@ViewScoped
public class IndexManagedBean {

    private ArrayList data;
    private Integer ageFileter;

    public ArrayList getData() {
        return data;
    }

    public void setData(ArrayList data) {
        this.data = data;
    }

    public Integer getAgeFileter() {
        if (ageFileter == null) {
            return new Integer(0);
        }
        return ageFileter;
    }

    public void setAgeFileter(Integer ageFileter) {
        this.ageFileter = ageFileter;
    }

    public String getAllData() {
        setData(Person.createDummyData());
        return "";
    }

    public String updateData() {
        return "";
    }
}

デモの中でもお伝えしましたが、本来 JPA で DB に接続して Person Entity に対して全レコードを抽出するコードを書く方が現実的なのですが、EL 3.0 は本来 Collection を対象とする事をわかりやすくするため、JPA を使わずに自分でダミーのデータをcreateDummyData()で作成しています。

package jp.co.oracle.ee7samples.model;

import java.util.ArrayList;

public class Person {
    private String name;
    private Integer age;
    private String sex;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Integer getAge() {
        return age;
    }

    public void setAge(Integer age) {
        this.age = age;
    }

    public String getSex() {
        return sex;
    }

    public void setSex(String sex) {
        this.sex = sex;
    }

    public static ArrayList createDummyData() {
        ArrayList<Person> data = new ArrayList<>();
        Person person;
        for (int i = 0; i < 100; i++) {
            person = new Person();
            person.setAge(Integer.valueOf(i));
            if (i % 2 == 1) {
                person.setName("山田 太郎" + i);
                person.setSex("男性");
            } else {
                person.setName("山田 花子" + i);
                person.setSex("女性");
            }
            data.add(person);
        }
        return data;
    }
}

2013年5月11日 at 3:01 PM

Servlet 3.0 web-fragment.xml による設定


Web アプリケーションの開発者は Apache Wicket や Spring 等 Servlet とは異なる別の外部フレームワークを開発時に利用する事があるかと思います。これらの外部フレームワークを使用するためには、これらのフレームワーク特有の設定 (Servlet, Filter 等)を web.xml に設定する必要があります。しかし複数の外部フレームワークを同一アプリケーション内で使用する場合、単一の web.xml ファイル内に全ての設定が含まれファイルが肥大化します。また web.xml ファイルが肥大化すると、各フレームワーク毎の設定を管理する際に可読性も低下しているため、管理が困難となります。

そこで、Web Fragment はフレームワーク毎に独自に設定を登録、管理できるようなメカニズムを提供しています。このWeb Fragment は Servlet 3.0 に導入された新しい技術で、配備記述子をモジュール化し、コンテナがモジュール化した配備記述子を認識する事ができるようになり、上記のような問題を解決しています。
一つの、web-fragment.xml ファイルは web.xml の一部として認識され、利用する外部フレームワーク毎に複数の web-fragment.xml を作成することもできます。

それでは、web-fragment.xml をどこに作成するか確認してみましょう。まず、Web アプリケーションのプロジェクトを作成します。この際、WEB-INF/lib ディレクトリ配下に、web-fragment.xml を含む jar ファイル (下記の例ではExternalLib.jar) をコピーします。

> jar tvf FragmentSample.war
0 Sun Mar 14 14:36:00 JST 2010 META-INF/
95 Sun Mar 14 14:35:58 JST 2010 META-INF/MANIFEST.MF
0 Sun Mar 14 14:36:00 JST 2010 WEB-INF/
0 Sun Mar 14 14:36:00 JST 2010 WEB-INF/classes/
0 Sun Mar 14 14:36:00 JST 2010 WEB-INF/lib/
2076 Sun Mar 14 14:36:00 JST 2010 WEB-INF/lib/ExternalLib.jar
515 Sun Mar 14 14:36:00 JST 2010 WEB-INF/sun-web.xml
469 Sun Mar 14 14:36:00 JST 2010 index.xhtml


ExternalLib.jar には、META-INF ディレクトリ配下に web-fragment.xml を作成します。
> jar tvf ExternalLib.jar
0 Sun Mar 14 14:36:00 JST 2010 META-INF/
109 Sun Mar 14 14:35:58 JST 2010 META-INF/MANIFEST.MF
995 Sun Mar 14 14:36:00 JST 2010 META-INF/web-fragment.xml


web-fragment.xml には下記のような内容を記載します。下記の例では JSF 2.0 の設定を web-fragment.xml に記載していますが、web.xml に記載する内容とほぼ同様の内容が記載されている事が分かります。
<?xml version=”1.0″ encoding=”UTF-8″?>
<web-fragment xmlns=”http://java.sun.com/xml/ns/javaee”&nbsp;
              xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221;
              xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee&nbsp;
              http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd&#8221;
         version=”3.0″>

    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
    </context-param>
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>/faces/*</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
    <welcome-file-list>
        <welcome-file>faces/index.xhtml</welcome-file>
    </welcome-file-list>
</web-fragment>

web.xml の記載は、Servlet 3.0 からオプション化されていますので、web.xml が無くても上記は動作しますが、web.xml を記載する場合は、<metadata-complete> に true が設定されていないことを確認してください。この<metadata-complete> はアノテーションの利用を許可したり、外部リソースをコンテナが自動的に検出するかどうかを指定する設定ですが、true に設定されていると、アノテーションの利用が不可になる他、web-fragment.xml 等のリソースの自動検出ができなくなります。このタグが記述されていない場合、もしくは false に設定されている場合は、アノテーションも、リソースの自動検出も有効になりますので確認してください。

<web-app version=”3.0″ xmlns=”http://java.sun.com/xml/ns/javaee&#8221; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd&#8221; metadata-complete=”false”>
(例:Servlet 3.0 でアノテーション、web-fragment.xml の有効化)

また、複数の外部フレームを利用する場合、フレームワーク毎にそれぞれの web-fragment.xml を作成する事もできます。また、設定を読み込む順番を指定するため2種類の方法を提供しています。

● Absolute Ordering
  web.xml ファイルに、<absolute-ordering> を指定して順番を設定します。

● Relative Ordering
  web-fragment.xml ファイルに <ordering> を指定して順番を設定します。

例えば、2つの外部フレームワークを2つの Web Fragment(Fragment1, Fragment2) にそれぞれ設定した場合を想定します。この時、web.xml に順番を指定する場合、下記のように記載します。web.xml の設定が最初に読み込まれた後、Fragment2→Fragment1の設定が読み込まれます。

   <web-app>
       <name>MyApp</name>
       <absolute-ordering>
          <name>Fragment2</name>
          <name>Fragment1</name>
       </absolute-ordering>
       …
   </web-app>


最後に、web-fragment.xml の設定は外部フレームワークやリソースをモジュール化して読み込ませる事が可能になる他、web.xml の肥大化を防ぎ、可読性も向上するため設定管理が楽になります。是非お試しください。

備考:
最初は、上記 web-fragment.xml の設定を Wicket 1.4 を使用して試しましたが動作させる事ができませんでした。調査した結果、現在の Wicket 1.4 は WicketFilter 中で web.xml ファイルを直接参照するように実装されているため、web-fragment.xml の設定ファイル中から設定を読み込む事ができないためでした。今後 WicketFilter 側で修正が施されれば、Wicket の設定も web-fragment.xml に含める事ができるようになるかもしれません。

WicketFilter.java のソースコード

実装部分:
InputStream is = filterConfig.getServletContext().getResourceAsStream(“/WEB-INF/web.xml”);

2010年3月14日 at 4:04 PM

Servlet 3.0 の新機能概要


Servlet 3.0 の新機能をプレゼン形式でまとめてみました。個々の機能に関する詳細は別途記載する予定ですが、ここでかんたんに概要を説明します。

Servlet 3.0 は Servlet 2.5 からかなり多くの改良が施されています。
Java SE 5 から利用可能になった、アノテーションを利用し、今まで web.xml に記載していた Servlet や Filter 等の設定をアノテーションで記載できるようになり開発生産性が大幅に向上しました。
また、プラガビリティの向上として、外部のフレームワークやライブラリの設定を web.xml 以外のファイル (web-fragment.xml) に記載できるようになったため、web.xml の肥大化を抑制でき、またフレームワークの設定管理が容易になっています。
その他では Servlet API 自身でマルチパートを扱えるようになったため、Servlet API だけでファイルをアップロードすることができるようになっています。
さらに、Servlet 3.0 から非同期処理を実現できるようになっています。この非同期処理機能は、Comet/Reverse Ajax 等のアプリケーションを実装できる他、DB アクセス等とても処理に時間がかかるような処理を非同期で処理する事ができるようになります。例えば、HttpServlet のスレッドとは別のスレッドで非同期に実現する事で DB が高負荷時に HttpServlet の最大スレッド数に到達し Web のアクセスが不可になる状態を防ぐ事もできます。
その他では、HttpServletRequest に login/logout/authenticate のメソッドが含まれ、プログラムを利用しログイン/ログアウト処理を実装できるようになった他、@ServletSecurity を使用して web.xml に記載していた < security-constraint > の設定をプログラム中で宣言できるようになっています。

改良された、Servlet 3.0 を是非お試しください。


web.fragment.xml に関する詳細は 「Servlet 3.0 web-fragment.xml による設定」 のエントリをご参照ください。


マルチパートの詳細は 「Servlet 3.0 File Upload 機能」 のエントリをご参照ください。

2010年3月14日 at 2:26 AM 1件のコメント

ここから始める Java EE 6


2009年12月に Java EE 6 がリリースされて、約3ヶ月経ちました。Java EE 6 にはかなり多くの改善がみられますが、どこから始めればいいのかわからない方に、JSF2,JPA2,EJB 3.1を使ったかんたんな Java EE 6 アプリケーションの書き方を紹介します。

Java EE 6 には非常にたくさんの技術が含まれているので一度に全てを理解することは大変だと思いますが、まずはこのサンプルを通じて、JSF,JPA,EJB にどのような変更が加わったのか、またどのような点が楽になったのか等を理解して頂ければと思います。

開発/実行環境:
開発環境:NetBeans 6.8
実行環境:Oracle GlassFish Server v3

(上記は別途インストールしておいてください。)

サンプルアプリケーションの概要:

コードを書く前にこれから作成するサンプルアプリケーションの概要について説明します。このアプリケーションはとても簡単なアプリケーションでユーザ(データ)を登録して参照するだけという、いたってかんたんなアプリケーションです。また処理フローもとてもシンプルです。

サンプルアプリケーションの処理フロー

アプリケーションの完成予想イメージは下記です。ユーザ登録画面で「作成」ボタンを押下しデータを登録した後、一覧表示画面が表示されます。また一覧表示画面中の「新規作成」のリンクを押下すると登録画面に遷移します。

サンプルアプリケーションの完成イメージ

1.新規プロジェクトの作成

それでは早速プロジェクトを作成していきます。今回作成するアプリケーションは、EJBを含んでいますが新規プロジェクトの作成時「Web アプリケーション」を選択して作成することにします。

補足:
Java EE 6 におけるパッケージ構成の変更点を紹介します。過去の Java EE のバージョンでは下記のように EJB を ear にまとめたり、JSF/Servlet 等を war にまとめたりといったようにパッケージ構成が面倒でした。Java EE 6 からはこのようなパッケージ化の必要はなくなり、EJB も war に含めてデプロイできるようになりました。 

パッケージの簡略化

それでは、メニューから「ファイル」→「新規プロジェクト(W)…」→「Java Web」→「Web アプリケーション」を選択し、「次へ>」ボタンを押下してください。

新規プロジェクトの作成

プロジェクト名に「PersonManagement」を入力し「次へ>」ボタンを押下します。

新規プロジェクト作成

次に、「サーバと設定」で配備するアプリケーションサーバとJava EE のバージョンを選択します。ここでは、「GlassFish v3 ドメイン」と「Java EE 6 Web」を選択し「次へ>」ボタンを押下します。

稼働サーバとフレームワークの選択

次に、使用するフレームワークを選択します。今回は、「JavaServer Fcaces」を使用しますのでこれにチェックを付け「完了(F)」ボタンを押下します。

フレームワークの選択

プロジェクトを作成すると下記のような画面が表示されます。

プロジェクト作成完了

2. JPA 2.0:Entity Bean の作成

新規プロジェクトを作成後、Entity Bean を作成します。Java EE 5 から Entity CMP 2.x に代わり JPA 1.0 が登場し、DBに対する持続性のコード記述がかなり楽になりました。JPA 2.0 ではさらに扱いやすくなり、機能面でも改善が施されています。(JPA 2.0 の新機能の詳細は別途記載する予定です。また今回はとても簡単なサンプルのためJAP 2.0の新機能はあまり使用していません。JPA 1.0と同等レベルの記述内容)

それでは、実際に Entity Bean を作成してみましょう。メニューから「ファイル」→「新規ファイル(N)…」→「持続性」を選択してください。

NetBeans を利用すると既存のデータベースのテーブルから Entity クラスを自動的に生成する事ができます。既に DB テーブルを作成している場合は「データベースからのエンティティークラス」を選択して作成してください。NetBeans を使う上で、この機能は大変便利です。私も普段は先に DB のテーブルを作成して、Entity クラスは NetBeans で自動生成しますので一から Entity クラスを作成する事はあまりしません。是非お試しください。

今回、私は DB のテーブルが作成されていない状態で新規にエンティティークラスを生成しますので「エンティティークラス」を選択し「次へ>」ボタンを押下します。この方法では、エンティティークラスを先に作成した後、エンティティクラスに該当するテーブルを DB 上に後から構築します(Entity クラスを元にテーブルを自動生成することもできます)。

エンティティークラスの作成

ここで新しいエンティティークラス名「Person」、パッケージ名「ent」を入力します。「主キー型」はこのテーブルの主キーの型を選択します。Person を ID で管理しますので、そのまま、「Long」型を設定します。

エンティティクラスの作成

「完了(F)」ボタンを押下する前に1点注意してください。ワーニングで「プロジェクトに持続性ユニットがありません。エンティティークラスを持続さ…」というメッセージが表示されています。これはこのエンティティクラスに対する持続性ユニットが存在していない事を意味しています。そこで「持続性ユニットを作成…」ボタンを押下し、このエンティティクラスに紐づく持続性ユニットを作成します。ボタンを押下すると下記の画面が表示されます。

持続性ユニットの作成

持続性プロバイダとして JPA 2.0 の参照実装である「EclipseLink(JPA 2.0)(デフォルト)」と、データソースを選択します。また表生成の方針ですが、「作成」を選択すると自動的に DB にテーブルを作成します。全ての入力が完了した後、最後に「作成」ボタンを押下します。
この時、後のプログラミング時に使用しますので、入力した持続性ユニット名(PersonManagementPU)を覚えておいてください。

「作成」ボタンを押下すると、「新規エンティティ作成画面」に戻ってきますが、持続性ユニットに関するワーニングが消えたことを確認した後、最後に「完了(F)」ボタンを押下してください。ボタンを押下すると入力された情報を元に ID のみを持つ Person エンティティのひな形が自動生成されます。また同時に、構成ファイル配下に、持続性ユニットの設定ファイル persistence.xmlが自動生成されます。

作成された Entity クラス(Person)のひな形を編集していきます。

ソースコードを確認すると @Entity のアノテーションが自動的に付加されている事に気づきます。このアノテーションを付加することによりコンパイラや、EJB コンテナが本クラスをエンティティクラスと解釈してくれるようになります。

名前、住所、電話番号、年齢をあつかえるようにフィールドを追加し、それぞれに対するセッタ、ゲッタメソッドを記載してください。また、@NamedQuery で JPQL を記載し、DBに登録されている全ての Person を取得できるようにします。

package ent;
import java.io.Serializable;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.NamedQuery;&nbsp;

@Entity
@NamedQuery(name="findAllPerson", query="SELECT p FROM Person p")
public class Person implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    @Column(nullable=false,length=256)
    private String name;

    @Column(nullable=false,length=256)
    private String address1;

    @Column(nullable=false,length=12)
    private String telephone;

    @Column(nullable=false)
    private Long age;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (id != null ? id.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        if (!(object instanceof Person)) {
            return false;
        }
        Person other = (Person) object;
        if ((this.id == null &amp;&amp; other.id != null) || (this.id != null &amp;&amp; !this.id.equals(other.id))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "entity.Person[id=" + id + "]";
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getAddress1() {
        return address1;
    }

    public void setAddress1(String address1) {
        this.address1 = address1;
    }

    public String getTelephone() {
        return telephone;
    }

    public void setTelephone(String telephone) {
        this.telephone = telephone;
    }

    public Long getAge() {
        return age;
    }

    public void setAge(Long age) {
        this.age = age;
    }
}

以上で、このサンプルアプリケーションに必要なエンティティクラスはできました。

3.EJB 3.1:ステートレスセッション Bean の作成

エンティティクラスを生成したので、次に EJB (ステートレス・セッション Bean) を作成します。「ファイル」→「新規ファイル(N)…」→「Java EE」→「セッション Bean」を選択し、「次へ>」ボタンを押下してください。

EJB セッション Bean の作成

ボタンを押下すると下記の画面が表示されます。ここで「EJB 名(N)」、「パッケージ(K)」を入力し「完了(F)」ボタンを押下します。

ステートレスセッション Bean の作成

補足:
上記画面を確認するとローカルインタフェース、リモートインタフェースが選択できるようになっています。
EJB 3.1 からローカルインタフェースがオプション化されインタフェースを作成する必要がなくなりました。EJB 3.0 では下記の例のようにインタフェースを定義し、それを実装しなければなりませんでしたが、EJB 3.1 からはアノテーションを付加するだけでコンテナが理解してくれるようになります。 

EJB 3.0 でのローカルインタフェースの実装例

EJB 3.0

実際にコードで書くと下記のようになります。

public interface Hello {
    public String sayHello();
}

@Stateless
public class HelloBean implements Hello {
    public String sayHello() { return "hello"; }
}

EJB の利用時

@EJB Hello helloRef;
    ...
    helloRef.sayHello();

これが、EJB 3.1 では下記のようにインタフェースを定義する必要はなくなります。

 

EJB 3.1

EJB 3.1 を利用する時のコードは下記となります。

EJB 3.1

 

それではコードを編集していきましょう。今回は、データの検索と追加を行いますので、それぞれの処理を行う2つのメソッドを実装しています。まず、@PersistenceContextのアノテーションで、(JPA Entity クラスを作成した時に作成した持続性ユニット名。persistence.xml に記載されている。)持続性ユニット名(“PersonManagementPU”)を記載します。これにより持続機能を持った EntityManager のオブジェクト(em)がセットされます。

package pejb;

import ent.Person;
import java.util.List;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.Query;

@Stateless
public class PersonEJB {

    @PersistenceContext(unitName="PersonManagementPU")
    private EntityManager em;

    public List<Person> findAllPersons(){
    //Entity(Person)クラスの @NamedQuery の記載に基づき検索
        Query query = em.createNamedQuery("findAllPerson");
        return (List<Person>) query.getResultList();
    }

    public Person createPerson(Person person){
        em.persist(person);
        return person;
    }
}

4.JSF:Managed Bean の作成

EJBと、Entity を作成したので、JSF から利用する Managed Bean を作成しましょう。「ファイル」→「新規ファイル(N)…」→「JavaServer Faces」→「JSF 管理対象 Bean」を選択し「次へ>」ボタンを押下してください。

「クラス名(N)」、「パッケージ(K)」を入力し「完了(F)」ボタンを押下します。

補足:
JSF 2.0 からは下記のような faces-config.xml の設定ファイルがオプション化されました。そこで Managed Bean の設定や画面遷移を XML ファイルに記載する必要はなく、アノテーションを利用しプログラム上で実現することができるようになりました。 

JSF1.2 までの faces-confg.xml の設定例:

<managed-bean>
<managed-bean-name>PersonController</managed-bean-name>
<managed-bean-class>PersonController</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
<navigation-rule>
<from-view-id>/foo.jsp</from-view-id>
<navigation-case>
<from-outcome>ok</from-outcome>
<to-view-id>/bar.jsp</to-view-id>
</navigation-case>
</navigation-rule>

 

 

コードを編集していきましょう。作成するクラスが Managed Bean であることをコンテナに理解させるため、@ManagedBean のアノテーションを利用します。アノテーションを指定する際、”name” 属性は必須で Managed Bean を識別する名前を入力します。

package mbean;

import ent.Person;
import pejb.PersonEJB;
import java.util.ArrayList;
import java.util.List;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;
import javax.ejb.EJB;

@ManagedBean(name="PersonController")
@RequestScoped
public class PersonController {

    public PersonController() {
    }

    @EJB
    private PersonEJB personEJB;

    private Person person = new Person();
    private List<Person> personList = new ArrayList<Person>();

    //Facelets の action="#{PersonController.doNew} により画面遷移
    public String doNew(){
        return "createPerson.xhtml";
    }

    //Facelets の action="#{PersonController.doCreatePerson} により画面遷移
    public String doCreatePerson(){
        //画面から入力された Person を DB に登録
        setPerson(personEJB.createPerson(getPerson()));
        //DB に登録されている全 Person を personList に設定
        setPersonList(personEJB.findAllPersons());
        return "listPersons.xhtml";
    }

    public Person getPerson() {
        return person;
    }

    public void setPerson(Person person) {
        this.person = person;
    }

    public List<Person> getPersonList() {
        return personList;
    }

    public void setPersonList(List<Person> personList) {
        this.personList = personList;
    }
}

5.JSF 2.0: ベージの作成

最後に、表示画面を作成します。JSF 2.0 から facelet を xhtml で記載できるようになりました。

「ファイル」→「新規ファイル(N)…」→「JavaServer Faces」を選択し「次へ>」ボタンを
押下してください。

JSF 表示画面の作成

ファイル名 (createPerson.xhtml) を入力すると自動的に .xhtml の拡張子が付加されます、最後に「完了(F)」ボタンを押下します。

JSF 表示画面の作成

自動生成されたひな形を編集して下記のコードを記載してください。Facelets で扱えるタグ等は別途紹介する予定ですが、みていただければわかるとおり、HTML も記載する事ができますし、スタイルシート等を記載することも可能です。また、JSF 2.0 から Ajax をサポートしていますので、Ajax のコードを利用してサーバと通信する事もできるようになります。

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html">
      <h:head>
        <title>Facelet Title</title>
    </h:head>
    <h:body>
        <h:form>
            <table>
                <tr>
                    <td>
                <h:outputLabel value="名前:"/>
                </td>
                <td>
                <h:inputText value="#{PersonController.person.name}"/>
                </td>
                </tr>
                <tr>
                    <td>
                <h:outputLabel value="住所"/>
                </td>
                <td>
                <h:inputText value="#{PersonController.person.address1}"/>
                </td>
                </tr>
                <tr>
                    <td>
                <h:outputLabel value="電話番号"/>
                </td>
                <td>
                <h:inputText value="#{PersonController.person.telephone}"/>
                </td>
                </tr>
                <tr>
                    <td>
                <h:outputLabel value="年齢"/>
                </td>
                <td>
                <h:inputText value="#{PersonController.person.age}"/>
                </td>
                </tr>
            </table>
            <h:commandButton value="作成" action="#{PersonController.doCreatePerson}"/>
        </h:form>
    </h:body>
</html>

最後に、登録された一覧を表示する画面を作成します。
「ファイル」→「新規ファイル(N)…」→「JavaServer Faces」を選択し「次へ>」ボタンを
押下してください。

JSF 表示画面の作成

ファイル名(listPersons)を入力し「完了(F)」ボタンを押下します。

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">
      <h:head>
        <title>Facelet Title</title>
    </h:head>
    <h:body> 

        <h:dataTable value="#{PersonController.personList}" var="psn" border="1">
            <h:column>
                <f:facet name="header">
                    <h:outputText value="名前"/>
                </f:facet>
                <h:outputText value="#{psn.name}"/>
            </h:column>

            <h:column>
                <f:facet name="header">
                    <h:outputText value="住所"/>
                </f:facet>
                <h:outputText value="#{psn.address1}"/>
            </h:column>

            <h:column>
                <f:facet name="header">
                    <h:outputText value="電話番号"/>
                </f:facet>
                <h:outputText value="#{psn.telephone}"/>
            </h:column>

            <h:column>
                <f:facet name="header">
                    <h:outputText value="年齢"/>
                </f:facet>
                <h:outputText value="#{psn.age}"/>
            </h:column>
        </h:dataTable>
        <h:form>
            <h:commandLink action="#{PersonController.doNew}">
                新規作成</h:commandLink>
        </h:form>
    </h:body>
</html>

以上で、このアプリケーションの実装は完了です。

NetBeans のメニューより「実行(R)」→「主プロジェクトを実行(R)」を選択してください。実行すると自動的にブラウザがオープンしアプリケーションのデフォルトのコンテンツが表示されます。

コンテキストルートでアクセスされた時のデフォルトページを変更したい場合は、web.xml ファイルを編集する必要があります。下記のように welcome-file-list を編集してください。

web.xml の編集

<welcome-file-list>
<welcome-file>faces/createPerson.xhtml</welcome-file>
</welcome-file-list>

設定を変更した後、もう一度プロジェクトを実行してください。すると下記のように自動的に登録画面が表示されるようになります。

データを入力して「作成」ボタンを押下してみましょう。下記のように一覧表示画面が表示されれば問題はありません。

最後に、エラーハンドリングについて紹介します。例外が発生した際に特定のエラーページにリダイレクトさせるようにweb.xml の<error-page> タグを記載する必要があります。<exception-type>で、ハンドリングした例外毎にエラーページを表示させる事が可能です。本番環境においては、少なくとも JSF で発生する例外の親である javax.servlet.ServletException を記載してください。

web.xml の編集

<error-page>
<exception-type>javax.servlet.ServletException</exception-type>
<location>/error.xhtml</location>
</error-page>

 

以上で、今回の Java EE 6 のアプリケーション作成は終了です。NetBeans を利用するとウィザードを使って、コードのひな形を作成してくれたり、また設定も極力 XML ファイルを手動で編集しなくても済むようになります。是非お試しください。今回紹介したサンプルは Java EE 6 を利用する上で最も基本的な構成と思います、上記の例を元に色々と修正を加え、DI/CDI や Bean Validation 等を加えて Java EE 6 の機能を是非色々と試してみてください。

最後に、私の環境で作成したNetBeans 6.8 のプロジェクトを下記から入手できるようにしました。
(※ Sun の mediacast.sun.com サイトにファイルをアップロードしていますので、
仮にこのサイトが閉鎖してしまった場合は申し訳ありませんがご了承ください。)

● NetBeans 6.8 のプロジェクト(ソース、設定ファイル等を含む)
● GlassFish v3 配備用 WARファイル

2010年2月26日 at 3:33 PM 2件のコメント

Java EE 6 / GlassFish v3 の仮想カンファレンス開催








Java EE 6 / GlassFish v3 に関連した仮想カンファレンス開催が

2009年12月15日 (日本時間:12/16 夜中 AM1:00 から)されます。

各セッションは30分〜1時間で開催される予定です。

日本の方は、真夜中から明け方までになるのでその時間帯で、

見ることはできないと思うのですが、今海外のエンジニアに

録画して後から見れるようにして欲しいと要望をだしていますので、

もし、録画されたらそちらを見てみてください。




詳細はコチラ




● Java EE: The Foundation for Your Business (Keynote)

● Java EE 6: An Overview (Keynote)

● GlassFish v3 – Java EE 6 Reference Implementation & Beyond (Keynote)

● Enterprise Java Beans (EJB) 3.1 Features

● Jersey, JAX-RS and REST with GlassFish v3

● Servlet 3.0

● Java Persistence API (JPA) 2.0

● Java Server Faces (JSF) 2.0

● Web Services in GlassFish

● Context Dependency and Injection (JSR 299)

● OSGi in GlassFish v3

● Dynamic Languages with GlassFish v3

● Tools for GlassFish v3: NetBeans and Eclipse

● Grizzly: NIO & Web Framework. Comet using GlassFish

● Monitoring, Management in GlassFish v3



日本時間では明日には、GlassFish の FCS(First Customer Shipment) 版がいよいよリリースされます。

また、GA(General Availability) 版はクリスマス前にはリリースされるかと思います。

年末まで各種イベントが目白押しですが、Sun の GlassFish ブロガー達が数多くの情報を

発信します。



是非、下記のタグもご参照ください。




http://blogs.sun.com/main/tags/glassfish

2009年12月9日 at 10:43 PM

過去の投稿


Java Champion & Evangelist

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2017年1月
« 10月    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

カテゴリー

Twitter

clustermap

ブログ統計情報

  • 912,019 hits

Feeds