現在のルール業界における"お作法"は、ステートレス決定サービスに集中しています。またそれにおいて別々のワークフローエンジンがある時点で、意思決定時点で別のステートレスエンジンを呼び止めます。30年に渡るリサーチと開発の後、私たちが提供できるのはあるワークフローエンジンからステートレスなWebサービスを介して呼び出され、美化されたスプレッドシートに要約される、数百万ポンドのライセンス契約（要するにパッケージソフトウェア）なのです。このモデルは実はなかなか実用的です。しかし、馬鹿にするわけではありませんが、このレベルの統合は頑張ってもせいぜい表面的なもので、これらのモデルを統一して更に踏み込んだものにする必要があるのです。

その記事は”プロセスバーチャルマシン(PVM)(source)”から異名を得たものは何か、と言うことに関するjBPM(source)が発行した新聞を基にしている。全体的に考えて、PVMはJavaにとってバイトコードであるものをワークフロー化することなのである。プロセス定義言語から独立しているプロセス実行エンジンである。 KrisはPVM(source)がプロセス実行構成概念を統合することによっていくつかの利点がもたらされることを説明した。

• ルールはプロセス定義内でモデルされることが可能になる
• データ（ストラクチャ定義を含んで）はルールとプロセスの間で共有される
• 統一された監査
• 簡易化された管理機能
• ルールとプロセスインスタンスが、共有コンテキストを介した変更に反応するよう並行に動作する機能

PVMはプロセス中心DSLの部品として機能する。Krisは実装言語の例として、最近発表されたPageFlow(source)（webページ内でコントロールフローを特定するためのワークフロー言語）とRuleFlow(source)（大規模なルールが評価されるべき命令を特定するためのワークフロー言語）と同様に既存のjBPM言語jPDLを挙げた。

Drools 4.0 ルールフローダイアグラム

Krisはプロセスインスタンスの実行する責任がある”ワークアイテムハンドラー”の役割に関して論じた。興味深いのはコンテキストによって異なるハンドラーを持っているということである。これはルールとワークフローベースの開発－テストにおいて、長い間存在してきた批判を打開するのに使用できるかもしれない。

ワークフローはライフステージにおけるその段階によって、振る舞いを変化させることができる。例えばテストにはワークフローの実行を純粋にテストするだけのハンドラーを登録することができる。シミュレーションには実行されるべきワークアイテム、そしてこのシミュレーションを行う人がこれらのワークアイテムを完成、また破棄する可能性の可視化が可能になる。