WCF 웹 서비스 및 클라이언트

Question

의견을 보내 주신 WCF 서비스에 대해 몇 가지 질문이 있습니다. 실제 시나리오에 WCF 서비스를 적용하는 방법에 대한 많은 자료를 읽었지만 많은 모순 된 의견이 있습니다.

우리는 백엔드 데이터 저장소에 대한 인터페이스 이상을위한 데이터 서비스를 제공하지 않습니다. 이 데이터 서비스에는 데이터 서비스가 보유한 데이터가 변경 될 때 알림을 받아야하는 클라이언트가 많이 있습니다. 이러한 클라이언트는 이후 이러한 알림을 기반으로 데이터 서비스의 데이터를 요청할 수 있습니다. 우리는 최대 2000 개의 클라이언트를 지원하고 싶습니다 (웹 기반 솔루션은 아니지만 대규모 분산 네트워크 일 수 있음).

내 문제 :

· 연결이 서비스와 클라이언트 사이에서 손실 된 경우, 클라이언트가 즉시 알아야한다.

· 서비스는 짧은 시간 내에 데이터 변경 사항을 클라이언트에 알려야합니다. 알림은 대기열에 넣고 나중에 수신 할 수 없습니다.

· 클라이언트 측에서 구성 작업을 많이하지 않아도 서비스를 사용할 수 있습니다.

· 확장 성이 좋지 않은 서비스와 클라이언트간에 영구 연결을 원하지 않습니다.

접근 방법 우리가 살펴 보았다 :

· MSMQ

· 양면 바인딩

·

· 구독/접근 방법을 게시 (바인딩 실버 라이트 3의 새로운 폴링 포함) 이벤트에 대한 폴링.

우리 모두는 이러한 단점을 발견했으며, 우리가 원하는 것을 수행하는 최적의 방법 중 하나가 아닌 것으로 나타났습니다.

도움을 주시면 감사하겠습니다.

감사 이안

Answer 1

이 정확하게 당신이 찾고있는 것은 아니지만, 이벤트 기반 서비스 아키텍처에 올 때, 상담 할 수있는 사람 (또는 블로그) Udi Dahan이다.

그의 기사 Event-Driven Architecture: SOA Through the Looking Glass은 이러한 문제에 대한 접근 방법에 대한 개요를 제공합니다. 이 기사는 WCF에 대해 명시 적으로 논의하지는 않지만 WCF에 대해서도 많이 알고 있으므로 블로그를 숨김으로써 무언가가 유용하다고 생각하는 경우에만 권장 할 수 있습니다.

Answer 2

첫 번째 우려 사항을 해결하는 유일한 방법은 네 번째 규칙을 위반하는 것입니다. 클라이언트가 연결이 끊어 졌다는 것을 알기 위해서는 지속적인 폴링 메커니즘 ("즉시"를 무시하는) 또는 열린 연결을 유지해야합니다. WFC는 연결을 열지 않으므로 첫 번째 관심사는 연결 사용에 반대하는 것입니다.

두 번째 관심사는 어떤 기술을 선택 하든지간에 확장 문제를 제기합니다. 상태 기반 연결 패턴은 장기적으로 구현 및 확장하기가 훨씬 어려울 수 있으므로 관심사가 완전한 비즈니스 요구 사항인지 단순히 기본 설정인지 검토 할 수 있습니다.