yojikのlog

yojikのブログです

ワークフローエンジンと依存関係(妄想多め)

wkzkさんのブログをよんで思ったこと。
http://d.hatena.ne.jp/wkzk/20080129/1201577159
ワークフローエンジンとサービス、業務アプリの依存関係って地味に難しそうな問題ですね。
一般的なのは、こんな感じでしょうか。

業務アプリ(画面) → ワークフローエンジン → サービス(業務ロジック+他システム呼び出しとか)

「業務ロジックはサービスとして作成する」「ワークフローエンジンからWebサービスやスクリプトなどを経由して業務ロジックを呼ぶ」「画面側の業務アプリは薄く保つ」「ワークフローエンジンはコントロールとしての役割を果たす」という感じです。各コンポーネント間の連携はESB等を使うかもしれませんが、レイヤ型のWebアプリと本質は変わらないですよね。
多分、ゼロからシステムを作る場合は、これが王道だと思います。各社のSOAスイート製品も基本的にはこの構造ですよね(たぶん)。自動生成などの技術を使えば画面側アプリの作りこみを最小にできそうですし、ESB等を使えばワークフローの状態遷移に連動する他システム呼出も自由自在?でしょう。
この方式の欠点というか気になる点は、複数の業務アプリがあって、それらを生かしたままワークフローエンジンと繋ぎたいという要求に弱そうということです。どうしても作り直しが発生しそうです。(例えば既存の業務システムで普通に保存していたデータを突然承認フローに参加させたくなったとか。。)
というわけで、こんな構造にしたいのです。

業務アプリ(画面+業務ロジック) ← ワークフローアプリケーション → サービス(他システム呼び出しとか)

「業務画面と業務ロジックという関連深いものは一体」「ワークフローアプリは単なるエンジンではなく、業務データの監視とワークフロー(ステート)のブラウズ*1可能なWebアプリ」「ワークフローアプリがデータの変更を検知して、自身で管理しているワークフローの状態データを変更」「必要があればそのタイミングで他システム呼び出し」といった形で連携してほしいのです。ワークフローエンジンがコントロールじゃなくてオブザーバみたいな役目を果たすイメージですね。*2
業務データとワークフロー(状態)の情報を分離、いっそ業務アプリとワークフローアプリを分離するのが目的です。既存の業務アプリで管理されるデータを、業務側の変更を最小限にしつつ、複数の観点のワークフローに参加させることが可能です。こうすれば「蓄積したデータの活用」という業務アプリの本題に立ち向かえるのかなぁと思ってます。T字形の話とちょっと似てますね。
実現手段がまったく思い浮かばないので完璧に妄想だったのですが、flowrのようなURL(リソース)ベースの連携が有望かもしれないと思いました。ブログパーツを特定の画面に埋め込むだけで、業務の変化をワークフローアプリがトラッキングできるようになります。既存の業務アプリに、承認却下ボタンを後付で貼り付けるといった事もできそうです。
ROA時代には必須のパターンになるのではないのでしょうか? (いいすぎ?)

*1:これが微妙に難しそう

*2:BAMの話に繋がってくるかも?