Nick is continuing my discussion on durable messaging support in modern WS-* based stacks, especially WCF.
I agree that having a simple channel configuration support to direct messages into permanent information source (like SQL) would be beneficial.
A simple idea that begs for an alternative implementation of a WCF extensibility point, has some questions:
- What happens when messages are (or should be) exchanged in terms of a transaction context?
- How can we demand transaction support from the underlying datastore, if we don't want to put limitations onto anything residing beind the service boundary?
- What about security contexts? How can we acknowledge a secure, durable sessionful channel after two weeks of service
hibernation down time? Should security keys still be valid just because service was down and not responding all this time?
- Is durability limited to client/service recycling or non-memory message storage? What about both?
Is [DurableService]enough?