문제

COM MY WAY : C로 작성된 자체 시스템이있는 장치와 관리 목적 관리를위한 Windows 응용 프로그램 (구성 보내기, 장치에서 녹음 된 데이터 검색, 장치의 상태 모니터링)이 있습니다. 내가 사용할 기술을 선택하는 데 유연성이 있습니다. 요구 사항은 지금 매우 흐릿하므로 유연한 것이되어야합니다. 1 차 통신 프로토콜은 TCP입니다. 예를 들어 일부 네트워크 오작동으로 인해 일반 통신이 실패 할 때 COM 포트를 유지 보수 옵션으로 사용할 수 있습니다.

응용 프로그램과 장치 사이의 "프록시"로 WCF 서비스를 사용하는 것을 고려하고 있습니다. 앱은 데이터를 서비스로 전송하고 서비스를 처리하고 데이터를 장치로 보냅니다 (패킷의 데이터는 장치가 이해할 수 있음), 장치는 TCP 패킷을 WCF 서비스로 다시 전송하여 처리 된 메시지를 응용 프로그램으로 전송합니다. WCF의 이러한 사용이 의미가 있습니까?

WCF는 WebApp에서 쉽게 액세스 할 수 있으므로 일반적인 Windows 응용 프로그램 외에도 시스템을 더 섹시하게 만들 수 있지만 그만한 가치가 있습니까? 당신은 어떻게 생각하고, 당신의 아이디어를 공유하십시오. :)

도움이 되었습니까?

해결책

내가 이해하는 것처럼, 당신은 세 가지 요소가있는 시스템 아키텍처를 고려하고 있습니다. Windows 애플리케이션, 장치 세트, 그리고 두 가지 사이의 대리 또는 중간으로 작용하는 추가 서비스.

첫 번째 질문 : 관리 응용 프로그램이 장치 자체에 연결할 수없는 이유가 있습니까? 관리에 사용되는 Windows 앱은 다른 앱과 마찬가지로 장치에 소켓을 열 수 있어야합니다. 왜 그렇지 않겠습니까? 나는 이것을 물어 보는 또 다른 방법 인 것 같아요. 브로커 인 세 번째 요소를 아키텍처에 소개하는 정당성은 무엇입니까? 소개하고 싶은 비동기식이 있습니까? 규모의 문제일까요 - 아마도 장치 수가 너무 커서 UI와 앱에서 직접 연결하는 대신 별도의 앱을 관리 할 수있는 별도의 앱을 원할 수도 있습니다. 네트워크 토폴로지의 문제입니까? 브로커에서 어떤 기술을 사용해야하는지 고려하기 전에 먼저 아키텍처에 브로커를 포함하도록 강요하는 내용을 결정하십시오.

세 번째 요소에 대한 정당성이 좋은 것으로 가정하면 WCF가 해당 요소에 적합한 통신 기술인지 여부를 고려할 수 있습니다. 확실히 2 개의 Windows 기반 앱 사이에서 WCF는 잘 작동합니다. 동일한 기계에있는 경우 이름이 지정된 파이프 바인딩을 사용하고 로컬 커뮤니케이션을 위해 매우 잘 얻을 수 있습니다. 이 두 앱이 다른 Windows 시스템에 배포되면 네트워크 통신에서 TCP를 사용하여 다시 활용할 수 있습니다.

또한 브로커와 장치 간의 연결을 고려하고 싶습니다. WCF는 비 WCF 시스템과 상호 연결할 수 있습니다. 기존 시스템과 상호 연결하려면 WCF 측에 일부 확장을 작성해야합니다. 그러나 가능하며 WCF에 대한 근처의 사용 사례를 말하고 싶습니다. 보다 이 주제에 대한 자세한 내용은이 Q입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top