makotan _at_ gmail dot com

用途は？

buri

きっとこれを書かないと完結しない（ｗ
ワークフローエンジン、BPMエンジン、ぶりのそれぞれでおもいっきり違うのがこれかな〜
でも、各種エンジンで違う領域をカバーしたりするので判りにくくなってる

  • まずは、BPMのエンジン

BPELとかを使うタイプのエンジンで、主にシステムのオーケストレーションを目的にしてるのが最大の特徴。システムのオーケストレーションって言うのは一言で言うと複数のシステムを連動させつつ動作させるって事。
具体的にはSOAとかMQとかを使う事が多いので、このためにシステムをSOA対応したりするって話が出てくる

  • 次はワークフローエンジン

XPDLや独自定義のXMLを使う事が多いタイプのエンジンで単一のシステムに閉じてることが多くてその中でのTokenの状態を管理したりするのが最大の特徴。エンジンに画面の定義とかそういうのまでセットになってる事が多くて、これだけでワークフローを使ったシステムを作れるのが売りの一つ。エンジン単独でも使えるようになってるし、監視のGUI等もあるので便利かも
単一のシステムに閉じつつも他のシステムを呼び出せるようにもなってることが多いので、BPMなエンジンとしてみられがち

  • 最後はぶり

正式にはワークステートエンジン、その名の通り状態管理をする為だけのエンジンで、アプリケーションに組み込まれてその中で動作することを前提に作ったもの
S2Daoでアクセスするテーブルのレコード単位での状態を管理するのが特徴。
ぶりは他種類のエンジンをカバーする気もなく、それしかしない＆出来ない事をメリットとして感じる人向け。外部のシステムの呼び出しはS2のコンポーネントを使うっていうのが大前提で、さらに普通はSQLを書いてデータを取得するのでSQLの普通の知識が確実に必要

  • 雑感

個人的には上に書いたものに行くほど大規模の会社向きかな〜って思う
ぶりは単独のアプリケーションに閉じた世界でフラグをなくすことを目標にしてるからプログラマーが楽をする為のツールになると思うけど、きっと山のように使った本格的なアプリとかがサンプルにないと実際の使い方は判ってくれないと思うので、多分流行るのは無理だなって感じた。少なくとも既存のサンプルだと使い方がレアケースすぎかな（笑）
って言える程度にぶりが難しいことが判るようになったオレって偉い？みたいな（爆）
作った頃は「なんでぶりの用途が判んないんだろ」って思ってたんだよ！！
まぁあと数年したら少しは状況が変わるかなぁ〜