もう少しだ

jBPMの理解/英語離れ防止/より多くの人とのつながり/などから、翻訳をお手伝いさせてもらって、ようやく峠はこえたかな。(ソースみながら、動かしながらやって時間もそれなりにかかったけど）
http://www.jbug.jp/cgi-bin/fswiki/wiki.cgi?page=JBoss+jBPM%A5%E6%A1%BC%A5%B6%A5%AC%A5%A4%A5%C9
もうちょっと残っているのと、自己校正をして、用語登録を整理して、DocBookの準備をして、ひとくぎり。
他メンバーに校正してもらえるところまでもう少しです。


感想としては、基本的にはjBPMは、グラフ指向の共通基盤という印象が強く、そのままでも利用できるが、拡張しなければいけない部分もおおいと思う。strutsベースで自社FW開発しましたーっていうのと一緒。ただ拡張性を売りにしているが、Interfaceがきっている、xmlで指定すれば切り替えられる、という部分はそれとして、「拡張できる」というのはわかるが、「拡張しやすい」とは思えなかった。たしかに、そこからInterfaceきってたら、どうにでも実装（拡張）できるけどなぁ、というのがひとつ。情報量が少ないというのが２つ。

You can customize the JBPM core any way you'd like--classes, tables, hibernate mapping files, whatever;
 in JPBM 2, I added a "notes" table with mapping and modified another class/table/mapping to 
add a "state" reference. However, doing so will likely break compatibility with future versions and 
will seriously limit your ability to get help on forums like this one if your changes are extensive.
 Personally, I believe you would be better off learning/using the core of JBPM 
as is (for the most part) and then adding your own customizations on top of that core. 
When thinking about the core of JBPM, I prefer to think "add too" rather than "modify". 

↑http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70266
フォーラムにあった、昔のバージョンの時のコメントでこんなのがあった。自由にカスタマイズできるけど将来的なバージョンとのコンパチを考えると、変更より、できれば、追加するやり方で。。。っていわれてしまうと、ハデな拡張はできなさそうと、いったところ。これが３つ目。


トッツキにくいという（導入しにくい/学習しにくい）印象が強い。


ただクラス構造は、わかりやすいと思う。プロセス変数というのが、ちょっとしっくりきてないが、それ以外については、BPMでよくでてくる用語でクラス/インターフェースがきられているのでシンプルでわかりやすい部分も多いと思う。これがベースにあるのは、決してマイナスではないと思う。ノード入場時/退場時のイベント通知/検出や、ユーザ実装アクションを挿入できたり(AOPじゃない)簡単にできる。JMS連携/内部メッセージングシステム/アクション、ノード、タスクの拡張性、ビジネスカレンダ(ちょっと改良の余地あり）など機能的にも、まあまあいいんじゃないかな。


細かい部分で未実装という箇所もまだある。まだ発展途上なのです。作者は、DSLの方向性も示唆/研究しているみたいで目は話せない。


なので、手間隙かければ改善できる部分は結構あると思う。実際のプロジェクトで利用すると、けっこういろいろでてきそう。ただ要件を聞いたときに、これならできる、できない、これでよければ今はできる、といえるようにはなっていると思う。
独自ビジネスプロセスフレームワークを車輪のごとく作るよりかは、ぜんぜんjBPMベースで作ってもいいと思う。


いろいろ翻訳したり、ソース解析したりしたので、ちょっと愛着がでできている今日この頃。