私は、通常の命令型プログラミングに対して、ワークフロー (つまり WF) の説得力のあるユース ケースを見つけるのに長い間苦労してきました。毎回、WF を除外するか、WF への参加を延期する必要があるという結論に戻ります。しかし、何かが足りないというしつこい感じがずっとあります。
ワークフローの方法を強く主張している本を知っている人はいますか? この本は、(i) WF を十分に説明し、(ii) 適切なユース ケースを使用して、通常のストレート コーディングを行うよりも WF の実装が簡単であることを示す必要があります。
感謝します。
非専門家の観点から、私がWFを主張する2つのことがあります。1つはワークフロープラットフォームに固有のものであり、もう1つはおそらくより便利なものです。
便利な機能は、アクティビティを構成する新しい方法を作成する機能です。命令型プログラミングでは、構成プリミティブの限られたレパートリーのみが提供されます。基本的には、シーケンス、if-else、およびループです。WFを使用すると、インターリーブ実行、並列実行、単純小選挙区制などの独自の合成演算子を構築できます。もちろん、ステートマシンの高度な合成メカニズムが組み込まれています。
これらの演算子はすべてC＃のような命令型言語で作成できるため、これは便利な機能だと思います。実際、これがWF演算子の作成方法です。ただし、WFを使用すると、カスタムコンポジションの使用と読み取りが簡単になりますが、C＃では、ラムダ式が大量に発生します。したがって、複雑なオーケストレーション要件がある場合、つまり、アクティビティを組み合わせる方法がシーケンス、if-else、およびループよりも複雑な場合、WFによってプログラムの表現と理解が容易になる可能性があります。
ユニークな特徴は耐久性です。これは、Shukla and Schmidtの本が始まり、そして戻ってくるところです。C＃またはVBで記述された命令型プログラムは、運が良ければ数時間、数日、数週間、場合によっては数か月間実行できます...しかし、最終的にIISはアプリプールを循環させるか、管理者は最新のセキュリティ更新プログラムをインストールしたいと考えます。 、または誰かが電源コードにつまずく予定です。それでは、あなたのプログラムはどのように覚えていますか？ Eメール"？
従来の命令型プログラムでは、プロセスが終了すると、実行状態もそれに伴って終了します。新しいプロセスを開始できますが、プログラムの最初から開始されます。もちろん、データベースを作成し、それを使用して「発注書を取得」や「クレジット承認を取得」などのフラグを保存できます。ただし、状態を保存してクエリを実行し、その状態に応じてプログラムの適切なポイントに戻るには、アプリケーション固有のコードを作成する必要があります。また、実行時間の長いアプリケーションごとに、新しいデータベースと新しい保存/復元/ジャンプロジックを設計する必要があります。
耐久性のあるワークフローとは、この問題に取り組むことです。プログラムをアクティビティのワークフローとして作成する場合、WFは、実行フローのどこにあるかを含め、その状態を維持します。プログラムを実行しているマシンが発火してデータセンターを焼き尽くす可能性がありますが、銀行からの応答が来ると、WFは他のデータセンターでプログラムをウェイクアップし、適切な場所で適切な場所で実行を開始しますデータ。
それは私にとってWFの「強力なケース」です。多くの場合、それは必要ありません。アプリケーションは十分に短命であるため、障害は重大な懸念事項ではなく、最初から再起動することが実行可能な回復戦略です。ただし、応答に数時間かかる可能性のある外部システムを調整している場合や、応答に数日かかる場合がある人間が関与するビジネスプロセスなど、長期間使用できるアプリケーションの場合、耐久性がWFのキラー機能になる可能性があります。
免責事項：私はWFプログラマーではなく、実際のWFシステムを構築したことはありません。私はBizTalkのバックグラウンドから、そしてWFについて読んだことからこれに来ているので、この評価はちょっと理論的です。それがすべて同じように役立つことを願っています！
あなたの質問に良い答えがあるかどうかはわかりません。問題は、2 つの非常に異なることを求めているため、質問が有効でないことや、そのようなことではありません。
まず、ワークフローを使用する説得力のある理由を尋ねます。これは非常に主観的な質問であり、テクノロジーとはまったく関係ありません。あらゆる種類の成功したワークフローの実装と失敗したワークフローの実装を示しているホワイト ペーパーを Web で見つけることができます。これはテクノロジーに関係なく、製品 X を使用して行われたソリューションは、製品 Y を使用して行われた可能性もあります。Shukla と Schmidt の章は確かに基礎を説明していますが、それがどこでどのように機能するかを示す良い本であるかどうかはわかりません。ワークフローの適用方法。
次に、Windows Workflow Foundation について説明する本を探しています。最初の質問は、WF3 または WF4 です。これらは非常に異なる獣です。.NET 4 がリリースされたときに WF3 に置き換わるため (すぐに) WF4 を想定します。ほとんどの場合、WF3 から始めることはあまり意味がありません。しかし、WF3 はあまり人気がなく、ほとんどの作家にとって本の市場はあまり利益を上げていなかったため、WF4 の本はまだ出ていません。Bruce Bukovics は、彼のPro WF: Windows Workflow in .NET 3.5本の新しいバージョンに取り組んでいると思います。これまでのところ何もありませんが、msdn サイトの非常に限定されたドキュメントと私のようなブログに固執しています。もちろんこんなコースもありますDevelopMentor から (注: 私は主なコースの作成者であるため、恥知らずなプラグインです)
この回答でいくつかの理由を提供しましたここ、これらはあなたに役立つかもしれません.
あなたの質問に対する完全な答えではありませんが、これがすべてあなたにとって役立つことを願っています.
正当な理由は次のとおりです。 ビジネス プロセスの視覚的な概要。クライアント (ドメインの専門家) にデザイナーを使ってワークフローを編集してもらうこともできます。アプリケーションを再起動し、再コンパイルせずに実行します
良い本: Bruce Bukowics と私のいつものお気に入り: PRO C#2010 と .NET 4 フレームワークには優れた章があります
これも直接的な答えではありませんが、他のリソースを検索する場合に役立つ場合があります。私には、WF はビジネス プロセス実行言語 (BPEL)で導入された概念を中心にかなり密接にモデル化されているように見えます。この標準。WF よりもずっと前から存在しており、BPEL を使用すると、WF を何に使用するかがわかります。
私は WF を使用したことがありませんが、BPEL を少しいじってみると、使いにくいことがわかりました。これは主にツールのサポートによるものです (ビジュアル モデリング用の Eclipse プラグインが不足していることに気付きました)。これを、「通常のプログラミング言語の構文」に比べて XML のコードを読むのが難しいという事実と組み合わせると、BPEL は実行可能なソリューションではありませんでした。WF に優れたビジュアル ツールがある場合、この問題は少なくとも解決されています。
このトピックについて具体的に説明した本を私は知りません。ただし、WF (またはその他のワークフロー製品) の魅力の 1 つは、元の OO 関係者 (Alan Kay など) が関心を持っていた、疎結合のメッセージ ベースのパラダイムの可能性を再び導入したことだと思います。
「メッセージ」が渡されるという概念は、WF ではすぐにはわかりません。ただし、個別のマシンとして機能するオブジェクトの概念はそうです。
OO の状態に関するすばらしい (しかしややクレイジーな) 本については、David West による Object Thinking を参照してください。また、OO が彼にとって何を意味するかについての Alan Kay の議論については、 こちらを参照してください。