This project is read-only.

Status of Simple Service Bus

Oct 12, 2010 at 12:32 PM



I've been looking at both NServicebus and Masstransit but both of them contained a bit too much of "magic" for us to avoid trouble with MSMQ or didn't support ActiveMQ that well ( our default broker).

Being just minutes away of deciding to write our own Servicebus, i saw SSB which seems to be built for the same reasons as why we didn't want to commit to Masstransit / Nservicebus ( we actually offered to help with Masstransit development but the lacking documentation made this very hard, that together with the direction they seem to want to take, is the reason why i'm considering this)

The only thing is: looking at the code, it seems that a rather important feature is missing ( Sagas) and looking at the discussion board, i saw that the code has changed owner and this owner is probably moving back to Nservicebus in the future ?


I am just wondering: Is this project slowly dying or is there still interest in continueing ?

Can someone tell me about the status / roadmap / Features already done, and the ones that still need to be done ?

I would like to have some futher information before comitting to this project.


Kind regards,


Oct 15, 2010 at 7:00 PM
Edited Oct 15, 2010 at 7:01 PM

Well. i'm guessing that having to wait  more then a  week on a reply kinda says it all :s

Oct 15, 2010 at 9:54 PM

Yeah looks like it's finally dead. However, if you are planning to write your own service bus, there is nothing preventing you from using the source as a basis, adding sagas and whatnot, rather than starting from scratch. Feel free to fork it, maybe throw it up on github. However it was written so long ago that it doesn't take advantage of more recent advances in C#; .NET 4 and its dynamic capabilities possibly coupled with IronRuby for message handling, mapping and routing would really simplify the API of a service bus. In the end you might be better off starting from scratch. Just a thought though.

Oct 16, 2010 at 8:11 PM

Hey! Usually I respond quickly, but I was out on a cruise for the past week, just got back. The project isn't dead, but not very active either. We are a few that use this for production systems. There are not a lot of features planned, the main one is to adopt a Service Locator instead of the custom-built, but other than that we haven't planned a lot. We do welcome any contributions though.

Nov 3, 2010 at 6:03 PM


Thanks.. that might not be such a bad idea.. i like many features from MT, Nservicebus but the implementation of SSB is the closest to EIP that i found sofar.. , i wanted to continue on the code base but have seen some *ahum* hacks that make me think starting fresh might be the best move.. the ActiveMQ implementation rocks though.. haven't seen it done that good in any of the others..


Thanks for the reply, and i do understand, however, if you are the only developer ( and you have stated somewhere earlier that you might swap out SSB for NServicebus in your own project).. it worries me.. a minimum of support would be nice without having to dive into the code everytime an error pops up.

I am currently actualy using SSB but am planning on starting a new Project for a Service Bus


Nov 3, 2010 at 6:25 PM

I'm a little surprised on the hacks, in my opinion the SSB code is fairly clean. Do you have any examples?

I did look a little at other serivce bus projects, but I decided that SSB is still the best option for my products. I continue to use this as the back-bone for a large-scale public transaction-based web site and system that is currently in production. I've push through millions of messages between multiple servers and have seen very good stability. This is using MSMQ.

I definitely welcome anybody to fork or create their own project, but be prepared that it's a lot of work and there are already several projects that are half-baked. Which features do you feel lacking in SSB?

Nov 3, 2010 at 10:47 PM

@nocturnalcoder: thanks for your nice comment on the ActiveMQ implementation ;-)

Nov 4, 2010 at 3:58 PM


I might have been a bit Harsh on "hacks" , what i mostly mean is parts in the code that are partially implemented (like sagas) but this could all be a lack of my knowledge of the codebase..

Eitherway, a few ideas and reasons ( beware, this is just how i see things, isn't necessairly the truth)


* API has some room for improvement altough i do understand many of the decisions since there was obviously the idea to make SSB as thin as possible in your code base ( nobody except the actual moving parts have to know SSB is involved). I would try to keep this as clean as possible but some features are just needed by us and are difficult (or impossible) todo without some extra attributes on existing Classes ( model, DTO, messages).. however this could easily be made optional
* Namespace cleanup. Some things are just located in very strange places ( for me) and i would do a cleanup and remodel of the namespace to reflect it a but more logically ( for example your main interface is hidden in SimpleServicebus.Bus.IMessageBus)
* Implement the Full EIP range in the Core API (not using IExtendedMessagebus)  and provide good helpers to easily setup things like Dynamic Router, Envelope Wrapper etc
* Saga's ( and seperate service handeling state etc)
* Might want to raise to .NET 3.5 at least to be able to use some of the more fancy features
* True Message Broker independence ( might be able to do this using Apache.NMS message library since this already allows an interface to a lot know Message Brokers like: MSMQ, Websphere MQ, ActiveMQ, Tibco and through stomp can speak with just about any JMS broker supporting Stomp)
* Endpoint Monitoring and control if possible


Eitherway.. this is how i would like a Servicebus to look, doesn't mean it would be a good idea for everyone ;-)

Looking at forking.. well, i would love to , on the other hand, why bother to be yet another one-man project ? I actually offered the MT team to join and they were happy to get some contribution but our views on messaging where too different (EIP was not on their wishlist and i didn't feel like stripping the whole thing to enable it to then not see it merged in the main branch because they do not want to use it.. this together with the large codebase and close to no documentation ( not even working samples in their project actually) made me "reconsider" my choice.. then i found SSB.. now i am interrested to develop this further but i don't want to be the one-man "development team" behind something.



Nov 4, 2010 at 6:17 PM

I think all those bullets points are on the mark. There are some endpoint monitoring capabilities built in already, but no control. I'm just popping in from the peanut gallery to suggest that if you guys do decide to really hack on this thing and take it to another level, sagas, JMS, etc, that you strongly consider moving the project to github. There is a small learning curve, but it is a much better environment for collaboration, and if a major refactoring was to take place, git(hub)'s very sophisticated and robust branching, forking, merging system just can't be beat. Plus, that's where all the cool kids are hanging out now-a-days :) There is no discussion forum, so projects tend to use google groups, which would allow group discussions to take place entirely via e-mail instead of having to log into codeplex.

Also, if you do decide to do a major refactoring, I would add this on list of possible targets:

* Simplify configuration system

I'm not sure what I was thinking with the configuration system, but looking back it feels extremely overcomplicated.

Nov 4, 2010 at 10:00 PM

I totally support such features, but I'm probably not the right person to drive any of that. For me the driving features of SSB was Simple ServiceBus. My plans are to continue to use and support SSB, but I personally probably won't add many new features (time constraint).

Nov 5, 2010 at 1:55 AM

I would support such features too, but like HakanL, I also have time constraints which will prevent me from beeing very active, unfortunately.

I agree with PlasticLizard regarding the configuration which is too complex. That's why I created my own way of configuring the ActiveMQ transport... I have also introduces a way to automatically configure every endpoints using metadata that decorates our messages (like [MessageRoute(Source = MyCompany.Service1, Destination = MyCompany.Service2)]. Then I have destination resolver that knows that MyCompany.Service1 is bound to "MyCompany.V10.Service1" and each endpoint must specifies which system it is, allowing us to know the routes matching this source. Finally, we made a tool that can generate a HTML page that extracts all this information in order to undersand the systems, the messages, and their interactions. I will detail this later if someone is interested...

Also, I must say that at first I thought the health monitoring features would be great, but I never used them! With ActiveMQ we have a broker which provides informations about every consumers. We also use Hyperic to send an alert as soon as there is zero consumer for our queues. Finally, we would rather use enterprise monitoring software for dealing with the services we rely on, and collect statistics, trigger alerts, consolidate all the enterprise information within one console, instead of duplicating the effort. And I didn't like the way SSB forces us to either enable or disable the monitoring when the endpoint starts, pulsing the statistics all the time, instead of waiting that a console asks for them.

Anyway, as many people already said, I liked the simplicity and small scope of the project, and that's why I ran away from MassTransit or NServiceBus.

Nov 5, 2010 at 2:08 AM

That's a very elegant way of doing message routing, I like that a lot. I also agree after considering a bit that separating workflow management (aka sagas) from the service bus is probably better, i.e. instead of building a concept of sagas into the bus, it may be better to have the orchestration in a separate system and have it use the bus simply for message passing. That's ultimately how we ended up arranging our system, and it makes modeling business processes and how they map to service interactions very straightforward.

Nov 5, 2010 at 4:37 AM

Yea the configuration is a little complex. I did something similar to livetocode, but I added a simple list of messages for each category of services and then register that at start-up. But decorating the classes is a nice way. Please write something up if you have a chance.

I also fell for the monitoring in SSB, but in the end I never implemented it either. I also came to the conclusion that an external system (that can monitor other aspects as well) was a better solution for me.

Yes, the simple aspect of SSB, the fact that everything was exposed as interfaces and synchronous wrappers on top was that made us pick SSB. As far as Sagas go, I too believe that it doesn't belong in (this kind of) service buses. Orchestration in itself is a very big topic, I was part of a group that wrote our own BPEL-WS1 engine from scratch so I know first-hand, something I don't mind keeping outside SSB. But SSB would be an excellent delivery mechanism for a Saga system.

Nov 5, 2010 at 11:27 AM

Hi, Thanks all for the input.. i do agree with the "Simple" part. That's why most of these features should be made "optional" in seperate libs using SSB as delivery mechanism ( like plastic lizard says).

Concerning time: This seems to be everybody's problem these days , mine included ;-)

@LiveToCode: That sounds like a very nice solution. I would love to see / hear a bit more about it.

Jan 18, 2011 at 8:30 AM

Hi everyone,

I'm planning on using a light ServiceBus for an project.

I've found SSB and it seems to fit my needs. Will the development go on for this project, since the last commit was from July 2010 I think.


Jan 18, 2011 at 8:34 AM

Hi! No guarantees, but personally I'm using SSB in a production system with 1000s of messages through the system each day. I do some fixes in SSB when I find something (a few commits recently), but no major new features are planned. If SSB solves your need then I'd say go ahead and use it. If you depend on some future features that don't exist today, then you probably need to go look some more.

I decided on SSB because the implementation is very clean, plus the impact to my system to replace it with something else would probably be low, fairly low dependency overall.