Home

What problem does this component solve?

When this component was originally conceived it was intended to be used in a product, to provide a PubSub extension point to that product. The developers of the product could add the PubSub message publishing component and if the customers of the product needed to integrate it with some other applications they could do so by defining a subscriber, dropping it in the bin, and it would just start working. The original design aimed to make the underlying PubSub component as easy to use as a generic List or Stack.

Along the way I added other requirements, I wanted it to be easy to use by the developers, so it does a lot of self configuration and it offers practically no customization points. I also did not see any need to add customization without requirements for those. So the defaults meet the needs for a specific case. I wanted it to be usable by any IoC container, so I did not take a dependency on any container.

The original design was based around the concept of a Queuing mechanism, but as it turned out this was not a great choice because I am not abstracting transportation, nor am I aiming to abstract the off loading of work. The component does off load the work to a separate thread but not in the way that you see a classic queuing mechanism working. In the end a database approach makes more sense (which the EsentProvider follows). A message is saved to the database along with a list of subscribers. When each subscriber is completed the database is updated when all subscribers are completed the message is removed. IN the MSMQ provider this is achieved via saving and removing messages.

Notes:

Some of the Unit tests will fail when they are all run together. Its because I have not figured out how to completely Isolate them from each other. There are only so many hours in the day :-)