No - what you said makes sense. Doing what I'm doing now is not impossible
without instance subscription support - I can compensate by building other
components to stand in and deliver the same results. If removing them would
make RSB simpler then by all means go for it - I wasn't aware of how
complicated that feature is. At the end of the day it's saving me from having
to write extra code in my end to end tests, which is not a big deal.
Thanks,
Matt
On Sep 23, 2011, at 5:33 PM, Corey Kaylor wrote:
> @Matt
>
> The common way that I handle sending messages to a particular instance is by
> having something that handles that concern by itself. One example that we
> have used is something similar to IEventAggregator in Caliburn. In our case
> we have hooks for when instances are created from the container and
> implements Handles<T> and is auto-subscribed with the event aggregator
> (Avoids the need for explicit subscription).
>
> slim example
>
> public void Consume(EventMessage message)
> {
> eventAggregator.Publish(message);
> }
>
> //in another class that might have typically implemented
> OccassionalConsumerOf<T>
> Handle(CustomerMoved message)
> {
> //do something
> }
>
> So the more specific question is... Would it be a big deal in the case of a
> published message on the bus to receive and not have any listeners i.e.
> already created handlers at the destination?
>
> There is a lot of working parts to make the instance subscriptions work with
> little payoff IMO.
>
> Does what I've said make sense, or am I missing something that this type of
> thing wouldn't work for in your case?
>
> On Fri, Sep 23, 2011 at 4:53 PM, Matt Burton <[email protected]> wrote:
> 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.
>
>
>
> --
> 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.
