Upload Login /
...

アナウンスメント・ワークショップ アプリケーション WebSphere Application Server V8.0

by user

on
Category: Documents
>> Downloads: 2
11

views

Report

Comments

Description

Transcript

アナウンスメント・ワークショップ アプリケーション WebSphere Application Server V8.0
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
®
WebSphere Application Server V8.0
アナウンスメント・ワークショップ
OSGiアプリケーション
© 2011 IBM Corporation
1
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
1
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Disclaimer
ƒ この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エム システムズ・エ
ンジニアリング株式会社の正式なレビューを受けておりません。
ƒ 当資料は、資料内で説明されている製品の仕様を保証するものではありません。
ƒ 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2011年7月
現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能
性があるのでご注意下さい。
ƒ 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。
ƒ IBM、IBMロゴ、ibm.comおよびWebShereは、世界の多くの国で登録された
International Business Machines Corporationの商標です。他の製品名およびサービ
ス名等は、それぞれIBMまたは各社の商標である場合があります。現時点でのIBMの
商標リストについては、http://www.ibm.com/legal/copytrade.shtmlをご覧ください。
ƒ JavaおよびすべてのJava関連の商標は Oracleやその関連会社の米国およびその他
の国における商標または登録商標です。
© 2011 IBM Corporation
2
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
2
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Agenda
ƒOSGi & Enterprise OSGi概要
–OSGi登場の背景
–OSGiの歴史と現状
–OSGiのコア機能
–Enterprise OSGi
ƒOSGiの使いどころ
–OSGiが効果を発揮するケース
–OSGi適用時の考慮点
ƒWAS V8.0のOSGi対応
–アプリケーション開発とパッケージング
–運用管理
© 2011 IBM Corporation
3
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
3
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGi & Enterprise OSGi概要
© 2011 IBM Corporation
4
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
4
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiとは?
ƒ モジュール化(コンポーネント化)を行うための技術の一つ
ƒ Javaにおける完全なモジュールシステムを実現
–特に、ランタイムにおけるモジュール化の弱点を補強するもの
ƒ モジュールは「OSGiバンドル」として構成する
–設計・開発者や運用管理者には、OSGiに関する知識が必要
© 2011 IBM Corporation
5
WAS V8.0 アナウンスメント・ワークショップ
OSGiはアプリケーションをソフトウェア・モジュールの組合せとして構築するための基盤であり、
Javaを拡張するための仕様として標準化されています。
特に、Javaのランタイム環境におけるモジュールシステムの弱点を強化するものという位置づけに
なります。
OSGiにおけるモジュールは「OSGiバンドル」として規定されています。
OSGiベースのシステムを構築する場合、ソフトウェア・モジュールはアプリケーション・ライフサイク
ル全般において「バンドル」として管理されますので、設計者・開発者はもちろんですが、運用管理
者にもOSGiについてのスキルが求められます。
WAS V8.0 アナウンスメント・ワークショップ
5
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
コンポーネント指向(モジュール指向)プラットフォームの要件
ƒ モジュール境界が定義できること
–外部に公開するインターフェース
–モジュールに閉じたリソース
–物理的なパッケージングの仕様
ƒ モジュール間の依存性管理が可能であること
–依存先モジュールの明示
–モジュールのバージョン管理
–依存関係の解決
ƒ モジュールのライフサイクル管理が可能であること
–インストール/アンインストール
–開始/停止
–ライフサイクル・イベントへの対応
© 2011 IBM Corporation
6
WAS V8.0 アナウンスメント・ワークショップ
なぜOSGiが注目されているのかを考えるにあたって、コンポーネント指向(モジュール指向)のアプリ
ケーション・プラットフォームについて考えてみましょう。
アプリケーションを再利用可能なモジュールの組合せとして構築する場合、モジュールを稼働させる
ための基盤が必要となります。
一般に、この基盤に求められる要件は以下のようになります。
(1)モジュール境界の定義
モジュールの独立性を高めるため、モジュールの内部と外部を分離し、モジュールの内部状態が外
部に影響を与えないようにします。
モジュールの物理的な形態に関する取り決めも必要です。
(2)モジュールの依存性管理
システム全体での整合性を保証するため、モジュール自身のバージョン管理や、モジュール間での
バージョンを含む依存関係を管理できる必要があります。
(3)モジュールのライフサイクル管理
モジュールが自律的に動作するためには、モジュールのライフサイクル(状態)を管理できる必要が
あります。
モジュールのライフサイクルはプラットフォームのライフサイクルとは独立しており、ある意味では個々
のモジュールが独立した生物や細胞のようなものだと考えると理解しやすいでしょう。
WAS V8.0 アナウンスメント・ワークショップ
6
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Javaの現状
Java8(Project Jigsaw)で
モジュール化機構を導入
ƒ モジュール境界の定義に関する課題
しかし、リリースは2012年の予定
– クラスやメソッドの可視性だけでは十分な制御が難しい
• publicではクラスローダー全体に公開されてしまう
• そもそも、Javaのクラスはモジュールの単位としては細かすぎる
– JARはモジュールとしては機能不足
• 単に複数のクラスやリソースをまとめる機能のみ
• 一旦ロードされた後は、個別のクラス単位で認識されるのみ（JARは意識しない）
ƒ モジュール間の依存性管理に関する課題
– 静的な依存関係はコンパイルしてみないと分からない
– 実行時の依存関係は実行してみないと分からない
– バージョン管理機能がない
ƒ モジュールのライフサイクル管理に関する課題
– 一旦ロードしたクラスはアンロードできない
– ライフサイクルという概念はない(ロードされたら直ちに有効となる)
© 2011 IBM Corporation
7
WAS V8.0 アナウンスメント・ワークショップ
Javaの現状をコンポーネント指向プラットフォームの要件に照らし合わせて見ると、機能的に不十分
な点が多いことがわかります。
現在のJavaは、特にランタイム環境(Java VMやJava EEアプリケーション・サーバー)におけるモ
ジュール化機構が不足していると言えます。
この課題は既に認識されており、Project JigsawというプロジェクトでJavaへのモジュール化機構導
入が検討されています。
ただし、Project JigsawはJava 7では採用が見送られたため、最速で2012年に登場予定のJava 8
を待たなければなりません。
そこで、今すぐ使え、既に多数の実績のあるモジュール化機構としてOSGiが注目を集めているので
す。
WAS V8.0 アナウンスメント・ワークショップ
7
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGi小史
ƒ 1999年：「Open Service Gateway Initiative」が設立
–当初は家庭や小規模オフィス向けの
ゲートウェイ装置で動作するサービスプログラムの実行基盤
ƒ 2003年：名称を「OSGi Alliance」に変更
–対象を車載機器やモバイル端末、エンタープライズ・システムに拡大
ƒ 2003年：Eclipse 3.0がプラグイン管理システムとしてOSGi仕様を
採用
–Javaの世界での知名度が一気に向上
ƒ 2010年：OSGi R4.2の一部としてEnterprise Specification公開
–Java EE環境でOSGiを活用するための拡張仕様
–Spring Framework由来のDIコンテナ機能も標準化
© 2011 IBM Corporation
8
WAS V8.0 アナウンスメント・ワークショップ
OSGiの存在意義を理解するために、OSGi登場の背景とこれまでの歴史について簡単に紹介して
おきます。
OSGiは当初、家庭用のアプライアンス機器や組み込み機器でJavaベースのアプリケーションを動
作させるための仕様として標準化が進みました。
2003年にEclipse3.0のプラグイン管理システムの基盤としてOSGiが採用され、Java開発者に
OSGiが広く認知されるようになります。
そして2010年にOSGiをエンタープライズ・アプリケーションの世界で活用するための標準仕様とし
て、Enterprise Specificationが策定されました。
これはOSGi R4.2の拡張仕様として定義されており、アプリケーション・サーバーが提供する機能と
OSGiバンドルから利用する方法や、Spring Frameworkと同等の機能を持ったDIコンテナ機能が
規定されています。(仕様策定にはSpringSourceのメンバーも深くかかわっています。)
IBMはEnterprise Specの策定メンバーであり、WAS V7.0ではFeature Pack for OSGi and
JPA2.0としてEnterprise Spec対応を進めてきましたが、WAS V8.0ではアプリケーション・サーバー
の標準機能に取り込まれています。
WAS V8.0 アナウンスメント・ワークショップ
8
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiの提供する機能
ƒModuleレイヤー
–依存関係の解決
–複数バージョンの管理
ƒLife Cycleレイヤー
–モジュールの動的ロード
ƒServiceレイヤー
ƒSecurityレイヤー
実行環境が依存関係を管理
異なるモジュールが
同一モジュールの異なるバージョンを
要求してもOK
JVMを起動したまま
モジュールの入れ替えが可能
© 2011 IBM Corporation
9
WAS V8.0 アナウンスメント・ワークショップ
OSGiの提供する機能は以下のように階層化されています。
(1)Moduleレイヤー
OSGiのコアとなるモジュール(バンドル)の管理機能を提供します。モジュールのバージョンや依存
関係も管理します。
(2)Life Cyleレイヤー
モジュールのライフサイクル管理機能を提供します。モジュールのインストール/アンインストールや
開始/停止などを指示できます。
(3)Serviceレイヤー
モジュール間で疎な連携を行うためのサービス・レジストリー機能を提供します。詳細は後述します。
(4)Securityレイヤー
Javaのセキュリティ機構を踏襲する形で、認証やアクセス制御などの機能を提供します。
OSGiによる拡張は少ないので、本資料では詳細説明は割愛しています。詳細についてはOSGi仕
様書などを参照してください。
WAS V8.0 アナウンスメント・ワークショップ
9
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Bundle: OSGiにおけるモジュール
JAR
+
OSGi
Metadata
META-INF/MANIFEST.MF
© 2011 IBM Corporation
10
WAS V8.0 アナウンスメント・ワークショップ
OSGiにおけるモジュールは「バンドル(Bundle)」と呼ばれます。
バンドルは物理的にはJARファイルそのものですが、マニフェストファイル(MANIFEST.MF)にOSGiで
定義されているメタデータを追記することで、OSGiフレームワークにバンドルとして認識されるよう
になります。
特別な定義ファイルやパッケージング・フォーマットを採用せず、既存のJavaの仕様を活かす形で
仕様が規定されているため、非OSGi環境との相互運用性が高く、連続的に移行可能であるとが
OSGiのメリットの一つです。
例えば、OSGiバンドルは通常のJava環境でも普通のJARファイルとして利用できます。
WAS V8.0 アナウンスメント・ワークショップ
10
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGi Metadata
Manifest-Version: 1.0
Export-Package: org.apache.aries.samples.blueprint.helloworld.server;
uses:="org.apache.aries.samples.blueprint.helloworld.api";
version="0.2.0.incubating"
Import-Package:
org.apache.aries.samples.blueprint.helloworld.api;version="[0.2,0.3)"
Implementation-Title: Apache Aries
Implementation-Version: 0.2-incubating
Bundle-Name: Apache Aries Blueprint HelloWorldServer
Bundle-SymbolicName: org.apache.aries.samples.blueprint.helloworld.server
Bundle-Vendor: The Apache Software Foundation
Build-Jdk: 1.6.0_21
Bundle-Version: 0.2.0.incubating
Bundle-ManifestVersion: 2
Bundle-Description: Example blueprint hello world application - server
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-DocURL: http://www.apache.org
© 2011 IBM Corporation
11
WAS V8.0 アナウンスメント・ワークショップ
マニフェストファイルにOSGiのメタデータを追記した例を示します。
OSGiでは多数の追加項目が規定されていますが、本質的に重要な項目は以下です。
(1)Export-Package
このバンドルが外部に公開するAPIを指定します。OSGiではAPIの公開はJavaのパッケージ単位で
行われます。
公開されていないAPIはバンドルの外部から参照することができません。
(2)Import-Package
このバンドルが動作するために必要とするAPIを、名称とバージョンの組合せで指定します。
バージョンは範囲指定が可能ですが、詳細は後述します。
(3)Bundle-SymbolicName / Bundle-Version
バンドルの名前とバージョンを指定します。ランタイム環境では、モジュールはこの2つの組合せで
ユニークに指定できることが必要です。
バージョン番号は「数字.数字.数字.(アルファベット or 数字)」となり、数字の大きいものが新しい
バージョンとみなされます。
WAS V8.0 アナウンスメント・ワークショップ
11
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
バージョン管理
Export
com.foo.bar
1.4.5
Import ＜ 1.4.0
1.2.0≦ バージョン
com.foo.bar
[1.2.0, 1.4.0)
両方のバンドルに同名の
Classが存在していても、
正しく解決される
com.foo.bar
1.3.12
com.foo.bar
[1.4.0, 1.5.0)
© 2011 IBM Corporation
12
WAS V8.0 アナウンスメント・ワークショップ
バージョン管理は以下のように行われます。
左側がcom.foo.barをexportしているバンドルで、右側がcom.foo.barをimportしているバンドルで
す。
com.foo.barは1.3.12と1.4.5の二つのバージョンが同時に提供されていますが、バージョンが異な
るのでOSGiフレームワークはこれらを別のものとして扱います。
右上のバンドルはcom.foo.barの1.2.0以上、1.4.0未満のバージョンを要求していますので、左下の
バンドルが提供するAPIが条件に合致します。
従って、右上のバンドルと左下のバンドルには参照関係が構成されます。
次に、右下のバンドルはcom.foo.barの1.4.0以上、1.5.0未満を要求していますので、左上のバンド
ルと参照関係が構築されます。
条件に合致するAPIが複数存在する場合は、デフォルトでは新しい(バージョン番号の大きい)ものが
優先されます。
Import-packageの指定にはバージョン条件に加え、プロパティで絞り込みを行うためのクエリーを指
定することもできますが、ここでは詳細は割愛します。
WAS V8.0 アナウンスメント・ワークショップ
12
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
バンドルのライフサイクルと依存関係の解決
バンドルをstopすると、
"Stopping"を経て
"Resolved"に戻る
バンドルをstartすると、
"Starting"を経て"Active"に
OSGi Frameworkにバ
ンドルをロードすると
"Installed"に
Import-Packageなどで指定され
た依存関係を満たすかチェック
⇒OKなら"Resolved"に
© 2011 IBM Corporation
13
WAS V8.0 アナウンスメント・ワークショップ
バンドルのライフサイクルは以下のように遷移します。
(1)Installed
バンドルをロードした直後はこの状態です。
(2)Resolved
OSGiフレームワークが、メタデータで指定された依存関係などを満たすことができるかを確認し、OKであれば
この状態になります。
依存関係が満たせない場合はInstalledに差し戻され、利用することはできませんので、この時点でモジュール
の整合性が保証されることになります。
(3)Starting
OSGiフレームワークに対してバンドルの開始を指示すると、開始処理が実行され、この状態になります。
(4)Active
開始処理が完了するとこの状態になり、バンドルが利用可能になります。
(5)Stopping
OSGiフレームワークに対してバンドルの停止を指示すると、停止処理が実行され、この状態になります。
(6)Resolved
停止処理が完了する、バンドルはResolved状態に戻ります。
(7)Uninstalled
Resolved状態のバンドルにアンインストールを指示するとこの状態になります。
OSGiフレームワークのランタイムからは除去された状態になりますが、バンドルの物理的なファイルなどは削除
されずに残っている場合もあります。(実装依存)
WAS V8.0 アナウンスメント・ワークショップ
13
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
バージョン管理: behind the scenes
ClassLoader
Export
Import
com.foo.bar
1.4.5
com.foo.bar
[1.2.0, 1.4.0)
com.foo.bar
1.3.12
com.foo.bar
[1.4.0, 1.5.0)
Frameworkがバンドル毎に
ClassLoaderを作成し、
Metadataに従って関連付ける
14
© 2011 IBM Corporation
WAS V8.0 アナウンスメント・ワークショップ
OSGiフレームワークがどうやってバージョン管理を実現しているのか、その仕組みを解説します。
Javaでは同じクラスローダー上にロードしたクラスは異なるクラス名(FQCN)を持っていなければなら
ず、同じクラス名でバージョンが異なるものを混在させることはできません。
OSGiでは、この問題をバンドル別にクラスローダーを作成することで解決しています。
その上で、export-importの参照関係が満たされるように、OSGiフレームワークがクラスローダーの
関連付けを行います。
WAS V8.0 アナウンスメント・ワークショップ
14
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Export-Importによるバンドル間の関連付け
ƒ Export-Package/Import-Packageによる参照は
「静的な参照」関係
ƒ 依存関係の解決は、バンドルを開始(start)した時に、OSGi
Framework上にロードされているバンドルに対して行われる
ƒ 依存関係を更新するためには、バンドルを再起動する必要あ
り
この方法では、
動的なモジュールの交換は不可能
© 2011 IBM Corporation
15
WAS V8.0 アナウンスメント・ワークショップ
ここで、OSGiで動的なモジュールの更新を行うために必要な前提条件について整理しておきましょ
う。
これまで説明してきた、OSGiメタデータのExport-Package/Import-Packageによる参照は、実は「静
的」な参照関係であることに注意が必要です。
というのも、この方法では依存関係の解決はバンドルを開始した時点でのOSGiフレームワークの
状態を前提として行われ、一度構築されたバンドル・クラスローダーの参照関係はバンドルが
activeである間は更新されないためです。
従って、新しいモジュールをリリースして、そのモジュールがexportする新しいAPIを参照させるため
には、import側すなわちクライアント・バンドルを再起動してクラスローダーを再構成する必要があ
るのです。
当然ながら、バンドルの停止中にはバンドルを利用できませんので、この手順ではバンドルの更新
時にアプリケーションの利用停止を引き起こすことになります。
WAS V8.0 アナウンスメント・ワークショップ
15
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
バンドルのバージョンアップ？
Export
Import
<<active>>
<<active>>
com.foo.bar
1.4.5
com.foo.bar
[1.4.0, 1.5.0)
install/start
com.foo.bar
1.4.6
クライアント・バンドルを
stop/startしない限り、新し
いバージョンとの紐付けは
行われない
© 2011 IBM Corporation
16
WAS V8.0 アナウンスメント・ワークショップ
前頁で説明した内容を図示するとこのようになります。
WAS V8.0 アナウンスメント・ワークショップ
16
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
動的なモジュール交換を実現するには?
ƒ OSGi Frameworkの提供するサービス・レジストリーを利用
ƒ 「サービス」と言っても大げさなものではなく、実体はJavaの
Class(Interface)
サービス
レジストリー
Register
レジストリーから毎回
Lookupするので、更新され
たバージョンが登録されて
いれば直ちに反映される
Lookup
サービス
リクエスター
サービス
プロバイダー
© 2011 IBM Corporation
17
WAS V8.0 アナウンスメント・ワークショップ
では、動的なモジュール交換を実現するにはどうすればよいのでしょうか？その鍵となるのがOSGi
Frameworkの提供する「サービス」機能です。
サービス・レジストリーの利用方法は以下のようになります。
(1)サービスプロバイダーが、OSGiのAPIを利用してレジストリーにサービスを登録
(2)サービスリクエスターが、OSGiのAPIを利用してレジストリーからサービスを取得
(3)サービスリクエスターがサービスを実行
サービスの実体はJavaのクラスなので、レジストリーから取得した後は普通にメソッド呼出しなどを
行うことが可能です。また、登録は具体的なクラスを指定しますが、取得はインターフェース型を指
定することが多いです。
サービスの参照はメタデータのexport-importで指定する必要がないため、クラスローダーの関連
付けは行われません。これにより、バンドル間の疎な連携が可能になります。
図で「黄色い三角形」が配置されてる関連は、export-importによる静的参照ではなく、サービスに
よる動的参照であることを示しています。
OSGi関連の資料ではよく使われる記法ですので憶えておいて下さい。
サービス・レジストリーからの参照はLookup実行毎に行われますので、新しいサービスをレジスト
リーに登録すれば、リクエスターを再起動することなく直ちに新しいサービスを利用することが可能
になります。
ただし、Lookup処理のオーバーヘッドを回避するため、OSGi Frameworkがキャッシュすることも多
いようです。
WAS V8.0 アナウンスメント・ワークショップ
17
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
(例) サービスの登録と参照
Serviceの登録
public class GreetingImple implements Greeting {
・・・・・・・
}
public class Activator implements BundleActivator {
public void start(BundleContext ctx) {
ctx.registerService(Greeting.class.getName(),
new GreetingImpl("service"), null);
}
・・・・
Interfaceのクラス名で、
GreetingImplのインスタンスを
登録
Serviceの参照
public class Client implements BundleActivator {
Interfaceのクラス名で、サービ
public void start(BundleContext ctx) {
スのインスタンスを取得
ServiceReference ref =
ctx.getServiceReference(Greeting.class.getName());
((Greeting) ctx.getService(ref)).sayHello();
}
・・・・
© 2011 IBM Corporation
18
WAS V8.0 アナウンスメント・ワークショップ
サービスプロバイダーとサービスリクエスターのコード例です。
ここではOSGi FrameworkのAPIを利用していますが、後述するBlueprintを利用するとサービスの登
録・参照をXMLファイルの定義で宣言的に行うことも可能です。
プロバイダーとリクエスターで共通に利用するインターフェース(ここではGreeting)は別のバンドルに
切り出しておき、プロバイダー側のバンドルとリクエスター側のバンドルの両方からImport-Package
によって参照するのがベストプラクティスとされています。
サービスの実装が変わってもインターフェースは不変であるため、サービス・レジストリーに登録す
る実装クラスだけを更新すれば、クライアント・バンドルを再起動しなくても新しい実装を利用できま
す。
WAS V8.0 アナウンスメント・ワークショップ
18
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGi R4.2 Enterprise Specification
ƒOSGi Alliance Enterprise Expert Group(EEG)によっ
て定められたEnterprise向けの拡張仕様
–http://www.infoq.com/news/2010/03/osgi-enterprise-42released
ƒ以下が規定されている
–アプリケーションのアセンブリ・フォーマットの拡張
–Java EEコンテナ・サービスとの統合
–宣言的なDI仕様(Blueprint)
© 2011 IBM Corporation
19
WAS V8.0 アナウンスメント・ワークショップ
これまではベースとなるOSGiの要点について説明してきました。
ここからはエンタープライズ向けの拡張について概要をご紹介します。
OSGiのエンタープライズ向け拡張は、OSGi R4.2の拡張仕様として2010年に策定が完了しました。
仕様策定にはアプリケーション・サーバーのベンダーや、SpringSourceなどが関わっています。
Enterprise Specificationの主な内容としては以下があります。
・アプリケーションのアセンブリ・フォーマット拡張: WARやEARをOSGi対応にしたもの
・アプリケーション・サーバー(Java EEコンテナ)との連携: JNDI/JTA/JPAなど
・Blueprnitコンテナ: 標準化されたSpring FrameworkライクなDIコンテナ
WAS V8.0 アナウンスメント・ワークショップ
19
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGi化したエンタープライズ・アプリケーション
OSGi
metadata
OSGi
Bundle
OSGi
Bundle
OSGi
Bundle
（.jar）
（.jar）
（.jar）
Web App
Bundle （.wab）
Enterprise
Bundle App
（.eba）
Business
Level
Application
Context
Path
Enterprise Bundle App （.eba）
Virtual
Host
© 2011 IBM Corporation
20
WAS V8.0 アナウンスメント・ワークショップ
Enterprise Specではアセンブリ・フォーマット(パッケージング形式)が拡張され、アプリケーションを
OSGiバンドルの組合せとして構築できるようになりました。
既存の.warや.earにOSGiメタデータを追加した.wab/.ebaが追加されており、これらも特殊なOSGi
バンドルとして扱われます。
また、.wab/.ebaには専用のメタデータも追加されています。
WASでは、OSGiアプリケーションをBLA(Business Level Application)と対応付けて管理するように
実装されています。
WAS V8.0 アナウンスメント・ワークショップ
20
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGi Frameworkの提供するサービス
ƒ OSGi Framework上で実行されているバンドルから利用可能
– サービスは自由に作成・登録が可能
– 標準で様々なサービスが定義されている
I/O
Connector
Service
Preference
Service
ƒ Blueprintコンテナサービス
– Spring FrameworkをベースとしたDIサービス
– XMLファイルの構成に基づいて依存性を注入
Log
Service
依存関係の注入(DI)
サービスの公開
コンポーネント
(POJO)のスタティッ
クな構造の組み立て
サービスの利用
Blueprint managed
bundle
OSGi 4.2で
標準仕様に
追加
Blueprint コンテナのスコープはバ
ンドル内に制限(バンドル毎に1つ)
Mobule-Context内には複数の
<components /> を定義可能
© 2011 IBM Corporation
21
WAS V8.0 アナウンスメント・ワークショップ
Enterprise Specでは、OSGiの標準サービスに加え、以下のサービスが追加されています。
(1)アプリケーション・サーバーが提供するサービスとのブリッジ
JNDI/JTAといったサーバー・サービスを、OSGiのサービス・レジストリーから利用することができます。
OSGiバンドルがアプリケーション・サーバーのサービスを利用するために提供されています。
(2)Blueprintコンテナ
XMLファイルで宣言的に定義したサービスの依存関係を自動的に解決します。
OSGiのAPIで直接サービス・レジストリを操作する必要がなく、アプリケーション開発者にOSGiを意
識させることがありません。
WAS V8.0 アナウンスメント・ワークショップ
21
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Blueprint component model
ƒ サービスレジストリへの登録や参照を宣言的に行うための仕様
ƒ JNDIサービスにより、OSGiのサービスレジストリにJNDI経由でアクセス可能
[OSGI-INF/blueprint/service.xml]
OSGi Bundle
(.jar)
<blueprint
xmlns:tx="http://www.ibm.com/appserver/schemas/8.0/blueprint/transactions"
xmlns:jpa="http://www.ibm.com/xmlns/ibm-blueprint-jpa/v1.0.0">
<bean id="blabberImpl" class="com.ibm.ws.eba.example.blabber.persistence.BlabberImpl">
<jpa:context property="entityManager" unitname="blabber" />
<tx:transaction method="*" value="Required"/>
Interface名で実装(bean)を公開
</bean>
<service id="blabberService" ref="blabberImpl"
interface="com.ibm.ws.eba.example.blabber.persistence.spi.BlabberUserInterface" />
</blueprint>
OSGiサービス・レジストリーから
Interface名で実装(bean)を取得
Client
InitialContext ic = new InitialContext();
return (BlabberUserInterface) ic.lookup("osgi:service/" +
BlabberUserInterface.class.getName());
© 2011 IBM Corporation
22
WAS V8.0 アナウンスメント・ワークショップ
Blueprintコンテナによるサービスの定義の例です。
サービス・レジストリへの登録は<service>タグで記述するだけです。
サービス利用者側もOSGiバンドルであればBlueprintが利用できるため、同様にXMLファイルで
サービスの参照が指定できます。
ServletなどOSGiバンドル外のクライアントからも、Enterprise SpecのJNDIサービスを経由すること
でサービスを参照できます。
その場合はJNDIのネームスペースとして「osgi:service」を利用してください。
WAS V8.0 アナウンスメント・ワークショップ
22
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiの使いどころ
© 2011 IBM Corporation
23
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
23
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiのメリット(1): 安全なコンポーネント化の促進
ƒ コンポーネント間の意図しない依存関係の抑制
non-OSGi環境
実行モデル(Java)
フラットな
ClassLoader
A.jar
OSGi環境
実行モデル(OSGi)
バンドル毎の
ClassLoader
B.jar
設計時に意図し
ていない依存関
係が発生するリ
スク
A.jar
メタデータで指定さ
れた依存関係が実
行時にも保証され
る
C.jar
B.jar
C.jar
ƒ コンポーネント間の依存関係のトレーサビリティの保証
A.jar
モジュールを修正する
際に影響を受けるモ
ジュールがメタデータ
から機械的に特定でき
る
B.jar
C.jar
E.jar
D.jar
F.jar
G.jar
© 2011 IBM Corporation
24
WAS V8.0 アナウンスメント・ワークショップ
OSGiがどのような場合に特に効果を発揮するか考えてみます。
OSGiを採用するメリットの一つ目は、コンポーネント化を安全に進めることができるということです。
これは、OSGiの提供するバンドルの独立性や、バンドル間の依存関係の明示が役立ちます。
WAS V8.0 アナウンスメント・ワークショップ
24
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiのメリット(2): 動的なモジュールの交換
ƒ OSGi Frameworkが提供するサービス・レジストリーを利用
ƒ Interfaceと実装の分離、疎結合、動的更新
サービス
レジストリー
1.1.0
レジストリーから動的に
Lookupするため、更新され
たバージョンが登録されてい
れば直ちに利用可能になる
1.1.1
Service Reference
による間接参照
25
© 2011 IBM Corporation
WAS V8.0 アナウンスメント・ワークショップ
OSGiを採用するもう一つのメリットは、サービス・レジストリーによる間接参照を利用したモジュール
の動的更新の実現です。
エンタープライズ・システムにおいては無停止でのアプリケーション更新を行うために様々なテク
ニックが利用されていますが、OSGiを採用することで解決可能な問題もあるかもしれません。
WAS V8.0 アナウンスメント・ワークショップ
25
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiを適用するためのトレードオフ
ƒ OSGiを適用するためのコストはタダではない
–アプリケーションは設計段階できちんとモジュール分割しておく
–開発者はOSGiバンドルのメタデータを管理する
–OSGiに対応した実行環境を用意する
–運用管理者はOSGiバンドルのライフサイクル管理を行う
ƒ コストに見合った効果が得やすいケース
–アプリケーションの規模が大きい場合
–アプリケーションのメンテナンスが頻繁に発生する場合
–アプリケーションの一部を運用中に動的に交換したい場合
© 2011 IBM Corporation
26
WAS V8.0 アナウンスメント・ワークショップ
OSGi採用のメリットについて考察してきましたが、OSGiを採用する場合にはそれに伴うコストとのト
レードオフについても考えなければなりません。
既に説明した通り、アプリケーションのOSGi化はライフサイクル全般に影響を及ぼすため、開発プ
ロセスや運用、エンジニアのスキル育成など、全般にわたって検討が必要になります。
また、当然ながら、アプリケーションの実行環境としてOSGiに対応したものを選定する必要がありま
す。
コストに見合った効果を得やすいケースとして、「大規模」「頻繁な修正」「無停止更新」などのキー
ワードに該当する場合には特に採用を検討する価値があると考えられます。
WAS V8.0 アナウンスメント・ワークショップ
26
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
WAS V8.0のOSGi対応
© 2011 IBM Corporation
27
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
27
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
WAS V8.0のOSGi アプリケーション機能
Update
開発スピードアップ、モジュール化による再利用性の向上、動的更新、Webアプリ
ケーションおよびエンタープライズ・アプリケーションにおけるバージョンニング
特徴:
ƒ モジュール単位の開発と運用管理: アプリケーション・アーカイブ
から共通ライブラリを分離し、複数のバージョンを横断的に集中
管理
ƒ 標準化されたDIフレームワーク: POJOベース開発モデルをサ
ポートし、依存関係の管理やコンポーネントの活性化・ 非活性化
を制御するDIコンテナーをサーバーに統合
Newƒ
無停止更新: アプリケーションを再起動せずにモジュールの更新
が可能
ƒ Java標準サービスとの連携: トランザクション、セキュリティ、永
続化といったJava標準サービスをコンポーネント化されたアプリ
ケーション(OSGiバンドル)からサービスとして利用可能
webA.jar
webA.jar
webA.jar
webA.jar
WEB-INF/classes/servletA.class
webA.jar
WEB-INF/classes/servletA.class
webA.jar
WEB-INF/classes/servletA.class
webA.jar
WEB-INF/classes/servletA.class
webA.jar
WEB-INF/web.xml
WEB-INF/classes/servletA.class
WEB-INF/web.xml
WEB-INF/classes/servletA.class
WEB-INF/web.xml
WEB-INF/classes/servA.class
WEB-INF/web.xml
WEB-INF/classes/servA.class
META-INF/MANIFEST.MF
WEB-INF/web.xml
META-INF/MANIFEST.MF
WEB-INF/web.xml
META-INF/MANIFEST.MF
WEB-INF/web.xml
META-INF/MANIFEST.MF
WEB-INF/web.xml
META-INF/MANIFEST.MF
META-INF/MANIFEST.MF
META-INF/MANIFEST.MF
META-INF/MANIFEST.MF
BundleRepository
Repository
Bundle
logging f/w jar
persistence f/w jar
MVC f/w jar
ƒ SCAとの統合: コンポーネントは粗粒度のSOAサービスを提供
するSCAコンポーネントとして公開可能
© 2011 IBM Corporation
28
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0では、WAS V7.0でFeature Pack for OSGi and JPA2.0で提供されていたOSGi
アプリケーション対応機能が標準機能として組み込まれています。
また、V8.0で新たにモジュールの無停止更新が可能になりました。
Feature Packではサービスの更新であってもアプリケーションの再起動が必要でしたが、
V8.0では不要になっています。
WAS V8.0 アナウンスメント・ワークショップ
28
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
WAS管理コンソールからのOSGiアプリケーション更新
ƒ 実際の更新を行う前に、管理コンソールで新しいバンドルのプレビューが可能
ƒ 動的更新機能により、アプリケーションの停止を伴わずにバンドルの更新が可能
インストール済み
バンドルの
バージョンを
指定して更新
© 2011 IBM Corporation
29
WAS V8.0 アナウンスメント・ワークショップ
管理コンソールにOSGiバンドルの管理機能が組み込まれており、アプリケーションを構成
する個別のバンドル単位でのバージョン管理が可能です。
WAS V8.0 アナウンスメント・ワークショップ
29
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
バンドル・リポジトリーの管理
WASの内部バンドル・リポジトリーに
登録されているバンドルの一覧
外部バンドル・リポジトリーを参照する場合は
URLを指定
30
© 2011 IBM Corporation
WAS V8.0 アナウンスメント・ワークショップ
デプロイ済みのバンドルを管理する、内部バンドル・リポジトリーの管理機能が管理コンソールから利
用できます。
バンドルはWASに直接デプロイするだけでなく、外部バンドル・リポジトリーからネットワーク経由で
取得してくることも可能です。
外部バンドル・リポジトリーを利用する場合は、この画面からURLを登録しておきます。
WAS V8.0 アナウンスメント・ワークショップ
30
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiアプリケーションの動的更新
New
„Blueprintコンポーネント・モデルによるサービスのダイナミックな更新
„サービスが更新されている間、コンテナがリクエストを一時的にブロック
„アプリケーションの停止を避け、サービスのダウンを防止
© 2011 IBM Corporation
31
WAS V8.0 アナウンスメント・ワークショップ
V8.0の新機能として、OSGiアプリケーションの動的更新に対応しました。
既にご紹介したとおり、OSGiにおける動的更新を行うためには、バンドル間がサービスによる間接
参照で連携していることが前提となります。
この図では、サービス・プロバイダーはバンドルB3で、B3をバージョン1.0.0から1.0.1に更新する手
順を説明しています。
B1からB3への連携は間接参照であるため、モジュールの更新中にはサービスの実行は一時停止
され、更新後に再開されます。
WAS V8.0 アナウンスメント・ワークショップ
31
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Enterprise OSGi開発を支援するツール
ƒ OSGiバンドルの開発効率化
– RADのベースであるEclipseでは、プラグイン機構としてOSGiを採用
• Eclipseプラグイン開発支援機能が利用可能
– Enterprise OSGiでも同様
ƒ Enterprise OSGiに対応した開発ツール
– Rational Application Developer V8.0
• OSGi R4.2 Enterprise Specificationに対応したアプリケーション開発支援機能を含む
– IBM Rational Development Tools for OSGi Applications
• http://www.ibm.com/developerworks/rational/downloads/10/rationaldevtoolsforosgiapplications.html
• 無償のEnterprise OSGi開発プラグイン
• RAD8.0のEnterprise OSGi対応機能を切り出したもので、一部機能制限あり
ƒ 開発ツールが提供するアプリケーション開発支援機能の例
– Enterprise Specに対応して拡張されたOSGiメタデータ・エディタを提供
• プレーンテキスト(MANIFEST.MF)でメタデータを編集する必要なし
– Enterprise Application Bundle(EAB)プロジェクト・ウィザード
• Enterprise Specで定義されたパッケージング仕様に対応
– バンドル・エクスプローラーによる依存関係の可視化 （RAD8.0のみ)
• アプリケーション全体でのバンドルの依存関係の直観的な把握が可能
© 2011 IBM Corporation
32
WAS V8.0 アナウンスメント・ワークショップ
OSGiアプリケーション開発に固有の作業を支援するための開発ツールをご紹介します。
商用のRAD V8.0、および無償のEclipseプラグインがあります。
WAS V8.0 アナウンスメント・ワークショップ
32
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
バンドル・メタデータ・エディタ
Bundleのメタデータや
ビルド／ランタイム情報の管理
© 2011 IBM Corporation
33
WAS V8.0 アナウンスメント・ワークショップ
専用の開発ツールを利用することで、マニフェストファイルを直接編集することなく、バンドルのメタ
データを効率よく管理することが可能になります。
バンドル間の参照関係などもGUI上の操作で容易に指定できます。
WAS V8.0 アナウンスメント・ワークショップ
33
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
バンドル・エクスプローラー
Bundleの依存関係を可視化
選択したBundleの詳細情報
※RAD8.0(有償製品)の機能で、無償版のプラグインには含まれない
© 2011 IBM Corporation
34
WAS V8.0 アナウンスメント・ワークショップ
バンドル間の依存関係がどのようになっているか確認するためには、メタデータを一つ一つ付き合わ
せていく必要があり、大規模なアプリケーションでは骨の折れる作業です。
RAD8.0はこのようにアプリケーション全体でのバンドルの依存関係を可視化する機能を提供してい
ますので、手間をかけずに構造を把握することができます。
WAS V8.0 アナウンスメント・ワークショップ
34
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
(参考) Apache Ariesプロジェクト
ƒ Apache Ariesプロジェクト
– WAS8.0のOSGiアプリケーションフレームワークのベースをオープンソース化
– http://incubator.apache.org/aries/index.html
ƒ OSGiアプリケーション開発で参考になる有用な成果物を提供
– サンプル
• http://incubator.apache.org/aries/downloads.html
• Mavenを使うプロジェクトの構成方法や、Blueprintの使い方、テストコードの書き方など
• EquinoxやFelix上でEnterprise OSGiベースのアプリケーションを動かすために、
Apache Geronimoの成果物を利用する方法
• DayTraderベンチマーク・アプリケーションのOSGi版(Aries Trader)
– EBA Maven Plugin
• http://incubator.apache.org/aries/ebamavenpluginproject.html
• MavenでEBAをビルドするためのプラグイン
• マニフェストファイルの自動生成に対応
© 2011 IBM Corporation
35
WAS V8.0 アナウンスメント・ワークショップ
WAS8.0のOSGiアプリケーションフレームワークは、基本部分がApache Ariesプロジェクトに寄贈
されてオープンソースとして公開されています。
ソースコードそのものも技術情報として有用ですが、それ以外にもサンプルコードやビルドスクリプ
トなど、アプリケーション開発者にとって有用な情報が多く提供されています。
サンプルコードはWAS8.0にデプロイして動かすこともできますので、ぜひ参照してみてください。
WAS V8.0 アナウンスメント・ワークショップ
35
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
Tivoli Performance Viewerによるパフォーマンス・モニタリング
ƒ アプリケーション毎／バンドル毎の統計情報が参照可能
© 2011 IBM Corporation
36
WAS V8.0 アナウンスメント・ワークショップ
運用管理に役立つ機能として、TPVによるバンドルのパフォーマンス・モニタリング機能が提供され
ています。
アプリケーション毎およびバンドル毎で、サービス実行やメソッド実行の統計情報が参照できます。
WAS V8.0 アナウンスメント・ワークショップ
36
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
OSGiとSCAのインテグレーション
SCA コンポジット
コンポーネント
POJO
EAR
SCAコンポジットはOSGiアプリケー
ションを含む異種コンポーネントか
ら構成され、SCAサービス・バイン
ディング(JMS, Webサービスなど)
によって統合される。
OSGi Application
バンドル
OSGiバンドルは OSGiアプリ
ケーションとして組み立てられ、
OSGiサービス・レジストリーを
通じてサービス連携を行う。
バンドル
POJO
POJO
POJO
バンドル
POJO は Blueprint コ ン テ キ ス ト に
よって組み立てられ、OSGiバンドル
としてスコープが定義される。
© 2011 IBM Corporation
37
WAS V8.0 アナウンスメント・ワークショップ
OSGiバンドルはSCAコンポーネントとしてラッピングすることができるため、SCAコンポジットの一部
として利用することが可能です。
これにより、現在のEnterprise OSGiでは対応していないEJBコンポーネントなどと連携する場合は、
SCA経由で連携することが可能となっています。
OSGiのコンポーネント・モデルはSCAと非常によく似たセマンティクスを持っており、SCAとの親和
性が高いため、SCAとの連携は容易です。
WAS V8.0 アナウンスメント・ワークショップ
37
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
まとめ
© 2011 IBM Corporation
38
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
38
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
まとめ
ƒOSGi & Enterprise OSGi
– OSGiはJavaに本格的なモジュール化機構を提供し、アプリケーションのコン
ポーネント化を促進する
– OSGiの肝は「バンドル」と「サービス」
– エンタープライズ・アプリケーション開発においてもOSGiのメリットを活用可能
ƒOSGiの使いどころ
– OSGiは万能の解決策ではない
• アプリケーションライフサイクル全般に影響
– 「大規模」「頻繁な修正」「長期利用」がキーワード
ƒWAS V8.0のOSGi対応
– アプリケーションを「バンドル」の組合せとして開発し、デプロイできる
– アプリケーション・サーバーの提供するサービスと連携可能
– EclipseやRADによる開発支援
© 2011 IBM Corporation
39
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
39
12. OSGiアプリケーション
12. OSGiアプリケーション
OSGiアプリケーション
参考資料
ƒ OSGi R4.2 仕様書
– http://www.osgi.org/Download/Release4V42
ƒ Introduction to OSGi by Neil Bartlett
– http://www.slideshare.net/njbartlett/introduction-to-osgi-tokyo-jug
ƒ WAS V8.0 Infocenter
– http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp
ƒ dW:エンタープライズOSGi入門
– 第1回 OSGi概要と実行環境の導入
http://www.ibm.com/developerworks/jp/websphere/library/was/was7_fep_osgi/1.html
– 第2回 OSGiのエンタープライズ拡張仕様を紐解く
http://www.ibm.com/developerworks/jp/websphere/library/was/was7_fep_osgi/2.html
– 第3回 OSGiによるアプリケーションのモジュール化
http://www.ibm.com/developerworks/jp/websphere/library/was/was7_fep_osgi/3.html
ƒ dW: WebSphere Application Server でエンタープライズ OSGi アプリケーションを開発する
– http://www.ibm.com/developerworks/jp/websphere/library/was/was7_osgi_develop/
ƒ dW: OSGiアプリケーションを開発、利用するためのベスト・プラクティス
– http://www.ibm.com/developerworks/jp/websphere/library/was/was7_osgi_practices/
© 2011 IBM Corporation
40
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
40
Fly UP