 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| Windows Workflow Foundation（WF） | ||||||||||||
|
次にWFについてみていきましょう。WFは、その名の通り、いわゆる「ワークフロー」の仕組みを.NET Framework上に実装したものです。WCFが通信に対する開発の新しいフレームワークであるように、WFはプロセスに関する新しいフレームワークを提供します。 開発者が従来記述していたコードをより可変性の高い部分と不変な部分に分離し、可変性の高いものについて、従来のようなソースコードによる実装ではなく、モデル駆動的な方法で実装できるようにした新しいフレームワークです。 このモデル駆動的な実装は、コードで記述することも可能ですが、開発ツール（Visual Studio）に付属しているデザイナーを使ってビジュアルにモデル化することが可能です（図1）。デザイナーをエンドユーザにホストし、エンドユーザによってフローを組み替えてもらうようなアプリケーションも構築できます。  図1：デザイナーによるワークフローの開発 （画像をクリックすると別ウィンドウに拡大図を表示します） このWFは、開発者にとっては、WCF以上に扱う上での知識と経験が必要とされます。まず、当然のことですが、どんなプロセスでもすべて可変に作ればよいというものではありません。可変性が向上する分、そのオーバーヘッドも大きくなります。 つまり、可変な部分と不変な部分を明確に分離するということが必要になってきます。ところが、実際のビジネスの活動を連想していただくとわかりますが、何が可変で何が不変であるかということを分析して分離することは、実は非常に難しい作業です。WFは非常に優れたフレームワークですが、このような分離ができない性質のアプリケーションや完結性の高い処理では、むやみに使うべきではないでしょう。 ワークフロー開発といっても、ただフローを組み立てるだけではありません。再利用性の高い「アクティビティ」の作成も可能です。また、承認プロセスなどのように生存時間の長いワークフローでは、それらをメモリからディスクに退避する処理なども必要です。こうした永続化などのワークフローに対する横断的な処理は、「サービス」としてワークフローのランタイムにプラグインしていくことができるようになっています。カスタムのサービスを作成することも可能です。 また、この仕組みが、.NET Frameworkという「基盤」の中に組み込まれていることには理由があります。サービス指向的な開発で活用できることはもちろんですが、何も「サービス指向」や「ビジネスプロセス管理」と大上段に構えなくとも、より日常的なアプリケーション開発においても、こうした実装が活用できる場面が多く存在するでしょう。 例えば、データのステータスの操作やルールに応じた画面遷移を行うアプリケーションにおいて、社内のルール変更などの周辺環境の変化に応じ動作を変える必要があるとあらかじめわかっている場合は、こうした部分の実装をワークフローによるモデル駆動な実装として分離しておくことで保守性が向上します。 こうしたケースでは、承認プロセスなどに見られるような逐次実行型のワークフローよりも、イベント駆動による状態遷移型のモデルが向いている場合が多いでしょう。WFでは、こうしたシステム的なワークフローも作成することができるようになっています。 つまりWFは、ヒューマンワークフローからシステムワークフローまで、開発の様々な局面において活用できるようになっています。事実、SharePoint Server 2007では、そのワークフロー実装のエンジンとして、内部では.NET Framework 3.0 のWFが使用されています。 今後マイクロソフトからリリースされる製品についても、もしワークフロー的な処理が必要な箇所があれば、きっとこのWFを基盤として機能が提供されるはずです。.NET Frameworkという基盤の中にこのワークフローエンジンが含まれているため、様々なレベルのワークフローの処理で、似て非なる別々のテクノロジを習得する必要はありません。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
