トップスポーツチームの監督に教わる秘訣
この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
News
プロセス仮想マシンについてTom Baeyensに訊く
作者 Gavin Terrill, 翻訳者 白石 俊平 投稿日 2008年5月19日 午前12時10分
jBPMプロセス仮想マシンにおける最新のアルファリリース(サイト・英語)で、JBossは「複数の定義言語をサポートしたプロセス実行エンジン」と言うビジョンの現実に近づいた。また、このリリースはjBPMへの興味を著しく引きつけた。jBPMを提供しているWebサイトは更新されている(サイト・英語) 。InfoQはこのプロジェクトについて、そしてPVM(サイト・英語)がBPMの景色をどう変えるのかについて、プロジェクトリードであるTom Baeyensに聞いた。InfoQ: InfoQの読者に、PVMのコンセプトが持つ歴史的な背景と目的について話していただけますか？
Tom: プロセス仮想マシン(サイト・英語) は、jBPM(サイト・英語)で探求してきた中核コンセプトの最終形です。
jBPM(サイト・英語）は、 jPDLと呼ばれる単一のプロセス言語から始まりました。しかしJBossの一部となった直後に、BPELもサポートできるのかどうかについてユーザに尋ねられました。このとき私は、多くのjPDL実装がBPELと重複していることに気づいたのです。それから私たちはプロセス言語特有の部分から、共通の部分を抜き出す作業を行ってきました。
jBPM 3では既に全てのコンセプトが実現されており、jPDLやBPELと言った複数のプロセス言語をネイティブで動作させます。しかし欠点としては、それが未だに一つの巨大なコードベースから成っていることであり、真にモジュール化されてはいないことです。BPMとワークフローの世界は完全に断片化しており、複数のプロセス言語の必要性はどんどん明白になりつつあります。そのため、私たちはよりモジュール化されたアプローチを必要としていたのです。
そこで、プロセス仮想マシンが登場したのです。それはグラフ構造を構築し、実行させるためのライブラリです。プロセス言語のネイティブ実装は、プロセス仮想マシン(source)の上で構築することができます。さらにそれはあらゆるJava環境の内部で動作します。標準のJava、エンタープライズJava、SEAMや Springなどです。
InfoQ: なぜこれが重要なのですか？
Tom: まず一つは、ビジネスプロセスマネジメント（BPM）とワークフローの世界が完全に断片化してしまっていることです。多くの異なるタイプのプロセス言語が存在し、その全てが対象となるユースケースと環境を持ちます。それはドメイン固有言語（DSL）のようです; 全てのルールを定義できる、一つの言語は存在しないでしょう。現在、これら全ての言語は固有のモノリシックなエンジンとともに提供されています。それは実用的ではありませんし、アプリケーションへの統合が困難です。
プロセス仮想マシン(source)は、これら全てのプロセス言語を一つのコア技術で動作させるための、シンプルな統一構造を提供しています。
.もう一つは、Javaの世界も同様に断片化していると言うことです。別個のサーバ上で、分離して動かす必要のあった伝統的なプロセスエンジンとは対照的に、 Java環境でさえあれば、あなたのアプリケーション内に統合して(source)プロセス仮想マシンを動かすことが可能です。これは、プロジェクトがプロセス技術を採用するための敷居を著しく低くします。なぜならプロセスのパーシステンスは、アプリケーションのパーシステンスと透過的に統合されうるからです。
InfoQ: 開発者は、プロセス仮想マシンそのものを取り扱うのでしょうか？
Tom: ほとんどのアプリケーション開発者は、プロセス仮想マシンそのものを取り扱うことはありません。その上に構築されたjPDLやBPEL、XPDLと言ったプロセス言語の一つで作業することになります。しかしプロセス仮想マシンの基本的なコンセプトを知っておくことは、アプリケーション開発者にとって重要でしょう。リレーショナルデータベースで作業するときに、開発者がテーブルやカラム、プライマリキーやSQLクエリについて知っているのと同じように、プロセス定義、実行、非同期の継続と言ったプロセス仮想マシンのコンセプトを知ることになるでしょう。
InfoQ: PVMのコンセプトをサポートするために、BullがJBossに加わりました - 他のパートナーとも仕事をしているのですか？
InfoQ: これまでに克服しなければならなかった、大きな困難にはどのようなものがありましたか？
- 実装のための分析: これは、今日のBPMに特化したスイートが主に対象としているユースケースです。分析ダイアグラムから始めて、実行可能なソフトウェアへと落とし込みます。多くの伝統的なベンダは、分析プロセスのダイアグラムと実行可能なプロセスの間の重大な差異を、多くのマジックを使って隠蔽しようとしています。
要求に責任を持つ非技術的な人々と、オートメーションに責任を持つ技術的な人々の間のコミュニケーション内で、そのダイアグラムが重要な役目を果たしています。しかし一般的に、非技術的な人々からの入力のみで、製品として利用可能なソフトウェアを生成できる技術は存在しません。
アナリストと開発者の間の協力作業を実現するために、実行可能なプロセス言語は、分析ダイアグラムに正しくフィットするぐらい柔軟である必要があります。カスタマイズ可能なアクティビティの実装やイベントリスナなどの機能は、ダイアグラムが実行可能なソフトウェアになった後でも、依然としてアナリストがダイアグラムを認識できることを確実にするためにも重要です。jPDLは、その目的のためには他に秀でています。またjPDLは、Javaテクノロジーと、開発者が好むようなコンパクトで可読性に優れたXML文法をクリーンに統合できます。XPDLもこうしたユースケースをサポートしています。XPDLの文法はより冗長で可読性に劣りますが移植性に優れています。歩みは遅いですが、しかし確実に、より多くのベンダーがこの標準を採用しつつあります。 - 非同期Javaアーキテクチャ: 非同期アーキテクチャで動作するために、Javaは真に魅力的なソリューションを提供していません。実際、これは非常に厄介です。
一つに、非同期メッセージのためのJMSとEJBタイマーを備えたエンタープライズプラットフォームが存在します。それらは非常に低レベルなもので、長時間実行されるプロセスをサポートするために、たくさんのデプロイメント・ディスクリプタを書く必要があります。その場合でも、物事がどう繋がっているかのオーバービューは完全に失われます。jPDLではそのオーバービューははっきりと可視化され、サーバの再起動なしに再デプロイを行うのも朝飯前です。デプロイメント・ディスクリプタに何時間もかける代わりに、ダイアグラムをグラフィカルに操作してプロセス遷移を再設定し、再デプロイするだけです。
もう一つは、標準のJavaプラットフォームには非同期アーキテクチャのサポートが完全に欠けていると言うことです。jPDLは標準のJavaと緊密に統合され、非同期の継続とタイマーを実現するために、プロセス仮想マシンのジョブ実行エンジンを活用します。
今やプロセス仮想マシンの基本的なインフラのおかげで、単一のjPDLプロセスが人間・Javaコード・その他からなる非同期のオーケストレーションを捉えることが可能です。そして、そのロジックは標準のJavaとエンタープライズJavaの間で移植可能になります。 - サービスオーケストレーション: BPELは、サービスオーケストレーションの標準としてサポートされ、広く受け入れられています。BPELはエンタープライズ・サービス・バス（ESB）のレベルで実行されるので、インテグレーションのための技術だと言えます。BPELプロセスは、Webサービスレベルでの（単純すぎる）スクリプト言語だと考えることができます。WSDLサービスは、BPELによって粗粒度のサービスとして記述できます。
InfoQ: どこに行けば読者がPVMについてもっと知ることができますか？
Tom: まず第一に、jBPM Community Dayが6月6日にダブリンで開催されます。これはコアjBPM開発者やパートナー、クライアント、jBPMについてより知りたいと考える他の人々と接触できるすばらしいチャンスです。これはフリーのイベントで、金曜の午後に開かれます。詳しくは、jBPM Community DayのWikiページをチェックするか、dublin@jbpm.orgにメールしてください。
二番目は気の短い人向けですが、PVMのマニュアル(source)が存在しており、アクティビティを構築してそれをいかに扱う方法をステップ・バイ・ステップで説明しています。
最後に、"プロセスコンポーネントモデルは次世代のワークフローか？"(参考記事・英語)と言うInfoQの記事がある。これは最近公開された記事で、このトピックに関するさらに詳しいバックグラウンドを知ることができる。
原文はこちらです：
関連情報
InfoQ Japanはコンポーネントスクエアが運営しています
セキュアなIT基盤と付帯運用サービス”SecureOnline”
【無償】「Google Apps 企業向けソリューションセミナー」のご案内
No comments
返信