在WCF中构建可靠的服务

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.