SpringSource ApplicationFrameworkのライセンス、OSGi、技術的な側面に対する反応

作者 Scott Delap , 翻訳者 白石 俊平 投稿日 2008年5月23日

セクション

運用/インフラ,

デベロップメント

トピック

Java ,

アプリケーションサーバ

タグ

Spring

先日InfoQが報じた(関連記事) ように、SpringSourceはSpringSource Application Platformのベータリリースを最近発表した。我々のニュースやTheServerSide.com(source)の報道が引き金となり、活発な議論を引き起こした。数週間が過ぎ、開発者や業界の専門家たちのコメントは二つの分野に集約されてきた。ライセンス/全体的な戦略と、OSGi/技術的な実装についてである。

ライセンスと全体的な戦略

これほど重大な発表であれば、人々は良い点も悪い点も見つけ出すのが普通である。Imparaプロジェクト（Spring-DMと同様のソリューションをApache License 2.0のもとで作成している）のPhil Zoioは、ブログで以下のように述べている(source)。

...これは本質的には、SpringとOSGiの巨大な統合です。私はOSGiがアプリケーションサーバベンダではなく、一般的な開発者に受け入れられるようになるにはどうしたら良いかを述べてきました。OSGiの特異性を扱うことに、普通のJava開発者が熱中するだろうと私は未だに信じています。...ライセンスについては疑問があります。最初は、SpringSourceはGPLではなくApache V2.0ライセンスに則っていない（訳注: 原文では否定形だが、おそらく間違い） - 多分間違ってnotがついているのだと思われます。SpringFrameworkのライセンスはApacheLicense2.0だし。Shumpei 5/19/08 11:24 AMメジャーな製品をリリースしてきました。このライセンス変更は非常に大きく、市場における企業の位置づけ自体が変わると言うことを反映しています...最後に私が感じている疑問は、この製品全体の中でSpring Framework自身がどこにフィットしているのか、と言うことです。私はいつも、Spring FrameworkはRod Johnsonたちによる製品の中でも最も重要なものだと考えています。...しかしSpring Application Frameworkでは、彼らは大きな賭けに出ています...

一方、Per Olesenは製品とライセンスに対して熱烈に歓迎しているようである(source)。

...私は既に、springframeworkを私のメインエンジンとして活用しており、POJO ORMの方法を長きにわたって採用してきました。これらの方法は全てJEE5やJPAの前からありましたし、私はそれが好きです。私は新しい製品においても、JEE5 EJBの利用を見送ってきました - なぜなら、多くの場合Springモデルの方が優れていることがわかっているからです。それに、JEE5 EJBはプロプライエタリです。このプラットフォームのライセンスは、私のすごく好きなGPLv3です。私の目から見ると、GPLライセンスモデルはこの種のプロダクトには本当に向いていると思います。他の人によって機能が追加されたりそれ自体が拡張されたりしても、オープンであり続けるからです。

IBMのBilly Newportは、アプリケーションサーバベンダの視点(source)から意見している。

...それは、私や他の人が次の数年間で計画/希望していたものに似ています。私たちの多くは、商用フレンドリなライセンス（EPL、BSD、Apache）によるOSGiベースの分散プラットフォームを探っているところです。...まとめると、私はそのプラットフォームを有益な物だとは見なしていません。私はそれはコモディティ化していると考えています。私はプロファイルと、モニタリングのためのプロファイルこそが有益であり、商用フレンドリなライセンスによるOSGiの分散実行環境こそが新しいJVMであり、ベンダはそれに対してミドルウェア/プロファイルを構築するものだと考えています。Spring DMがApacheライセンスだと言うことを考えると、私はSpringサーバに対する追加作業をクリーンルーム実装し、すぐにEPLかApacheで利用できるようにできます。（しかし）これはSpringSourceサーバの売上を考えると価値が制限されてしまうことでしょう。...私は SpringSourceがしようとしていることを矮小化したくはありません。これはとてもクールで、必要とされているものです。しかし、そのコンポーネントのほとんどがApache 2.0かEPLだったら、Java EEやBPELのフローエンジンを作るよりも、もっと単純に最後にギャップを埋めることができるのに、と言うことです。the last gap is a lot simpler...の文、訳し方が難しい。意訳しました -Shumpei 5/19/08 11:57 AM .

IBMフェローである、Jerry Cuomoもコメントしている(source)。

...InfoQにおける記事が引き金となって、私のメール受信箱はものすごくにぎやかになり、まるでクリスマスツリーのようです。件名はこうです - "SpringSourceが、WebSphereに宣戦布告。" ほんとですか？私にはそのようにはあまり見えません。まず最初に申し上げておきたいのは...私はSpringのファンであり、OSGiの基盤と Springフレームワークのような技術は、Javaベースのアプリケーションが提供する未来だと考えています。一つのサイズのサーバが全てにフィットしていた日々は過ぎ、特定のタイプの作業に特化したサーバを構築する、と言う目的へと進歩しています。...SpringSourceが突然やってきて、それをGPLライセンスの基で行うのは残念なことだと感じています。Apacheライセンスの"リファレンス"アプリケーションプラットフォームから、業界は利益を得てきました。...しかし、適切なサイズで複数のパーソナリティを持つ、と言うプラットフォームへの進化のトレンドは無秩序なものではありませんし、SpringSourceとWebSphereの間で戦争が起ころうとしているわけでもありません - それは単に業界が進歩していく過程に過ぎません。そして恐らくJavaコミュニティとは、これまでどおり協力していけるでしょうし、チャンスの場を作り出していけるでしょう。実際にこれを評価し、最終的に広まるかどうかは我々の顧客次第です...

 最後に、Marc Fleury（かつてJBossに所属）の考え(source) を抜きにしては業界の反応を語ることはできないだろう。 

実は、少しだけ気にはなりますが、それほどでもありません。私にとってこれは、ベンチャーキャピタルにそそのかされた動きです。Springは本来コンサルタント会社であり、フレームワーク開発も行ってはいますが、ランタイムの売上に関しては苦戦しています。そこで、「じゃーん！今や我々はOSGiカーネルを中心とした、パッケージ製品を持ってますよ」と言うわけです。 ... 最後に、彼らと他のアプリケーションサーバとの関係に、これがどれくらい影響を及ぼすのかがはっきりしません。彼らはもはや中立ではないのです...見てください、アプリケーションサーバ戦争は2005年に集結しています。現在は2008年であり、EE内でのライトなプログラミングモデル、POJOプログラミングが至る所にあります。

OSGi and Technical Aspects OSGiと技術的な側面

戦略に関するコメントに並行して、SpringSource Application Platformの発表に対しては、OSGiコミュニティ内の多くの開発者から反応があった。Neil Bartlett (source)はOSGiが一般的に使われるようになること、バンドルリポジトリの発表、そして彼が取りかかろうとしていたOSGiの問題をSpringSource Application Platformが解決してくれていることなど、ポジティブな意見を数多く述べている。しかし彼は新しいバンドルヘッダには懸念を示している。

...ここには、あまり感心しない物事があります... 新しい二つのバンドルヘッダがあります。Import-BundleとImport-Libraryです。私の見る限り、Import-BundleはちょうどRequire-Bundleと同じ問題を持っています。この新しいヘッダは不正な手段を単純に提供します。すなわち、あなたは実際の Bundle-SymbolicNameではなく、論理的なバンドル名を共有します。これはパッケージ自身ではなく、パッケージ集合のラッパーに対してバインディングしてしまう、と言う問題を解決していません。さらに悪いのがImport-Libraryで、バンドルの集合全体に対して一度に Import-Bundleを行うのです！...

 Peter Kriens(source)も同じ考えを持っている。 

...バンドルリポジトリはすばらしいの一言につきます。...このバンドルリポジトリには、悲惨な作業が必要だったはずです。称賛に値します！...しかし、 Spring Source Application Platformはちょっとしたショックでした。ドキュメントを眺めてみると、私はOSGiに似ているけども見覚えのない多くのヘッダを見つけました: Import-Library、Import-Bundle、Applicationなどです。それは、SpringSourceがOSGiを広範囲にわたって"改善した"ように見えます...

またSpringSourceチームはいくつかのブログエントリで、アプリケーションプラットフォームの様々な側面を説明している。

 SpringSource Application PlatformとOSGiの上でSpringアプリケーションを動かす(source)

• ロード時のウィービング
• クラスパス・スキャニング
• スレッドコンテキストクラスローダの管理

SpringSource Application Platformのデプロイメントオプション(source)

• 生のOSGiバンドル
• Java EE WAR
• Webモジュール
• プラットフォーム・アーカイブ（PAR）

SpringSource Application Platformのマニフェストヘッダ(source)

• Import-Bundle
• Import-Library

SpringSource Application Platformのプロビジョニング・リポジトリを使う（訳注: repository/bundleディレクトリがOSGiリポジトリとなる）(source)

• 実行時のプロビジョニング
• リポジトリにアイテムを追加する
• 複数のインストール間でリポジトリを共有する

SpringSource Application Platformの主な利点の一つは、必要に応じて依存性が解決されると言うその能力です。この利点は二つあります: プラットフォームのメモリフットプリントが可能な限り小さくなることと、一枚岩のデプロイメント単位（例えばWARファイル）の中に依存関係のすべてをカプセル化することなくアプリケーションをデプロイできるようになることです。これらの能力の利点を得るために、プラットフォームのプロビジョニング・リポジトリを理解する必要があり、このブログは単にそれを提供することを意図しています...

原文はこちらです：http://www.infoq.com/news/2008/05/sap-reactions

• 次へ >