Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
成長できるエンタープライズシステムを目指して 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,416 views

Published on

  • Be the first to comment

  • Be the first to like this

成長できるエンタープライズシステムを目指して-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. まとめ: 複雑なシステム-> 小さく ・ 独立 ・ 組み合わせ

×