かなり長い開発サイクルを経て、JBoss AS 5 (リンク) RC1のリリースが行われた。InfoQは、プロジェクトリードであるDimitoris Andreadisにインタビューし、その新機能とリリースのタイムラインについて尋ねた。またDimitrisは、Java EE 6の機能やJBoss ASが競合に対して優位な点、OSGiだけに固執するのではなく、プラガブルなコンポーネントモデルを選んだ事についてもコメントしてくれた。
InfoQ:このリリースにおける主要な機能や、以前のバージョンに対して追加された部分を簡単に挙げてもらえないか？また、新しいAPIについても簡単に説明してもらえないだろうか？
JBoss AS5では、全ての主要なJBossサブシステムを次のレベルに引き上げる事により、新機能が目に見えて多数追加されている。
古いJBoss MQを置き換えるJBoss Messaging 1.4が、現在ではデフォルトのJMSプロバイダだ。JBMは透過的なフェイルオーバーと、インテリジェントなメッセージ再配信とともに、クラスタ化されたキューとトピックをサポートしている。メッセージはディスクのI/Oを発生させる事なく、ノードをまたいでメモリ内でレプリケートされるか、非常に巨大なメッセージをサポートするためのページング技術を用いて、ポピュラーなリレーショナルデータベースに永続化される。JBMは目覚ましいパフォーマンスを発揮しているし、書き込みに使用される追記オンリーのジャーナリングストレージのおかげで、物事はどんどん良い方向に向かっている。
JAX- WS/JAX-RPCをフルにサポートしたJBoss WebServices 3.0は、XOPとSwA、そしてWS-*標準の実行環境を搭載している。JBWSはプラガブルなアーキテクチャに移行し、その基盤となるWebサービススタックの置き換えを可能にした。そのため、ネイティブのJBossWSをSunのMetroやApacheのCXFに取り替える事が可能だ。従って、あなたは今抱えている問題に最も適したWebサービススタックを使う事が出来るはずだ。
AS5におけるクラスタリングは、ステートフルセッションビーンに対するバディレプリケーションがサポートされた事で、スケーラビリティが改善され、クラスタ化されたWebセッションのメモリ使用量をコントロールするためのパッシベーション（非活性化）も改善された。 EJB3 エンティティとHibernateのキャッシュは非常に改善された。その理由は、エンティティ（インバリデーション・キャッシュ）とクエリ（レプリケーション・キャッシュ）で別々のキャッシュを用いる事が出来るからだ。それを下でささえるJGroupsのプロトコルスタックにも、パフォーマンスの改善が行われている。
JBoss Transactionは、JBoss 5向けのデフォルトのトランザクションマネージャだ。JBoss TSはすでにAS 4.2シリーズとJBoss Webの組み合わせでテストされている。JBoss WebはJBoss 5におけるサーブレットコンテナで、Apache Tomcatをベースとして実装されている。ベースとなったTomcatは、Apache Httpサーバ以上のスケーラビリティとパフォーマンス特性を達成するため、ネイティブのAPRベースコネクタをサポートしている。
API の点から考えると、AS5はJava EE 5の実装だ。そのため、関連する全てのAPI実装がなされていると期待できる。EJB3、JAX-WS、JPAなどの、Java EE 5で"新しく"導入されたAPIのほとんどは、JBoss AS 4.2シリーズで既に実装が存在している。しかしJBoss AS5では、TCK（テクノロジ互換性キット）テストのカバレッジが増加した事により、適合性要件をより完全に満たす事になった。
InfoQ：JBoss Application Serverのバージョン5が、かなり長い開発サイクルを経たと言う事実は何度か批判されてきた。少なくとも、他のコンテナと比較しても長い期間だった。これはなぜだったのか？4.2のリリースが、この遅れに関する全ての原因なのか？
確かにJBoss AS 4.2と、Enterprise Application Platform (EAP 4.2) の最初のバージョンは、AS 5に対して多大な影響をもたらした。私たちのリソースは少なく、そしてFedora/RHELモデルに従って製品を作る努力は、私たち（元JBoss社員:JBossians）にとってひと味違うものだった。一方4.2は、さまざまなJBossテクノロジー（例えばJBoss Transactions）のための足がかり兼テスト環境であり、AS5がリリースされる前に準備が整っていた。そのため、こうした様々なテクノロジーをコミュニティに対して素早く提供できたのは良い事だ。
一方AS5の全体像を見ると、あくまで私の意見だが、この努力が3年前に開始されたときには誰も想像できなかったものであると思う。新しいカーネルを完全に一から作り、MBeanからPOJOに移行し、AOPをより低レベルで統合し、サブシステムをまたいでメタデータ処理を統合し、クラスローディングシステムを変更し、デプロイヤをAOP化した。他の言葉で言いかえると、既存のサービスの大多数を、後方互換性を保ちながら内部のアーキテクチャを変更し、アプリケーションサーバの中身を置き換えたのだ。それは一歩進めるたびに大きな困難を伴う、非常に大変な作業だった。
他にも、様々な内部のサブシステムに対する適切なSPIを作り出すと言う問題もあった。これは長期的に見ると良い事だ。なぜなら凄まじいプラガビリティを実現しただけではなく、異なる実行環境においてもJBossプロジェクトをア・ラ・カルト的に利用する事を可能にするからだ（例えば、スタンドアローンの EJB3コンテナや、他のアプリケーションサーバへの組み込みなど）。しかし、非常に小さなプロジェクトを何ダースも保守しなければならない事から、大きなオーバーヘッドが生じた。さらに、これほど大きなコードベースをmaven2に移行すると言う事を想像してみてほしい。
もちろんJBossを使いたがっているエンドユーザと開発者にとって、これらは内部的な実装の詳細にすぎない。Java EE 5を完全保証するJBossのリリースが遅れた事は、彼らに迷惑をかけてしまった。そうしたユーザに対して私は素直に謝罪し、彼らの忍耐に感謝する。 AS5がもうすぐリリースでき、あらゆる初期の問題を解決できたと言う幸運もあり、結果として報いられる事だろう。
JBoss AS5は単なるJava EE 5アプリケーションサーバではない。それはJBossプロジェクトの次世代に向けた、最新鋭のサーバ実行環境として、ビジョンを指し示すものだ。
InfoQ: 2月にリリースされた最後のβ版を踏まえて、RC1のリリースに関して話したい事があるか？最終バージョンがリリースされるのはいつだと考えているか？
CR1（リリース候補）は本当にすぐ、6月の終わりにリリースされるだろう（ほとんどできあがっている）。8月の頭にリリースされるCR2がそれに続くだろう。こうしたCRリリースから受け取るコミュニティからの反応次第で、私たちは最終バージョンのリリース日を決定する。
JBoss AS5のリリースは、現在私たちの中で最高の優先度が与えられている。
InfoQ: 現在議論されているJava EE 6の機能、特にプロファイルについてのJBossの見解はどうか？
Java EE 6におけるプロファイルの提案には、個人的にはいろんな感情が交じり合っている。Java EE仕様の主な目的は、開発者に対してEEテクノロジーの包括的なツールセットを提供する事だ。それだからこそ、規格に準拠した実行環境間でアプリケーションを移植しやすかったのだ。テクノロジーを非常に小さなサブセット（例えばプロファイルA）に減らすことで、仕様に非準拠な拡張を追加するよう開発者に強制することになり、EEアプリケーションの移植性が損なわれてしまう。
コンフィグレーションを簡素化できる事で、あなたが使わないテクノロジーによるランタイムのオーバーヘッドを避ける事が出来ると言うが、これは全く異なる事柄だ。JBossASはリリースされた初期の頃から三つの事前定義プロファイル（minimal、default、all、その他にもjemsインストーラを使っているのなら他にもいくつか）があり、あなたには常に、サーバのコンフィグレーションを実際に使用するものだけに絞り込む自由が与えられていた。 JMSが必要ないなら、特定のサブシステムを取り除くだけだ。しかしこれは、プラットフォームプロバイダにとっての単なる実装の詳細だ。
より広範なJava EEテクノロジーにとって重要なのは、包括的で、汎用的に使い易く、最新である事だ。EJB3、JPA、JAX-WSの採用は、プラットフォームを大きく後押しした。古い仕様を削除するプロセスも、正しい方向へのステップだ。Java EEの仕様には、ほとんど使われないもの（例: CSIv2）やもはや廃れたもの（例: CMP）が存在し、それらはプラットフォームから撤退すべきだ。しかし、基本的なプロファイルがJSPとJSFのどちらを提供すべきか、を議論するのは単にばからしい事だ; どちらのテクノロジーにも良い用途が存在する。
私は、TomcatにEE準拠のお墨付きがされる（プロファイルA）と言うのは本当に意味がない事だと思う。Tomcatに対して２、３の拡張機能を施し、それをJava EEだと宣伝するのを許すのであれば話は別だが。もしくは、Tomcatのコンフィグレーションをさらに増強する（プロファイルB）が、Webサービスを行う事はできないとか。つまりプロファイルはJava EEコミュニティにとって、どちらかと言うと害になるものだと私は信じている。
InfoQ: 最近SpringSourceは、Springアプリケーションを実行するよう設計されたモジュールベースのJavaアプリケーションサーバ、Spring Application Platformをリリースした。Springが行ったように、JBossテクノロジー（Hibernate、Seam、Messagingなど）を使ったスタンドアローンのアプリケーションサーバを作る予定はあるか？
あなたが知っているように、JBoss ASのコンフィグレーションは、本当に必要とするサービスのセットだけにする事が出来る; これはJBossでは常に可能だった。事前定義されたWebコンフィグレーションを持つ事は、現在のところ技術的な決断よりも、マーケティング上の決断が好まれているように見える。新しい機能を追加するよりも、能力や機能を除去する方が簡単だ。当分の間、私たちはJBoss EAPの上にJBoss ESB、JBoss jBPM、JBoss Rulesを加えた、JBoss Enterprise SOA Platformを構築し、より高い目標を達成する事にフォーカスしてきた。しかし真に市場が望むなら、もしくはJava EE 6のプロファイルが進められたなら、私たちは恐らくWeb Platformバンドルを作成し、サポートするだろう。
InfoQ: OSGiをサーバサイドのアプリケーションに使用する事が、今日では一般的になりつつある。実際、GlassFishとSpring Application Platformがそれを選択した。JBoss 5は、その代わりにプラガブルなコンポーネントモデルを許容するアーキテクチャをとることで、古いコードベースとの互換性と、よりよいコンポーネントモデルを将来的に採用することの、どちらも許容している。これをあなたは、競合に対する戦略的な利点になると考えているのか？
もちろんだ。
思い返してみると、JBossは2001年に始まり、動的なマイクロカーネルアーキテクチャの上に構築された最初のJavaアプリケーションサーバだった。 JMX MBeanServerがカーネルのコアとして採用され、MBeanはカーネルにサービスをプラグインするためのコンポーネントモデルとなった。これはその当時では素晴らしい選択だったが、その後POJOとAOPが有力なプログラミングモデルになり、JMXコアの限界が見えてくるようになった。最初のリファクタリングが開始されたのはJBoss 3だ。私たちは自身のJMXカーネル（JBossMX）を置き換え、XMBeansを通じてPOJOとインターセプタのサポートを提供するようになった。しかしすぐに、私たちが完全に制御できる、真のPOJOカーネルに向かうべきだと言う道がはっきりとしてきた。
JBoss 5での3年間の研究開発を経て、カーネルやコンポーネントモデルを切り替えるのは、非常に痛みを伴うプロセスだと言う事を私たちは学んできた: これは単に、サーバは内部的にはいかなる特定のコンポーネントモデルとも結びついてはいけないと言う事だ。何らかの理由でOSGiが時代遅れになったとき、もしくはよりクールなコンポーネントモデルが実現されたとき、私たちの競合は同じ痛みを受ける事だろう。ある意味で、彼らは7年前のJBossに似ている。
しかしJBossは、JBoss Microcontainer上に新しいファサードを構築するだけで、新しいコンポーネントモデルをサポートする事が出来る。同じ方法で、私たちはネイティブなPOJO、レガシーなMBeans、そしてもうじきOSGiバンドルをサポートするし、その他の既存のコンポーネントモデルや、将来登場するものも合わせて、興味のあるものをサポートしていくだろう。抽象化のパワーこそがベストなのだ！
InfoQ: プラガブルなコンポーネントモデルについてですが、コンポーネントモデル間で情報を共有したり、それらを協調させたりする事は、開発者にとって可能なのか？
イエス、それこそが美しい部分だ。JBoss内の全てのコンポーネントは、その種類（POJO、MBean、Spring Bean、OSGiバンドルなど）に関わりなく同じ世界を共有し、依存関係に応じてMicroContainerが相互にワイアリングしたり、異なるコンポーネントモデルをまたいでアスペクトを適用したりする事が出来る。私たちはまだ、Adrian Brockによって設計されたMicroContainerテクノロジーの能力や限界を理解する最初の段階にある。しかしその可能性は、明らかに興味深いもののように見える。
InfoQ: InfoQの読者に対して、JBoss ASの将来的な方向性に関して何かコメントはあるか？バージョン5のあとには何が来るのだろうか？
そうだね、現段階における私たちの主なフォーカスはAS5をリリースする事だ。将来に関して、あまりに多くの予言めいた事をしたくはない。私が知っている事は、AS5は健全な基盤と完全な拡張性、クロスコンポーネントモデル、アスペクトが統合された実行環境を提供するだけではなく、イノベーションがより早いペースで発生するだろう、と言う事だ。これにより、AS5を作るのにかかった時間に比べて、より早くAS6がリリースされる事を私は期待している！
確かに、OSGiをサポートしたり、管理機能を向上させたり、と言ったより注意を注ぐべき分野が存在する。特に、数多くのデプロイメントが行われている場面では顕著だ。様々なJBossプロジェクトを通じて、たくさんのイノベーションがパイプラインに待ち行列を作っている; そしてJavaがオープンになる事により、JVM自身の改善や、アプリケーションサーバとのより密な統合が起こるのではないか - 特にLinuxサイドで - と期待している。
JBoss ASや、関連するプロダクトに関するより多くの情報を得たければ、こちらのリンクを参照してほしい: http://www.infoq.com/jp/jboss