Sounds great, except for getting rid of OccasionalConsumerOf<T> - I use this a great deal in doing end to end tests - very handy. If there's a better way I'd love to know what it is.
On Fri, Sep 23, 2011 at 1:14 PM, Corey Kaylor <[email protected]> wrote: > Thinking out loud here and looking to gauge reactions so don't take anything > as concrete. > > After having worked with FubuMVC for some time now and seeing the power that > customizable conventions bring, I've been thinking about how this might > simplify or change things with regard to the .NET service bus > implementations. In addition to thinking about conventions I've had some > ideas or nagging feelings for improvements. Let me know if you have others. > > Some ideas in no particular order. > > Changing heavily the way message endpoints are considered a consumer through > convention, with a set of defaults that still leverages the existing > ConsumerOf<T> > Conventionally describe how sagas are initiated, finished, etc. > Bottles from Fubu to auto wireup endpoints for a given bottle - possibly in > its own appdomain > Conventionally determine routing? > Getting rid of OccasionalConsumerOf<T>, it's ugly, provides little value and > can be handled with event aggregation inside your apps > Conventionally auto-subscribe > Chain of responsibility for consuming message pipline, aka BehaviorChains in > Fubu > Message delivery expiration, if not able to send with timespan, discard (or > insert your convention here) > Endpoints that are considered volatile and will only retry send x times > (might only be possible with rhino queues at the moment) > Conventions for URI's to help with bottles scenario when using rhino queues > and requires more than one listening port > > An example might be at the host level saying for environment 'QA' port > starts with 55 > For the bottle level it might say the port ends with 24 > > Break up the transports into their own packages > In general the transports need to be broken up into different things that > handle smaller responsibility, separated to their own nuget packages > In the same vein the DefaultServiceBus could be broken down and separated as > well, not the core IServiceBus interface, but rather the implementation > Make a common Message type used between transports > > -- > 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.
