JEE 6: 拡張性、プロファイル、そして仕様の削減

作者 Charles Humble, 翻訳者 白石 俊平 投稿日 2008年1月24日 午前12時46分

コミュニティ

Java

トピック

Enterprise Application Blocks

タグ

Java EE

公開されている詳細はまだ少し大雑把だが、Java EE 6の大まかな方向性は明らかになり、Java EE標準の役割が変わろうとしている。Java EEは、当初の構想ではエンタープライズコンピューティングにおける完全なスタックとされていたが、Java EEの現在のバージョンにおけるギャップを埋めるため、Struts、Hibernate、Seamと言ったオープンソースプロジェクトが広く大規模に採用されてきた。いくつかの場合こうしたオープンソースプロジェクトは、仕様の次期バージョンに影響を与えてきた。Java EEの役割自体は、完全なソリューションを提供すると言うよりも、ベンダーとオープンソース開発者がその上に構築を行えるような、堅牢なインフラストラクチャコードの集合を提供する、と言うものになりつつある。次期JavaEEのための包括的なJSRであるJSR 316(source)は、エキスパートグループが主な目的とする「拡張性」を実現することにより、この新しい関係をより公式な基盤にすることを目指している。さらに同仕様は、Java EEが巨大かつ複雑であることを認め、以下の二つを提案している - 仕様における特定の要素を削除すること、そして特定の開発者グループを対象としたEE機能のサブセットを提供する、プロファイルの導入だ。これはまた、前バージョンから始まった単純化のための作業 - 外部設定ファイルへの依存を減らすための、アノテーションの利用も含め - の上に構築されるだろう。

仕様の削減の為にとられるアプローチは、Java SE 6でとられたものと同じになるだろう（このブログエントリ(source)で述べられている）。それは複数ステップのプロセスとして実行される。あるリリースの時点で「削除候補」とされ、コミュニティの反応によっては、次のリリースでオプショナルなコンポーネントへと追いやられる。JSRでは、2つの仕様を最初の削除候補として提案している - 事実上JAX-WS（JSR 224, Java API for XML-Based Web Services(source)）に置き換えられているJAX-RPC [JSR 101, Java APIs for XML-Based RPC(source)]と、現在Java Persistence API [もともとはJSR 220, Enterprise JavaBeans 3.0(source)の一部として定義]で置き換えられているEJB CMPだ。Artimaでのインタビュー(source)において、EE 6のスペックリードであるRoberto ChinniciとBill Shannonは、JAXR API [JSR 93, Java API for XML Registries 1.0(source)] （WebサービスレジストリにアクセスするためのAPIで、広く使われているようには見えない）が削除候補に加わるのではないか、と示唆した。

仕様削減については大した議論を引き起こすことはなかったが、Sunによるプロファイルの使用はいくつか論議をかもしてきた。SpringSourceのCEOであるRod Johnsonは、確実に賛同している。

ようやくユーザは、ユーザがアプリケーションの構築を始める二年も前に標準化委員会が考えた「ユーザが欲しているもの」ではなく、本当に自分たちが求めるものを探し当てることができるようになるでしょう。"とJohnsonは言う。”今こそ、ソ連式の計画経済が健全な競争へと代わるべき時です。”

しかしOSGiのエバンジェリスト、Peter Kriensは決して好ましくは思っていない(source)。

EE 6向けに計画されている最初の新しいプロファイルは、Webアプリケーション開発者向けのWeb Profileだ。この新しいプロファイルの導入と同様に、その他の市場区分（例えば、電気通信・財務アプリケーションなど）向けのプロファイルを作成するためのルールが、仕様によって定義されるだろう。

"拡張性に関する技術的な詳細は、JSRがいくつかの野心的なゴールを目指しているにもかかわらずあまり明確ではない: "...私たちは、Java EEアプリケーションサーバ上にクリーンな形でレイヤをかぶせる、もしくはプラグインするためのこうしたテクノロジーが、さらに利用できると望ましいと信じています、"とJSR 316仕様は述べている。"より多くの拡張ポイントやサービス・プロバイダ・インターフェースを追加することで、プラットフォームの実装に対して、これら他のテクノロジーをクリーンに、効率よくプラグインすることができます。そしてプラットフォームに組み込まれたそれらの機能を、開発者は非常に簡単に利用することができるようになります。"

こうしたアプローチの一つの例は、JSR 196: Java Authentication Service Provider Interface for Containers(source)（コンテナ向けのJava認証サービスプロバイダ・インターフェース）だ。これはもともとJ2EE 1.4向けに計画されていた、三つのAPIのうちの一つである。これは標準的なサービス・プロバイダ・インターフェースを提供しており、認証メカニズムのプロバイダをコンテナに統合することができる。そのインターフェースを使用したプロバイダは、他のコンテナにあるコンポーネントの呼び出しの時にコンテナに使われることも含め、コンテナがアクセス可否の決定を行うための認証IDを確立するために用いられる。この仕様は2007年10月に最終リリースされており、ダウンロードすることが可能(source)だ。

これももともと1.4向けに計画されていたのだが、Java EE 6はコンテナに管理された環境での利用に適したタイマーAPIと、コンテナに管理されたスレッドプールを用いて並列処理を行うために、コンテナの管理が可能なプログラミングモデルの正式なリリースが行われるはずだ。これら二つのAPIはIBMとBEAが共同で開発し、BEAのWebLogicとIBMの WebSphereの双方で既に利用可能だ。仕様はこちらから(PDF・英語)。

EE 6に含められることが計画されている、二つの新しいAPIが存在する。一つ目はWebBeansで、JBoss SeamとGoogleのGuiceに強く影響されており、Web層とトランザクション層のコンポーネントモデルを統合することで、Java EEにおけるWebベースのアプリケーション向けに、プログラミングモデルを単純化することを目標にしている。さらにWebBeansの仕様は会話（Conversation）モデル(source)と永続（Persistent）コンテキストを提供(source)し、きめ細やかな状態管理を提供し、複数のWebトランザクションを一つの作業単位（一つの会話）として扱うことを可能にする。WebBeansモデルは、Gavin Kingの手によるマニフェスト(source)と四つの章（1章(source)、2章(source)、3章(source)、4章(source)）からなる記事により、広範囲にわたってプレビューすることができる。

"WebBeansのJSRに対する反応はおおむね肯定的だが、JSR 316に票を投じる際、IBMはいくつかの反対意見を述べている。
" 我々は、「JSFとEJBのコンポーネントを統合する」と言うJSR 299が認可された元々の理由を、JSR 299自身が超えていくと言う方向性に関心を持っています。そしてその方向に向けた努力を続けることで、JSR 299がJava EE 6から削除されるのが当然だと信じています。我々はまたも新しいコンポーネントモデル定義を加えた、Java EE 6プラットフォームを採用するのが顧客にとって容易なことだとは信じていません。"

二番目の新しいAPIははJSR 311: a Java API for RESTful Web Services（RESTful なWebサービスのためのJava API）(source)であり、よりいろいろな反応が成されている。以前のInfoQ記事(source)に、コミュニティの反応がうまくまとめられている。Brian Leonardのブログ(source)と関連リンクではこのJSRについてのさらに詳しい情報が提供されており、Bill Burkeがいくつかのフィードバック(source)を寄せている。

JavaEE6はたくさんのコアAPIの見直しをする事になるだろう。メジャーアップデートは以下のように計画されている。

1. Java Persistence API:  JPAのバージョン2は、以下を野用な機能を含む拡張が行われる。
   
   • オブジェクト/リレーショナルマッピング機能の拡張。既存のマッピングオプションの組み合わせをより柔軟にし、埋め込みオブジェクトのコレクションをサポート、順序づけられたリスト、アクセスタイプを組み合わせられるように、DDL生成をサポートするための追加のメタデータ、などなど。
   • Java Persistenceクエリ言語の機能を拡張
   • エンティティのデタッチとマージ、永続コンテキスト管理に関して、更なる規約の標準化
   • エンティティマネージャとクエリのコンフィギュレーションに対する"ヒント"のセットを標準化
   • Java EE環境向けの、プラガビリティ規約を拡張
2. Servlets: 継続的な人気にも関わらず、サーブレットAPIはJ2EE 1.4以来メジャーバージョンが登場していない。サーブレットAPI バージョン3.0が目指すところは、以下のようなものだ。
   • ウェブフレームワークのプラガビリティを改善
   •  アノテーションによってweb.xmlを省略可能にするとともに、アノテーションとジェネリクスを通じた使い易さの向上
   •  ノンブロッキング入出力、遅延リクエスト処理、遅延レスポンスクローズの提供による、非同期（Comet）処理のサポート
   •  ログイン・ログアウトのサポートとサーブレットの自己登録を含めた、セキュリティ機能の向上。
3. JavaServer Faces 2.0: ２回目となる仕様変更は（メジャーリリース）以下を目指している
   • 設定ファイルの依存関係を無くし、JSPタグハンドラの自動生成を導入する事で使いやすさを改善
   • 宣言的レンダラへのサポートを追加
   • リクエストプロセスのライフサイクル変更と、ビューの部分的アップデートを許可する事によるAJAXサポートの改善
   • 開発者がカスタムコンポーネントを書く事を、より容易に

最後に、いくつかのマイナーアップデートが存在する。

1. Enterprise JavaBeans は、 EJBコンポーネントモデルの更なる単純化を目指す。EJB 3.1は、省略可能なローカルビジネスインターフェースの導入により、BeanクラスのみでローカルEJBコンポーネントを開発できるようになるだろう。また、ejb-jarなしで、EJBコンポーネントを.warファイルにパッケージ／デプロイすることも可能になる。
2. Java EE Connector Architectureは開発の容易性と仕様の全体的な改善に焦点を当てられる。
3. JAX-WS: 詳細はまだ公表されていない。

いくつかのAPIは、Java EE 6向けの最終判断が成されていない。注目に値するのは二つだ。一つはJSR 168, the Java Portlet specification(source)で、いくつものメジャーなポータル開発者たちに受け入れられてきた。もう一つはJSR 208, Java Business Integration(source) (JBI)で、サービス仲介のための仕様だが、BEAとIBMを除く全員に支持されて来たものである。

このEE 6仕様は2008年の第四クォータを最終リリースのターゲットとしており、時間的には非常に限られている。

原文はこちらです：http://www.infoq.com/news/2008/01/jee6

• 次へ >