I wrote about this once before.

Let's say I'm building a service that I want to be stateless but has some notion of a session with a client. Let's say (for argument's sake) that the interface looks like this;

public interface IServe

{

  int GetFirstNumber(out Guid sessionToken);

  int GetNextNumber(Guid sessionToken, out bool isLastNumber);

}

Ok, so it's a messy interface but it serves the purpose of illustration. The idea is that the first time the client calls the service, the service will not only generate them their first result but it'll also return them a session id of some sort so that they can come back later on and resume the session in order to get the next number in the sequence.

Naturally, you could hide the session id in a SOAP header or you could hide it in a transport (i.e. HTTP) header if you wanted to hide it from the interface (it's a good question as to whether you do IMHO).

Now - in between calls to this service the implementation is going to serialize the state for the client. That is, it's going to write the Guid and the current position within the sequence of numbers into a database. When (if) the client calls back, we'll grab their state, return the next number and save the state again.

Is this hard? Not really - it's fairly easy to understand and it's fairly easy to implement.

But then (as far as I can tell) this is exactly what DurableServices do for you in WCF and yet when I look at them it seems disproportionately complicated to make use of.

As an example, here's the list of "rules" from MSDN regarding using DurableServices;

An exception is thrown if any of the following are not true:

• All sessionful bindings have a context binding element such as WSHttpContextBindingElement or NetTcpContextBindingElement

• The ConcurrencyMode value must not be set to Multiple

• The InstanceContextMode value must be PerSession

• There must be one sessionful endpoint configured for the service

• If the contract disallows sessions, then CanCreateInstance must be set to true for all operations

• If the contract permits or allows sessions then all operations for which CanCreateInstance is set to true must be request/response operations, that is IsOneWay cannot be set to true

• If SaveStateInOperationTransaction is set to true, then all operations on the service must either be decorated with OperationBehaviorAttribute..::TransactionScopeRequired set to true or decorated with TransactionFlowOption..::Mandatory and ConcurrencyMode is set to Single

Oh wow - what's all that about???!??! Rather than learn all these rules, I've a feeling that I'd rather just write my own implementation then at least;

1. I'll feel comfortable that I didn't break any rules.
2. I'll know exactly what it's doing.

So, for me right now, DurableServices looks like a bit of functionality that might be nice in making some other bits of the Framework useful (e.g. I think they underpin the Workflow Services stuff) but I'd struggle to see people using this for their own efforts outside of Workflow. The complexity/benefit ratio seems way out of whack to me.