g*workshop 20101209 osgi and grails2.0
TRANSCRIPT
Grails2.0 に備えて OSGi を学ぼう@ 第 13 回 G* ワークショップ
2010/12/9日本アイ・ビー・エム ( 株 ) 須江 信洋
http://twitter.com/nobusue
※ 資料の内容は個人としての意見・見解を述べたものであり、所属する企業・組織が内容を保証するものではありません。
( 不要かもしれませんが ) 自己紹介 須江 信洋（すえ のぶひろ） 1970 年生まれの 40 才 ずっと JavaEE 関連の仕事をしています
職場は何回か変わってます。。。 G* との関わり
Groovy を組み込んだ製品 (WebSphere sMash) を売ってます
JGGUG サポート・メンバー 「 Groovy イン・アクション」翻訳メンバーの一味 「 Groovy 入門（仮称）」依然として執筆中です。。。
2
今日、私がここに出てきた理由は・・・ OSGi って最近よく聞くけど、いったい何者？ それは美味しいですか？ それは開発者を苦しめる新たなバズワードですか？ 僕らに何か関係あるんですか？ 関係ないけどガンダム UC は商業ベースの同人作
品？
3
という、もろもろの疑問を解決するためだと認識しており
ます
OSGi ってなんで必要なの？一言で教えて。ようがす。
4
Answer:Java はコンポーネント指向プラットフォーム
として欠陥があるからです
コンポーネント指向 ( モジュール指向 ) プラットフォームの要件
モジュール境界が定義できること 外部に公開するインターフェース モジュールに閉じたリソース 物理的なパッケージングの仕様
モジュール間の依存性管理が可能であること 依存先モジュールの明示 モジュールのバージョン管理 依存関係の解決
モジュールのライフサイクル管理が可能であること インストール / アンインストール 開始 / 停止 ライフサイクルイベントへの対応
Java の現状 モジュール境界の定義に関する課題
クラスやメソッドの可視性だけでは十分な制御が難しい public ではクラスローダー全体に公開されてしまう そもそも、 Java のクラスはモジュールの単位としては細かすぎる
JAR はモジュールとしては機能不足 単に複数のクラスやリソースをまとめる機能のみ 一旦ロードされた後は、個別のクラス単位で認識されるのみ（ JAR は意識
しない） モジュール間の依存性管理に関する課題
静的な依存関係はコンパイルしてみないと分からない 実行時の依存関係は実行してみないと分からない バージョン管理機能がない
モジュールのライフサイクル管理に関する課題 一旦ロードしたクラスはアンロードできない ライフサイクルという概念はない ( ロードされたら直ちに有効となる )
Project Jigsaw でモジュール化機構を導入ただし Java8(2012 年予定 )
7
OSGi 小史 1999 年：「 Open Service Gateway Initiative 」が設立
当初は家庭や小規模オフィス向けのゲートウェイ装置で動作するサービスプログラムの実行基盤
2003 年：名称を「 OSGi Alliance 」に変更 対象を車載機器やモバイル端末、エンタープライズシステム
に拡大 2003 年： Eclipse 3.0 がプラグイン管理システムとして OSGi
仕様を採用 Java の世界での知名度が一気に向上
2010 年： OSGi R4.2 の一部として Enterprise Specification 公開 Java EE環境で OSGi を活用するための拡張仕様 Spring Framework 由来の DI コンテナ機能も標準化
8
OSGi の提供する機能 Moduleレイヤー
依存関係の解決 複数バージョンの管理
Life Cycleレイヤー モジュールの動的ロード
Serviceレイヤー Securityレイヤー
実行環境が依存関係を管理
異なるモジュールが同一モジュールの異なるバージョンを
要求しても OK
JVM を起動したままモジュールの入れ替えが可能
Bundle: OSGi におけるモジュール
9
JAR +OSGi
Metadata
META-INF/MANIFEST.MF
OSGi Metadata
10
Manifest-Version: 1.0Export-Package: org.apache.aries.samples.blueprint.helloworld.server; uses:="org.apache.aries.samples.blueprint.helloworld.api"; version="0.2.0.incubating"Import-Package:org.apache.aries.samples.blueprint.helloworld.api;version="[0.2,0.3)"Implementation-Title: Apache AriesImplementation-Version: 0.2-incubatingBundle-Name: Apache Aries Blueprint HelloWorldServerBundle-SymbolicName: org.apache.aries.samples.blueprint.helloworld.serverBundle-Vendor: The Apache Software FoundationBuild-Jdk: 1.6.0_21Bundle-Version: 0.2.0.incubatingBundle-ManifestVersion: 2Bundle-Description: Example blueprint hello world application - serverBundle-License: http://www.apache.org/licenses/LICENSE-2.0.txtBundle-DocURL: http://www.apache.org
11
バージョン管理
ImportExport
com.foo.bar
1.4.5
com.foo.bar
1.3.12
com.foo.bar
[1.2.0, 1.4.0)
com.foo.bar
[1.4.0, 1.5.0)
1.2.0 ≦ バージョン ＜ 1.4.0
両方の Bundle に同名のClass が存在していても、正しく解決される
12
Bunlde のライフサイクルと依存関係の解決
OSGi Framework にBundle をロードすると
"Installed" に
Import-Package などで指定された依存関係を満たすかチェック
⇒OK なら "Resolved" に
Bundle を start すると、 "Starting" を経
て "Active" に
Bundle を stop すると、 "Stopping" を経て "Resolved" に戻る
13
ライフサイクル・サービス
import org.osgi.framework.BundleActivator;import org.osgi.framework.BundleContext;public class MyAppActivator implements BundleActivator { public void start(BundleContext context) throws Exception { System.out.println("Bundle is starting."); } public void stop(BundleContext context) throws Exception { System.out.println("Bundle is stopping."); }}
import org.osgi.framework.BundleActivator;import org.osgi.framework.BundleContext;public class MyAppActivator implements BundleActivator { public void start(BundleContext context) throws Exception { System.out.println("Bundle is starting."); } public void stop(BundleContext context) throws Exception { System.out.println("Bundle is stopping."); }}
Bundle の状態が変化したときに、 Framework から
コールバックされる
14
バージョン管理 : behind the scenes
ImportExport
com.foo.bar
1.4.5
com.foo.bar
1.3.12
com.foo.bar
[1.2.0, 1.4.0)
com.foo.bar
[1.4.0, 1.5.0)
ClassLoader
Framework が Bundle毎にClassLoader を作成
し、 Metadata に従って関連付ける
めでたし、めでたし？ ここまでの話で「おや？」と思った方、鋭い！ 実はまだ問題があります。。。整理してみましょう。
Bundle 間の依存関係の解決は、 Bundle をロードした後に行われる
無事に依存関係が解決できると、 Bundle毎のクラスローダーが関連づけられ、 "Resolved" に
Bundle を start すると "Active" になって動作する では、既に Active になっている Bundle の新しい
バージョンをリリースするには、どうすれば？
15
Bundle のバージョンアップ？
16
com.foo.bar
1.4.5
com.foo.bar
[1.4.0, 1.5.0)
ImportExport<<active>> <<active>>
com.foo.bar
1.4.6
install/start
Client Bundle を stop/start しない限り、新しいバージョンとの紐付けは行われない
実は・・・ Export-Package/Import-Package による参照は
「静的な参照」関係 依存関係の解決は、 Bundle を start した時に
OSGi Framework にロードされている Bundle に対して行われる
依存関係を更新するためには、 Bundle を再起動する必要あり
17
この方法では、動的なモジュールの交換は不可
能(涙 )
では、動的なモジュールの交換はどうする？ そのための仕組みが、 OSGi Framework の提供する
Service Registry です Service と言っても大げさなものではなく、実体は Java の
Class(Interface) です
18
ServiceRegistry
ServiceProvider
ServiceRequester
register lookup
Registry から毎回 lookupするので、更新されたバージョンが登録されていれば
直ちに反映される
Service の登録と参照
19
public class Activator implements BundleActivator { public void start(BundleContext ctx) { ctx.registerService(Greeting.class.getName(), new GreetingImpl("service"), null); }・・・・
public class GreetingImple implements Greeting {・・・・・・・}
Service の登録
public class Client implements BundleActivator { public void start(BundleContext ctx) { ServiceReference ref = ctx.getServiceReference(Greeting.class.getName()); ((Greeting) ctx.getService(ref)).sayHello(); }・・・・
Service の参照
Interface のクラス名で、 GreetingImpl のインス
タンスを登録
Interface のクラス名で、サービスのインスタンスを
取得
OSGi R4.2 Enterprise Specification
OSGi Alliance Enterprise Expert Group(EEG)によって定められた Enterprise 向けの拡張仕様 http://www.infoq.com/news/2010/03/osgi-enterpris
e-42-released
以下が規定されている アプリケーションのアセンブリ・フォーマットの拡張 JavaEE コンテナ・サービスとの統合 宣言的な DI 仕様 (Blueprint)
21
OSGi 化したエンタープライズ・アプリケーション
OSGi Bundle（ .jar ）
OSGi Bundle（ .jar ）
OSGi Bundle（ .jar ）
OSGimetadata
Web AppBundle （ .wab ）
EnterpriseBundle App（ .eba ）
Enterprise Bundle App （ .eba ）
ContextPath
BusinessLevel
Application
VirtualHost
Blueprint component model サービスレジストリへの登録や参照を宣言的に行うための仕様 JNDI サービスにより、 OSGi のサービスレジストリに JNDI経由でアクセス可能
OSGi Bundle(.jar)
<blueprint xmlns:tx="http://www.ibm.com/appserver/schemas/8.0/blueprint/transactions" xmlns:jpa="http://www.ibm.com/xmlns/ibm-blueprint-jpa/v1.0.0"><bean id="blabberImpl" class="com.ibm.ws.eba.example.blabber.persistence.BlabberImpl"> <jpa:context property="entityManager" unitname="blabber" /> <tx:transaction method="*" value="Required"/></bean><service id="blabberService" ref="blabberImpl" interface="com.ibm.ws.eba.example.blabber.persistence.spi.BlabberUserInterface" /></blueprint>
[OSGI-INF/blueprint/service.xml]
InitialContext ic = new InitialContext(); return (BlabberUserInterface) ic.lookup("osgi:service/" + BlabberUserInterface.class.getName());
Client
Interface名で実装 (bean) を公開
OSGi サービス・レジストリーからInterface名で実装 (bean) を取得
23
ちょっと宣伝：WAS V7 Feature Pack for OSGi Applicationshttp://www.ibm.com/software/jp/websphere/apptransaction/was/featurepacks/osgi/
WAS の上で動くアプリケーションも "OSGi Bundle" にApache Foundation に寄贈されIncubator でオープンソース化の作業中
OSGi って何がうれしいの？ ( その１ ) 設計モデルと実行モデルの一致
設計モデル
実行モデル (Java)
A.jar B.jar
C.jar
A.jar B.jar
C.jar
フラットな Class Loader
実行モデル (OSGi)
A.jar B.jar
C.jar
バンドル毎の Class Loader
設計モデル
実行モデル
non-OSGi
OSGi
設計時に意図していない参照のリスク
依存関係を明示することで設計時の意図を遵守
OSGi ってなにがうれしいの？ ( その２ ) 依存関係のトレーサビリティ
A.jar B.jar
C.jar D.jar
E.jarF.jar G.jar
モジュールを入れ替える際に影響を受けるモジュールが機械的に特定できる
Grails と OSGi Grails 2.0 Roadmap
http://www.grails.org/Roadmap
26
意味がわからないので、翻訳してみた
27
よくわからんけど、要は Grails のプラグインを OSGi Bundle にするよってこ
とかな？
Grails プラグインを OSGi 化する理由は？ すいません、プラグイン作ったことないので。。。 妄想してみます。 おそらく、以下のような課題があるのでしょう
プラグイン間の依存関係がよく壊れて動かなくなる？ 同一プラグインの複数バージョンを同時にデプロイでき
ない？ アプリケーションを稼働させたまま、サービスモジュー
ルを入れ替えることができない？（いわゆる活性保守） Grails2.0 のブランチはまだ作成されていないので、
どうなるかまったく予想がつきません。
28
待ちきれないよ！！！！ そんなあなたにお勧め、 Grails OSGi plugin
http://www.grails.org/plugin/osgi
Grails アプリケーションを Bundle 化して実行できます grails bundle grails run-bundle
29
まとめると・・・ OSGi って最近よく聞くけど、いったい何者？
モジュラー Java のプラットフォームです。
それは美味しいですか？ 正直、万人向けのお味ではありませんが、慣れるとやみつきになります。
それは開発者を苦しめる新たなバズワードですか？ そんなことはないです。むしろ、大規模開発ではアーキテクトと開発者と基盤担当者の共同作業をやりやすくしてくれます。
僕らに何か関係あるんですか？ Grails2.0 のプラグインシステムは OSGi ベースになるみたいですよ。 SpringSource も OSGi に力をいれてますよ。 今は知ってる人が少ないからチャンスかも。。。。。
関係ないけどガンダム UC は商業ベースの同人作品？ そうです。面白ければいいぢゃないですか！ね、 @bikisuke さん。
30
31
参考資料（宣伝成分多めですが・・・ ) OSGi R4.2 仕様書
http://www.osgi.org/Download/Release4V42 Introduction to OSGi by Neil Bartlett
http://www.slideshare.net/njbartlett/introduction-to-osgi-tokyo-jug dW:エンタープライズ OSGi 入門
第 1 回 OSGi 概要と実行環境の導入http://www.ibm.com/developerworks/jp/websphere/library/was/was7_fep_osgi/1.html
第 2 回 OSGi のエンタープライズ拡張仕様を紐解くhttp://www.ibm.com/developerworks/jp/websphere/library/was/was7_fep_osgi/2.html
第 3 回 OSGi によるアプリケーションのモジュール化http://www.ibm.com/developerworks/jp/websphere/library/was/was7_fep_osgi/3.html
RedBooks: Getting Started with the Feature Pack for OSGi Applications and JPA 2.0 http://www.redbooks.ibm.com/abstracts/sg247911.html?Open
dW: OSGi アプリケーションを開発、利用するためのベスト・プラクティス http://www.ibm.com/developerworks/jp/websphere/library/was/was7_osgi_prac
tices/
以上です。ありがとうございました。
32