G*workshop 20101209 OSGi and Grails2.0
Upcoming SlideShare
Loading in...5
×
 

G*workshop 20101209 OSGi and Grails2.0

on

  • 1,439 views

 

Statistics

Views

Total Views
1,439
Views on SlideShare
1,432
Embed Views
7

Actions

Likes
0
Downloads
6
Comments
0

2 Embeds 7

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

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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
    OSGi Bundle(.jar)
    OSGi Bundle(.jar)
    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って何がうれしいの?(その1)
    設計モデルと実行モデルの一致
    実行モデル
    実行モデル(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ってなにがうれしいの?(その2)
    依存関係のトレーサビリティ
    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