.NET Framework 3.
WFを使用することで、
そこで、
その前にここで、
① WFの機能
WFは、
ワークフローでは宣言式の長時間実行プロセスとしてプログラムを表現することができます。WFは、
WFは、
WFでは、
WFで使用される用語はおもに2つです。
- ワークフロー
-
ワークフローは、
アクティビティのマップとして定義されたヒューマンプロセスまたはシステムプロセスのモデルです。 ワークフローベースのプログラムは、
宣言XAML （Extensible Application Markup Language） 文書内に指定されます。これは、 ドメイン固有アクティビティの見地からプログラムの構造を指定する文書です。 - アクティビティ
-
アクティビティは、
ワークフローのステップであり、 ワークフローの実行、 再利用、 および構成の単位です。 アクティビティのマップは、
ルール、 アクション、 状態、 およびそれらの関係を表します。アクティビティを配置してデザインされたWFのワークフローは、 .NETアセンブリにコンパイルされ、 ワークフローランタイムおよび共通言語ランタイム （移行CLRと略します） で実行されます。 アクティビティは、
C#あるいはVisual Basicなどの従来のCLRベースのプログラミング言語で実装されます。
WFベースのアプリケーションは、
また、
② WCFの機能
WCFでは、
WCFは主にWCFランタイムと、
WCFは設計時にこれらのさまざまな分散システム技術を選択する必要性をなくし、
- （出典:Microsoft社 MSDNライブラリ）
WCFで使用される用語は主に3つです。そしてそれらはWCFサービスの記述
- アドレス
（Address） コントラクトのエンドポイントを、
ネットワークアドレスに紐付けて （バインディング定義を使用、 すなわち名前によって） 展開します。 - バインディング
（Binding） トランスポートに加え、
サービス品質、 セキュリティ、 およびその他のオプションを指定するサービスのバインディングを選択または定義します。 - コントラクト
（Contract） コントラクトを定義してサービス上で実装します。
ここで、
コントラクトにはサービスコントラクトとデータコントラクトがあります。 サービスコントラクトはインターフェイスの形態とルール、
および関連するメッセージと操作を定義します。データコントラクトは操作の入出力メッセージを介して交換されるデータの形態とルールを定義します
これらの 3つの要素が独立していることはとても重要です。
これらがそれぞれ独立していることにより、
サービスは、
これにより、
③ WCFとWFを統合したアプリケーションの設計手順
WCFとWFを統合したアプリケーションを設計する場合、
対象業務の流れの把握
まずは業務の流れを把握することから始めます。これには一般的にはビジネスフローダイアグラムやビジネスワークフォローなどが用いられます。
最初はできるだけ細かい単位で作成します。慣れてきたらそれぞれのビジネスフローダイアグラムやビジネスワークフォロー間の接続や連携、
これにより、
これができたら、
WFの適用検討
シナリオができたらWFでの設計を検討します。その際、
この2種類の選択基準は以下のようになります。
- シーケンシャルワークフロー
比較的単純な業務の流れで、
処理が継続的に流れていく場合。ただし、 処理は必ず処理開始から処理終了まで流れる。 一般的にワークフローで実現できる場合が多い。
- ステートマシンワークフロー
イベントにより呼び出され、
状態が変化していく。状態は必ず初期状態から始まり、 最終状態で終わる。状態の遷移までには時間がかかることもある。 一般的にワークフローではなく、
状態遷移図で設計する。
どちらのワークフローを使用するか選択し決定したら、
シーケンシャルワークフローを選択しワークフローを書き始めたが、
その場合はアプリケーションを分けてそれぞれを連携させる方式にしたほうがよいでしょう。
WFの設計
今回のWFの設計時にはWCFと連携していることを意識して設計する必要がります。
それは通常のWFの設計であれば、
また、
ただし、
- 異なるクライアントから同じワークフローインスタンスを呼ばない
グローバルインスタンス化されたワークフローは、
さまざまなクライアントから呼び出すことができます。しかし、 既に呼ばれているインスタンスを別のクライアントから呼び出されるとエラーが返されることになります。これは既に呼び出されているクライアントからのバインディング時にユニークなGUIDが生成され、 保持されています。そのため、 別のクライアントから呼び出された時にこのGUIDの不一致によりエラーが発生してしまいます。 - 持続ワークフローサービスを利用してネットワーク共有から異なるクライアントでステータスが同じワークフローインスタンス呼ばない
これも同様に既に呼び出しているクライアントとのGUIDの不一致によりエラーが発生してしまいます。
WCFの設計
WFと連携してサービスとして公開する場合、
データコントレクトにはワークフローとデータをやり取りするためのデータを設計します。この際、
また、
これによりWCFを経由してWFのワークフローがサービスとして公開されることになります。こうして公開されたサービスは、
その他のアドレス、
④ WCFとWFを統合したアプリケーションの設計時の注意点
このように、
- ワークフローでカスタムメイドしたWCFを含むアクティビティは多用しない
ワークフローとサービスは基本的に非同期で実行されます。そのため、
WCFを含むアクティビティを使用する場合、 意図しない時間がかかることがあります。また、 WCFでの通信にはコストがかかるものもあります。これらを多用することにより、 リソースを圧迫することもあります。 - 長時間ワークフローをWCFと連携して構築してサービス化する場合はリソースに注意する
長時間ワークフローでは途中経過のデータを保持する必要があります。これらは通常セッションとして保持されますが、
WCFと連携する場合、 連携時に生成されたデータも保持する必要があります。これにより、 設計時には意図しなかったリソースを圧迫することもあります。 - Webサービスとして公開する場合はさまざまな入力アクティビティを用意する必要がある場合がある
Webサービスとして公開する場合、
接続されるクライアントが多枝にわたる場合があります。そのため、 それぞれのクライアントにあったプロパティを持ったアクティビティを作成する必要があります。ここで、 動的なプロパティを持ったWCFの構築を検討する方法もありますが、 あまりお勧めできません。なぜならば管理が煩雑になるばかりでなく、 実行が遅くなる可能性があります。
⑤ .NET Framework 3.5でのWCFとWFの統合
.NET Framework 3.
ReceiveActivity
WCFサービスコントラクトによって定義された操作を実装するサービス側アクティビティ。
ワークフローでWCFサービスコントラクトに定義された操作を実装する場合は、
ReceiveActivityアクティビティでは、
- 一方向の受信
メッセージを送信するクライアントは、
応答を送信するサービスを想定していません。
- 要求の受信 － 応答の送信
メッセージはReceiveActivityアクティビティによって受信および処理されてから、
応答はクライアントに送信されます。
- 要求の受信 － エラーの送信
メッセージはReceiveActivityアクティビティによって受信および処理されてから、
応答またはエラーはクライアントに送信されます。
- （出典:Microsoft社 MSDNライブラリ）
SendActivity
WCFサービス操作の同期呼び出しをモデル化するクライアント側アクティビティ。
SendActivityアクティビティを使用すると、
- 一方向の送信メッセージ
SendActivityアクティビティはメッセージを送信しますが、
サービスからの応答を想定していません。
- 要求を送信し、
応答を読み取り SendActivityアクティビティはメッセージを送信し、
応答をサービスから受信するまで待ちます。
- 要求を送信し、
エラーを読み取り SendActivityアクティビティはメッセージを送信し、
応答またはエラーをサービスから受信するまで待ちます。
- （出典:Microsoft社 MSDNライブラリ）
これらのアクティビティが追加されたことにより、
今まではWFからWCFの呼び出しを行う場合、
また、