ぶりってな〜に〜？

実は昨日の続き・・・ちょっと長め（笑）
ワークフローエンジンって言うのが「絵を描いてその通りに何かの状態を管理するもの」と定義したとき、絵を描くところ、何かの状態を管理するところの二つのパーツに分かれる
で、絵を描くというとBPELとかXPDLとかUMLとか独自定義とか何らかの方法で実現しつつ、しかも絵として表現するのかxmlをそのまま書かせるのかとか、色々考えていく事になる
ちなみに、ぶりがXPDLを使ってる理由は開発時点で無料のエディタが手に入りつつ、定義が標準に準拠してたっていうのが理由。その時点でBPELの無料のエディタが手に入ってたらBPELのエンジンになってたかもしれない・・・
で、絵を書いてそれを動かすと。
動かすときに動かす為の準備とか、動かすものの準備とか色々頑張れば環境が作れるんだけど、一般的なワークフローエンジンってこの作業が結構大変っぽい
まともにはぶりしか使ったことがないけど話を聞くと大変そうだった
で、ワークフローをどこに保存するのかっていうのが実は結構重要で、大きく分けて3つの方法があって、RDBに保存する、Javaに変換する、インタプリタで実行する。それぞれメリットとデメリットがあって、面倒ながら説明すると・・・
RDBに保存するとデプロイ作業が意外と手間になるんだけど、複数個のアプリケーションサーバが同一のものを操作するという事でメジャーなエンジンはこの方法をとるんじゃないかなって思うんだけど、実装するとインタプリタ形式になりそうな気がする
Javaに変換するのは変換の時にちょっと時間がかかるだけで多分実行速度は最速だとおもう、ただし、複数個のアプリケーションサーバで確実に同一のものを動作させるって言うのを保証するのはちょっと大変かな
インタプリタ形式はXMLとかRDBとかを見ながら実行する方式で実行速度は低い代わりに定義の修正に一番強いと思う。なのでRDBを使うようなワークフローエンジンはこの方式にすると思うなぁ〜
で、ぶりはというとXPDLを実行時にJavaに変換してclassを読み込む方針。これは個人的趣味で決めた（笑）再起動すれば自動的に読み直すのでそれはそれで良いかなと。あと、フローが変わるなら画面とかも一緒に変えるだろうという判断もあったかなぁ〜
動作の定義はそれで終わるとして次に「何か」を定義しないといけない、これが無いと画面とのつなぎも出来ない
ワークフローエンジンはデータの定義を内部に持ってそのI/Oをする事が多い。これはXPDLの定義をよく見てると気がつくけど、データを定義する所ってちゃんとあってそこに書くことになってるらしいし、メジャーなワークフローエンジンのほとんどがそういう仕様なんじゃないかなぁ〜
ぶりはというと、内部に定義を持つとS2Daoが使えないとか、定義情報をテーブルに展開するのが面倒とか、そんなことしたらSQL書くのが辛くなるからとかそういう理由でテーブルの情報と関係するようにした。これでS2Daoも自由に使えるし、安心だなぁ〜と。
で、あとはエンジンが必要って言うクラスをえっちらおっちら書いてからAPIを使って呼べば絵に描いたとおりにちゃんと状態遷移を管理してくれるよ。めでたしめでたし。
まぁ特にぶりは「どう使えばいいのか」が一番悩むらしいんだけど、使いたく無いものを無理に使うのは精神衛生上良くないと思うな（笑）