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

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

19-C-3 近藤寛喜
株式会社チェンジビジョン
開発部

Developers Summit 2010

アジェンダ

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


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


システムはそもそも複雑なもの

http://www.flickr.com/photos/adc/411821495/

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


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

オブジェクト指向も、構造化設計も
複雑性を軽減させる仕組み

http://www.flickr.com/photos/procsilas/392877509/

•例： Eclipse

高い成長性を維持


Eclipseの成長の要因の一つは、

モジュール型アーキテクチャ
にある


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

スモールイズビューティフル

http://www.flickr.com/photos/mdpettitt/2665598298/

スモールイズビューティフル

• 柔軟な構成を取れる
• 保守しやすい
• 理解が簡単
• 再利用しやすい
• … 等々


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

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


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


Java のクラスロードモデル
依存拡張ブート
クラスローダクラスローダ
JAR

アプリケーションクラスローダ

A B C

G
D
E F


つまり・・・

• JARをモジュールとして分離し、再利用
• →必要なJARが無い
• →ClassNotFoundExceptionでクラッシュ

JARには暗黙的な依存関係が存在


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/

•Eclipse の例

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


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

モジュール型システムの問題

• 開発コスト
– 意識しない時の3倍
• 独立性の担保
• 依存関係の整理
• 規模が小さい時は×
　　　　→例:設計したら1モジュール

使うべき場所を
見誤らないように宮本武蔵・五輪書より
武器や流派にこだわるな

二.OSGiとは？


OSGi とは

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


OSGi とは

黒船来航

増える OSGi の利用例

• King of Java Application's infrastructure
• By Neil Bartlett

どんなところで有効なの？

• 継続して成長させたいシステム
– ツール
– Webサービス
– エンタープライズシステム
• お客さん毎に違う機能セットを提供したい
– パッケージのカスタム
• プラグインシステムを提供したい


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

サービス連携
動的 (Dynamic)

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


OSGi のクラスロードモデル
System G

A B C

JAR+メタデータ
• Bundle(バンドル) D E F


利点

• 依存するBundleごと他のシステムへ
– →Eclipseのプラグインのインストール

• 依存の宣言がないBundle同士は分離
• →Bundle内の変更が他に影響しにくい
• →Bundleごとに独立できる


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


欠点

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

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


OSGi メタデータの
一例


メタデータがあるので・・・

• パッケージによる公開・非公開の制御
• JARに必要なパッケージの宣言
• →パッケージを公開しているJAR必要
• →依存関係を定義できる


依存の定義方法

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


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


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

バージョンの異なる
JAR への依存
• java -cp a.jar b.jar c.jar a_v2.jar
• (通常フラットなクラスパスの場合)

app Ext Boot

a b c a2

先に宣言された JAR で解決 Developers Summit 2010

バージョンの異なる
Bundle への依存
• OSGi環境下の場合
System app Ext Boot

a a2

b c

宣言された Bundle で解決

動的 (Dynamic)
サービス連携

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


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


Declartive Service
( サービスの宣言 )
• Consumer(要求側)とProvider(供給側)
• Consumerは、必要なIFを宣言
• Providerは供給できるIFと、実装を宣言

• 特別なIF、アノテーションは不要


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


Dynamic

• 稼働中にBundleの構成を変更できる
• →install,update,uninstall,start,stop,refresh
• 必要になったBundleを更新

• →こんな事ができるのは、Bundleごとに独立
してるからこそ。


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


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


二 . 登録サービスを限定
• 複数のサービスを登録
• →Bundleが複数の責務を担っている
• Bundleが大きくなる兆候
• Bundleを小さくするために
• →登録サービスは限定する


三 . 役割を明確に
• 3種別のBundle(by うじょさん)
• API Bundle → インタフェースのみ
• Library Bundle → これまでのJAR
• Service Bundle → サービス登録/利用

• その他
– Mock Bundle → API Bundleを空実装


四 . 公開パッケージを限定する
• 他のBundle開発中の、間違えを防ぐ
– 不要な依存を増やしやすい。
– 依存が増える→独立性が悪化
– 変更による影響を及ぼしやすくする。

非公開パッケージ名の規約として、パ
ッケージ名を”*.internal.*”と明示


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


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


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


四.デモ

こんぴろ書店 ( デブサミ支店 )
• 書籍登録
• 書籍検索
• それぞれ別々のBundleで開発

動的に切り替えます。Bundleが
独立している事を実感してください。
(開発環境:Spring DM(1.2.1)+Maven)
http://github.com/kompiro/osgi-demo-bookstore.git

初期構成
web.
books. web
admin
domain

books

依存
books
mock サービス
System 提供


一 .mock から impl に
web.
books. web
admin
domain

books books books
mock 2
依存
books
サービス
impl System 提供


二 .mock と impl を共存
( システムの一部が旧バージョン )
web.
books. web
admin
domain

books books books
mock 2
依存
books
サービス
impl System 提供


五.OSGiがもたらす未来


Polyglot( 多言語 )OSGi
System G

A B C

JRuby Scala Groovy


必要なサービスを必要な時に

システムが能動的に取得

参考文献


本日盛り込まなかった内容

• 標準化
• スクリプト言語との対応
• 実装毎の細かな差異
• 具体的なテスト方法(UnitTest等)


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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

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

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

Plus de Hiroki Kondo

Plus de Hiroki Kondo (20)

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

Notes de l'éditeur