New "in memory" queue underlying the service bus

[jeremydmiller]

This time, I want this to be production quality. Use the TPL dataflow instead of homegrown code. Probably still make it a static so it's easily shared between running nodes in testing scenarios.

[jeremydmiller]

Okay, so here's some more thoughts. I vote that we completely ignore the delayed message feature from FubuMVC just for the moment to simplify the MVP. A "transport" in Jasper will need to be able to send messages to other nodes and be able to listen for messages received from other nodes. In FubuMVC, we had the concept of a "reply channel" for a given message and transport that gave the receiving end of the message a means to call back to the original node with any required responses. That caused some trouble in the fubu timeline, so we might reconsider the approach.

To implement the in memory transport, there are a handful of interfaces I just pushed into Jasper that are somewhat simplified versions of the same thing in FubuMVC that a transport type will need to implement:

1. IChannel - runtime support for sending or receiving messages from a single, logical queue
2. ITransport - "knows" how to build channels for a given queue Uri and will have some logic to be determined later on how to connect a replay channel. Just assume that the ITransport signatures around the Reply Uri/Channel will change as we learn more.
3. IMessageCallback - for a received message, this gives the rest of the message handling pipeline a way to tell the underlying queue to pop the message off the queue, requeu it, move it to error queues, etc.

I said "static" up above, but I think this should end up being scoped to the running application itself. What we can do in testing scenarios, is to share an instance of the in memory transport between different JasperRuntime's in order to do testing completely in memory.