ご存知の方も多いと思いますが、先週ロサンゼルスで Microsoft Professional Developer Conference 2005 (PDC05) が開催されました。概要は日本の MSDN のWeb でも紹介されています。ただし日本の開発部隊は、調布のオフィスに籠もって Visual Studio 2005 開発の最終的な仕上げ作業の最中なので、残念ながら、PDC05 の観客の熱気を直接感じる機会はありませんでした。
それでも Web や社内のメールを通して入ってくる PDC05 の話題として、Windows Vista 関連、LINQ などの「VS2005 の次」をにらんだ技術の紹介、Expression、Project Atlas そのほか、これでもかというくらいいろいろな新技術が紹介されているのを見ると、開発担当の一人としては、「これからたんへんだ～」と思うと同時に意味もなくワクワクしてしまいます。
その中で今回 Windows Vista 関連のプラットフォーム技術として、以下の３つについての詳細が語られました:
- Windows Presentation Foundation (Avalon)
- Window Communication Foundation (Indigo)
- Windows Workflow Foundation (WWF)
(余談: 1 の Windows Presentation.. とタイプして、次にどうしても Manager と打ちたくなる私はだいぶ古いかもしれません..)
上の 1 と 2 はずいぶん前から社外にも紹介されています。しかし 3 については (日本の) MS 社内でも今まであまり語られていなかった部分です。
それでもちょっと調べてみると、すでに英語版としては WWF の Developer Center (英語)やコミュニティ サイト (英語)まで立ち上がっており、サンプルのダウンロードもあったりで、なかなか良いスタートを切っているようです。
PDC ではちょっと地味な WWF ですが、せっかくなので米国本社 WWF アーキテクトである Dave Green の最近の Blog を、本人の承諾を得た上で日本語に翻訳してご紹介したいと思います。私自身は翻訳が専門でない上、Blog というかなりラフな原文を元にしているため、多少の不備はお許しください。
http://blogs.msdn.com/davegreen/archive/2005/09/17/470704.aspx (原文)
What is Workflow, and why bother?
ワークフローとは? そしてなぜそうなのか?
ワークフロー、この使い古された言葉は、その説明にもなり、またその説明の妨げにもなってきました。ですからワークフローという言葉について、私が意味するところを 始めに説明した方がよいと思います。
ワークフローは、最終的に二つのアイディアに行き着きます。一つは「ワーク(仕事)」としての存在です。ワークフロー的には、各々の仕事内容ごとのざっくりとした単位として考えられます。もう一つは「流れ(フロー)」で、こちらはどの仕事をいつ処理するかということを意味します。
だとしたら、下のコードはワークフローでしょうか?
public void HandleLoanRequest (string customerID, Application app)
{
if (CheckCredit(customerId, app.Amount))
{
MakeOffer (customerId, app);
}
}
私はこれもワークフローだと考えます。この仕事は顧客の預金残高を確認したのち、何らかのサービスの提供を行います。そして HandleLoanRequest はこの作業が可能か、またどのようなときに実施されるのかについて定義します。
しかし、ワークフロー ツールの開発会社としては、完璧にその仕事を成し遂げるために、ここに示したコード以上の何かが必要であると、ずいぶん以前から感じているという事実があります。これは、私たちがワークフローのためのキーとなる概念を、未だ見つけていないということを示しています。
私としては、これは私たちが単にフローを記述できるだけではなく、記述したフローを精査し、推論し、操作できるようにする必要があるということだと思います。単純に言って、ワークフローにはモデルというものが必要なのです。
C# (などでコードを書くこと) はそのための一つの方法です。例えば私たちは、ワークフローのために書いたコードをスキャンして、それを基にフローのグラフを描くためのコーディング標準を定義することはできます。
または開発者のために属性を定義して、それを使って開発者の既存コードの特定の部分を呼び出し、モデルを形成するようにできたかもしれません。ただし、これは 私たちがWindows Workflow Foundation のために選択したことではありませんでした。詳細は今後お話しすることになると思いますが、ここでは私たちが行った様々な選択について、その理由を説明しようと思います 。
まずは、なぜモデルが必要かというところまで戻ってみましょう。私たちはモデルを作るために手間隙をかけなければいけないとして、なぜそうなのでしょうか? またその見返りとして何が手に入るのでしょう? (or the beef, as this Englishman abroad is learning to call it)
その見返りはモデルが可能にすることから来るのではないかと思います。
可視化 - 開発者にとって可視化は、開発時およびメンテ時に役に立ちます。また同時に利用者にとっても、なぜワークフローが決められたとおりに動作するのか知りたい場合、またIT プロにとっては、どのアプリの挙動がおかしいか、またはおかしいと思われるかを知りたい時などにも便利です。
表現性 - ワークフロー モデルは、ある特徴的な問題に対処することに特化したドメイン特化言語(DSL)です。一つの例として、あるドキュメント レビュープロセスを考えてみます。このプロセスでは、5 人のうち 3 人がレビュー結果に OK したら合格とし、それ以降のレビューを不要とします。このプロセス の場合、コーディングするにはいささか退屈ですが、Windows Workflow Foundation では、このような問題に対応する機能も持っています。
実行 - Windows Workflow Foundation のランタイムは、モデルを利用することで、同じ問題を何度も何度も解決する手間を省くことができます。状態管理と補正などの長期運用されるワークフローの難しい問題に対処するため、私たちはWindows Workflow Foundation の中に、シンプルかつ表現性の高いモデル要素によってコントロールされたサポート機能を組み込みました。
モニタリング - モデルの存在は、特定の意味情報を持ったイベントの流れの生成を、開発者の追加作業なく行うことを可能にします。これはワークフローまたはその集合体のインスタンスをモニターするために利用可能です。Windows Workflow Foundation は、ワークフローの状態から取得したアプリケーション データを使ってイベントの宣言的修飾を可能にし、それによって、例えば預金の確認がオーダー #14532 のために開始されたことを伝えることができます。
変換 - モデルはモデルを生みます。例としては、あるワークフロー モデルのメッセージ交換形式への変換は、PDC で Dharma と Don が行った素晴らしいデモのように、それとのコミュニケーションを必要とします。もう一方の変換はカスタマイズです。ISV がワークフロー製品を出荷すると、それを VAR がカスタマイズし、そして顧客がまたカスタマイズします。しかる後その ISV が新しいバージョンの製品を出荷します。ワークフローにとって、共有され正しく理解されたモデルの利用は、結果として生まれた3重のカスタマイズをより扱いやすくします。
構成 - もしアプリケーションが「ワーク」と「フロー」に分解できるならば、それぞれの「ワーク」の最小単位の要素は、正しく理解されたインターフェース を通して他のワークフローに再利用可能になるはずです。ワークフロー自体は「ワーク」の有効な定義の集合体であり、他のワークフローによっても利用可能なのです。
カスタマイズと変換を組み合わせることで、「ワーク」と「フロー」のそれぞれの定義を共有可能、または相互にやりとり可能となるエコシステムを実現できます。
操作 - ワークフローを実行中に生成したり、変更する必要が生じることは珍しいことではありません。それがコード変更であるならば、たとえユーザーが対処方法を理解していたとしても、セキュリティ担当者にとっては問題となるでしょう。モデルを利用することで、動的な操作が可能となり、それはコントロール可能かつ容易です。Windows Workflow Foundation はワークフローの型とインスタンスに対し、動的な変更を行うことをサポートしています。
私の説明はこれで終わりです(少なくともこれが、この土曜の午後に思い浮かんだことのすべてです)。 上記の理由により、モデルというものが良いアイディアだと私たちが考え、優れた ROI (投資利益率) をもたらすと確信しているのです。しかし、これらがあなたのシナリオに恩恵をもたらさないと考える場合は、(Windows Workflow Foundation に頼ることなく) あなた自身がコードを書くことが最良の方法となるでしょう。
posted on Saturday, September 17, 2005 4:04 PM by Dave Green