メモ - wakizakash

いじっていて気になったことを自分用にメモ。後で整理。jBPMやった後でburiをみると、気づくこと、抵抗があることがある。まだ勉強中なので理解できてない部分もあるけど。。。

まずは大きい印象としてjBPMはプロセスが中心にある、buriはデータが中心にある。

これはburiがワークフローに特化しているっていう点は踏まえておくにしても、プロセスの開始が実際にデータを登録して始まるっていうのがミソ。jBPMはProcessInstanceのインスタンス化するところから始まるからちょっと抵抗があった。基本的なコンセプトとして、そんなAPI駆使しなくても楽チンだよーっていうのがあるからなんでしょうな。モノがあって業務が流れるというのを素直に表現しているといえば、そんな感じかも。メールを出すだけのactivityで始まるなど、情報化しないアクティビティって実際にユースケースとしては無いのかな。

そんなもので、フロー(XPDL)にDao操作を記述(省略可）する。このDao依存もちょっと抵抗あった。フローの単体テストクラスがDaoの不具合によって異常終了することがあるから。またDao/Dtoが決まってないと仮決めで置くことになる。

あとBuriはユーザも中心にある。jBPM Process Designerをみてもわかるけど、swimlane無い。あくまでプロセスが中心。人の変更の方が変更が激しいからだろうか。で、jBPMの場合は別画面でassignment(Role)を設定する。ちなみに設定なくてもいけてしまう。これはどうなんだろうかなぁと思う>jBPM.
なので、Dao/DTOなくても、ユーザ情報なくても、フローの制御、テストクラスの作成ができる。ある意味アジャイル。

jBPMにはjBPM Identityなるユーザ情報(グループ情報)を管理できる別コンポーネントがあるのでユーザ情報と権限情報を扱う場合にはこれを併用することになる。jBPMはセキュリティ関連はザルで、たいしたことやってない。んなものでロシア人作のRunaWFEなるものがjBPMベースであったりして、これはセキュリティ面を強化しているらしい。

ユーザ情報は悩ましい。BuriにもBuriUserがあるけど、実案件だと既にログインテーブルとかあったりしてユーザ情報は2重で持ちたくないっていわれそうな気もするし。

追記BuriUserは、ユーザ管理のユーザ情報とぶり管理するための情報との変換テーブル、ということでした。

次に大きな違いは”Bao”っすね。やっぱり。jBPM先に調べてよかったと思う。じゃなきゃBaoのありがたさは意識できなかったかも。単純にBaoを決めうちのように利用するだけで終わってたかもしれない。jBPMだといくつかAPI覚えないといけないし。依存関係もあるし。Baoはプロキシって感じ。普通はDao使って登録するところを、Baoを通すことによって、Daoで登録して、状態とそのデータの関連を保持して、みたいな。厳密にはそれだけじゃないけど。

後は箇条書きでメモ。
jBPM(jPDL)にpackageの概念がない
Buriはpackage内のプロセス間の呼び出し（開始など）にext-attに対してBao命令を書く
JaWEの赤いプロセス終了とjBPMのend-stateはイコールじゃない。イコールなのは別途、終了activityを用意する。

XPDLにdeadlineってある。
XPDLにビジネス例外がある。

JaWEのTool activityのtypeでprocedureがプルダウンで選択できるけど、XPDL仕様上deprecatedになっている。今はApplicationのみ。

まだまだ、準備段階。。あとLimitまで1週間ぐらいだ。。。気合。