成長できるエンタープライズシステムを目指して OSGi によるモジュール型アーキテクチャの実現 近藤寛喜 株式会社チェンジビジョン 開発部 19-C-3
 
自己紹介
[ 宣伝 / お仕事 ]astah* ブースへお立ち寄りください <ul><li>astah* community ブースありマス。 </li></ul>3/31 まで動く特別評価版進呈中 お手元のチラシをご覧ください
アジェンダ <ul><li>システムを継続的に成長させるには? </li></ul><ul><li>OSGi とは? </li></ul><ul><li>Bundle 設計の六個の勘どころ </li></ul><ul><li>デモ </li><...
一 . システムを持続的に  成長させるには?
システムはそもそも複雑なもの http://www.flickr.com/photos/adc/411821495/
複雑なシステムを わかりやすく構築するには どうしたらよいですか?
複雑なシステムを構成するには 複雑性を 軽減する仕組み が必要
オブジェクト指向も、構造化設計も 複雑性を軽減させる仕組み http://www.flickr.com/photos/procsilas/392877509/
<ul><li>例: Eclipse </li></ul>高い成長性を維持
Eclipse の成長の要因の一つは、 モジュール型アーキテクチャ にある
モジュール型アーキテクチャ http://www.flickr.com/photos/37hz/1247083341/
スモールイズビューティフル http://www.flickr.com/photos/mdpettitt/2665598298/
スモールイズビューティフル <ul><li>柔軟な構成を取れる </li></ul><ul><li>保守しやすい </li></ul><ul><li>理解が簡単 </li></ul><ul><li>再利用しやすい </li></ul><ul><...
普通の Java だったら・・・ http://www.flickr.com/photos/morberg/3146874095/
Q.JAR で モジュールシステムを構成 できないの?
A. できないことはないです。 でもモジュールとして維持するのが大変。
Java のクラスロードモデル ブート クラスローダ A B C D E F G 拡張 クラスローダ アプリケーションクラスローダ JAR 依存
つまり・・・ <ul><li>JAR をモジュールとして分離し、 再利用 </li></ul><ul><li>-> 必要な JAR が無い </li></ul><ul><li>-> ClassNotFoundException でクラッシュ <...
JAR は 依存する JAR の情報 を持っていません
アプリケーション クラスローダの中 http://www.flickr.com/photos/shareski/3481154470/
APP クラスローダでは 変更した時の影響範囲 が分かりません
再利用の二つの軸 時間軸 空間軸 ( 機能 : ライブラリ等 )
成長するシステム とは 時間軸での再利用 ができるシステムの事
新しい要件 に対応する度に システムを全部更新 をしますよね?
規模が大きく なるにつれ、どうなっていきますか?
システムを全部更新 する= 影響が分からないので 全テスト
ごちゃごちゃのシステム http://www.flickr.com/photos/joiseyshowaa/2402764792/
見通しよく整理する http://www.flickr.com/photos/cheltenham/4100341188/
システムを分割 し、影響範囲を限定するため 独立 させたい
依存情報があれば 、依存情報から テスト範囲を限定できます
どうやって? http://www.flickr.com/photos/oddwick/1765661986/
<ul><li>Eclipse の例 </li></ul>プロジェクト間の独立性と 依存関係の整理がキー
まとめ: 複雑なシステム-> 小さく ・ 独立 ・ 組み合わせ
モジュール型システムの問題 <ul><li>開発コスト </li></ul><ul><ul><li>意識しない時の 3 倍 </li></ul></ul><ul><ul><ul><li>独立性の担保 </li></ul></ul></ul><u...
二 .OSGi とは?
OSGi とは <ul><li>Open Service Gateway initiative の略 </li></ul><ul><li>「オープンなサービスゲートウェイの推進」 </li></ul><ul><li>Dynamic  Modul...
OSGi とは <ul><li>黒船来航 </li></ul>
増える OSGi の利用例 <ul><li>King of Java Application's infrastructure </li></ul><ul><li>By Neil Bartlett </li></ul>
どんなところで有効なの? <ul><li>継続して成長させたいシステム </li></ul><ul><ul><li>ツール </li></ul></ul><ul><ul><li>Web サービス </li></ul></ul><ul><ul><...
OSGi の 3 大要素 モジュールシステム サービス連携 動的 ( Dynamic ) http://www.flickr.com/photos/yourdon/2921734152/
OSGi の 3 大要素 モジュールシステム サービス連携 動的 (Dynamic) http://www.flickr.com/photos/yourdon/2921734152/
OSGi を使って モジュールシステムを構築すると、 クラスローダの関係はこうなります。
OSGi のクラスロードモデル System A B C D E F <ul><li>JAR+ メタデータ </li></ul><ul><li>Bundle( バンドル ) </li></ul>G
利点 <ul><li>依存する Bundle ごと他のシステムへ </li></ul><ul><ul><li>-> Eclipse のプラグインのインストール </li></ul></ul><ul><li>依存の宣言がない Bundle 同士は...
Bundle =  JAR  +  メタデータ 今まで通りの環境でも使える
欠点 <ul><li>独自のクラスロード構造 </li></ul><ul><ul><li>Class.forName() が使えない </li></ul></ul><ul><ul><li>-> クラスローダが異なるクラスは読めない </li><...
OSGi のメタデータの 書き方一例 <ul><li>META-INF/MANIFEST.MF に記述 </li></ul><ul><li> シンボル名 :Bundle-SymbolicName </li></ul><ul><li> バージョン...
OSGi メタデータの 一例
メタデータがあるので・・・ <ul><li>パッケージによる公開・非公開の制御 </li></ul><ul><li>JAR に必要なパッケージの宣言 </li></ul><ul><li>-> パッケージを公開している JAR 必要 </li><...
依存の定義方法 <ul><li>パッケージによる依存定義 </li></ul><ul><ul><li>Import-Package </li></ul></ul><ul><li>Bundle による依存定義 </li></ul><ul><ul>...
バージョン (1) 定義方法 <ul><li>Maven とはちょっと違うバージョン定義 </li></ul><ul><li>メジャー . マイナー . パッチ . 識別子 </li></ul><ul><ul><li>例 :1.2.0.beta...
バージョン (2) 範囲指定 <ul><li>「開区間」、「閉区間」、「暗黙」の 3 種 </li></ul><ul><li>[1.0.0, 2.0.0]  ->  1.0.0 ≦ バージョン≦ 2.0.0 </li></ul><ul><li>...
バージョンの異なる JAR への依存 <ul><li>java -cp a.jar b.jar c.jar a_v2.jar </li></ul><ul><li>( 通常フラットなクラスパスの場合 ) </li></ul>先に宣言された JAR...
バージョンの異なる Bundle への依存 <ul><li>OSGi 環境下の場合 </li></ul>宣言された Bundle で解決 app a Ext Boot b c a2 System
OSGi の 3 大要素 モジュールシステム 動的 (Dynamic) サービス連携 http://www.flickr.com/photos/yourdon/2921734152/
Declartive Service ( サービスの宣言 : 利用側 ) <ul><li>一部抜粋 </li></ul>
Declartive Service ( サービスの宣言:提供側 ) <ul><li>一部抜粋 </li></ul>
Declartive Service ( サービスの宣言 ) <ul><li>Consumer( 要求側 ) と Provider( 供給側 ) </li></ul><ul><li>Consumer は、必要な IF を宣言 </li></ul...
Declarative Service ( サービスの宣言 ) <ul><li>実装間で相互運用可 </li></ul><ul><ul><li>Declarative Service(XML/Annotation) </li></ul></ul...
OSGi の 3 大要素 モジュールシステム サービス連携 動的 (Dynamic) http://www.flickr.com/photos/yourdon/2921734152/
Dynamic <ul><li>稼働中に Bundle の構成を変更できる </li></ul><ul><li>-> install,update,uninstall,start,stop,refresh </li></ul><ul><li>必...
四 .Bundle 設計の六つの勘どころ
Bundle 設計の勘どころ 一 . 大きくしすぎない <ul><li>大きくなったら分割を検討 </li></ul><ul><li>-> 複数の役目を担当? </li></ul><ul><li>-> 新機能のためにライブラリ追加 ? </li...
Bundle 設計の勘どころ 二 . 登録サービスを限定 <ul><li>複数のサービスを登録 </li></ul><ul><li>-> Bundle が複数の責務を担っている </li></ul><ul><li>Bundle が大きくなる兆候...
Bundle 設計の勘どころ 三 . 役割を明確に <ul><li>3 種別の Bundle(by  うじょさん ) </li></ul><ul><li>API Bundle ->  インタフェースのみ </li></ul><ul><li>Li...
Bundle 設計の勘どころ 四 . 公開パッケージを限定する <ul><li>他の Bundle 開発中の、間違えを防ぐ </li></ul><ul><ul><li>不要な依存を増やしやすい。 </li></ul></ul><ul><ul><...
Bundle 設計の勘どころ 五 .Bundle= 独立したシステム <ul><li>隣の芝生は青い </li></ul><ul><li>システムまたげば DRY は通用せず </li></ul><ul><ul><li>非公開クラスを利用 </...
Bundle 設計の勘どころ 六 .Bundle をまたいだ継承、静的参照は × <ul><li>期待した通りに動作しない事が多いです。 </li></ul><ul><li>-> デモ作成でハマりました。 </li></ul><ul><li>-...
Bundle 設計の勘どころ まとめ <ul><li>一 . 大きくしすぎない </li></ul><ul><li>二 . 登録サービスを限定 </li></ul><ul><li>三 . 種別毎に分割する </li></ul><ul><li>四...
まとめ: 複雑なシステム-> 小さく ・ 独立 ・ 組み合わせ
四 . デモ
こんぴろ書店 ( デブサミ支店 ) <ul><li>書籍登録 </li></ul><ul><li>書籍検索 </li></ul><ul><li>それぞれ別々の Bundle で開発 </li></ul>動的に切り替えます。 Bundle が 独...
初期構成 System books books mock web. admin web books. domain 依存 サービス 提供
一 .mock から impl に System books books mock web. admin web books. domain 依存 サービス 提供 books impl books 2
二 .mock と impl を共存 ( システムの一部が旧バージョン ) System books books mock web. admin web books. domain 依存 サービス 提供 books impl books 2
五 .OSGi がもたらす未来
Polyglot( 多言語 )OSGi System A B C JRuby Scala Groovy G
必要なサービスを必要な時に <ul><li>システムが能動的に取得 </li></ul>
参考文献
本日盛り込まなかった内容 <ul><li>標準化 </li></ul><ul><li>スクリプト言語との対応 </li></ul><ul><li>実装毎の細かな差異 </li></ul><ul><li>具体的なテスト方法 (UnitTest 等...
まとめ: 複雑なシステム-> 小さく ・ 独立 ・ 組み合わせ
 
Upcoming SlideShare
Loading in …5
×

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

1,401 views
1,346 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,401
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

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

    ×