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 の現状 モジュール境界の定義に関する課題

クラスやメソッドの可視性だけでは十分な制御が難しい 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