1. 成長できるエンタープライズシステムを目指して OSGi によるモジュール型アーキテクチャの実現 近藤寛喜 株式会社チェンジビジョン 開発部 19-C-3

3. 自己紹介

4. [ 宣伝 / お仕事 ]astah* ブースへお立ち寄りください astah* community ブースありマス。 3/31 まで動く特別評価版進呈中 お手元のチラシをご覧ください

5. アジェンダ システムを継続的に成長させるには？ OSGi とは？ Bundle 設計の六個の勘どころ デモ OSGi がもたらす未来

6. 一 . システムを持続的に 成長させるには？

7. システムはそもそも複雑なもの http://www.flickr.com/photos/adc/411821495/

8. 複雑なシステムを わかりやすく構築するには どうしたらよいですか？

9. 複雑なシステムを構成するには 複雑性を 軽減する仕組み が必要

10. オブジェクト指向も、構造化設計も 複雑性を軽減させる仕組み http://www.flickr.com/photos/procsilas/392877509/

11. 例： Eclipse 高い成長性を維持

12. Eclipse の成長の要因の一つは、 モジュール型アーキテクチャ にある

13. モジュール型アーキテクチャ http://www.flickr.com/photos/37hz/1247083341/

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

15. スモールイズビューティフル 柔軟な構成を取れる 保守しやすい 理解が簡単 再利用しやすい … 等々

16. 普通の Java だったら・・・ http://www.flickr.com/photos/morberg/3146874095/

17. Q.JAR で モジュールシステムを構成 できないの？

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

19. Java のクラスロードモデル ブート クラスローダ A B C D E F G 拡張 クラスローダ アプリケーションクラスローダ JAR 依存

20. つまり・・・ JAR をモジュールとして分離し、 再利用 -> 必要な JAR が無い -> ClassNotFoundException でクラッシュ JAR には暗黙的な依存関係が存在

21. JAR は 依存する JAR の情報 を持っていません

22. アプリケーション クラスローダの中 http://www.flickr.com/photos/shareski/3481154470/

23. APP クラスローダでは 変更した時の影響範囲 が分かりません

24. 再利用の二つの軸 時間軸 空間軸 ( 機能 : ライブラリ等 )

25. 成長するシステム とは 時間軸での再利用 ができるシステムの事

26. 新しい要件 に対応する度に システムを全部更新 をしますよね？

27. 規模が大きく なるにつれ、どうなっていきますか？

28. システムを全部更新 する＝ 影響が分からないので 全テスト

29. ごちゃごちゃのシステム http://www.flickr.com/photos/joiseyshowaa/2402764792/

30. 見通しよく整理する http://www.flickr.com/photos/cheltenham/4100341188/

31. システムを分割 し、影響範囲を限定するため 独立 させたい

32. 依存情報があれば 、依存情報から テスト範囲を限定できます

33. どうやって？ http://www.flickr.com/photos/oddwick/1765661986/

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

35. まとめ： 複雑なシステム-> 小さく ・ 独立 ・ 組み合わせ

36. モジュール型システムの問題 開発コスト 意識しない時の 3 倍 独立性の担保 依存関係の整理 規模が小さい時は × ->例 : 設計したら 1 モジュール 宮本武蔵・五輪書より 武器や流派にこだわるな 使うべき場所を 見誤らないように

37. 二 .OSGi とは？

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

39. OSGi とは 黒船来航

40. 増える OSGi の利用例 King of Java Application's infrastructure By Neil Bartlett

41. どんなところで有効なの？ 継続して成長させたいシステム ツール Web サービス エンタープライズシステム お客さん毎に違う機能セットを提供したい パッケージのカスタム プラグインシステムを提供したい

42. OSGi の 3 大要素 モジュールシステム サービス連携 動的 ( Dynamic ) http://www.flickr.com/photos/yourdon/2921734152/

43. OSGi の 3 大要素 モジュールシステム サービス連携 動的 (Dynamic) http://www.flickr.com/photos/yourdon/2921734152/

44. OSGi を使って モジュールシステムを構築すると、 クラスローダの関係はこうなります。

45. OSGi のクラスロードモデル System A B C D E F JAR+ メタデータ Bundle( バンドル ) G

46. 利点 依存する Bundle ごと他のシステムへ -> Eclipse のプラグインのインストール 依存の宣言がない Bundle 同士は分離 -> Bundle 内の変更が他に影響しにくい -> Bundle ごとに 独立できる

47. Bundle = JAR + メタデータ 今まで通りの環境でも使える

48. 欠点 独自のクラスロード構造 Class.forName() が使えない -> クラスローダが異なるクラスは読めない リソースが読めない -> クラスローダが ( 同上 ) 対処法 : -> クラスローダの入れ替え System A B C D E F G

49. OSGi のメタデータの 書き方一例 META-INF/MANIFEST.MF に記述 シンボル名 :Bundle-SymbolicName バージョン :Bundle-Version 依存関係 必要なパッケージ :Import-Package 公開パッケージ :Export-Package

50. OSGi メタデータの 一例

51. メタデータがあるので・・・ パッケージによる公開・非公開の制御 JAR に必要なパッケージの宣言 -> パッケージを公開している JAR 必要 -> 依存関係を定義 できる

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

53. バージョン (1) 定義方法 Maven とはちょっと違うバージョン定義 メジャー . マイナー . パッチ . 識別子 例 :1.2.0.beta1 識別子には文字列が使える ただし、識別子がついている方が上位として認識 例： 1.2.0 よりも、 1.2.0.beta1 の方が上位 定義されていない場合は 0.0.0

54. バージョン (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, ∞)

55. バージョンの異なる JAR への依存 java -cp a.jar b.jar c.jar a_v2.jar ( 通常フラットなクラスパスの場合 ) 先に宣言された JAR で解決 app a Ext Boot b c a2

56. バージョンの異なる Bundle への依存 OSGi 環境下の場合 宣言された Bundle で解決 app a Ext Boot b c a2 System

57. OSGi の 3 大要素 モジュールシステム 動的 (Dynamic) サービス連携 http://www.flickr.com/photos/yourdon/2921734152/

58. Declartive Service ( サービスの宣言 : 利用側 ) 一部抜粋

59. Declartive Service ( サービスの宣言：提供側 ) 一部抜粋

60. Declartive Service ( サービスの宣言 ) Consumer( 要求側 ) と Provider( 供給側 ) Consumer は、必要な IF を宣言 Provider は供給できる IF と、実装を宣言 特別な IF 、アノテーションは不要

61. Declarative Service ( サービスの宣言 ) 実装間で相互運用可 Declarative Service(XML/Annotation) Blueprint Service(Spring DM/Aries) Google Guice Peaberry iPOJO

62. OSGi の 3 大要素 モジュールシステム サービス連携 動的 (Dynamic) http://www.flickr.com/photos/yourdon/2921734152/

63. Dynamic 稼働中に Bundle の構成を変更できる -> install,update,uninstall,start,stop,refresh 必要になった Bundle を更新 -> こんな事ができるのは、 Bundle ごとに 独立 してるからこそ。

64. 四 .Bundle 設計の六つの勘どころ

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

66. Bundle 設計の勘どころ 二 . 登録サービスを限定 複数のサービスを登録 -> Bundle が複数の責務を担っている Bundle が大きくなる兆候 Bundle を小さくするために -> 登録サービスは限定する

67. Bundle 設計の勘どころ 三 . 役割を明確に 3 種別の Bundle(by うじょさん ) API Bundle -> インタフェースのみ Library Bundle -> これまでの JAR Service Bundle -> サービス登録 / 利用 その他 Mock Bundle -> API Bundle を空実装

68. Bundle 設計の勘どころ 四 . 公開パッケージを限定する 他の Bundle 開発中の、間違えを防ぐ 不要な依存を増やしやすい。 依存が増える->独立性が悪化 変更による影響を及ぼしやすくする。 非公開パッケージ名の規約として、パッケージ名を ” *.internal.*” と明示

69. Bundle 設計の勘どころ 五 .Bundle= 独立したシステム 隣の芝生は青い システムまたげば DRY は通用せず 非公開クラスを利用 -> コピーを検討 -> 別途 Bundle にする 良い垣根は良いお隣さんを育む By Jeff Mcaffer

70. Bundle 設計の勘どころ 六 .Bundle をまたいだ継承、静的参照は × 期待した通りに動作しない事が多いです。 -> デモ作成でハマりました。 -> 思い返すといい思い出がありません。 -> public なのに、参照できず落ちる -> やろうと思えばやれる = バッドノウハウ

71. Bundle 設計の勘どころ まとめ 一 . 大きくしすぎない 二 . 登録サービスを限定 三 . 種別毎に分割する 四 . 公開パッケージを限定 五 .Bundle= 独立したシステム 六 . 不要な継承、静的参照はしない 小さい 独立

72. まとめ： 複雑なシステム-> 小さく ・ 独立 ・ 組み合わせ

73. 四 . デモ

74. こんぴろ書店 ( デブサミ支店 ) 書籍登録 書籍検索 それぞれ別々の Bundle で開発 動的に切り替えます。 Bundle が 独立している事を実感してください。 ( 開発環境 :Spring DM(1.2.1)+Maven) http://github.com/kompiro/osgi-demo-bookstore.git

75. 初期構成 System books books mock web. admin web books. domain 依存 サービス 提供

76. 一 .mock から impl に System books books mock web. admin web books. domain 依存 サービス 提供 books impl books 2

77. 二 .mock と impl を共存 ( システムの一部が旧バージョン ) System books books mock web. admin web books. domain 依存 サービス 提供 books impl books 2

78. 五 .OSGi がもたらす未来

79. Polyglot( 多言語 )OSGi System A B C JRuby Scala Groovy G

80. 必要なサービスを必要な時に システムが能動的に取得

81. 参考文献

82. 本日盛り込まなかった内容 標準化 スクリプト言語との対応 実装毎の細かな差異 具体的なテスト方法 (UnitTest 等 )

83. まとめ： 複雑なシステム-> 小さく ・ 独立 ・ 組み合わせ