@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.
