Java EE 技術を使用するための長期的戦略を立てる

技術の変更は当然のことであり、また必要なものですが、変更によって既存のアプリケーションの動作が影響される場合もあります。このような変更の必然性を考えると、Java™ EE などの仕様の変更に左右される技術に頼るのは危険だと思えるかもしれません。しかし、どの技術を使用するのが適しているかを判断するときに十分な根拠に基づいて技術を選択し、周到な計画を立てることによって、互換性のない変更による影響を最小限に抑えることは可能です。この記事では、読者が根拠に基づいた選択を行えるように情報を提供するとともに、変更による組織への影響を最小限に抑えるための IBM® の取り組みについて説明します。
IBM WebSphere 開発者向け技術ジャーナルより。

Jim Knutson, WebSphere J2EE Architect, IBM

Jim KnutsonJim Knutson は、WebSphere の J2EE アーキテクトです。IBM の J2EE 関連仕様への参加責任者で、WebSphere と IBM への関わりは J2EE が登場する以前に遡ります。彼は SOA および Web サービスをサポートするためのプログラミング・モデルの展開にも従事しています。



2008年 5月 14日

はじめに

Java™ EE プラットフォームはその歴史を通して何度もバージョンアップを繰り返してきましたが、これらのバージョンアップは肯定的に受け取られることも、否定的に受け取られることもありました。変更の大半は業界によって主導されているため、業界全体で必要とされる変更と言えます。それでも今までのバージョンアップのなかには、API の変更 (既存のアプリケーションのソースをコンパイルすると問題が発生する可能性があります) や振る舞いの変更 (実行時にアプリケーションが失敗する原因となります) など、「互換性のない」形でプログラミング・モデルを変更するものがありました。このようなバージョンアップは当然のことながら、互換性のない変更によって影響を受けるアプリケーションに多額の投資をしている人々にとっての懸念材料となります。

この記事では、Java EE プラットフォームでの互換性のない変更による影響を最小限にする方法、そしてこのような変更が組織に与える影響をできる限り抑えるために IBM がどのように取り組んでいるのかを説明します。


非互換性の原因

プラットフォームに非互換性をもたらす原因はいくつかあります。仕様の改善に取り組む専門家グループのメンバーが正しいことをしようと努力しているのは確実に言えることですが、彼らも人間です。完璧ではありません。どんなに懸命に努力しても、何かしら気付かないことがあるものです。

  • 非互換性の原因として最初に挙げられるのは、すべての振る舞いを完全に記述する仕様はないということです。あらゆる振る舞いを完全に記述することは実際には不可能です。これが可能だとしたら、さまざまなベンダーが採用する可能性のある、ありとあらゆる仕様本文の解釈 (ならびに拡張解釈) を予測するという部分で専門家グループのメンバーが全能でなければなりません。振る舞いが完全には記述されていないことから、異なるベンダー間でアプリケーションを移植すると移植性の問題が生じる可能性があります。さらに、拡張した振る舞いが、後に標準の振る舞いとして完全に記述され、仕様としてバージョンアップされると、問題の種となります。

    これに多少関連するのが、仕様への準拠テストは完全ではないという問題です。Java EE CTS (Compliance Test Suite) は、仕様に従った正しい振る舞いを確実にするという目的で設計されていますが、すべての要件を完全にテストすることはありません。それは、テスト・ケースの作成が不可能な場合もあれば、リソースの制約によって必要なすべてのテスト・ケースを実行できない場合もあるからです。さらに、テスト・ケースが適切に動作しないためテスト・スイートから排除されるという場合も考えられます。このため、ベンダーの作成したソフトウェアが CTS に合格したにも関わらず、その振る舞いが仕様の要求する振る舞いとは異なることに気付かないという可能性が生じます。その後、テスト・ケースを CTS に追加して問題が表面化した場合には、製品が市場に出た後に振る舞いを変更しなければならないことになります。さらに、ベンダーの作成したソフトウェアが CTS に合格し、振る舞いが (ベンダーによる仕様の解釈に従って) 適切だとしても、他の実装とは動作が異なる可能性もあります (他の実装では解釈が異なる場合)。このような場合には、仕様の明確化が必要となってきます (これは通常、メンテナンス・リリースで行われます)。こうして仕様が更新されると、すでに市場に出ている製品が新しい解釈に対応するために振る舞いを変更しなければならなくなるという事態が考えられます。

  • 次に挙げる非互換性の原因は、新しく登場した技術をプラットフォームに採用しようと急ぐことによるものです。私たちが目にした時期尚早なデリバリーの一例は、JAX-RPC です。業界全体で急速に高まっている Web サービスに対するニーズに対処するために一連の API を短時間で提供しようとしたわけですが、その後のベスト・プラクティスと使用パターンの出現により、(当初定義されていたものより) はるかに効率的な API の定義が可能だったことがわかりました。さらに、より優れた API のセットを提供するためには技術スタック全体を改訂したほうが望ましいという結果になりました。

    J2EE™ デプロイメント・モデルの早急な採用についても同じことが言えます。この技術の最初のバージョンは、アプリケーション・デプロイメントを処理するにはあまりにも不十分であることがわかり、業界で実際に採用されることはありませんでした。幸い、この特定のプラットフォーム技術を採り入れたユーザーは非常に少なかったため、その削除や置き換えによって影響を受けたユーザーはほとんどいませんでした。

  • 3 つ目に挙げる非互換性の原因は、この問題自体が認識されないことです。専門家グループは、その仕様で扱おうとしている分野での業界の専門家で構成されていますが、それでも非互換性が認識されなかったり、懸念事項となっていない場合があります。専門家グループは全体的な目標に向かって取り組みますが、専門家グループを構成するそれぞれのメンバーにも独自の目標があり、その目標は必ずしもプラットフォームのユーザー一人ひとりのニーズと一致する (あるいはニーズを考慮して立てられている) わけではないという点を忘れないでください。

  • 最後に挙げる非互換性の原因は、互換性を確実にするための専用リソースがないことです。Java EE プラットフォーム・ベンダーの場合、テスト作業を行い、見つかった問題を報告するという手段で互換性を確実にすることも可能ですが、それには仕様がまだドラフト段階にあるときから、ベンダーが仕様を実装して動作するようにしなければなりません。この方法が若干現実的でないことは証明されています。


IBM による対策

IBM は互換性のない変更についての苦情に耳を傾け、可能な限りその問題に対処しようと取り組んでいます。Java EE 5 仕様以来、IBM では仕様が後方互換性 (バイナリーとソースの両方) を維持するように懸命な努力を続けています。Sun™ では常に、Java に対するバイナリー互換性を保持してきましたが、IBM はアプリケーションの保守性にはソース互換性も同じく重要であることに気付いたからです。その結果、今では仕様のリーダーたちが互換性に関する記述を仕様に含めるようになっています。

もちろん、すべての振る舞いを完全に記述することはほぼ不可能です。そこで、IBM はさまざまな専門家グループに参加し、すでに問題が明らかになった仕様に関するフィードバックを提供しています。IBM が認識した互換性問題のうち、この活動によって回避できたものもあれば、そうでないものもあります。

成功例の 1 つは、JAX-RPC を凍結し、新しい仕様 (JAX-WS) をその後継として公開することで、JAX-RPC に対して互換性のない変更が行われないようにしたことです。現行の API へのマイグレーションに時間がかかることには変わりありませんが、これによって短命に終わる要件はなくなります。仕様を凍結すれば、特定の API のセットが戦略的でないと見なされていることをユーザーが認識できる一方、その仕様に従って作成した既存のアプリケーションの振る舞いには影響しません。顧客の投資を守ることが、IBM が標準に参加することによって第一に達成しようとしている目標の 1 つです。

これに関連してくるのが、非推奨の問題です。IBM では古くなった技術を使用した振る舞いと API を認識し、それを維持するために仕様の要件の枠を超えてサポートを提供するよう努めています。そしてある時点で、IBM はこれらの既存の振る舞い、あるいは API を「非推奨」として宣言し、将来的に削除する意向を示します。一般に、非推奨として宣言された振る舞いは 2 回の完全な IBM 製品リリース・サイクルでサポートされてから削除されることになっています。

非互換性を早期に特定できなかった最近の例としては、Web コンポーネントのトランザクション伝播要件に関する仕様の解釈に違いがあったという事例があります。この非互換性の問題は、サーブレット仕様の非常に早い段階から存在していました。今後、トランザクションの振る舞いに対する依存関係は移植できない可能性があることをユーザーが認識するように仕様が明確化される予定です (IBM WebSphere® Application Server の振る舞いに影響するかどうかは、まだ明らかになっていません)。

WebSphere Application Server のさまざまなリリース・レベルへマイグレーションする際のベスト・プラクティス、計画、そして問題については、IBM Support Web サイトを参照してください。

技術を素早く採り入れることに関しては、良い面もあれば、悪い面もあります。業界のニーズに迅速に対応するということは良い面ですが、悪い面として、多少の経験を重ねないと識別されないような問題が含んでしまっている可能性があります。IBM では、Java EE プラットフォームへの技術の導入方法を変更するように奨励しています。その方法では、プラットフォームの完成度が高い場合、振る舞いや API に対して互換性のない変更が必要となる可能性があるような新しい技術は次のリリースで採用しないようにし、新技術を成熟させるための (あるいはプラットフォームに採用するのに十分な完成度であることが実証されるための) インキュベーション期間を設けることが強く求められます。そうすれば、ベンダーは将来 (おそらく互換性が損なわれる) 大幅な変更が行われる可能性があるという警告をしつつ、インキュベーション段階の技術を提供するという選択が可能になります。ただし、いったんプラットフォームに採り入れた技術は堅実に、互換性を維持するように進化させることが条件となります。しかし、このような考え方は Java EE プラットフォームの専門家グループのメンバー全員に共通しているわけではありません。Java EE プラットフォームのユーザーとして特定の結果をお望みの場合には、この件に関するあなたの意見をお寄せください。その方法としては、Java EE 仕様のリーダーに連絡するか、またはこの記事の著者に連絡するのでも構いません。

IBM が互換性の重要性を認識するように活動を開始して以来、その認識は高まっています。互換性の問題に真剣に取り組むようになった専門家グループのメンバーが増えるにつれ、仕様では互換性についての意図を一層明確にするようになってきています。それでも、これによって互換性のない変更がなくなると言っているわけではありません。仕様のリーダーと専門家グループが互換性のない変更を決定する前に、その変更に含まれる意味を以前よりも検討するようになってきているというだけです。通常、この検討の状況は文書化されるので、仕様が確定する前に知ることができます。

今のところ、ソースの互換性がバイナリーの互換性と同じく重要であると誰もが納得しているわけではありません。十分考慮して設計された技術であれば、インターフェースは進化してもソース・コードを変更する必要はありません。しかし、そうではない技術の場合、インターフェースを進化させる必要が出てきたら互換性のない変更を行うしかありません。IBM では十分考慮して設計された技術を提供できるように努力していますが、この業界ではすべてに目を配るには助けが必要となります。仕様がドラフト段階を経るのは、業界、つまりユーザー一人ひとりがフィードバックを行えるようにするためです。


ユーザーが取り得る対策

IBM が取り組んでいる対策以外にも、互換性のない変更が行われる可能性を抑えるためにできることはたくさんあります。

  • 仕様プロセスに関与する。進行中の変更を監視する人間が多いことに越したことはありません。プロセスに関与すれば、あなたの意見にも確実に耳が傾けられます。現在、Java EE 6 仕様は改訂作業が進んでいるところで、まもなくドラフトの形で入手可能になります。既存のアプリケーションに影響する可能性のある変更について調べ、それに該当する変更が承認された場合の影響を評価するには絶好のタイミングです。

  • 安定した仕様、または仕様のなかの安定した部分にだけ依存する。例えば、サーブレット仕様の基本部分はリリースされてからすでに長い時間が経過しています (しかも、かなり安定しています)。それに比べると、サーブレット・フィルターには遥かに浅い歴史しかありません。JAX-WS サービスに至っては登場したばかりです。登場してからまもない技術や機能を追加するときには、互換性のない変更が発生する可能性が高いということを覚悟しておくのが妥当です。

  • 業界の傾向を見守る。業界での最新の話題はほとんどの場合、現在進行中の話です。Web サービスと SOA は現在の最新の話題なので、この 2 つをサポートする技術はそのうち変更される可能性があります。この進化の過程で Web サービスと SOA が互換性を維持するかどうかは総じて業界次第ですが、IBM では互換性を保つよう最善を尽くすつもりです。


Java EE 技術の現在と未来

この記事の残りでは、Java EE プラットフォームに含まれる以下の技術とそれぞれに予想される変更について検討していきます。

プレゼンテーション層

  • サーブレット

    現時点で極めて安定した技術となっているサーブレットは完成度が高く、非常によく理解されています。Web 2.0 への対応を別にすれば大きな変更はないはずですが、もちろんまったく変更の可能性がないというわけではありません。

    • Java EE 5 は、メタデータをコンポーネントのソース・コードに組み込めるようにすることで、プラットフォームのユーザビリティー問題のいくつかに対処しました。サーブレット仕様ではこの長所を十分に活用していなかったため、今後変更されることが見込まれます。ただしそのために取られる措置は、振る舞いを変更するのではなく、メタデータのフォームを追加するだけとなるはずです。

    • Java EE 5 でのもう 1 つの主要な変更は、JavaServer™ Faces と JavaServer Pages での式言語の統合ですが、この統合は後方互換性を持つように設計されているため、大きな問題にはならないと思います。

    • メタデータのスコープは、今後変更される可能性があります。サーブレットはメタデータをモジュール・レベルで宣言し、すべての Web コンポーネントで共有する傾向にある一方、EJB はメタデータをコンポーネント・レベルで宣言する傾向にあります。そこで予想できるのが、コンポーネントをスコープとしたメタデータとモジュールをスコープとしたメタデータの両方が可能になることです。既存のスコープの振る舞いは維持されるため、この場合も同じく、非互換性の原因にはならないはずです。

    • もう 1 つ可能性がある変更は、振る舞いを宣言によって定義するのではなく、プログラムによって動的に定義する API を追加するというものです。SOA はこのスタイルを推奨しているようで、プログラムによる振る舞いモデルをまだ採用していない技術でもいつかはこれを採り入れ、すべての技術が宣言型のモデルとプログラムによる振る舞いモデルの両方を採用することになりそうです。ほとんどの部分で、この変更が非互換性をもたらすとは考えられません。唯一の例外は、アプリケーションが実行しなければならないメソッドをインターフェースに追加する場合ですが、業界では明示的なインターフェースを使わないようにしている (代わりにアノテーション付きのメソッドを使用) という現在の傾向を考えれば、この場合も問題にはなることはないでしょう。

  • JSP (JavaServer Pages) および JSTL (Java Standard Tag Library)

    JSP と JSTL も現時点で極めて安定している技術なので、大々的な変更はないはずです。

  • JavaServer Faces (JSF)

    JSF はまだ比較的新しい技術と言えます。JSF は現在、仕様の次のバージョンに向けて大幅な改訂作業が進められているところで、次のバージョンでは JSF 管理 Bean と Enterprise JavaBeans™ が統合されることが予想されます。これらの変更が既存のアプリケーションに影響する可能性は、他のプレゼンテーション技術に比べると高いので、JSF 専門家グループのメンバーである IBM は問題があるかどうか注意深く監視していくつもりです。

    今後懸念となるのは、JSF での Ajax サポートが OpenAjax Alliance の仕様にどれだけ適合するかです。IBM はこのアライアンスへの参加を通して、標準が改訂されていくなかで互換性が損なわれないように取り組んでいきます。JSF での Ajax サポートは (このサポートが実現した時点で) 初めてのことなので、この機能の使用には JSF の他の部分よりも多少高いリスクが伴うことでしょう。詳細は、2009年の初め頃に明らかになります。

  • ポートレット

    Java EE プラットフォームには含まれていませんが、IBM WebSphere Application Server V6.1 とそれ以降のバージョンではポートレットを使用することができます。ポートレット仕様は現在、改訂作業が行われているところですが、IBM はこの仕様のリーダーとしてその進化をコントロールできる立場にあります。

    バージョン 2.0 のポートレット仕様は、バージョン 1.0 で省略された機能 (リソース提供の調整など) を追加する大々的な改訂作業になり、Java Portlet 仕様を完成に向けて導くものとなっています。今後のバージョンでは、Servlet 3.0 や JSF 2.0 など、主に他の Java EE 仕様の変更に合わせた変更が行われる可能性がありますが、これらの変更によってポートレット側に主要な新しい機能が組み込まれることはないはずです。

    この記事を執筆している時点では、Java Portlet 仕様のバージョン 2.0 にはバージョン 1.0 とのソースおよびバイナリー互換性があるようで、バージョン 1.0 であいまいだった振る舞いの仕様がバージョン 2.0 では明確にされており、その振る舞いを制御するためのスイッチが追加される予定となっています。この互換性表明は、仕様が最終決定に至って十分なテストが行われた時点で実証されることになります。

ビジネス・ロジック

  • EJB (Enterprise JavaBeans)

    EJB 仕様は新しい機能を次々と追加してきましたが、それは上位互換性を持つような形で行われてきました。そこで、EJB 3.0 仕様は EJB プログラミング・モデル構文を一変させています。ただし、古い 2.1 以前のプログラミング・モデルも引き続き使用できるだけでなく、3.0 のプログラミング・モデルには後方互換性のサポートが含まれているため、クライアントおよびサーバー・コンポーネントを異なるバージョンの仕様で実装することが可能になっています。

    • 現時点でセッション Bean は十分に安定しているため大幅な変更はないはずですが、新しい関数が追加される可能性はあります。

    • メッセージ駆動型 Bean も十分安定しています。

    • CMP/BMP による永続性は安定してはいるものの、リレーショナル永続化技術として JPA (Java Persistence API) を使用すること、または非リレーショナル永続化技術に JCA (Java EE Connector Architecture) を使用することを優先して非推奨となる可能性があります。

    • 仕様の次のバージョンで考えられる変更は、セッション Bean とメッセージ駆動型 Bean を 1 つにまとめ、同期対話スタイルと非同期対話スタイルの両方を持つ単一のコンポーネント・スタイルにすることです。前回の仕様改訂から考えて、次のバージョンでも堅実で、互換性のある進化が期待できます。

永続化

  • JDBC

    現時点で極めて安定した状態の JDBC は、パフォーマンスおよび互換性への長期投資となります。ただし、そのための前提はデータベース・ベンダーを変えないことです。データベース・ベンダーを変えると、SQL 文の変更や、使用しているロックおよび分離レベルの変更が必要になってくる場合があります。

  • JPA (Java Persistence API)

    JPA は、Java プラットフォームで EJB CMP Object/Relational Mapping サポートの後継となることが予定されている技術です。これは新しい技術なので、今後の進化が見込まれます。その一方、この技術は複数のベンダー実装経験 (Hibernate、TopLink、および Kodo) に基づいているため、変更によって非互換性がもたらされるリスクは多少なりとも軽減されています。JPA は、JDBC ベンダーの違いによる影響をある程度吸収してくれます。

統合

  • JMS (Java Message Service)

    長い間ほとんど変更されていない JMS は、安定した技術であると考えられます。

  • Java EE Connector Architecture

    Java EE Connector Architecture は今まで安定していましたが、ある問題を抱えているため、次のバージョンではそれについての対処が行われることになるでしょう。その問題とは、現行のアーキテクチャーではフェールオーバーやインバウンドおよびアウトバウンドの整合性に関する処理を行わないという問題です。そのため、ベンダーは拡張機能に頼ってこの問題に対処しなければなりませんでした。この問題やその他の問題に対処するための仕様の変更は互換性が保てるように計画されていますが、それでもカスタマイズして作成されたリソース・アダプターには結果的に影響せざるを得ません。他のベンダーから購入し、保守を受けているアダプターでは、こうした変更による影響 (1 つでもある場合) がないようにする必要があります。

  • JavaMail および JAF (JavaBeans Activation Framework)

    JavaMail の進化は、ひっそりとしたものでした。それはおそらく、例えばサーブレットや EJB に比べ、JavaMail を使用する開発者の割合が低いためでしょう。このアーキテクチャーは進化によって影響を受ける可能性のある実装クラスが多いことから、進化するのも、ソース互換性を保つのもより困難です。しかし一般に、このアーキテクチャーの大部分は現時点で安定しており、現在予想される変更はありません。JAF は MIME タイプの処理に使用されるため、概して JavaMail と同じように安定していると考えられます。

  • JAX-RPC (Java API for XML-based RPC)

    Java EE 6 では JAX-RPC の使用が推奨されなくなる可能性があるため、新しい開発では以下の仕様に従うかどうかを考慮する必要があります。

    • JAX-RPC: 安定した技術ですが、すべてのケースに有効なわけではないため、いずれは使用されなくなっていくはずです。
    • JAX-WS: 新しい技術であるため変更される可能性はありますが、業界の現在の動向を反映しています。
  • JAX-WS (Java API for XML Web Services)

    第 2 世代の Web サービス API である JAX-WS は、JAX-RPC に比べ、戦略面で優位に立っています。JAX-WS は、仕様の進化の妨げとなる後方互換性の問題を回避するための新しい技術として定義されました。しかし W3C 標準委員会の決定が原因の、JAX-WS の進化にまつわる問題がすでにいくつか存在していたため、仕様に含まれる一部の要件を削除するという改訂が行われました。さらに進化する可能性があるのは Web サービスの領域です。現在、(JAX-RS - JSR 311 による) RESTful なサービスへの重点的な取り組みに加え、Web サービスに関するサービス品質 (信頼性の高いメッセージングまたはトランザクションなど) の標準化が望まれています。すべてはまだ比較的新しいので、業界がこれらの領域でさらに経験を積んだ時点で、再編成が行われる可能性があります。

    完成度の点からは、JAX-WS では JAX-RPC の経験が大いに役立っています。JAX-RPC から学んだ教訓が JAX-WS に生かされていることから、この仕様は極めて有効かつ完成度の高いものとなっています。Java SE 6 (JDK/JRE) には JAX-WS と JAXB の両方が組み込まれているため、この 2 つの仕様はさらに安定化することになるでしょう。

  • JAXB (Java Architecture for XML Binding)

    第 2 世代の Web サービス API である JAX-WS は、JAX-RPC に比べ、戦略面で優位に立っています。JAX-WS は、仕様の進化の妨げとなる後方互換性の問題を回避するための新しい技術として定義されました。しかし W3C 標準委員会の決定が原因の、JAX-WS の進化にまつわる問題がすでにいくつか存在していたため、仕様に含まれる一部の要件を削除するという改訂が行われました。さらに進化する可能性があるのは Web サービスの領域です。現在、(JAX-RS - JSR 311 による) RESTful なサービスへの重点的な取り組みに加え、Web サービスに関するサービス品質 (信頼性の高いメッセージングまたはトランザクションなど) の標準化が望まれています。すべてはまだ比較的新しいので、業界がこれらの領域でさらに経験を積んだ時点で、再編成が行われる可能性があります。

  • SAAJ (SOAP with Attachments API for Java)

    SAAJ は、Web サービス・メッセージを対象とした極めて安定したレンダリング・フォームです。標準化された DOM API を利用するための拡張を別とすれば、初期リリースからの変更はほとんどありません。

  • JAXR (Java API for XML Registries)

    JAXR もまた、Java EE プラットフォームへの導入を急ぎすぎた技術のひとつです。JAXR は UDDI V2 および ebXML V2 の抽象化を提供することを前提としていたため、これらの標準の V3 バージョンが JAXR とほぼ同時に作成されると、JAXR は早々に使われなくなりました。業界はこの分野では依然として発展を続けているので、JAXR を今後進化させたとしてもその完成時には時代遅れになってしまうでしょう。業界が多少落ち着いてきたときに、JAXR は劇的に進化するか、あるいは別の技術に置き換えられるかのどちらかになる可能性があります。

その他の技術

  • Java EE Management

    Java EE Management はこれまで極めて安定しており、これからも安定状態は続くと期待されています。

  • Java EE Deployment

    この技術は使用しないようにしてください。そのタスクには役不足であるため、将来的にはなくなるか、あるいは大幅な改訂作業により置き換えられる可能性があるからです。

  • JAAS (Java Authentication and Authorization Service)

    JAAS は Java EE プラットフォームのセキュリティー・サービスの中核となります。この技術は概して安定していますが、JAAS サブジェクト伝播に関しては、ベンダー間で振る舞いが異なることがわかっています。今後の Java EE プラットフォーム仕様では、業界での一貫性を実現するために違いを明確にするための取り組みが行われることになるでしょう。

  • JACC (Java Authorization Contract for Containers)

    Java EE 5 での変更で、アノテーションによるメタデータ宣言が可能になったことにより、アノテーション付きセキュリティー宣言を処理できるように JACC を変更する必要が出てきました。JACC 1.0 プロバイダーがセキュリティー・アノテーションを使って適切なセキュリティーの振る舞いを提供できるとは思えませんが、アノテーション付きセキュリティー宣言を使用しない既存のアプリケーションは引き続き正常に動作するはずです。

次世代の技術

未来が確実でないことは当然ですが、Java EE プラットフォームにこれからも影響を与え続ける技術については予測がつきます。以下に挙げる技術は大幅に進化する可能性があるため、互換性の視点から慎重に考えて取り組まなければなりません。

  • JAX-RS - RESTful なサービス

    業界では、疎結合サービスに正式な Web サービスを使用するのが常に有効であるとは限らないと認めています。しかし疎結合サービスは業界でも初めてのことなので、この新しい話題に関係して蓄積された経験は限られています。ベスト・プラクティスのパターンが明らかになってくれば、仕様が大幅に変更されるかどうかを簡単に予測することができるはずです。

  • WebBeans

    Java EE 6 の内容に WebBeans という新しい技術を追加するという案があります。これは当初、JSF 管理 Bean と EJB を統合する方法として提案された技術ですが、その後の進化により、他の数多くのコンポーネント・モデルも包含するように意図された独特のコンポーネント・モデルになりました。この分野での実績はほとんどありません (WebBeans は JBoss Seam をベースにモデル化されるはずでしたが、それより遥かに範囲の広いモデルになったからです)。最も参考になるのは、最初の SCA 仕様を生み出す結果となった数年に渡る検討です。SCA も同じく、その他多くのコンポーネント・モデルを包含するコンポーネント・モデルとして機能する仕様です。近い将来、WebBeans のスコープが大幅に縮小されない限り、その仕様は大きく進化することになるでしょう。

  • Timer および Workmanager

    この 2 つの仕様は、エンタープライズ・サービス品質を非同期 (つまり、スレッド化) プログラミング・スタイルに推進するものです。IBM と BEA (CommonJ) による共同作業から生まれたエンタープライズ・サービス品質と非同期プログラミング・スタイルは、複数のベンダーがこうした技術を提供することによるリスクをいくらか軽減しましたが、これらの仕様は API のベースを、スレッド化作業管理用 Java Concurrency Utilities に変更しています。これを業界が受け入れるのか、あるいは追加の変更を必要とするのかはまだ明らかになっていませんが、これらの仕様を用いる上でのリスクは WebBeans より小さいはずです。既存の Asyncronous Beans API を WebSphere Application Server 内で使用することで、非常に長い期間、少なくともこの先、2 つの仕様が安定するまでの間は安定性と互換性を維持できると思います。


まとめ

特定の技術や Java EE プラットフォームの機能を使用するかどうかを決定するために未来を予言することは誰にもできません。業界は絶えず進化し、その進化によってプラットフォームは左右されるからです。しかし、どの技術を使用するのが適切かを判断する際に、情報に基づいた選択を行うことはできます。情報に基づいた選択を行う上で、この記事が十分な情報を提供できたことを願います。


謝辞

Dana Duffield、Greg Truty、Kevin Sutter、Maxim Moldenhauer、Piotr Przybylski、Randy Schnier、Stefan Hepper、Stephen Kenna の各氏の協力に感謝の意を述べます。

参考文献

学ぶために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere, Java technology
ArticleID=314769
ArticleTitle=Java EE 技術を使用するための長期的戦略を立てる
publish-date=05142008