That is actually a pretty good question. The major aspects are probably going to remain the same, the notions of one way messages and queues are still something that I strong believe in.
What would likely change is the entire setup story. For example, doing discovery for queues so we don't need to specify them, a lot more conventions and a lot less reliance on the container as service locator. I would probably also provide something like the REST interface that we have in RavenDB to allow to see what is going on, recent traffic, etc. That can be very valuable in terms of understanding what is going on. I would also probably abandon the MSMQ / Rhino Queues and transport issues for something like RavenMQ That is a drastic difference in the distribution model (compare that to Unicast vs. Multicast in NSB). But it allows some very interesting aspects on the system behavior, especially with remote clients. That is about it, I think. On Wed, Apr 27, 2011 at 1:01 PM, Steve Wagner <[email protected]> wrote: > The original questions went via twitter. But since Ayende said the answer > would be longer and should be happen per mail, i decided to redirect that > question here so that everyone can read it. > > -Steve > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
