私は、Web 上の基幹業務アプリケーションで WF を使用することを検討しています。このテクノロジに関する最近の直接の報告を楽しみにしています。
ここでの私の主な関心は、プロジェクトの保守性を改善することと、頻繁に変更される複雑なプロセスに取り組む際の開発者の生産性を向上させることです。
私は WF のアイデアが本当に気に入っていますが、比較的知られていないようで、私が遭遇した多くの古いコメントでは、一度それに入ると圧倒的に複雑であると述べています。
小規模から中規模のプロジェクトでは使用できない (またはトレードオフが悪い) ほど過剰に設計されている場合、それは私が知る必要があることです。
もちろん、2006年後半から出ているので、成熟したのかもしれません。もしそうなら、それは非常に役立つ別の情報です！
前もって感謝します！
Windows Workflow Foundationは非常に有能な製品ですが、最初のバージョンではまだ非常に優れています:-(
使用する主な理由は次のとおりです。
WFはライブラリ/フレームワークとして提供されるため、ほとんどの場合、WFランタイムをインスタンス化するホストを作成する必要があります。とはいえ、IISでホストされているWCFを使用することは実行可能なソリューションであり、多くの作業を節約できます。ただし、WCF / WFカップリングは完全ではなく、深刻な作業が必要です。詳細については、 http：//msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspxを参照してください。次のバージョンでは、かなりの数の変更/拡張が行われる予定です。
WF（およびWCF）は、Microsoftから出てくる多くの新しいものの中心にあります。PDC中にいくつかの興味深い発表が期待できます。
ところで、ワークフローの複数のバージョンを実行し続けるには少し手間がかかりますが、それはほとんど標準の.NETです。ここから始めて、このテーマに関する一連のブログ投稿を行いました：http: //msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx
ビジネス要件の視覚的モデリングについて。理論的には、これは意図と実装を分離することで非常にうまく機能します。ただし、実際には、純粋に技術的な理由でワークフローにかなりの数の余分なアクティビティをドロップします。ビジネスアナリストに形や線の半分を無視するように指示する必要があるため、そのような目的は無効になります。
関連する質問: Windows Workflow Foundation をいつ使用するのですか? そこでの私の答え：
次のいずれかに該当する場合にのみ、WF が必要になることがあります。
- 長時間実行されるプロセスがあります。
- 頻繁に変更されるプロセスがあります。
- プロセスの視覚的なモデルが必要です。
詳細については、Paul Andrew の投稿「Windows Workflow Foundation を何に使用しますか? 」を参照してください。
WF をいかなる種類のビジュアル プログラミングとも混同したり関連付けたりしないでください。それは間違っており、非常に悪いアーキテクチャ/設計の決定につながる可能性があります。
したがって、そのような要件がある場合は、WF が適しています。もちろん、それは比較的複雑ですが、解決しようとしている問題も複雑です (時には非常に複雑です)。IMHO、たとえば、イベントハンドラーがアタッチされているオブジェクトを脱水/再水和するのは非常に複雑です（オブジェクトがメモリにないときにトリガーできるイベントを使用）。
「小規模から中規模のプロジェクト」の意味を判断することはできませんが、一般的に、プロジェクトに上記のリストから少なくとも 2 つの要件がある場合は、WF をソリューションと見なすことができます。
大規模な SharePoint アプリケーションで WF を使用しましたが、問題ないと言えます。それは多くのパワーと柔軟性を持っています。そして、Kevin が言及しているように、ワークフローの根底にある概念を理解すれば、それを使ってほとんど何でもできるようになります。
一方で、バージョン管理の欠如など、将来的にアプリケーションに大きな損害を与える可能性がある、いくつかの非常に深刻な問題があります。xxx-v1、xxx-v2、および xxx-v3 という名前の同じワークフローの最大 3 つの並列バージョンをデプロイして、古いインスタンスを実行し続け、新しいインスタンスで更新されたバージョンを使用することを余儀なくされました。お尻の本当の痛み。ああ、そこにはいくつかの本当に直感的でない概念もあります (相関トークン、wtf??)
ワークフローを使用して私が関与したプロジェクトがありました。(管理者からの) アイデアは、私たちプログラマーが「エンジン」とフレームワークと共にワークフロー アクティビティを作成するというものでした。次に、プログラマー以外の人が、エンジンが自動的にロードする dll に独自のワークフローをコンパイルすることで、残りのすべてを処理します。
経営陣は、ワークフローを使用してソフトウェアの開発を支援する非プログラマーのこの考えに同意しましたが、それはほとんど完全に時間の無駄でした。このプロジェクトで解決しようとしていた問題は比較的複雑であり、最初からソフトウェアをほぼ常に変更する必要があることを知っていました (その計算は他の企業や政府に依存していました)。
最終的な結果として、ワークフロー モジュールを他の人が使用できるように十分に汎用的にすることができませんでした。したがって、プログラマーはワークフローで作業することを余儀なくされた人であり、ワークフローが行ったことはすべて私たちの邪魔をすることでした。
私は過去数か月間ワークフロー4.0を使用しており、ほとんどの場合感銘を受けましたが、習得するのは非常に困難でした。
最新バージョン（.NET 4.0 RCに付属）の場合、Web、書籍、または利用可能なトレーニングコースにはほとんどドキュメントがありません。現在は機能していない3.0バージョンに関連する記事しか見つかりませんでした。MSDNのドキュメントでさえ、地上では軽いものです。
ワークフローデザイナは、どうしても直感的ではないため、学習は非常に困難です。私はStackOverflowで一人の人からの回答に頼らなければなりませんでした（ちなみにモーリスに感謝します！）-そして私は彼の助けなしに詰め込まれました。
要約すると、それは可能性を秘めていると思いますが、まだそれを学ぶのはかなり怒っているでしょう-さらなるトレーニング、ドキュメント、本を待ってください。
昨年、私たちは WF を使用した実用的なアプリケーションを完成させました。現在は、非常に大きな銀行が住宅ローン プロセスに使用する信じられないほど巨大なシステムのバックボーンとして使用されています。pe プロセスには、顧客の申し込みからクレジットの承認まで、多くのステップがあります。
成功したものの、その過程には多くの問題と危機がありました。また、小規模なプロジェクトの場合は、手間をかける価値はありません。
私は MS WF を、K2 のような本格的なエンタープライズ ワークフロー製品ではなく、低レベルのワークフロー ライブラリと見なしています。これにより、ワークフロー対応アプリケーションを構築できますが、それ自体はワークフロー アプリケーションではありません。この立場での私の経験は肯定的でしたが、それを中心に多くの独自のインフラストラクチャ (pub/sub フレームワーク、ワークフロー ライフタイム マネージャーなど) を構築する必要がありました。世の中に出回っているドキュメントの多くはかなり単純化されており、MS WF に基づくエンタープライズ ワークフロー アプリケーションの構築については説明していません。
学ぶのは難しい。非常に柔軟です。エンド ユーザー向けのビジュアル ツールと混同しないでください。プログラマー専用です。依存プロパティのアプローチが好きかどうかはわかりません。
それは本当にあなたがそれで何をしたいかに依存します。少ししか使用していませんが、MetaStorm（技術的にはBPMであることはわかっていますが、ワークフローコンポーネントはまだあります）、Process Choriographer、IBM MQワークフローなどのより成熟した製品と比較すると、比較はできません。十分に成熟していません。一方、他の人がいない場所では無料で、おそらく仕事を成し遂げることができます。数百万ドルのオペレーションを行うかどうかはわかりませんが、それよりも小さいオペレーションでは、もう一度試してみます。あなたが直面しようとしている本当のハードルは、それが必要とする思考プロセスの変化です。以前に州のシステムを扱ったことのある開発者がいない場合、それは本当のハードルになる可能性があります。
ブライアン、あなたのコメントに返信することはできませんが、とにかく、バージョン管理とは、既に実行中のインスタンスを壊さずに、ワークフローの基礎となるコードに変更を加え、既存のワークフローに更新を適切に適用することを意味します。「ストック」WF についてはわかりませんが、少なくとも SharePoint 環境ではワークフロー バージョンの概念がないため、新しいバージョンをまったく異なるワークフローとして展開する必要があり、メンテナンスの悪夢になります。これは「リハイドレーション」とは何の関係もありません。リハイドレーションとは、何らかのイベントや状態の変化の後に、「休眠状態」のワークフローを活動に戻すプロセスです。これは、ワークフロー ランタイムによって透過的に処理されます。
WF は SharePoint (WSS 3.0) に統合されており、さまざまな SharePoint Web サイト用にかなりの数のワークフローを作成したので、SharePoint での WF の経験について話すことができます。他のワークフロー フレームワークと比較して、WF のスコアは良好です。安定しており (不可解なエラーは経験していません)、ワークフローの設計はかなり簡単で (Visual Studio のワークフロー デザイナーのおかげです)、シーケンシャル ワークフローだけでなくステート マシン ワークフローも使用できます。
もちろん、これは完璧ではありません。開発者は、(アクティビティ モデルなどの) 概念を理解するのに時間がかかることは間違いありません。しかし、「小さなタスク」であっても、間違いなく使用できます。
WFF を試したことはありませんが、Leon Bambrick による WFF に関するこの記事を読んだことを覚えています。彼は基本的に、ソフトウェア開発ツールのジャンル全体がナンセンスであると述べています。いずれかの方法を決定するのに役立つ場合があります。