David Chappell氏は、彼の新しい論説「Workflow way」の書き出しとして、優れたサーバー・サイド・ソフトウェアを書くとは何を意味するのかを論じるている。
コードを書く人なら誰でも優れたソフトウェアを作りたいと思っています。サーバー・アプリケーションの場合、拡張性に優れ、多くのリソースを使うことなく大量の負荷をこなすことが優れているという意味の一部分でしょう。また、優れたアプリケーションは作成者とメンテナンスを担当する人双方が理解できるものでなければなりません。これらの２つを同時に実現することは簡単ではありません。アプリケーションに拡張性を持たせるためのアプローチとして、ロジックをばらばらの理解しずらい断片に分割するという手法がとられることがよくあります。一カ所で実行される一つにまとめられたロジックを書くことでアプリケーションに拡張性を持たせるのは、ほとんど不可能なのです。
彼は、このような実装を実現するいくつかの異なるアプローチについて言及している。
- もっとも単純な実装は、1台のマシンの1つのプロセスで実行される一塊のアプリケーションを作成することです。この実装では、通常、次のことを実装しなければなりません。
この単純なアプローチには次のような利点があります。- 単純な文字列型変数で表されたステートを管理する。
- 外部から入力を得る。例えば、クライアントからのリクエストを受信する。単純なアプリケーションでは、単にコンソールから読み取ることもあるだろうし、もっと一般的な例としては、WebブラウザからHTTPリクエストを受信する、もしくは、他のアプリケーションからSOAPメッセージを受信するといったことがある。
- 外部に結果を送信する。実装方式に依存するが、アプリケーションは、HTTPや、SOAPメッセージやコンソールへの書き出し、あるいは他の方法で結果を送信する。
- if/elseやwhileといった制御構文を使って分岐を定義する
- アプリケーションの各所にある適切なコードを実行することで動作する
このアプローチによる制限は次のようなものです。- …ロジックを直接的かつ、ひとまとまりにして実装することができる。これはコードに関わる人が、そのコードを理解するのに役立つし、イベントの出現順が明確になる。
- …アプリケーションのステートの取り扱いが簡単。ステートは、プロセスのメモリに保持される。プロセスは一連の処理が終了するまで走りつづけるので、ステートがいつでも利用可能。
ユーザであれ、コンソールであれ、Webサービス・クライアントであれ、その他の何であれ、アプリケーションが入力を待っている際には、処理をブロックするだけだ。利用しているスレッドとプロセスは、どんなに時間がかかろうとも、入力が到着するまで保持される。スレッドとプロセスは、比較的希少なリソースであるので、入力を待っているだけで、それらを保持し続けるアプリケーションは拡張性に乏しい。
- 入力を待っているときにはシャットダウンして、入力が届いた時点で再び起動するアプリケーション。この方式でも、アプリケーションは、前に述べた方式と同じロジック含みますが、今度は、断片に分断されています。クライアントからの最初のリクエストを受信すると、適切なコードの断片がロードされて実行されます。リクエストが処理され、レスポンスが送り返され、断片はアンロードされます。メモリーには何も残りません。クライアントからの２つめのリクエストがくると、それを処理するコードの断片がロードされて実行されます。このような実装は、Webアプリケーションによくあるものです。特定のページが、特定のリクエストを処理し、アプリケーションは次のリクエストを待ちます。このアーキテクチャの利点は、次のとおりです。
これらの利点はありますが、代償として複雑性も増します。- アプリケーションが不必要にスレッドやプロセスを握りっぱなしにしないので、このアプローチはリソースを無駄にしない。
- … その時々で、アプリケーションを異なるマシンの異なるプロセスで実行させることができる。単一のシステムに縛られるのではなく…アプリケーションを複数のマシンで実行させることができる
- …複数のコードの断片は、何らかの方法でステートを共有しなければならない。それぞれの断片は必要に応じてロードされ、シャットダウンされるので、ステートはデータベースやその他の永続化ストアといった外部に保持されなければならない
- …コードをみても、プログラム全体のロジックを一気に見渡すことはできない…制御フローも一目ではわからない。実際、クライアントからの2度目のリクエストを処理するコードの断片は、最初のリクエストがすでに終了しているかを確認することから始めないとならないかもしれない。重要な業務プロセスを実装するアプリケーションにとって、様々な断片に散らばった制御フローを理解し、実装することは困難を伴う。
- Workflowベースのアプリケーション。Workflowベースのアプリケーションはステートの管理や外部とのやりとり、実行フローの制御、アプリケーション処理の実行といった通常のアプリケーションが行うことと同じことを行います。しかしWorkflowではこれらのことは全てアクティビティとして処理されます。これらのアクティビティが典型的なプログラムの様々な機能に対応しています。伝統的なプログラムが行うようにアクティビティの実行を制御するためにプログラム言語の要素を組み込んで利用するのではなく、ワークフローでのアクティビティの実行はWorkflowランタイムによって制御されます。ランタイムは、アクティビティの実行方法を知っているのです。このアーキテクチャの利点は、次のようなことです。
David氏によって述べられているWorflowアプローチのその他の利点としては、並列実行の制御や、(アクティビティレベルの)高い再利用性、プロセス実行の可視化／追跡などが含まれる。- …Workflowを使った方式は開発者に統一されたフロー制御の方式を与えてくれる。ちょうどプログラムの主要なロジックが明快な流れで定義されている単純な場合のようなものだ。これによってフロー制御を理解しやすくなる… Workflowそのものが制御フローを表している。
- … Workflowは、入力を待つ際に、スレッドをブロックしたりプロセスを使ったりしてメモリに常駐することがない。その他の利点としては、永続化されたWorkflowは、最初に実行されていたマシンと別のマシンで実行される可能性が潜在的にあることだ。このことにより、Workflowのそれぞれの部分が、異なるシステムで実行されるということも起こりえる
David氏の論説の残りの部分では、Windows Workflow Foundation(Windows WF)実装の詳細や、その利用シナリオ、WCFやDublin、ASP.NETといったその他の.NETテクノロジーとの統合について述べている。また彼は、.NET 4で導入されたWFの新機能について概要を述べている。
David氏の論説は、Workflowアプリケーションを構築するにあたってWindows WFがどのように使えるかを述べているが、Tom Baeyens氏は次のように述べている
… (この論説は)WorkflowとBPMエンジンのエッセンスを説明している…BPMエンジンは、JavaやCやCobolといった通常の言語と次の２つの面で異なっている。
- ランタイムのステートが永続化可能である。プロセスの実行のどの時点でもプロセスの実行は中断でき、ステートが保存される。その後、実行ステートが永続化ストレージから取得されて、続きが実行される。
- グラフィカルな表現。BPMプロセスが言語による通常のプログラムと異なる2つめの側面は、BPMプロセスがグラフィカルに箱と矢印を使って表現されるようになっていることだ。
この論説は、Workflowエンジンの動きとWorkflow向きのアプリケーションがどのようなものかを理解したい人には、絶好の読み物だ。