問題タブ [channelfactory]

複数のアプリケーションで使用される一連の WCF サービスを構築しています。そのため、WCF サービスにアクセスするための共通ライブラリを定義しようとしています。

異なるユーザーによって行われた各サービス要求は異なるチャネルを使用する必要があることを知っているので、要求ごとにチャネルをHttpContext.Current.Itemsキャッシュし ( )、アプリケーションごとにチャネルを作成するために使用される ChannelFactory をキャッシュすることを考えています ( HttpApplication.Items)。同じChannelFactory。

ただし、ChannelFactory と Channel を閉じるときのこのキャッシュ メカニズムについて質問があります。

1. 使用された後、リクエストの最後にチャンネルを閉じる必要がありますか、それとも、そのリクエストのコンテキストが終了したときにチャンネルを閉じたまま (?) にしても問題ありませんか?
2. チャンネルファクトリーはどうですか？各チャネルはそれを作成した ChannelFactory に関連付けられているため、アプリケーション プロセス (AppDomain) の存続期間中、同じ ChannelFactory を保持しても安全ですか?

これは、これを管理するために使用しているコードです。

ありがとう！

ChannelFactoryを実装する StackOverflow で見つかった例を一部使用して、別のサービス内から WCF サービスを呼び出そうとしています。

テスト用のソリューション内に別のコンソール アプリ プロジェクトを作成しました (VS 2008、ところで)、

これは、エンドポイントを示すローカル サービスのApp.Configからのものです。

これは、テスト プロジェクト独自のApp.Configからのものです。

これは、ローカル サービスで公開したメソッドで、リクエスト オブジェクトをリモート サービスに渡します。

私が受け取るエラーはこれです：

ServiceModel クライアント構成セクションで、名前が「 ServiceSoap」でコントラクトが「ServiceReference.ServiceSoap 」のエンドポイント要素が見つかりませんでした。これは、アプリケーションの構成ファイルが見つからなかったか、この名前に一致するエンドポイント要素が client 要素に見つからなかったためである可能性があります。

ローカル サービスの app.config (リモート サービスを指すサービス リファレンスが定義されている)、テスト アプリの app.config、または他の場所で、endpoint 要素が正確にどこにないのでしょうか。 !

更新:この MSDN の記事を読んだ後、ある種の回避策を見つけました。または、ChannelFactory をインスタンス化する別の方法だと思います。

app.config に存在しない情報や正しくない情報を取得しようとする代わりに、Binding (BasicHttpBinding) の値とリモート サービスへのアドレスを手動でプラグインします。これにより、「エンドポイント要素が見つかりませんでした」というエラーを回避できたようですが、これが最善の解決策であるかどうかはわかりません。

ChannelFactory が State プロパティを持つとはどういう意味ですか? 作成されたチャネルが接続ベースの状態を持つことができることを理解しています。しかし、なぜ ChannelFactory にもそのような接続状態があるのか​​ について混乱しています。それもWCFサービスに接続しますか?

Wenlong Dong による WCF ChannelFactory キャッシングに関する素晴らしい記事を読みました。

私の質問は、 ChannelFactory が実際に呼び出し間でキャッシュされていることを実際にどのように証明できるのでしょうか? ClientBase のコンストラクターに関する規則に従いました。ClientBase から継承するオブジェクトで、次のオーバーロードされたコンストラクターを使用しています。

ClientBase(string endpointConfigurationName, EndpointAddress remoteAddress);

上記の記事では、次のように述べられています。

これらのコンストラクターのすべての引数 (デフォルトのものを含む) は、次のリストにあります。

· InstanceContext callbackInstance

· 文字列 endpointConfigurationName

· EndpointAddress リモートアドレス

これら 3 つの引数が ClientBase の構築時に同じである限り、同じ ChannelFactory を使用できると安全に想定できます。幸いなことに、String 型と EndpointAddress 型は不変です。つまり、単純な比較を行って、2 つの引数が同じかどうかを判断できます。InstanceContext では、オブジェクト参照比較を使用できます。したがって、タイプ EndpointTrait が MRU キャッシュのキーとして使用されます。

ChannelFactory キャッシュ理論をテストするために、ClientBase コンストラクターで Hashcode をチェックしています。

呼び出しごとにハッシュ値が異なるため、ChannelFactory が実際にはキャッシュされていないと思われます。

何かご意見は？

よろしく

マイルズ

Channel Factoryを使用して、asp.netmvcにキャッシュしようとしています。状態を知る必要があるため、PerSessionインスタンスモードを使用しています。このため、プロキシをすぐに閉じることはできません。そして、私は毎回プロキシを閉じて、再開したくありません。プロキシを開いたままにすると、12回目にタイムアウトになります。同時セッションのタイムアウトを増やすことはできますが、それが正しいアプローチであるかどうかを知りたいです。私はWCFを初めて使用するので、私の質問がばかげている場合はご容赦ください。-事前に感謝しますプラット

私たちの SharePoint/ASP.NET 環境には、すべて共通のインターフェイスから派生した一連のデータ取得クラスがあります。私は、WCF を使用して他の SharePoint ファームとリモートで通信できるデータ リトリーバーを作成するタスクを割り当てられました。私が現在実装している方法は、シングルトンChannelFactory<T>が静的コンストラクターで作成され、リモート データ リトリーバーの各インスタンスによって再利用されて、個々のプロキシ インスタンスが作成されるというものです。ChannelFactoryはアプリ ドメインで 1 回だけインスタンス化され、その作成はスレッド セーフであることが保証されているため、これはうまく機能すると考えました。私のコードは次のようになります。

私の質問は、これは良いデザインですか？ChannelFactoryが作成されたら、単に呼び出すために使用しているだけなので、スレッドセーフについて心配する必要はないと考えましたが、CreateChannel()間違っていますか? スレッド化の問題を引き起こす可能性のある舞台裏で状態を変更したり、ファンキーなことを行ったりしていませんか? さらに、手動で破棄するコードをどこかに配置する必要がありますか (静的ファイナライザー?)、ChannelFactoryまたは IIS が再起動されるたびにすべてのクリーンアップ作業が行われると想定できますか?

関連: ChannelFactory の再利用戦略

タイトルが示すように、WCFで、ChannelFactoryを使用して新しいチャネルインスタンスを手動で作成するのではなく、「プロキシを生成する」ことを選択する理由を理解しようとしています。私はそれぞれの例を見てきましたが、なぜあなたがどちらか一方に行くのかについての説明を実際には見つけていません。

正直なところ、私はこれまでに、ChannelFactory<T>私が継承したチャネルとfromコードのみを操作しました。

では、なぜ「プロキシを生成する」のでしょうか。メリットとデメリットは何ですか？

あいさつ、次のようにファクトリのクレデンシャルを設定しようとすると、どのような問題が発生しますか。

オブジェクトが読み取り専用であるという例外が発生します。ユーザー名を設定したいときに発生します。

.Net WCF クライアントによって消費される REST サービスがあります。

エラーが発生すると、REST サービスは HTTP 400 Bad Request を返し、応答本文には JSON のシリアル化された詳細が含まれます。

Fiddler、Javascript、または C# から直接要求を実行すると、エラーが発生したときに応答本文に簡単にアクセスできます。

ChannelFactoryただし、 6 つの非常に複雑なインターフェイスを持つ WCF を使用しています。このプロキシによってスローされる例外は常に でありProtocolException、有用な詳細はありません。

このエラーが発生したときに応答本文を取得する方法はありますか?

アップデート

.Net を使用してこれを行うにはさまざまな方法があり、エラー応答を取得する方法は他にもあることを認識しています。それらは知っておくと便利ですが、この質問には答えません。

私たちが使用している REST サービスは変更され、複雑なインターフェイスは更新されます。新しいインターフェイスでを使用するChannelFactoryと、(実行時ではなく) コンパイル時に例外が発生し、コードの保守と更新がはるかに簡単になります。

WCF チャネルを使用しているときにエラー HTTP ステータスの応答本文を取得する方法はありますか?

私は、再利用のために WCF プロキシをキャッシュすることに関連する StackOverflow に関する他の記事を参照しました。また、何かを呼び出す前にプロキシを明示的に開く必要がある理由を説明するこの記事を読みました。最良の実装の詳細については、まだ少しぼんやりしています。

私の質問は、Web サイトでのサービス呼び出しのプロキシをいつ開いて閉じる必要があるか、およびそれらの有効期間 (呼び出しごと、要求ごと、または Web アプリごと) をどのようにすべきかということです。現時点では、キャッシュされたセキュリティ コンテキストを利用する予定はありません (ただし、予測できないわけではありません)。

ありがとう！