RSB V3?

[Corey Kaylor]

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
  

[Jason Meckley]

+1 all around :)
Would any of these features distinguish themselves from NSerivceBus or Mass Transit?

[Matt Burton]

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.

> --
> You received this message because you are subscribed to the Google Groups
> "Rhino Tools Dev" group.
> To post to this group, send email to rhino-t...@googlegroups.com.
> To unsubscribe from this group, send email to
> rhino-tools-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rhino-tools-dev?hl=en.
>

[Corey Kaylor]

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

[Matt Burton]

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

[Corey Kaylor]

I might be able to do a hybrid of EventAggregator and regular subscription. One that simplifies things internally and still provides hooks for instances. The thing that I'm hung up on is I don't really think that it's very important for publishing code to know the difference between instance subscription and regular subscription. Thanks for your comments I'll keep them in mind before ripping things apart.

On a side note, I think I can do everything I've described with a new registration mechanism while keeping all the existing stuff in place and marking them as deprecated. If it works out it should provide people a little bit of time to adapt. We'll see when I get a bit further.

[Corey Kaylor]

@Jason 

To be honest, I'm not sure about the other bus implementations. I haven't looked in a while.

[Matt Burton]

I'd opt for removing rather than replacing complexity. Apart from my testing scenario I can't think of another place where I would use instance subscriptions in production code. I can imagine situations like ASP.NET WebForms pages being instance subscribers but that just feels wrong to me (apart from the notion of using WebForms in the first place :) I'd much rather see RSB become lean and mean while still maintaining the out of the box simplicity that drew me to it in the first place. Perhaps your idea of the event aggregator could become a sample application, living in a new GitHub repo along with others showing examples of some advanced use cases. Or maybe instead of sample applications a "contrib" concept is introduced, though that is a slippery slop with version maintenance, etc… just some ideas….

Thanks,

Matt

[René M. Andersen]

+1, specially for breaking up the transports into their own packages. I Guess an effect of this will be that it becomes easier to add new transports?

[Corey Kaylor]

The behaviors should definitely simplify the transports. They would essentially become just peek and dequeue and pass message to chain. It would definitely make your transaction discussion a walk in the park.

On Fri, Jan 6, 2012 at 12:51 AM, René M. Andersen <renemygin...@gmail.com> wrote:

+1, specially for breaking up the transports into their own packages. I Guess an effect of this will be that it becomes easier to add new transports?

--

You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/gT9ghEsSdTQJ.

[Jason Meckley]

@Corey, are you talking about a behavior chain like FUBU. Or even using FUBU directly?

[Corey Kaylor]

I'm trying to persuade Jeremy to put the core behavior stuff into FubuCore and use it directly.

On Fri, Jan 6, 2012 at 9:17 AM, Jason Meckley <jasonm...@gmail.com> wrote:

@Corey, are you talking about a behavior chain like FUBU. Or even using FUBU directly?

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/k6gCLE4zwksJ.

[Jason Meckley]

that's what I thought :)

How difficult would this be to implement within RSB itself? I ask because it seems the more dependencies infrastructure requires, the more difficult it is to upgrade a system. If the logic is not too complex, the behavior chain could be built within RSB and no dependency on FUBU would be required.

Or would you take advantage of the other FubuCore features as well? In which case you are already dependent on Fubu.

[Corey Kaylor]

I'll keep that in consideration.

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/_7DbSGG5slEJ.

[Corey Kaylor]

A bit of an update on the status of my v3 ideas.

I have successfully made a spike that leverages FubuMVC directly for handling messages in RSB and all the boostrapping needs of consumers.

What does this buy us?

1. All the behavior chain goodness and conventions that Fubu has to offer.
2. Modularity via bottles also handled by Fubu boostrapping.
3. Leverages subcontainer for lifecycle of a message consumer (no more IMessageModule ugliness)
4. We can introduce new conventions, if action has a return type, next behavior after action would issue a bus.Reply for example
5. Possibly reduce or eliminate the requirement for DTC by intercepting Send, Publish, etc until all behavior chains have been executed successfully then perform the send operations.
6. With a little bit of work we would get the Fubu Diagnostics and potentially a simple mechanism to expose an admin UI through Fubu running on top of Kayak.

What do we lose?

1. Currently Fubu only has StructureMap support, although it is built agnostic
2. Likely will have to think through a Fubu + RSB saga story, however the existing RSB saga will work and continue to work fine.

Where I plan to focus my efforts...

I want this effort to be more of an adapter rather than a rewrite of RSB internals etc. You can opt in if you want to use the adapter, but don't have to.
I want to focus on the separation of ITransport(s) and build a one or two more with primary focus on rabbitmq.

Any more thoughts or opinions?

[Corey Kaylor]

Here is a proof of concept if you want to see what it looks like.

https://github.com/CoreyKaylor/fubutransportation-spike 

[Jason Meckley]

I took a look at the source and it seems straight forward. I recently changed employers and my current work doesn't require ESB at this time, so I won't have any input on the project in the foreseeable future.

[Oren Eini (Ayende Rahien)]

What does the client code looks like?

[Corey Kaylor]

The client code would either be the same as it is today, or the same as the server in my example if you as a bus user want that. IMO it makes more sense to use this on the server side, but nothing would prevent you from using the same code on both ends.