Windows Workflow Foundation についてどのような経験がありましたか?

https://stackoverflow.com/questions/115124

02-07-2019
|

質問

私は Web 上の基幹業務アプリケーションでの使用について WF を評価しています。このテクノロジに関する最近の直接の説明を聞きたいと思っています。

ここでの私の主な関心は、プロジェクトの保守性を向上させることであり、おそらく頻繁に変更される複雑なプロセスに取り組む際の開発者の生産性を向上させることです。

私は WF のアイデアがとても気に入っていますが、あまり知られていないようで、私が見つけた多くの古いコメントでは、一度始めると圧倒的に複雑であると述べられていました。

小規模から中規模のプロジェクトでは使用できない (または悪いトレードオフ) ほど過剰に設計されている場合は、それを知っておく必要があります。

もちろん、2006年末から発売されているので、成熟しているのかもしれません。もしそうなら、それは非常に役立つ別の情報です！

前もって感謝します！

解決

Windows Workflow Foundation は非常に有能な製品ですが、まだ最初のバージョンにすぎません :-(

使用する主な理由は次のとおりです。

ビジネス要件を視覚的にモデル化します。
ビジネスロジックをビジネスルールから分離し、ルールを XML ファイルとして外部化します。
ワークフローを XML ファイルとして外部化することで、ビジネスフローをアプリケーションから分離します。
長期間何も起こらなかった場合に自動的に反応する機能を備えた、長時間実行されるプロセスを作成します。たとえば、請求書が支払われていないなどです。
長時間実行されるワークフローを自動的に永続化して、リソースの使用量を抑え、プロセスやマシンの再起動を可能にします。
ビジネス要件に役立つワークフローの自動追跡。

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が必要になる場合があります。

長時間実行されるプロセスがあります。

頻繁に変更されるプロセスがあります。

プロセスの視覚的なモデルが必要です。

詳細については、ポールアンドリューの投稿を参照してください。 Windows Workflow Foundation を何に使用するか?

WFをいかなる種類の視覚的なプログラミングと混同したり、関連付けたりしないでください。それは間違っており、非常に悪いアーキテクチャ/デザインの決定につながる可能性があります。

したがって、そのような要件がある場合は、WF が良い候補になります。もちろん、それは比較的複雑ですが、解決しようとしている問題も複雑です (場合によっては非常に複雑です)。私見ですが、たとえば、イベントハンドラーがアタッチされたオブジェクト (オブジェクトがメモリにないときにトリガーされる可能性のあるイベント) をデハイドレート/リハイドレートするのは非常に複雑です。

「小規模から中規模のプロジェクト」が何を意味するのか判断できませんが、一般的に、プロジェクトに上記リストの少なくとも 2 つの要件がある場合、解決策として WF を検討できると思います。

私たちは大規模な SharePoint アプリケーションで WF を使用しましたが、それは問題ないと言えます。多くのパワーと柔軟性を備えています。そして、Kevin が述べているように、ワークフローの基礎となる概念を理解すれば、それを使ってほとんど何でもできるようになります。

一方で、バージョン管理の欠如など、将来的にアプリケーションに大きな損害を与える可能性がある非常に深刻な問題もいくつかあります。古いインスタンスを実行し続け、新しいインスタンスが更新されたバージョンを使用できるようにするために、xxx-v1、xxx-v2、xxx-v3 という名前の同じワークフローの最大 3 つの並列バージョンをデプロイする必要がありました。本当にお尻が痛いです。ああ、そこには非常に直感的ではない概念もいくつかあります (相関トークン、何??)

仕事でワークフローの使用に携わったプロジェクトがありました。(経営陣からの) アイデアは、私たちプログラマーが「エンジン」とフレームワークとともにワークフローアクティビティを作成するというものでした。その後、プログラマーではない人が、独自のワークフローをエンジンが自動的にロードする DLL にコンパイルすることで、残りのすべてを処理します。

経営陣は、非プログラマーがワークフローを使用してソフトウェア開発を支援するというこの考えに納得しましたが、それはほぼ完全な時間の無駄でした。私たちがこのプロジェクトで解決しようとしていた問題は比較的複雑で、ソフトウェアをほぼ常に変更する必要があることは最初からわかっていました (その計算は他の企業や政府に依存していました)。

最終的な結果は、ワークフローモジュールを他の人が使用できるほど汎用的なものにすることができなかったということです。つまり、ワークフローを使用して作業することを余儀なくされていたのはプログラマーであり、ワークフローが行うことはすべて私たちの邪魔をするだけでした。

私はここ数か月間、Workflow 4.0 を使用してきましたが、ほとんど感銘を受けましたが、習得するのは非常に難しいと感じました。

最新バージョン (.NET 4.0 RC に付属) については、Web 上にも書籍にもドキュメントがほとんどなく、利用可能なトレーニングコースもありません。現在は廃止された 3.0 バージョンに関連する記事しか見つかりませんでした。MSDN のドキュメントですら、根拠は薄いです。

ワークフローデザイナーは決して直観的ではないため、学習するのは非常に困難です。私は StackOverflow 上の 1 人からの回答に頼らなければなりませんでした (ちなみにモーリス、ありがとう!) - 彼の助けがなかったら私はもう行き詰まっていたでしょう。

要約すると、これには可能性があると思いますが、まだ学ぶのはかなり気が狂うでしょう。さらなるトレーニング、ドキュメント、書籍を待ってください。そうでないと、盲目的に取り組むことになります。

昨年、私たちは WF で実用的なアプリケーションを完成させました。現在、このアプリケーションは、非常に大きな銀行が住宅ローンの手続きに使用している、信じられないほど巨大なシステムのバックボーンとして使用されています。peのプロセスには、顧客の申請から与信の承認まで多くのステップがあります。

それは成功しましたが、その過程には非常に多くの問題と危機がありました。また、小規模なプロジェクトの場合は、苦労する価値はありません。

私は MS WF を、K2 のような本格的なエンタープライズワークフロー製品ではなく、低レベルのワークフローライブラリと考えています。これにより、ワークフロー対応アプリケーションを構築できますが、それ自体はワークフローアプリケーションではありません。この能力での私の経験はポジティブなものでしたが、それを中心に多くの独自のインフラストラクチャ (パブリッシュ/サブスクライブフレームワーク、ワークフローライフタイムマネージャーなど) を構築する必要がありました。世の中にあるドキュメントの多くはかなり単純化されており、MS WF に基づいたエンタープライズワークフローアプリケーションの構築についてはカバーされていません。

学ぶのが難しい。かなり柔軟です。プログラマのみを対象とした、エンドユーザー向けのビジュアルツールと混同しないでください。依存関係プロパティのアプローチが気に入るかどうかはわかりません。

それは本当にあなたがそれを使って何をしたいかによって決まります。私は少ししか使っていませんが、MetaStorm (技術的には BPM であることはわかっていますが、まだワークフローコンポーネントが存在します)、Process Choriographer、IBM MQ ワークフローなどのより成熟した製品と比較することはできません。ただ十分に成熟していないだけです。一方、他のサービスが利用できないところは無料で、おそらく仕事を完了させることができます。数百万ドル規模の手術を行うかどうかはわかりませんが、小規模な手術であれば、もう一度試してみるつもりです。あなたが直面する本当のハードルは、それに必要な思考プロセスの変化です。これまでに州システムを扱った経験のある開発者がいない場合、それは大きなハードルとなる可能性があります。

ブライアン、あなたのコメントには返信できませんが、とにかく、バージョン管理とは、すでに実行中のインスタンスを壊すことなくワークフローの基礎となるコードに変更を加え、既存のワークフローに更新を適切に適用することを意味します。「ストック」WF についてはわかりませんが、少なくとも SharePoint 環境ではワークフローバージョンの概念がないため、新しいバージョンをまったく異なるワークフローとして展開する必要があり、メンテナンスの悪夢になります。これは「リハイドレーション」とは関係がありません。リハイドレーションとは、何らかのイベントまたは状態の変化の後に、「休止状態」のワークフローをアクティビティに戻すプロセスです。これはワークフローランタイムによって透過的に処理されます。

WF は SharePoint (WSS 3.0) に統合されており、さまざまな SharePoint Web サイト用にかなりの数のワークフローを作成したので、SharePoint での WF の経験についてお話します。他のワークフローフレームワークと比較すると、WF のスコアは優れています。安定しており (不可解なエラーは発生していません)、ワークフローの設計はかなり簡単で (Visual Studio のワークフローデザイナーのおかげで)、シーケンシャルワークフローだけでなくステートマシンワークフローも使用できます。

もちろん、これは完璧ではなく、開発者が概念を理解するのに確かに時間がかかるでしょう。アクティビティモデル);しかし、「小さなタスク」であっても、間違いなく使えます。

WFFを試したことはありませんが、読んだ記憶がありますレオン・バンブリックによる WFF に関するこの記事そこで彼は基本的に、ソフトウェア開発ツールというジャンル全体がナンセンスであると述べています。いずれかの方法を決定するのに役立つかもしれません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow