5

現在、バックグラウンドで実行されている Windows サービスと、ローカルまたはリモート クライアント (通常は 1 ～ 3 のみ) で構成される .NET 4 アプリケーションがあります。

クライアントには WPF GUI があり、Windows サービスからのデータが必要です。そのため、ローカル クライアントには NamedPipe バインディングを使用し、リモート クライアントには NetTcp バインディングを使用して WCF を使用します。これは機能しますが、到達できないエンドポイントで問題が発生することがよくあります (チャネルに障害がある、見つからないなど)。すでに障害のある接続を再構築しようとしていますが、かなり壊れやすいようです...

次に、Web Api に入ります。HTTP ベースのスタックの方が堅牢なようです (チャネルもエンドポイントもありません。Windows サービスでも自己ホストできます)。各リクエストは個別に処理されるため、チャンネルが壊れても問題はないようです。したがって、何かが失敗した場合は、要求を繰り返すだけです。(そして、他のアプリから ASP.NET MVC を使用した経験があるため、これは私たちにとって新しいことではありません)。

今、私たちは最善の策を考えています。既存の WCF サービス (約 15 の操作を含む 1 つのサービス インターフェイス) を "強化" するか、インターフェイスを Web Api に移動して HTTP 要求として (JSON データを使用して) 実行する方がよいでしょうか? ここでの主な問題はパフォーマンスではありません...

何か案は？ハルトムート

4

1 に答える 1

4

Web API に移行するのではなく、WPF アプリケーションの WCF (SOAP) サービスを使い続けることをお勧めします。これにはいくつかの理由があります。最初に、新しい Web API が対処しようとしていること、つまり、RESTful/HTTP/ハイパーメディア サービスをサポートするためのフレームワークを提供することを検討する必要があると思います。これは、(プラットフォームに関係なく) サービスの「リーチ」または相互運用性を最大化したい Web、モバイル、JavaScript アプリケーションなど、HTTP を多用するアプリケーションの構築に適している可能性があります。これは、WPF クライアントに使用できないと言っているわけではありませんが、すべてのトラフィックがドメインに対してローカルである場合、現在の実装に固執する方が理にかなっています。

サービス/クライアントに対して行った拘束力のある選択は、私には問題ないように思えます。私はあなたのチャネルがなぜ失敗したのかに焦点を当て、これらの問題に対処します. また、IIS を介してサービスをホストし、WAS を使用して非 HTTP エンドポイントを公開することを検討することもできます。私は過去にこれで多くの成功を収めており、ほとんどの場合、かなり安定しています。また、独自のホストを管理する際の頭痛の種もいくつか取り除かれます。TCP バインディング エラーが心配な場合は、新しい HTTP または wsHTTP エンドポイントを作成し、代わりにそれを使用してください。これにより、プログラミング モデルを変更することなく、Web API が使用するものとまったく同じトランスポートが提供されます。

于 2012-04-19T01:14:56.507 に答える