ちょっと拡張してみたけど...

提供されているJBPMThreadServletがあるけど、コマンド実行してくれるスレッドとスケジュール管理（監視）するスレッドは無条件で起動される。んなもので、Servlet自体、新しく設けて、その部分は外だしで利用者が必要時に利用できるようにしてみた、DIで定義だけにして、タイマー制御はちょこっとSpringを拝見。
タイマー監視すると、標準なServiceを利用するとTimerテーブルを指定した間隔でSQLをなげて、該当アクションがあったら実行してくれる。指定を間違えると、ものすごいSQLがたくさん発行される。->DBじゃなくした。
普通に使うとJBPMのAPI依存になるので、勉強がてらにjBPMContextを保持したInterceptorを設けて、アノテーションでプロセス開始、終了、ノードの遷移を指定できるようにして、ベタな記述をへらしてみた。退場遷移にて条件分岐が発生する場合は未考慮。アノテーションがいいかは要検討。また退場時の条件分岐も

@leave(name="isSuceed")
public boolean isSuceed100() {
   return hoge.amount > 100;
}

みたいな感じで、ActionとServiceの層の間で、上記メソッドとアノテーションが取得できるインターセプタか何かでもおいて、ノードの退場先は判定するかな。でも、逆にそんな風に分けるのもうざいかな？どうせ、上記メソッドをService層/クラスにもたせるんだったら、そのまま return "isSuceed100"って感じにして、JSFとおんなじ感じでもいいかな。状態遷移の制御のためのロジックがService層にあっても、別におかしくないといえばおかしくないけど。うーん。考えどころだな。

ビジネスカレンダ機能があって、営業時間とかを利用するやつなのだが、たぶん、本番では、DBで祝日もあわせて持つようなことがほとんどなので、利用しないことにした。

ってな感じで、ちょっとやろうとすると、ぶちあたる。他にも、jBPMテーブルにアクセスするためのDaoとかも一度だけだけど、利用者の要件によっては作る必要があるんだろうなぁとか。結局は、そのまま使える部分が少ないと思う。実際の開発で時間があるんなら別だけど。（まずない）だから、jBPMのforumも、あまり書き込みがされていないんだろうな。（推測）

うーん、実装面では、例えば、この人でこの条件（状態）だったら、こう処理しようというロジックがjBPM側で判定できるので、IF文とかは少なくなってシンプルになるんだろうな。

jBPMは、何かもったいないような気がする。クラス設計(ProcessDefinition,ProcessInstance,TaskInstance,など）はシンプルでわかりやすいのに。

でも、時間が。。。趣味と違って仕事には納期があるし。。。。

デザイナpluginは何でswimlaneの概念があるのに、役割を並べて表示しないんだろう。。。