0

現在、Web サービスに関するあらゆる種類の技術的詳細を他のシステムから抽象化するシステムを構築しています。Enterprise Bus に少し似ていますが、それ以上の機能があります。

要求を処理するために Windows Workflow を使用することにしました。要求されたアクションの種類が判明次第、そのアクションを処理するために特別に設計されたワークフローを開始します。ここで、呼び出す Web サービスの一部は非同期であるため、ワークフローは応答を待つ必要があります。基本的な考え方は、コールバック Web サービスを最後に実装し、コールバックが「何らかの方法で」到着したときに、応答を待っている実行中のワークフローにデータを渡すというものです。

これまでのところ、2 つの可能性を見てきました。

  1. 外部データ交換サービス
  2. WorkflowQueueingService

最初のサービスは比較的使いやすいですが、イベント ベースであるため、イベントを逃すとデータが失われます。キューベースのソリューションが必要です。技術的には、すぐにコールバックを受け取ることを知らせる同期応答を取得する前でも、Web サービスからコールバックを受け取ることができるからです。

2 番目のサービスは完璧に見えましたが、使用方法が非常に制限されています。アイテムをキューに入れるのは非常に簡単ですが、その前にキューが存在することを確認する必要があります。また、キューの作成は、アクティビティの実行オーバーライドでのみ可能であるようです。さまざまなワークフローが多数あるため、Initialize オーバーライドで何らかの作業を行う基本ワークフロー クラスがあり、そこでキューを作成したいので、特別な「Initialize」アクティビティを作成する必要はありません。すべてのワークフローを開始する必要があります。また、新しいアイテムが受信されたときの通知を基本クラスにしたいと考えています。したがって、特定のワークフローは、キューにデータがあることを知るために WaitHandle を待つだけで済みます。

私が言及した 2 つのサービスを使用する必要はありませんが、できる限りシンプルに保ちたいと考えています。

4

2 に答える 2

1

WF では、ランタイムまたはサービスと実際のワークフローとの間のすべての通信はキュー ベースです。ExternalDataExchangeService はイベントを使用しているように見えますが、これらは WorkflowQueueingService および WorkflowQueue メカニズムの薄い層にすぎません。

一般的には、完全な制御が可能な WorkflowQueueingService を使用することを好みます。基本を理解すると、ほとんどの場合、ExternalDataExchangeService を操作するのがさらに簡単になります。

于 2009-01-08T13:11:52.523 に答える
0

私の仮定が間違っていたことが判明しました。シナリオをテストして問題が発生したことは 100% 確信していましたが、同僚と話し合った後、再テストしたところ、ExternalDataExchangeService は問題なく動作しました。したがって、より複雑なソリューションを見つける必要はありません。今のところ、ExternalDataExchangeService を使用するだけです。

于 2009-01-27T22:37:01.863 に答える