環境：
.NET Framework 3.0 

こんにちは。ずいぶんとご無沙汰してしまい申し訳ございません。

さて、WF (Windows Workflow Foundation) の SqlWorkflowPersistenceService において、永続化されたデータは SQL Server 上の InstanceState テーブルに格納されますが(「ワークフローの作成とランタイムサービスの利用」 を参照)、このデータは通常は、インスタンスの Complete や Terminate により自動的に破棄されます。(もっと厳密には、ランタイムの停止時ではなく、インスタンスの Complete, Terminate の時点で即座に削除されます。)

ご存知の通り(これは以前からこの仕組みですが)、ASP.NET のアプリケーションでセッションを使用するシナリオでも、例えばクラスタなどに配慮して SQL Server にセッションを保持した場合、無効化されたセッションの情報 (ステートの情報) は SQL Agent サービスにより破棄されます。(厳密には、永続化しないスキーマ構成をインストールしておくと、SQL Server の再起動でも破棄されます。)
そして、Visual Studio 2008 などを使った今後の開発 (「WCF と WF の連携」 を参照) では、こうしたテクノロジーの組み合わせになってくることでしょう。

一般的な言い方をすれば、上述の通り、こうしたテクノロジーを組み合わせたサーバアプリケーション開発では、”インスタンスに対する終了処理さえ正しく実施すれば” トランザクション系の「ゴミ」の削除は自動化されていると考えて良いです。
がしかし、”インスタンスに対する終了処理さえ正しく実施すれば” というところは、現実の開発ではポイントとなってくるはずです。ありがちなシナリオとして、コマース系、もしくはエンタープライズ系の大規模なアプリケーション開発などで、Web サーバ (もしくは Web ファーム), アプリケーションサーバ (もしくは アプリケーションファーム) に分離した構成を連想してみてください。一度永続化された場合、Terminate を呼ばずに終了するとゴミが残ります。WCF / WF 連携における WF のクライアントが Web サーバ側にあるこのようなケースにおいても、作業を中断した「ゴミ」が残らないようにするための WF の終了方法に関する設計や、あるいは廃棄のための仕組みの設計などを入念に実施しておく必要が生じるわけです。(無論、PersistenceService を継承して自身で独自の永続化のエンジンを作成する場合には、ここに、その方針をここに埋め込むこともできるでしょう。)

ここでは些細な例を記載しましたが、現実の開発では、例えば、負荷分散 (ロードバランス) やフェイルオーバーをどう構成するか、ステートフルな場合はステート情報をどう管理すべきか、など、グランドデザインのレベルからさまざまな設計上のポイントが生じてきます。そして、こうしたテーマは、もはやデベロッパーや IT Pro などの垣根を超えた内容 (相互での調整が必要) になってくることでしょう。
今後、最新の .NET Framework 3.0 および 3.5 を使用して、こうしたエンタープライズ系のシステムを構築していく場合の留意点や設計、インフラの展開方法など、より実践的な話題をテーマに、デベロッパーの方向け、IT Pro の方向けのセミナーやオンラインの情報を提供したいと思っています。
まずは、「IT Pro 道場」を対象にスタートを検討中です。