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