현재 중요한 데이터를 반환하는 데 사용해야하는 서비스 (wsHttp)를 설계 중입니다. 클라이언트가이 데이터를 요청하자마자 데이터베이스에서 가져 와서 목록을 컴파일 한 다음 데이터베이스에서 데이터를 삭제하고 목록을 반환합니다.WCF에서 신뢰할 수있는 서비스 구축
내 관심사는 클라이언트 (네트워크 문제 등)로 돌아 오는 과정에서 발생합니다. 이미 데이터베이스에서 데이터를 삭제했지만 클라이언트는 절대로이를받지 못합니다.
어떤 해결책을 원했습니까?
이것은 분산 컴퓨팅의 고유 한 문제입니다. 쉬운 해결책은 없습니다. 문제는 그러한 오류를 복구하는 것이 얼마나 중요한지입니다.
예를 들어, 일부 레코드를 삭제하지만 클라이언트의 연결이 끊어지면 다음에 연결할 때 해당 레코드가 삭제 된 것으로 표시됩니다. 그가 다시 삭제하려고해도 (데이터가 UI에 남아 있음) 아무런 해가 없습니다.
돈을 이체하는 은행의 경우 두 번째 프로세스에서 발생한 트랜잭션과 일치하는 오류 해결 메커니즘이 있습니다. 충돌은 수동으로 처리됩니다.
일부 시스템은 로 NServiceBus는 저장 메시지와 메시지가 그가 다시 연결될 때마다 결국 도착 클라이언트로 향하는 최종 일관성에 대한 MSMQ에 의존하고 있습니다.
이에 대한 해결책은 없습니다. 데이터가 수신되었다는 사용자/자동 확인의 일부 형태를 구현하고 이것이 반환 된 후에 만 삭제해야합니다.
쉬운 해결책이 있습니다.하지만 상자에 들어오지 않습니다.
WS-ReliableMessaging (또는 동등한 TCP/IP)과 같은 프로토콜은 메시징에서 신뢰성 계층을 제공하지만 해당 계층이 메시지를 위의 계층으로 오프로드하면 모든 베팅은 해제됩니다.
신뢰성은 통신 스택 아래의 하위 계층이 아닌 응용 프로그램 계층 인 절대 최상위 계층에서만 완전히 처리 할 수 있습니다. 이것은 순수한 기술적 관심사가 아니라 일류 비즈니스 관심사가됩니다.
민감한 데이터를 삭제하는 과정을 약간 변경하면 문제가 해결 될 수 있습니다.
즉시 삭제하는 대신 삭제 플래그를 지정하십시오. 그런 다음 클라이언트가 중요한 데이터를 수신했음을 확인해야한다는 주장을 서비스에 적용하는 비즈니스 프로세스를 구축하십시오. 그런 다음 승인을 받으면 삭제 되었음이 표시된 데이터를 안전하게 삭제할 수 있습니다.
나는 최근에 신뢰성이 하위 계층에 오프로드 될 수없는 일류 비즈니스 관심사 인 이유를 blog post이라고 썼습니다.