DISQUS

Mark Bjerke · 1 year ago

This is really good work and we are taking a careful look. Thank you for providing the project.

Nathan · 1 year ago

I'm glad you like it, thanks for the compliment. It's still very much a work in progress, so please don't be shy with any feedback, suggestions, requests etc. as you pick through it.

george · 1 year ago

Good work. Would it be possible to present the set up of this project in a WebCast as for new SOA developers, this would be a great guid into getting it to work. Thanks.

Nathan · 1 year ago

Once the project has stabilized then I think that is a great idea.

Colin Jack · 6 months ago

Have you thought about merging your changes in with what Udi has done now 1.9 is out the door?

nstults · 6 months ago

I keep a loose eye on NSB to see if parts of what I've done can be reused as NSB components, but in reality while this project started out life as a fork, it really ended up being a nearly total rewrite. I'm not sure there is any nServiceBus code left, although the overall architecture remains vaguely the same, so a "merge" is certainly no longer possible. Even if it were it is extraordinarily unlikely Udi would accept my changes, our styles are just too different.

danvanderboom · 2 weeks ago

Great work, Nathan. I'm glad I found SimpleServiceBus before diving too deeply into nServiceBus. I want the fastest path to swapping out MSMQ for Windows Azure Queue Storage for cloud compute components, and SimpleServiceBus sounds easier to customize in this way. You've made a lot of design choices I would have made, so it's nice to know our styles are similar. I especially like the replaceable subsystems, message pipeline pattern, polymorphic message handling, lack of third-party dependencies, and I agree that requiring a reference to a service bus assembly in a message contracts assembly is silly.

nstults · 1 week ago

Dan, I'm glad you like it. However, I would be careful about skipping over a careful review of NServiceBus because of my descriptions here - this post is quite old, and NServiceBus is now maintained by a team, evolves rapidly, and has a very active community. Many of the shortcomings in this post have been overcome in recent versions of NSB. I'm not steering you away from SSB, I'm just cautioning that NSB also deserves your time in a thorough evaluation, because the very active development team and thriving community are huge assets that SSB simply does not possess.