O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
成長できるエンタープライズシ
ステムを目指して
OSGi によるモジュール型アーキテクチャの実現



 19-C-3                近藤寛喜
                       株式会社チェンジビジョン
      ...
自己紹介
アジェンダ

•   システムを継続的に成長させるには?
•   OSGiとは?
•   Bundle設計の六個の勘どころ
•   デモ
•   OSGiがもたらす未来




         Developers Summit 2010
一.システムを持続的に
  成長させるには?




   Developers Summit 2010
システムはそもそも複雑なもの




    http://www.flickr.com/photos/adc/411821495/
複雑なシステムを
わかりやすく構築するには
 どうしたらよいですか?

    Developers Summit 2010
複雑なシステム
を構成するには
複雑性を軽減す
る仕組みが必要
オブジェクト指向も、構造化設計も
 複雑性を軽減させる仕組み




   http://www.flickr.com/photos/procsilas/392877509/
•例: Eclipse

高い成長性を維持




         Developers Summit 2010
Eclipseの成長の要因の一つは、

モジュール型アーキテクチャ
           にある




      Developers Summit 2010
モジュール型アーキテクチャ
    http://www.flickr.com/photos/37hz/1247083341/
スモールイズビューティフル




   http://www.flickr.com/photos/mdpettitt/2665598298/
スモールイズビューティフル

•   柔軟な構成を取れる
•   保守しやすい
•   理解が簡単
•   再利用しやすい
•   … 等々




         Developers Summit 2010
普通の Java だったら・・・
http://www.flickr.com/photos/morberg/3146874095/
Q.JARで
モジュールシステムを構成
   できないの?


    Developers Summit 2010
A.できないことはないです。
でもモジュールとして維持するのが
        大変。



     Developers Summit 2010
Java のクラスロードモデル
   依存         拡張                       ブート
            クラスローダ                   クラスローダ
  JAR


         アプ...
つまり・・・

 • JARをモジュールとして分離し、再利用
 • →必要なJARが無い
 • →ClassNotFoundExceptionでクラッシュ

 JARには暗黙的な依存関係が存在




          Developers ...
JARは依存する
JARの情報を持
っていません
アプリケーション
             クラスローダの中
http://www.flickr.com/photos/shareski/3481154470/
APPクラスロー
ダでは変更した
時の影響範囲が
分かりません
再利用の二つの軸



   空間軸
  ( 機能 : ライブラリ等 )




              時間軸
             Developers Summit 2010
成長するシステ
ムとは時間軸で
の再利用ができ
るシステムの事
新しい要件に対
応する度にシス
テムを全部更新
をしますよね?
規模が大きくな
るにつれ、どう
なっていきます
か?
システムを全部
更新する=影響
が分からないの
で全テスト
ごちゃごちゃのシステム




  http://www.flickr.com/photos/joiseyshowaa/2402764792/
見通しよく整理する




  http://www.flickr.com/photos/cheltenham/4100341188/
システムを分割
し、影響範囲を
限定するため独
立させたい
依存情報があれ
ば、依存情報か
らテスト範囲を
限定できます
どうやって?




   http://www.flickr.com/photos/oddwick/1765661986/
•Eclipse の例

プロジェクト間の独立性と
依存関係の整理がキー




        Developers Summit 2010
まとめ:
複雑なシステム
→小さく・独
立・組み合わせ
  Developers Summit 2010
モジュール型システムの問題

•   開発コスト
     –   意識しない時の3倍
          •   独立性の担保
          •   依存関係の整理
•   規模が小さい時は×
    →例:設計したら1モジュール


...
二.OSGiとは?




      Developers Summit 2010
OSGi とは

•   Open Service Gateway initiativeの略
•   「オープンなサービスゲートウェイの推進」
•   Dynamic Module Systems for Java
•   Javaのための動的...
OSGi とは




          黒船来航
増える OSGi の利用例




  •   King of Java Application's infrastructure
                      •        By Neil Bartlett
        ...
どんなところで有効なの?

•   継続して成長させたいシステム
    –   ツール
    –   Webサービス
    –   エンタープライズシステム
•   お客さん毎に違う機能セットを提供したい
    –   パッケージのカス...
OSGi の 3 大要素
モジュールシステム
サービス連携
動的 ( Dynamic )
      http://www.flickr.com/photos/yourdon/2921734152/
OSGi の 3 大要素
モジュールシステム
サービス連携
動的 (Dynamic)
     http://www.flickr.com/photos/yourdon/2921734152/
OSGiを使って
モジュールシステムを構築すると、
クラスローダの関係はこうなります。




     Developers Summit 2010
OSGi のクラスロードモデル
                               System         G




                 A                 B          C


JAR+...
利点

•   依存するBundleごと他のシステムへ
    –   →Eclipseのプラグインのインストール


•   依存の宣言がないBundle同士は分離
•   →Bundle内の変更が他に影響しにくい
•   →Bundleごと...
Bundle =   JAR + メタデータ
今まで通りの環境でも使える



             Developers Summit 2010
欠点

•   独自のクラスロード構造
     –   Class.forName()が使えない
     –   →クラスローダが異なるクラスは読めない
     –   リソースが読めない
     –   →クラスローダが(同上)   ...
OSGi のメタデータの
書き方一例
META-INF/MANIFEST.MFに記述
 シンボル名:Bundle-SymbolicName
 バージョン:Bundle-Version
 依存関係
  必要なパッケージ:Import-Packag...
OSGi メタデータの
一例




      Developers Summit 2010
メタデータがあるので・・・

•   パッケージによる公開・非公開の制御
•   JARに必要なパッケージの宣言
•   →パッケージを公開しているJAR必要
•   →依存関係を定義できる




         Developers Su...
依存の定義方法

•   パッケージによる依存定義
    –   Import-Package
•   Bundleによる依存定義
    –   Require-Bundle
•   それぞれ依存するバージョンを範囲で指
    定



...
バージョン (1)
定義方法
•   Mavenとはちょっと違うバージョン定義
•   メジャー.マイナー.パッチ.識別子
    –例:1.2.0.beta1
•   識別子には文字列が使える
    –ただし、識別子がついている方が上位とし...
バージョン (2)
範囲指定
•   「開区間」、「閉区間」、「暗黙」の3種
•   [1.0.0, 2.0.0] → 1.0.0 ≦バージョン
    ≦2.0.0
•   [1.0.0, 2.0.0) → 1.0.0 ≦バージョン<
   ...
バージョンの異なる
JAR への依存
•   java -cp a.jar b.jar c.jar a_v2.jar
•   (通常フラットなクラスパスの場合)

     app                  Ext           ...
バージョンの異なる
Bundle への依存
 •   OSGi環境下の場合
System           app                     Ext        Boot



             a          ...
OSGi の 3 大要素
モジュールシステム
動的 (Dynamic)
サービス連携
     http://www.flickr.com/photos/yourdon/2921734152/
Declartive Service
( サービスの宣言 : 利用側 )
 •   一部抜粋




            Developers Summit 2010
Declartive Service
( サービスの宣言:提供側 )
 •   一部抜粋




            Developers Summit 2010
Declartive Service
( サービスの宣言 )
 •   Consumer(要求側)とProvider(供給側)
 •   Consumerは、必要なIFを宣言
 •   Providerは供給できるIFと、実装を宣言

 •  ...
Declarative Service
( サービスの宣言 )
 •   実装間で相互運用可
     –   Declarative Service(XML/Annotation)
     –   Blueprint Service(Spr...
OSGi の 3 大要素
モジュールシステム
サービス連携
動的 (Dynamic)
     http://www.flickr.com/photos/yourdon/2921734152/
Dynamic

•   稼働中にBundleの構成を変更できる
•   →install,update,uninstall,start,stop,refresh
•   必要になったBundleを更新

•   →こんな事ができるのは、Bun...
四.Bundle設計の六つの勘どころ




      Developers Summit 2010
Bundle 設計の勘どころ
一 . 大きくしすぎない
•   大きくなったら分割を検討
•   →複数の役目を担当?
•   →新機能のためにライブラリ追加?
•   これらは大きくなる兆候です。




         Developer...
Bundle 設計の勘どころ
二 . 登録サービスを限定
•   複数のサービスを登録
•   →Bundleが複数の責務を担っている
•   Bundleが大きくなる兆候
•   Bundleを小さくするために
•   →登録サービスは限定す...
Bundle 設計の勘どころ
三 . 役割を明確に
•   3種別のBundle(by うじょさん)
•   API Bundle → インタフェースのみ
•   Library Bundle → これまでのJAR
•   Service Bu...
Bundle 設計の勘どころ
四 . 公開パッケージを限定する
•   他のBundle開発中の、間違えを防ぐ
    –   不要な依存を増やしやすい。
    –   依存が増える→独立性が悪化
    –   変更による影響を及ぼしやすく...
Bundle 設計の勘どころ
五 .Bundle= 独立したシステム
•    隣の芝生は青い
•    システムまたげばDRYは通用せず
    – 非公開クラスを利用
    – →コピーを検討
    – →別途Bundleにする
   ...
Bundle 設計の勘どころ
六 .Bundle をまたいだ継承、
静的参照は ×
•   期待した通りに動作しない事が多いです。
•   →デモ作成でハマりました。
•   →思い返すといい思い出がありません。
     – →publicな...
Bundle 設計の勘どころ
まとめ
•   一.大きくしすぎない
•   二.登録サービスを限定                   小さい
•   三.種別毎に分割する
•   四.公開パッケージを限定
•   五.Bundle=独立したシ...
まとめ:
複雑なシステム
→小さく・独
立・組み合わせ
  Developers Summit 2010
四.デモ
 Developers Summit 2010
こんぴろ書店 ( デブサミ支店 )
•     書籍登録
•     書籍検索
•     それぞれ別々のBundleで開発


    動的に切り替えます。Bundleが
    独立している事を実感してください。
    (開発環境:Spr...
初期構成
                            web.
  books.                             web
                           admin
  domain

...
一 .mock から impl に
                                web.
   books.                                web
                      ...
二 .mock と impl を共存
( システムの一部が旧バージョン )
                                web.
   books.                                web
  ...
五.OSGiがもたらす未来




   Developers Summit 2010
Polyglot( 多言語 )OSGi
                      System          G




        A                 B           C



        JRuby  ...
必要なサービスを必要な時に




   システムが能動的に取得
     Developers Summit 2010
参考文献




       Developers Summit 2010
本日盛り込まなかった内容

•   標準化
•   スクリプト言語との対応
•   実装毎の細かな差異
•   具体的なテスト方法(UnitTest等)




           Developers Summit 2010
まとめ:
複雑なシステム
→小さく・独
立・組み合わせ
  Developers Summit 2010
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-
Próximos SlideShares
Carregando em…5
×

成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-

3.706 visualizações

Publicada em

  • Seja o primeiro a comentar

成長できるエンタープライズシステムを目指して-OSGiによるモジュール型アーキテクチャの実現-

  1. 1. 成長できるエンタープライズシ ステムを目指して OSGi によるモジュール型アーキテクチャの実現 19-C-3 近藤寛喜 株式会社チェンジビジョン 開発部 Developers Summit 2010
  2. 2. 自己紹介
  3. 3. アジェンダ • システムを継続的に成長させるには? • OSGiとは? • Bundle設計の六個の勘どころ • デモ • OSGiがもたらす未来 Developers Summit 2010
  4. 4. 一.システムを持続的に  成長させるには? Developers Summit 2010
  5. 5. システムはそもそも複雑なもの http://www.flickr.com/photos/adc/411821495/
  6. 6. 複雑なシステムを わかりやすく構築するには どうしたらよいですか? Developers Summit 2010
  7. 7. 複雑なシステム を構成するには 複雑性を軽減す る仕組みが必要
  8. 8. オブジェクト指向も、構造化設計も 複雑性を軽減させる仕組み http://www.flickr.com/photos/procsilas/392877509/
  9. 9. •例: Eclipse 高い成長性を維持 Developers Summit 2010
  10. 10. Eclipseの成長の要因の一つは、 モジュール型アーキテクチャ にある Developers Summit 2010
  11. 11. モジュール型アーキテクチャ http://www.flickr.com/photos/37hz/1247083341/
  12. 12. スモールイズビューティフル http://www.flickr.com/photos/mdpettitt/2665598298/
  13. 13. スモールイズビューティフル • 柔軟な構成を取れる • 保守しやすい • 理解が簡単 • 再利用しやすい • … 等々 Developers Summit 2010
  14. 14. 普通の Java だったら・・・ http://www.flickr.com/photos/morberg/3146874095/
  15. 15. Q.JARで モジュールシステムを構成 できないの? Developers Summit 2010
  16. 16. A.できないことはないです。 でもモジュールとして維持するのが 大変。 Developers Summit 2010
  17. 17. Java のクラスロードモデル 依存 拡張 ブート クラスローダ クラスローダ JAR アプリケーションクラスローダ A B C G D E F Developers Summit 2010
  18. 18. つまり・・・ • JARをモジュールとして分離し、再利用 • →必要なJARが無い • →ClassNotFoundExceptionでクラッシュ JARには暗黙的な依存関係が存在 Developers Summit 2010
  19. 19. JARは依存する JARの情報を持 っていません
  20. 20. アプリケーション クラスローダの中 http://www.flickr.com/photos/shareski/3481154470/
  21. 21. APPクラスロー ダでは変更した 時の影響範囲が 分かりません
  22. 22. 再利用の二つの軸 空間軸 ( 機能 : ライブラリ等 ) 時間軸 Developers Summit 2010
  23. 23. 成長するシステ ムとは時間軸で の再利用ができ るシステムの事
  24. 24. 新しい要件に対 応する度にシス テムを全部更新 をしますよね?
  25. 25. 規模が大きくな るにつれ、どう なっていきます か?
  26. 26. システムを全部 更新する=影響 が分からないの で全テスト
  27. 27. ごちゃごちゃのシステム http://www.flickr.com/photos/joiseyshowaa/2402764792/
  28. 28. 見通しよく整理する http://www.flickr.com/photos/cheltenham/4100341188/
  29. 29. システムを分割 し、影響範囲を 限定するため独 立させたい
  30. 30. 依存情報があれ ば、依存情報か らテスト範囲を 限定できます
  31. 31. どうやって? http://www.flickr.com/photos/oddwick/1765661986/
  32. 32. •Eclipse の例 プロジェクト間の独立性と 依存関係の整理がキー Developers Summit 2010
  33. 33. まとめ: 複雑なシステム →小さく・独 立・組み合わせ Developers Summit 2010
  34. 34. モジュール型システムの問題 • 開発コスト – 意識しない時の3倍 • 独立性の担保 • 依存関係の整理 • 規模が小さい時は×     →例:設計したら1モジュール 使うべき場所を 見誤らないように 宮本武蔵・五輪書より 武器や流派にこだわるな Developers Summit 2010
  35. 35. 二.OSGiとは? Developers Summit 2010
  36. 36. OSGi とは • Open Service Gateway initiativeの略 • 「オープンなサービスゲートウェイの推進」 • Dynamic Module Systems for Java • Javaのための動的なモジュールシステム Developers Summit 2010
  37. 37. OSGi とは 黒船来航
  38. 38. 増える OSGi の利用例 • King of Java Application's infrastructure • By Neil Bartlett Developers Summit 2010
  39. 39. どんなところで有効なの? • 継続して成長させたいシステム – ツール – Webサービス – エンタープライズシステム • お客さん毎に違う機能セットを提供したい – パッケージのカスタム • プラグインシステムを提供したい Developers Summit 2010
  40. 40. OSGi の 3 大要素 モジュールシステム サービス連携 動的 ( Dynamic ) http://www.flickr.com/photos/yourdon/2921734152/
  41. 41. OSGi の 3 大要素 モジュールシステム サービス連携 動的 (Dynamic) http://www.flickr.com/photos/yourdon/2921734152/
  42. 42. OSGiを使って モジュールシステムを構築すると、 クラスローダの関係はこうなります。 Developers Summit 2010
  43. 43. OSGi のクラスロードモデル System G A B C JAR+メタデータ • Bundle(バンドル) D E F Developers Summit 2010
  44. 44. 利点 • 依存するBundleごと他のシステムへ – →Eclipseのプラグインのインストール • 依存の宣言がないBundle同士は分離 • →Bundle内の変更が他に影響しにくい • →Bundleごとに独立できる Developers Summit 2010
  45. 45. Bundle = JAR + メタデータ 今まで通りの環境でも使える Developers Summit 2010
  46. 46. 欠点 • 独自のクラスロード構造 – Class.forName()が使えない – →クラスローダが異なるクラスは読めない – リソースが読めない – →クラスローダが(同上) System G • 対処法: A B C • →クラスローダの入れ替え D E F Developers Summit 2010
  47. 47. OSGi のメタデータの 書き方一例 META-INF/MANIFEST.MFに記述  シンボル名:Bundle-SymbolicName  バージョン:Bundle-Version  依存関係   必要なパッケージ:Import-Package   公開パッケージ:Export-Package Developers Summit 2010
  48. 48. OSGi メタデータの 一例 Developers Summit 2010
  49. 49. メタデータがあるので・・・ • パッケージによる公開・非公開の制御 • JARに必要なパッケージの宣言 • →パッケージを公開しているJAR必要 • →依存関係を定義できる Developers Summit 2010
  50. 50. 依存の定義方法 • パッケージによる依存定義 – Import-Package • Bundleによる依存定義 – Require-Bundle • それぞれ依存するバージョンを範囲で指 定 Developers Summit 2010
  51. 51. バージョン (1) 定義方法 • Mavenとはちょっと違うバージョン定義 • メジャー.マイナー.パッチ.識別子 –例:1.2.0.beta1 • 識別子には文字列が使える –ただし、識別子がついている方が上位として認識 –例:1.2.0よりも、1.2.0.beta1の方が上位 • 定義されていない場合は0.0.0 Developers Summit 2010
  52. 52. バージョン (2) 範囲指定 • 「開区間」、「閉区間」、「暗黙」の3種 • [1.0.0, 2.0.0] → 1.0.0 ≦バージョン ≦2.0.0 • [1.0.0, 2.0.0) → 1.0.0 ≦バージョン< 2.0.0 • バージョン “1.*” を指す • 1 → [1.0.0, ∞) • 未指定 → [0.0.0, ∞) Developers Summit 2010
  53. 53. バージョンの異なる JAR への依存 • java -cp a.jar b.jar c.jar a_v2.jar • (通常フラットなクラスパスの場合) app Ext Boot a b c a2 先に宣言された JAR で解決 Developers Summit 2010
  54. 54. バージョンの異なる Bundle への依存 • OSGi環境下の場合 System app Ext Boot a a2 b c 宣言された Bundle で解決 Developers Summit 2010
  55. 55. OSGi の 3 大要素 モジュールシステム 動的 (Dynamic) サービス連携 http://www.flickr.com/photos/yourdon/2921734152/
  56. 56. Declartive Service ( サービスの宣言 : 利用側 ) • 一部抜粋 Developers Summit 2010
  57. 57. Declartive Service ( サービスの宣言:提供側 ) • 一部抜粋 Developers Summit 2010
  58. 58. Declartive Service ( サービスの宣言 ) • Consumer(要求側)とProvider(供給側) • Consumerは、必要なIFを宣言 • Providerは供給できるIFと、実装を宣言 • 特別なIF、アノテーションは不要 Developers Summit 2010
  59. 59. Declarative Service ( サービスの宣言 ) • 実装間で相互運用可 – Declarative Service(XML/Annotation) – Blueprint Service(Spring DM/Aries) – Google Guice Peaberry – iPOJO Developers Summit 2010
  60. 60. OSGi の 3 大要素 モジュールシステム サービス連携 動的 (Dynamic) http://www.flickr.com/photos/yourdon/2921734152/
  61. 61. Dynamic • 稼働中にBundleの構成を変更できる • →install,update,uninstall,start,stop,refresh • 必要になったBundleを更新 • →こんな事ができるのは、Bundleごとに独立 してるからこそ。 Developers Summit 2010
  62. 62. 四.Bundle設計の六つの勘どころ Developers Summit 2010
  63. 63. Bundle 設計の勘どころ 一 . 大きくしすぎない • 大きくなったら分割を検討 • →複数の役目を担当? • →新機能のためにライブラリ追加? • これらは大きくなる兆候です。 Developers Summit 2010
  64. 64. Bundle 設計の勘どころ 二 . 登録サービスを限定 • 複数のサービスを登録 • →Bundleが複数の責務を担っている • Bundleが大きくなる兆候 • Bundleを小さくするために • →登録サービスは限定する Developers Summit 2010
  65. 65. Bundle 設計の勘どころ 三 . 役割を明確に • 3種別のBundle(by うじょさん) • API Bundle → インタフェースのみ • Library Bundle → これまでのJAR • Service Bundle → サービス登録/利用 • その他 – Mock Bundle → API Bundleを空実装 Developers Summit 2010
  66. 66. Bundle 設計の勘どころ 四 . 公開パッケージを限定する • 他のBundle開発中の、間違えを防ぐ – 不要な依存を増やしやすい。 – 依存が増える→独立性が悪化 – 変更による影響を及ぼしやすくする。 非公開パッケージ名の規約として、パ ッケージ名を”*.internal.*”と明示 Developers Summit 2010
  67. 67. Bundle 設計の勘どころ 五 .Bundle= 独立したシステム • 隣の芝生は青い • システムまたげばDRYは通用せず – 非公開クラスを利用 – →コピーを検討 – →別途Bundleにする – 良い垣根は良いお隣さんを育む – By Jeff Mcaffer Developers Summit 2010
  68. 68. Bundle 設計の勘どころ 六 .Bundle をまたいだ継承、 静的参照は × • 期待した通りに動作しない事が多いです。 • →デモ作成でハマりました。 • →思い返すといい思い出がありません。 – →publicなのに、参照できず落ちる • →やろうと思えばやれる=バッドノウハウ Developers Summit 2010
  69. 69. Bundle 設計の勘どころ まとめ • 一.大きくしすぎない • 二.登録サービスを限定 小さい • 三.種別毎に分割する • 四.公開パッケージを限定 • 五.Bundle=独立したシステム 独立 • 六.不要な継承、静的参照はしない Developers Summit 2010
  70. 70. まとめ: 複雑なシステム →小さく・独 立・組み合わせ Developers Summit 2010
  71. 71. 四.デモ Developers Summit 2010
  72. 72. こんぴろ書店 ( デブサミ支店 ) • 書籍登録 • 書籍検索 • それぞれ別々のBundleで開発 動的に切り替えます。Bundleが 独立している事を実感してください。 (開発環境:Spring DM(1.2.1)+Maven) http://github.com/kompiro/osgi-demo-bookstore.git Developers Summit 2010
  73. 73. 初期構成 web. books. web admin domain books 依存 books mock サービス System 提供 Developers Summit 2010
  74. 74. 一 .mock から impl に web. books. web admin domain books books books mock 2 依存 books サービス impl System 提供 Developers Summit 2010
  75. 75. 二 .mock と impl を共存 ( システムの一部が旧バージョン ) web. books. web admin domain books books books mock 2 依存 books サービス impl System 提供 Developers Summit 2010
  76. 76. 五.OSGiがもたらす未来 Developers Summit 2010
  77. 77. Polyglot( 多言語 )OSGi System G A B C JRuby Scala Groovy Developers Summit 2010
  78. 78. 必要なサービスを必要な時に システムが能動的に取得 Developers Summit 2010
  79. 79. 参考文献 Developers Summit 2010
  80. 80. 本日盛り込まなかった内容 • 標準化 • スクリプト言語との対応 • 実装毎の細かな差異 • 具体的なテスト方法(UnitTest等) Developers Summit 2010
  81. 81. まとめ: 複雑なシステム →小さく・独 立・組み合わせ Developers Summit 2010

×