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.
