在 WCF 中构建可靠的服务
我目前正在设计一个服务（wsHttp），它应该用于返回敏感数据。一旦客户请求这些数据，我就会从数据库中获取它，编译一个列表，然后从数据库中删除数据并返回列表。
我担心的是，在返回客户端的路上发生了一些事情（网络问题，...）我已经从数据库中删除了数据，但客户端永远不会得到它。
我这里有哪种现成的解决方案？
I am currently designing a service (wsHttp) which should be used to return sensitive data. As soon as a client asks for this data, I get it from the database, compile a list, then delete the data from the database and return the list.
My concern is that something happens on the way back to the client (network issues, ...) I have already deleted the data from the database, but the client will never get it.
Which out of the box solution do I have here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是分布式计算固有的问题。 没有简单的解决方案。问题是从此类错误中恢复有多重要。
例如，如果删除了一些记录，但客户端断开连接，则下次连接时，他将看到这些记录已被删除。即使他尝试再次删除它们（数据保留在用户界面中），这也不会造成任何损害。
对于转账的银行来说，他们有一个错误解决机制，可以在第二个流程中匹配他们之间发生的交易。冲突将由人工处理。
一些系统（例如NServiceBus）依赖MSMQ来存储消息和最终一致性，其中只要客户端再次连接，发往客户端的消息最终都会到达。
This is an inherent problem in the distributed computing. There is no easy solution. The question is how important it is to recover from such errors.
For example, if one deletes some records but the client gets disconnected, next time he connects he will see those records as deleted. Even if he tries to delete them again (data stayed in the UI), this will do no harm.
For banks transferring money, they have an error resolution mechanism where they match the transactions that happened between them in a second process. Conflicts will be dealt manually.
Some systems such as NServiceBus rely on MSMQ for storing messages and eventual consistency where a message destined to a client will eventually arrive whenever he is connected again.
对此没有现成的解决方案。您需要实现某种形式的用户/自动确认，以确认数据已收到，并且只有在返回后才删除。
埃德
There is no out of the box solution for this. You would need to implement some form of user/automated confirmation that the data had been recieved and only delete once this was returned.
Ed
有一个简单的解决方案。但它不是现成的。
像 WS-ReliableMessaging（或同等的 TCP/IP）这样的协议为您的消息传递提供了一层可靠性，但是一旦该层将消息卸载到上面的层，所有的赌注都消失了。
因此，可靠性只能在绝对最高层（应用层）得到完全解决，而不能由通信堆栈的任何较低层来解决。这使其成为一流的商业问题，而不是纯粹的技术问题。
通过稍微更改删除敏感数据的过程即可解决该问题。
不要立即删除它，而是将其标记为删除。然后，将客户端必须确认收到敏感数据的断言构建到驱动服务的业务流程中。然后，当您收到确认消息时，您可以安全地删除标记为删除的数据，因为您知道这些数据已被收到。
我最近写了一篇博客文章，推理可靠性是无法转移到较低层的一流业务关注点。
There is an easy solution. But it doesn't come in a box.
Protocols like WS-ReliableMessaging (or equally TCP/IP) give you a layer of reliability under your messaging, but all bets are off once that layer offloads the message to the layer above.
So reliability can only be fully addressed at the absolute highest layer - the application layer, not by any lower layer down the communication stack. This makes it a first class business concern, not a purely technical concern.
The problem can be solved with a slight change to the process of deleting your sensitive data.
Instead of deleting it immediately, flag it for deletion. Then, build into the business processes that drive your service the assertion that the client must acknowledge receipt of the sensitive data. Then, when you get the acknowledgement back you can safely delete the data flagged for deletion, knowing that it has been received.
I recently wrote a blog post reasoning that reliability is a first class business concern that cannot be offloaded to a lower layer.