Question

LEON2 on Thu, 26 Jun 2008 04:55:27


LEON2です。

 

識者の意見を求めるべく投稿させていただきました。
今回は、WFと業務アプリケーションのかかわり方についてご意見をいただけたら思います。

 

昨今、企業が開発している業務アプリケーションはデータベースを機軸にアプリケーションを構成しています。
このデータベースアプリケーションは以下のような基本形を中心に複数画面を開発し、それらの画面をメニュー画面で束ねておくというのが一般的なようです。

 

データベースアプリケーションの基本形
 1.画面起動後、データベースに必要なデータを照会する。
 2.照会結果を画面に展開する。
 3.ユーザが画面に展開したデータを編集する。
 4.編集内容をデータベースに反映する。
 5.データベースに反映された内容を元に業務ロジック処理する。

 

WFはこの様に開発されてきたデータベース中心の業務アプリケーションをどのように変化させていくのでしょうか?
WFを学習する過程でいくつかのサンプルを見てきましたが、いまだベストプラクティスと呼べるものには出会えていません。

 

「ワークフローは業務を効率化します!!WFでワークフローアプリケーションを作りましょう。」という趣旨のはわかりますが、企業において業務アプリケーションを1から作り直すのは稀ですよね?

 

データベースアプリケーションは画面毎に完結した機能構成になっていて、それをデータベースが結び付けてアプリケーション、ひいてはシステムを構成しています。

WFにおいてワークフローが各画面や機能を結びつける役割となるのなら、データベースの位置関係はどこにあるのでしょうか?
現状のデータベースアプリケーションとWFを結びつける糸口・・・未だ見えません・・・。

 

以上、よろしくお願いします。


Sponsored



Replies

Nobuyasu on Thu, 26 Jun 2008 14:22:26


再び返信させていただきます。

確かにLEON2さんのおっしゃるような形態のアプリケーションでは、業務アプリケーションを最初から作り直すという動機を与えるのは、難しいかもしれません。私の専門はシーケンスワークフローのリホスティングなので、その場合、プロジェクトフローの再構築に関し、アクティビティのドラッグとプロパティの変更だけで済むという利点があります。また、プログラムを組めない人もプロジェクトを修正できるという大きな利点もあります。

 

その名の通り、途中で人手を介したり、イベントを利用するフロー形態の業務アプリケーションやオーケストレーションでその機能を発揮するのではと思っています。画面遷移のみの利用であれば、私もあまり魅力を感じません。

 

しかし、リホスティングに関しても、サンプルは提供されていますが、アプリケーションとしてこなれたもににするには、やはりかなり敷居が高いのも事実です。正に通常の自分の業務ソリューションを離れてCodeDomなどの知識も必要になってきます。

 

USの当サイトに比べて、さびしい状態が続いていますが(苦手な英語で読んだり質問するのが大変^^;)、ドキュメントも日本語化されてきていますので、ゆっくりと深く日本でも普及してゆくのではと楽観しています。