Java EEを脱したSpringSourceの新アプリケーションサーバ

ベンチャーキャピタルから1000万ドルの資金調達(source)をしてから1年経って、今SpringSource（Springフレームワークの開発を行っている企業）はアプリケーションサーバのベンダにのしあがった。既存のJava EEサーバの巨頭にSpringとOSGiとApache TomcatをベースにしたアプリケーションサーバであるSpringSource Application Platform(サイト・英語)（編者注：SpringSourceのRob Harropは技術的により詳細な記事 (source)をブログに載せている）で立ち向かおうとしているのだ。この新しいアプリサーバはJava EE標準を離れ、Springのプログラミングモデルをネイティブに備え、またOSGiコアを中心にした新しいデプロイとパッケージングのシステムも備えている。今日リリースされたベータバージョン(source)はSpringSource Evaluationライセンスとなっているが、GA（General Availability：一般利用可能）バージョンはオープンソース（GPLv3ライセンス）でリリースされ、サブスクリプション（有償サービス）バージョンは1ヶ月以内にリリースされることになっている。

SpringSource Application PlatformはJava EEアプリケーションサーバではない。WARデプロイはサポートされるがEARデプロイはサポートされず、他にもEJBのようなJava EE仕様がサポートされない。SpringSource Applicaton Platformは世間で広く用いられているオープンソースプロジェクトのSpring Portfolio（Spring製品群）を直接的にサポートするようゼロから設計が始められた。より詳しく言えば、このアプリケーションサーバは OSGiベースのデプロイに対応したSpring Dynamic Modulesを活用したSpring Portfolioのプログラミングモデルを基に構築されている。SpringSourceはロギングやトレース、ブート、クラスロード、管理のための” カーネル”を作り、Eclipse FoundationのEquinox OSGi実行環境上にその他の機能を乗せている。Tomcatはウェブ機能のためのOSGiバンドル（OSGiの部品単位）として取り込まれている。

InfoQ はSpringフレームワークの共同創作者でSpringSourceのCEOであるRod Johnsonとこの新しいアプリケーションサーバについて話をした。この新しいプラットフォームに対する需要を説明する中で、現在の開発/製造現場で苦痛を生んでいる多くの問題点（たとえば複数の設定ファイルに同じメタデータを書いたり）を指摘した。あるデプロイ先の上でいろいろなツールやフレームワークを使って自分たちのアプリケーションをデプロイする、要するにサーバを別のサーバの上にデプロイするのはプロジェクトではよくあることだ。しかし実際に使っているのはアプリサーバのウェブコンテナの部分だけだったりする。そういうことがあったため、今日の開発の要求に対応したよりシンプルなプラットフォームを提供することをSpringSourceは考えた。

新しいアプリケーションサーバの利点について、Johnson氏はモジュール性を強調した。これにはサーバ自体のモジュール性と、開発者が実際使うパッケージングや開発モデルのモジュール性の両方がある。OSGiとOSGiバンドル間の依存性の特性を利用したことで、アプリケーションサーバは現在動いているアプリケーションに必要な機能だけをアクティブにすればよく、サーバの利用するリソース量とスタートアップ時間も削減できる。OSGiの依存性では、異なるアプリケーションが依存する異なるバージョンのライブラリが共存することも可能になっている。またシステム全体を再起動することなくアプリケーションサーバのパーツを更新したり再起動させることもできる。開発の視点から言えば、サーバのモジュール性のおかげで、適度な粒度で再デプロイするようにすればコード変更をすぐに反映させることができる。

OSGi とSpringSourceでのEclipse Equinox OSGiの利用について聞くと、Johnson氏はOSGi仕様とランタイム実装によって提供される基盤を賞賛する一方、OSGiは日々のアプリケーション開発に利用するには少しばかり低レベルだろうと指摘もした。SpringSourceは企業レベルの開発現場でOSGiの恩恵を容易に得られるようにしたいと考えている、とJohnson氏は説明した。この新しいアプリケーションサーバではOSGiが持つ多くの複雑性を新しいプログラミングモデルの構造によってカバーしている。さらに彼は続けて、新しいアプリケーションサーバではPARデプロイユニットをサポートし、これによりエンタープライズアプリケーションでのOSGiの利用が容易になると述べた（このことについては後で触れる）。

OSGi では本来サポートされない既存ライブラリのサポートについて尋ねられたJohnson氏は、多大な作業が行われたことでアプリケーションサーバ環境やクラスローディングがレガシーライブラリも扱えるはずだと答えた。今後SpringSourceはTomcatなどのプロジェクトに対してライブラリを OSGiバンドルに対応させるために必要なパッチをフィードバックしていくそうだ。

Johnson氏はアプリケーションサーバのコードの大部分はGPLv3のライセンスでリリースされるだろうと説明した。サーバに関することであれプログラミングモデルやデプロイユニットに関することであれ開発者によって寄与される全てのことはオープンソース方式で行うことが可能になるだろう。同時に SpringSourceはこのアプリケーションサーバの商用バージョンも提供する予定で、それにはサポートや保障、運用管理、リソース監視が含まれることになる。

Java EEについて、またSpring Application Platformの発表によりJava EEサポートを続けるSpring Portfolio製品群にどれだけ影響があるかについて、Johnson氏はこう答えた。 

･･･私たちがしようとしていることは基本的にSpringユーザコミュニティを特定の方向へ向かわせようというものではありません。私たちは単にユーザに新たな選択肢を与えようとしているのです。ユーザはいつも正しいというのがSpringのフィロソフィです。ユーザは自分たちが何を望んでいるか十分に知っているのです。この選択肢を選ぶ選ばないにかかわらず、ユーザはこのオプションを得られることを歓迎してくれるだろうと考えています･･･

SpringSourceではSpring Portfolioや他のSpringSource製品が他のアプリケーションプラットフォームと互換性が保たれるように最大限の努力している、と Johnson氏は明言した。そして来たるJava EE 6仕様については次のようにコメントした。:

Java EE 6はモジュール性についてのものであり、（Java EEを）正しい方向に導くものです。SpringSource ApplicationサーバがJava EE 6 Compliant（準拠）となるのは十分ありえることです。Java EE 6 CompliantにはA、B、Cの3つのプロファイルがあるのですが、私からはっきり言えば、私たちはCの要素であるEntity Beans 1.1やいくつかのレガシーテクノロジを実装することはないと思います。私たちが実装するのはAとBのプロファイルになる可能性がかなり高いと思いますが、仕様はまだ決定されてないので100%そうなるとは言い切れません。

最後にInfoQとJohnson氏はSpringSource Application Platformの全体像について話をした。OSGiへの移行について彼はこう述べた。 

旧来のアプリケーションサーバは時代遅れになりつつあります。BEAとIBMは自分たちのアプリケーションサーバでOSGiを使うように作り直そうとしています。SpringSourceはちょうどOSGiをサポートしたものを提供しようとしているところです。全てが統合されたプラットフォームを使っているケースあるいは開発者はほとんどありません。そんなプラットフォームではなくTomcatをデプロイ先として使っているのです。そしてそういった人たちは Java EEというよりはSpringのプログラミングモデルによってコードを書いています。マーケットは既にOSGiを選択しています。問題は、あとどれだけ開発者が今のサーバと格闘しないといけないかです。

Johnson氏は3つの理由によりSpringSource Application Platformが成功することを確信していると語った。 

• これは最新のテクノロジをベースとする最初の製品です。Java EEへの準拠はもはや最重要事項ではありません。私たちにはクリーンで新しいコードの土台があり、そのことで競争上の優位性を得ました。私たちが設計し世に送り出すのは、過去10年の間要求されたことに対してではなく今日の要求を満たすためのものです。 
• JavaがあるべきはPOJOプログラミングです。これまでのPOJOプログラミングは他の製品に苦し紛れに接ぎ木されたものでしたが、私たちが作ってきたものではPOJOプログラミングが設計上の前提となっています。
• SpringSource Application Platformで使われているOSGiテクノロジは最も基本的な次世代テクノロジです。

Rod Johnson氏に引き続いて、InfoQはSpringSourceのRob Harrop氏に新しいサーバの技術的な詳細を聞いた。従来のJava EEアプリケーションサーバと比べ、なくなっているもの・加わっているものについて彼はこう述べた。 

･･･ JPA（Java Persistence API）とJMS（Java Message Service）は両方ともサポートされますが、特別な実装をおこなうつもりはありません。JPAについてはHibernateとOpenJPAと Toplinkをサポートします。またアプリケーション間の住み分けを担うOSGi環境にはload-time weavingのサポートを加えていて、共有ライブラリを誤って変更してしまわないようにしています。JNDIはサポートされずOSGi Service Registryが使われます。サーブレットは組み込まれているTomcat経由でサポートします。Java EEにあってSpringSource Application PlatformにないものにはEntity Beansなどがあります。

次にSpring Dynamic Modulesについて聞いた。Spring Dynamic Modulesはかなりの長きに渡ってパブリックプロジェクトとして進められている。Harrop氏はモジュールのデプロイに関してSpring Dynamic Modulesに何か加えられたことはないか聞かれこう答えた。 

このプラットフォームには複数のアプリケーションのアイディアが取り込まれていて、それらは1つあるいは複数のバンドルによって成り立っています。アプリケーションに含まれるバンドルは互いに衝突がないようにはっきりと設定されています。サービスが互い矛盾するようでは困るので、このことはサービスを OSGi Service Registryに登録しているアプリケーションにとって特に重要なことです。

またImport-Libraryを取り入れたことでサードパーティ製のライブラリをアプリケーションで利用するのをかなり簡単にすることができました。直感的に分かりづらいとこもあるImport-Packageのコードをたくさん書かなくても、Import-Libraryを使えば目的のライブラリに必要なパッケージを全て持ってくることができます。Hibernate JPAのようなライブラリは複数のバンドルにより成り立つので、Import-Libraryを使うと使わないのではかなりの違いがあります。

このプラットフォームで実行できるようにSpring Dynamic Modulesを拡張するには、ほんの少しコードを追加するだけで大丈夫です。

バンドル化されたSpring Dynamic Modulesは通常のOSGiバンドルと同様にMETA-INF/spring/*.xmlファイルを含みます。これらのファイルはバンドルが起動された時点でApplicationContextに登録されます。Spring Dynamic ModulesはSpring NamespaceHandlerによって異なるバンドルでサービスをインポートしたりエクスポートしたりできるような仕組みを提供します。

PAR（Platform ARchive）は基本的にOSGiバンドルの集まりで、そのうちのいくつかはSpring Dynamic Modulesのために含まれています。これらのバンドルを束ねることでアプリケーションが構成されます。PARがプログラミング方法を変えることはなく、OSGiやSpringやSpring Dynamic Modulesの方法でプログラミングすれば大丈夫です。

旧来のライブラリでOSGiに準拠しないものにどのように対処すればいいかを話す中で、BuddyのClassloaderのようなこれまで用いられてきたテクニックについて尋ねると、氏はこう答えた。 

使わないようにするというのが良いやり方でしょう。Buddyのクラスローディングの方法である動的インポートやRequrire-Bundleはクラス空間に矛盾がないよう保つのが困難なことから、すでに忌避されています。そして私たちはそれに変わる独自メカニズムを提供するつもりもありません。 

そのかわり、私たちは通常のケースにおいてリソースの読み込みを効率良く行えるように、Eqinoxにいくつかの低レベルでの機能を追加しました。具体的にはload-time weavingが行われるようクラスローディングを拡張し、読み込みのセマンティック（どのようなクラスローダの下でロードしているのかが分かるようにする）がいらないようにし、サードパーティ製のバンドルが目的のクラスを見つけられるようにContext Class Loaderをコントロールしています。この部分の核となるのがPARで、Context Class Loaderやload-time weavingで見えるスコープを定義します。

最悪の場合では、OSGiで動くように変更を加えたバージョンのライブラリを作ったりもしました。私たちが作ったライブラリはSpringSource Enterprise Bundle Repositoryで手に入れることができますし、元のプロジェクトにも全てのパッチを送っています。

ここ２年ほどJava EE標準はもう終わっているものなのかという議論が多く見られるが、今我々はJava EEをサポートしないでも次のメジャーとなりうるアプリサーバが世に出てきたのを目の当たりにしている。我々の自由が広げるこの変化について読者はどう思われるだろうか。

 原文はこちらです：     http://www.infoq.com/news/2008/04/springsource-app-platform