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

3,368 views
3,245 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,368
On SlideShare
0
From Embeds
0
Number of Embeds
290
Actions
Shares
0
Downloads
116
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • システムをいくつかのモジュールに分割 モジュールを組み合わせてシステムを構築 -> 「 Modularity 」 モジュール毎に独自に発展が可能 -> インタフェースに互換があれば OK -> モジュールごとにパフォーマンス改善 構成要素によって、振る舞いを変えられる
  • 前の話とつながりが悪い . サービスの連携 ( 宣言敵に )
  • 前の話とつながりが悪い . サービスの連携 ( 宣言敵に )
  • 前の話とつながりが悪い . サービスの連携 ( 宣言敵に )
  • Declartive Service とは、 Bundle からシステムに対し、どういうサービスが必要なのか、はたまたどういうサービスを提供できるのか、宣言するというものです。ピンと来た方も大勢いらっしゃるとおもいますが、この考え方は DI 、依存性を注入する、というところに非常に近いものと言えるでしょう。言い換えると、 Bundle がどういうサービスに依存していて、どういうサービスが提供できるのか、を宣言するわけです。 依存するサービスはインタフェースでの宣言、実装は POJO というあたりも DI と同じです。 Di との違いは、あくまで DI は静的な条件で行われるもので、起動時に構築された県連性は、変更できませんが、 Declartive Service では、宣言も含め動的に変更できます。インタフェースに基づく開発
  • Declartive Service とは、 Bundle からシステムに対し、どういうサービスが必要なのか、はたまたどういうサービスを提供できるのか、宣言するというものです。ピンと来た方も大勢いらっしゃるとおもいますが、この考え方は DI 、依存性を注入する、というところに非常に近いものと言えるでしょう。言い換えると、 Bundle がどういうサービスに依存していて、どういうサービスが提供できるのか、を宣言するわけです。 依存するサービスはインタフェースでの宣言、実装は POJO というあたりも DI と同じです。 Di との違いは、あくまで DI は静的な条件で行われるもので、起動時に構築された県連性は、変更できませんが、 Declartive Service では、宣言も含め動的に変更できます。インタフェースに基づく開発
  • 前の話とつながりが悪い . サービスの連携 ( 宣言敵に )
  • バージョンをあげると、動かなくなる例
  • 成長できるエンタープライズシステムを目指して-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

    ×