G*workshop 20101209 OSGi and Grails2.0

Grails2.0に備えてOSGiを学ぼう@第13回 G*ワークショップ
2010/12/9
日本アイ・ビー・エム(株)　須江信洋
nsue@e-mail.ne.jp
http://twitter.com/nobusue
※資料の内容は個人としての意見・見解を述べたものであり、
所属する企業・組織が内容を保証するものではありません。

(不要かもしれませんが)自己紹介
須江信洋（すえのぶひろ）
1970年生まれの40才
ずっとJavaEE関連の仕事をしています
職場は何回か変わってます。。。
G*との関わり
Groovyを組み込んだ製品(WebSphere sMash)を売ってます
JGGUGサポート・メンバー
「Groovy イン・アクション」翻訳メンバーの一味
「Groovy入門（仮称）」依然として執筆中です。。。
2

今日、私がここに出てきた理由は・・・
OSGiって最近よく聞くけど、いったい何者？
それは美味しいですか？
それは開発者を苦しめる新たなバズワードですか？
僕らに何か関係あるんですか？
関係ないけどガンダムUCは商業ベースの同人作品？
3
という、もろもろの疑問を解決するためだと認識しております

OSGiってなんで必要なの？一言で教えて。
ようがす。
4
Answer:
Javaはコンポーネント指向プラットフォームとして欠陥があるからです

コンポーネント指向(モジュール指向)プラットフォームの要件
モジュール境界が定義できること
外部に公開するインターフェース
モジュールに閉じたリソース
物理的なパッケージングの仕様
モジュール間の依存性管理が可能であること
依存先モジュールの明示
モジュールのバージョン管理
依存関係の解決
モジュールのライフサイクル管理が可能であること
インストール/アンインストール
開始/停止
ライフサイクルイベントへの対応

Javaの現状
Project Jigsawでモジュール化機構を導入
ただしJava8(2012年予定)
モジュール境界の定義に関する課題
クラスやメソッドの可視性だけでは十分な制御が難しい
publicではクラスローダー全体に公開されてしまう
そもそも、Javaのクラスはモジュールの単位としては細かすぎる
JARはモジュールとしては機能不足
単に複数のクラスやリソースをまとめる機能のみ
一旦ロードされた後は、個別のクラス単位で認識されるのみ（JARは意識しない）
モジュール間の依存性管理に関する課題
静的な依存関係はコンパイルしてみないと分からない
実行時の依存関係は実行してみないと分からない
バージョン管理機能がない
モジュールのライフサイクル管理に関する課題
一旦ロードしたクラスはアンロードできない
ライフサイクルという概念はない(ロードされたら直ちに有効となる)

7
OSGi小史
1999年：「Open Service Gateway Initiative」が設立
当初は家庭や小規模オフィス向けのゲートウェイ装置で動作するサービスプログラムの実行基盤
2003年：名称を「OSGi Alliance」に変更
対象を車載機器やモバイル端末、エンタープライズシステムに拡大
2003年：Eclipse 3.0がプラグイン管理システムとしてOSGi仕様を採用
Javaの世界での知名度が一気に向上
2010年：OSGi R4.2の一部としてEnterprise Specification公開
JavaEE環境でOSGiを活用するための拡張仕様
Spring Framework由来のDIコンテナ機能も標準化

8
OSGiの提供する機能
実行環境が依存関係を管理
異なるモジュールが同一モジュールの異なるバージョンを要求してもOK
JVMを起動したままモジュールの入れ替えが可能
Moduleレイヤー
依存関係の解決
複数バージョンの管理
Life Cycleレイヤー
モジュールの動的ロード
Serviceレイヤー
Securityレイヤー

Bundle: OSGiにおけるモジュール
9
OSGi
Metadata
+
JAR
META-INF/MANIFEST.MF

OSGi Metadata
10
Manifest-Version: 1.0
Export-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 Aries
Implementation-Version: 0.2-incubating
Bundle-Name: Apache Aries Blueprint HelloWorldServer
Bundle-SymbolicName: org.apache.aries.samples.blueprint.helloworld.server
Bundle-Vendor: The Apache Software Foundation
Build-Jdk: 1.6.0_21
Bundle-Version: 0.2.0.incubating
Bundle-ManifestVersion: 2
Bundle-Description: Example blueprint hello world application - server
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-DocURL: http://www.apache.org

11
バージョン管理
1.2.0≦ バージョン＜ 1.4.0
com.foo.bar
com.foo.bar
com.foo.bar
com.foo.bar
1.4.5
1.3.12
[1.2.0, 1.4.0)
[1.4.0, 1.5.0)
Import
Export
両方のBundleに同名のClassが存在していても、正しく解決される

12
Bunldeのライフサイクルと依存関係の解決
Bundleをstopすると、"Stopping"を経て"Resolved"に戻る
Bundleをstartすると、"Starting"を経て"Active"に
OSGi FrameworkにBundleをロードすると"Installed"に
Import-Packageなどで指定された依存関係を満たすかチェック
⇒OKなら"Resolved"に

13
ライフサイクル・サービス
Bundleの状態が変化したときに、Frameworkからコールバックされる
importorg.osgi.framework.BundleActivator;importorg.osgi.framework.BundleContext;publicclassMyAppActivatorimplementsBundleActivator {publicvoidstart(BundleContext context) throws Exception {System.out.println("Bundle is starting."); }publicvoidstop(BundleContext context)throws Exception {System.out.println("Bundle is stopping."); }}

14
バージョン管理:behind the scenes
com.foo.bar
com.foo.bar
com.foo.bar
com.foo.bar
1.4.5
1.3.12
[1.2.0, 1.4.0)
[1.4.0, 1.5.0)
ClassLoader
Import
Export
FrameworkがBundle毎にClassLoaderを作成し、Metadataに従って関連付ける

めでたし、めでたし？
ここまでの話で「おや？」と思った方、鋭い！
実はまだ問題があります。。。整理してみましょう。
Bundle間の依存関係の解決は、Bundleをロードした後に行われる
無事に依存関係が解決できると、Bundle毎のクラスローダーが関連づけられ、"Resolved"に
Bundleをstartすると"Active"になって動作する
では、既にActiveになっているBundleの新しいバージョンをリリースするには、どうすれば？
15

Bundleのバージョンアップ？
16
com.foo.bar
com.foo.bar
com.foo.bar
1.4.5
[1.4.0, 1.5.0)
1.4.6
Import
Export
<<active>>
<<active>>
install/start
Client Bundleをstop/startしない限り、新しいバージョンとの紐付けは行われない

実は・・・
Export-Package/Import-Packageによる参照は「静的な参照」関係
依存関係の解決は、Bundleをstartした時にOSGi FrameworkにロードされているBundleに対して行われる
依存関係を更新するためには、Bundleを再起動する必要あり
17
この方法では、動的なモジュールの交換は不可能(涙)

では、動的なモジュールの交換はどうする？
そのための仕組みが、OSGiFrameworkの提供するService Registryです
Serviceと言っても大げさなものではなく、実体はJavaのClass(Interface)です
18
Registryから毎回lookupするので、更新されたバージョンが登録されていれば直ちに反映される
ServiceRegistry
register
lookup
Service
Requester
Service
Provider

Serviceの登録と参照
19
public class GreetingImple implements Greeting {
・・・・・・・
}
Serviceの登録
public class Activator implements BundleActivator {
public void start(BundleContextctx) {
ctx.registerService(Greeting.class.getName(),
new GreetingImpl("service"), null);
}
・・・・
Interfaceのクラス名で、GreetingImplのインスタンスを登録
Serviceの参照
public class Client implements BundleActivator {
public void start(BundleContextctx) {
ServiceReference ref =
ctx.getServiceReference(Greeting.class.getName());
((Greeting) ctx.getService(ref)).sayHello();
}
・・・・
Interfaceのクラス名で、サービスのインスタンスを取得

OSGi R4.2 Enterprise Specification
OSGi Alliance Enterprise Expert Group(EEG)によって定められたEnterprise向けの拡張仕様
http://www.infoq.com/news/2010/03/osgi-enterprise-42-released
以下が規定されている
アプリケーションのアセンブリ・フォーマットの拡張
JavaEEコンテナ・サービスとの統合
宣言的なDI仕様(Blueprint)

21
OSGi化したエンタープライズ・アプリケーション
OSGi Bundle（.jar）
OSGimetadata
BusinessLevelApplication
EnterpriseBundle App（.eba）
Web AppBundle （.wab）
ContextPath
VirtualHost
Enterprise Bundle App （.eba）

Blueprint component model
サービスレジストリへの登録や参照を宣言的に行うための仕様
JNDIサービスにより、OSGiのサービスレジストリにJNDI経由でアクセス可能
[OSGI-INF/blueprint/service.xml]
<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 Bundle(.jar)
Interface名で実装(bean)を公開
OSGiサービス・レジストリーからInterface名で実装(bean)を取得
InitialContextic = new InitialContext();
return (BlabberUserInterface) ic.lookup("osgi:service/" + BlabberUserInterface.class.getName());
Client

23
ちょっと宣伝：WAS V7 Feature Pack for OSGi Applications
Apache Foundationに寄贈されIncubatorでオープンソース化の作業中
http://www.ibm.com/software/jp/websphere/apptransaction/was/featurepacks/osgi/
WASの上で動くアプリケーションも"OSGi Bundle"に

OSGiって何がうれしいの？(その１)
設計モデルと実行モデルの一致
実行モデル
実行モデル(Java)
フラットなClass Loader
設計モデル
B.jar
A.jar
non-OSGi
設計モデル
B.jar
設計時に意図していない参照のリスク
A.jar
C.jar
実行モデル(OSGi)
バンドル毎のClass Loader
C.jar
OSGi
B.jar
A.jar
依存関係を明示することで設計時の意図を遵守
C.jar

OSGiってなにがうれしいの？(その２)
依存関係のトレーサビリティ
A.jar
モジュールを入れ替える際に影響を受けるモジュールが機械的に特定できる
B.jar
C.jar
D.jar
E.jar
F.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_practices/

以上です。ありがとうございました。
32

G*workshop 20101209 OSGi and Grails2.0

by Nobuhiro Sue on Dec 09, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 7

Statistics

G*workshop 20101209 OSGi and Grails2.0 — Presentation Transcript

http://static.slidesharecdn.com	4
http://a0.twimg.com	3