問題タブ [operationcontext]

私は、.NET クライアントから Java ベースのサービスを呼び出すときに、送信メッセージに SOAP ヘッダーを挿入することを検討しています。

以下に示すように、OperationContextScope が私の要件に最適であり、初期テストでは正常に動作することがわかりました。私のアプリケーションは.NETコンソールバッチであるため、これで間違いを犯していないことを確認したかったのです。.NET コンソール アプリケーションのコンテキストでこのクラスを使用する際に問題はありますか?

wsdl と xsd を渡すことで、SVCUITIL を使用して JAVA サービスのプロキシを作成しました。

非同期操作が呼び出されOperationContextた後 (およびスレッド ID が変更された後) に nullを取得することに問題があります。

私はこれが既知の問題であることを知っており、この問題に関していくつかの StackOverflow の質問を投げかけました。

ここで.net 4.6.2読むことができるように、問題の修正があります。

OperationContext.Current 非同期の改善

WCF には、OperationContext.Current を ExecutionContext に含める機能が追加され、OperationContext が非同期の継続を通過できるようになりました。この改善により、WCF は CurrentContext をあるスレッドから別のスレッドに伝達できるようにします。これは、OperationContext.Current の呼び出しの間にコンテキスト スイッチがあったとしても、その値はメソッドの実行中に正しく流れることを意味します。

これを自分の側でサポートしてもらうために何か特別なことをする必要がありますか? 私はVS 2013を使用しており、フレームワークを更新し4.6.2てdev-packをインストールしました。プロジェクトを使用するように変更しましたが、非同期呼び出しの後でFramework 4.6.2も nullが返されます。OperationContext

次の点を考慮してください。

1 つのマスター サーバーと、マスター サーバーと通信できる別の場所に複数のサーバーがあります。さらに (GUI) クライアントは各サーバーに接続できます。

だから私は誰もが知っている公開インターフェースを持っています:

さらに、サーバーはコールバック コントラクトをサポートしているため、マスター サーバーはそれに接続されているサーバーで要求をトリガーできます。

サーバーには2つの実装されたコントラクトがあることを意味します。そのため、マスター サーバーですべてのサブスクライバーを ( SubscribeI cache allOperationContextで) 反復し、クライアントのコールバック コントラクトを呼び出すと、タイムアウトするだけです。私はある種の ContractMismatch を予期していました。操作タイムアウト以外の何か (そしてすぐに!) ?!?

クライアントが接続に使用したコントラクト名も調べてみました ( OperationContext.Current)。しかし、それもうまくいきませんでした。IServerServiceではどちらの場合も言いOperationContext.Current.EndpointDispatcher.ContractNameます。

OperationContract接続時にクライアントが使用したものをサーバー側で把握する可能性はありますか?

もちろん、メソッドによってサーバー インターフェイスを拡張することもできますSubscribeServerが、それはかなり醜いように思えます。

編集：

提案されたように、私は実装しましたMessageInspector。しかしAfterReceiveRequest、IClientChannel では正常にキャストできますICallback

さらに奇妙なのは、コールスタックに既に含まれていることReliableDuplexSessionChannelです:

これは、コールバック コントラクトが定義されているサービス クラスを実装する場合、IServerService接続しているすべてのクライアントが二重プロキシ経由でルーティングされることを意味しますか? クライアントが使用する (または実装する) コントラクトに関係なく?