2008-03-27
JBoss and OSGi
Mark NewtonがAles Justinに対して実施したインタビューがJBoss.orgに公開されています。面白い内容なので最初のさわりだけでも紹介したいと思います。
Mark
JBoss研究開発部門ではここのところ新しいOSGi実装に取り組んでいますが、その目的は何ですか？
Ales
最初の目標はOSGiベースのクラスローダを持つことです。これは最初にの実行時サービスのために作成され、後に、OSGiエンタープライズ専門グループ（EGG）の活動に沿って、アプリケーション開発者のために同じものを導入する計画です。第二の目標は完全なOSGiコア仕様v4.1実装を作ることです。JBossマイクロコンテナ（MC）がすでにOSGiのコア機能を実現しているおかげで、この試みは容易に実現されます。さらに、我々は新しいOSGi EGGの「コンポーネントモデル」をサポートします。最後に、JBoss AS 5はすでにプロファイルというコンセプトを持っているので、我々のProfileServiceでOSGi Bundle Repository(OBR)を使うように統合します。
現在、Javaのクラスのインストールや管理は問題が多いです。Red HatのRPMやDebianのaptと比較してみてください。Java言語が提供するのは、クラスパスという概念とクラスローディングの低レベルな制御機能だけです。クラスのバージョン管理、クラス間の依存関係の管理を「パッケージ」単位で行うのは容易ではありません。特にアプリケーションサーバーのように、システムクラスとミドルウェアのクラス、複数のアプリのクラスが混在する環境では、クラス管理のトラブルはさまざまな形で現れます。
OSGiはパッケージ単位でのクラスローディングを制御できる仕組みを提供してくれるのでこのような問題を改善してくれることが期待できます。クラスローダ階層で、下位のクラスローダに対して、特定のクラスを見せないというVisibilityのコントロールや特定のバージョンへの依存性を明記することができます。これより、OSGiのモジュールをJVMにロードしても、ロード済のアプリと安全に共存できるようになります。OSGiは最初は組み込み機器に実行時にサービスをロードするために策定されたものなので、動的にネットワークからJVMにロードする仕組みを備えています。さらに、OSGiではこのようにしてロードしたサービスを手動で停止したり、開始したりすることができます。
JBossに話を戻しましょう。JBoss5ではプロファイルサービスというものが導入されます。これは、JBoss4までminimal/default/allでお馴染みのConfiguration Setを汎用的にしたもので、環境設定やデプロイ設定を「プロファイル」として管理できるようにします。このプロファイルサービスでは、OSGi Bundle Repository(OBR)と同じインタフェースで作られます。プロファイルサービス上では、OSGiバンドルとして提供されたJBossサービスを開始・停止できるようになるのでしょう。デプロイしたものを停止ができるということは、WindowsやLinuxのサービスでは当たり前ですが、これがアプリサーバーレベルのサービスで可能になるのです。
Mark
なぜ、すでにあるOSGi実装を利用しないのですか？
Ales
現在のOSGiサービスレジストリには我々が必要とする機能が足りません。細かな粒度の依存性、AOPとの統合、既存のJMXをサポートすること、スコープ付メタデータ、Open MBeans、Virtual File System (VFS)、汎用デプロイヤなどです。もし、現存する実装にこれらの機能を追加したなら、全部を統合するのは最初から開発するのと同じくらいの努力が必要となるでしょう。それに、我々自身の実装を作り上げることで、我々のアプリケーションサーバのコア部分、すなわちカーネルに対して最大限のコントロールを保証します。
我々はおそらく現存するOSGiフレームワークのクラスローディングを使うことができたでしょうが、それは前に述べたように無理やり動かすように物事を捻じ曲げてしまうことになるのです。我々は頑丈な実装を持ちたかったので、private/protected修飾子の背後に汚い詳細を隠せるように、ポリシーやデリゲーションを介してしっかりと制御できることが重要でした。この観点から、我々自身のクラスローディング層を実装することが道理にかなっていたのです。リソース参照のようなこともVirtual File Systemを使って実装できます。VFSはデプロイの場所や構造（パッケージされているか、展開されているか）にかかわらずアクセスできるようにしてくれるのです。
JBossマイクロコンテナは、このOSGiのクラスローダを作るためのコアとなる機能が組み込まれていますので、マイクロコンテナのFacadeとして、JMXだけでなく、OSGiもサポートすることができます。汎用OSGiフレームワークの上にアプリケーションサーバーを構築するというアプローチではなく、マイクロコンテナ自身がカーネルとそれに組み込まれるプラグインコンポーネントの集合体として構成されています。
JBossマイクロコンテナのソースを眺めるとすぐに気が付くのですが、ソースはSPIとAbstractクラスだらけで、FactoryパターンやVisitorパターンがいたるところで使われています。JBoss Deployment Frameworkは、一枚岩ではなく、多くの種類のコンポーネントが複雑に絡み合ってできています。Virutual File Systemとは、JARや、JARを展開したディレクトリを区別なく扱えるようにする抽象化レイヤです。なんと、VFSを使えば、メモリ上にアーカイブを作ってマイクロコンテナにデプロイすることもできます。これはUTに便利そう。
AssembledDirectory jar = AssembledContextFactory.getInstance().create("ejbTestCase.jar");
jar.addClass(Customer.class);
jar.addClass(CustomerDAOBean.class);
jar.addClass(CustomerDAOLocal.class);
jar.addClass(CustomerDAORemote.class);
jar.mkdir("META-INF").addResource("tutorial-persistence.xml", "persistence.xml");
Bootstrap.getInstance().deploy(jar);
JBossマイクロコンテナ、OSGi、プロファイルサービス。なかなか手ごわいですが、それらが目指す将来のサービス管理は非常に魅力的です。なぜなら、JBossの利点でもあり欠点でもあるUnified Class Loaderを補完し、サービスの動的インストールと安定稼動を可能にするからです。今回のインタービューに登場する2人は（私のお気に入りの）JBoss Microcontainer User Guideの著者でもあります。今後のこの2人の活躍に期待しています。
2008-03-23
Implement business logic with the Drools rules engine
DroolsルールエンジンとEclipseプラグインを使ったチュートリアル。
Droolsのブログより。
JBoss.org Online Store open for business
JBoss.orgのマウスパッドやバッチ、Tシャツなど。
"Free your code, and the rest will follow. "
2008-03-22
Opening EAP for IntelliJ IDEA 8.0
IDEA 8.0のEAPが開始されました。Seamがサポートされているようです。IDEAらしく、JBoss ELのクラス補完だけではなく、Observer/RaiseEvent間の整合性チェック、コンテキスト変数のチェック、という一歩先の「あったらいいな機能」が提供されています。
JBoss seam support, with coding assistance and dedicated visual tools
2008-03-19
First Release Of The Process Virtual Machine
The Process Virtual Machineのホームページはここ
The Process Virtual Machine is a simple Java library for building and executing process graphs. This serves as a basis for all kinds of workflow, Business Process Management (BPM) and orchestration process languages.
参考：プロセスコンポーネントモデルは次世代のワークフローか？(InfoQ)
2008-03-16
EJB 3.1 Early Draft Now Available
EJB 3.1 Eary Draftがここからダウンロードできます。
参考（TSSの記事）:
IntelliJ IDEA 7.0.3インストール
最近のIDEAはEclipseやMavenもサポートしています。EclipseでJBossのソースを読んでいたのですが、やはりソース解析にはIDEAが最高ということで、最新版をインストールしてJBoss5のソース（Eclipseプロジェクト）を読み込ませてみました。
JBossのプロジェクトすべてをロードするのに数分かかり、起動時ですでに280MBのメモリを消費しています。IDEAではロード時にクラス情報をメモリ上で管理し、それを検索や編集のときに利用しています。
そのおかげで、クラスのソースを表示するのにCtrl-Nを叩いてクラス名の一部を入力すればすぐにクラス名を補完入力してくれますし、Ctrl-Hでクラス階層を表示するのも実に速い。検索結果を「お気に入り」に登録しておけば次回に同じクラスを探すのも簡単。アップグレードしようかなぁ。
2008-03-15
Contexual Injection
JBossマイクロコンテナは状態機械(state machine)です。マイクロコンテナは、デプロイされたPOJOを管理するだけではなくて、起動・停止などのデプロイの状態も一緒に管理し、POJO間の依存関係を解決します。
普通のDIコンテナでは名前やタイプを使って依存性の注入をしますが、マイクロコンテナはサービスの実行環境として使われるのを想定しているので、サービスの起動中や再デプロイが発生した場合など、状態を無視して注入してしまうとすぐに実行時エラーになってしまいます。だから、依存先のサービスが準備できていないときはそちらの作業が終了してから注入をするとか、状態を意識した制御が必要になります。
この状態を意識した依存性の管理は、マイクロコンテナで始めて導入されたコンセプトではありません。世間でDIコンテナが登場する前から、JBossのJMXマイクロカーネルは、まさにこの仕事をMBean間の依存関係解決という形で実現してきました。JBoss5のマイクロコンテナはこの仕事をJMX MBeanからPOJOへ、MBeanインタセプタからAOPという形へ、サービス実行環境をより汎用的かつポータブル*1なフレームワークに進化させているのです。
マイクロコンテナで依存性の管理をしているのはControllerで、そこで管理されるサービスの状態はControllerContextです。このControllerContextはPOJOの状態を保持しています。この状態としては、たとえば、デプロイの状態、他のPOJOとの依存関係、モード（自動起動/手動起動）などがあります。
次の例は、マイクロコンテナからPOJOを取り出す具体例です。この例ではPOJOを取り出すのに、まずControllerContextを取り出し、そのControllerContextからターゲットとなるPOJOを取り出しています。
private final static String HRSERVICE = "HRService";
...
// Start JBoss Microcontainer
bootstrap = new EmbeddedBootstrap();
bootstrap.run();
kernel = bootstrap.getKernel();
controller = kernel.getController();
...
ControllerContext context =
controller.getInstalledContext(HRSERVICE);
if (context != null) { manager = (HRManager) context.getTarget(); }
昨日の日記でDeployment callbackを紹介しましたが、これは後からデプロイによってPOJOが動的に追加された場合に、POJOの間の参照関係を実行時に解決することができます。このように、マイクロコンテナのDIは、デプロイされる実行環境の状況が動的に変わることを想定して作られています。まさにプラガブルでダイナミックな依存性注入の仕組みです。
*1：「ポータブル」というのは、マイクロコンテナがあれば、JBoss Application Server以外の環境でもJBossのサービスを動かし、サービスを連携させることができるというビジョンからきています
2008-03-14
Deployment callback
昨日の日記で、JBoss5のMainDeployerはStructuralDeployersとDeployersという2種類のデプロイヤの集合を持つと書きました。しかし、bootstrap-beans.xmlをよく見ると、明示的にStructuralDeployersにJARStructureやWARStructureのようなDeployerをDIを使って注入していません。一体どうやって、Deployerの集合を集めるのでしょうか。
<bean name="StructuralDeployers" class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl">
<property name="structureBuilder">
<bean name="StructureBuilder" class="org.jboss.deployers.vfs.plugins.structure.VFSStructureBuilder"/>
</property>
<incallback method="addDeployer"/>
<uncallback method="removeDeployer"/>
</bean>
ポイントは下から2行のincallbackとuncallbackという指定です。これはカーネルに任意のPOJOがデプロイされるとき、引数の型が一致していればコールバックされるというものです。つまり、bootstrap-beans.xmlでは単純にDeployerを宣言しておくだけで、StructuralDeployer型のDeployerは自動的にVFSStructuralDeployersImpl::addDeployerがコールバックされて、StructuralDeployers beanに登録されるという訳。
/**
* Add a structure deployer
*
* @param deployer the deployer
*/
public synchronized void addDeployer(StructureDeployer deployer)
{
if (deployer == null)
throw new IllegalArgumentException("Null deployer");
structureDeployers.add(new StructureDeployerWrapper(deployer));
log.debug("Added structure deployer " + deployer);
}
参考：Deployment callback, JBoss Microcontainer 2.0.0 User Guide
2008-03-13
JBoss5 Deployerアーキテクチャ
JBoss5のDeployerのアーキテクチャはJBoss4から大きく変更されています。これが"Aspectized" Deployerです。従来は単一のDeployerがやっていた仕事を、アーカイブの解析、クラスローダ作成、Beanの登録などの各フェーズに分割し、それぞれをDeployerと呼んでいます。
With the old style of JBoss Deployers, a single deployer implementation would handle all the processing for the matching top level deployment unit. This behaviour was completely changed in the new Deployers architecture. Here we have a new way of handling deployment unit, we call it an aspectized deployment, meaning that each deployer implementation does just one thing
- Chapter 10. Deployers module, Getting Started with the JBoss Microcontainer
これら各Deployerを組み合せを変えればデプロイの処理を自在にカスタマイズできます。このデプロイやの組み合せの定義をしているのがbootstrap-beans.xmlで、サーバーのブート時に登録されるPOJOが記述されています。
JBoss5のMainDeployerにはStructuralDeployersとDeployersという2種類のデプロイヤの集合が注入されています。以前のMainDeployerが、ファイルのサフィックスなどを見て下請けのDeployerにディスパッチしていたのとは対照的です。
<bean name="MainDeployer" class="org.jboss.deployers.plugins.main.MainDeployerImpl">
<property name="structuralDeployers"><inject bean="StructuralDeployers"/></property>
<property name="deployers"><inject bean="Deployers"/></property>
<property name="mgtDeploymentCreator"><inject bean="ManagedDeploymentCreator"/></property>
</bean>
StructuralDeployersはアーカイブの構造解析を司るものでJARやWARなどのファイルの構造に依存した処理をします、DeployersはSARDeployerやEJB3Deployerのようにデプロイの本来処理をするものです。
各Deployerはファイルのサフィックスなどを見て、自分が処理すべきアーカイブか否かを判断することができます。また、Deployは自分がどのフェーズで実行されるべきものかを知っているので、複数のDeployerの実行順序も制御されます。
bootstrap-beans.xmlでは、MainDeployerの定義以降で、*DeployerというPOJOが幾つも登録されていますが、これは上で書いたように複数の単機能のDeployersを束にして従来のデプロイ機能を実現しているためです。
2008-03-12
JBossマイクロコンテナを探る
ここ何日かマイクロコンテナのドキュメントを見ながらJBoss5 Beta4のソースを読んでいます。
マイクロコンテナのクラスにはほとんどクラスコメントが書いてないので、Classファイルから逆にJavaソースを生成したような感じになってしまっています。またクラス名もConfigurationとか、Registryとか、Busとか、非常にそっけないので、ソースを見る前に適切なドキュメントを読むのが良いと思います。
JBoss Microcontainerのページで公開されている次の2つのドキュメントが基本です。
上のUser Guideは良いです。この手の開発者向けのドキュメントとしては、かなり説明が丁寧です。ただし、まだ、後半部分は書きかけといった感じです。
実は、サイトには公開されていませんが、ソースには次のドキュメントのDocBookが入っています。SVNからマイクロコンテナをチェックアウトしてPDFを作っておきましょう。これは、上のリファレンスよりも技術的なポイントがまとめてあるので参考になるでしょう。
JBossWikiのJBossMicrocontainerにはUML図を含めていろいろと書かれていますが、それだけ読んでも背景を知らないとピンと来ません。私は次のページがCoreサービスを簡潔にまとめているので気に入っています。たとえば、"Deployer - holds deployment aspects and applies them"と書いてあります。つまり、JBoss5ではDeployerというのはPOJOをデプロイするときにアスペクトを適用するものなのです。
このように、マイクロコンテナとAOPは密接な関係があります。マイクロコンテナとJBoss AOPの統合についてはForumに記事が投稿されています。
2008-03-11
JBoss SOA Platform (SOA-P) Documentation
JBoss Enterprise SOA Platform (version 4.2)、つまりjBPM/Drools/JBossESBの製品版、のドキュメント。JBossESBしか比べてませんが、各章のリンクが先頭に張られていてCommunity版より読みやすそうです。
2008-03-07
JBoss徹底活用ガイド打ち上げ
今、帰宅しました。中央線に乗って気がついたときには高尾でした。
大月まで行かなくてよかった。
皆様、お疲れさまでした。
小林さん、京都からの参加ありがとうございました。
nekopさん、Bigなゲストありがとう。
またよろしく!
2008-03-05
JBossの買収は失敗したのか
まずは、下の記事を順番に読んで見てください。
ZDNet（発端となった記事）
Time to call the Red Hat-JBOSS deal a failure?
上の記事へのコメント(何をもって「失敗」といっているのか）
RE: How do you define failure?...
Marc Fleuryのレスポンス（RedHatはPRが下手なだけ）
The Power of PR, is JBoss/Red Hat a failure?
CNET Blog（RedHatはこれから回収に行く。安泰）
What's really going on at JBoss?
Marc says: a lack of media coverage doesn't translate into a lack of commercial success.
(3/11追加, Bob Bickelからのコメントあり)
2008-03-01
Executive moves: Shaun Connolly leaves Red Hat
一昨年の12月にお会いしたことがありました。そのとき、私からJJBugの翻訳の状況について説明し、その後、JJBugの翻訳プロジェクトがRed Hatと一緒にできるように尽力して下さりました。
草若さんをころさないでーーって
みてました。
草々さん編も楽しんでます。