C で記述された独自のシステムを備えたデバイスと、管理目的 (構成の送信、デバイスからの記録データの取得、デバイスの状態の監視) 用の Windows アプリケーションです。使用するテクノロジーを柔軟に選択できます。要件は現在かなりあいまいなので、柔軟なものにする必要があります。主要な通信プロトコルは TCP です。何らかのネットワーク障害などにより正常な通信ができなくなった場合、保守オプションとして COM ポートを使用することがあります。
アプリケーションとデバイス間の「プロキシ」として WCF サービスを使用することを検討しています。アプリはサービスにデータを送信し、サービスはデータを処理してデバイスに TCP パケットを送信します (パケット内のデータはデバイスが理解できます)。この WCF の使用は意味がありますか?
WCF は webapp から簡単にアクセスできるため、通常の Windows アプリケーションに加えて、システムをよりセクシーにすることもできますが、それだけの価値はありますか? どう思いますか、あなたのアイデアを共有してください:)
私が理解しているように、あなたは 3 つの要素を持つシステム アーキテクチャを検討しています。Windows アプリケーション、一連のデバイス、およびプロキシまたは仲介者として機能する追加のサービスで、2 つの間の通信を仲介します。
最初の質問: 管理アプリケーションがデバイス自体に接続できない理由はありますか? 管理に使用する Windows アプリは、別のアプリと同じように簡単にデバイスへのソケットを開くことができる必要があります。なぜそうしないのですか？これを尋ねる別の方法は、次のようになると思います。3 番目の要素であるブローカーをアーキテクチャに導入する正当な理由は何ですか? 導入したい非同期性はありますか? 規模の問題ですか。デバイスの数が非常に多いため、UI を使用してアプリから直接接続するのではなく、すべてのデバイスとの通信を別のアプリで管理したい場合があります。ネットワークトポロジの問題ですか？ブローカで使用するテクノロジを検討する前に、まずアーキテクチャにブローカを含める必要がある理由を決定します。
3 番目の要素に正当な理由があると仮定すると、WCF がその要素に適した通信テクノロジであるかどうかという問題を考えることができます。確かに、2 つの Windows ベースのアプリ間では、WCF はうまく機能します。それらが同じマシン上にある場合は、名前付きパイプのバインディングを使用して、ローカル通信に非常に優れたパフォーマンスを得ることができます。これら 2 つのアプリが異なる Windows マシンに分散されている場合は、TCP を使用して、ネットワーク通信で非常に優れたパフォーマンスを得ることができます。
また、ブローカーとデバイス間の接続も考慮する必要があります。WCF は、非 WCF システムと相互接続できます。既存のシステムと相互接続するには、WCF 側でいくつかの拡張機能を作成する必要があります。しかし、それは可能であり、WCF のほぼ主流のユースケースと言えます。そのトピックの詳細については、この Q を参照してください。