1

私は、SOAP Webサービスの「非同期」モード、「二重」モード、または「コールバック」モードとさまざまに呼ばれるものを使用する必要があるプロジェクトを検討しています。このモードでは、サービスの呼び出し元はSOAPヘッダーで「reply-to」アドレスを提供し、サービスはHTTP応答で呼び出しの出力を返す代わりに、この「reply-to」への個別のHTTP接続を作成します。 "アドレスを指定して、応答メッセージを投稿します。これは通常、次のように、CompositeDuplexBindingを使用してWCFで実現されます。

<binding name="async_http_text">
    <compositeDuplex clientBaseAddress="http://192.168.10.123:1234/async" />
    <oneWay />
    <textMessageEncoding messageVersion="Soap12WSAddressing10" />
    <httpTransport useDefaultWebProxy="false" />
</binding>

これにより、呼び出しごとに1つではなく2つのHTTP接続が発生します。1つはクライアントからサービスに、もう1つはサービスからクライアントに戻ります。サービス実装の観点からは、何も変更されません。インターフェイスメソッドを実装するメソッドがあり、要求を受け取って応答を返します。素晴らしい、これは私がほとんど必要としているものです。

私の状況では、リクエストとレスポンスは数分から数日まで何でも分けることができます。要求と応答を分離し、後で応答するのに十分な情報が得られるまで（または、特定の状況では決して応答しないまで）状態（メッセージ、応答URIなど）を「保存」する方法が必要です。

必要なばかげたタイムアウト値（有効なものとして受け入れられている場合でも）とともに、メソッドを一度に最大数日間基本的に「一時停止」することにそれほど興奮していませんが、どうすればよいかわかりません。このようなシステムを組み合わせます。

完全に明確にするために、私は標準化団体によって提供される一連の標準を実装しているので、SOAPメッセージのセマンティクスを変更したりプロトコルの実装を変更したりする柔軟性がありません。この種の相互作用は、ReplyToヘッダーがWS-Addressingに実装されたときに意図されていたものとまったく同じです。

どうしますか？おそらく、Workflow Foundationはこの種のことを可能にしますか？

4

2 に答える 2

1

実際、Windows Workflow Foundation (v4) は、この種のメッセージ交換を容易にします。

WF を使用すると、要求と応答を分離し、ワークフローの永続化、アイドル状態、外に出て草刈りなど、基本的に途中でやりたいことを実行できるため、この機能を「無料」で利用できます。情報は次の URL にあります。

デュプレックス (MSDN)

ワークフロー 4 サービスと二重通信

于 2011-02-04T20:38:08.153 に答える
1

このような場合、WCF で定義されている HTTP 二重通信を使用しないでください。セッション、サーバー上に存在するサービスインスタンスなど、他のいくつかの前提条件に依存しているため、単純に機能しません。タイムアウトに関する多くの問題が追加されます。

必要なのは、サービスが一方向のサービスを公開し、クライアントも一方向のサービスを公開するという事実に基づく双方向通信です (サービスは、ある種の配信通知をサポートするために双方向にすることができます)。最初のリクエストでクライアントのアドレスを渡すだけでなく、同じクライアントから渡された複数のリクエストを区別するための相関 ID も渡します。リクエストが完了したら、クライアント サービスを呼び出します。はい、すべてを自分で管理する必要があります。

イントラネット環境にいて、クライアントが Windows ベースである場合は、トランスポート プロトコルを MSMQ に変更することを検討することもできます。MSMQ には、これらすべての要件に対するサポートが組み込まれているからです。

編集：

更新された質問を確認しましたが、あなたのコミュニケーション パターンは Soap Messaging と呼ばれるでしょう。私はWCFでそれをやったことがありませんが、可能であるはずです。通信の両側でサービスを公開する必要があります。必要な契約に正確に従うようにサービスを構築できます。サービスが呼び出しを受信すると、OperationContext.Current.IncommingMessageHeadersWS-Addressing 情報へのアクセスに使用できます。この情報を保存して、必要に応じて後で使用できます。問題は、これらの情報に必要なものが含まれていないことです。最初にクライアントでそれらを埋める必要があります。これは一般に、を使用OperationContextScopeして埋めることで可能OperationContext.Current.OutgoingMessageHeadersです。私が恐れているのは、WCF は「巧妙」であり、発信する WS-Addressing 情報への変更をオーバーライドできるということです。私はおそらく週末に自分で試してみます。

于 2011-02-04T08:47:41.437 に答える