BT

InfoQ ホームページ ニュース PojoSRはJavaにサービスレジストリを持ち込む

PojoSRはJavaにサービスレジストリを持ち込む

ブックマーク

原文(投稿日:2011/10/13)へのリンク

Karl Pauls氏が PojoSR 0.1.6をリリースした。これは、完全なOSGiランタイムスタックを必要とせずにOSGi バンドルをロードでき、サービスを一緒に繋ぐことができるようにする。PojoSR が完全なOSGiプラットフォームと違うのは、ネストしたクラスローダーを使わないことである。なので構造化したOSGi環境でしばしば動かなくなる Hibernateのような行儀の悪いライブラリでも正常に動き続ける。

クラスパス(classpath )上で走っている通常のアプリケーションと違って、 PojoSRによって、フラットなクラスパス ビューからアプリケーションを μServicesで作られたクラスパス ビューへ移行できる。 Declarative Services やApache Felix Gogoシェルのような既存のOSGi バンドルはスタンドアロン環境で走ることができる。バンドルは(現在)クラスパスにある順番で起動するが、Bundle Activatorを持つクラスパス上のあらゆるJARは起動される。これによって、Javaアプリケーションは、フラットなクラスパス の世界でも OSGiに似たランタイムを起動できる。

$ curl http://repo1.maven.org/maven2/com/googlecode/pojosr/de.kalpatec.pojosr.framework/0.1.6/de.kalpatec.pojosr.framework-0.1.6.jar > pojosr.jar $ curl http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.gogo.runtime/0.8.0/org.apache.felix.gogo.runtime-0.8.0.jar > runtime.jar $ curl http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.gogo.command/0.8.0/org.apache.felix.gogo.command-0.8.0.jar > command.jar $ curl http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.gogo.shell/0.8.0/org.apache.felix.gogo.shell-0.8.0.jar > shell.jar $ java -cp pojosr.jar:runtime.jar:shell.jar:command.jar de.kalpatec.pojosr.framework.PojoSR g! lb START LEVEL 1 ID|State |Level|Name 0|Active | 1|System Bundle (0.0.1) 1|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Classes/classes.jar!/ (0.0.0) 2|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Classes/ui.jar!/ (0.0.0) 3|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Classes/jsse.jar!/ (0.0.0) 4|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/lib/jce.jar!/ (0.0.0) 5|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Classes/charsets.jar!/ (0.0.0) 6|Active | 1|jar:file:/System/Library/Java/Extensions/AppleScriptEngine.jar!/ (0.0.0) 7|Active | 1|jar:file:/System/Library/Java/Extensions/dns_sd.jar!/ (0.0.0) 8|Active | 1|jar:file:/System/Library/Java/Extensions/j3daudio.jar!/ (0.0.0) 9|Active | 1|jar:file:/System/Library/Java/Extensions/j3dcore.jar!/ (0.0.0) 10|Active | 1|jar:file:/System/Library/Java/Extensions/j3dutils.jar!/ (0.0.0) 11|Active | 1|jar:file:/System/Library/Java/Extensions/jai_codec.jar!/ (0.0.0) 12|Active | 1|jar:file:/System/Library/Java/Extensions/jai_core.jar!/ (0.0.0) 13|Active | 1|jar:file:/System/Library/Java/Extensions/mlibwrapper_jai.jar!/ (0.0.0) 14|Active | 1|jar:file:/System/Library/Java/Extensions/MRJToolkit.jar!/ (0.0.0) 15|Active | 1|jar:file:/System/Library/Java/Extensions/QTJava.zip!/ (0.0.0) 16|Active | 1|jar:file:/System/Library/Java/Extensions/vecmath.jar!/ (0.0.0) 17|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/lib/ext/apple_provider.jar!/ (0.0.0) 18|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/lib/ext/dnsns.jar!/ (0.0.0) 19|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/lib/ext/localedata.jar!/ (0.0.0) 20|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/lib/ext/sunjce_provider.jar!/ (0.0.0) 21|Active | 1|jar:file:/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/lib/ext/sunpkcs11.jar!/ (0.0.0) 22|Active | 1|Apache Felix Gogo Runtime (0.8.0) 23|Active | 1|Apache Felix Gogo Shell (0.8.0) 24|Active | 1|Apache Felix Gogo Command (0.8.0)

InfoQは Karl氏と話す機会を持てたので、 最初にPojoSRとはどのようなものか、という質問をした。

Karl Pauls: OSGiに移行するには、コードベースがはJava (Spring, JPAなど)では一般的である、class loading hacks や静的なクラスローディングを使わない必要があります。 class loading hacksはほとんどの場合、 OSGiで置き換えることができます。しかし、今までは、それらを使う前に、モジュール性の視点から、まずクリーンでなければなりませんでした。

PojoSRのお陰で、Javaで作られたアプリケーションは、サービスベースのモジュール性の恩恵を受けられるのです。始めに既存のコードからいかなるクラスローダーのトリックを取り除く必要はありません。したがって、OSGi へ移行するのに、最初に全てのコードを綺麗にする必要がありません。このアプローチのお蔭で、多くの既存のコードがそのままで動くのです。ただそれらをクラスパスに加えるだけです。

InfoQ: PojoSRを書くようになった動機はなんですか?

Karl Pauls: 本当に始めたのは、今年の始めの Peter Kriens氏との議論からです。我々は、 サービスがOSGiの実際に最も面白い側面だ、と話してました。多くの人々が OSGiをステロイド上のクラスローダーとして考え、サービスを完全に無視しているのを見るのは、かなりイライラくるものです。副作用として、彼らは OSGiにイラついています。なぜなら彼らは間違った層にある彼らの問題の幾つかを解決しようとしているからです。それらはサービスを使えばほとんど自然に解決されてしまうものです。

しかし一番重要な点は、我々は2人とも、OSGiのサービスモデルを20年前のオブジェクト指向のような、新しい種類のパラダイムとして考えたことです。「動的」サービスの概念やSCR, iPOJOなどのような サービスコンポーネントモデルは、それ自身で新しく価値のあるもので、 OSGiの「動的」世界を受け入れる時に扱わなければならない類のものではありません。

想像できると思いますが、それは生き生きとした議論で、私の中では、どうやったら人々がもっとサービスレベルで考えるようにできるだろうか、という事になりました。Peterの考えではおそらく、スタンドアロンのサービスレジストリが役立つだろう、ということでした。しばらくそれについて考えた後、これは実際には、そんなに難しいことではないと、考えるようになりました。というのも、私は Apache Felixにあるサービスレジストリを再利用するだけだからです。そして実際それが私がやったことです。

InfoQ: サービスディスカバリ プラットフォームは、PojoSR と完全な OSGi スタックとでは、どう違うのですか?

Karl Pauls: PojoSRはそれに関しては2つの方法を提供しています。一つ目は、バンドルコンテキストからサービス関連のメソッドを捉えるスタンドアロンのサービスレジストリです。これによって、サービスを発行、発見できます。これはOSGi内で動くのと、非常に似たように動きますが、バンドルの概念をほぼ完全に無視しています。

2つ目は PojoSRを起動する時に、クラスパスに実際のバンドルを追加できます。通常のOSGi フレームワークのようにアクティベーターを実行します。どちらのアプローチもモジュール境界を強要しません。同じパッケージの複数のバージョンを許しません。ほとんどのOSGi モジュール層のフィーチャもサポートしません(しかし、幾つかはサポートされます)。例えば、 Bundle-ClassPathをサポートしませんが、似たような Bundle.getResource()はサポートしているので、エクステンダーパターンは動きます。

重要なことは、サービスを使えば、いずれ class loading hacksを除くことができることです。そうなれば完全なOSGiへの移行やいくつものバージョンを並べたり、本当のモジュール境界を置くこともずっと簡単になるでしょう。更に非OSGi環境でバンドルを使えるようになります。

InfoQ: PojoSRを使って何を上手く動かすことができましたか?

Karl Pauls: 私はかなり小さいものから始めました。 gogoシェルのようなものや基本的なサービスモデル例えば、 Declarative Services (SCR), iPOJO, Blueprint, Dependency Managerが動くことを確認しました。そうしたら、 Apache Felix WebconsoleがFelix http.jetty Serviceと一緒に動きました。基本的に、動かそうとしたものはほとんど、ちょっとした調整で動きました(ほとんど場合確認したのは、Bundle-Classpath上の全エントリーが 実際のクラスパス上に抽出され、同時に、クラスパスのあるバンドル順に動くことです)

Vaadinベースのものを動かすことが出来ました。例えば、Marcel Offermans と私が我々のチュートリアルでよく使う例とか、非常に洗練された Vaadinベースのシェルである Apache Aceですね。結局、Apache Slingようなものでさえ動き、おそらくOSGiの最大の例であるEclipse IDE自身ぐらいレベルでも動くのです。

Eclipseを動かすこともでき、通常のJavaパースペクティブや bndtoolsでも動きます(確かにPDEとP2は動きません。 equinoxに強く依存しているからです)。これらの例が全て完全に動いたとか、 PojoSRがOSGiフレームワークを完璧な代替になると言っているわけではありません。しかし、よくモジュール化された(OSGi-ベースの)システムは、 (ちょっとした調整で)PojoSRでもほとんど動く、ということを示しており、このことは OSGiとモジュール性への確かな証しです。コードをモジュール化すれば、選択肢があります。

InfoQ: PojoSRが本格的な'OSGi-lite' 標準になるだろう、と思ってますか?

Karl Pauls: いや、とにかく OSGi Allianceついて話すことはできませんし、しません。しかし OSGiがこのモデルについて、態度を決めたり、願わくばある種の標準化に持っていくことで支持してくれることは、意味があると思います。そのことで議論がありましたが、最終的な結論には至っていません。真の疑問は、このアプローチが仕様化を保証するほど注目を集めるかどうかです。私はどちらでもいいです。私の一番の目標である、人々がサービスを最初に使うのを簡単にする、ということは、その実装をリリースすることで達成されましたからね。それはOSGi へ移行するのに大変な助けとなり、今日人々はそれを使っています。

InfoQ: JavaOneでのスピーチ、 Service First Migration to OSGiなどへの反応はどうでしたか?

Karl Pauls: JavaOneでは、我々は PojoSRについて2つ話をしました。一つは、 Richard S. Hall と私による、 "μServices for the rest of us" です。もう一つが BJ Hargrave と Peter Kriensによる "Service-First Migration to OSGi"です。更に ごく最近DarmstadtでのOSGi Community Event で話をし、パネルに参加しました。これらからのフィードバックは非常に好意的でした。

皆、そのアイデアが気に入ったようです。特に既存のアプリケーションを OSGiに移行する際に、非常に良くある問題を解決できるのがその理由です。好まれているもう一つの強力なアイデアは、クラスパスにバンドルを置くだけで、コントロールできることです。いったんそうすると、集中的に変更する必要がありません。クラスパスにある誰かにコントロールを委譲できるからです。

InfoQ: 既存のアプリケーションを PojoSRに移行するにはどのような移行手順が必要なのですか?

Karl Pauls: 通常のJavaアプリケーションに関しては、実際たいしたことはありません。必要なのは、どこかに PojoSRのインスタンスを作ることです。それだけです。それとどのようにやり取りするのが一番いいか、まだ結論が出ていませんが、当面言えるのは、次にやることは、 Bundle-Activator(あるいは、もっといいのは、アノテーション ベースのサービスコンポーネントモデル)をアプリケーションに導入して、その機能のあるものをサービスに作り直すことです。それが簡単か手間かはアプリケーションに依存しますが、重要なことは、他に何の変更も要らないことです。

更に、既存の OSGiサービスやバンドルを活用したい、そしてそれらを単にアプリケーションのクラスパスに追加したいと思うでしょう。例えば、早く始めたい、そしてプラグインシステムをあなたのアプリケーションに追加したいだけと考えているとしましょう。そうすればアプリケーション内にあるAPIを利用できますから。これは非常に簡単にできます。 PojoSRを最初に起動し、次に実際のアプリケーションを起動する新しい mainメソッドを作るだけです。こうすると、クラスパスにあるバンドルがあなたのアプリケーションとやり取りを始めます。次に例えば、Declarative Servicesランタイムをクラスパスに追加すれば、アプリケーションのJARのどれかにある Declarative Servicesをほとんど直接使い始めることができます。あなたのJARに必要なメタデータを追加するだけで、後は大丈夫です。

InfoQ: 完全なOSGi スタックが走らないところでも PojoSRは走ることができたのですか?

Karl Pauls: もちろんです。Peter Kriens氏が 彼の最初のブログ投稿に書いたのは、OSGiベースの何かを Amazon AWS Elastic Beanstalk上で走らせる簡単な手段として、PojoSRを使いました。しかしこれは完全なOSGi フレームワークでも動くでしょう(ずっとやることは多いですが)からあくまでも便宜上のためでした。おそらく、最も面白い例は、 Angelo van der Sijptと私がGoogle App Engine (GAE)で Felix Webconsoleと一緒に動かした デモアプリケーション でしょう。

その時点では、完全な OSGiフレームワークでは、それは無理でした[編集部:スレッドを生成する際の制限によって]が、 PojoSRを使うとかなり簡単でした。幸運にも、OSGi を使うのが難しい場所やシナリオがだんだん少なくなってきていますが、それでもまだ、完全なOSGi ランタイムを統合するのが不可能ではないにしても、かなりのことをする必要があります。このような状況には、PojoSRは考慮に値するでしょう。 PojoSRを使えば、OSGi 仕様書に従った、上手くモジュール化したアプリケーションを開発することができます。そして非OSGi 対応の環境でそのようなアプリケーションを走らせることができます。例えば、それをWARに追加するするのは訳ないことです。

InfoQ: PojoSRの将来をどう考えますか?

Karl Pauls: 今は、はっきりしたことは言えません。その発想は非常に私には面白く、理解されるか興味があります。願わくば、 OSGi Allianceがモジュール層なしの OSGiフレームワークの仕様を作成して欲しいです。しかし、私はこの成果を Apache Felixにマージしたいと思っています。標準化されなくてもそれは有益なこですから。私は、 PojoSRは、もっとアプリケーションがOSGiとその(サービス指向)アーキテクチャを採用するのに本当に重要だ、と考えています。

PojoSRについての更なる情報は、Google Code projectページで見つけることができる。サービス自身は、ダウンロードページかMavenからmvn:com.googlecode.pojosr:de.kalpatec.pojosr.frameworkでダウンロードできる。pojosr-discuss グループもある。Karl氏にはツイッターの @karlpaulsで繋がる。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。